21.01.2015 Views

Frame Relay

Frame Relay

Frame Relay

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>Frame</strong> <strong>Relay</strong><br />

Petr Grygárek<br />

rek<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies 1


Basic characteristics<br />

• Used to implement WAN links over shared infrastructure<br />

• infrastructure provided by independent operator<br />

• private <strong>Frame</strong>-<strong>Relay</strong> infrastructure<br />

• Layer 2 technology<br />

• Assumes fast and reliable links between switching elements in FR cloud<br />

• No hop-by-hop error-control and flow-control<br />

• upper layers of user devices have to solve it by themselves<br />

• Fast and efficient switching<br />

• Independent of layer 3 protocol(s) used<br />

• Virtual-circuit based<br />

• implemented using fast frame (L2) switching (“relaying”)<br />

• Fast VC creation/deletion (compared to leased line)<br />

• QoS-enabled<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

2


Infrastructure and DTEs<br />

Most-common DTEs<br />

• Router<br />

• <strong>Frame</strong> <strong>Relay</strong> Access Device (FRAD)<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

3


Virtual circuits<br />

• Set-up over FR infrastructure (cloud)<br />

• Simulate “real” circuits with predefined parameters<br />

• Permanent Virtual Circuit (PVC)<br />

• requires (software based) preconfiguration by infrastructure provider<br />

• used most often<br />

• Switched Virtual Circuit (SVC)<br />

• created on user-device (DTE) demand<br />

• need for signalling standard and unique DTE addresses<br />

• Q.933 – similar to ISDN Q.931<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

4


VC Principle<br />

FR Switch<br />

I 1<br />

I 2<br />

I 1<br />

DLCI in<br />

I 2<br />

I in<br />

FR Switch<br />

110<br />

DLCI out I out<br />

----------------------------------------<br />

110 I 2<br />

17 I 3<br />

17 I 3<br />

110 I 2<br />

I 3 17<br />

DTE B<br />

I 1<br />

I 2<br />

I 1<br />

FR Switch<br />

56 121<br />

DTE A<br />

I 3<br />

DLCI in<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

I in<br />

DLCI out I out<br />

----------------------------------------<br />

56 I 3<br />

121 I 2<br />

121 I 2<br />

56 I 3<br />

I 2<br />

FR Switch<br />

DLCI in<br />

I in<br />

DLCI out I out<br />

----------------------------------------<br />

121 I 1<br />

110 I 2<br />

110 I 2<br />

121 I 1<br />

5


Data Link Connection Identifier<br />

(DLCI)<br />

• Identifies individual virtual circuits on local loop<br />

• and on inter-FR-switch links, if network cloud implemented<br />

using FR switches<br />

• 10-bit value<br />

• Locally unique<br />

• can be repeated on different links<br />

• Assigned by FR cloud operator<br />

• User DLCI: 16 to 1007<br />

• <strong>Frame</strong> <strong>Relay</strong> switches change DLCI along PVC path<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

6


Virtual circuit configuration<br />

(FR switch-based infrastructure)<br />

• In each FR switch along PVC path, switching<br />

table entry must be entered<br />

• <br />

• Both PVC direction must be configured<br />

• the same DLCIs used on each link in both directions<br />

commonly<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

7


DLCI local significance<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

8


Virtual circuit advantages<br />

• Requires only one physical access line regardless<br />

to number of virtual circuits established<br />

• doesn’t require multiple leased lines to customer site<br />

• per PVC payment, but smaller fees compared to<br />

separate leased lines<br />

• Flexible – new circuits can be quickly added and<br />

unnecessary ones deleted on as-needed basis<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

9


Switched virtual circuits (SVC)<br />

• Q.933 signalling between user and FR switch<br />

• subset of Q.931<br />

• Sent over DLCI 0 (together with LMI messages)<br />

• Q.922 provides reliable link for Q.933 messages transfer<br />

• QoS parameters appointed during call setup<br />

• Connection establishment:<br />

• SETUP, PROGRESS, ALERTING, CALL PROCEEDING,<br />

CONNECT, CONNECT ACK<br />

• Connection Termination:<br />

• DISCONNECT, RELEASE, RELEASE COMPLETE<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

10


Local access loop<br />

•Subscriber connected by single leased line (or ISDN)<br />

•Typical access line rates 56kbps to (approx) 54 Mbps<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

11


<strong>Frame</strong> <strong>Relay</strong> standard<br />

<strong>Frame</strong>-relay defines es local access loop, not<br />

implementation of network cloud<br />

(infrastructure)<br />

• may be built upon frame-relay switches, ATM,<br />

connectionless IP or other technology<br />

• invisible to <strong>Frame</strong> <strong>Relay</strong> user<br />

• Infrastructure must provide committed<br />

parameters to provisioned VCs<br />

• CAR, Bc, Be, …<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

12


<strong>Frame</strong> <strong>Relay</strong> Standardization Bodies<br />

1. Gang of Four:<br />

1.<br />

• DEC, Cisco, Northern Telecom, StrataCom …<br />

2. www.frforum.com<br />

2.<br />

• Cooperates with ITU-T<br />

• FRF.x standards<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

13


<strong>Frame</strong> <strong>Relay</strong> Interfaces<br />

• User-to-Network Interface (UNI)<br />

• between customer and FR operator<br />

• Network-to-Network Interface (UNI)<br />

• between two FR operators<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

14


User-to-Network Interface<br />

(UNI)<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

15


DTE to DCE protocol (Q.922)<br />

• <strong>Frame</strong> delimited by flags (bit stuffing used)<br />

• <strong>Frame</strong> based on HDLC<br />

• Variable frame length (max 8/16kB)<br />

• Multiple frame formats (historical reasons)<br />

• IETF (RFC1490)<br />

• (older) CISCO frame: 4B header<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

16


<strong>Frame</strong> header fields (1)<br />

• DLCI – Data Link Connection Identifier<br />

• C/R (Command/Response) bit<br />

• currently unused (maintained for compatibility with<br />

HDLC)<br />

• EA (Extended Address)<br />

• if set to 1, current byte is the last addressing byte<br />

(otherwise another byte follows)<br />

• Provides capability to extend DLCI in the future<br />

• Current implementations all use 2B address field<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

17


<strong>Frame</strong> header fields (2)<br />

Fields for congestion avoidance and resolution<br />

• FECN – Forward Explicit Congestion<br />

Notification<br />

• BECN – Backward Explicit Congestion<br />

Notification<br />

• DE – Discard Eligibility<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

18


Multiprotocol encapsulation<br />

<strong>Frame</strong> header does not carry layer 3 protocol ID<br />

• FRF.3/RFC 1490 - Multiprotocol Interconnect over <strong>Frame</strong> <strong>Relay</strong><br />

• L3 protocol given by NLPID<br />

NLPID (Network Layer Protocol ID)<br />

• 2 bytes just behind frame header<br />

• NLPID values defined in ISO/IEC TR 9577<br />

• NLPID may indicate usage of SNAP header<br />

• Earlier proprietary L3 protocol ID identification<br />

Can vary on different VCs<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

19


Network to Network Interface<br />

(NNI)<br />

• Connects two different FR clouds<br />

• Supports multi-network PVCs<br />

• Consists of PVC segments (over individual FR<br />

clouds)<br />

• DLCI assignment and QoS parameters setting<br />

coordination needed on NNI<br />

• Bridges signalling protocols variations<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

20


Local Management Interface<br />

(LMI)<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

21


Local Management Interface (LMI)<br />

• Operates between DTE and FR access switch<br />

• FR DTE, FR DCE<br />

• Multiple variations (historical reasons)<br />

• ANSI T1.617 (=Annex D), q933a(=Annex A), Gang<br />

of Four<br />

• DLCI 0 / 1023<br />

• VC status messages<br />

• DTE-DCE line keepalives<br />

• Obtaining list of VCs from FR switch<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

22


LMI frame<br />

• Carried in normal FR frame<br />

• reserved protocol number (0x09)<br />

• Reserved DLCI<br />

• Call reference – unused<br />

• Message Type<br />

• Status-inquiry<br />

• Status-message (keepalive), Full Status Message (PVC list)<br />

• differ in IEs included<br />

• Variable number of information elements (IE)<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

23


<strong>Frame</strong> <strong>Relay</strong> Congestion<br />

Management<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

24


Congestion avoidance and recovery<br />

• Congestion avoidance<br />

• ability to inform stations about emerging congestion<br />

• Congestion recovery<br />

• actions taken to recover from congestion and return<br />

to normal operating state<br />

• frame discard<br />

Separate for every VC and direction<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

25


Congestion avoidance<br />

implementation<br />

• Backward<br />

Explicit<br />

Congestion<br />

Notification (BECN)<br />

• Set by intermediate switching elements to ask source to slow<br />

down<br />

• Cisco: source slows down by 25 % (if not under configured minimal<br />

imal<br />

CIR)<br />

• Forward Explicit<br />

Congestion<br />

Notification (FECN(<br />

FECN)<br />

• Set by intermediate switching elements to inform destination<br />

it should ask source to slow down<br />

• Destination utilizes upper layer protocol to accomplish that<br />

• (e.g. TCP starts to delay ACKs)<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

26


Congestion recovery<br />

implementation<br />

• Discard Eligibility (DE) bit<br />

• Set by access FR switch for nonconforming frames<br />

• If congestion occurs on some link, frames with DE<br />

set should be dropped first<br />

• May be set by source DTE to give priorities to<br />

traffic entering FR cloud<br />

• If congestion persists even when DE frames<br />

discarded, network have to start discarding of<br />

non-DE frames<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

27


<strong>Frame</strong> <strong>Relay</strong> QoS parameters,<br />

their measurement and enforcement<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

28


FR virtual circuit QoS parameters<br />

Parameters take into account bursty nature of traffic<br />

• Bc – committed burst<br />

• Maximum amount of data the network commits to deliver over a VC during<br />

appointed interval Tc<br />

• Committed information rate (CIR)<br />

• estimate of normal traffic during a busy period<br />

• CIR=Bc/Tc<br />

• Sum of CIRs of all VCs commonly greater than physical access line speed<br />

• Be - excess burst<br />

• Maximum amount of data by which a user can exceed Bc during an interval Tc<br />

• Delivered at lower probability than the data within Bc<br />

• Excess Information Rate (EIR)<br />

• EIR=Be/Tc<br />

• <strong>Frame</strong> above CIR+EIR (maximum rate) are discarded<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

29


Service Level Agreement<br />

Access rate = physical access line bitrate<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

30


Traffic policing and traffic shaping<br />

• Traffic policing – done at provider’s network<br />

edge to limit traffic coming from customer<br />

• Traffic exceeding committed information rate is<br />

either discarded or marked as eligible for later<br />

discard<br />

• Traffic shaping – done at customer boundary<br />

router to shape traffic to comply with rate<br />

provider agrees to transfer<br />

• uses memory buffers to shape bursts<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

31


Traffic policing<br />

• Runs on FR access switch<br />

• Determines whether to pass incoming frame to<br />

network cloud, mark it as discard eligible or<br />

discard it<br />

• No further traffic flow measurements are taken<br />

inside network cloud<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

32


Traffic shaping /rate limiting<br />

• Applied at customer boundary router<br />

• Mechanism to smooth (bursty) traffic flow to<br />

meet service provider requirements (CIR,Bc,Be)<br />

• <strong>Frame</strong>s exceeding agreement are buffered and<br />

sent later<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

33


Traffic policing/shaping<br />

implementation algorithms<br />

• Leaky bucket<br />

• imposes a hard limit on the data transmission rate<br />

• Token bucket<br />

• allows a certain amount of burstiness while imposing<br />

a limit on the average data transmission rate<br />

• sometimes considered an improvement of Leaky<br />

bucket<br />

Leaky bucket and token bucket algorithms are<br />

often mistakenly lumped together<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

34


Leaky bucket Algorithm<br />

Provides a mechanism by which bursty traffic can be shaped into<br />

steady stream of traffic to the network<br />

• Arriving frames are placed in a bucket with a hole in the bottom<br />

• The bucket can queue at most b bytes. If a frame arrives when<br />

the bucket is full, the frame is discarded.<br />

• <strong>Frame</strong>s s drain through the hole in the bucket, into the network, at<br />

a constant rate of r bytes per second, thus smoothing traffic<br />

bursts.<br />

• In practise, we need to sent not exactly r bytes, but whole frame<br />

Ineffective, do not allow to pass traffic bursts even if network<br />

bandwidth is available<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

35


Token Bucket Algorithm<br />

• Once per time interval (Tc), tokens are added to the<br />

bucket<br />

• Number corresponds to CIR in Bytes/second<br />

• Bucket has limited capacity (Bc+Be), overleaking tokens are<br />

discarded<br />

• If frame arrives, token bucket is checked whether there<br />

is at least as many tokens as data byte count in<br />

incoming frame<br />

• If there is enough tokens, frame is passed and appropriate<br />

number of tokens removed from the bucket<br />

• Otherwise, the frame is stored into waiting queue (buffered) /<br />

discarded<br />

• Be e allows to “save” some tokens from previous Tc<br />

interval(s) to the current one<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

36


Token Bucket Implementation<br />

• FR access switch maintains a cumulative amount<br />

of data sent by user (counter C)<br />

• C decremented by Bc every Tc interval<br />

• C is always greater than 0<br />

• When frame arrives<br />

• If C Bc+Be: Discard frame<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

37


Typical rate limiting usage<br />

Often physical local loop rate at central site<br />

outperforms physical local loop rate at branch<br />

site<br />

• Because we want to communicate with multiple<br />

branch sites<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

38


TCP/IP over <strong>Frame</strong> <strong>Relay</strong><br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

39


Scenerio<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

40


Typical <strong>Frame</strong> <strong>Relay</strong> usage<br />

topologies<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

41


Typical usage<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

42


Relationship between IP subnets and<br />

FR virtual circuits<br />

• One physical router interface may correspond to<br />

one VC<br />

• One physical router interface may accommodate<br />

multiple VCs (more(<br />

obvious)<br />

• logical subinterface assigned to every VC<br />

• bound to right VC by DLCI configuration<br />

• behaves like physical interface from routing<br />

protocol’s point of view<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

43


Subinterfaces<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

44


<strong>Frame</strong> <strong>Relay</strong> (sub)interface types<br />

• Point-to-point<br />

• separate IP subnet for every subinterface<br />

• Point-to-multipoint<br />

• common IP subnet on all VCs<br />

• similar to broadcast network, but without broadcast<br />

capability<br />

• router interface “routes” between connected VCs<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

45


IP to DLCI mapping<br />

• Point-to-point interface<br />

• Single IP address and DLCI configured<br />

• Point-to-multipoint interface<br />

• IP address of local side of (all) VCs configured<br />

• Static maps configured<br />

• for every possible peer IP address we configure DLCI of<br />

VC connected to that peer<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

46


Inverse ARP (INARP)<br />

INARP allows automatic discovery of peer IP address to<br />

DLCI mapping<br />

• If no DLCI or static map is configured on<br />

(sub)interface, router sends INARP FR <strong>Frame</strong> to every<br />

known VC<br />

• List of available DLCIs can be obtained from FR switch<br />

using LMI<br />

• Peer responds with L3 address configured on it’s<br />

interface<br />

• DLCI-to-peer-address mapping dynamic entry can be<br />

created<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

47


<strong>Frame</strong>-relay routing problems<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

48


DV routing updates problems<br />

• Distance vector routing protocols use broadcast<br />

to send routing updates<br />

• Cisco implementation: VCs do not pass<br />

broadcasts if not explicitly configured to do so<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

49


Split Horizon problem<br />

Split-horizon rule must be abandoned on physical<br />

interface accommodating multiple VCs<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

50


OSPF<br />

• <strong>Frame</strong>-relay cloud represented with NBMA network<br />

node type in OSPF topology graph<br />

• Non-Broadcast Multi Access = multiple neighbors accessible<br />

via single physical interface, but no single broadcast frame<br />

can be sent to all of them<br />

• Be careful when configuring DR priorities on NBMA<br />

network with other than full-mesh topology<br />

• DR should be directly connected to all other routers using<br />

VC<br />

• Different OSPF timers used on NBMA networks<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

51


FR Additional features<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

52


FR multicast support<br />

• All multicast traffic of a multicast group sent to<br />

entity called multicast server, which forwards<br />

data to multicast group members<br />

• DLCI 1019-1022 reserved for that purpose<br />

• One-way and two-way multicast<br />

• Additional LMI messages defined to notify user<br />

about addition, deletion and presence of<br />

multicast group<br />

Not supported by most operators<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

53


Interesting FR references<br />

• http://www.cisco<br />

cisco.com/univercd/cc/td/doc/cisintwk/<br />

ito_doc<br />

doc/frame.htm<br />

• Overview and basic concepts<br />

• http://www.protocols.com/pbook/frame.htm<br />

• Detailed overview of FR standards<br />

• http://www.cse.wustl.edu/~jain/cis788-95/ftp/frame_relay<br />

• Advanced FR features<br />

• http://qbone.internet2.edu/bb/Bucket.doc<br />

• http://en.wikipedia.org/wiki/Token_bucket<br />

• Token Bucket/Leaky Bucket algorithm<br />

© 2005 Petr Grygarek, Advanced Computer Networks Technologies<br />

54

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!