TO 2-14-06 p. 1 Spring 2006 EE 5304/EETS 7304 Internet Protocols Tom Oh Dept of Electrical Engineering [email protected] Lecture 6 Network Protocol

TO 2-14-06 p. 1

Spring 2006

EE 5304/EETS 7304 Internet Protocols

Tom OhDept of Electrical Engineering

[email protected]

Lecture 6

Network Protocol (ATM)

TO 2-14-06 p. 2

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. 3

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

Assumes reliable, high rate digital transmission links Fast packet switching can be suitable for both real-time

traffic (eg, speech) and nonreal-time data

TO 2-14-06 p. 4

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

Routing decision is made once, during connection establishment

Simplifies and speeds up packet processing

TO 2-14-06 p. 5

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• Simple header, shorter packet to minimize packetization delay

and effect of lost speech packet

TO 2-14-06 p. 6

ATM Cell Format (cont)

ITU made compromise on cell length: 48 bytes info. + 5 byte header

at UNI at NNI

GFC VPIVPI VCI

VCIVCI PT

HEC

48-byte data

CLP

VPIVPI VCI

VCIVCI PT

HEC

48-byte data

CLP

8 bits 8 bits

TO 2-14-06 p. 7


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 Meaning

'000' user data, cell type 0, no congestion

'001' user data, cell type 1, no congestion

'010' user data, cell type 0, congestion experienced

'011' user data, cell type 1, congestion experienced

'100' OAM F5 segment cell

'101' OAM F5 end-to-end cell

'110' resource management (RM) cell for ABR

'111' reserved for future use

TO 2-14-06 p. 8


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

Use CRC code over header only Switches between single bit error correction and error

detection-only

TO 2-14-06 p. 9


Correctionmode

(default)

Detectionmode

No errors detected

Single-bit errordetected and corrected,

or multiple-bit errorsdetected and cell

discarded

No action

Cellsdiscarded

TO 2-14-06 p. 10

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. 11

QoS (cont)

QoS parameter Definition

Accuracy Cell error ratio (CER) fraction of cells delivered with bit errors

Severely errored cellblock ratio (SECBR)

fraction of N-cell blocks delivered with M or more errored cells

QoS aspect

Cell misinsertion rate

rate of appearance of misdirected cells from a different connection

Cell loss ratio (CLR) fraction of cells not deliveredDependability

Speed Cell transfer delay (CTD) maximum delay in delivering cells measured by p-percentile

Cell delay variation (CDV) range between maximum and minimum cell delays, or deviation of cell delivery times from a reference pattern

ATM QoS Parameters

TO 2-14-06 p. 12

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 time-varying bandwidth, eg, compressed voice/video

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

TO 2-14-06 p. 13

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

No traffic control

TO 2-14-06 p. 14

QoS (cont)

Main QOS parameters are max. cell delay, CDV, and CLR

Specified QOS parameters depend on what is important to type of service

CBR rt-VBR nrt-VBR ABR

Cell transfer delay Negotiated Unspecified

Cell loss ratio UnspecifiedNegotiated

UBR

Cell delay variation Negotiated Unspecified

Cell error ratio Implicit

ImplicitCell misinsertion ratio

TO 2-14-06 p. 15

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. 16

Spring 2006

EE 5304/EETS 7304 Internet Protocols

Tom OhDept of Electrical Engineering

[email protected]

Lecture 6

IPv4, ICMP

TO 2-14-06 p. 17

Outline

Role of IP in internetworking

IPv4 packet header

Internet Control Message Protocol (ICMP)

TO 2-14-06 p. 18

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

Gateways translate different protocols Each network communicates with other networks using a

common universal protocol

TO 2-14-06 p. 19

Gateways

Networks understand their own protocol, and gateways convert packets between networks

NetworkA

NetworkB

NetworkC

A:Bgateway

B:Cgateway

TO 2-14-06 p. 20

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’

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

TO 2-14-06 p. 21

Routers

Networks communicate by common Internet protocol

Routers forward IP packets between networks

NetworkA

NetworkB

NetworkC

TO 2-14-06 p. 22

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’

Common protocol establishes a baseline expectation for capabilities (connection-oriented/connectionless, QoS assurances, minimum packet size, etc.)

Internet has some type of structural organization

TO 2-14-06 p. 23

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

No guarantees on delivery, delays, or sequential order

TO 2-14-06 p. 24

IPv4 Datagram Header Format

VERS HLEN TOS TOTAL LENGTH

bits: 4 4 4 4 4 4 4 4

IDENTIFICATION FRAGMENT OFFSETFlags

PROTOCOLTTL HEADER CHECKSUM

SOURCE IP ADDRESS

DESTINATION IP ADDRESS

IP OPTIONS (if any)

Version (4 bits): currently 4, new version 6

TO 2-14-06 p. 25

IPv4 Datagram Header Format (cont)


bits: 4 4 4 4 4 4 4 4



SOURCE IP ADDRESS


IP OPTIONS (if any)

Header length (4 bits): in units of 4-bytes (commonly 20 bytes → HLEN = 5)

TO 2-14-06 p. 26



bits: 4 4 4 4 4 4 4 4



SOURCE IP ADDRESS


IP OPTIONS (if any)

Type of service (8 bits): original definition

P P P D T R C 0

TO 2-14-06 p. 27

ToS Field

Precedence (3 bits): importance

000: routine 001: priority 010: immediate 110: internetwork control 111: network control

TO 2-14-06 p. 28

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. 29

ToS Field (cont)

ToS field specification not clear and required more work for routers → not widely supported and now obsoleted

Current definitionD D D D D D E E

Explicit congestion notification (2 bits) [RFC 3168]

00: not used01: no congestion10: no congestion11: congestion experienced

Diffserv code point (6 bits) [RFC 2474]

TO 2-14-06 p. 30



bits: 4 4 4 4 4 4 4 4



SOURCE IP ADDRESS


IP OPTIONS (if any)

Total length (16 bits): of datagram in bytes (max 65,535 bytes)

TO 2-14-06 p. 31



bits: 4 4 4 4 4 4 4 4



SOURCE IP ADDRESS


IP OPTIONS (if any)

Identification (16 bits): to identify fragments belonging to same original packet

Flags (3 bits): used for fragmentation

Fragment offset (13 bits): used for fragmentation

TO 2-14-06 p. 32

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

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

TO 2-14-06 p. 33

Fragmentation (cont)

Identification field: all fragments belonging to same original datagram should have same Identification number (value has no other meaning)

Flags:

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

TO 2-14-06 p. 34


Fragment offset (13 bits): used for reassembly of fragments into datagram

Indicates where this fragment belongs in original datagram Offset is measured in 8-byte units

TO 2-14-06 p. 35


DATA

byte 0 byte 600 byte 1200

IP Header

DATAIP Header

DATAIP Header

DATAIP Header

Fragment 1offset = 0



Datagram

Example: datagram is fragmented into 3 fragments (each becomes a separate IP datagram)

TO 2-14-06 p. 36


Example: datagram of 288 data bytes is fragmented into 3 fragments of 128, 128, and 32 bytes

Header field Fragment 1

Header length 5

Total length 148

Fragment offset 0

Identification 99

MF 1

Fragment 2

5

148

16

99

1

Fragment 3

5

52

32

99

0

TO 2-14-06 p. 37



bits: 4 4 4 4 4 4 4 4



SOURCE IP ADDRESS


IP OPTIONS (if any)

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

TO 2-14-06 p. 38



bits: 4 4 4 4 4 4 4 4



SOURCE IP ADDRESS


IP OPTIONS (if any)

Protocol (8 bits): identifies higher layer protocol using datagram

TO 2-14-06 p. 39

Protocol Field

Common protocol values [full list in RFC 2780]

ValueValue ProtocolProtocol

1 ICMP

6 TCP

8 Exterior gateway protocol

9 Any private interior gateway protocol

17 UDP

45 Interdomain routing protocol

88 EIGRP

89 OSPF

TO 2-14-06 p. 40



bits: 4 4 4 4 4 4 4 4



SOURCE IP ADDRESS


IP OPTIONS (if any)

Header checksum (16 bits): to detect errors in packet header

TO 2-14-06 p. 41

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

Error check of data field is responsibility of higher layers

TO 2-14-06 p. 42

Header Checksum

IP header:

2 bytes

2 bytes

+ + + + + + + + =

Checksuminitially 0

ChecksumSummation

TO 2-14-06 p. 43


Source address (32 bits) and destination address (32 bits)

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

TO 2-14-06 p. 44

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• Few networks, each network has many hosts• 7 bits for netID (max. 128), 24 bits to hostID (max. 16.8

million)

TO 2-14-06 p. 45


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

Many networks, each network has few hosts 21 bits to netID (max. 2 million), 8 bits to hostID (max.

256)

NetID

bits: 7 24

HostID0

NetID

14 16

HostID

NetID

21 8

HostID1

Class A

Class B

Class C

01

1 0

TO 2-14-06 p. 46


Difficulties:

Hosts moving to a different network must get new address Class C network growing into class B network involves

administrative effort

TO 2-14-06 p. 47

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): • 0: datagram or network control• 1: reserved for future use• 2: debugging and measurement• 3: reserved for future use

TO 2-14-06 p. 48

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.orgbits: 1 2

COPY OPTION CLASS

5

OPTION NUMBER

TO 2-14-06 p. 49

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 Loose source routing: can make detours as long as hit the

addresses on list

TO 2-14-06 p. 50


Example: timestamp (option 11)

Source creates an empty list of addresses and timestamps Each switch adds its IP address and time that datagram

was handled

TO 2-14-06 p. 51

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

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?

TO 2-14-06 p. 52

ICMP (cont)

IP header ICMP message

Type ChecksumCode Type-specific data

IP payload

8 bits 8 bits 16 bits Variable

TO 2-14-06 p. 53

ICMP Message Format (cont)

Type (8 bits) : function of message

0: Echo Reply 3: Destination Unreachable 4: Source Quench 5: Redirect 8: Echo Request 11: Time Exceeded 13: Timestamp Request 14: Timestamp Reply

TO 2-14-06 p. 54

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. 55

ICMP (cont)

Example: Echo Request and Echo Reply

Used in ping (Packet InterNet Groper) program Host A sends echo request to B 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

TO 2-14-06 p. 56

ICMP (cont)

Example: Destination Unreachable

Returned to source host when a router cannot forward an IP datagram for various reasons

bits: 8

TYPE (3)

8

CODE (0-12) CHECKSUM

IP HEADER + FIRST 64 BITS OF DATAGRAM

8 8

UNUSED (ALL ZERO)

TO 2-14-06 p. 57

ICMP (cont)

Example: Source Quench

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

TO 2-14-06 p. 58

ICMP (cont)

Example: Time Exceeded

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)

TO 2-14-06 p. 59

ICMP (cont)

Used in traceroute program to discover route of IP datagrams (which often take same route)

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

TO 2-14-06 p. 60

ICMP (cont)

Example: Timestamp Request and Timestamp Reply

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

TO 2-14-06 p. 61

ICMP (cont)

bits: 8

TYPE (13 or 14)

8

CODE (0) CHECKSUM

ORIGINATE TIMESTAMP

8 8

SEQUENCE NUMBERIDENTIFIER

RECEIVE TIMESTAMP

TRANSMIT TIMESTAMP

TO 2-14-06 p. 62

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. 63

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)

Documents

TO 2-14-06 p. 1 Spring 2006 EE 5304/EETS 7304 Internet Protocols Tom Oh Dept of Electrical Engineering [email protected] Lecture 6 Network Protocol