NETWORK ANALYZER
COMMUNICATION LAB
1
Table Of Contents
ATM NETWORKS ..................................................................................................... 3
ATM GOALS.......................................................................................................... 3
ATM CHARACTERISTICS .................................................................................... 6
ATM LAYERING ................................................................................................... 7
ATM Cell structure ................................................................................................. 7
ATM Adaption Layers (AAL's) .............................................................................. 11
RADCOM NETWORK ANALYZER ......................................................................... 14
CONNECTIONS .................................................................................................. 16
ANALYZER DESKTOP ........................................................................................ 18
ATM CELL SIMULATION ........................................................................................ 22
CONNECTIONS .................................................................................................. 23
DESKTOP CONFIGURATION ............................................................................. 24
STARTING THE SIMULATION PROCESS.......................................................... 28
CAPTURING THE SIMULATION ......................................................................... 31
HTTP CAPTURE ..................................................................................................... 36
CONNECTIONS .................................................................................................. 37
More Preperations ............................................................................................... 38
DESKTOP CONFIGURATION ............................................................................. 39
STARTING THE CAPTURING PROCESS ........................................... 43
2
ATM NETWORKS
ATM GOALS
The ATM network protocol was designed to solve a problem in
existing network protocols, the problem was that they were designed
originally as "single purpose" networks - networks designed to
provide only one type of service and had a very limited ability
(sometimes no ability at all) to provide other services, the most
hardest thing is in networking is the combination of all sorts of traffic
types like voice, video and data over the same lines.
The requirements of modern networking involve:

Handling multiple types of traffic (voice, video, data), all with
individual characteristics that make very different demands
(sometimes downright opposed to each other) of the
communications channel

A fair and equitable way of charging for transport services, to
provide the user with economically priced access, and the
carrier with a profitable return on investment

Reliability and flexibility of the communications links

Ensuring accessibility to network capacity for both existing and
future equipment and services with minimal disruption in
existing operations
Of all solutions proposed today it would seem that the technology
that could best answer these demands is Asynchronous Transfer
Mode or ATM.
3
Let's examine the different types of traffic and their demands on a
communication channel:
Voice:

Its generation is asynchronous (a speaker may speak anytime)

Its transmission must be synchronous (once the message
starts, it must flow continuously as it is spoken)

The bandwidth required for a voice conversation in digital
communication is relatively small and constant (64K)

The signals may contain a high degree of error and the
information can still be retrieved correctly (after all, at each end
there is an intelligent human being that can always ask "Huh,
whaddya say?")
Video

The generation is synchronous (continuous)

Its transmission is synchronous (you wouldn't like to see first a
half a head, then a pair of feet, then the rest of the image of a
person)

The bandwidth required is variable and it could range from
under 64 Kbps to several MBPS in the same session.

(Humans require 25-30 images/second and sometimes, with a
sudden change in scenery and a lot of excitement before the
camera, there is a tremendous amount of information to be
sent in an awfully short time; some other times only very small
changes between consecutive screens need be transmitted)

Error control should be tight - otherwise the wrong information
on the monitor may trigger severe wrongful actions (security
misinformation, wrong reaction of robots, etc.)
4
Data

Its generation could be either asynchronous (text) or
synchronous (telemetry)

Its transmission in general can be asynchronous (data typically
can wait patiently in buffers), so no special timing relationship
between the transmitter and the receiver is required

The amount of bandwidth varies enormously from a few bits
per second to billions of bits per second

The information is extremely error-sensitive, so extreme
caution must be exercised in transmission and error control
must be very tight.
5
ATM CHARACTERISTICS
1. Connection Oriented - That means creating a "Virtual circuit"
between the two stations before starting data transfer (just like
telephony networks).
2. A signaling mechanism for creating the virtual circuits.
3. Allocation of Band Width to the different users is done
asynchronously, according to the needs (hence. ATM).
4. ATM is designed to have a uniform platform for all types of
services(voice, data video etc.).
figure: ATM layering
6
ATM LAYERING

Physical layer : deals with the transmitting and recieving of
data bits.

ATM Cell switching : creates the Cell with 53 bytes of data,
the first 5 bytes of the Cell are header bytes and contains the
routing fields, data type etc., the last 48 bytes are the Payload the data.

ATM Adaption Layer : translates the data from the different
type of users and with different size, according to the different
services.
ATM Cell structure
header (5
bytes)
Payload (48 bytes)
The use of fixed and short length gives ATM several advantages:

Hardware switching : an atm switch reads the header and
immidiately switches it to i'ts destination.

The ability to transfer all type of data : whether stable rate
data (voice video) or burst rate data (LAN).

Quality Of Service : It is possible to assess the switching and
relay delays and provide QOS to all types of traffic (voice video
etc.).
7

Parallel Processing : fixed length cells enables the use of
Hardware switching based of parallel processing and achieve
very high rates.
ATM does not protect data from errors. ATM relies on user
equipment error control, and therefore works well on digital lines with
low bit error rates. The cells for one user are transmitted over a
Permanent or Switched Virtual Circuit Connection (PVC or SVC) . in
ATM, the paths over which various circuit connections are made are
prebuilt. This saves processing time both at the user-to-network
interface (UNI) and network-to-network interface (NNI).
This also goes hand-in-hand with the carrier system of choice for
ATM, SONET (Synchronous Optical Network), which defines user
paths using its lines and sections of fiber.
8
figure: ATM Connections
The cell header contains (among other things) a field of eight bits to
define possible virtual paths at the UNI (256 physical destinations)
and a field of sixteen bits to define up to 65,536 virtual circuits on
each path.
At the NNI (in the network -- between switches) the number of virtual
paths is increased to 4,096 (twelve bits) because it is assumed that
the network will carry many more than just one user.
The two fields are called VPI (Virtual Path Identifier) and VCI (Virtual
Circuit Identifier) respectively. A virtual connection (VC) will carry
data, voice or video (not all simultaneously). Each type of traffic
requires at least one unique VC.
9
figure: ATM UNI and NNI Cells
Header fields:

GFC (Generic flow control) : A 4 bit field exists only in UNI for
flow control.

VPI (Virtual Path Identifier) :A 8 bit field that defines a virtual
path - A path is a tube that can hold several virtual channels.

VCI (Virtual Channel Identifier) :A 16 bit field that defines A
virtual channel.

PT (Payload Type) : Indicates the type off traffic in the data
field, AAL type and network congestion.

CLP (Cell Loss Priority) : 1 bit indicates the this is dispensible
in a case of overload (if CLP==1).

HEC (Header Error Control) :A 8 bit field for finding error in
the cell header.
10
ATM Adaption Layers (AAL's)
While the cells are docile little workers carrying information in their
payload bit-times, some will get lost due to noise or equipment
failure, others due to congestion. Therefore, various types of traffic
generators with their different requirements have to carefully prepare
or 'adapt' their messages for travel over the ATM network.
This is done in each case by a piece of software or firmware called
AAL (ATM Adaptation Layer).
The AAL has two stages:

A service (or traffic type) -dependent sublayer called
Convergence Sublayer (CS).

A service-independent Segmentation And Reassembly (SAR)
sublayer
The CS assures the necessary error control and sequencing as well
as the sizing of information. The SAR then chops the CS message
into the 48-byte payload packets and attaches them to the five-byte
header. There are five types of adaptation layer services, designated
AAL1, AAL 2, etc. At the transmit node AAL1 prepares voice traffic,
AAL2 prepares video traffic, AAL3 and AAL5 prepare connectionoriented data (TCP-like data) and AAL4 prepares connectionless
data (SMDS or LAN-like) for cell relay switching. After the preparation
stage, the message is delivered to the segmentation layer, where the
cells are created and sent.
11
At the receive side the cells go through the reassembly layer and are
passed to AAL1, 2, 3, 4, or 5 for the recreation of the original
message. This message is then delivered to the video monitor, the
voice receiver or the data process expecting it.
AAL3 and AAL5 are both intended for connection-oriented data.
However, AAL3 is a complex, sophisticated preparer designed by a
committee of the ITU - TSS (Telecommunications Standards Sector,
formerly known as CCITT). AAL5 is much simpler and relies mostly
on the fact that the network is error-free most of the time. AAL5 is
also known as SEAL (Simple and Efficient Adaptation Layer) and is
the creation of the ATM Forum, an organization of users,
manufacturers and carriers that try to steer ATM services with
common sense. Presently ITU-TSS is studying AAL5.
Our only interest at this point is on AAL5:
12
Before the TCP or some other data message is chopped into cells, a
'trailer' is appended to that message, containing a 'length' indicator of
two bytes (TCP segments can be 65,536 bytes long), a CRC error
checking code for the whole message, and some bits signaling userto-user (end-to-end) what this message is about (this is still under
study and is to be used by each user equipment as it sees fit). Then
this 'adapted' message is put through the chopper and the cells are
sent.
13
RADCOM NETWORK ANALYZER
The Network Analyzer is a component that connects to a
communication network through different interfaces and analyzes the
traffic in the network's different levels.
The Network Analyzer connects to the Network and listen to the
traffic or creates traffic itself without interfering with the data flow.
The Analyzer can do the following things:


Monitoring the network.
o
Data capture.
o
Statistics.
o
Graphic analysis of the captured data.
o
Detecting the physical range of the network.
o
Displaying the data in different levels.
Simulation of data in the network.
14
15
CONNECTIONS
The Analyzer connects to the Network through fiber optics, it actually
sevesas a mediator between two network components (like :ATM
switch or ATM Hdevice) and in a monitoring mode does not interfere
with the network flow but just monitoring each cell going through it.
Here is a schematical diagram on the connections :
Explenation:

Connect Tx of channel1 in the Analyzer to Rx in ATM
switch/Hdevice 1.

Connect Rx of channel1 in the Analyzer to Tx in ATM
switch/Hdevice 1.

Connect Tx of channel2 in the Analyzer to Rx in ATM
switch/Hdevice 2.

Connect Rx of channel2 in the Analyzer to Tx in ATM
switch/Hdevice 2.
16
In the Cell Simulation experiment we need a different configuration:
Explenation :

Connect Tx of channel1 in the Analyzer to Rx of channel2 in
the Analyzer.

Connect Rx of channel1 in the Analyzer to Tx of channel2 in
the Analyzer
17
ANALYZER DESKTOP
To open the Analyzer desktop double click on the PrismLite Icon on
the windows Desktop.
The Analyzer desktop looks like this :
18
Config button
The config button allows you to change the the channel asignment.
We will use only the "ATM Cell Simulation" - for learning about the
structure of a cell, and "Monitor" for monitoring the traffic in the
network (focus on HTTP frames).
19
Processes button
Allows you to control which processes to run (capture, simulation,
analysis and more).
As we said earlier we will consentrate on the Capture (monitoring)
and Simulation (ATM Cell Simulation).
20
Processes windows
In the bottom of the analyzer Desktop there is a list of widows
available:
If we want to add/remove a window we do in by pressing the
Processes button and selecting/unselecting the desired process.
21
ATM CELL SIMULATION
In this experiment we will test the Analyzer ability to produce an ATM
cell and send it cotinously at any rate(load) we choose.
we will build our own cell and set the cell parameters (header) like
VCI , VPI we want and eventually even select or build owr own
payload (data).
We will then monitor the traffic we are producing using the capture
window and see if what we wanted to send is inded what was sent.
22
CONNECTIONS
Because we want to produce our own cell, then Transmit it and then
capture it - we need to get it back to us so we need to create some
sort of loop.
A loop means that we need to Recieve what we are transmitting, our
set up looks like this:
Explenation :

Connect Tx of channel1 in the Analyzer to Rx of channel2 in
the Analyzer.

Connect Rx of channel1 in the Analyzer to Tx of channel2 in
the Analyzer
So everything we send from one channel will be recieved in the
other.
23
DESKTOP CONFIGURATION
Now we need to configure out Analyzer desktop so it will suit our
demands.
As you already know the Desktop looks like this:
First we need to configure our channel assignment so that the
analyzer know what to do, so press the config button.
24
This window is the channel assignment window from here you can
choose the working mode for each channel.
In this window you need to set the "Working Mode" to ATM Cell
Simulation (as is already set).
Now press Config and get the next window:
25
Here you can determine the port's configuration, we want to capture
AAL5 cells so we will set the analyzer to do so, Now press the config
button for the Frame Level.
And press the VPCI Definition:
26
In the Type fiels choose AAL5_Cell (that means that the information
will be captured as Cells and not as frames) now press OK.
(in the following menus keep pressing ok untill you get to the main
screen).
The system will now do some adjustments (which will take a few
seconds).
Now lets make sure that we are running the right processes, press
the processes button :
27
Make sure that the Capture button and the Simulation check boxes
are checked, press apply.
STARTING THE SIMULATION PROCESS
In the buttom of the screen you will see some minimized windows :
We will consentrate on Simulation and Capture.
Maximize the Simulation window, and press setup :
28
In the Transmit buttons choose Continuously - which means that the
cells we will produce will be transmitted untill we will stop the process
manually.
Choose The Bandwidth load factor you want.
Now press Builder which will help you build your Cell :
It is possible to build An ip packet, AAL5 packet and more but we will
consentrate on the Cell Builder, so press the Cell builder, and in the
next window press New - because we want to build our own cell.
29

Choose a name for your cell.

Choose interface (UNI or NNI).

Choose VPI (0 - 255 for UNI or 0 - 4095 for NNI).

Choose VCI (0 - 65535). (Do not choose VPI==0 and VCI==0
because this is defined to be the void cell).

Choose PT (payload type) = 0.

In the payload choose Raw Cell.

In the data choose Quick brown fox (The quick brown fox
jumped over the lazy dog....) or choose user defined and write
your own payload (in ASCII).
press OK.
30
In the cell list choose your new cell, press OK and press OK in the
builder and afterwards in the simulation setup window.
Youre cell simulation is ready to run.
Press GO to start the simulation.
CAPTURING THE SIMULATION
What we did so far was to simply create an endless flow of cells from
the analyzer and back to the analyzer, we now want to capture this
flow.
Maximize the minimized Capture window; this will open the capture
window.
In the capture window click Go:
31
You can see the cells running but you still cannot see the 48 bytes
you've put in the payload fields,
Press the button that says Protocol (in the upper left side of this
window) :
32
In the Start decoding... choose Raw data, click OK.
Now your Capture window looks like this:
33
As you can see you get frame by frame each frame contains exactly
one Cell (see that Length == 48 for all frames, exactly the payload of
an atm cell), notice also that the VCI and VPI are the ones you chose
and that the payload is "The quick brown fox..".
Now you can try doing the same, but this time in the Builder choose
stream builder and set a number of different cells, each one with a
different VCI and VPI.
34
You can also use the IP builder and build an IP packet, ICMP
protocol, Echo Request that sends "ping" which asks for the
destination computer to send back an echo reply.
ENJOY
35
HTTP CAPTURE
In this experiment we will test the Analyzer ability to capture an HTTP
transaction between a web server and a web client, we want to see
how exactly the interaction works in this protocol.
We will use our computer as the web client, and we also need
another computer (with windows NT/2000 SERVER and a web
server installed).
36
CONNECTIONS
Our setup includes at least 5 components :

A web server.

A web client.

The network Analyzer.

An ATM switch.

Another ATM switch / ATM Hdevice.
And in a more details about the Analyzer connections:
37
More Preperations
In order for you to do this experiment you need to make sure you
move some files from this disk to the Web Server.
In this disk you will find a Directory called "files for server", inside this
directory there are three html files :

default.html

frame1.html

frame2.html
copy these files to the default web directory in the web server
computer, it should be the directort: "c:\inetPub\wwwroot".
Also make sure that this is indeed the default directory for the web
pages and that "default.html" is the default file in this server.
38
DESKTOP CONFIGURATION
Now we need to configure out Analyzer desktop so it will suit our
demands.
As you already know the Desktop looks like this:
First we need to configure our channel assignment so that the
analyzer know what to do, so press the config button.
39
This window is the channel assignment window from here you can
choose the working mode for each channel.
In this window you need to set the "Working Mode" to Monitor (as is
already set).
Now press Config and get the next window:
Here you can determine the port's configuration, press the config
button for the Frame Level :
40
And press the VPCI Definition:
In the type select box you need to select : AAL5, and press OK.
(in the following menus keep pressing ok untill you get to the main
screen).
The system will now do some adjustments (which will take a few
seconds).
41
Now lets make sure that we are running the right processes, press
the processes button:
Make sure that the Capture button check box is checked, press
apply.
42
STARTING THE CAPTURING PROCESS
In the buttom of the screen you will see some minimized windows :
We will consentrate on Capture.
Maximize the minimized Capture window :
Press GO.
43
Now you should see lots of frames passing by, we want to see HTTP
frames so lets setup the system to capture HTTP frames.
Press the "All" button and then the "Protocol" button you will get a
protocol setup window:
44
In the Start decoding.... field choose HTTP, now press OK.
Now you will see again lots of frames, but this time you will see a
field containing the HTTP content of each frame, some will mean
nothing to you so we will just have to search for the right ones for us.
Now we want to load the HTML file from our web server, so open a
new Internet Explorer Application and write the server IP num,
wait untill the page is loaded intirely.
go back to the capture window and hit STOP, to stop the capturing
process.
in this window start searching for the lines that look like this:
45
Frame: 0 Captured at: +00:11.198
Length: 240 From: Network Status: Ok
ATM: Status - O.K
ATM: Station - 0,37
ATM: VPI - 0
ATM: VCI - 37
ATM: AAL Type - 5
HTTP: Fragmented Data
HTTP: ...`.J...`.J.&[email protected]."8o...GET / HTTP/1.0
HTTP: Accept: */*
HTTP: Accept-Language: he
HTTP: User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)
HTTP: Host: 132.72.45.146
HTTP: Connection: Keep-Alive
HTTP:
HTTP: ................E..
this is the HTTP frame which asks the web server for the web page
"GET / HTTP/1.0"
notice that the host's IP address is metioned.
So this is the request for the web page, now let us look for the web
server reply.
This will probably look like this :
46
Frame: 0 Captured at: +00:05.489
Length: 528 From: User Status: Ok
ATM: Status - O.K
ATM: Station - 0,37
ATM: VPI - 0
ATM: VCI - 37
ATM: AAL Type - 5
HTTP: Fragmented Data
HTTP: ...`.J.&.`[email protected].!.{...HTTP/1.1 200 OK
HTTP: Server: Microsoft-IIS/4.0
HTTP: Connection: keep-alive
HTTP: Content-Location: http://132.72.45.146/default.html
HTTP: Date: Thu, 18 Jan 2001 12:41:33 GMT
HTTP: Content-Type: text/html
HTTP: Accept-Ranges: bytes
HTTP: Last-Modified: Thu, 18 Jan 2001 12:40:35 GMT
HTTP: ETag: "6047bcda4b81c01:e51"
HTTP: Content-Length: 131
HTTP:
HTTP: <html>
HTTP: <frameset cols="20%,80%">
HTTP: <frame src="frame1.html" name="f14">
HTTP: <frame src="frame2.html" name="f22">
HTTP: </frameset>
HTTP: </html>...................................0..
here also we can see that the server is sending some identifying data
about himself, and at last the HTML page which begins with <html>
and ends with </html>.
47
As we said earlier our purpose of this experiment is to use the
ANALYZER to analyze th http protocol and learn a bit about how it
works.
As you can see this html page is simply a "frame" that devides the
screen into 2 parts, the content of each part is not important, what is
important is to see how these calls for the 2 pages "frame1.html" and
"frame2.html" are made.
Try to guess yourself , is the first frame brought all at once and then
the other, or maybe in a parallel way , a bit from the first page and a
bit from the second page ( These 2 file are about 20 - 100Kb each so
it makes sence that they won't be brought in one packet).
Well try for your self,
The first page "frame1.html" is made entirely of the letter Z.
The second page "frame2.html" is made entirely of the letter A.
Now start looking at the rest of the capture window identify the
messages from your computer to the server which are mostly
requests for html pages ("get frame1.html" and "get frame2.html") ,
and the frames from the server are the actual web pages (in html
format).
You can probably see that after the request for the first page most of
the frames are from the server containing the english letter "Z", but if
you continue paging while paying attention to the frames you will see
another request to the second page and after that how the 2 pages
are brought "simoultanously", a bit of "ZZZZZZZZZZ" and a bit of
"AAAAAAAA" all the way.
48
now do the same with a more comlicated file one with a background
and pictures inside (not only ASCII files but also binary files), and see
if this is the same with these kind of files (of course you cannot tell
which binary fileis which but you can understand this from the "get"
commands from the user asking for the next image before the first
one is finished).
ENJOY
49