Transcript Lecture 6 - Lyle School of Engineering

Spring 2006
EE 5304/EETS 7304 Internet Protocols
Lecture 6
Network Protocol (ATM)
Tom Oh
Dept of Electrical Engineering
[email protected]
TO 2-14-06 p. 1
Administrative Issues
 We will have test 1 on Feb. 28.
 Test will consists of Lecture 1- 5.

Mutiple choice, true/false, short answers,
 We will review for the test today.
 DVD students: If you don’t have proctor at your
site, please contact Gary McClesky as soon as
possible.
TO 2-14-06 p. 2
ATM (Comer Ch. 14)
 Asynchronous Transfer Mode was ITU standard in
late 1980s

Based on fast packet switching research in 1970s-1980s
 Objective: streamlined or "lightweight" protocol
allows fast packet processing and shorter packet
delays


TO 2-14-06 p. 3
Assumes reliable, high rate digital transmission links
Fast packet switching can be suitable for both real-time
traffic (eg, speech) and nonreal-time data
ATM (cont)
 No ACKs or retransmissions (no sequence
numbers)

Error control is done end-to-end (in higher protocol layer)
as needed
 Connection-oriented: virtual circuits


TO 2-14-06 p. 4
Routing decision is made once, during connection
establishment
Simplifies and speeds up packet processing
ATM Cell Format
 In ITU standards, US took position on cell (packet)
format: 64 bytes info. + 5 byte header

Data switching was important consideration
•
More complicated header
 Eur. position on cell format: 32 bytes info. + 4 byte
header

Speech multiplexing was important consideration
•
TO 2-14-06 p. 5
Simple header, shorter packet to minimize packetization delay
and effect of lost speech packet
ATM Cell Format (cont)
 ITU made compromise on cell length: 48 bytes info.
+ 5 byte header
at UNI
GFC
VPI
at NNI
VPI
VCI
VPI
VPI
VCI
VCI
PT
HEC
48-byte data
8 bits
TO 2-14-06 p. 6
VCI
VCI
CLP
VCI
PT
HEC
48-byte data
8 bits
CLP
ATM Cell Format (cont)
 GFC (4 bits): only at UNI; ignored by network; use
is not standardized
 VPI/VCI: 24 bits (UNI) or 28 bits (NNI) to identify
virtual circuit

Certain values are reserved for signaling cells (VCI=5),
OAM cells (VCI=3,4), etc.
 PT (payload type): 3 bits for EFCI, AAL5, and type
of cell
PT code
'000'
'001'
'010'
'011'
'100'
'101'
'110'
'111'
TO 2-14-06 p. 7
Meaning
us er data, cell type 0, no conges tion
us er data, cell type 1, no congestion
us er data, cell type 0, conges tion experienced
us er data, cell type 1, conges tion experienced
OAM F5 segment cell
OAM F5 end-to-end cell
resource management (RM) cell for ABR
reserved for future use
ATM Cell Format (cont)
 CLP (cell loss priority): 1 bit (CLP=1 cells are
discarded before CLP=0)


User may set CLP=1 for less important cells (eg, if layered
coding is used)
Network may set CLP=1 for excessive cells (see later)
 HEC (header error control): 8 bits to correct single
bit errors or detect bit errors


TO 2-14-06 p. 8
Use CRC code over header only
Switches between single bit error correction and error
detection-only
ATM Cell Format (cont)
No errors detected
No
action
Correction
mode
(default)
Detection
mode
Single-bit error
detected and corrected,
or multiple-bit errors
detected and cell
discarded
TO 2-14-06 p. 9
Cells
discarded
Quality of Service (QoS)
 QoS is a central concept in ATM



ATM is designed to support different services by treating
each connection according to its service class
More complicated than traditional packet switching
networks
Most networks are designed for best effort or only one type
of service (if any), e.g, reliable
 QoS parameters describe network performance
(impairments) per end-to-end connection oriented
to user’s viewpoint
TO 2-14-06 p. 10
QoS (cont)
ATM QoS Parameters
QoS aspect
Accuracy
TO 2-14-06 p. 11
QoS parameter
Definition
Cell error ratio (CER)
fraction of cells delivered with bit errors
Severely erro red cell
block ratio (SECBR)
fraction of N-cell blocks delivered with
M or more errored cells
Cell mis ins ertion
rate
rate of appearance of mis directed cells
from a different connection
Dependability
Cell loss ratio (CLR)
fraction of cells not delivered
Speed
Cell trans fer d elay (CTD)
maximum delay in delivering cells
measured by p-percentile
Cell d elay v ariation (CDV)
range between maximum and minimum
cell delays, or deviation of cell delivery
times from a reference pattern
ATM Services
 Constant bit-rate (CBR): for circuit-emulation for
real-time applications that need reserved
bandwidth

Traffic control: CAC, UPC
 Variable bit-rate (VBR): for applications with timevarying bandwidth, eg, compressed voice/video


TO 2-14-06 p. 12
Real-time VBR (rt-VBR): need guaranteed end-to-end
delay, eg, real-time compressed voice
Nonreal-time VBR (nrt-VBR): do not need end-to-end
delay guarantees, eg, nonreal-time data
ATM Services (cont)
 Available bit-rate (ABR): for data applications that
can be flow-controlled by feedback control, eg,
nonreal-time loss-sensitive rate-adaptable data

Traffic control: CAC, feedback control via RM cells
 Unspecified bit-rate (UBR): need only best-effort
service, eg, nonreal-time bursty data

TO 2-14-06 p. 13
No traffic control
QoS (cont)
 Main QOS parameters are max. cell delay, CDV, and
CLR

TO 2-14-06 p. 14
Specified QOS parameters depend on what is important to
type of service
Connection Admission Control (CAC)
 QoS is sustained mainly by connection admission
control

CAC allows network to accept or reject a new connection
request
 Source provides requested QoS level and traffic
rate parameters (eg, peak rate)


If accepted, network guarantees QoS as long as user
conforms to given traffic rate parameters
No feedback control during connection
 This approach relies on congestion prevention
instead of congestion reaction
TO 2-14-06 p. 15
Spring 2006
EE 5304/EETS 7304 Internet Protocols
Lecture 6
IPv4, ICMP
Tom Oh
Dept of Electrical Engineering
[email protected]
TO 2-14-06 p. 16
Outline
 Role of IP in internetworking
 IPv4 packet header
 Internet Control Message Protocol (ICMP)
TO 2-14-06 p. 17
Role of IP in Internetworking
 Different networks are owned and operated by
independent organizations, but need to work
together as internetwork or internet
 Two possible approaches


TO 2-14-06 p. 18
Gateways translate different protocols
Each network communicates with other networks using a
common universal protocol
Gateways
 Networks understand their own protocol, and
gateways convert packets between networks
A:B
gateway
Network
A
TO 2-14-06 p. 19
B:C
gateway
Network
B
Network
C
Gateways
 Networks can be simple - support only one protocol

Burden is put on gateways - gateways can be complicated
 If many types of networks → many types of
gateways
 No universal ‘lowest common denominator’



TO 2-14-06 p. 20
Individual networks many not support virtual connections,
QoS, signaling, etc.
Capabilities of one network may be ‘lost in translation’ to
another network without same capabilities
Internet has no real structural organization
Routers
 Networks communicate by common Internet
protocol

Routers forward IP packets between networks
Network
A
TO 2-14-06 p. 21
Network
B
Network
C
Routers
 Burden is put on networks to support a common
network-to-network protocol, in addition to internal
network protocol (which may be anything)

Routers are relatively simple packet switches
 Common protocol establishes a universal ‘lowest
common denominator’


TO 2-14-06 p. 22
Common protocol establishes a baseline expectation for
capabilities (connection-oriented/connectionless, QoS
assurances, minimum packet size, etc.)
Internet has some type of structural organization
Role of IP (cont)
 1978 IP version 4 specified [RFC 791]
 1983 mandated by DoD as requirement for any
networks to connect to ARPANET

1983 TCP/IP implemented in Unix BSD (Berkeley software
distribution)
 Design philosophy: IP is designed to be simple to
minimize burden on networks

Also economy of scale → inexpensive routers
 Best effort service: connectionless datagram
delivery

TO 2-14-06 p. 23
No guarantees on delivery, delays, or sequential order
IPv4 Datagram Header Format
Version (4 bits): currently 4, new version 6
bits :
4
4
VERS
HLEN
4
4
4
TOS
IDENTIFICATION
TTL
4
TOTAL LENGTH
Flags
PROTOCOL
FRAGMENT OFFSET
HEADER CHECKSUM
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
IP OPTIONS (if an y)
TO 2-14-06 p. 24
4
4
IPv4 Datagram Header Format (cont)
Header length (4 bits): in units of 4-bytes (commonly
20 bytes → HLEN = 5)
bits :
4
4
VERS
HLEN
4
4
4
TOS
IDENTIFICATION
TTL
4
TOTAL LENGTH
Flags
PROTOCOL
FRAGMENT OFFSET
HEADER CHECKSUM
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
IP OPTIONS (if an y)
TO 2-14-06 p. 25
4
4
IPv4 Datagram Header Format (cont)
Type of service (8 bits): original definition
P P P D T R C 0
bits :
4
4
VERS
HLEN
4
4
4
TOS
IDENTIFICATION
TTL
4
TOTAL LENGTH
Flags
PROTOCOL
FRAGMENT OFFSET
HEADER CHECKSUM
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
IP OPTIONS (if an y)
TO 2-14-06 p. 26
4
4
ToS Field
 Precedence (3 bits): importance
TO 2-14-06 p. 27

000: routine

001: priority

010: immediate

110: internetwork control

111: network control
ToS Field (cont)
 D flag (1 bit): minimize delay
 T flag (1 bit): maximize throughput
 R flag (1bit): maximize reliability
 C flag (1 bit): minimize monetary cost
 0 (1 bit): reserved
TO 2-14-06 p. 28
ToS Field (cont)
 ToS field specification not clear and required more
work for routers → not widely supported and now
obsoleted
 Current definition
D D D D D D E E
Diffserv code point
(6 bits) [RFC 2474]
TO 2-14-06 p. 29
Explicit congestion notification
(2 bits) [RFC 3168]
00: not used
01: no congestion
10: no congestion
11: congestion experienced
IPv4 Datagram Header Format (cont)
Total length (16 bits): of datagram in bytes (max
65,535 bytes)
bits :
4
4
VERS
HLEN
4
4
4
TOS
IDENTIFICATION
TTL
4
TOTAL LENGTH
Flags
PROTOCOL
FRAGMENT OFFSET
HEADER CHECKSUM
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
IP OPTIONS (if an y)
TO 2-14-06 p. 30
4
4
IPv4 Datagram Header Format (cont)
Identification (16 bits): to identify fragments
belonging to same original packet
Flags (3 bits): used for fragmentation
Fragment offset (13 bits): used
for fragmentation
bits :
4
4
VERS
HLEN
4
4
4
TOS
IDENTIFICATION
TTL
4
TOTAL LENGTH
Flags
PROTOCOL
FRAGMENT OFFSET
HEADER CHECKSUM
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
IP OPTIONS (if an y)
TO 2-14-06 p. 31
4
4
Fragmentation
 IP datagrams can be fragmented into multiple
smaller datagrams, each routed independently,
because networks may have limit on packet length
 Fragments are reassembled only at dest. host




TO 2-14-06 p. 32
Intermediate routers do not need to store/reassemble
fragments
But fragments can only get smaller and smaller →
inefficient
If fragment is lost, entire datagram is lost at dest.
Reassembly timer: datagram is discarded if all fragments
do not arrive by timeout from first fragment
Fragmentation (cont)
 Identification field: all fragments belonging to same
original datagram should have same Identification
number (value has no other meaning)
 Flags:



TO 2-14-06 p. 33
0 (1 bit): reserved
DF flag (1 bit): “don’t fragment” prevents datagram from
fragmentation (datagram may be discarded)
MF flag (1 bit): all fragments have “more fragments”=1
except last fragment has “more fragments”=0
Fragmentation (cont)
 Fragment offset (13 bits): used for reassembly of
fragments into datagram
TO 2-14-06 p. 34

Indicates where this fragment belongs in original datagram

Offset is measured in 8-byte units
Fragmentation (cont)
Example: datagram is fragmented into 3 fragments
(each becomes a separate IP datagram)
byte 0
Datagram
IP Header
Fragment 1
offs et = 0
IP Header
Fragment 2
offs et = 600
byte 600
DATA
DATA
IP Header
Fragment 3
offs et = 1200
TO 2-14-06 p. 35
byte 1200
DATA
IP Header
DATA
Fragmentation (cont)
Example: datagram of 288 data bytes is fragmented
into 3 fragments of 128, 128, and 32 bytes
TO 2-14-06 p. 36
Header field
Fragment 1
Fragment 2
Fragment 3
Header length
5
5
5
Total length
148
148
52
Fragment offset
0
16
32
Identification
99
99
99
MF
1
1
0
IPv4 Datagram Header Format (cont)
Time to live (8 bits): maximum lifetime of packet in seconds, to
prevent infinite looping in network
- Should be decremented by time at each router
- But since routers forward packets quickly, decrement by 1
sec -- TTL is hop count
- Recommended initial value 64
- Packet is discarded when TTL=0
bits :
4
4
VERS
HLEN
4
4
4
TOS
IDENTIFICATION
TTL
4
TOTAL LENGTH
Flags
PROTOCOL
FRAGMENT OFFSET
HEADER CHECKSUM
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
IP OPTIONS (if an y)
TO 2-14-06 p. 37
4
4
IPv4 Datagram Header Format (cont)
Protocol (8 bits): identifies higher layer protocol
using datagram
bits :
4
4
VERS
HLEN
4
4
4
TOS
IDENTIFICATION
TTL
4
TOTAL LENGTH
Flags
PROTOCOL
FRAGMENT OFFSET
HEADER CHECKSUM
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
IP OPTIONS (if an y)
TO 2-14-06 p. 38
4
4
Protocol Field
 Common protocol values [full list in RFC 2780]
TO 2-14-06 p. 39
Value
Protocol
1
ICMP
6
TCP
8
Exterior gateway protocol
9
Any private interior gateway protocol
17
UDP
45
Interdomain routing protocol
88
EIGRP
89
OSPF
IPv4 Datagram Header Format (cont)
Header checksum (16 bits): to detect errors
in packet header
bits :
4
4
VERS
HLEN
4
4
4
TOS
IDENTIFICATION
TTL
4
TOTAL LENGTH
Flags
PROTOCOL
FRAGMENT OFFSET
HEADER CHECKSUM
SOURCE IP ADDRESS
DESTINATION IP ADDRESS
IP OPTIONS (if an y)
TO 2-14-06 p. 40
4
4
IP Datagram Header (cont)
 Header checksum (16 bits):


Set checksum = 0, take 1's complement sum of all 16-bit
words in header
Checksum = 1's complement of result
 Recalculated at every switch because header
changes

Errored packets are discarded
 Applies to header only -- IP tries only to deliver to
right destination

TO 2-14-06 p. 41
Error check of data field is responsibility of higher layers
Header Checksum
Checksum
initially 0
2 bytes
IP header:
2 bytes
+
+
+
+
+
Summation
TO 2-14-06 p. 42
+
+
+
=
Checksum
IP Datagram Header (cont)
 Source address (32 bits) and destination address
(32 bits)




TO 2-14-06 p. 43
Every host has unique 32-bit address consisting of two
parts: (netID, hostID)
NetID allows more efficient routing in internetworking
(discussed more later)
NetID assigned by Internet Assigned Number Authority
(IANA) through the Internet Network Information Center
(INTERNIC)
All hosts on same network have same netID; hostID is
assigned locally
IP Addresses (cont)
 Address is usually written as 4 decimal numbers
separated by periods, each integer representing a
byte of the IP address

eg, 10000000 00001010 00000010 00011110 is written as
128.10.2.30
 Bit allocations are different per 5 classes (class is
indicated by first few bits of address field)

A: Very large networks
•
•
TO 2-14-06 p. 44
Few networks, each network has many hosts
7 bits for netID (max. 128), 24 bits to hostID (max. 16.8
million)
IP Datagram Header (cont)
 B: Medium size (campus) networks


More networks, each network has moderate number of
hosts
14 bits to netID (max. 16,384), 16 bits to hostID (max.
65,536)
 C: Small networks

bits :
7
Many networks,
each network has24 few hosts
Class A

0
NetID
HostID
14
21 bits to netID (max.
2 million), 8 bits16to hostID (max. 256)
Class B
1 0
NetID
HostID
21
Class C
TO 2-14-06 p. 45
1 1 0
NetID
8
HostID
IP Datagram Header (cont)
 Difficulties:


TO 2-14-06 p. 46
Hosts moving to a different network must get new address
Class C network growing into class B network involves
administrative effort
IP Datagram Header Options
 Option = option code (8 bits) + additional data bytes
(variable number)
 Option code:


Copy flag (1 bit): 1 = copy this option into all fragments; 0
= copy only into first fragment
Option class (2 bits):
•
•
•
•
TO 2-14-06 p. 47
0: datagram or network control
1: reserved for future use
2: debugging and measurement
3: reserved for future use
IP Datagram Header Options (cont)
 Option number (5 bits):

0: end of option list

3: loose source routing

7: record route

9: strict source routing

11: timestamp (if option class = 2)
 Complete list of options: www.iana.org
bits :
TO 2-14-06 p. 48
1
2
5
COPY
OPTION CLASS
OPTION NUMBER
IP Datagram Header Options (cont)
 Example: record route (option 7)


Source creates an empty list of IP addresses
Each switch adds its IP address to list when it passes
datagram
 Example: source route (option 3 or 9)

Allows source to specify a route, eg, to test a network

Source writes a list of IP addresses

Strict source routing: must follow list exactly

TO 2-14-06 p. 49
Loose source routing: can make detours as long as hit the
addresses on list
IP Datagram Header (cont)
 Example: timestamp (option 11)


TO 2-14-06 p. 50
Source creates an empty list of addresses and timestamps
Each switch adds its IP address and time that datagram
was handled
ICMP (Internet Control Message Protocol)
 Required part of IP, allows reporting of troubles and
network conditions

Otherwise, senders may make wrong assumptions and
choose wrong actions
 ICMP messages are carried in the data portion of IP
datagrams



TO 2-14-06 p. 51
Identified by protocol field = 1
But ICMP is not considered higher layer; same layer as IP
and a part of IP
Doesn’t this violate the principles of protocol layering?
ICMP (cont)
IP payload
IP header
TO 2-14-06 p. 52
ICMP message
8 bits
8 bits
16 bits
Type
Code
Checksum
Variable
Type-specific data
ICMP Message Format (cont)
 Type (8 bits) : function of message
TO 2-14-06 p. 53

0: Echo Reply

3: Destination Unreachable

4: Source Quench

5: Redirect

8: Echo Request

11: Time Exceeded

13: Timestamp Request

14: Timestamp Reply
ICMP Message Format (cont)
 Code (8 bits): more information about message
type

0: network unreachable

1: host unreachable

3: port unreachable

5: source route failed

6: destination network unknown

7: destination host unknown
 Checksum (16 bits): same as IP checksum but over
ICMP message only
 Additional fields: type-dependent
TO 2-14-06 p. 54
ICMP (cont)
 Example: Echo Request and Echo Reply

Used in ping (Packet InterNet Groper) program

Host A sends echo request to B


TO 2-14-06 p. 55
B returns echo reply with copy of identifier (sending
process ID), sequence number (packet ID), and optional
data in echo request
Tests that IP datagram routing and host software are
working properly, and also measures roundtrip delay as
estimate of distance
ICMP (cont)
 Example: Destination Unreachable

Returned to source host when a router cannot forward an
IP datagram for various reasons
bits:
8
8
TYPE (3)
CODE (0-12)
8
8
CHECKSUM
UNUSED (ALL ZERO)
IP HEADER + FIRST 64 BITS OF DATAGRAM
TO 2-14-06 p. 56
ICMP (cont)
 Example: Source Quench




TO 2-14-06 p. 57
Optional: congested router or host can return source
quench to reduce its transmission rate
No message to relieve source quench
Normally, source may decrease its rate until no more
source quench messages are received, then gradually
increases rate
Found to be ineffective, unfair, and consume bandwidth
during congestion-- not used much
ICMP (cont)
 Example: Time Exceeded



TO 2-14-06 p. 58
IP datagrams contain Time-to-live (or hop count) in header
to prevent looping
Field is decremented at each hop, and datagram is
discarded when field is 0
Then time exceeded message is returned to source host
(or when dest. host times out waiting for all fragments of a
datagram to arrive)
ICMP (cont)
 Used in traceroute program to discover route of IP
datagrams (which often take same route)



TO 2-14-06 p. 59
IP record route option is limited to 9 IP addresses, and not
consistently supported
Traceroute begins with datagram with TTL=1; first router
will discard and return ICMP time exceeded; traceroute
continues with datagram with TTL=2; and so on
Finally reaches host but datagram has unused UDP port
number-- host returns ICMP port unreachable
ICMP (cont)
 Example: Timestamp Request and Timestamp
Reply




TO 2-14-06 p. 60
A sends timestamp request (with origination time) to B to
get Bs clock reading of time of day
Upon receipt, B adds its clock reading (receive time)
When B returns timestamp reply, B adds its clock reading
(transmit time)
A uses 3 timestamps in timestamp reply message to
estimate its time difference from Bs clock
ICMP (cont)
bits:
8
8
TYPE (13 or 14)
CODE (0)
IDENTIFIER
8
8
CHECKSUM
SEQUENCE NUMBER
ORIGINATE TIMESTAMP
RECEIVE TIMESTAMP
TRANSMIT TIMESTAMP
TO 2-14-06 p. 61
TEST 1 Review
 Types of networks (size, switching, media, network
protocols, services)
 Standards
 Terminalogy
 OSI
 TCP/IP
 Data Link Layer (synchronization, error control,
error detection, hamming distance, hamming code,
Bit Interleaved Parity, horizontal/vertical parity
checks, ARQ Schemes)
TO 2-14-06 p. 62
Review
 LANs (general)
 MAC protocol (Aloha, CSMA, CSMA/CD, Token Ring)
 Bridges (Transparent Learning Bridges)
 Network Layer (Routing)
 Static routing, Source Routing, Flooding
 Dijkstra’s Algorithm, Bellman Ford Algorithm
 Distance Vector Routing (RIP, IGRP, EIGRP)
 Link State Routing.
 X. 25 ( Data and Control Packet, Sliding Window)
TO 2-14-06 p. 63