idnits 2.17.00 (12 Aug 2021) /tmp/idnits2726/draft-kamapabhava-fr-pwe3-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 69 lines == It seems as if not all pages are separated by form feeds - found 13 form feeds but 15 pages 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 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 540 has weird spacing: '...between a pai...' -- 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 (April 2002) is 7334 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) == Unused Reference: 'I233' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'FRF1' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'FRF2' is defined on line 722, but no explicit reference was found in the text == Unused Reference: 'FRF4' is defined on line 725, but no explicit reference was found in the text == Unused Reference: 'FRF10' is defined on line 728, but no explicit reference was found in the text == Unused Reference: 'PWE3REQ' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'RFC2615' is defined on line 750, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'I233' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF4' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF10' == Outdated reference: draft-ietf-pwe3-requirements has been published as RFC 3916 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-requirements (ref. 'PWE3REQ') -- Possible downref: Non-RFC (?) normative reference: ref. 'PWE3FW' -- Possible downref: Non-RFC (?) normative reference: ref. 'Q922' -- Possible downref: Non-RFC (?) normative reference: ref. 'Q933' -- Possible downref: Non-RFC (?) normative reference: ref. 'X36' -- Possible downref: Non-RFC (?) normative reference: ref. 'X76' Summary: 6 errors (**), 0 flaws (~~), 14 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PWE3 Working Group Claude Kawa 2 Internet Draft Nortel Networks 3 Expires: October 2002 Andrew G. Malis 4 Vivace Networks, Inc. 5 Prayson Pate 6 Overture Networks, Inc. 7 Ravi Bhat 8 Nishit Vasavada 9 Amber Networks 11 April 2002 13 Frame Relay Transport and Encapsulation over Pseudo-Wires 14 draft-kamapabhava-fr-pwe3-01.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance 19 with all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other groups 23 may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference material 28 or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright(C) The Internet Society (2001). All Rights Reserved. 39 Abstract 41 This document defines frame relay pseudo-wire specific aspects. A frame 42 relay pseudo wire exists between network edge nodes and support as 43 faithfully as possible an instance of a frame relay service. A frame 44 relay pseudo-wire is a mechanism that allows frame relay protocol 45 control information and payload to be carried over IP or MPLS Packet 46 Switched Networks. 48 Table of Contents 50 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . 3 53 4. Requirements for Frame Relay Over PWE3 . . . . . . . . . . . . 3 54 5. Reference model . . . . . . . . . . . . . . . . . . . . . . . 4 55 6. General Encapsulation and FRoPW packet processing . . . . . . 5 56 7. Configuration prerequisites . . . . . . . . . . . . . . . . . 10 57 8. Frame Relay over MPLS PSN . . . . . . . . . . . . . . . . . . 10 58 9. Frame Relay over IP PSN. . . . . . . . . . . . . . . . . . . 11 59 10.Use of L2TP with frame relay pseudo-wires over IP PSN . . . . 12 60 11 Frame relay port to port mode . . . .. . . . . . . . . . . . . 13 61 12.Security Considerations. . . . . . . . . . . . . . . . . . . 13 62 13 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 14.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 64 15.Author's Addresses . . . . . . . . . . . . . . . . . . . . . 14 66 Conventions used in this document 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC 2119. 72 1. Introduction 74 This document defines frame relay pseudo-wire (PW) specific aspects. A 75 frame relay PW allows frame relay protocol control information and 76 payload to be carried over IP or MPLS Packet Switched Networks (PSNs) 77 using MPLS or L2TP for multiplexing as specified in the framework draft 78 [PWE3FW]. A frame relay PW is a mechanism that emulates the essential 79 attributes of frame relay service over a PSN. The required functions 80 to support frame relay PW by a network edge node include: 82 - Encapsulation of frame relay specific information in a suitable 83 frame relay over pseudo wire packet, 85 - Transfer of this information across a PSN for delivery to a peer edge, 86 node, 88 - Extraction of frame relay specific information by the remote edge 89 node, 91 - Generation of native frame relay frames for forwarding across an 92 egress port of the remote PE device, 94 - Execution any other operations required to support frame relay 95 service. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119. Below are the 102 definitions for the terms used throughout the document. 104 Packet Switched Network: 105 A Packet Switched Network (PSN) is a network 106 using IP, MPLS or L2TP as the unit of 107 switching. 109 Pseudo Wire Emulation Edge to Edge: 110 Pseudo Wire Emulation Edge to Edge (PWE3) is a 111 mechanism that emulates the essential 112 attributes of a service (such as a T1 leased 113 line or Frame Relay) over a PSN. 115 Customer Edge: A Customer Edge (CE) is a device where one end 116 of an emulated service originates and 117 terminates. The CE is not aware that it is 118 using an emulated service rather than a "real" 119 service. 121 Provider Edge: A Provider Edge (PE) is a device that provides 122 PWE3 to a CE. 124 Pseudo Wire: A Pseudo Wire (PW) is a connection between two 125 PEs carried over a PSN. The PE provides the 126 adaptation between the CE and the PW. 128 PW End Service: A Pseudo Wire End Service (PWES) is the 129 interface between a PE and a CE. This can be a 130 physical interface like a T1 or Ethernet, or a 131 virtual interface like a VC or VLAN. 133 Pseudo Wire PDU: A Pseudo Wire PDU is a PDU sent on the PW that 134 contains all of the data and control 135 information necessary to provide the desired 136 service. 138 PSN Tunnel: A PSN Tunnel is a tunnel inside which multiple 139 PWs can be nested so that they are transparent 140 to core network devices. 142 3. Acronyms and Abbreviations 144 CE Customer Edge 145 FCS Frame Check Sequence 146 FR Frame Relay 147 FRoPW Frame Relay over Pseudo Wire 148 LSP Label Switched Path 149 LSR Label Switching Router 150 MPLS Multiprotocol Label Switching 151 MTU Maximum Transfer Unit 152 NNI Network-Network Interface 153 PE Provider Edge 154 PSN Packet Switched Network 155 PW Pseudo-wire 156 POS Packet over Sonet/SDH 157 PVC Permanent Virtual Circuit 158 SPVC Switched/Soft permanent virtual circuit 159 SVC Switched Virtual Circuit 160 UNI User-Network Interface 161 VC Virtual Circuit 163 4. Requirements for Frame Relay Over Pseudo-Wire Emulation Edge to edge 165 The section lists the main frame relay pseudo-wires requirements to be 166 met between two edge nodes (known as provider edges (PEs): 168 1. Frame Transport: It must be possible to carry between two PEs both 169 user and maintenance traffic on the same pseudo-wire. It must 170 be possible also to distinguish between the two types of traffic. 172 2. Frame Length: Must transport variable length FR frames 173 without being limited by the PSN MTU. 175 3. Bi-directional traffic: Must support bi-directional traffic. 177 4. Frame ordering: Must preserve FR frames order. 179 5. Control bits: Must support the transport of FR Discard Eligibility 180 (DE), Forward Explicit Congestion Notification (FECN), Backward 181 Explicit Congestion Notification (BECN) and Command/Response (C/R) bits 182 [Q922]. 184 6. PVC Status Maintenance: Must support the mapping and transport of 185 frame relay PVC status indications defined in Q933 Annex A [Q933]. 186 The support of PVC continuity check should be provided. Note PVC status 187 maintenance will be addressed in another IETF draft. 189 7. Traffic Management: Should be able to map the following FR 190 traffic management parameters to PWs traffic parameters: 192 a) CIR (Committed Information Rate) or throughput, 193 b) Bc (Committed burst size), 194 c) Be (Excess Burst Size), 195 e) Maximum frame size. 197 8. Frame Priority and QoS: Should support the ability to map different 198 FR priorities or QoS classes as defined in [X36,X76] to appropriately 199 engineered PWs and tunnel PSNs. 201 9. Frame relay VC type: Must support PVC, support of SVC and SPVC is 202 optional and will be addressed in the future. 204 5. Reference model 206 Figure 1 shows PWE3 reference model with additional frame relay 207 concepts. This section will be completed with additional details 208 imported from [PWE3REQ and PWE3FW] and specific information related 209 to frame relay. 211 |<------- Pseudo Wire ------>| 212 | | 213 | |<-- PSN Tunnel -->| | 214 PW V V V V PW 215 End Service +----+ +----+ End Service 216 (FR UNI or NNI)| | | | (FR UNI or NNI) 217 +-----+ | | PE1|==================| PE2| | +-----+ 218 | |----------|............PW1.............|----------| | 219 | CE1 | | | | | | | | CE2 | 220 | |----------|............PW2.............|----------| | 221 +-----+ | | |==================| | | +-----+ 222 ^ +----+ +----+ | ^ 223 | Provider Edge 1 Provider Edge 2 | 224 | | 225 |<------------- Emulated Service ----------------->| 226 (i.e. FR PVC, SVC or SPVC) 227 Customer Customer 228 Edge 1 Edge 2 230 Figure 1 - PWE3 Reference Model 232 6. General Encapsulation and FRoPW packet processing 234 6.1. General Encapsulation 236 The general Frame Relay over Pseudo Wires (FRoPW) packet format to 237 carry frame relay information (user's payload and frame relay 238 control information) from one PE to another is shown in Figure 2. 240 +-------------------------------+ 241 | | 242 | Delivery Header | 243 | | 244 +-------------------------------+ 245 | | 246 | FRoPW Header | 247 | | 248 +-------------------------------+ 249 | | 250 | Payload packet | 251 | | 252 +-------------------------------+ 254 Figure 2 - General format of FRoPW packet 256 The delivery header is a header specific to the PSN, it is discussed in 257 the following sections addressing each type of PSN. FRoPW header 258 contains protocol control information, its structure is shown in Figure 259 3. The packet payload field is the content of the information field of 260 frame relay frame defined in ITU-T Recommendation Q.922 Annex A [Q922]. 262 FRoPW header structure is shown in Figure 3. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Res |P|B|F|D|C|I|L| Length | Sequence Number | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 3 - FRoPW header structure 272 The meaning of the fields is as follows: 273 Res (bits 0 to 2): 274 Reserved bits. They are set to zero on transmission and ignored on 275 reception. 277 P - Payload Type (bit 3): 278 If set to zero then the payload field contains user's data else it 279 contains network maintenance data used by the PEs. 281 B - BECN (bit 4): 282 FR BECN (Backward Explicit Congestion Notification) bit [Q.922]. 284 F - FECN (bit 5): 285 FR FECN (Forward Explicit Congestion Notification) bit [Q922]. 287 D - DE (bit 6) 288 FR DE bit indicates the discard eligibility [Q922]. 290 C/R - Command/Response (bit 7) 291 FR frame C/R (command/response) bit [Q922]. 293 I, L - Initial and Last fragment indicators (bits 8 and 9): 295 0 1: First fragment of a fragmented FRoPW packet 296 1 0: Last fragment of a fragmented FRoPW packet 297 0 0: Complete FRoPW packet 298 1 1: Neither the first nor the last fragment of a fragmented FRoPW packet 300 I and L bits are used for fragmentation and re-assembly of FRoPW packet 301 when these capabilities are enabled in the two PEs terminating a PW. 303 Length (bits 10 to 15): 304 The length field is used to pad short FRoPW packets when Ethernet links 305 are used in the PSN. The length field is used as follows: If the length 306 of a frame relay frame (consisting of control information and payload) 307 is less than 64 bytes, the length field MUST be set to the FRoPW packet 308 length. Otherwise the length field MUST be set to zero. The value of the 309 length field, if non-zero, is used to remove any padding. 311 Sequence number (Bit 16 to 31): 312 If it is not used, it is set to zero by the sender and ignored by the 313 receiver. Otherwise it specifies the sequence number of a complete FRoPW 314 packet or a fragment. A circular list of sequence numbers is used. A 315 sequence number takes a value from 1 to 65535 (2**16-1). Arithmetic 316 modulo 2**16 is used to generate a new sequence number. The value of 317 zero indicates that the sequence number field is not used. 319 The sequence number must be used when fragmentation and re-assembly are 320 enabled between two peer PEs terminating a PSN tunnel. The sequence 321 number may be used to detect out-of-order delivery of FRoPW packets 322 when the PSN does not guarantee in-order delivery. 324 6.2. FRoPW packet processing 326 6.2.1. Generating FRoPW packets 328 The generation process of a FRoPW packet is initiated when a PE receives 329 a frame relay frame from one of its frame relay UNI or NNI. The PE takes 330 the following actions (not necessarily in the order shown): 332 - It generates the following fields of FRoPW header from the 333 corresponding fields of the frame relay frame as follows: 335 - C/R bit is copied unchanged in the FRoPW header. 337 - DE bit is copied as follows into the FRoPW header: If it was set to 338 one in the incoming frame relay frame, it must be copied unchanged 339 in the FRoPW header. Otherwise if it was set to zero, it may be set 340 to zero or one, depending on the traffic policing performed by the 341 PE device. 343 - FECN is copied as follows into the FRFoPW header: If it was set to 344 one in the incoming frame relay frame, it must be copied unchanged 345 in the FRoPW header. Otherwise if it was set to zero, it may be set 346 to zero or one, depending on the congestion state of the PE device 347 in the forward direction. 349 - BECN follows the same processing rules as FECN, except that it 350 applies to the backward direction. 352 - The length field will be addressed in the next iteration of this draft. 354 - The sequence field is set according to the configuration parameters. 355 Details are provided below. 357 - The payload field is the contents of the frame relay information field 358 stripped from any bit or byte stuffing. 360 Once the FRoPW packet has been generated, additional processing specific 361 to the type of PW used and the underlying PSN is performed. 363 6.2.1.1. Setting the sequence number 365 If the two PEs terminating a PSN tunnel support the sequence number 366 capability then the following procedure to number FRoPW packets is used: 368 - The initial packet transmitted on the frame relay PW MUST use 369 sequence number 1, 371 - For a subsequent packet, the sequence number corresponds to the 372 sequence number of the preceding packet incremented by 1 modulo 373 2**16, 375 - When the sequence number reaches the maximum 16 bit 376 value (65535) the next sequence number wrap to 1. 378 If the PEs do not support sequence number processing, then the sequence 379 number field MUST be set to 0. 381 6.2.2. Receiving FRoPW packets 383 When a PE receives a FRoPW packet, it processes the different FRoPW 384 header fields in order to synthesize a new frame relay frame for 385 transmission across one of its frame relay UNI or NNI. The PE performs 386 the following act ions (not necessarily in the order shown): 388 - The PE checks the P bit to ensure that it is set to "user's data", 390 - It generates the following frame relay header fields from the 391 corresponding fields of the FRoPW packet as follows: 393 - C/R bit is copied unchanged in the frame relay header. 395 - DE bit is copied as follows into the frame relay header: If it was 396 set to one in the incoming FRoPW packet, it must be copied 397 unchanged in the frame relay header. Otherwise if it was set to 398 zero, it may be set to zero or one, depending on the traffic 399 policing performed by the PE device. 401 - FECN is copied as follows in the frame relay header: If it was set 402 to one in the incoming FRoPW packet, it must be copied unchanged 403 in the frame relay header. Otherwise if it was set to zero, it may 404 be set to zero or one, depending on the congestion state of the PE 405 device in the forward direction. 407 - BECN follows the same processing rules as FECN, except that it 408 applies to the backward direction. 410 - It processes the length and sequence field, the details are in the 411 subsequent sub-sections. 413 - It generates the frame relay information field from the contents of 414 the FRoPW packet payload and retrieves the appropriate DLCI. 416 Once the frame relay frame has been generated, it is queued for 417 transmission across the selected frame relay UNI or NNI after the FCS 418 and HDLC flags have been added and any bit or byte stuffing has been 419 performed. 421 6.2.2.1 Checking the sequence number 423 If the receiving PE support packet sequencing, the processing is done as 424 follows: 426 When a FRoPW packet is received the sequence number is processed as follows: 428 - If the sequence number of the packet is 0, then the packet passes the 429 sequence number check. 431 - Otherwise if the packet sequence number >= the expected sequence 432 number and the packet sequence number - the expected sequence 433 number < 32768, then the packet is in order. 435 - Otherwise if the packet sequence number < the expected sequence 436 number and the expected sequence number - the packet sequence 437 number >= 32768, then the packet is in order. 439 - Otherwise the packet is out of order. 441 If a FRoPW packet passes the sequence number check, it is further 442 processed in order to be forwarded to its next destination. 444 If the packet is in order, then the expected sequence number is set as 445 per the following assignment: 447 expected_sequence_number := packet_sequence_number + 1 mod 2**16 448 if (expected_sequence_number = 0) then expected_sequence_number := 1; 450 FRoPW packets, which are received out of order are dropped. Packet 451 re-ordering by the receiver is not supported in this version of the 452 draft. 454 If the receiving PE does not support sequence number processing, then 455 the sequence number field is ignored. Note support of the sequence 456 number capability is agreed upon by the two PEs either by configuration 457 or by signalling prior to any packet exchange. 459 6.2.2.3 Processing of the length field by the receiver 461 (To be completed) 462 6.3. Fragmentation and Re-assembly procedures 464 6.3.1. Fragmentation procedure 465 Fragmentation is performed when a FRoPW packet is too long for 466 transmission across the PSN and when the configuration of the PSN 467 tunnel and/or PW allows fragmentation to be performed. I and L bits of 468 a FRoPW fragment are used to indicate the type of fragment: 470 First fragment (I = 0 and L = 1), last fragment (I = 1 and L = 0) 471 neither the first not the last fragment(I = L = 1). The sequence number 472 is used to number the fragments. If packet sequencing is used for every 473 FRoPW packet, the numbering of FRoPW fragments follows the same 474 procedure as the numbering of complete packets: For every fragment, the 475 sequence number is the sequence number of the previous FRoPW 476 packet/fragment incremented by one modulo 2**16. 478 When packet sequencing is not used for every packet but only with 479 fragmentation and re-assembly, the sequence number is re-initialized for 480 every long frame relay frame that requires fragmentation. The first 481 FRoPW packet fragment has a sequence number equal to 1 and for each 482 subsequent fragment, the sequence number is incremented by 483 1 modulo 2**16. 485 If fragmentation is not supported and a frame relay frame is too long 486 for transmission in a single FRoPW packet, it shall be discarded. 488 6.3.2. Re-assembly procedure 489 When a frame relay frame has been fragmented into multiple FRoPW 490 fragments by the sending PE and fragmentation/re-assembly is supported 491 by the receiving PE, the receiving PE will re-assemble the FRoPW 492 fragments to synthesize the original frame relay frame. 494 6.4. Handling of error conditions 496 To be completed. 498 6.5. FR SVC and SPVC Signalling between PEs 500 Not supported in this document. 502 6.6. FR PVC provisioning 504 Provisioning of frame relay VCs requires the following actions: Frame 505 relay VC segments (see Figure 1) are provisioned between each CE and 506 the corresponding PE. A FR PW is established between the two PEs to 507 complete the Frame Relay VC. 509 The two PEs terminating a frame relay PW executed a PVC maintenance 510 protocol to exchange PVC status information and for "keep-alive" 511 purposes. The PVC maintenance protocol will be defined in another 512 document. 514 7. Configuration prerequisites 516 Since frame relay VCs are bi-directional and carry traffic in the two 517 opposite directions, at least one pair of tunnel PSN must be available 518 between two PEs with appropriate traffic and QoS capabilities before 519 they can start exchanging FRoPW packets. Some PSN tunnels require to be 520 created and maintained, other do not. Establishing, maintaining and 521 releasing PSN tunnel are outside the scope of this document. Binding 522 between a pair of frame relay interfaces/DLCI and a PW is done when the 523 PW and FR VC segments are created. 525 In addition a PE must be configured with the following parameters per 526 tunnel PSN. These parameters will apply to all Frame Relay PWs nested 527 inside the tunnel PSN: 529 1. Maximum transfer unit (MTU) of the PSN, 530 2. Whether fragmentation and re-assembly will be supported or not, 531 3. Use of the sequence number: With fragmentation only, always or never, 532 4. Additional configuration parameters specific to each PW and PSN are 533 listed in the section covering each PSN. 535 8. Frame Relay over MPLS PSN 537 8.1. MPLS tunnel and VC LSPs 539 MPLS label switched paths (LSPs) called "Tunnel LSPs" establish an 540 association between a pair of PEs. A tunnel LSP correspond to a "PSN 541 tunnel" of Figure 1. Several "Virtual Circuit LSPs" (VC LSPs) may be 542 nested inside one Tunnel LSP. Each VC LSP carries the traffic of a frame 543 relay PVC or SVC in one direction. Since LSPs are uni-directional, a 544 pair of VC LSPs (and corresponding tunnel LSPs) carrying traffic in 545 opposite directions will be required usually for each frame relay PVC 546 or SVC. 548 8.2. Relationship between FR VCs and MPLS VC LSPs 550 Frame Relay VCs are considered to be bi-directional objects mainly 551 because of the way they are created and identified. A single frame relay 552 identifier (DLCI) refers to the two directions of a frame relay VC and 553 frame relay signalling establishes the two directions simultaneously 554 with the same message flows. In general each direction of a frame relay 555 VC may have different traffic and QoS characteristics. The resource 556 management of a frame relay implementation treats each direction 557 separately and independently. MPLS LSPs, on the other hand are uni- 558 directional and are established separately. 560 In the case of frame relay over MPLS, during the creation of a frame 561 relay VC, a pair of VC LSPs will have to be established between two PEs. 562 For one end-to-end frame relay VC two VC LSPs exists: One VC LSP to 563 transport the traffic from PE1 to PE2 and another one to transport the 564 traffic in the opposite direction. The VC LSP in each direction must 565 comply with the characteristics of the corresponding direction of the 566 frame relay VC. 568 The VC LSP from PE1 to PE2 is the transmit VC LSP for PE1 and the 569 receive LSP for PE2. Likewise, the VC LSP from PE2 to PE1 is the 570 transmit LSP for PE2 and the receive LSP for PE1. 572 In the frame relay domain, a DLCI identifies a frame relay VC and in the 573 MPLS domain, VC LSP labels with possible different values identify the 574 pair of VC LSPs, one label value for each LSP. 576 In PE1 to PE2 direction a tunnel LSP transmits MPLS packets from PE1 to 577 PE2,the corresponding label is not related to any frame relay VC. When 578 PE1 sends a FRoPW packet to PE2, it first pushes a VC label on its label 579 stack, and then pushes on a tunnel LSP label. The VC label is not 580 visible until the FRoPW packet reaches PE2. PE2 forwards FRoPW packet 581 based on the LSP VC label. The VC label must be always at the bottom of 582 the label stack. While the packet is transported across the MPLS 583 network, additional labels may be pushed on (and then popped off) as 584 needed. The processing is similar in the opposite direction from PE2 to 585 PE1. 587 8.3. FRoPW packet format over MPLS PSN 589 In the case of frame relay over MPLS PSN, the generic FRoPW packet 590 format of Figure 2 becomes as shown in Figure 4. 592 +-------------------------------+ 593 | Tunnel LSP label(s) | n words (4n bytes per label) 594 +-------------------------------+ 595 | VC LSP label | 1 word 596 +-------------------------------+ 597 | FRoPW Header | 598 | (See Figure 3) | 1 word 599 +-------------------------------+ 600 | Payload packet | 601 |(Q.922 frame information field)| Maximum N bytes 602 | | (to be specified) 603 +-------------------------------+ 605 Figure 4 - Frame relay over MPLS packet format 607 (Section to be completed) 609 9. Frame relay over IP PSN 611 {Section and subsections to be completed) 613 Note both IP v4 and IP v6 are supported. 615 9.1. General aspects of frame relay over IP PSN 617 9.2 Frame relay over IP PSN FRoPW packet format 619 Two FRoPW packet format used over IP (v4 or v6) PSN are defined. One 620 when MPLS is not used for switching and the other, when MPLS is used. 621 When MPLS is not used, FRoPW packet format is shown in Figure 5. 623 +-------------------------------+ 624 | IP v4 or v6 header | m words 625 +-------------------------------+ 626 | FR PW identifier | 627 | (See Figure 6) | 1 word 628 +-------------------------------+ 629 | FRoPW Header | 630 | (See Figure 3) | 1 word 631 +-------------------------------+ 632 | Payload packet | 633 |(Q.922 frame information field)| Maximum N bytes 634 | | (to be specified) 635 +-------------------------------+ 637 Figure 5 -FRoPW packet format over IP PSN without MPLS 639 FR PW identifier field shown in Figure 5 identifies a frame relay 640 VC between two PEs in the case of frame relay over IP PSN without 641 MPLS switching. The format of this field is shown in Figure 6. This 642 format of this identifier is similar to MPLS LSP label format. This 643 format allows to have one size for identifying a frame relay VC between 644 two PEs, instead of having two formats as allowed in FRF.1.2 and FRF.2.2 645 (see [Q922, FRF1 and FRF2]). The use of the other fields will be 646 described in a subsequent version of this draft. 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | FR PW Identifier | Exp |0| TTL | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 FR PW Identifier: Frame relay PW identifier, 20 bits 655 Exp: Experimental Use, 3 bits 656 TTL: Time to Live, 8 bits 658 Figure 6 - Frame relay PW identifier for frame relay over IP PSN 660 When MPLS is used with IP PSN, FRoPW packet format is shown in Figure 7. 662 +-------------------------------+ 663 | Tunnel LSP label(s) | n words (4n bytes per label) 664 +-------------------------------+ 665 | VC LSP label | 1 word 666 +-------------------------------+ 667 | IP v4 or v6 header | n words 668 +-------------------------------+ 669 | FRoPW Header | 670 | (See Figure 3) | 1 word 671 +-------------------------------+ 672 | Payload packet | 673 |(Q.922 frame information field)| Maximum N bytes 674 | | (to be specified) 675 +-------------------------------+ 677 Figure 7 -FRoPW packet format over IP PSN with MPLS 679 9.3. Frame relay over IP PSN processing 681 (To be completed). 683 9.4. Additional configuration objects for frame relay over IP PSN 685 (To be completed as required). 687 10. Use of L2TP with frame relay pseudo-wires over IP PSN 689 When the PSN is an IP PSN, L2TP may be used as the multiplexing protocol 690 as per the framework document [PWE3FW]. 692 (To be completed). 694 11. Frame relay port to port mode 696 Frame relay port to port mode of operation applies to both IP and 697 MPLS PSN. This mode provides transport of frame relay frames 698 encapsulated in their entirety, including the address (with the 699 control bits and DLCI) and information fields, but excluding the 700 flags and the FCS. Bit or byte stuffing is undone. 702 Frame relay control bits (F, B, D and C bits) carried in FRoPW 703 header are not used and must be set to 0 when transmitting ignored 704 upon receipt. It must be noted that this mode is transparent to the 705 FECN, BECN and DE bits; these bits are carried unchanged by the 706 sending PE. 708 Frame relay port mode is an OPTIONAL capability. 710 12. Security Considerations 712 (To be completed). 714 13. References 716 [I233] ITU-T Recommendation I.233.1, ISDN frame relay bearer 717 service, Geneva, October 1991 719 [FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement, 720 Frame Relay Forum, April 2000 722 [FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement, 723 Frame Relay Forum, 2001 725 [FRF4] FRF.4.1, Frame relay SVC UNI Implementation Agreement, 726 Frame Relay Forum, January 2000 728 [FRF10] FRF.10.1, Frame relay SVC NNI Implementation Agreement, 729 Frame Relay Forum, January 2000 731 [PWE3REQ] XiPeng Xiao, et al., Internet draft, draft-ietf-pwe3- 732 requirements-01.txt, July 2001 734 [PWE3FW] Prayson Pate, et al., Internet draft, Framework for 735 Pseudo Wire Emulation Edge-to-Edge (PWE3) 737 [Q922] ITU-T Recommendation Q.922, ISDN Data Link Layer 738 Specification for Frame Mode Bearer Services, ITU, 739 Geneva, 1992. 741 [Q933] ITU-T Recommendation Q.933, ISDN Signaling Specification 742 for Frame Mode Bearer Services, Geneva, October 1995. 744 [RFC3032] E. Rosen, et al., RFC 3032 MPLS Label Stack encoding, 745 January 2001. 747 [RFC3031] E. Rosen, et al., RFC 3031 MPLS Architecture, January 748 2001. 750 [RFC2615] A. G. Malis, RFC 2615 PPP over SONET/SDH, June 1999. 752 [X36] ITU-T Recommendation X.36, Interface between a DTE 753 and DCE for public data networks providing frame relay, 754 Geneva, 2000 756 [X76] ITU-T Recommendation X.76, Network-to-network interface 757 between public data networks providing frame relay 758 services, Geneva, 2000 760 14. Acknowledgements 762 To be completed. 764 15. Author's Addresses 766 Claude Kawa 767 Nortel Networks 768 3500 Carling Ave. 769 Ottawa, Ontario, Canada 770 email: kawa@nortelnetworks.com 772 Andrew G. Malis 773 Vivace Networks, Inc. 774 2730 Orchard Parkway 775 San Jose, CA 95134 776 e-mail: Andy.Malis@vivacenetworks.com 778 Prayson Pate 779 Overture Networks 780 P. O. Box 14864 781 RTP, NC, USA 27709 782 email: prayson.pate@overturenetworks.com 784 Ravi Bhat 785 Amber Networks 786 50 Vanivalas Road 787 Bangalore 560 004 India 788 email: rbhat@nokia.com 790 Nishit Vasavada 791 Amber Networks 792
793 email: nishit@nokia.com