Frame Relay
Frame Relay
Frame Relay
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