idnits 2.17.1 draft-ietf-mpls-fr-03.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-26) 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 24 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 313 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 28 instances of too long lines in the document, the longest one being 1 character 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 95: '... The keywords MUST, MUST NOT, MAY, O...' RFC 2119 keyword, line 96: '... SHALL, SHALL NOT, SHOULD, SHOUL...' RFC 2119 keyword, line 296: '... VC merging MUST be communicated t...' RFC 2119 keyword, line 332: '... FR-LSRs SHOULD operate on loop fr...' RFC 2119 keyword, line 333: '...efore, FR-LSRs SHOULD use loop detec...' (22 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...' == (308 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 (16 November 1998) is 9293 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 16 November 1998 7 Use of Label Switching on Frame Relay Networks 9 Specification 11 draft-ietf-mpls-fr-03.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 (LDP) described in [LDP] relative to Frame Relay Networks. 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.............5 49 4. Label Encapsulation.........................................5 50 5. Frame Relay Label Switching Processing......................7 51 5.1 Use of DLCIs..............................................7 52 5.2 Homogeneous LSPs..........................................8 53 5.3 Heterogeneous LSPs........................................8 54 5.4 Frame Relay Label Switching Loop Prevention and Control...8 55 5.4.1 FR-LSRs Loop Control - MPLS TTL Processing.............9 56 5.4.2 Performing MPLS TTL calculations......................10 57 5.5 Label Processing by Ingress FR-LSRs......................13 58 5.6 Label Processing by Core FR-LSRs.........................14 59 5.7 Label Processing by Egress FR-LSRs.......................14 60 6 Label Switching Control Component for Frame Relay..........15 61 6.1 Hybrid Switches (Ships in the Night) ...................16 62 7 Label Allocation and Maintenance Procedures ...............16 63 7.1 Edge LSR Behavior........................................16 64 7.2 Efficient use of label space-Merging FR-LSRs.............19 65 7.3 LDP message fields specific to Frame Relay...............20 66 8 Security Considerations ..................................22 67 9 Acknowledgments ..........................................23 68 10 References ...............................................23 69 11 Authors' Addresses .......................................24 70 Appendix A - changes since previous versions..................25 71 1. Introduction 73 The Multiprotocol Label Switching Architecture is described in 74 [ARCH]. It is possible to use Frame Relay switches as Label Switching 75 Routers. Such Frame Relay switches run network layer routing 76 algorithms (such as OSPF, IS-IS, etc.), and their forwarding is based 77 on the results of these routing algorithms. No specific Frame Relay 78 routing is needed. 80 When a Frame Relay switch is used for label switching, the top 81 (current) label, on which forwarding decisions are based, is carried 82 in the DLCI field of the Frame Relay data link layer header of a 83 frame. Additional information carried along with the top (current) 84 label, but not processed by Frame Relay switching, along with other 85 labels, if the packet is multiply labeled, are carried in the generic 86 MPLS encapsulation defined in [STACK]. 88 Frame Relay permanent virtual circuits (PVCs) could be configured to 89 carry label switching based traffic. The DLCIs would be used as MPLS 90 Labels and the Frame Relay switches would become Frame Relay Label 91 Switching Routers, while the MPLS traffic would be encapsulated 92 according to this specification, and would be forwarded based on 93 network layer routing information. 95 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 96 SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as 97 defined in RFC 2119. 99 This document is a companion document to [STACK] and [ATM]. 101 2. Terminology 103 LSR 105 A Label Switching Router (LSR) is a device which implements the 106 label switching control and forwarding components described in 107 [ARCH]. 109 LC-FR 111 A label switching controlled Frame Relay (LC-FR) interface is a 112 Frame Relay interface controlled by the label switching control 113 component. Packets traversing such an interface carry labels in 114 the DLCI field. 116 FR-LSR 117 A FR-LSR is an LSR with one or more LC-FR interfaces which 118 forwards frames between two such interfaces using labels carried 119 in the DLCI field. 121 FR-LSR domain 123 A FR-LSR domain is a set of FR-LSRs, which are mutually 124 interconnected by LC-FR interfaces. 126 Edge Set 128 The Edge Set of an FR-LSR domain is the set of LSRs, which are 129 connected to the domain by LC-FR interfaces. 131 Forwarding Encapsulation 133 The Forwarding Encapsulation is the type of MPLS encapsulation 134 (Frame Relay, ATM, Generic) of a packet that determines the 135 packet's MPLS forwarding, or the network layer encapsulation if 136 that packet is forwarded based on the network layer (IP, 137 etc...)header. 139 Input Encapsulation 141 The Input Encapsulation is the type of MPLS encapsulation (Frame 142 Relay, ATM, Generic) of a packet when that packet is received on 143 an LSR's interface, or the network layer (IP, 144 etc...)encapsulation if that packet has no MPLS encapsulation. 146 Output Encapsulation 148 The Output Encapsulation is the type of MPLS encapsulation 149 (Frame Relay, ATM, Generic) of a packet when that packet is 150 transmitted on an LSR's interface, or the network layer (IP, 151 etc...)encapsulation if that packet has no MPLS encapsulation. 153 Input TTL 155 The Input TTL is the MPLS TTL of the top of the stack when a 156 labeled packet is received on an LSR interface, or the network 157 layer (IP) TTL if the packet is not labeled. 159 Output TTL 161 The Output TTL is the MPLS TTL of the top of the stack when a 162 labeled packet is transmitted on an LSR interface, or the 163 network layer (IP) TTL if the packet is not labeled. 165 Additionally, this document uses terminology from [ARCH]. 167 3. Special characteristics of Frame Relay Switches 169 While the label switching architecture permits considerable 170 flexibility in LSR implementation, a FR-LSR is constrained by the 171 capabilities of the (possibly pre-existing) hardware and the 172 restrictions on such matters as frame format imposed by the 173 Multiprotocol Interconnect over Frame Relay [MIFR], or Frame Relay 174 standards [FRF], etc.... Because of these constraints, some special 175 procedures are required for FR-LSRs. 177 Some of the key features of Frame Relay switches that affect their 178 behavior as LSRs are: 180 - the label swapping function is performed on fields (DLCI) in the 181 frame's Frame Relay data link header; this dictates the size and 182 placement of the label(s) in a packet. The size of the DLCI 183 field can be 10 (default), 17, or 23 bits, and it can span two, 184 or four bytes in the header. 186 - there is generally no capability to perform a `TTL-decrement' 187 function as is performed on IP headers in routers. 189 - congestion control is performed by each node based on parameters 190 that are passed at circuit creation. Flags in the frame headers 191 may be set as a consequence of congestion, or exceeding the 192 contractual parameters of the circuit. 194 - although in a standard switch it may be possible to configure 195 multiple input DLCIs to one output DLCI resulting in a 196 multipoint-to-point circuit, multipoint-to-multipoint VCs are 197 generally not fully supported. 199 This document describes ways of applying label switching to Frame 200 Relay switches, which work within these constraints. 202 4. Label Encapsulation 204 By default, all labeled packets should be transmitted with the 205 generic label encapsulation as defined in [STACK], using the frame 206 relay null encapsulation mechanism: 208 0 1 (Octets) 209 +-----------------------+-----------------------+ 210 (Octets)0 | | 211 / Q.922 Address / 212 / (length 'n' equals 2 or 4) / 213 | | 214 +-----------------------+-----------------------+ 215 n | . | 216 / . / 217 / MPLS packet / 218 | . | 219 +-----------------------+-----------------------+ 221 "n" is the length of the Q.922 Address which can be 2 or 4 222 octets. 224 The Q.922 [ITU] representation of a DLCI (in canonical order - 225 the first bit is stored in the least significant, i.e., the 226 right-most bit of a byte in memory) [CANON]is the following: 228 7 6 5 4 3 2 1 0 (bit order) 229 +-----+-----+-----+-----+-----+-----+-----+-----+ 230 (octet) 0 | DLCI(high order) | 0 | 0 | 231 +-----+-----+-----+-----+-----+-----+-----+-----+ 232 1 | DLCI(low order) | 0 | 0 | 0 | 1 | 233 +-----+-----+-----+-----+-----+-----+-----+-----+ 235 10 bits DLCI 237 7 6 5 4 3 2 1 0 (bit order) 238 +-----+-----+-----+-----+-----+-----+-----+-----+ 239 (octet) 0 | DLCI(high order) | 0 | 0 | 240 +-----+-----+-----+-----+-----+-----+-----+-----+ 241 1 | DLCI | 0 | 0 | 0 | 0 | 242 +-----+-----+-----+-----+-----+-----+-----+-----+ 243 2 | DLCI(low order) | 0 | 244 +-----+-----+-----+-----+-----+-----+-----+-----+ 245 3 | unused (set to 0) | 1 | 1 | 246 +-----+-----+-----+-----+-----+-----+-----+-----+ 248 17 bits DLCI 249 7 6 5 4 3 2 1 0 (bit order) 250 +-----+-----+-----+-----+-----+-----+-----+-----00 251 (octet) 0 | DLCI(high order) | 0 | 0 | 252 +-----+-----+-----+-----+-----+-----+-----+----- 253 1 | DLCI | 0 | 0 | 0 | 0 | 254 +-----+-----+-----+-----+-----+-----+-----+-----+ 255 2 | DLCI | 0 | 256 +-----+-----+-----+-----+-----+-----+-----+-----+ 257 3 | DLCI (low order) | 0 | 1 | 258 +-----+-----+-----+-----+-----+-----+-----+-----+ 260 23 bits DLCI 262 The use of the frame relay null encapsulation implies that labels 263 implicitly encode the network protocol type. 265 Rules regarding the construction of the label stack, and error 266 messages returned to the frame source are also described in [STACK]. 268 The generic encapsulation contains "n" labels for a label stack of 269 depth "n" [STACK], where the top stack entry carries significant 270 values for the EXP, S , and TTL fields [STACK] but not for the label, 271 which is rather carried in the DLCI field of the Frame Relay data 272 link header encoded in Q.922 [ITU] address format. 274 5. Frame Relay Label Switching Processing 276 5.1 Use of DLCIs 278 Label switching is accomplished by associating labels with routes and 279 using the label value to forward packets, including determining the 280 value of any replacement label. See [ARCH] for further details. In a 281 FR-LSR, the top (current) MPLS label is carried in the DLCI field of 282 the Frame Relay data link layer header of the frame. The top label 283 carries implicitly information about the network protocol type. 285 For two connected FR-LSRs, a full-duplex connection must be available 286 for LDP. The DLCI for the LDP VC is assigned a value by way of 287 configuration, similar to configuring the DLCI used to run IP routing 288 protocols between the switches. 290 With the exception of this configured value, the DLCI values used for 291 MPLS in the two directions of the link may be treated as belonging to 292 two independent spaces, i.e. VCs may be half-duplex, each direction 293 with its own DLCI. 295 The allowable ranges of DLCIs, the size of DLCIs, and the support for 296 VC merging MUST be communicated through LDP messages. Note that the 297 range of DLCIs used for labels depends on the size of the DLCI field. 299 5.2 Homogeneous LSPs 301 If is an LSP, it is possible that LSR1, LSR2, and 302 LSR3 will use the same encoding of the label stack when transmitting 303 packet P from LSR1, to LSR2, and then to LSR3. Such an LSP is 304 homogeneous. 306 5.3 Heterogeneous LSPs 308 If is an LSP, it is possible that LSR1 will use 309 one encoding of the label stack when transmitting packet P to LSR2, 310 but LSR2 will use a different encoding when transmitting a packet P 311 to LSR3. In general, the MPLS architecture supports LSPs with 312 different label stack encodings on different hops. When a labeled 313 packet is received, the LSR must decode it to determine the current 314 value of the label stack, then must operate on the label stack to 315 determine the new label value of the stack, and then encode the new 316 value appropriately before transmitting the labeled packet to its 317 next hop. 319 Naturally there will be MPLS networks which contain a combination of 320 Frame Relay switches operating as LSRs, and other LSRs, which operate 321 using other MPLS encapsulations, such as the Generic (MPLS shim 322 header), or ATM encapsulation. In such networks there may be some 323 LSRs, which have Frame Relay interfaces as well as MPLS Generic 324 ("MPLS Shim") interfaces. This is one example of an LSR with 325 different label stack encodings on different hops of the same LSP. 326 Such an LSR may swap off a Frame Relay encoded label on an incoming 327 interface and replace it with a label encoded into a Generic MPLS 328 (MPLS shim) header on the outgoing interface. 330 5.4 Frame Relay Label Switching Loop Prevention and Control 332 FR-LSRs SHOULD operate on loop free FR-LSPs or LSP Frame Relay 333 segments. Therefore, FR-LSRs SHOULD use loop detection and MAY use 334 loop prevention mechanisms as described in [ARCH], and [LDP]. 336 5.4.1 FR-LSRs Loop Control - MPLS TTL processing 338 The MPLS TTL encoded in the MPLS label stack is a mechanism used to: 340 (a) suppress loops; 342 (b) limit the scope of a packet. 344 When a packet travels along an LSP, it should emerge with the same 345 TTL value that it would have had if it had traversed the same 346 sequence of routers without having been label switched. If the 347 packet travels along a hierarchy of LSPs, the total number of LSR- 348 hops traversed should be reflected in its TTL value when it emerges 349 from the hierarchy of LSPs [ARCH]. 351 The initial value of the MPLS TTL is loaded into a newly pushed label 352 stack entry from the previous TTL value, whether that is from the 353 network layer header when no previous label stack existed, or from a 354 pre-existent lower level label stack entry. 356 A FR-LSR switching same level labeled packets does not decrement the 357 MPLS TTL. A sequence of such FR-LSR is a "non-TTL segment". 359 When a packet emerges from a "non-TTL LSP segment", it should however 360 reflect in the TTL the number of LSR-hops it traversed. In the 361 unicast case, this can be achieved by propagating a meaningful LSP 362 length or LSP Frame Relay segment length to the FR-LSR ingress nodes, 363 enabling the ingress to decrement the TTL value before forwarding 364 packets into a non-TTL LSP segment [ARCH]. 366 When an ingress FR-LSR determines upon decrementing the MPLS TTL that 367 a particular packet's TTL will expire before the packet reaches the 368 egress of the "non-TTL LSP segment", the FR-LSR MUST not label switch 369 the packet, but rather follow the specifications in [STACK] in an 370 attempt to return an error message to the packet's source: 372 - it treats the packet as an expired packet and return an ICMP 373 message to its source. 375 - it forwards the packet, as an unlabeled packet, with a TTL 376 that reflects the IP (network layer) forwarding. 378 If the incoming TTL is 1, only the first option applies. 380 In the multicast case, a meaningful LSP length or LSP segment length 381 is propagated to the FR-LSR egress node, enabling the egress to 382 decrement the TTL value before forwarding packets out of the non-TTL 383 LSP segment. 385 5.4.2 Performing MPLS TTL calculations 387 The calculation applied to the "input TTL" that yields the "output 388 TTL" depends on (i)the "input encapsulation", (ii)the "forwarding 389 encapsulation", and (iii)the "output encapsulation". The 390 relationship among (i),(ii), and (iii), can be defined as a function 391 "D" of "input encapsulation" (ie), "forwarding encapsulation" (fe), 392 and "output encapsulation" (oe). Subsequently the calculation applied 393 to the "input TTL" to yield the "output TTL" can be described as: 395 output TTL = input TTL - D(ie, fe, oe) 397 or in a brief notation: 399 output TTL = input TTL - d 401 where "d" has three possible values: "0","1", or "the number of hops 402 of the LSP segment": 404 For unicast transmission: 406 +================+=================+=================+=================+ 407 | | Type of | Type of | Type of | 408 | d | Input | Forwarding | Output | 409 | | Encapsulation | Encapsulation | Encapsulation | 410 +================+=================+=================+=================+ 411 | 0 | Frame Relay | Frame Relay | Frame Relay | 412 +----------------+-----------------+-----------------+-----------------+ 413 | 1 | any | Generic MPLS | Generic MPLS | 414 +----------------+-----------------+-----------------+-----------------+ 415 | number of hops | | Generic MPLS | | 416 | of | any | or | Frame Relay | 417 | LSP segment | |IP(network layer)| | 418 +================+=================+=================+=================+ 420 The "number of hops of the LSP segment" is the value of the "hop 421 count" that is attached with the label used when the packet is 422 forwarded, if LDP [LDP] has provided such a "hop count" value when it 423 distributed the label for the LSP, that is the LDP message had a "hop 424 count object". If LDP didn't provide a "hop count", or it provided an 425 "unknown" value, the default value of the "number of hops of the 426 segment" is 1. 428 When sending a label binding upstream, the "hop count" associated 429 with the corresponding binding from downstream, if different than the 430 "unknown" value, MUST be incremented by 1, and the result transmitted 431 upstream as the hop count associated with the new binding (the 432 "unknown" value is transmitted unchanged). If the new "hop count" 433 value exceeds the "maximum" value, the FR-LSR MUST NOT pass the 434 binding upstream, but instead MUST send an error upstream 435 [LDP][ARCH]. 437 For multicast transmission: 439 +================+=================+=================+=================+ 440 | | Type of | Type of | Type of | 441 | d | Input | Forwarding | Output | 442 | | Encapsulation | Encapsulation | Encapsulation | 443 +================+=================+=================+=================+ 444 | 0 | Frame Relay | Frame Relay | Frame Relay | 445 +----------------+-----------------+-----------------+-----------------+ 446 | | | Generic MPLS | | 447 | 1 | any | or | Frame Relay | 448 | | |IP(network layer)| | 449 +----------------+-----------------+-----------------+-----------------+ 450 | number of hops | | Generic MPLS | | 451 | of | Frame Relay | or | any | 452 | LSP segment | |IP(network layer)| | 453 +================+=================+=================+=================+ 455 Referring to the "forwarding encapsulation" with the abbreviation "I" 456 for IP (network layer), "G" for Generic MPLS, and "F" for Frame 457 Relay MPLS, referring to an LSR interface with the abbreviation "i" 458 if the input or output encapsulation is IP and no MPLS encapsulation, 459 "g" when the input or output MPLS encapsulation is Generic MPLS, "f" 460 when it is Frame Relay, "a" when it is ATM, and furthermore 461 considering the symbols "iIf", "gGf", "fFf", etc... as LSRs with 462 input, forwarding and output encapsulations as referred above, the 463 following describes examples of TTL calculations for the Homogeneous 464 and Heterogeneous LSPs discussed in previous sections: 466 Homogeneous LSP 467 --------------- 468 IP_ttl = n IP_ttl=mpls_ttl-1 = n-6 469 --------->iIf fIi---------> 470 | mpls_ttl = n-5 ^ 471 | | 472 number of hops 1| Frame Relay |5 473 | | 474 V 2 3 4 | 475 fFf--->fFf--->fFf--->fFf 476 "iIf" is "ingress LSR" in Frame Relay LSP and 477 calculates: mpls_ttl = IP_TTL - number of hops = n-5 478 "fIi" is "egress LSR" from Frame Relay LSP, and 479 calculates: IP_ttl = mpls_ttl-1 = n-6 481 Heterogeneous LSP 482 ----------------- 483 ingress LSR egress LSR 484 IP_ttl = n IP_ttl = n - 15 485 links LAN PPP FR ATM PPP FR LAN 486 --->iIg-->gGg-->gGf fGa aGg-->gGf fGg-->gIi---> 487 hops 1 2 | 6 | | 9 | 10 | 13 ^ 14 15 488 |1 4| |1 3| |1 3| 489 V 2 3 | V 2 | V 2 | 490 fFf-->fFf-->fFf aAa-->aAa fFf-->fFf 491 mpls_ttl 492 n-1 n-2 (n-2)-4=n-6 (n-6)-3=n-9 n-10 n-13 n-14 494 "iIg" is "ingress LSR" in LSP; it calculates: mpls_ttl=n-1 495 "gGf" is "egress LSR" from Generic MPLS segment, and 496 "ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-6 497 "fGa" "egress LSR" from Frame Relay segment, and 498 "ingress LSR" in ATM segment and calculates: mpls_ttl=n-9 499 "gGf" is "egress LSR" from Generic MPLS segment, and 500 "ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-13 501 "fGg" is "egress LSR" from Frame Relay segment, and 502 ingress LSR" in Generic MPLS segment and calculates: mpls_ttl=n-14 503 "gIi" is "egress LSR" from LSP and calculates: IP_ttl=n-15 505 And further examples: 507 Frame Relay Unicast -- TTL calculated at ingress 509 (ingress LSR) 1 2 3 4 510 x--->---+--->---+--->>--+-->>---x (egress LSR) 511 o.ttl=i.ttl-4 | 2 3 512 ^ 513 hops 1| 514 | 515 x (ingress LSR) 516 o.ttl=i.ttl-3 517 Frame Relay Multicast -- TTL calculated at egress 519 (egress LSR)x o.ttl=i.ttl-3 520 hops | 521 ^3 522 (ingress LSR) | o.ttl=i.ttl-4 523 x--->---+--->---+--->---+--->---x (egress LSR) 524 1 2 3 4 526 5.5 Label Processing by Ingress FR-LSRs 528 When a packet first enters an MPLS domain, the packet is forwarded by 529 normal network layer forwarding operations with the exception that 530 the outgoing encapsulation will include an MPLS label stack [STACK] 531 with at least one entry. The frame relay null encapsulation will 532 carry information about the network layer protocol implicitly in the 533 label, which MUST be associated only with that network protocol. The 534 TTL field in the top label stack entry is filled with the network 535 layer TTL (or hop limit) resulted after network layer forwarding 536 [STACK]. The further FR-LSR processing is similar in both possible 537 cases: 539 (a) the LSP is homogeneous -- Frame Relay only -- and the FR-LSR is 540 the ingress. 542 (b) the LSP is heterogeneous -- Frame Relay, PPP, Ethernet, ATM, 543 etc... segments form the LSP -- and the FR-LSR is the ingress into a 544 Frame Relay 545 segment. 547 For unicast packets, the MPLS TTL SHOULD be decremented with the 548 number of hops of the Frame Relay LSP (homogeneous), or Frame Relay 549 segment of the LSP (heterogeneous). An LDP constructing the LSP 550 SHOULD pass meaningful information to the ingress FR-LSR regarding 551 the number of hops of the "non-TTL segment". 553 For multicast packets, the MPLS TTL SHOULD be decremented by 1. An 554 LDP constructing the LSP SHOULD pass meaningful information to the 555 egress FR-LSR regarding the number of hops of the "non-TTL segment". 557 Next, the MPLS encapsulated packet is passed down to the Frame Relay 558 data link driver with the top label as output DLCI. The Frame Relay 559 frame carrying the MPLS encapsulated packet is forwarded onto the 560 Frame Relay VC to the next LSR. 562 5.6 Label Processing by Core FR-LSRs 564 In a FR-LSR, the current (top) MPLS label is carried in the DLCI 565 field of the Frame Relay data link layer header of the frame. Just as 566 in conventional Frame Relay, for a frame arriving at an interface, 567 the DLCI carried by the Frame Relay data link header is looked up in 568 the DLCI Information Base, replaced with the correspondent output 569 DLCI, and transmitted on the outgoing interface (forwarded to the 570 next hop node). 572 The current label information is also carried in the top of the label 573 stack. In the top-level entry, all fields except the label 574 information, which is carried and switched in the Frame Relay frame 575 data link-layer header, are of current significance. 577 5.7 Label Processing by Egress FR-LSRs 579 When reaching the end of a Frame Relay LSP, the FR-LSR pops the label 580 stack [ARCH]. If the label popped is the last label, it is necessary 581 to determine the particular network layer protocol which is being 582 carried. The label stack carries no explicit information to identify 583 the network layer protocol. This must be inferred from the value of 584 the label which is popped from the stack. 586 If the label popped is not the last label, the previous top level 587 MPLS TTL is propagated to the new top label stack entry. 589 If the FR-LSR is the egress switch of a Frame Relay segment of a 590 hybrid LSP, and the end of the Frame Relay segment is not the end of 591 the LSP, the MPLS packet will be processed for forwarding onto the 592 next segment of the LSP based on the information held in the Next Hop 593 Label Forwarding Entry (NHLFE) [ARCH]. The output label is set to the 594 value from the NHLFE, and the MPLS TTL is decremented by the 595 appropriate value depending the type of the output interface and the 596 type of transmit operation (see section 6.3). Further, the MPLS 597 packet is forwarded according to the MPLS specifications for the 598 particular link of the next segment of the LSP. 600 For unicast packets, the MPLS TTL SHOULD be decremented by one if the 601 output interface is a generic one, or with the number of hops of the 602 next ATM segment of the LSP (heterogeneous), if the output interface 603 is an ATM (non-TTL) interface. 605 For multicast packets, the MPLS TTL SHOULD be decremented by the 606 number of hops of the FR segment being exited. An LDP constructing 607 the LSP SHOULD pass meaningful information to the egress FR-LSR 608 regarding the number of hops of the FR "non-TTL segment". 610 6. Label Switching Control Component for Frame Relay 612 To support label switching a Frame Relay Switch MUST implement the 613 control component of label switching, which consists primarily of 614 label allocation and maintenance procedures. Label binding 615 information MAY be communicated by several mechanisms, one of which 616 is the Label Distribution Protocol (LDP) [LDP]. 618 Since the label switching control component uses information learned 619 directly from network layer routing protocols, this implies that the 620 switch MUST participate as a peer in these protocols (e.g., OSPF, 621 IS-IS). 623 In some cases, LSRs may use other protocols (e.g. RSVP, PIM, BGP) to 624 distribute label bindings. In these cases, a Frame Relay LSR should 625 participate in these protocols. 627 In the case where Frame Relay circuits are established via LDP, or 628 RSVP, or others, with no involvement from traditional Frame Relay 629 mechanisms, it is assumed that circuit establishing contractual 630 information such as input/output maximum frame size, 631 incoming/outgoing requested/agreed throughput, incoming/outgoing 632 acceptable throughput, incoming/outgoing burst size, 633 incoming/outgoing frame rate, used in transmitting, and congestion 634 control MAY be passed to the FR-LSRs through RSVP, or can be 635 statically configured. It is also assumed that congestion control and 636 frame header flagging as a consequence of congestion, would be done 637 by the FR-LSRs in a similar fashion as for traditional Frame Relay 638 circuits. With the goal of emulating a best-effort router as default, 639 the default VC parameters, in the absence of LDP, RSVP, or other 640 mechanisms participation to setting such parameters, should be zero 641 CIR, so that input policing will set the DE bit in incoming frames, 642 but no frames are dropped. 644 Control and state information for the circuits based on MPLS MAY be 645 communicated through LDP. 647 Support of label switching on a Frame Relay switch requires 648 conformance only to [FRF] (framing, bit-stuffing, headers, FCS) 649 except for section 2.3 (PVC control signaling procedures, aka LMI). 650 Q.933 signaling for PVCs and/or SVCs is not required. PVC and/or SVC 651 signaling may be used for non-MPLS (standard Frame Relay) PVCs and/or 652 SVCs when both are running on the same interface as MPLS, as 653 discussed in the next section. 655 6.1 Hybrid Switches (Ships in the Night) 657 The existence of the label switching control component on a Frame 658 Relay switch does not preclude the ability to support the Frame Relay 659 control component defined by the ITU and Frame Relay Forum on the 660 same switch and the same interfaces (NICs). The two control 661 components, label switching and those defined by ITU/Frame Relay 662 Forum, would operate independently. 664 Definition of how such a device operates is beyond the scope of this 665 document. However, only a small amount of information needs to be 666 consistent between the two control components, such as the portions 667 of the DLCI space which are available to each component. 669 7. Label Allocation and Maintenance Procedures 671 The mechanisms and message formats of a Label Distribution Protocol 672 are documented in [ARCH] and [LDP]. The "downstream-on-demand" label 673 allocation and maintenance mechanism discussed in this section MUST 674 be used by FR-LSRs that do not support VC merging, and it MAY also be 675 used by FR-LSRs that do support VC merging (note that this mechanism 676 applies to hop-by-hop routed traffic): 678 7.1 Edge LSR Behavior 680 Consider a member of the Edge Set of a FR-LSR domain. Assume that, as 681 a result of its routing calculations, it selects a FR-LSR as the next 682 hop of a certain route (FEC), and that the next hop is reachable via 683 a LC-Frame Relay interface. Assume that the next-hop FR-LSR is an 684 "LDP-peer" [ARCH][LDP]. The Edge LSR sends an LDP "request" message 685 for a label binding from the next hop, downstream LSR. When the Edge 686 LSR receives in response from the downstream LSR the label binding 687 information in an LDP "mapping" message, the label is stored in the 688 Label Information Base (LIB) as an outgoing label for that FEC. The 689 "mapping" message may contain the "hop count" object, which 690 represents the number of hops a packet will take to cross the FR-LSR 691 domain to the Egress FR-LSR when using this label. This information 692 may be stored for TTL calculation. Once this is done, the LSR may use 693 MPLS forwarding to transmit packets in that FEC. 695 When a member of the Edge Set of the FR-LSR domain receives an LDP 696 "request" message from a FR-LSR for a FEC, it means it is the 697 Egress-FR-LSR. It allocates a label, creates a new entry in its Label 698 Information Base (LIB), places that label in the incoming label 699 component of the entry, and returns (via LDP) a "mapping" message 700 containing the allocated label back upstream to the LDP peer that 701 originated the request. The "mapping" message contains the "hop 702 count" object value set to 1. 704 When a routing calculation causes an Edge LSR to change the next hop 705 for a route, and the former next hop was in the FR-LSR domain, the 706 Edge LSR should notify the former next hop (via an LDP "release" 707 message) that the label binding associated with the route is no 708 longer needed. 710 When a Frame Relay-LSR receives an LDP "request" message for a 711 certain route (FEC) from an LDP peer connected to the FR-LSR over a 712 LC-FR interface, the FR-LSR takes the following actions: 714 - it allocates a label, creates a new entry in its Label 715 Information Base (LIB), and places that label in the incoming 716 label component of the entry; 718 - it propagates the "request", by sending an LDP "request" 719 message to the next hop LSR, downstream for that route (FEC); 721 In the "ordered control" mode [ARCH], the FR-LSR will wait for its 722 "request" to be responded from downstream with a "mapping" message 723 before returning the "mapping" upstream in response to a "request" 724 ("ordered control" approach [ARCH]). In this case, the FR-LSR 725 increments the hop count it received from downstream and uses this 726 value in the "mapping" it returns upstream. 728 Alternatively, the FR-LSR may return the binding upstream without 729 waiting for a binding from downstream ("independent control" approach 730 [ARCH]). In this case, it uses a reserved value for hop count in the 731 "mapping", indicating that it is 'unknown'. The correct value for hop 732 count will be returned later, as described below. 734 Since both the "ordered" and "independent" control has advantages and 735 disadvantages, this is left as an implementation, or configuration 736 choice. 738 Once the FR-LSR receives in response the label binding in an LDP 739 "mapping" message from the next hop, it places the label into the 740 outgoing label component of the LIB entry. 742 Note that a FR-LSR, or a member of the edge set of a FR-LSR domain, 743 may receive multiple binding requests for the same route (FEC) from 744 the same FR-LSR. It must generate a new "mapping" for each "request" 745 (assuming adequate resources to do so), and retain any existing 746 mapping(s). For each "request" received, a FR-LSR should also 747 generate a new binding "request" toward the next hop for the route 748 (FEC). 750 When a routing calculation causes a FR-LSR to change the next hop for 751 a route (FEC), the FR-LSR should notify the former next hop (via an 752 LDP "release" message) that the label binding associated with the 753 route is no longer needed. 755 When a LSR receives a notification that a particular label binding is 756 no longer needed, the LSR may deallocate the label associated with 757 the binding, and destroy the binding. This mode is the "conservative 758 label retention mode" [ARCH]. In the case where a FR-LSR receives 759 such notification and destroys the binding, it should notify the next 760 hop for the route that the label binding is no longer needed. If a 761 LSR does not destroy the binding (the FR-LSR is configured in 762 "liberal label retention mode" [ARCH]), it may re-use the binding 763 only if it receives a request for the same route with the same hop 764 count as the request that originally caused the binding to be 765 created. 767 When a route changes, the label bindings are re-established from the 768 point where the route diverges from the previous route. LSRs 769 upstream of that point are (with one exception, noted below) 770 oblivious to the change. Whenever a LSR changes its next hop for a 771 particular route, if the new next hop is a FR-LSR or a member of the 772 edge set reachable via a LC-FR interface, then for each entry in its 773 LIB associated with the route the LSR should request (via LDP) a 774 binding from the new next hop. 776 When a FR-LSR receives a label binding from a downstream neighbor, it 777 may already have provided a corresponding label binding for this 778 route to an upstream neighbor, either because it is using 779 "independent control" or because the new binding from downstream is 780 the result of a routing change. In this case, it should extract the 781 hop count from the new binding and increment it by one. If the new 782 hop count is different from that which was previously conveyed to the 783 upstream neighbor (including the case where the upstream neighbor was 784 given the value 'unknown') the FR-LSR must notify the upstream 785 neighbor of the change. Each FR-LSR in turn increments the hop count 786 and passes it upstream until it reaches the ingress Edge LSR. 788 Whenever a FR-LSR originates a label binding request to its next hop 789 LSR as a result of receiving a label binding request from another 790 (upstream) LSR, and the request to the next hop LSR is not satisfied, 791 the FR-LSR should destroy the binding created in response to the 792 received request, and notify the requester (via an LDP "withdraw" 793 message). 795 When an LSR determines that it has lost its LDP session with another 796 LSR, the following actions are taken: 798 - MUST discard any binding information learned via this 799 connection; 801 - For any label bindings that were created as a result of 802 receiving label binding requests from the peer, the LSR may 803 destroy these bindings (and deallocate labels associated 804 with these binding). 806 7.2 Efficient use of label space - Merging FR-LSRs 808 The above discussion assumes that an edge LSR will request one label 809 for each prefix in its routing table that has a next hop in the FR- 810 LSR domain. In fact, it is possible to significantly reduce the 811 number of labels needed by having the edge LSR request instead one 812 label for several routes. Use of many-to-one mappings between routes 813 (address prefixes) and labels using the notion of Forwarding 814 Equivalence Classes (as described in [ARCH]) provides a mechanism to 815 conserve the number of labels. 817 Note that conserving label space (VC merging) may be restricted in 818 case the frame traffic requires Frame Relay fragmentation. The issue 819 is that Frame Relay fragments must be transmitted in sequence, i.e. 820 fragments of distinct frames must not be interleaved. If the 821 fragmenting FR-LSR ensures the transmission in sequence of all 822 fragments of a frame, without interleaving with fragments of other 823 frames, then label conservation (VC merging) can be performed. 825 When label conservation is used, when a FR-LSR receives a binding 826 request from an upstream LSR for a certain FEC, and it does already 827 have an outgoing label binding for that FEC, it does not need to 828 issue a downstream binding request. Instead, it may allocate an 829 incoming label, and return that label in a binding to the upstream 830 requester. Packets received from the requester, with that label as 831 top label, will be forwarded after replacing the label with the 832 existing outgoing label for that FEC. If the FR-LSR does not have an 833 outgoing label binding for that FEC, but does have an outstanding 834 request for one, it need not issue another request. This means that 835 in a label conservation case, a FR-LSR must respond with a new 836 binding for every upstream request, but it may need to send one 837 binding request downstream. 839 In case of label conservation, if a change in the routing table 840 causes a FR-LSR to select a new next hop for one of its FECs, it MAY 841 release the binding for that route from the former next hop. If it 842 doesn't already have a corresponding binding for the new next hop, it 843 must request one (note that the choice depends on the label retention 844 mode [ARCH]). 846 If a new binding is obtained, which contain a hop count that differs 847 from that of the old binding, the FR-LSR must process the new hop 848 count: increment by 1, if different than "unknown", and notify the 849 upstream neighbors who have label bindings for this FEC of the new 850 value. To ensure that loops will be detected, if the new hop count 851 exceeds the "maximum" value, the label values for this FEC must be 852 withdrawn from all upstream neighbors to whom a binding was 853 previously sent. 855 7.3 LDP messages specific to Frame Relay 857 The Label Distribution Protocol [LDP] messages exchanged between two 858 Frame Relay "LDP-peer" LSRs may contain Frame Relay specific 859 information such as: 861 "Frame Relay Label Range": 863 0 1 2 3 864 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 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Reserved |Len| Minimum DLCI | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Reserved | Maximum DLCI | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 with the following fields: 873 Reserved 874 This fields are reserved. They must be set to zero on transmission 875 and must be ignored on receipt. 877 Len 878 This field specifies the number of bits of the DLCI. The following 879 values are supported: 881 Len DLCI bits 883 0 10 884 1 17 885 2 23 886 Minimum DLCI 887 This 23 bit field is the binary value of the lower bound of a block 888 of Data Link Connection Identifiers (DLCIs) that is supported by 889 the originating FR-LSR. The Minimum DLCI should be right justified 890 in this field and the preceding bits should be set to 0. 892 Maximum DLCI 893 This 23 bit field is the binary value of the upper bound of a block 894 of Data Link Connection Identifiers (DLCIs) that is supported by 895 the originating FR-LSR. The Maximum DLCI should be right justified 896 in this field and the preceding bits should be set to 0. 898 "Frame Relay Merge": 900 0 1 2 3 4 5 6 7 901 +-+-+-+-+-+-+-+-+ 902 | Reserved |M| 903 +-+-+-+-+-+-+-+-+ 905 with the following fields: 907 Merge 908 One bit field that specifies the merge capabilities of the FR-LSR: 910 Value Meaning 912 0 Merge NOT supported 913 1 Merge supported 915 A FR-LSR that supports VC merging MUST ensure that fragmented 916 frames from distinct incoming DLCIs are not interleaved on the 917 outgoing DLCI. 919 Reserved 920 This field is reserved. It must be set to zero on transmission and 921 must be ignored on receipt. 923 and "Frame Relay Label": 925 0 1 2 3 926 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 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Reserved |Len| DLCI | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 with the following fields: 933 Reserved 934 This field is reserved. It must be set to zero on transmission and 935 must be ignored on receipt. 937 Len 938 This field specifies the number of bits of the DLCI. The following 939 values are supported: 941 Len DLCI bits 943 0 10 944 1 17 945 2 23 947 DLCI 948 The binary value of the Frame Relay Label. The significant number 949 of bits (10, 17, or 23) of the label value are to be encoded into 950 the Data Link Connection Identifier (DLCI) field when part of the 951 Frame Relay data link header (see Section 4.). 953 8. Security Considerations 955 This section looks at the security aspects of: 957 (a) frame traffic, 959 (b) label distribution. 961 MPLS encapsulation has no effect on authenticated or encrypted 962 network layer packets, that is IP packets that are authenticated or 963 encrypted will incur no change. 965 The MPLS protocol has no mechanisms of its own to protect against 966 misdirection of packets or the impersonation of an LSR by accident or 967 malicious intent. 969 Altering by accident or forgery an existent label in the DLCI field 970 of the Frame Relay data link layer header of a frame or one or more 971 fields in a potentially following label stack affects the forwarding 972 of that frame. 974 The label distribution mechanism can be secured by applying the 975 appropriate level of security to the underlying protocol carrying 976 label information - authentication or encryption - see [LDP]. 978 9. Acknowledgments 980 The initial version of this document was derived from the Label 981 Switching over ATM document [ATM]. 983 Thanks for the extensive reviewing and constructive comments from (in 984 alphabetical order) Dan Harrington, Milan Merhar, Martin Mueller, 985 Eric Rosen. Also thanks to George Swallow for the suggestion to use 986 null encapsulation, and to Eric Gray for his reviewing. 988 Also thanks to Nancy Feldman and Bob Thomas for their collaboration 989 in including the LDP messages specific to Frame Relay LSRs. 991 10. References 993 [MIFR] T. Bradley, C. Brown, A. Malis "Multiprotocol Interconnect 994 over Frame Relay" RFC 2427, September 1998. 996 [ARCH] E. Rosen, R. Callon, A. Vishwanathan, "Multi-Protocol Label 997 Switching Architecture", Work in Progress, July 1998. 999 [LDP] L. Anderson, P. Doolan, N. Feldman, A. Fredette, R. Thomas, 1000 "Label Distribution Protocol", Work in Progress, August 1998. 1002 [STACK] E. Rosen et al, "Label Switching: Label Stack Encodings", 1003 Work in Progress, September 1998 1005 [ATM] B. Davie et al. "Use of Label Switching with ATM", Work in 1006 Progress, July 1998. 1008 [ITU] International Telecommunications Union, "ISDN Data Link Layer 1009 Specification for Frame Mode Bearer Services", ITU-T Recommendation 1010 Q.922, 1992. 1012 [FRF] Frame Relay Forum, User-to-Network Implementation Agreement 1013 (UNI), FRF 1.1, January 19, 1996 1014 11.Authors' Addresses 1016 Alex Conta 1017 Lucent Technologies Inc. 1018 300 Baker Ave, Suite 100 1019 Concord, MA 01742 1020 +1-978-287-2842 1021 E-mail: aconta@lucent.com 1023 Paul Doolan 1024 Ennovate Networks 1025 330 Codman Hill Rd 1026 Boxborough MA 01719 1027 +1-978-263-2002 1028 E-mail: pdoolan@ennovatenetworks.com 1030 Andrew Malis 1031 Ascend Communications, Inc 1032 1 Robbins Rd 1033 Westford, MA 01886 1034 +1-978-952-7414 1035 E-mail: malis@ascend.com 1036 Appendix A - Changes since previous versions 1038 From "version 02 to 03" 1039 - Replace "cloud" with "domain", 1040 - Update references to other documents, 1041 - Change definitions in "Terminology" section, 1042 - Add more definitions to "Terminology" section, 1043 - Make editorial changes to text and figures, 1044 - Change "Performing TTL calculations" section, 1045 - Add more reviewers in "Acknowledgments" section, 1046 - Add Appendix A - changes.