idnits 2.17.1 draft-ietf-mpls-fr-00.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-04-19) 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 18 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 254 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]), 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 292: '... FR-LSRs MUST use a mechanism that i...' RFC 2119 keyword, line 328: '...ent", the FR-LSR MUST not label switch...' RFC 2119 keyword, line 433: '... label, which MUST be associated on...' (12 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 26 has weird spacing: '... please check...' == (249 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 (December 1997) is 9622 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) == Missing Reference: 'FRAMEW' is mentioned on line 480, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'MIFR' -- 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' Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 7 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 December 1997 7 Use of Label Switching on Frame Relay Networks 9 Specification 11 draft-ietf-mpls-fr-00.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 not appropriate to use Internet- 23 Drafts as reference material or to cite them other than as a "working 24 draft" or "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Distribution of this memo is unlimited. 34 Abstract 36 This document defines the model and generic mechanisms for 37 Multiprotocol Label Switching on Frame Relay networks. A 38 Multiprotocol Label Switching Architecture is described in [ARCH]. 39 MPLS enables the use of Frame Relay Switches as Label Switching 40 Routers (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 Swithcing Processing......................6 51 5.1 Use of DLCIs..............................................6 52 5.2 Homogenous LSPs...........................................7 53 5.3 Heterogenous 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 8 Security Considerations ..................................17 66 9 Acknowledgments ..........................................18 67 10 References ...............................................18 68 11 Authors' Addresses .......................................18 69 1. Introduction 71 A Multiprotocol Label Switching Architecture is described in [ARCH]. 72 The framework for Multiprotocol Label Switching protocols is 73 described in [FRAMEW]. It is possible to use Frame Relay switches as 74 Label Switching Routers. Such Frame Relay switches run network layer 75 routing algorithms (such as OSPF, IS-IS, etc.), and their forwarding 76 is based on the results of these routing algorithms. No specific 77 Frame Relay 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 114 A FR-LSR is an LSR with one or more LC-FR interfaces which 115 forwards frames onto these interfaces using labels carried in 116 the DLCI field. 118 FR-LSR cloud 120 A FR-LSR cloud is a set of FR-LSRs which are mutually 121 interconnected by LC-FR interfaces. 123 Edge Set 125 The Edge Set of an FR-LSR cloud is the set of LSRs which are 126 connected to the cloud by LC-FR interfaces. 128 3. Special characteristics of Frame Relay Switches 130 While the label switching architecture permits considerable 131 flexibility in LSR implementation, a FR-LSR is constrained by the 132 capabilities of the (possibly pre-existing) hardware and the 133 restrictions on such matters as frame format imposed by the 134 Multiprotocol Interconnect over Frame Relay [MIFR], or Frame Relay 135 standards (Q.922, etc). Because of these constraints, some special 136 procedures are required for FR-LSRs. 138 Some of the key features of Frame Relay switches that affects their 139 behavior as LSRs are: 141 - the label swapping function is performed on fields (DLCI) in the 142 frame's Frame Relay data link header; this dictates the size and 143 placement of the label(s) in a packet. The size of the DLCI 144 field can be 10 (default), 17, or 23 bits, and it can span two, 145 or four bytes in the header. 147 - there is generally no capability to perform a `TTL-decrement' 148 function as is performed on IP headers in routers. 150 - congestion control is performed by each node based on parameters 151 that are passed at circuit creation. Flags in the frame headers 152 may be set as a consequence of congestion, or exceeding the 153 contractual parameters of the circuit. 155 - although in a standard switch it may be possible to configure 156 multiple input DLCIs to one output DLCI resulting in a 157 multipoint-to-point circuit, multipoint-to-multipoint VCs are 158 generally not fully supported. 160 This document describes ways of applying label switching to Frame 161 Relay switches which work within these constraints. 163 4. Label Encapsulation 165 By default, all labeled packets should be transmitted with the 166 generic label encapsulation as defined in [STACK], using the frame 167 relay null encapsulation mechanism. The labels implicitly encode the 168 network protocol type, consequently those particular labels cannot be 169 used with other network protocols. Rules regarding the construction 170 of the label stack, and error messages returned to the frame source 171 are also described in [STACK]. 173 0 1 (Octets) 174 +-----------------------+-----------------------+ 175 (Octets)0 | | 176 / Q.922 Address / 177 / (length 'n' equals 2 or 4) / 178 | | 179 +-----------------------+-----------------------+ 180 n | . | 181 / . / 182 / MPLS packet / 183 | . | 184 +-----------------------+-----------------------+ 186 "n" is the length of the Q.922 Address which can be 2 or 4 187 octets. 189 The Q.922 representation of a DLCI (in canonical order - the 190 first bit is stored in the least significant, i.e., the right- 191 most bit of a byte in memory) [CANON]is the following: 193 7 6 5 4 3 2 1 0 (bit order) 194 +-----+-----+-----+-----+-----+-----+-----+-----+ 195 (octet) 0 | DLCI(high order) | 0 | 0 | 196 +-----+-----+-----+-----+-----+-----+-----+-----+ 197 1 | DLCI(low order) | 0 | 0 | 0 | 1 | 198 +-----+-----+-----+-----+-----+-----+-----+-----+ 200 10 bits DLCI 201 7 6 5 4 3 2 1 0 (bit order) 202 +-----+-----+-----+-----+-----+-----+-----+-----+ 203 (octet) 0 | DLCI(high order) | 0 | 0 | 204 +-----+-----+-----+-----+-----+-----+-----+-----+ 205 1 | DLCI | 0 | 0 | 0 | 0 | 206 +-----+-----+-----+-----+-----+-----+-----+-----+ 207 2 | DLCI(low order) | 0 | 208 +-----+-----+-----+-----+-----+-----+-----+-----+ 209 3 | unused (set to 0) | 1 | 1 | 210 +-----+-----+-----+-----+-----+-----+-----+-----+ 212 17 bits DLCI 214 7 6 5 4 3 2 1 0 (bit order) 215 +-----+-----+-----+-----+-----+-----+-----+-----00 216 (octet) 0 | DLCI(high order) | 0 | 0 | 217 +-----+-----+-----+-----+-----+-----+-----+----- 218 1 | DLCI | 0 | 0 | 0 | 0 | 219 +-----+-----+-----+-----+-----+-----+-----+-----+ 220 2 | DLCI | 0 | 221 +-----+-----+-----+-----+-----+-----+-----+-----+ 222 3 | DLCI (low order) | 0 | 1 | 223 +-----+-----+-----+-----+-----+-----+-----+-----+ 225 23 bits DLCI 227 The generic encapsulation contains "n" labels for a label stack of depth 228 "n", where the top stack entry carries significant values with the 229 exception of the label which is carried in the DLCI field of the Frame 230 Relay data link header encoded in Q.922 address format. 232 5. Frame Relay Label Switching Processing 234 5.1 Use of DLCIs 236 Label switching is accomplished by associating labels with routes and 237 using the label value to forward packets, including determining the 238 value of any replacement label. See [ARCH] for further details. In a 239 FR-LSR, the current (top) MPLS label is carried in the DLCI field of 240 the Frame Relay data link layer header of the frame. The top label 241 carries implicitly information about the network protocol type. 243 For two connected FR-LSRs, a full-duplex connection must be available 244 for LDP. The DLCI for the LDP VC is assigned a value by way of 245 configuration, similar to configuring the DLCI used to run IP routing 246 protocols between the switches. 248 With the exception of this configured value, the DLCI values used for 249 MPLS in the two directions of the link may be treated as belonging to 250 two independent spaces, i.e. VCs may be half-duplex, each direction 251 with its own DLCI. In case of DLCI aggregation (DLCI space 252 conservation), half-duplex (unidirectional) VCs are desired, since a 253 "many to few" aggregation is possible in one direction but not in 254 reverse. 256 The allowable ranges of DLCIs are always communicated through LDP. 257 Note that the range of DLCIs used for labels depends on the size of 258 the DLCI field. 260 5.2 Homogenous LSPs 262 If is an LSP, it is possible that LSR1, LSR2, and 263 LSR3 will use the same encoding of the label stack when transmitting 264 packet P from LSR1, to LSR2, and then to LSR3. Such an LSP is 265 homogenous. 267 5.3 Heterogenous LSPs 269 If is an LSP, it is possible that LSR1 will use 270 one encoding of the label stack when transmitting packet P to LSR2, 271 but LSR2 will use a different encoding when transmitting a packet P 272 to LSR3. In general, the MPLS architecture supports LSPs with 273 different label stack encodings on different hops. When a labeled 274 packet is received, the LSR must decode it to determine the current 275 value of the label stack, then must operate on the label stack to 276 determine the new label value of the stack, and then encode the new 277 value appropriately before transmitting the labeled packet to its 278 next hop. 280 Naturally there will be MPLS networks which contain a combination of 281 Frame Relay switches operating as LSRs, and other LSRs which operate 282 using other MPLS encapsulations, such as the MPLS shim header, or ATM 283 encapsulation. In such networks there may be some LSRs which have 284 Frame Relay interfaces as well as "MPLS Shim" interfaces. This is one 285 example of an LSR with different label stack encodings on different 286 hops of the same LSP. Such an LSR may swap off a Frame Relay encoded 287 label on an incoming interface and replace it with a label encoded 288 into an MPLS shim header on the outgoing interface. 290 5.4 Frame Relay Label Switching Loop Prevention and Control 292 FR-LSRs MUST use a mechanism that insures loop free FR- LSPs or LSP 293 FR segments. One such mechanism is the diffusion computation for loop 294 prevention [ARCH]. 296 5.4.1 FR-LSRs Loop Control - MPLS TTL processing 298 The MPLS TTL encoded in the MPLS label stack is a mechanism used to: 300 (a) suppress loops; 302 (b) limit the scope of a packet. 304 When a packet travels along an LSP, it should emerge with the same 305 TTL value that it would have had if it had traversed the same 306 sequence of routers without having been label switched. If the 307 packet travels along a hierarchy of LSPs, the total number of LSR- 308 hops traversed should be reflected in its TTL value when it emerges 309 from the hierarchy of LSPs [ARCH]. 311 The initial value of the MPLS TTL is loaded into a newly pushed label 312 stack entry from the previous TTL value, whether that is from the 313 network layer header when no previous label stack existed, or from a 314 pre-existent lower level label stack entry. 316 A FR-LSR switching same level labeled packets does not decrement the 317 MPLS TTL. A sequence of such FR-LSR is a "non-TTL segment". 319 When a packet emerges from a "non-TTL LSP segment", it should however 320 reflect in the TTL the number of LSR-hops it traversed. In the 321 unicast case, this can be achieved by propagating a meaningful LSP 322 length or LSP segment length to the FR-LSR ingress nodes, enabling 323 the ingress to decrement the TTL value before forwarding packets into 324 a non-TTL LSP segment [ARCH]. 326 When an ingress FR-LSR determines upon decrementing the MPLS TTL that 327 a particular packet's TTL will expire before the packet reaches the 328 egress of the "non-TTL LSP segment", the FR-LSR MUST not label switch 329 the packet, but rather follow the specifications in [STACK] in an 330 attempt to return an error message to the packet's source. 332 In the multicast case, a meaningful LSP length or LSP segment length 333 is propagated to the FR-LSR egress node, enabling the egress to 334 decrement the TTL value before forwarding packets out of the non-TTL 335 LSP segment. 337 5.4.2 Performing MPLS TTL calculations 339 Considering the "incoming TTL" the MPLS TTL of the top of the stack 340 when a labeled packet is received, and the "output TTL" the MPLS TTL 341 of the top of the stack when a packet leaves a node, the relationship 342 between the two is defined as a function of the type of the output 343 interface, and the type of transmit operation done on the output 344 interface (unicast or multicast): 346 output TTL = function (input TTL, output interface type, type of transmit)= 348 = input TTL - funct (output interface type, type of transmit) 350 Considering the symbol"I" for an IP interface, the symbol "G" for a 351 generic MPLS ncapsulating interface, the symbol "A" for a MPLS ATM 352 encapsulating 353 interface, the symbol "F" for a MPLS FR encapsulating interface, and 354 "G_G", "F_G", etc... LSRs with specific input and output interfaces, 355 and also the symbols "O.TTL" and "I.TTL" for the "output" and "input" 356 TTL, the following describes the possible combinations: 358 input,output Unicast 360 ->G_G-> O.TTL = I.TTL - 1 362 ->F_G-> O.TTL = I.TTL - nr. of hops of starting segment (ingress F) 363 ->G_F-> O.TTL = I.TTL - 1 (egress F) 365 ->A_F-> O.TTL = I.TTL - nr. of hops of starting segment (ingress F) 366 ->F_A-> O.TTL = I.TTL - 1 (egress F) 368 ->F_F-> similar to ->A A-> no TTL processing 370 input,output Multicast 372 ->G_G-> O.TTL = I.TTL - 1 374 ->G_F-> O.TTL = I.TTL - 1 (ingress F) 375 ->F_G-> O.TTL = I.TTL - nr. of hops of ending segment (egress F) 377 ->A_F-> O.TTL = I.TTL - 1 (ingress F) 378 ->F_A-> O.TTL = I.TTL - nr. of hops of ending segment (egress F) 380 ->F_F-> similar to ->A A-> no TTL processing 381 Homogenous LSP 383 --->I_F Frame Relay F_I---> 384 hops = 5 | | 385 F_F--->F_F--->F_F--->F_F 386 loop free 387 ip_ttl = n ip_ttl=n-6 388 mpls_ttl = n-5 n-5 390 Heterogenous LSP 392 LSP LSP 393 ingress egress 395 LAN PPP FR ATM PPP FR LAN 397 --->I_G-->G_G-->G_F F_A A_G-->G_F F_G-->G_I---> 398 | / | | | | 399 hops 1 1 | 4 / | 3 | 1 | 3 | 1 1 400 F_F--F_F--F_F A_A--A_A F_F--F_F 402 loop free loop free loop free 403 ip_ttl 404 n n-15 405 mpls_ttl 406 n-1 n-2 n-6 n-9 n-10 n-13 n-14 408 Unicast -- TTL calculated at ingress 410 1 2 3 4 411 o-------o-------o-------o-------o 412 ttl=n-4 / 2 3 413 / 414 hops 1/ 415 / 416 o ttl=n-3 417 Multicast -- TTL calculated at egress 419 o ttl=n-3 420 hops / 421 3/ 422 / ttl=n-4 423 o-------o-------o-------o-------o 424 1 2 3 4 426 5.5 Label Processing by Ingress FR-LSRs 428 When a packet first enters an MPLS domain, the packet is forwarded by 429 normal network layer forwarding operations with the exception that 430 the outgoing encapsulation will include an MPLS label stack [STACK] 431 with at least one entry. The frame relay null encapsulation will 432 carry information about the network layer protocol implicitly in the 433 label, which MUST be associated only with that network protocol. The 434 TTL field in the top label stack entry is filled with the network 435 layer TTL (or hop limit) resulted after network layer forwarding 436 [STACK]. The further FR-LSR processing is similar in both possible 437 cases: 439 (a) the LSP is homogenous -- Frame Relay only -- and the FR-LSR is 440 the ingress. 442 (b) the LSP is heterogeneous -- Frame Relay, PPP, Ethernet, ATM, 443 etc... segments form the LSP -- and the FR-LSR is the ingress into a 444 Frame Relay 445 segment. 447 For unicast packets, the MPLS TTL SHOULD be decremented with the 448 number of hops of the Frame Relay LSP (homogenous), or Frame Relay 449 segment of the LSP (heterogeneous). An LDP constructing the LSP 450 SHOULD pass meaningful information to the ingress FR-LSR regarding 451 the number of hops of the "non-TTL segment". 453 For multicast packets, the MPLS TTL SHOULD be decremented by 1. An 454 LDP constructing the LSP SHOULD pass meaningful information to the 455 egress FR-LSR regarding the number of hops of the "non-TTL segment". 457 Next, the MPLS encapsulated packet is passed down to the Frame Relay 458 data link driver with the top label as output DLCI. The Frame Relay 459 frame carrying the MPLS encapsulated packet is forwarded onto the 460 Frame Relay VC to the next LSR. 462 5.6 Label Processing by Core FR-LSRs 464 In a FR-LSR, the current (top) MPLS label is carried in the DLCI 465 field of the Frame Relay data link layer header of the frame. Just as 466 in conventional Frame Relay, for a frame arriving at an interface, 467 the DLCI carried by the Frame Relay data link header is looked up in 468 the DLCI Information Base, replaced with the correspondent output 469 DLCI, and transmitted on the outgoing interface (forwarded to the 470 next hop node). 472 The current label information is also carried in the top of the label 473 stack. In the top level entry, all fields except the label 474 information, which is carried and switched in the Frame Relay frame 475 data link-layer header, are of current significance. 477 5.7 Label Processing by Egress FR-LSRs 479 When reaching the end of a Frame Relay LSP, the FR-LSR pops the label 480 stack [FRAMEW],[ARCH]. If the label popped is the last label, it is 481 necessary to determine the particular network layer protocol which is 482 being carried. The label stack carries no explicit information to 483 identify the network layer protocol. This must be inferred from the 484 value of the label which is popped from the stack. 486 If the label popped is not the last label, the previous top level 487 MPLS TTL is propagated to the new top label stack entry. 489 If the FR-LSR is the egress switch of a Frame Relay segment of a 490 hybrid LSP, and the end of the Frame Relay segment is not the end of 491 the LSP, the MPLS packet will be processed for forwarding onto the 492 next segment of the LSP based on the information held in the Next Hop 493 Label Forwarding Entry (NHLFE) [ARCH]. The output label is set to the 494 value from the NHLFE, and the MPLS TTL is decremented by the 495 appropriate value depending the type of the output interface and the 496 type of transmit operation (see secion 6.3). Further, the MPLS packet 497 is forwarded according to the MPLS specifications for the particular 498 link of the next segment of the LSP. 500 For unicast packets, the MPLS TTL SHOULD be decremented by one if the 501 output interface is a generic one, or with the number of hops of the 502 next ATM segment of the LSP (heterogeneous), if the output interface 503 is an ATM (non-TTL) interface. 505 For multicast packets, the MPLS TTL SHOULD be decremented by the 506 number of hops of the FR segment being exited. An LDP constructing 507 the LSP SHOULD pass meaningful information to the egress FR-LSR 508 regarding the number of hops of the FR "non-TTL segment". 510 6. Label Switching Control Component for Frame Relay 512 To support label switching a Frame Relay Switch MUST implement the 513 control component of label switching. This consists primarily of 514 label allocation and maintenance procedures. Label binding 515 information MAY be communicated by several mechanisms, one of which 516 is the Label Distribution Protocol (LDP) [LDP]. 518 Since the label switching control component uses information learned 519 directly from network layer routing protocols, this implies that the 520 switch MUST participate as a peer in these protocols (e.g., OSPF, 521 IS-IS). 523 In some cases, LSRs may use other protocols (e.g. RSVP, PIM, BGP) to 524 distribute label bindings. In these cases, a Frame Relay LSR should 525 participate in these protocols. 527 In the case where Frame Relay circuits are established via LDP, or 528 RSVP, or others, with no involvement from traditional Frame Relay 529 mechanisms, it is assumed that circuit establishing contractual 530 information such as input/output maximum frame size, 531 incoming/outgoing requested/agreed throughput, incoming/outgoing 532 acceptable throughput, incoming/outgoing burst size, 533 incoming/outgoing frame rate, used in transmitting, and congestion 534 control MAY be passed to the FR-LSRs through RSVP, or can be 535 statically configured. It is also assumed that congestion control and 536 frame header flagging as a consequence of congestion, would be done 537 by the FR-LSRs in a similar fashion as for traditional Frame Relay 538 circuits. With the goal of emulating a best-effort router as default, 539 the default VC parameters, in the absence of LDP, RSVP, or other 540 mechanisms participation to setting such parameters, should be zero 541 CIR, so that input policing will set the DE bit in incoming frames, 542 but no frames are dropped.. 544 Control and state information for the circuits based on MPLS MAY be 545 communicated through LDP. 547 Support of label switching on a Frame Relay switch requires 548 conformance only to FRF 1.1 (framing, bit-stuffing, headers, FCS) 549 except for section 2.3 (PVC control signaling procedures, aka LMI). 550 Q.933 signaling for PVCs and/or SVCs is not required. PVC and/or SVC 551 signaling may be used for non-MPLS (standard Frame Relay) PVCs and/or 552 SVCs when both are running on the same interface as MPLS, as 553 discussed in the next section. 555 6.1 Hybrid Switches (Ships in the Night) 557 The existence of the label switching control component on a Frame 558 Relay switch does not preclude the ability to support the Frame Relay 559 control component defined by the ITU and Frame Relay Forum on the 560 same switch and the same interfaces (NICs). The two control 561 components, label switching and those defined by ITU/Frame Relay 562 Forum, would operate independently. 564 Definition of how such a device operates is beyond the scope of this 565 document. However, only a small amount of information needs to be 566 consistent between the two control components, such as the portions 567 of the DLCI space which are available to each component. 569 7. Label Allocation and Maintenance Procedures 571 A possible scenario for the label allocation and maintenance for FR- 572 LSRs is the following: 574 7.1 Edge LSR Behavior 576 Consider a member of the Edge Set of a FR-LSR cloud. Assume that, as 577 a result of its routing calculations, it selects a FR-LSR as the next 578 hop of a certain route, and that the next hop is reachable via a LC- 579 Frame Relay interface. The Edge LSR uses a specific LDP request for a 580 label binding from the next hop. The hop count field in the request 581 is set to 1. Once the Edge LSR receives the label binding 582 information, the label is used as an outgoing label. The binding 583 received by the edge LSR may contain a hop count, which represents 584 the number of hops a packet will take to cross the FR-LSR cloud when 585 using this label. 587 When a member of the Edge Set of the FR-LSR cloud receives a label 588 binding request from a FR-LSR, it allocates a label, creates a new 589 entry in its Label Information Base (LIB), places that label in the 590 incoming label component of the entry, and returns (via LDP) a 591 binding containing the allocated label back to the peer that 592 originated the request. It sets the hop count in the binding to 1. 594 When a routing calculation causes an Edge LSR to change the next hop 595 for a route, and the former next hop was in the FR-LSR cloud, the 596 Edge LSR should notify the former next hop (via LDP) that the label 597 binding associated with the route is no longer needed. 599 When a Frame Relay-LSR receives (via LDP) a label binding request for 600 a certain route from a peer connected to the FR-LSR over a LC-FR 601 interface, the FR-LSR takes the following actions: 603 - it allocates a label, creates a new entry in its Label 604 Information Base (LIB), and places that label in the incoming 605 label component of the entry; 607 - it requests (via LDP) a label binding from the next hop for 608 that route; 610 - it returns (via LDP) a binding containing the allocated 611 incoming label back to the peer that originated the request. 613 The hop count field in the request that the FR-LSR sends (to the next 614 hop LSR) is set to the hop count field in the request that it 615 received from the upstream LSR plus one. Once the FR-LSR receives 616 the binding from the next hop, it places the label from the binding 617 into the outgoing label component of the LIB entry. 619 The FR-LSR may choose to wait for the request to be satisfied from 620 downstream before returning the binding upstream (a "conservative" 621 approach). In this case, the FR-LSR increments the hop count it 622 received from downstream and uses this value in the binding it 623 returns upstream. 625 Alternatively, the FR-LSR may return the binding upstream without 626 waiting for a binding from downstream (an "optimistic" approach). In 627 this case, it uses a reserved value for hop count in the binding, 628 indicating that it is unknown. The correct value for hop count will 629 be returned later, as described below. 631 Since both the conservative and the optimistic approach has 632 advantages and disadvantages, this is left as an implementation 633 choice. 635 Note that a FR-LSR, or a member of the edge set of a FR-LSR cloud, 636 may receive multiple binding requests for the same route from the 637 same FR-LSR. It must generate a new binding for each request 638 (assuming adequate resources to do so), and retain any existing 639 binding(s). For each request received, a FR-LSR should also generate 640 a new binding request toward the next hop for the route. 642 When a routing calculation causes a FR-LSR to change the next hop for 643 a route, the FR-LSR should notify the former next hop (via LDP) that 644 the label binding associated with the route is no longer needed. 646 When a LSR receives a notification that a particular label binding is 647 no longer needed, the LSR may deallocate the label associated with 648 the binding, and destroy the binding. In the case where a FR-LSR 649 receives such notification and destroys the binding, it should notify 650 the next hop for the route that the label binding is no longer 651 needed. If a LSR does not destroy the binding, it may re-use the 652 binding only if it receives a request for the same route with the 653 same hop count as the request that originally caused the binding to 654 be created. 656 When a route changes, the label bindings are re-established from the 657 point where the route diverges from the previous route. LSRs 658 upstream of that point are (with one exception, noted below) 659 oblivious to the change. Whenever a LSR changes its next hop for a 660 particular route, if the new next hop is a FR-LSR or a member of the 661 edge set reachable via a LC-FR interface, then for each entry in its 662 LIB associated with the route the LSR should request (via LDP) a 663 binding from the new next hop. 665 When a FR-LSR receives a label binding from a downstream neighbor, it 666 may already have provided a corresponding label binding for this 667 route to an upstream neighbor, either because it is operating 668 optimistically or because the new binding from downstream is the 669 result of a routing change. In this case, it should extract the hop 670 count from the new binding and increment it by one. If the new hop 671 count is different from that which was previously conveyed to the 672 upstream neighbor (including the case where the upstream neighbor was 673 given the value `unknown') the FR-LSR must notify the upstream 674 neighbor of the change. Each FR-LSR in turn increments the hop count 675 and passes it upstream until it reaches the ingress Edge LSR. 677 Whenever a FR-LSR originates a label binding request to its next hop 678 LSR as a result of receiving a label binding request from another 679 (upstream) LSR, and the request to the next hop LSR is not satisfied, 680 the FR-LSR should destroy the binding created in response to the 681 received request, and notify the requester (via LDP). 683 When a LSR determines that it has lost its LDP session with another 684 LSR, the following actions are taken. Any binding information 685 learned via this connection must be discarded. For any label 686 bindings that were created as a result of receiving label binding 687 requests from the peer, the LSR may destroy these bindings (and 688 deallocate labels associated with these binding). 690 7.2 Efficient use of label space - Merging FR-LSRs 692 The above discussion assumes that an edge LSR will request one label 693 for each prefix in its routing table that has a next hop in the FR- 694 LSR cloud. In fact, it is possible to significantly reduce the number 695 of labels needed by having the edge LSR request instead one label for 696 several routes. Use of many-to-one mappings between routes (address 697 prefixes) and labels using the notion of Forwarding Equivalence 698 Classes (as described in [ARCH]) provides a mechanism to conserve the 699 number of labels. 701 Note that conserving label space may be restricted in case the frame 702 traffic requires Frame Relay fragmentation. The issue is that Frame 703 Relay fragments must be transmitted in sequence, i.e. fragments of 704 distinct frames must not be interleaved. If the fragmenting FR-LSR 705 ensures the transmission in sequence of all fragments of a frame, 706 without interleaving with fragments of other frames, then label 707 conservation (aggregation) can be performed. 709 In the case where the label space is to be conserved, it is desirable 710 to use half-duplex (unidirectional) VCs, since a "many to few" 711 aggregation is possible in one direction but not in reverse. 713 8. Security Considerations 715 This section looks at the security aspects of: 717 (a) frame traffic 719 (b) label distribution. 721 MPLS encapsulation has no effect on authenticated or encrypted 722 network layer packets, that is IP packets that are authenticated or 723 encrypted will incur no change. 725 The MPLS protocol has no mechanisms of its own to protect against 726 misdirection of packets or the impersonation of an LSR by accident or 727 malicious intent. 729 Altering by accident or forgery an existent label in the DLCI field 730 of the Frame Relay data link layer header of a frame or one or more 731 fields in a potentially following label stack affects the forwarding 732 of that frame. 734 The label distribution mechanism can be secured by applying the 735 appropriate level of security to the underlying protocol carrying 736 label information - authentication or encryption - see [LDP]. 738 9. Acknowledgments 740 The initial version of this document was derived from the Label 741 Switching over ATM document [ATM]. 743 Thanks for the extensive reviewing and constructive comments from (in 744 alphabetical order) Dan Harrington, Milan Merhar, Martin Mueller. 745 Also thanks to George Swallow for the suggestion to use null 746 encapsulation, and to Eric Gray for his reviewing. 748 10. References 750 [MIFR] T. Bradley, C. Brown, A. Malis "Multiprotocol Interconnect 751 over Frame Relay" 753 [FRAMEW]"A Framework for Multiprotocol Label Switching" R.Callon et 754 al. 756 [ARCH] "Proposed Architecture for MPLS" in "draft-rosen-mpls-00.txt" 757 by E. Rosen, R. Callon, R. Vishwanathan. 759 [LDP] Label Distribution Protocol - work in progress. 761 [STACK] "Label Switching: Label Stack Encodings" "draft-mpls-label- 762 encaps-00.txt" by Rosen et al. 764 [ATM] "draft-davie-mpls-atm-00.txt" by Davie et al. 766 10.Authors' Addresses 768 Alex Conta 769 Lucent Technologies Inc. 770 300 Baker Ave, Suite 100 771 Concord, MA 01742 772 +1-508-287-2842 773 E-mail: aconta@lucent.com 774 Paul Doolan 775 Ennovate Networks 776 330 Codman Hill Rd 777 Boxborough MA 01719 778 +1-978-263-2002 779 E-mail: pdoolan@ennovatenetworks.com 781 Andrew Malis 782 Ascend Communications, Inc 783 1 Robbins Rd 784 Westford, MA 01886 785 +1-978-952-7414 786 E-mail: malis@ascend.com