310 likes | 416 Vues
Frame Relay. Packet switching system with low overhead Assumes very reliable high-quality physical network Developed for use in ISDN networks Used widely in a variety of private and public networks which are not ISDN. 3. 4. 13. 1. 2. 15. 14. 16. X.25 Packet Flow. Intermediate node.
E N D
Frame Relay • Packet switching system with low overhead • Assumes very reliable high-quality physical network • Developed for use in ISDN networks • Used widely in a variety of private and public networks which are not ISDN
3 4 13 1 2 15 14 16 X.25 Packet Flow Intermediate node 12 5 6 11 2 8 7 10 9 Source Destination
Frame Relay Packet Flow Intermediate node 2 3 7 6 1 2 8 5 4 Source Destination
Frame Relay • Control Signalling carried on separate logical connection from user data • Multiplexing and switching of logical connections take place at layer 2 not layer 3 • No hop-by-hop flow control or error control • Protocol functionality at user-network interface is reduced • Large increase in throughput over X.25
Frame Relay Protocol Architecture Control Plane User Plane User Plane Control Plane Q.931/Q.933 User-selectable TE functions User-selectable TE functions Q.931/Q.933 LAPD (Q.921) LAPD (Q.921) LAPF core (Q.922) LAPF core (Q.922) I.430/I.431 Physical I.430/I.431 Physical
Control Plane Protocols • Q.933 protocol is used for control of connections • In ISDN, Control signalling uses LAPD protocol • It is also possible to use in-channel call control using Q.933 on top of Q.922
User Plane Protocols • LAPF (Q922) used for data transfer between users • LAPF Core functions: • Frame delimiting, alignment, transparency • Frame multiplexing / de-multiplexing • Frame integrity checking ( size, byte count, errors) • Congestion control • Functions are a sub-layer of data link layer • They provide a bare frame transfer service
Frame Relay and X.25 X.25 Implemented by end system not network Implemented by end system and network LAPB LAPF control LAPF core I.430/I431 Implemented by end system and network I.430/I431
Frame Relay Call Control • Subscriber must first be connected to a frame handler • This is called an access connection • When access connection is made, multiple logical channels can be multiplexed on the connection • These are called frame relay connections • They can be on-demand or semi-permanent
Frame Relay Call Control • Two types of access connection • Switched Access • User on switched network where exchange does not have frame handling capability • Exchange provides switched access (demand or semi-permanent) to remote frame handler • Integrated Access • User connected to pure frame relay network or switched network with integrated frame handling in local exchange • User has direct logical access to frame handler
User Access Switched access connection TE NT ET ET FH Semi-permanent access connection Switched access TE NT ET FH Local exchange Integrated access
Frame Relay Connections • Analogous to virtual circuit in X.25 • Can be established when access connection established to frame handler • Multiple connections supported over single link • Called data link connections • Each connection has a unique Data link connection identifier (DLCI)
Frame Relay Connections • Data transfer sequence • Establish logical connection between two endpoints and assign unique DLCI • Exchange information in data frames - each frame has a DLCI • Release logical connection
Frame Relay Connections • Establishment and release of Logical connection is made by messages over dedicated call control logical connection with DLCI =0
Frame Relay Control Signalling Frame Relay Network NT ISDN NT Setup Setup D-channel Q.931 exchange to establish B-channel circuit- switched connection Connect Connect ack Connect Connect ack Setup B-channel Q.933 exchange to establish B-channel frame - mode connection Setup Connect Connect ack Connect ack Connect Frame relay Q.922 exchange of user data on B-Channel Message exchange for switched access to frame handler over ISDN
Frame Relay Control Signalling Frame Relay Network NT ISDN NT Disconnect Disconnect B-channel Q.933 exchange to release B-channel frame- mode connection Release Release Release complete Release complete D-channel Q.931 exchange to release B-channel circuit - switched connection Disconnect Disconnect Release Release Release complete Release complete Message exchange for terminating switched access to frame handler
LAPF Frame Format Flag 1 octet Address 2 - 4 octets Information variable length FCS 2 octets Flag 1 octet Frame Format 8 7 6 5 4 3 2 1 Upper DLCI C/R EA 0 Lower DLCI FECN BECN DE EA 1 Address field 2 octets (default) Legend EA Address field extension bit C/R Command/response bit DE Discard eligibility bit FECN Forward explicit congestion notification BECN Backward explicit congestion notification DLCI Data link connection identifier
LAPF Frame Format • No control field exists in the frame • The connection can only carry user data • Therefore no in-band signalling exists • No error control or flow control exists since there are no sequence numbers
LAPF Frame Format • Address field carries DLCI • Address field length may be extended to 2, 3, or 4 octets • Length determined by EA bits - default is 2 octets • DLCI allows multiple logical connections to be multiplexed on single channel • DLCI can be 10, 17 or 24 bits depending on address field length
Congestion Control • No in-channel control signalling means no sliding window flow control • Congestion control is the joint responsibility of the network and the end-user • Network monitors congestion • User controls congestion by limiting flow of traffic at origin • Network discards packets as a last resort
Technique Type Discard Control Discard Strategy Backward explicit congestion notification Congestion avoidance Forward explicit congestion notification Congestion avoidance implicit congestion notification Congestion recovery Congestion Control Techniques Function Key elements Provides guidance to network about which frames to discard DE bit Provides guidance to end-systems about congestion in network BECN bit Provides guidance to end-systems about congestion in network FECN bit End system infers congestion from frame loss Sequence numbers in higher-layer PDU
Discard Strategy • Network agrees to support a connection at a certain data rate: • Committed information rate (CIR) in bps • Committed burst size (Bc) in bits over time T • Network also negotiates excess burst size (Be) the maximum amount of data in excess of Bc it will attempt to transfer in normal conditions
Discard Strategy • Frame handler monitors traffic on a logical connection • If data rate exceeds Bc in time interval T it will set DE bit and forward packet • If data rate exceeds Bc+ Be in time interval T it will discard data
Discard Strategy Bits Transmitted Discard Region Bc+Be DE = 1 Region Bc Access Rate CIR D = 0 Region Time Frame 2 DE=0 Frame 1 DE=0 Frame 3 DE=0 T
Discard Strategy Bits Transmitted Discard Region Bc+Be DE = 1 Region Bc Access Rate CIR D = 0 Region Time Frame 1 DE=0 Frame 2 DE=1 Frame 3 DE=1 T
Discard Strategy Bits Transmitted Discard Region Bc+Be DE = 1 Region Bc Access Rate CIR D = 0 Region Time Frame 1 DE=0 Frame 2 DE=1 Frame 3 Discard T
Congestion Avoidance • Network alerts end-systems to growing congestion • End-systems reduce offered load to network • Two methods exist in frame relay • Forward explicit congestion notification (FECN) • Backward explicit congestion notification (BECN)
Congestion Avoidance • Two bits, FECN and BECN exist in each frame address field • Any frame handler that detects may set either bit • Any frame handler receiving a frame with a bit set must forward the frame with the bit set • The bits therefore are signals to the end-user
Congestion Avoidance • The frame handler monitors outgoing queue lengths • Determines average queue length • If average exceed a threshold, then FECN bit or BECN bit or both is set • They may be set for certain logical connections or all depending on queue sizes
Congestion Avoidance • On receipt of BECN signal, user reduces rate of frame transmission • On receipt of FECN signal, user notifies peer user to reduce rate of frame transmission
Congestion Recovery • When higher-level end-end protocol detects frame loss it assumes congestion • This is called implicit signalling • Flow control may be used to recover • Gradual reduction of window size and gradual increase as frame loss disappears