idnits 2.17.1 draft-ietf-mpls-fr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 270 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 9 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([ARCH], [LDP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 94: '... The keywords MUST, MUST NOT, MAY, O...' RFC 2119 keyword, line 95: '... SHALL, SHALL NOT, SHOULD, SHOUL...' RFC 2119 keyword, line 296: '... FR-LSRs MUST use a mechanism that i...' RFC 2119 keyword, line 331: '...ent", the FR-LSR MUST not label switch...' RFC 2119 keyword, line 436: '... label, which MUST be associated on...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '...ment is an I...' == Line 16 has weird spacing: '...cuments of t...' == Line 17 has weird spacing: '... groups may ...' == Line 21 has weird spacing: '...-Drafts may ...' == Line 22 has weird spacing: '...opriate to u...' == (265 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When an ingress FR-LSR determines upon decrementing the MPLS TTL that a particular packet's TTL will expire before the packet reaches the egress of the "non-TTL LSP segment", the FR-LSR MUST not label switch the packet, but rather follow the specifications in [STACK] in an attempt to return an error message to the packet's source. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 October 1998) is 9290 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'LDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'STACK' -- Possible downref: Non-RFC (?) normative reference: ref. 'ATM' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF' Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group A. Conta (Lucent) 3 INTERNET-DRAFT P. Doolan (Ennovate) 4 A. Malis (Ascend) 5 22 October 1998 7 Use of Label Switching on Frame Relay Networks 9 Specification 11 draft-ietf-mpls-fr-02.txt 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or obsoleted by 22 other documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as "work in 24 progress." 26 To view the entire list of current Internet-Drafts, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 29 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 30 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 32 Abstract 34 This document defines the model and generic mechanisms for 35 Multiprotocol Label Switching on Frame Relay networks. Furthermore, 36 it extends and clarifies portions of the Multiprotocol Label 37 Switching Architecture described in [ARCH] and the Label Distribution 38 Protocol described in [LDP] relative to Frame Relay Networks. MPLS 39 enables the use of Frame Relay Switches as Label Switching Routers 40 (LSRs). 42 Table of Contents 44 Status of this Memo.........................................1 45 Table of Contents...........................................2 46 1. Introduction................................................3 47 2. Terminology.................................................3 48 3. Special Characteristics of Frame Relay Switches.............4 49 4. Label Encapsulation.........................................5 50 5. Frame Relay Label Switching Processing......................6 51 5.1 Use of DLCIs..............................................6 52 5.2 Homogeneous LSPs..........................................7 53 5.3 Heterogeneous LSPs........................................7 54 5.4 Frame Relay Label Switching Loop Prevention and Control...8 55 5.4.1 FR-LSRs Loop Control - MPLS TTL Processing.............8 56 5.4.2 Performing MPLS TTL calculations.......................9 57 5.5 Label Processing by Ingress FR-LSRs......................11 58 5.6 Label Processing by Core FR-LSRs.........................12 59 5.7 Label Processing by Egress FR-LSRs.......................12 60 6 Label Switching Control Component for Frame Relay..........13 61 6.1 Hybrid Switches (Ships in the Night) ...................14 62 7 Label Allocation and Maintenance Procedures ...............14 63 7.1 Edge LSR Behavior........................................14 64 7.2 Efficient use of label space-Merging FR-LSRs.............17 65 7.3 LDP message fields specific to Frame Relay...............17 66 8 Security Considerations ..................................19 67 9 Acknowledgments ..........................................20 68 10 References ...............................................20 69 11 Authors' Addresses .......................................21 70 1. Introduction 72 The Multiprotocol Label Switching Architecture is described in 73 [ARCH]. It is possible to use Frame Relay switches as Label Switching 74 Routers. Such Frame Relay switches run network layer routing 75 algorithms (such as OSPF, IS-IS, etc.), and their forwarding is based 76 on the results of these routing algorithms. No specific Frame Relay 77 routing is needed. 79 When a Frame Relay switch is used for label switching, the current 80 label, on which forwarding decisions are based, is carried in the 81 DLCI field of the Frame Relay data link layer header of a frame. 82 Additional information carried along with the current label, but not 83 processed by Frame Relay switching, along with other labels, if the 84 packet is multiply labeled, are carried in the generic MPLS 85 encapsulation defined in [STACK]. 87 Frame Relay permanent virtual circuits (PVCs) could be configured to 88 carry label switching based traffic. The DLCIs would be used as MPLS 89 Labels and the Frame Relay switches would become MPLS switches while 90 the MPLS traffic would be encapsulated according to this 91 specification, and would be forwarded based on network layer routing 92 information. 94 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 95 SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as 96 defined in RFC 2119. 98 2. Terminology 100 LSR 102 A Label Switching Router (LSR) is a device which implements the 103 label switching control and forwarding components described in 104 [ARCH]. 106 LC-FR 108 A label switching controlled Frame Relay (LC-FR) interface is a 109 Frame Relay interface controlled by the label switching control 110 component. Packets traversing such an interface carry labels in 111 the DLCI field. 113 FR-LSR 115 A FR-LSR is an LSR with one or more LC-FR interfaces which 116 forwards frames onto these interfaces using labels carried in 117 the DLCI field. 119 FR-LSR cloud 121 A FR-LSR cloud is a set of FR-LSRs, which are mutually 122 interconnected by LC-FR interfaces. 124 Edge Set 126 The Edge Set of an FR-LSR cloud is the set of LSRs, which are 127 connected to the cloud by LC-FR interfaces. 129 Additionally, this document uses terminology from [ARCH]. 131 3. Special characteristics of Frame Relay Switches 133 While the label switching architecture permits considerable 134 flexibility in LSR implementation, a FR-LSR is constrained by the 135 capabilities of the (possibly pre-existing) hardware and the 136 restrictions on such matters as frame format imposed by the 137 Multiprotocol Interconnect over Frame Relay [MIFR], or Frame Relay 138 standards [FRF], etc.... Because of these constraints, some special 139 procedures are required for FR-LSRs. 141 Some of the key features of Frame Relay switches that affect their 142 behavior as LSRs are: 144 - the label swapping function is performed on fields (DLCI) in the 145 frame's Frame Relay data link header; this dictates the size and 146 placement of the label(s) in a packet. The size of the DLCI 147 field can be 10 (default), 17, or 23 bits, and it can span two, 148 or four bytes in the header. 150 - there is generally no capability to perform a `TTL-decrement' 151 function as is performed on IP headers in routers. 153 - congestion control is performed by each node based on parameters 154 that are passed at circuit creation. Flags in the frame headers 155 may be set as a consequence of congestion, or exceeding the 156 contractual parameters of the circuit. 158 - although in a standard switch it may be possible to configure 159 multiple input DLCIs to one output DLCI resulting in a 160 multipoint-to-point circuit, multipoint-to-multipoint VCs are 161 generally not fully supported. 163 This document describes ways of applying label switching to Frame 164 Relay switches, which work within these constraints. 166 4. Label Encapsulation 168 By default, all labeled packets should be transmitted with the 169 generic label encapsulation as defined in [STACK], using the frame 170 relay null encapsulation mechanism. The labels implicitly encode the 171 network protocol type, consequently those particular labels cannot be 172 used with other network protocols. Rules regarding the construction 173 of the label stack, and error messages returned to the frame source 174 are also described in [STACK]. 176 0 1 (Octets) 177 +-----------------------+-----------------------+ 178 (Octets)0 | | 179 / Q.922 Address / 180 / (length 'n' equals 2 or 4) / 181 | | 182 +-----------------------+-----------------------+ 183 n | . | 184 / . / 185 / MPLS packet / 186 | . | 187 +-----------------------+-----------------------+ 189 "n" is the length of the Q.922 Address which can be 2 or 4 190 octets. 192 The Q.922 [ITU] representation of a DLCI (in canonical order - 193 the first bit is stored in the least significant, i.e., the 194 right-most bit of a byte in memory) [CANON]is the following: 196 7 6 5 4 3 2 1 0 (bit order) 197 +-----+-----+-----+-----+-----+-----+-----+-----+ 198 (octet) 0 | DLCI(high order) | 0 | 0 | 199 +-----+-----+-----+-----+-----+-----+-----+-----+ 200 1 | DLCI(low order) | 0 | 0 | 0 | 1 | 201 +-----+-----+-----+-----+-----+-----+-----+-----+ 203 10 bits DLCI 204 7 6 5 4 3 2 1 0 (bit order) 205 +-----+-----+-----+-----+-----+-----+-----+-----+ 206 (octet) 0 | DLCI(high order) | 0 | 0 | 207 +-----+-----+-----+-----+-----+-----+-----+-----+ 208 1 | DLCI | 0 | 0 | 0 | 0 | 209 +-----+-----+-----+-----+-----+-----+-----+-----+ 210 2 | DLCI(low order) | 0 | 211 +-----+-----+-----+-----+-----+-----+-----+-----+ 212 3 | unused (set to 0) | 1 | 1 | 213 +-----+-----+-----+-----+-----+-----+-----+-----+ 215 17 bits DLCI 217 7 6 5 4 3 2 1 0 (bit order) 218 +-----+-----+-----+-----+-----+-----+-----+-----00 219 (octet) 0 | DLCI(high order) | 0 | 0 | 220 +-----+-----+-----+-----+-----+-----+-----+----- 221 1 | DLCI | 0 | 0 | 0 | 0 | 222 +-----+-----+-----+-----+-----+-----+-----+-----+ 223 2 | DLCI | 0 | 224 +-----+-----+-----+-----+-----+-----+-----+-----+ 225 3 | DLCI (low order) | 0 | 1 | 226 +-----+-----+-----+-----+-----+-----+-----+-----+ 228 23 bits DLCI 230 The generic encapsulation contains "n" labels for a label stack of depth 231 "n" [STACK], where the top stack entry carries significant values for 232 the EXP, S , and TTL fields [STACK] but not for the label, which is 233 rather carried in the DLCI field of the Frame Relay data link header 234 encoded in Q.922 [ITU] address format. 236 5. Frame Relay Label Switching Processing 238 5.1 Use of DLCIs 240 Label switching is accomplished by associating labels with routes and 241 using the label value to forward packets, including determining the 242 value of any replacement label. See [ARCH] for further details. In a 243 FR-LSR, the current (top) MPLS label is carried in the DLCI field of 244 the Frame Relay data link layer header of the frame. The top label 245 carries implicitly information about the network protocol type. 247 For two connected FR-LSRs, a full-duplex connection must be available 248 for LDP. The DLCI for the LDP VC is assigned a value by way of 249 configuration, similar to configuring the DLCI used to run IP routing 250 protocols between the switches. 252 With the exception of this configured value, the DLCI values used for 253 MPLS in the two directions of the link may be treated as belonging to 254 two independent spaces, i.e. VCs may be half-duplex, each direction 255 with its own DLCI. In case of DLCI aggregation (DLCI space 256 conservation), half-duplex (unidirectional) VCs are desired, since a 257 "many to few" aggregation is possible in one direction but not in 258 reverse. 260 The allowable ranges of DLCIs are always communicated through LDP. 261 Note that the range of DLCIs used for labels depends on the size of 262 the DLCI field. 264 5.2 Homogeneous LSPs 266 If is an LSP, it is possible that LSR1, LSR2, and 267 LSR3 will use the same encoding of the label stack when transmitting 268 packet P from LSR1, to LSR2, and then to LSR3. Such an LSP is 269 homogeneous. 271 5.3 Heterogeneous LSPs 273 If is an LSP, it is possible that LSR1 will use 274 one encoding of the label stack when transmitting packet P to LSR2, 275 but LSR2 will use a different encoding when transmitting a packet P 276 to LSR3. In general, the MPLS architecture supports LSPs with 277 different label stack encodings on different hops. When a labeled 278 packet is received, the LSR must decode it to determine the current 279 value of the label stack, then must operate on the label stack to 280 determine the new label value of the stack, and then encode the new 281 value appropriately before transmitting the labeled packet to its 282 next hop. 284 Naturally there will be MPLS networks which contain a combination of 285 Frame Relay switches operating as LSRs, and other LSRs, which operate 286 using other MPLS encapsulations, such as the MPLS shim header, or ATM 287 encapsulation. In such networks there may be some LSRs, which have 288 Frame Relay interfaces as well as "MPLS Shim" interfaces. This is one 289 example of an LSR with different label stack encodings on different 290 hops of the same LSP. Such an LSR may swap off a Frame Relay encoded 291 label on an incoming interface and replace it with a label encoded 292 into an MPLS shim header on the outgoing interface. 294 5.4 Frame Relay Label Switching Loop Prevention and Control 296 FR-LSRs MUST use a mechanism that insures loop free FR- LSPs or LSP 297 FR segments. Such mechanisms are described in [ARCH], and [LDP]. 299 5.4.1 FR-LSRs Loop Control - MPLS TTL processing 301 The MPLS TTL encoded in the MPLS label stack is a mechanism used to: 303 (a) suppress loops; 305 (b) limit the scope of a packet. 307 When a packet travels along an LSP, it should emerge with the same 308 TTL value that it would have had if it had traversed the same 309 sequence of routers without having been label switched. If the 310 packet travels along a hierarchy of LSPs, the total number of LSR- 311 hops traversed should be reflected in its TTL value when it emerges 312 from the hierarchy of LSPs [ARCH]. 314 The initial value of the MPLS TTL is loaded into a newly pushed label 315 stack entry from the previous TTL value, whether that is from the 316 network layer header when no previous label stack existed, or from a 317 pre-existent lower level label stack entry. 319 A FR-LSR switching same level labeled packets does not decrement the 320 MPLS TTL. A sequence of such FR-LSR is a "non-TTL segment". 322 When a packet emerges from a "non-TTL LSP segment", it should however 323 reflect in the TTL the number of LSR-hops it traversed. In the 324 unicast case, this can be achieved by propagating a meaningful LSP 325 length or LSP segment length to the FR-LSR ingress nodes, enabling 326 the ingress to decrement the TTL value before forwarding packets into 327 a non-TTL LSP segment [ARCH]. 329 When an ingress FR-LSR determines upon decrementing the MPLS TTL that 330 a particular packet's TTL will expire before the packet reaches the 331 egress of the "non-TTL LSP segment", the FR-LSR MUST not label switch 332 the packet, but rather follow the specifications in [STACK] in an 333 attempt to return an error message to the packet's source. 335 In the multicast case, a meaningful LSP length or LSP segment length 336 is propagated to the FR-LSR egress node, enabling the egress to 337 decrement the TTL value before forwarding packets out of the non-TTL 338 LSP segment. 340 5.4.2 Performing MPLS TTL calculations 342 Considering the "incoming TTL" the MPLS TTL of the top of the stack 343 when a labeled packet is received, and the "output TTL" the MPLS TTL 344 of the top of the stack when a packet leaves a node, the relationship 345 between the two is defined as a function of the type of the output 346 interface, and the type of transmit operation done on the output 347 interface (unicast or multicast): 349 output TTL = function (input TTL, output interface type, type of transmit)= 351 = input TTL - funct (output interface type, type of transmit) 353 Considering the symbol "I" for an IP interface, the symbol "G" for a 354 generic MPLS encapsulating interface, the symbol "A" for a MPLS ATM 355 encapsulating 356 interface, the symbol "F" for a MPLS FR encapsulating interface, and 357 "G_G", "F_G", etc... LSRs with specific input and output interfaces, 358 and also the symbols "O.TTL" and "I.TTL" for the "output" and "input" 359 TTL, the following describes the possible combinations: 361 input,output Unicast 363 ->G_G-> O.TTL = I.TTL - 1 365 ->F_G-> O.TTL = I.TTL - nr. of hops of starting segment (ingress F) 366 ->G_F-> O.TTL = I.TTL - 1 (egress F) 368 ->A_F-> O.TTL = I.TTL - nr. of hops of starting segment (ingress F) 369 ->F_A-> O.TTL = I.TTL - 1 (egress F) 371 ->F_F-> similar to ->A A-> no TTL processing 373 input,output Multicast 375 ->G_G-> O.TTL = I.TTL - 1 377 ->G_F-> O.TTL = I.TTL - 1 (ingress F) 378 ->F_G-> O.TTL = I.TTL - nr. of hops of ending segment (egress F) 380 ->A_F-> O.TTL = I.TTL - 1 (ingress F) 381 ->F_A-> O.TTL = I.TTL - nr. of hops of ending segment (egress F) 383 ->F_F-> similar to ->A A-> no TTL processing 384 Homogeneous LSP 386 --->I_F Frame Relay F_I---> 387 hops = 5 | | 388 F_F--->F_F--->F_F--->F_F 389 loop free 390 ip_ttl = n ip_ttl=n-6 391 mpls_ttl = n-5 n-5 393 Heterogeneous LSP 395 LSP LSP 396 ingress egress 398 LAN PPP FR ATM PPP FR LAN 400 --->I_G-->G_G-->G_F F_A A_G-->G_F F_G-->G_I---> 401 | / | | | | 402 hops 1 1 | 4 / | 3 | 1 | 3 | 1 1 403 F_F--F_F--F_F A_A--A_A F_F--F_F 405 loop free loop free loop free 406 ip_ttl 407 n n-15 408 mpls_ttl 409 n-1 n-2 n-6 n-9 n-10 n-13 n-14 411 Unicast -- TTL calculated at ingress 413 1 2 3 4 414 o-------o-------o-------o-------o 415 ttl=n-4 / 2 3 416 / 417 hops 1/ 418 / 419 o ttl=n-3 420 Multicast -- TTL calculated at egress 422 o ttl=n-3 423 hops / 424 3/ 425 / ttl=n-4 426 o-------o-------o-------o-------o 427 1 2 3 4 429 5.5 Label Processing by Ingress FR-LSRs 431 When a packet first enters an MPLS domain, the packet is forwarded by 432 normal network layer forwarding operations with the exception that 433 the outgoing encapsulation will include an MPLS label stack [STACK] 434 with at least one entry. The frame relay null encapsulation will 435 carry information about the network layer protocol implicitly in the 436 label, which MUST be associated only with that network protocol. The 437 TTL field in the top label stack entry is filled with the network 438 layer TTL (or hop limit) resulted after network layer forwarding 439 [STACK]. The further FR-LSR processing is similar in both possible 440 cases: 442 (a) the LSP is homogeneous -- Frame Relay only -- and the FR-LSR is 443 the ingress. 445 (b) the LSP is heterogeneous -- Frame Relay, PPP, Ethernet, ATM, 446 etc... segments form the LSP -- and the FR-LSR is the ingress into a 447 Frame Relay 448 segment. 450 For unicast packets, the MPLS TTL SHOULD be decremented with the 451 number of hops of the Frame Relay LSP (homogeneous), or Frame Relay 452 segment of the LSP (heterogeneous). An LDP constructing the LSP 453 SHOULD pass meaningful information to the ingress FR-LSR regarding 454 the number of hops of the "non-TTL segment". 456 For multicast packets, the MPLS TTL SHOULD be decremented by 1. An 457 LDP constructing the LSP SHOULD pass meaningful information to the 458 egress FR-LSR regarding the number of hops of the "non-TTL segment". 460 Next, the MPLS encapsulated packet is passed down to the Frame Relay 461 data link driver with the top label as output DLCI. The Frame Relay 462 frame carrying the MPLS encapsulated packet is forwarded onto the 463 Frame Relay VC to the next LSR. 465 5.6 Label Processing by Core FR-LSRs 467 In a FR-LSR, the current (top) MPLS label is carried in the DLCI 468 field of the Frame Relay data link layer header of the frame. Just as 469 in conventional Frame Relay, for a frame arriving at an interface, 470 the DLCI carried by the Frame Relay data link header is looked up in 471 the DLCI Information Base, replaced with the correspondent output 472 DLCI, and transmitted on the outgoing interface (forwarded to the 473 next hop node). 475 The current label information is also carried in the top of the label 476 stack. In the top-level entry, all fields except the label 477 information, which is carried and switched in the Frame Relay frame 478 data link-layer header, are of current significance. 480 5.7 Label Processing by Egress FR-LSRs 482 When reaching the end of a Frame Relay LSP, the FR-LSR pops the label 483 stack [ARCH]. If the label popped is the last label, it is necessary 484 to determine the particular network layer protocol which is being 485 carried. The label stack carries no explicit information to identify 486 the network layer protocol. This must be inferred from the value of 487 the label which is popped from the stack. 489 If the label popped is not the last label, the previous top level 490 MPLS TTL is propagated to the new top label stack entry. 492 If the FR-LSR is the egress switch of a Frame Relay segment of a 493 hybrid LSP, and the end of the Frame Relay segment is not the end of 494 the LSP, the MPLS packet will be processed for forwarding onto the 495 next segment of the LSP based on the information held in the Next Hop 496 Label Forwarding Entry (NHLFE) [ARCH]. The output label is set to the 497 value from the NHLFE, and the MPLS TTL is decremented by the 498 appropriate value depending the type of the output interface and the 499 type of transmit operation (see section 6.3). Further, the MPLS 500 packet is forwarded according to the MPLS specifications for the 501 particular link of the next segment of the LSP. 503 For unicast packets, the MPLS TTL SHOULD be decremented by one if the 504 output interface is a generic one, or with the number of hops of the 505 next ATM segment of the LSP (heterogeneous), if the output interface 506 is an ATM (non-TTL) interface. 508 For multicast packets, the MPLS TTL SHOULD be decremented by the 509 number of hops of the FR segment being exited. An LDP constructing 510 the LSP SHOULD pass meaningful information to the egress FR-LSR 511 regarding the number of hops of the FR "non-TTL segment". 513 6. Label Switching Control Component for Frame Relay 515 To support label switching a Frame Relay Switch MUST implement the 516 control component of label switching, which consists primarily of 517 label allocation and maintenance procedures. Label binding 518 information MAY be communicated by several mechanisms, one of which 519 is the Label Distribution Protocol (LDP) [LDP]. 521 Since the label switching control component uses information learned 522 directly from network layer routing protocols, this implies that the 523 switch MUST participate as a peer in these protocols (e.g., OSPF, 524 IS-IS). 526 In some cases, LSRs may use other protocols (e.g. RSVP, PIM, BGP) to 527 distribute label bindings. In these cases, a Frame Relay LSR should 528 participate in these protocols. 530 In the case where Frame Relay circuits are established via LDP, or 531 RSVP, or others, with no involvement from traditional Frame Relay 532 mechanisms, it is assumed that circuit establishing contractual 533 information such as input/output maximum frame size, 534 incoming/outgoing requested/agreed throughput, incoming/outgoing 535 acceptable throughput, incoming/outgoing burst size, 536 incoming/outgoing frame rate, used in transmitting, and congestion 537 control MAY be passed to the FR-LSRs through RSVP, or can be 538 statically configured. It is also assumed that congestion control and 539 frame header flagging as a consequence of congestion, would be done 540 by the FR-LSRs in a similar fashion as for traditional Frame Relay 541 circuits. With the goal of emulating a best-effort router as default, 542 the default VC parameters, in the absence of LDP, RSVP, or other 543 mechanisms participation to setting such parameters, should be zero 544 CIR, so that input policing will set the DE bit in incoming frames, 545 but no frames are dropped. 547 Control and state information for the circuits based on MPLS MAY be 548 communicated through LDP. 550 Support of label switching on a Frame Relay switch requires 551 conformance only to [FRF] (framing, bit-stuffing, headers, FCS) 552 except for section 2.3 (PVC control signaling procedures, aka LMI). 553 Q.933 signaling for PVCs and/or SVCs is not required. PVC and/or SVC 554 signaling may be used for non-MPLS (standard Frame Relay) PVCs and/or 555 SVCs when both are running on the same interface as MPLS, as 556 discussed in the next section. 558 6.1 Hybrid Switches (Ships in the Night) 560 The existence of the label switching control component on a Frame 561 Relay switch does not preclude the ability to support the Frame Relay 562 control component defined by the ITU and Frame Relay Forum on the 563 same switch and the same interfaces (NICs). The two control 564 components, label switching and those defined by ITU/Frame Relay 565 Forum, would operate independently. 567 Definition of how such a device operates is beyond the scope of this 568 document. However, only a small amount of information needs to be 569 consistent between the two control components, such as the portions 570 of the DLCI space which are available to each component. 572 7. Label Allocation and Maintenance Procedures 574 The mechanisms and message formats of a Label Distribution Protocol 575 are documented in [ARCH] and [LDP]. A possible scenario for the 576 label allocation and maintenance for FR-LSRs is "downstream-on- 577 demand" as it follows (note that this applies to hop-by-hop routed 578 traffic): 580 7.1 Edge LSR Behavior 582 Consider a member of the Edge Set of a FR-LSR cloud. Assume that, as 583 a result of its routing calculations, it selects a FR-LSR as the next 584 hop of a certain route (FEC), and that the next hop is reachable via 585 a LC-Frame Relay interface. Assume that the next-hop FR-LSR is an 586 "LDP-peer" [ARCH][LDP]. The Edge LSR sends an LDP "request" message 587 for a label binding from the next hop, downstream LSR. When the Edge 588 LSR receives in response from the downstream LSR the label binding 589 information in an LDP "mapping" message, the label is stored in the 590 Label Information Base (LIB) as an outgoing label for that FEC. The 591 "mapping" message may contain the "hop count" object, which 592 represents the number of hops a packet will take to cross the FR-LSR 593 cloud to the Egress FR-LSR when using this label. This information 594 may be stored for TTL calculation. Once this is done, the LSR may use 595 MPLS forwarding to transmit packets in that FEC. 597 When a member of the Edge Set of the FR-LSR cloud receives an LDP 598 "request" message from a FR-LSR for a FEC, it means it is the 599 Egress-FR-LSR. It allocates a label, creates a new entry in its Label 600 Information Base (LIB), places that label in the incoming label 601 component of the entry, and returns (via LDP) a "mapping" message 602 containing the allocated label back upstream to the LDP peer that 603 originated the request. The "mapping" message contains the "hop 604 count" object value set to 1. 606 When a routing calculation causes an Edge LSR to change the next hop 607 for a route, and the former next hop was in the FR-LSR cloud, the 608 Edge LSR should notify the former next hop (via an LDP "release" 609 message) that the label binding associated with the route is no 610 longer needed. 612 When a Frame Relay-LSR receives an LDP "request" message for a 613 certain route (FEC) from an LDP peer connected to the FR-LSR over a 614 LC-FR interface, the FR-LSR takes the following actions: 616 - it allocates a label, creates a new entry in its Label 617 Information Base (LIB), and places that label in the incoming 618 label component of the entry; 620 - it propagates the "request", by sending an LDP "request" 621 message to the next hop LSR, downstream for that route (FEC); 623 In the "ordered control" mode [ARCH], the FR-LSR will wait for its 624 "request" to be responded from downstream with a "mapping" message 625 before returning the "mapping" upstream in response to a "request" 626 ("ordered control" approach [ARCH]). In this case, the FR-LSR 627 increments the hop count it received from downstream and uses this 628 value in the "mapping" it returns upstream. 630 Alternatively, the FR-LSR may return the binding upstream without 631 waiting for a binding from downstream ("independent control" approach 632 [ARCH]). In this case, it uses a reserved value for hop count in the 633 "mapping", indicating that it is 'unknown'. The correct value for hop 634 count will be returned later, as described below. 636 Since both the "ordered" and "independent" control has advantages and 637 disadvantages, this is left as an implementation, or configuration 638 choice. 640 Once the FR-LSR receives in response the label binding in an LDP 641 "mapping" message from the next hop, it places the label into the 642 outgoing label component of the LIB entry. 644 Note that a FR-LSR, or a member of the edge set of a FR-LSR cloud, 645 may receive multiple binding requests for the same route (FEC) from 646 the same FR-LSR. It must generate a new "mapping" for each "request" 647 (assuming adequate resources to do so), and retain any existing 648 mapping(s). For each "request" received, a FR-LSR should also 649 generate a new binding "request" toward the next hop for the route 650 (FEC). 652 When a routing calculation causes a FR-LSR to change the next hop for 653 a route (FEC), the FR-LSR should notify the former next hop (via an 654 LDP "release" message) that the label binding associated with the 655 route is no longer needed. 657 When a LSR receives a notification that a particular label binding is 658 no longer needed, the LSR may deallocate the label associated with 659 the binding, and destroy the binding. This mode is the "conservative 660 label retention mode" [ARCH]. In the case where a FR-LSR receives 661 such notification and destroys the binding, it should notify the next 662 hop for the route that the label binding is no longer needed. If a 663 LSR does not destroy the binding (the FR-LSR is configured in 664 "liberal label retention mode" [ARCH]), it may re-use the binding 665 only if it receives a request for the same route with the same hop 666 count as the request that originally caused the binding to be 667 created. 669 When a route changes, the label bindings are re-established from the 670 point where the route diverges from the previous route. LSRs 671 upstream of that point are (with one exception, noted below) 672 oblivious to the change. Whenever a LSR changes its next hop for a 673 particular route, if the new next hop is a FR-LSR or a member of the 674 edge set reachable via a LC-FR interface, then for each entry in its 675 LIB associated with the route the LSR should request (via LDP) a 676 binding from the new next hop. 678 When a FR-LSR receives a label binding from a downstream neighbor, it 679 may already have provided a corresponding label binding for this 680 route to an upstream neighbor, either because it is using 681 "independent control" or because the new binding from downstream is 682 the result of a routing change. In this case, it should extract the 683 hop count from the new binding and increment it by one. If the new 684 hop count is different from that which was previously conveyed to the 685 upstream neighbor (including the case where the upstream neighbor was 686 given the value 'unknown') the FR-LSR must notify the upstream 687 neighbor of the change. Each FR-LSR in turn increments the hop count 688 and passes it upstream until it reaches the ingress Edge LSR. 690 Whenever a FR-LSR originates a label binding request to its next hop 691 LSR as a result of receiving a label binding request from another 692 (upstream) LSR, and the request to the next hop LSR is not satisfied, 693 the FR-LSR should destroy the binding created in response to the 694 received request, and notify the requester (via an LDP "withdraw" 695 message). 697 When an LSR determines that it has lost its LDP session with another 698 LSR, the following actions are taken: 700 - MUST discard any binding information learned via this 701 connection; 703 - For any label bindings that were created as a result of 704 receiving label binding requests from the peer, the LSR may 705 destroy these bindings (and deallocate labels associated 706 with these binding). 708 7.2 Efficient use of label space - Merging FR-LSRs 710 The above discussion assumes that an edge LSR will request one label 711 for each prefix in its routing table that has a next hop in the FR- 712 LSR cloud. In fact, it is possible to significantly reduce the number 713 of labels needed by having the edge LSR request instead one label for 714 several routes. Use of many-to-one mappings between routes (address 715 prefixes) and labels using the notion of Forwarding Equivalence 716 Classes (as described in [ARCH]) provides a mechanism to conserve the 717 number of labels. 719 Note that conserving label space may be restricted in case the frame 720 traffic requires Frame Relay fragmentation. The issue is that Frame 721 Relay fragments must be transmitted in sequence, i.e. fragments of 722 distinct frames must not be interleaved. If the fragmenting FR-LSR 723 ensures the transmission in sequence of all fragments of a frame, 724 without interleaving with fragments of other frames, then label 725 conservation (aggregation) can be performed. 727 In the case where the label space is to be conserved, it is desirable 728 to use half-duplex (unidirectional) VCs, since a "many to few" 729 aggregation is possible in one direction but not in reverse. 731 7.3 LDP messages specific to Frame Relay 733 The Label Distribution Protocol [LDP] messages exchanged between two 734 Frame Relay "LDP-peer" LSRs may contain Frame Relay specific 735 information such as: 737 "Frame Relay Label Range": 739 0 1 2 3 740 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Reserved |Len| Minimum DLCI | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Reserved | Maximum DLCI | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 with the following fields: 749 Reserved 750 This fields are reserved. They must be set to zero on transmission 751 and must be ignored on receipt. 753 Len 754 This field specifies the number of bits of the DLCI. The following 755 values are supported: 757 Len DLCI bits 759 0 10 760 1 17 761 2 23 763 Minimum DLCI 764 This 23 bit field is the binary value of the lower bound of a block 765 of Data Link Connection Identifiers (DLCIs) that is supported by 766 the originating FR-LSR. The Minimum DLCI should be right justified 767 in this field and the preceding bits should be set to 0. 769 Maximum DLCI 770 This 23 bit field is the binary value of the upper bound of a block 771 of Data Link Connection Identifiers (DLCIs) that is supported by 772 the originating FR-LSR. The Maximum DLCI should be right justified 773 in this field and the preceding bits should be set to 0. 775 and "Frame Relay Label": 777 0 1 2 3 778 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Reserved |Len| DLCI | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 with the following fields: 785 Reserved 786 This field is reserved. It must be set to zero on transmission and 787 must be ignored on receipt. 789 Len 790 This field specifies the number of bits of the DLCI. The following 791 values are supported: 793 Len DLCI bits 795 0 10 796 1 17 797 2 23 799 DLCI 800 The binary value of the Frame Relay Label. The significant number 801 of bits (10, 17, or 23) of the label value are to be encoded into 802 the Data Link Connection Identifier (DLCI) field when part of the 803 Frame Relay data link header (see Section 4.). 805 8. Security Considerations 807 This section looks at the security aspects of: 809 (a) frame traffic 811 (b) label distribution. 813 MPLS encapsulation has no effect on authenticated or encrypted 814 network layer packets, that is IP packets that are authenticated or 815 encrypted will incur no change. 817 The MPLS protocol has no mechanisms of its own to protect against 818 misdirection of packets or the impersonation of an LSR by accident or 819 malicious intent. 821 Altering by accident or forgery an existent label in the DLCI field 822 of the Frame Relay data link layer header of a frame or one or more 823 fields in a potentially following label stack affects the forwarding 824 of that frame. 826 The label distribution mechanism can be secured by applying the 827 appropriate level of security to the underlying protocol carrying 828 label information - authentication or encryption - see [LDP]. 830 9. Acknowledgments 832 The initial version of this document was derived from the Label 833 Switching over ATM document [ATM]. 835 Thanks for the extensive reviewing and constructive comments from (in 836 alphabetical order) Dan Harrington, Milan Merhar, Martin Mueller. 837 Also thanks to George Swallow for the suggestion to use null 838 encapsulation, and to Eric Gray for his reviewing. 840 Also thanks to Nancy Feldman and Bob Thomas for their collaboration 841 in including the LDP messages specific to Frame Relay LSRs 843 10. References 845 [MIFR] T. Bradley, C. Brown, A. Malis "Multiprotocol Interconnect 846 over Frame Relay" RFC 2427, September 1998. 848 [ARCH] E. Rosen, R. Callon, A. Vishwanathan, "Multi-Protocol Label 849 Switching Architecture", Work in Progress, July 1998. 851 [LDP] L. Anderson, P. Doolan, N. Feldman, A. Fredette, R. Thomas, 852 "Label Distribution Protocol", Work in Progress, August 1998. 854 [STACK] E. Rosen et al, "Label Switching: Label Stack Encodings", 855 Work in Progress, September 1998 857 [ATM] B. Davie et al. "Use of Label Switching with ATM", Work in 858 Progress, July 1998. 860 [ITU] International Telecommunications Union, "ISDN Data Link Layer 861 Specification for Frame Mode Bearer Services", ITU-T Recommendation 862 Q.922, 1992. 864 [FRF] Frame Relay Forum, User-to-Network Implementation Agreement 865 (UNI), FRF 1.1, January 19, 1996 866 11.Authors' Addresses 868 Alex Conta 869 Lucent Technologies Inc. 870 300 Baker Ave, Suite 100 871 Concord, MA 01742 872 +1-978-287-2842 873 E-mail: aconta@lucent.com 875 Paul Doolan 876 Ennovate Networks 877 330 Codman Hill Rd 878 Boxborough MA 01719 879 +1-978-263-2002 880 E-mail: pdoolan@ennovatenetworks.com 882 Andrew Malis 883 Ascend Communications, Inc 884 1 Robbins Rd 885 Westford, MA 01886 886 +1-978-952-7414 887 E-mail: malis@ascend.com