idnits 2.17.1 draft-martini-frame-encap-mpls-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 29 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 296 has weird spacing: '... Two mappi...' == Line 1187 has weird spacing: '...payload to be...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 2002) is 7980 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: 'L2TPv3' is mentioned on line 1169, but not defined == Missing Reference: 'Pn' is mentioned on line 965, but not defined == Unused Reference: 'FRF1' is defined on line 1311, but no explicit reference was found in the text == Unused Reference: 'FRF4' is defined on line 1317, but no explicit reference was found in the text == Unused Reference: 'FRF10' is defined on line 1320, but no explicit reference was found in the text == Unused Reference: 'L2TPV3' is defined on line 1336, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'DIX' -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF13' -- Possible downref: Non-RFC (?) normative reference: ref. 'FRF14' -- Possible downref: Normative reference to a draft: ref. 'LYR' == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'P8021Q' -- Possible downref: Non-RFC (?) normative reference: ref. 'P8023' == Outdated reference: A later version (-08) exists of draft-ietf-pwe3-requirements-01 ** 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. 'Q921' -- 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: 3 errors (**), 0 flaws (~~), 15 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PWE3 Working Group Claude Kawa (Editor) 2 Internet Draft Nortel Networks 4 Expires: December 2002 Andrew G. Malis 5 Vivace Networks, Inc. 7 Luca Martini 8 Nasser El-Aawar 9 Level 3 Communications, LLC. 11 Vinai Sirkay Prayson Pate 12 Vivace Networks, Inc. Overture Networks, Inc. 14 Giles Heron Steve Vogelsang 15 PacketExchange Ltd. Laurel Networks, Inc. 17 Chris Liljenstolpe Dimitri Stratton Vlachos 18 Cable & Wireless Mazu Networks, Inc. 20 Daniel Tappan Kireeti Kompella 21 Eric C. Rosen Juniper Networks 22 Cisco Systems, Inc. 23 Ravi Bhat 24 Nishit Vasavada 25 Nokia 27 June 2002 29 Frame Relay Encapsulation over Pseudo-Wires 30 draft-martini-frame-encap-mpls-01.txt 32 Status of this Memo 34 This document is an Internet-Draft and is in full conformance 35 with all provisions of Section 10 of RFC2026. 37 Internet-Drafts are working documents of the Internet Engineering Task 38 Force (IETF), its areas, and its working groups. Note that other groups 39 may also distribute working documents as Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference material 44 or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 Copyright Notice 53 Copyright(C) The Internet Society (2002). All Rights Reserved. 55 Abstract 57 This document defines frame relay pseudo-wire emulation edge-to-edge. 58 A frame relay pseudo-wire is a mechanism that exists between a 59 provider's edge network nodes and support as faithfully as possible 60 frame relay services over IP and MPLS packet switched network (PSN). 61 Two mapping modes are defined: One-to-one mapping mode characterized 62 by a one to one relationship between a frame relay VC and a pair 63 of MPLS LSPs is defined for MPLS PSN. The other mode is known as port 64 mode or many-to-one mapping mode and is defined for MPLS PSN and IP 65 PSN with L2TPv3. 67 Table of Contents 69 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . 4 72 4. Requirements for Frame Relay Over Pseudo-wires. . . . . . . . 5 73 5. Reference model and PWE3 protocol layering . . . . . . . . . . 6 74 6. General encapsulation for the two mapping modes . . . . . . 8 75 7. Frame Relay over MPLS PSN for the one-to-one mapping mode. . .10 76 8. FR SVC and SPVC Signalling between PEs. . . . . . . . . . . . 19 77 9. FR PVC provisioning. . . . . . . . . . . . . . . . . . . . . . 19 78 10. Frame relay port mode . . . . . . . .. . . . . . . . . . . . 19 79 11. Frame relay service over pseudo-wires. . . . . . . . . . . . .24 80 12. IANA considerations. . . . . . . . . . . . . . . . . . . . . .26 81 13. Security Considerations. . . . . . . . . . . . . . . . . . . 26 82 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 83 15. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 28 85 Conventions used in this document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119. 91 1. Introduction 93 This draft combines draft-martini-frame-encap-mpls-00.txt and draft- 94 kamapabhava-fr-pwe3-01.txt previously submitted to the PWE3 working 95 group and replaces both of these drafts. 97 This document defines frame relay pseudo-wire emulation edge-to-edge. 98 A frame relay pseudo-wire (PW) is a mechanism that exists between 99 provider's edge network nodes (PEs) and supports as faithfully as 100 possible frame relay services over IP and MPLS packet switched 101 network (PSN) using MPLS LSP [RFC3031, RFC3032] and L2TPv3 [L2TPv3] 102 tunnels for multiplexing purposes. L2TPv3 is used only with IP PSN in 103 this document. 105 The main functions required to support frame relay PW by a PE 106 include: 108 - Encapsulation of frame relay specific information in a suitable 109 frame relay over pseudo wire (FRoPW) packet, 111 - Transfer of a FRoPW packet across a PSN for delivery to a peer 112 PE, 114 - Extraction of frame relay specific information from a FRoPW 115 packet by the remote edge node, 117 - Generation of native frame relay frames for forwarding across an 118 egress port of the remote edge node, 120 - Execution of any other operations required to support frame 121 relay service. 123 Two mapping modes are defined between FR VCs and FR PWs: The first 124 one is called "one-to-one" mapping. because there is a one-to-one 125 correspondence between a FR VC and a pair of unidirectional PWs. The 126 second mapping is called "many-to-one" mapping or "port mode" because 127 multiple FR VCs assigned to a port are mapped to one pair of PWs. 128 One-to-one mapping mode is defined for MPLS PSN only and port mode is 129 defined for MPLS LSP and IP PSN with L2TPv3. 131 The main structure of this document is as follows: Section 4 lists 132 some important frame relay requirements to be met in a PWE3 133 environment. Section 5 described PWE3 reference model and PWE3 134 protocol layers described in [LYR]. Section 6 describes the generic 135 frame relay over pseudo-wire (FRoPW) packet format. Section 7 136 specifies frame relay over MPLS PSN for the one-to-one mapping 137 Section 8 just indicates that FR SVC and SPVC are not supported in 138 this document. Section 9 is about FR PVC provisioning. Section 10 139 describes FR port mode for MPLS PSN and IP PSN with L2TPv3. Finally, 140 Section 11 discusses the meaning of providing frame relay services in 141 the native and PWE3 environments and how faithfully/perfectly FR 142 service should be provided. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in RFC 2119. Below are 149 the definitions for the terms used throughout the document. 151 Backward direction: In frame relay it is the direction opposite to 152 the direction taken by a frame being forwarded 153 (see also forward direction). 155 Customer Edge: A Customer Edge (CE) is a device attached to a 156 provider's PSN and where the emulated (frame 157 relay) service originates and terminates. 159 Forward direction: In frame relay the reference used to 160 determine whether the direction of the traffic 161 is the forward or backward direction is the 162 frame being forwarded. The forward direction is 163 the direction taken by the frame being 164 forwarded. 166 Packet Switched Network: 167 A Packet Switched Network (PSN) is a network 168 using packets as the unit of switching. 170 Provider Edge: A Provider Edge (PE) is a device that provides 171 PWE3 to a CE. 173 Pseudo-Wire: A Pseudo Wire (PW) is a mechanism between two 174 PEs that carries the essential elements of an 175 emulated service (e.g. frame relay service) 176 over a PSN to provide the service to the CEs. 178 Pseudo-Wire Emulation Edge to Edge: 179 Pseudo-Wire Emulation Edge to Edge (PWE3) is 180 the technique that emulates the essential 181 characteristics of a service (e.g. frame relay) 182 over a PSN. 184 Pseudo-Wire PDU: A Pseudo Wire PDU is a PDU sent on the PW that 185 contains all of the data and control 186 information necessary to provide the desired 187 service. Frame relay pseudo-wire PDU is also 188 called Frame Relay over PW (FRoPW) packet. 190 Tunnel: A Tunnel is a mechanism to carry PW PDUs 191 between PEs in a transparent way to the PSN 192 core. 194 3. Acronyms and Abbreviations 196 Bc Committed burst size 197 Be Excess burst size 198 BECN Backward Explicit Congestion Notification 199 CE Customer Edge 200 CIR Committed Information Rate 201 C/R Command/Response 202 DE Discard Eligibility 203 DLCI Data Link Connection identifier 204 FCS Frame Check Sequence 205 FECN Forward Explicit Congestion Notification 206 FR Frame Relay 207 FRoPW Frame Relay over Pseudo Wire 208 L2TP Layer 2 Tunneling Protocol 209 FRS Frame Relay Service 210 LSP Label Switched Path 211 LSR Label Switching Router 212 MPLS Multiprotocol Label Switching 213 MTU Maximum Transfer Unit 214 NNI Network-Network Interface 215 PE Provider Edge 216 PSN Packet Switched Network 217 PW Pseudo-Wire 218 PWE3 Pseudo-Wire Emulation Edge to Edge 219 POS Packet over Sonet/SDH 220 PVC Permanent Virtual Circuit 221 QoS Quality of Service 222 SLA Service Level Agreement 223 SPVC Switched/Soft permanent virtual circuit 224 SVC Switched Virtual Circuit 225 UNI User-Network Interface 226 VC Virtual Circuit 228 4. Requirements for Frame Relay Over Pseudo-Wires 230 The section lists the main frame relay pseudo-wire requirements to 231 be met by a PE: 233 1. Frame Length: Should transport variable length FR frames 234 without being limited by the PSN MTU. 236 2. Bidirectional traffic: Must support bidirectional traffic. 238 3. Frame ordering: Must preserve FR frames order. 240 4. Transmission errors: Must detect (detectable) transmission 241 errors, 243 5. Control bits: Must support the transport of FR Discard 244 Eligibility (DE), Forward Explicit Congestion Notification 245 (FECN), Backward Explicit Congestion Notification (BECN) and 246 Command/Response (C/R) bits [Q922]. 248 6. PVC Status Maintenance: Must support the mapping and transport 249 of frame relay PVC status indications defined in Q.933 Annex A 250 [Q933]. The support of PVC link integrity check should be 251 provided. Note PVC status maintenance will be addressed in 252 another IETF draft. 254 7. Traffic Management: Should be able to map the following FR 255 traffic management parameters to PWs and tunnel traffic 256 parameters: 258 a) CIR (Committed Information Rate) or throughput, 259 b) Bc (Committed burst size), 260 c) Be (Excess Burst Size), 261 e) Maximum frame size. 263 8. Frame Priority and QoS: Should support the ability to map FR 264 transfer and discard priorities or QoS service classes defined 265 in [X36, X76] to appropriately engineered PWs and PSN tunnels. 267 9. Frame relay VC type: Must support PVC, support of SVC and SPVC 268 is optional. 270 5. Reference model and PWE3 protocol layering 272 5.1. Reference model 274 Figure 1 shows PWE3 reference model with additional frame relay 275 concepts. More details on the reference model can be found in 276 [PWE3REQ, PWE3FW]. 278 |<------ Pseudo-wires ------>| 279 | | 280 | |<-- PSN Tunnel -->| | 281 V V V V 282 FR +----+ +----+ FR 283 UNI or NNI | | PW1 | | UNI or NNI 284 +-----+ | | |==================| | | +-----+ 285 | |----------| PE1| | PE2|----------| | 286 | CE1 | | | | | | | | CE2 | 287 | |----------| | PW2 | |----------| | 288 +-----+ | | |==================| | | +-----+ 289 ^ +----+ +----+ ^ 290 | | 291 |<------------- Emulated Service ----------------->| 292 (i.e. FR PVC, SVC or SPVC) 294 Figure 1 - PWE3 Reference Model 296 Two mapping modes are defined between FR VCs and pseudo-wires: 298 - The first one is called "one-to-one" mapping. With one-to-one 299 mapping, for each frame relay VC, a pair of pseudo-wires (one 300 for each direction of the traffic) is established between a 301 pair of PEs. 303 - The second mapping is called "many-to-one" mapping or "port 304 mode": With this mapping multiple frame relay VCs related to a 305 port are assigned to one pair of pseudo-wires. 307 As specified later in this document, the encapsulation of frame 308 relay information is slightly different between the two mapping 309 modes. 311 5.2. Frame relay over PW and PWE3 protocol layering 313 This document supports MPLS PSN and IP PSN. With IP PSN, L2TPV3 314 [L2TPv3] is used for multiplexing purposes of a number of FR VCs 315 into one L2TPv3 tunnel. In addition, the one- to-one mapping mode 316 applies to frame relay over MPLS PSN only and the many-to-one 317 mapping mode applies to both frame relay over MPLS PSN and IP PSN 318 with L2TPv3. In terms of PWE3 protocol layering defined in [LYR], 319 we have the following two protocol stacks: 321 The first protocol stack is for the one-to-one mapping mode. It is 322 adapted from [LYR Figure 11]: 324 +---------------------+ 325 | Payload | 326 /=====================\ 327 H Payload Convergence H-----------------+ 328 H---------------------H | 329 H Timing (NIL) H | 330 H---------------------H | 331 H Sequencing H------------------------------------+ 332 \=====================/ | | 333 | PW Demultiplexer |---+ | | 334 +---------------------+ | | | 335 | PSN Convergence |-----------------------+----+----+ | 336 +---------------------+ | | | | | | 337 | MPLS PSN |-+ | v v v v v 338 +---------------------+ | | +--------------------------------+ 339 | MAC/Data-link | | | | Flags |Frag| Len |Seq # | 340 +---------------------+ | | +--------------------------------+ 341 | Physical | | +->| Inner MPLS LSP/PW Label | 342 +---------------------+ | +--------------------------------+ 343 +--->| Outer MPLS LSP Label | 344 +--------------------------------+ 345 Control words 347 Figure 2- FR PWE3 over MPLS PSN for the one-to-one mapping mode 349 Notes: 1-For the one-to-one mapping mode only MPLS PSN is used in 350 this document and MPLS LSP labels are used for PW 351 demultiplexer. 353 2-The payload is a FR frame information field only with 354 bit/byte stuffing undone (byte stuffing is used only over 355 Sonet/SDH transmission facilities [FRF14]). 357 3-Control words carrying different protocol control 358 information are used. They are described in subsequent 359 sections. 361 The second protocol stack is for the many-to-one mapping or port 362 mode. It is adapted from [LYR Figure 10]: 364 +---------------------+ +-------------------------+ 365 | Payload |------------>|FR frame less flags & FCS| 366 /=====================\ +-------------------------+ 367 H Payload Convergence H------------>| Nil | 368 H---------------------H +-------------------------+ 369 H Timing H------------>| Nil | 370 H---------------------H +------------+------------+ 371 H Sequencing H------------>| Pseudo-wire protocol | 372 \=====================/ +------------+------------+ 373 | PW Demultiplexer |------------>| L2TPv3 | MPLS | 374 +---------------------+ +------------+------------+ 375 | PSN Convergence |------------>| Nil | Nil | 376 +---------------------+ +------------+------------+ 377 | PSN |------------>| IP | MPLS | 378 +---------------------+ +------------+------------+ 379 | MAC/Data-link |------------>| MAC/Data-link | 380 +---------------------+ +-------------------------+ 381 | Physical |------------>| Physical | 382 +---------------------+ +-------------------------+ 384 Figure 3 - FR PWE3 protocol layers for port mode with IP and MPLS PSNS 386 Notes: 1-There are actually two instances of the protocol stack: 387 One for IP PSN and the other for MPLS PSN. 389 2-With IP PSN, L2TPv3 is used as PW demultiplexer. 391 3-With MPLS PSN, MPLS is used as PW demultiplexer. 393 4-The others PW demultiplexers listed in [LYR]: GRE, IPsec 394 and MPLS are not supported. It has to be decided whether 395 we need to support them or not. 397 5-The payload is a complete FR frame with the exception of 398 HDLC opening and closing flags and the Frame check 399 sequence (FCS) and with bit/byte stuffing undone. 401 6-Sequencing is provided by the PW protocol defined in this 402 document. 404 6. General encapsulation for the two mapping modes 406 The general frame relay over pseudo-wires (FRoPW) packet format 407 for carrying frame relay information (user's payload and frame 408 relay control information) between two PEs is shown in Figure 4. 410 +-------------------------------+ 411 | | 412 | PSN Delivery Header | 413 +-------------------------------+ 414 | | 415 | PW Identifier header | 416 +-------------------------------+ 417 | FRoPW Header | 418 | | 419 +-------------------------------+ 420 | | 421 | Payload | 422 | and a Pad (if needed) | 423 +-------------------------------+ 425 Figure 4 - General format of FRoPW packet 427 1. PSN delivery header is a header specific to the PSN, it is 428 discussed in the following sub-sections addressing each type of 429 PSN. 431 2. PW identifier header contains an identifier for multiplexing 432 PWs within a PSN tunnel. 434 3. FRoPW header contains protocol control information for 435 providing a frame relay service. Its structure is provided in 436 the following sections addressing each mapping mode. 438 4. The contents of the payload field depends on the mapping mode. 439 The details are provided in the following sections addressing 440 each mapping mode. 442 The Pad is used to bring the size of a FRoPW 443 packet to the minimum size required by the link layer when IEEE 444 802.3/Ethernet [P8023, DIX] segment is used. 446 Motivation for padding a FRoPW packet: 448 A FRoPW packet is encapsulated in the payload field of the 449 underlying link layer protocol frame. When IEEE 802.3 [P8023] or 450 DIX Ethernet [DIX] is used as the link layer between a PE and the 451 PSN core, there is a minimum frame size to meet and 452 correspondingly a the link layer frame must have a minimum data 453 field (payload) size to be valid. If the client data encapsulated 454 in the data field of an Ethernet/802.3 frame has a smaller size 455 than the minimum frame size, it has to be padded. 457 In the case of DIX Ethernet it is up to the client (e.g. the 458 protocol specified in this document) to pad its data to ensure 459 that the minimum length is met. 461 In the case of IEEE 802.3 [P8023] padding will be always performed 462 according to 802.3 specification regardless of the interpretation 463 of the Length/Type field. So if an IEEE 802.3 implementation pads 464 a data field, the receiver will not be able to determine whether 465 the frame contains padding characters or only client data when the 466 Type/Length field is used with the Type interpretation. With the 467 length interpretation there is no problem because the Length/Type 468 field will contain the length of the client data. 470 The protocol defined in this document has a padding capability for 471 two main reasons: When DIX Ethernet is used, to meet its 472 requirements and overcome its lack of padding capabilities. When 473 IEEE 802.3 is used to avoid that padding be done by 802.3 474 implementation when the Type/Length Field is used with the Type 475 interpretation. 477 A FR over PW implementation must ensure that FRoPW packets meet 478 IEEE 802.3/Ethernet minimum data field size. The various minimum 479 sizes in bytes are as follows: 481 IEEE 802.3/Ethernet minimum frame and data field sizes: 483 IEEE 802.3 DIX Ethernet 485 Min. frame size 64 64 487 Min. data field size 46 (untagged frame) 46 488 42 (VLAN tagged frame) - 490 In the case of IEEE 802.3 there are two minimum data field sizes: 491 One minimum size when the frame does not have a VLAN QTag prefix 492 [P8021Q] and when when it has one. 494 7. Frame Relay over MPLS PSN for the one-to-one mapping mode 496 7.1. MPLS tunnel and VC LSPs 498 MPLS label switched paths (LSPs) called "Tunnel LSPs" are used 499 between PEs and within MPLS PSN core for forwarding purposes of 500 FRoPW packets. A tunnel LSP corresponds to a "PSN tunnel" of 501 Figure 1. 503 Several "Virtual Circuit LSPs" (VC LSPs) may be nested inside one 504 Tunnel LSP. Each VC LSP carries the traffic of a frame relay VC in 505 one direction. Since LSPs are unidirectional, a pair of VC LSPs 506 and corresponding tunnel LSPs carrying traffic in opposite 507 directions will be required. 509 In PE1 to PE2 direction a tunnel LSP is used for forwarding FRoPW 510 packets from PE1 to PE2,the corresponding LSP label is not related 511 to any frame relay VC. When PE1 has to forward a FRoPW packet to 512 PE2, it first pushes a VC label on its label stack, and then 513 pushes on a tunnel LSP label. The VC label must be always at the 514 bottom of the label stack. The VC label is not visible in the core 515 PSN, only the tunnel LSP label and possibly other labels used in 516 the core PSN for forwarding purposes until the FRoPW packet 517 reaches PE2. While the FRoPW packet travels across the MPLS 518 network, additional labels may be pushed on (and then popped off) 519 as needed. When PE2 receives a FRoPW packet, it forwards the 520 packet to the local CE based on the LSP VC label. The processing 521 is similar in the opposite direction from PE2 to PE1 with the 522 corresponding LSP used in the PE2 to PE1 forwarding direction. 524 7.2. Relationship between FR VCs and MPLS VC LSPs 526 Frame Relay VCs are considered to be bidirectional objects mainly 527 because of the way they are created and identified. A single frame 528 relay identifier (DLCI) refers to the two directions of a frame 529 relay VC and frame relay signalling establishes the two directions 530 simultaneously with the same message flows. In general each 531 direction of a frame relay VC may have different traffic and QoS 532 characteristics. The resource management of a frame relay 533 implementation treats each direction separately and independently. 534 MPLS LSPs, on the other hand LSPs are unidirectional and are 535 established separately. Therefore for each FR VC there will be, in 536 general, two VC LSPs such that each one will be assigned to carry 537 the traffic in a different direction from the other. 539 During the creation of a frame relay VC, a pair of VC LSPs will 540 have to be established between two PEs. For one end-to-end frame 541 relay VC two VC LSPs exist: One VC LSP to transport the traffic 542 from PE1 to PE2 and the other to transport the traffic in the 543 opposite direction. In the frame relay domain, a DLCI identifies a 544 frame relay VC and in the MPLS domain, VC LSP labels with possible 545 different values identify each VC LSP. This mapping between a FR 546 VC and a pair of MPLS LSPs corresponds to the one-to-one mapping 547 described in Section 5. 549 7.3. One-to-one mapping and FRoPW packet format over MPLS PSN 551 For the one-to-one mapping mode for frame relay over MPLS PSN, the 552 FRoPW packet format is shown in Figure 5. 554 +-------------------------------+ 555 | Tunnel LSP label(s) | n words (1 word per label) 556 +-------------------------------+ 557 | VC LSP label | 1 word 558 +-------------------------------+ 559 | FRoPW Header | 560 | (See Figure 6) | 1 word 561 +-------------------------------+ 562 | Payload | 563 |(Q.922 frame information field)| N bytes 564 | and a Pad (if needed) | 565 +-------------------------------+ 567 Figure 5 - FR over MPLS packet format for the One-to-one mapping 569 Tunnel LSP label(s): 570 The Tunnel LSP label(s) corresponds to the PSN delivery header 571 of Figure 4. The label(s) is/are used by MPLS PSN nodes to 572 forward a FRoPW packet from one PE to the other. 574 VC LSP Label: 575 The VC LSP label identifies one PW (i.e. one LSP) assigned to a 576 FR VC in one direction. It corresponds to the PW identifier 577 header of Figure 4. Together the Tunnel LSP label(s) and VC 578 LSP label form an MPLS label stack [RFC3032]. 580 FRoPW header: 581 FRoPW header contains protocol control information. Its 582 structure is shown in Figure 6. 584 The above three headers were referred as "control words" in Figure 2. 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Res |F|B|D|C|Res| Length | Sequence Number | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Figure 6 - FRoPW header structure for one-to-one mapping mode 594 The meaning of the fields of FRoPW packet header (Figure 6) is as 595 follows: 597 Res (bits 0 to 3): 598 Reserved bits. They are set to zero on transmission and 599 ignored on reception. 601 F (bit 4): 602 FR FECN (Forward Explicit Congestion Notification) bit 603 [Q922]. 605 B (bit 5): 606 FR BECN (Backward Explicit Congestion Notification) bit 607 [Q.922]. 609 D (bit 6): 610 FR DE bit indicates the discard eligibility [Q922]. 612 C (bit 7) 613 FR frame C/R (command/response) bit [Q922]. 615 Res (bits 8 and 9): 616 Reserved bits. They are set to zero on transmission and 617 ignored on reception. 619 Length (bits 10 to 15): 620 The length field is used for padding the payload field of 621 short FRoPW packets when IEEE 802.3/Ethernet [P8023, DIX] 622 segment is used between a PE and the PSN. When padding of a 623 short FRoPW packet is performed the length field must be set 624 to the FRoPW packet size (Figure 5) specified in bytes. 625 Otherwise the length field must be set to zero. The value of 626 the length field, if non- zero, is used to remove any 627 padding. 629 Sequence number (Bit 16 to 31): 630 If it is not used, it is set to zero by the sender and 631 ignored by the receiver. Otherwise it specifies the sequence 632 number of a FRoPW packet. A circular list of sequence 633 numbers is used. A sequence number takes a value from 1 to 634 65535 (2**16-1). Arithmetic modulo 2**16 is performed to 635 generate a new sequence number. The value of zero indicates 636 that the sequence number field is not used. 638 Payload and Pad: 639 The payload field corresponds to Q.922 frame relay frame 640 information field with bit/byte stuffing removed. The 641 default for the number of bytes in a Q.922 information field 642 is 262 bytes. Recommendation Q.922 recommends to support a 643 size of a least 1600 bytes [Q922 clause A.5.1]. The maximum 644 length of the payload field should be agreed by the two PEs 645 when the VC LSP is established. 647 The Pad consists of a number of characters (including zero 648 character) to bring the FRoPW packet size to the minimum 649 size required by the link layer protocol, in particular IEEE 650 802.3/Ethernet (cf.section 6 for the motivation for padding. 651 Any 8-bit character with a decimal value from 0 to 255 may 652 be used as a padding character. 654 7.4. FRoPW packet processing 656 7.4.1. Generation of FRoPW packets 658 The generation process of a FRoPW packet is initiated when a PE 659 receives a frame relay frame from one of its frame relay UNI or 660 NNI. The PE takes the following actions (not necessarily in the 661 order shown): 663 - It generates the following fields of FRoPW header from the 664 corresponding fields of the frame relay frame as follows: 666 - Command/Response (C/R or C) bit: The C bit is copied 667 unchanged in the FRoPW header. 669 - Discard eligibility indicator (DE or D): The D bit is 670 set as follows in the FRoPW header: This bit, if used, 671 is set to 1 to indicate a request that a frame should 672 be discarded in preference to other frames in a 673 congestion situation. 675 Setting of this bit by a PE is optional. However, no PE 676 shall clear this bit (set it to 0 if it was received 677 with the value of 1). A PE that does not provide 678 discard eligibility notification shall pass this bit 679 unchanged. Networks are not constrained to discard only 680 frames with D = 1 in the presence of congestion [Q922 681 Annex A]. 683 - Forward explicit congestion notification (FECN or F 684 bit): FECN may be set by a congested PE to notify the 685 user that congestion avoidance procedures should be 686 initiated where applicable for traffic in the direction 687 of the FRoPW packet carrying the FECN [Q922]. 689 This bit is set to 1 to indicate to the destination 690 that the frames it receives have encountered congested 691 resources. This bit may be used by a destination to 692 adjust its transmission rate. 694 While setting this bit by a PE is optional, no PE shall 695 clear this bit (set it to 0 if it was received with the 696 value of 1). PEs that do not provide FECN shall pass 697 this bit unchanged. 699 - Backward explicit congestion notification (BECN or B 700 bit): BECN follows the same processing rules as FECN, 701 except that it applies to the opposite direction 702 [Q922]. 704 - Length: See the following sub-section "Processing of 705 the Length field by the sender". 707 - Sequence number: See the sub-section "Processing of the 708 Sequence number field by the sender". 710 - Payload and pad: 711 The payload and pad field of the FRoPW packet is the 712 contents of ITU-T Recommendation Q.922 [Q922] frame 713 relay frame information field stripped from any bit or 714 byte stuffing. The payload field may also have padding 715 characters appended to its right as specified in the 716 following sub-section on "Processing of the length 717 field by the sender". 719 Additional processing is performed by the lower protocol 720 layers in order to transmit the FroPW packet to its next 721 destination. 723 7.4.1.1. Processing of the length field by the sender 725 The procedure described here is used to determine whether 726 padding is required or not. 728 Let: 729 - Length_FRoPW_packet be the length of a FRoPW packet 730 shown in Figure 5, 732 length_field be the contents of the length field of 733 the FRoPW header, 735 - Min_data_field be the minimum size of the link layer 736 data field (46 or 42 bytes for 802.3/DIX Ethernet 737 depending on whether the frame is untagged or not 738 (See section 6 for the discussion), 740 - Padding_length be the length of the pad to be added 741 to the payload. 743 The padding procedure is as follows: 745 If the link layer protocol does not have a minimum 746 length requirement then Length_field is set to zero 747 and no padding is required. 749 Else if Length_FRoPW_packet >= Min_data_field then 750 padding is not required; set Length_field to 751 zero. 753 Else padding is required and the following 754 performed: 756 Padding_length = Min_data_field - 757 Length_FRoPW_packet; 759 Append Padding-length characters at the end of 760 the FRoPW payload field; 762 Length_field = length_FRoPW_packet. 764 End of the padding procedure. 766 7.4.1.2. Processing of the sequence number field by the sender 768 The sequence number field is set according to whether the 769 sequence number is used or not. 771 If the PE supports the sequence number capability then the 772 following procedure to number FRoPW packets is used: 774 - The initial packet transmitted on the frame relay PW 775 must use sequence number 1. 777 - For a subsequent packet, the sequence number 778 corresponds to the sequence number of the preceding 779 packet incremented by 1 modulo 2**16. 781 - When the sequence number reaches the maximum value 782 (65535) the next sequence number wrap to 1 (the value of 783 0 is skipped). 785 If the PE does not support sequence number processing, 786 then the sequence number field must be set to 0. 788 7.4.2. Reception of FRoPW packets 790 When a PE receives a FRoPW packet, it processes the different 791 fields of the FRoPW header in order to synthesize a new frame 792 relay frame for transmission to a CE on a FR UNI or NNI. The PE 793 performs the following actions (not necessarily in the order 794 shown): 796 - It generates the following FR frame header fields from the 797 corresponding fields of the FRoPW packet as follows: 799 - C/R bit is copied unchanged in the frame relay 800 header. 802 - D bit is copied as follows into the frame relay 803 header DE bit: If it was set to one in the incoming 804 FRoPW packet, it must be copied unchanged in the FR 805 frame header or, depending on the traffic policing 806 performed by the PE and it state of congestion, the 807 FRoPW packet may be dropped. 809 Otherwise if the D bit was set to zero, it may be set 810 to zero or one, depending on the traffic policing 811 performed by the PE device. Setting of this bit by a 812 PE is optional. 814 - The F bit is copied as follows in the frame relay 815 header FECN bit: If it was set to one in the incoming 816 FRoPW packet, it must be copied unchanged in the 817 frame relay header. Otherwise if it was set to zero, 818 it may be set to zero or one, depending on the 819 congestion state of the PE device in the forward 820 direction. Setting this bit by a PE is optional, if 821 the PE does not support FECN, it shall pass this bit 822 unchanged. 824 - BECN follows the same processing rules as FECN, 825 except that it applies to the opposite direction. 827 - It processes the length and sequence field, the 828 details are in the subsequent sub-sections. 830 - It generates the frame relay information field from 831 the contents of the FRoPW packet payload after 832 removing any padding character and retrieves the 833 appropriate DLCI. 835 Once the above fields of a FR frame have been generated, the FCS 836 has to be computed, HDLC flags have to be added and any bit or 837 byte stuffing has been performed. The FR frame is queued for 838 transmission on the selected frame relay UNI or NNI. 840 7.4.2.1. Checking the sequence number by the receiving PE 842 If the receiving PE does not support sequence number 843 processing, then it will skip the processing of the sequence 844 number field. 846 If the receiving PE supports packet sequencing capability, 847 when a FRoPW packet is received the sequence number is 848 processed as follows: 850 - If the sequence number of the packet is 0, then the packet 851 passes the sequence number check. Note a sequence number 852 equal to 0 means that the sender does not support the use 853 of sequence number. 855 - Otherwise if the packet sequence number >= the expected 856 sequence number and the packet sequence number - the 857 expected sequence number < 32768, then the packet is in 858 order. 860 - Otherwise if the packet sequence number < the expected 861 sequence number and the expected sequence number - the 862 packet sequence number >= 32768, then the packet is in 863 order. 865 - Otherwise the packet is out of order. 867 If the packet is in order, then it passes the sequence 868 number check and the expected sequence number is set as per 869 the following assignment: 871 expected_sequence_number := packet_sequence_number + 1 872 mod 2**16. If (expected_sequence_number = 0) then 873 expected_sequence_number := 1. 875 FRoPW packets which are received out of order are silently 876 discarded. As an option, a PE may buffer out of order FRoPW 877 packets to re-order and deliver them in order. 879 Re-ordering FRoPW packets is an implementation option but 880 requires that the sender numbers FRoPW packets. 882 7.4.2.2. Processing of the length field by the receiver 884 Any padding character, if present, in the payload field of a 885 FRoPW packet received must be removed before forwarding the 886 data to the next destination. 888 The procedure described here is used to remove padding 889 characters. 891 Let: 892 - Length_FRoPW_packet be the length of a FRoPW packet 893 received as shown in Figure 5, 895 length_field be the contents of the length field of 896 the FRoPW header of the packet received, 898 - Padding_length be the length of the pad to be removed 899 from the end of the payload field. 901 Padding removal procedure: 903 If Length_field is set to zero then 904 there is no padding character in the payload field 905 only user's data. 907 Else padding characters are included and their length is 908 computed as follows: 910 Padding_length = Length_FRoPW_packet - Length_field; 912 Remove Padding-length characters from the end of the 913 FRoPW payload field. 915 End of the padding removal procedure. 917 7.5. Handling of error conditions 919 If a PE receives a FRoPW packet with errors, it shall discard it 920 silently. 922 8. FR SVC and SPVC Signalling between PEs 924 Not supported in this document. 926 9. FR PVC provisioning 928 Provisioning of FR PVCs requires the following actions: The PEs and 929 CEs are configured independently for each FR UNI or NNI PVC segments. 930 Some of the configuration parameters may include: 932 - Outgoing and incoming throughputs (CIR), 933 - Outgoing and incoming committed burst sizes (Bc), 934 � - Outgoing and incoming excess burst sizes (Be), 935 - Outgoing and incoming maximum frame lengths, 936 - The DLCI assigned to the FR PVC locally, 937 - If used, FR transfer and discard priority class or FR service 938 class [X.36, X76] assigned to the FR VC. 940 To complete the FR VC, a PW (i.e. a pair VC LSP) is established 941 between the two PEs. Establishment of FR PW will be addressed in the 942 future. 944 To check the status of the FR PW at the remote PE, a PE 945 execute a PVC maintenance protocol (analogous to Q.933 Annex A PVC 946 management procedure [Q933, FRF2] to exchange PVC status information 947 and for "keep-alive" purposes. The PVC maintenance protocol will be 948 addressed in the future. 950 10. Frame relay port mode 952 10.1. General 954 Frame relay port mode or many-to-one mapping is an optional 955 capability. It applies to both MPLS and L2TPv3 pseudo-wires. 956 Figure 8 illustrates the concept of frame relay port mode. 958 +------+ +-------+ 959 | FR | | FR | 960 |device| FR UNI/NNI | device| 961 | [P1]------------------------[P2] | 962 | | carrying n FR VC | | 963 +------+ | +-------+ 964 | 965 [Pn]: A port | 966 | (a) FR interface between two 967 | FR devices 968 | 969 | 970 V 971 |<---------------------------->| 972 | | 973 +----+ +----+ 974 +------+ | | One PW pair | | +------+ 975 | | | |==================| | | | 976 | FR | FR | PE1| carrying n FR VC | PE2| FR | FR | 977 |device|----------| | | |---------|device| 978 | CE1 | UNI/NNI | | | | UNI/NNI | CE2 | 979 +------+ +----+ +----+ +------+ 980 | | 981 |<----------------------------------------------->| 982 n FR VC 984 (b) Pseudo-wires replacing the FR interface 986 Figure 7 - Concept of frame relay port-to-port mode 988 Figure 7 (a) shows two frame relay devices physically connected 989 with a frame relay UNI or NNI. Between their two ports P1 and P2, 990 n frame relay VCs are configured. Figure 7 (b) shows the 991 replacement of the physical frame relay interface with a pair of 992 PEs and a pair of PWs (one PW for each traffic direction between 993 PE1 and PE2). A PW may be an MPLS VC LSP or a L2TPv3 tunnel. The 994 interface between a FR device and a PE is either a FR UNI or NNI. 995 The set of n FR VCs between the two FR ports P1 and P2 (cf. Figure 996 7 (a)) are mapped now to one pair of PWs, hence with port mode we 997 have many-to-one mapping between FR VCs and a PW. 999 FR VCs are not visible individually to a PE, there is no 1000 configuration of individual FR VC in a PE. A PE processes the set 1001 of FR VCs assigned to a port as an aggregate. FR traffic and QoS 1002 parameters listed in Section 9 may be assigned to the aggregate 1003 traffic flowing on an interface between a CE and a PE and not to 1004 individual FR VC and policing may be performed on the aggregate. 1006 FR port mode provides transport between two PEs of a complete FR 1007 frame excluding the opening and closing flags and the Frame check 1008 sequence (FCS) and with bit/byte stuffing undone (see Figure 8) 1009 For more information, on FR frame format the reader should 1010 consult [Q922, Q921]. 1012 bit 8 7 6 5 4 3 2 1 bit 8 7 6 5 4 3 2 1 1013 +-------------------------------+ +-------------------------------+ 1014 | Upper DLCI |C/R| 0 | | Upper DLCI |C/R| 0 | 1015 +------------------------------- +-------------------------------+ 1016 | Lower DLCI | F | B | DE| 1 | | DLCI | F | B | DE| 0 | 1017 +-------------------------------+ +-------------------------------+ 1018 | | | DLCI | 0 | 1019 : Q.922 Information field : +-------------------------------+ 1020 : (i.e. FR payload) : | Lower DLCI | 0 | 1 | 1021 | | +-------------------------------+ 1022 +-------------------------------+ | | 1023 : Q.922 Information field : 1024 : (i.e. FR payload) : 1025 | | 1026 +-------------------------------+ 1028 (a) With 10 bits for the DLCI (b) With 23 bits for the DLCI 1030 Figure 8 - Fields of the frame relay frame used with port mode 1032 10.2. FRoPW packet format for MPLS port mode 1034 When MPLS PW is used with port mode, the FRoPW packet format is 1035 shown in Figure 9. 1037 +-------------------------------+ 1038 | Tunnel LSP label(s) | n words (1 word per label) 1039 +-------------------------------+ 1040 | VC LSP label | 1 word 1041 +-------------------------------+ 1042 | FRoPW Header | 1043 | | 1 word 1044 +-------------------------------+ 1045 | Payload | 1046 | (See Figure 8) | N bytes 1047 | and a Pad (if needed) | 1048 +-------------------------------+ 1050 Figure 9 - FR over MPLS packet format for the port mode mapping 1052 Tunnel LSP label(s) role is as specified for the one-to-one 1053 mapping. 1055 The VC LSP label identifies one PW (i.e. one LSP) assigned to 1056 one port for a set of FR VCs using that port. There is a pair 1057 of VC LSPs for the two traffic directions. 1059 FRoPW header: FRoPW header contains protocol control 1060 information. Its structure is shown in Figure 10. Frame relay 1061 control bits (F, B, D and C) are not used and are set to zero. 1062 Note it is possible to apply FECN, BECN and DE bits (bits 4, 5 1063 and 6) to the aggregate traffic but this use of the indicators 1064 requires further study. 1066 The use of the length and sequence number fields is the same as 1067 for the one-to-one mapping, with the following exceptions: 1068 There is one sequence number counter for the set of FR VCs and 1069 not one for each individual FR VC. To compute the FRoPW packet 1070 size to determine whether padding is needed or not, the format 1071 of Figure 9 is used. 1073 0 1 2 3 1074 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 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Res |0|0|0|0|Res| Length | Sequence Number | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 Figure 10 - FRoPW header structure for the port mode mapping 1081 The payload field contains a FR frame as shown in Figure 8 1082 extracted from an incoming FR frame received from a CE and 1083 padding characters if needed (see section 6 for the need to 1084 pad). 1086 The two peer PEs must agree on the length of the DLCI field (2 1087 or 4 bytes) and the maximum length of FR frame information 1088 field. 1090 The default for the number of bytes in a Q.922 information 1091 field is 262 bytes. Recommendation Q.922 recommends to support 1092 a size of a least 1600 bytes [Q922 clause A.5.1]. 1094 10.3. FRoPW packet format for L2TPv3 port mode 1096 When L2TPv3 PW is used with port mode, the FRoPW packet format 1097 is shown in Figure 11. This format is imported from [L2TPv3 1098 Figure 3.2.2] and is very similar to FRoPW general packet 1099 format of Figure 4. 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | PSN Delivery Header | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | L2TP Tunnel Header | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | L2-Specific Sublayer | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | Tunneled L2 Frame (See Figure 9) | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 Figure 11 - FR over L2TPv3 packet format for the port mode mapping 1113 PSN delivery header: 1114 The PSN delivery header serves the same role as the PSN 1115 delivery header of Figure 4. When the PSN is an IP network, 1116 the PSN delivery header is an IP v4 or v6 datagram header. 1118 L2TP Tunnel header: 1119 L2TP Tunnel header corresponds to the PW identifier header 1120 of Figure 4. There are two formats for L2TP Tunnel header 1121 defined in [L2TPv3]: One when L2TPv3 runs over IP directly 1122 and another one for L2TPv3 over UDP. The two formats are 1123 shown in Figure 12 (a) and (b). The description of the 1124 various fields can be found in [L2TPv3] 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Session ID | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | | 1132 | | 1133 : Cookie (optional, maximum 64 bits) : 1134 : : 1135 | | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 (a) L2TPv3 over IP Tunnel Header 1140 0 1 2 3 1141 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 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 |T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Session ID | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | | 1148 | Cookie (optional, maximum 64 bits)... : 1149 : : 1150 | | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 (b) L2TPv3 over UDP Tunnel Header 1155 Figure 12 - L2TPv3 over IP and UDP Tunnel Header 1157 L2-Specific Sublayer: 1158 L2-Specific Sublayer header shown in Figure 11 is analogous 1159 to FRoPW header of Figure 4. With L2TPv3 the same FRoPW 1160 header defined in Figure 10 for MPLS port mode is used also 1161 with L2TPv3. Although L2TPv3 draft defines a default L2- 1162 Specific Sublayer header, it is advantageous to use the same 1163 FRoPW header structure with the different types of pseudo- 1164 wires and the two mapping modes. 1166 It should be possible to add to the FRoPW header of Figure 1167 10 in the next version of this draft the other fields (P, S 1168 and Offsz) defined in for L2-Specific Sublayer default 1169 header [L2TPv3]. 1171 Tunneled L2 Frame: 1172 The Tunneled L2 Frame of Figure 11 corresponds to the 1173 payload of the general FRoPW format shown in Figure 4. This 1174 field is used to carry a FR frame as shown in Figure 8. 1175 Therefore for both MPLS and L2TPv3 used with FR port mode, 1176 the payload of the FRoPW packet is the same and consists of 1177 a frame relay frame, excluding the flags and the FCS, with 1178 bit/byte stuffing undone. 1180 10.4. FRoPW processing for port mode 1182 When a PE receives a FR frame from a FR device (a CE), it shall 1183 remove the flags, undo bit/byte stuffing and check the FCS 1184 field to determine whether transmission errors occurred or not. 1185 If transmission errors occurred, the frame is discarded. 1186 Otherwise, the FR fields shown in Figure 8 are encapsulated in 1187 a FRoPW packet payload to be forwarded to the remote PE. A PE 1188 shall not modify any of the fields shown in Figure 8, they 1189 shall be forwarded to the remote PE as received from the FR 1190 device. 1192 The processing of the length and sequence number fields is the 1193 same as for the one-to-one mapping, with the following 1194 exceptions mentionned earlier: There is one sequence number 1195 counter for the set of FR VCs and not one for each individual 1196 FR VC. To compute the FRoPW packet size to determine whether 1197 padding is needed or not, the format of Figure 9 is used. 1199 Upon receiving a FRoPW packet, the remote PE shall extract the 1200 payload field, encapsulate the result in a FR frame for 1201 transmission to the local FR device. 1203 11. Frame relay service over pseudo-wires 1205 Frame relay service (FRS) is defined in terms of a number of 1206 attributes in the basic ITU-T Recommendation on frame relay service 1207 [I233]. The most two fundamental aspects of FRS are: 1209 1-The requirement to deliver in order the user's data between 1210 two frame relay service access point, 1212 2-The detection of transmission errors if they are detectable. 1214 Besides the above two service attributes, FRS is defined by a number 1215 of traffic and QoS attributes in a number of ITU-T Recommendations 1216 [I.233, X.36 and X.76] and in the Frame Relay Forum Implementation 1217 Agreement FRF.13 [FRF13]. The following is a partial list 1218 illustrating some of frame relay service attributes: 1220 - Committed information rate 1221 - Excess information rate 1222 - Committed burst size 1223 - Excess burst size 1224 - transit delay 1225 - Frame delivery ratio 1226 - Service availability 1228 FR service providers use FRS attributes to define Service Level 1229 Agreements (SLA). A frame relay SLA are contractual and binding 1230 agreement describing the FRS service providers offer to their 1231 customers. 1233 An important question to ask is: What does it mean to offer a frame 1234 relay service? It means that the two fundamental attributes of FRS 1235 about in-sequence delivery and error detection must be satisfied by 1236 a network providing a frame relsy service. 1238 The other FRS attributes related to QoS and traffic are a matter of 1239 business decision because a multitude of possibilities are available 1240 to service providers. In one extreme, a service provider may offer a 1241 FRS with very stringent characteristics and in the opposite case, it 1242 will not provide any guarantee and provides just a best effort 1243 service. 1245 If we ask the previous question in the context of PWE3, we must first 1246 observe that PWE3 does not require that pseudo-wires emulate 1247 perfectly or faithfully the characteristics of the native service. In 1248 the case of FRS this means that the requirements to deliver in 1249 sequence the user's data and to detect transmission errors may be 1250 relaxed. 1252 For both the one-to-one mapping mode and many-to-one mapping/port 1253 mode, we have the following emulation possibilities with regard to 1254 the two main attributes of FRS: 1256 - In-sequence delivery of user's data: 1258 1-It is possible to emulate perfectly/faithfully this 1259 requirement. If the PSN does not guarantee in sequence 1260 delivery, the PEs should use the sequence number capability 1261 included in FRoPW packets to number the packets and check 1262 whether they are received in sequence or not. 1264 2-Alternatively a service provider may elect to drop the 1265 requirement to deliver in-sequence FRoPW packets. This 1266 document does not recommend this practice unless for a 1267 good reason. 1269 - Detection of transmission errors: 1271 This requirement must be supported. PW layer does not have 1272 the capability to detect transmission errors but rely on the 1273 underlying link layer protocol for transmission error 1274 detection. 1276 About FRS traffic and QoS parameters, there is no strict requirements 1277 to meet. Frame relay traffic and QoS attributes defined in the 1278 relevant FR documents allow service providers to offer various 1279 combinations of traffic and QoS parameters without imposing any 1280 strict performance objective. The same thing should be possible in a 1281 PWE3 network environment and it is not relevant to refer to how 1282 faithful/perfect FRS traffic and QoS attributes are provided because 1283 of the wide spectrum of possibilities. 1285 There is one additional note to add about FR port mode. Since the 1286 individual FR VCs are not visible to the PEs individually but only as 1287 an aggregate, the frame relay service, and in particular, the traffic 1288 and QoS parameters, provided to the CEs does not apply to the 1289 individual FR VCs assigned to a port but to their aggregate. 1291 12. IANA considerations 1293 Not applicable to this document. 1295 13. Security considerations 1297 PWE3 provides no means of protecting the contents or delivery of the 1298 FRoPW packets on behalf of the native service. PWE3 may, however, 1299 leverage security mechanisms provided by the PSN Tunnel Layer. A more 1300 detailed discussion of PW security is give in [LYR]. 1302 14. References 1304 [DIX] Digital, Intel and Xerox, The Ethernet, a local Area 1305 Network Data Link and Physical layer Specifications 1306 versions 1 and 2. 1308 [I233] ITU-T Recommendation I.233.1, ISDN frame relay bearer 1309 service, Geneva, October 1991. 1311 [FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement, 1312 Frame Relay Forum, April 2000. 1314 [FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement, 1315 Frame Relay Forum, April 2002. 1317 [FRF4] FRF.4.1, Frame relay SVC UNI Implementation Agreement, 1318 Frame Relay Forum, January 2000. 1320 [FRF10] FRF.10.1, Frame relay SVC NNI Implementation Agreement, 1321 Frame Relay Forum, January 2000. 1323 [FRF13] FRF.13, Service Level Definition Implementation 1324 Agreement, Frame Relay Forum, August 1998. 1326 [FRF14] FRF.14, Physical layer Implementation Agreement, Frame 1327 Relay Forum, December 1998. 1329 [I233] ITU-T Recommendation I.233, Frame Mode Bearer Services, 1330 ITU, Geneva, 1992. 1332 [LYR] Stewart Bryant, et al.,Protocol Layering in PWE3,draft- 1333 ietf-pwe3-protocol-layer-00.txt, May 2002, work in 1334 progress. 1336 [L2TPV3] M. Townsley, et al., Layer Two Tunneling Protocol 1337 (Version 3) "L2TPv3", draft-ietf-l2tpext-l2tp- 1338 base-02.txt, March 2002, work in progress.. 1340 [P8021Q] IEEE Std 802.1Q, Virtual bridged local area networks. 1342 [P8023] IEEE Std 802.3, Part 3 Carrier sense multiple access with 1343 collision detection (CSMA/CD) access method and physical 1344 layer specifications. 1346 [PWE3REQ] XiPeng Xiao, et al., Internet draft, draft-ietf-pwe3- 1347 requirements-01.txt, work in progress. 1349 [PWE3FW] Prayson Pate, et al., Internet draft, Framework for 1350 Pseudo Wire Emulation Edge-to-Edge (PWE3), work in 1351 progress. 1353 [Q921] ITU-T Recommendation Q.921, ISDN Data Link Layer 1354 Specification, ITU,Geneva, 1997. 1356 [Q922] ITU-T Recommendation Q.922, ISDN Data Link Layer 1357 Specification for Frame Mode Bearer Services, ITU, 1358 Geneva, 1992. 1360 [Q933] ITU-T Recommendation Q.933, ISDN Signaling Specification 1361 for Frame Mode Bearer Services, Geneva, October 1995. 1363 [RFC3032] E. Rosen, et al., RFC 3032 MPLS Label Stack encoding, 1364 January 2001. 1366 [RFC3031] E. Rosen, et al., RFC 3031 MPLS Architecture, January 1367 2001. 1369 [X36] ITU-T Recommendation X.36, Interface between a DTE and 1370 DCE for public data networks providing frame relay, 1371 Geneva, 2000. 1373 [X76] ITU-T Recommendation X.76, Network-to-network interface 1374 between public data networks providing frame relay 1375 services, Geneva,2000. 1377 15. Author's Addresses 1379 Claude Kawa 1380 Nortel Networks 1381 3500 Carling Ave. 1382 Ottawa, Ontario, Canada 1383 email: kawa@nortelnetworks.com 1385 Andrew G. Malis 1386 Vivace Networks, Inc. 1387 2730 Orchard Parkway 1388 San Jose, CA 95134 1389 e-mail: Andy.Malis@vivacenetworks.com 1391 Prayson Pate 1392 Overture Networks 1393 P. O. Box 14864 1394 RTP, NC, USA 27709 1395 email: prayson.pate@overturenetworks.com 1397 Ravi Bhat 1398 Nokia 1399 email: ravi.bhat@nokia.com 1401 Nishit Vasavada 1402 Nokia 1403 email: nishit.vasavada@nokia.com 1405 Luca Martini 1406 Level 3 Communications, LLC. 1407 1025 Eldorado Blvd. 1408 Broomfield, CO, 80021 1409 e-mail: luca@level3.net 1411 Nasser El-Aawar 1412 Level 3 Communications, LLC. 1413 1025 Eldorado Blvd. 1414 Broomfield, CO, 80021 1415 e-mail: nna@level3.net 1417 Giles Heron 1418 PacketExchange Ltd. 1419 The Truman Brewery 1420 91 Brick Lane 1421 LONDON E1 6QL 1422 United Kingdom 1423 e-mail: giles@packetexchange.net 1424 Dimitri Stratton Vlachos 1425 Mazu Networks, Inc. 1426 125 Cambridgepark Drive 1427 Cambridge, MA 02140 1428 e-mail: d@mazunetworks.com 1430 Dan Tappan 1431 Cisco Systems, Inc. 1432 250 Apollo Drive 1433 Chelmsford, MA, 01824 1434 e-mail: tappan@cisco.com 1436 Eric Rosen 1437 Cisco Systems, Inc. 1438 250 Apollo Drive 1439 Chelmsford, MA, 01824 1440 e-mail: erosen@cisco.com 1442 Steve Vogelsang 1443 Laurel Networks, Inc. 1444 Omega Corporate Center 1445 1300 Omega Drive 1446 Pittsburgh, PA 15205 1447 e-mail: sjv@laurelnetworks.com 1449 Vinai Sirkay 1450 Vivace Networks, Inc. 1451 2730 Orchard Parkway 1452 San Jose, CA 95134 1453 e-mail: sirkay@technologist.com 1455 Chris Liljenstolpe 1456 Cable & Wireless 1457 11700 Plaza America Drive 1458 Reston, VA 20190 1459 e-mail: chris@cw.net 1461 Kireeti Kompella 1462 Juniper Networks 1463 1194 N. Mathilda Ave 1464 Sunnyvale, CA 94089 1465 e-mail: kireeti@juniper.net