Chapter 11 Frame Relay Background Frame Relay Protocol

Chapter 11. Frame Relay • Background • Frame Relay Protocol Architecture • Frame Relay Call Control • User Data Transfer • Network Function • Congestion Control 1

Background • Key features of X. 25 – not only determines the user-network interface but also influences the internal design of the network – Call control packets are carried on the same channel and the same virtual circuit as data packets inband signaling – Multiplexing of virtual circuits takes place at layer 3 – Both layer 2 and layer 3 include flow control and error control mechanisms 2

Background (cont) • Goal of frame relay – eliminate much of the overhead that X. 25 imposes on end user systems and on the packet-switching network • Difference between frame relay and X. 25 – Call control signaling is carried on a separate logical connection from user data – Multiplexing and switching of logical connections take place at layer 2 – No hop-by-hop flow control and error control – End-to-end flow/error control are the responsibility of a higher layer 3

Packet switching v. s. Frame Relay 12 14 Packet-Switching (X. 25) 16 X. 25 3 1 6 4 X. 25 2 5 15 9 Source 8 FR 2 8 Source 10 3 6 7 FR 7 Destination Frame Relay 1 X. 25 11 13 FR 5 4 Destination 4

Frame Relay Protocol Architecture 5

User Plane • Transfer of information of btw end users • Uses core function of LAPF – Frame delimiting, alignment – Frame multiplexing/demultiplexing – Inspection of the frame to ensure that • it consists of an integral number of octets • it is neither too long nor too short – Detection of transmission error – Congestion control function 6

Frame Relay v. s. X. 25 7

Frame Relay v. s. X. 25 (cont) 8

Frame Relay Call Control Terminal equipment Network equipment Exchange termination Frame Handler 9

Frame Relay Call Control (cont) 10

Frame Relay Connection • Support multiple connections over a single link • Data link connection – DLCI: data link connection identifier • DLCI = 0 – dedicated to call control – 4 message types: SETUP, CONNECT, RELEASE COMPLETE 11

Control Signaling (e. g. ) 12

Frame Format (LAPF-core) 13

Frame Format (cont) • Only one frame type – used for carrying user data – no control frames • Not possible to use inband signaling – since a logical connection can only carry user data • Not possible to perform flow/error control – since there are no sequence number • DLCI – serves the same function as the virtual circuit number in X. 25 14

Network Function Routing based on DLCI Multiplex multiple logical connections 15

Congestion Control 16

Congestion Control (cont) 17

Congestion Control (cont) • Objectives (ITU-I Recommendation I. 370) – Minimize frame discard – Maintain an agreed quality of service – Minimize the possibility that one end user can monopolize network resources at the expense of other end users – Be simple to implement, and place little overhead – Create minimal additional network traffic – Distribute network resources fairly among end users – Limit spread of congestion – Minimize the variance in quality of service delivered to individual frame relay connections during congestion 18

Congestion Control (cont) Implicit (delay, discard) Policing Backpressure S/W Source S/W Destination Choke packet Explicit (binary, credit, rate) 19

Congestion Control (cont) • Backpressure – On the basis of links or logical connections – X. 25 -based packet-switching networks – Neither FR nor ATM has any capability for restricting flow on a hop-by-hop basis • Choke packet – A control packet generated at a congested node and transmitted back to a source node to restrict traffic flow – E. g. ICMP Source Quench packet – The source quench message can be used to a router or host that must discard IP datagrams because of a full buffer 20

Congestion Control (cont) • Implicit Congestion Signaling – By transmission delay and discarded packets – Effective technique in connectionless or datagrams configurations, such as IP-based internet – TCP: detect increased delay and segment loss • Explicit Congestion Signaling – The network alerts end systems and end systems take steps to reduce the offered load – Backward and Forward directions – Binary, Credit based, and Rate based approaches 21

Congestion Control (cont) • Limited tools available to the frame relay • Joint responsibility of the network and the end users – The network is in the best position to monitor the degree of congestion – The end users are in the best position to control congestion by limiting the flow of traffic • When congestion becomes severe enough – The network is forced to discard frames – In a way that is fair to all users 22

FR Congestion Control • Discard strategy • Congestion avoidance – Requires some explicit signaling mechanisms • Congestion recovery – Dropped frames are reported by some higher layer software – Implicit signaling mechanism 23

FR Congestion Control (cont) 24

Traffic Rate management • Reason – The simplest way to cope with congestion for FR is to discard frames arbitrarily – Since there is no reward for restraint, the best strategy is to transmit frames as rapidly as possible → exacerbates the congestion problem – Introduce the concept of a committed information rate (CIR) 25

Traffic Rate management (cont) • Committed information rate (CIR) • Committed Burst Size (Bc) – Max. amount of data that the network agrees to transfer over a measurement interval T • Excess Burst Size (Be) – The maximum amount of data in excess of Bc that the network will attempt to transfer over T • T = Bc / CIR or Bc = CIR * T • S CIRi, j <= Access Ratej for channel j i 26

Traffic Rate management (cont) 27

Traffic Rate management (cont) 28

Leaky Bucket Algorithm pkt 29

Congestion Avoidance • With explicit signaling • Two points of view about congestion – congestion always occurred slowly and almost always in the network egress nodes – congestion grew very quickly in the internal nodes and required quick, decisive action to prevent network congestion • Two approaches – Forward network congestion avoidance – Backward network congestion avoidance 30

Forward Explicit Congestion Notification • FECN • The notification indicates that this frame, on this logical connection, has encountered congested resources • Receipt of FECN signals – It requires the user to notify its peer user of this connection to restrict its flow of frames. It must be done at a higher layer, such as transport layer 31

Backward Explicit Congestion Notification • BECN • The notification indicates that the frames transmitted by the user (being notified) on this logical connection may encounter congested resources • Receipt of BECN signals – The user simply reduces the rate at which frames are transmitted until the signal ceases 32

FECN v. s. BECN Notify the peer user to restrict the flow of frames congested FR BECN FR FECN User reduces the rate until the signal ceases 33

Congestion Recovery • With implicit signaling – Occurs when the network discards a frame, and this fact is detected by the end user at a higher, end-to-end layer – When this occurs, the end user software may deduce that congestion exists • Once congestion is detected – The protocol uses flow control to recover from the congestion 34