idnits 2.17.1 draft-fischer-pwe3-atm-service-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 62 lines == It seems as if not all pages are separated by form feeds - found 1 form feeds but 29 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. ** The abstract seems to contain references ([6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '2' is defined on line 1276, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1279, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1282, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1292, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1303, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' == Outdated reference: A later version (-08) exists of draft-ietf-pwe3-requirements-02 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-requirements (ref. '6') == Outdated reference: A later version (-12) exists of draft-martini-l2circuit-encap-mpls-04 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-encap-mpls (ref. '7') -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '10' == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-01 -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group John Fischer 3 Internet Draft Matthew Bocci 4 Expiration Date: August 2002 Mustapha Aissaoui 5 Alcatel 6 A. Siddiqui 7 Cable & Wireless Mina Azad 8 Ghassem Koleyni 9 Anna Cui Nortel Networks 10 Advanced Fibre Communications 11 Jim Harford 12 Dave Paw AdvanceNet Systems 13 MCI WorldCom 14 Cheng C. Chen 15 Sat Sahota NEC America, Inc. 16 Telus Communications 17 Sushil Shelly 18 Eric Letourneau Avici Systems 19 Bell Canada 20 Phong Khuu 21 Dave King Turin Networks 23 Jeffery See 24 General Dynamics Aditya Sehgal 25 SBC 27 Sohel Q. Khan 28 Sprint 30 March 2002 32 PWE3: ATM service description 33 draft-fischer-pwe3-atm-service-03.txt 35 Status of this Memo 37 This document is an Internet-Draft and is in full conformance with 38 all provisions of section 10 of RFC 2026 [1]. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt. 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html. 56 Abstract 58 Generic requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3) 59 have been described in [6]. This draft lists ATM specific 60 requirements and provides encapsulation formats and semantics for 61 connecting ATM edge networks through a core packet network using IP, 62 L2TP or MPLS. This basic application of ATM interworking will allow 63 ATM service providers to take advantage of new technologies in the 64 core in order to provide ATM multi-services. 66 Table of Contents 68 1 Conventions used in this document................................3 70 2 Introduction.....................................................3 71 3 Terminology......................................................4 72 4 General Requirements.............................................5 73 5 ATM Service Encapsulation........................................5 74 5.1 Length and Sequence Number ....................................6 75 5.1.1 Setting the length field .................................7 76 5.1.2 Processing the length field ..............................7 77 5.1.3 Setting the sequence number ..............................8 79 5.1.4 Processing the sequence number ...........................8 80 6 ATM VCC Services.................................................9 81 6.1 ATM VCC Cell Transport Service ................................9 82 6.1.1 ATM OAM Cell Support ....................................11 83 6.2 ATM VCC Frame Transport Service ..............................11 84 6.2.1 Transparent AAL5 PDU Frame Service ......................12 85 6.2.1.1 OAM Cell Support ....................................13 87 6.2.1.2 Fragmentation .......................................14 88 6.2.1.2.1 Procedures in the ATM-to-MPLS Direction ........14 89 6.2.1.2.2 Procedures in the MPLS-to-ATM Direction ........15 90 6.2.2 AAL5 SDU Frame Service ..................................15 91 6.2.2.1 OAM Cell Support ....................................16 92 7 ATM VPC Services................................................17 93 7.1 ATM VPC Cell Transport Services ..............................17 94 7.1.1 OAM Cell Support ........................................19 96 8 ILMI support....................................................20 97 9 QoS considerations..............................................20 98 10 ATM Pseudo-Wire over MPLS specific requirements................22 99 10.1 MPLS Transport Label ........................................23 100 10.2 MPLS Pseudo Wire Label ......................................23 101 11 ATM Pseudo-Wire over L2TP specific requirements................24 102 11.1 L2TP Session ID .............................................25 104 11.2 Cookie ......................................................25 105 12 ATM Pseudo-Wire over IP specific requirements..................25 107 12.1 C, K, and S bits ............................................26 108 12.2 Protocol Type field .........................................26 109 12.3 Key Field ...................................................26 110 12.4 GRE Sequence Number Field ...................................27 111 13 Security Considerations........................................27 112 14 Intellectual Property Disclaimer...............................27 113 15 References.....................................................27 114 16 Acknowledgments................................................28 116 17 Authors' Addresses.............................................28 118 1 Conventions used in this document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [1]. 124 2 Introduction 126 Many service providers have multiple service networks and the 127 Operational Support System capabilities needed to support these 128 existing service offerings. Packet Switched Networks (PSNs) have 129 the potential to reduce the complexity of a service provider's 130 infrastructure by allowing virtually any existing digital service to 131 be supported over a single networking infrastructure. 133 The benefits of this model to a service provider are threefold: 135 1. Leveraging of the existing systems and services to provide 136 increased capacity from a packet switched core. 138 2. Preserving existing network operational processes and 139 procedures used to maintain the legacy services. 141 3. Using the common packet switched network infrastructure to 142 support both the core capacity requirements of existing services 143 and the requirements of new services supported natively over the 144 packet switched network. 146 This draft describes a method to carry ATM services over IP, L2TP 147 and MPLS. It lists ATM specific requirements and provides 148 encapsulation formats and semantics for connecting ATM edge networks 149 through a core packet network using IP, L2TP or MPLS. The 150 techniques described in this draft will allow ATM service providers 151 to take advantage of new technologies in the core in order to 152 provide ATM multi-services. 154 Figure 1, below displays the ATM services reference model. This 155 model is adapted from [6]. 157 |<------- Pseudo Wire ------>| 158 | | 159 | |<-- PSN Tunnel -->| | 160 V V V V 161 ATM Service+----+ +----+ ATM Service 162 +-----+ | | PE1|==================| PE2| | +-----+ 163 | |----------|............PW1.............|----------| | 164 | CE1 | | | | | | | | CE2 | 165 | |----------|............PW2.............|----------| | 166 +-----+ | | |==================| | | +-----+ 167 ^ | +----+ +----+ | ^ 168 | | Provider Provider | | 169 | | Edge 1 Edge 2 | | 170 | | 171 |<-------------- Emulated Service ---------------->| 173 Customer Customer 174 Edge 1 Edge 2 176 Figure 1: ATM Service Reference Model 178 3 Terminology 180 Packet Switched Network - A Packet Switched Network (PSN) is a 181 network using IP, MPLS or L2TP as the unit of switching. 183 Pseudo Wire Emulation Edge to Edge - Pseudo Wire Emulation Edge to 184 Edge (PWE3) is a mechanism that emulates the essential attributes of 185 a service (such as a T1 leased line or Frame Relay) over a PSN. 187 Customer Edge - A Customer Edge (CE) is a device where one end of an 188 emulated service originates and terminates. The CE is not aware 189 that it is using an emulated service rather than a "real" service. 191 Provider Edge - A Provider Edge (PE) is a device that provides PWE3 192 to a CE. 194 Pseudo Wire - A Pseudo Wire (PW) is a connection between two PEs 195 carried over a PSN. The PE provides the adaptation between the CE 196 and the PW. 198 Pseudo Wire PDU - A Pseudo Wire PDU is a PDU sent on the PW that 199 contains all of the data and control information necessary to 200 provide the desired service. 202 PSN Tunnel - A PSN Tunnel is a tunnel inside which multiple PWs can 203 be nested so that they are transparent to core network devices. 205 Ingress _ The point where the ATM service is encapsulated into a 206 Pseudo Wire PDU (ATM to PSN direction.) 208 Egress - The point where the ATM service is decapsulated from a 209 Pseudo Wire PDU (PSN to ATM direction.) 211 4 General Requirements 213 For transport of an ATM service across a PSN, the PSN SHOULD be able 214 to: 216 1. Carry all AAL types transparently. 217 2. Carry multiple ATM connections (VPCs and/or VCCs). 218 3. Support ATM OAM applications. 219 4. Transport Cell Loss Priority (CLP) and Payload Type Indicator 220 (PTI) information from the ATM cell header. 221 5. Provide a mechanism to detect mis-ordering of ATM cells over 222 the PSN. 223 6. Support traffic contracts and the QoS commitments made to the 224 ATM connections (through the use of existing IETF defined Diff- 225 Serv techniques). 227 5 ATM Service Encapsulation 229 This section describes the general encapsulation format for ATM over 230 PSN pseudo wires, such as IP, L2TP, or MPLS. The specifics 231 pertaining to each packet technology are covered in later sections. 233 Figure 2 provides a general format for encapsulation of ATM cells 234 (or frames) into packets. 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | PSN Transport Header (As Required) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Pseudo Wire Header | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Optional Length and Sequence Number | ATM Specific | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | ATM Service Payload | 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 2: General format for ATM encapsulation over PSNs 251 The PSN Transport Header depends on the packet technology: IP, L2TP 252 or MPLS. This header is used to transport the encapsulated ATM 253 information through the packet switched core. This header is always 254 present if the Pseudo Wire is MPLS. 256 The Pseudo Wire Header depends on the packet technology: IP, L2TP or 257 MPLS. It identifies a particular ATM service within the PSN tunnel. 259 The Length and Sequence Number is inserted after the Pseudo Wire 260 Header. This field is optional. 262 The ATM Specific Header is inserted before the ATM service payload. 263 The ATM Specific Header contains control bits needed to carry the 264 service. These are defined in the ATM service descriptions below. 265 The length of ATM specific header may not always be one octet. It 266 depends on the service type. 268 The ATM payload octet group is the payload of the service that is 269 being encapsulated. 271 5.1 Length and Sequence Number 273 The length and sequence number are not required for all services. 274 The control word is designed to satisfy these requirements. 276 - Sequentiality may need to be preserved. 277 - Small packets may need to be padded in order to be transmitted 278 on a medium where the minimum transport unit is larger than 279 the actual packet size. 281 The one-octet Length indicates length of the packet payload that 282 includes Sequence number length, the ATM specific header length and 283 the payload length (i.e., Pseudo Wire PDU). The Length field is set 284 to 0 by the ingress PE if not used and is ignored by the egress PE. 286 If the Pseudo Wire traverses a network link that requires a minimum 287 frame size such as Ethernet as a practical example, with a minimum 288 frame size of 64 octets, then such links will apply padding to the 289 Pseudo Wire PDU to reach its minimum frame size. In this case the 290 length field MUST be set to the PDU length. A mechanism is required 291 for the egress PE to detect and remove such padding. 293 The Sequence Number is a 2-octet field that may be used to track 294 packet order delivery. This field is set to 0 by the ingress PE if 295 not used and is ignored by the egress PE. The sequence number space 296 is a 16-bit, unsigned circular space. Processing of the sequence 297 number field is OPTIONAL. 299 In all cases the egress PE MUST be aware of whether the ingress PE 300 will send the length and sequence number over a specific Pseudo 301 Wire. 302 This may be achieved using static configuration or using Pseudo Wire 303 specific signaling. 305 5.1.1 Setting the length field 307 The length field is required to enable the egress PE to remove any 308 padding that may have resulted if the pseudo-wire traversed a 309 network link that enforces a minimum frame size (e.g. Ethernet). 310 Ethernet applies padding to frames that are smaller than 64 bytes, 311 where this includes a minimum of 18 bytes for the Ethernet header 312 and trailer. 314 The length field represents the size of the packet in bytes 315 including the length, sequence number, ATM specific header and ATM 316 service payload. If the size of the packet is larger than can be 317 represented by the length field, the field MUST be set to 0. In 318 addition, the length field MAY be set to 0 if the size of the packet 319 prevents any padding from being applied. 321 The AAL5 SDU Frame service is the only service that can generate 322 packets smaller than the Ethernet minimum and MUST set the length 323 field accordingly. The length field MUST either be set to the size 324 of the packet if the size is less than 46 bytes or to 0. 326 All other cell or frame transport services MUST either follow the 327 same procedure as the SDU frame service or always set the length 328 field to 0 to indicate to the remote PE that no padding was applied. 330 5.1.2 Processing the length field 332 When the length field is present the egress PE MUST follow these 333 procedures: 335 - If the length field of the packet is 0, then the packet does not 336 require padding to be stripped. 338 - Otherwise, the length field MUST be verified against the size of 339 the packet as follows. 341 - if the packet size is smaller than indicated by the length 342 field, the packet MUST be discarded 344 - otherwise, if the packet size is as indicated by the length 345 field then the packet does not require padding to be stripped 347 - otherwise, the packet is altered by removing the padding 348 bytes from the end of the packet to match the size indicated 349 by the length field. 351 5.1.3 Setting the sequence number 353 The following procedures SHOULD be used by the ingress PE if 354 sequencing is desired for a given ATM service: 356 - the initial PDU transmitted on the Pseudo Wire MUST use 357 sequence number 1 358 - the PE MUST increment the sequence number by one for each 359 subsequent PDU 360 - when the transmit sequence number reaches the maximum 16 bit 361 value (65535) the sequence number MUST wrap to 1 363 If the ingress PE does not support sequence number processing, then 364 the sequence number field in the control word MUST be set to 0. 366 5.1.4 Processing the sequence number 368 If the egress PE supports receive sequence number processing, then 369 the following procedures SHOULD be used: 371 When an ATM service is initially created, the "expected sequence 372 number" associated with it MUST be initialized to 1. 374 When a PDU is received on the Pseudo Wire associated with the ATM 375 service, the sequence number SHOULD be processed as follows: 377 - if the sequence number on the packet is 0, then the PDU passes 378 the sequence number check 380 - otherwise if the PDU sequence number >= the expected sequence 381 number and the PDU sequence number - the expected sequence 382 number < 32768, then the PDU is in order. 384 - otherwise if the PDU sequence number < the expected sequence 385 number and the expected sequence number - the PDU sequence 386 number >= 32768, then the PDU is in order. 388 - otherwise the PDU is out of order. 390 If a PDU passes the sequence number check, or is in order then, it 391 can be delivered immediately. If the PDU is in order, then the 392 expected sequence number SHOULD be set using the algorithm: 394 expected_sequence_number := PDU_sequence_number + 1 mod 2**16 395 if (expected_sequence_number = 0) 396 then expected_sequence_number := 1; 398 Pseudo Wire PDUs that are received out of order MAY be dropped or 399 reordered at the discretion of the egress PE. 401 If the egress PE does not support receive sequence number 402 processing, then the sequence number field MAY be ignored. 404 6 ATM VCC Services 406 This section defines three types of ATM VCC services that may be 407 supported over the PSN: ATM cell, ATM AAL5 PDU, and ATM AAL5 SDU. 409 6.1 ATM VCC Cell Transport Service 411 The VCC cell transport service is characterized by the mapping of a 412 single ATM VCC (VPI/VCI) to a Pseudo Wire. This service is fully 413 transparent to the ATM Adaptation Layer. The VCC cell transport 414 service is MANDATORY. 416 This service MUST use the following cell mode encapsulation: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | PSN Transport Header (As Required) | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Pseudo Wire Header | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Optional Length and Sequence Number |M|V|Res| PTI |C| 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | | 428 | ATM Cell Payload ( 48 bytes ) | 429 | | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 3: Single ATM VCC Cell Encapsulation 434 * M (transport mode) bit 436 Bit (M) of the control byte indicates whether the packet 437 contains an ATM cell or a frame payload. If set to 0, the 438 packet contains an ATM cell. If set to 1, the PDU contains an 439 AAL5 payload. The ability to transport an ATM cell in the AAL5 440 mode is intended to provide a means of enabling OAM 441 functionality over the AAL5 VCC. 443 * V (VCI present) bit 445 Bit (V) of the control byte indicates whether the VCI field is 446 present in the packet. If set to 1, the VCI field is present 447 for the cell. If set to 0, no VCI field is present. In the 448 case of a VCC, the VCI field is not required. For VPC, the VCI 449 field is required and is transmitted with each cell. 451 * Reserved bits 453 The reserved bits should be set to 0 at the transmitter and 454 ignored upon reception. 456 * PTI Bits 458 The 3-bit Payload Type Identifier (PTI) incorporates ATM Layer 459 PTI coding of the cell. These bits are set to the value of the 460 PTI of the encapsulated ATM cell. 462 * C (CLP) Bit 464 The Cell Loss Priority (CLP) field indicates CLP value of the 465 encapsulated cell. 467 For increased transport efficiency, the ingress PE SHOULD be able to 468 encapsulate multiple ATM cells into a Pseudo Wire PDU. The ingress 469 and egress PE SHOULD agree to a maximum number of cells in a single 470 Pseudo Wire PDU. This agreement may be accomplished via a Pseudo 471 Wire specific signaling mechanism or via static configuration. 473 When multiple cells are encapsulated in the same PSN packet, the ATM 474 control byte MUST be repeated for each cell. This means that 49 475 bytes are used to encapsulate each 53 byte ATM cell. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | PSN Transport Header (As Required) | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Pseudo Wire Header | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Optional Length and Sequence Number |M|V|Res| PTI |C| 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | | 487 | ATM Cell Payload ( 48 bytes ) | 488 | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 |M|V|Res| PTI |C| | 491 +-+-+-+-+-+-+-+-+ | 492 | ATM Cell Payload ( 48 bytes ) | 493 | | 494 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | | 496 +-+-+-+-+-+-+-+-+ 498 Figure 4: Multiple ATM VCC Cell Encapsulation 500 6.1.1 ATM OAM Cell Support 502 When configured for a VCC cell relay service, both PE's SHOULD act 503 as a VC switch in accordance with the OAM procedures defined in [5]. 505 The PEs MUST be able to pass the following OAM cells transparently: 506 - F5 AIS (segment and end-to-end) 507 - F5 RDI (segment and end-to-end) 508 - F5 loopback (segment and end-to-end) 509 - Resource Management 510 - Performance Management 511 - Continuity Check 512 - Security 514 The PEs SHALL use the ATM VCC cell mode encapsulation (Section 6.1) 515 when passing an OAM cell. The OAM cell MAY be encapsulated together 516 with other user data cells if multiple cell encapsulation is used. 518 The ingress PE SHOULD be able to generate an F5 AIS upon reception 519 of a corresponding F4 AIS or lower layer defect (such as LOS). 521 The egress PE SHOULD be able to generate an F5 AIS based on a PSN 522 failure (such as a PSN tunnel failure or LOS on the PSN port). 524 If the ingress PE cannot support the generation of OAM cells, it MAY 525 notify the egress PE using a Pseudo Wire specific maintenance 526 mechanism (to be defined). For example, the ingress PE MAY withdraw 527 the Pseudo Wire (VC label) associated with the service. Upon 528 receiving such a notification, the egress PE SHOULD generate the 529 appropriate F5 AIS. 531 6.2 ATM VCC Frame Transport Service 533 The frame mode services were designed specifically for better 534 transport efficiency than the cell mode. Two modes of AAL5 frame 535 transport are available. The transparent AAL5 PDU mode is intended 536 to be more efficient than cell mode, yet still provide full ATM 537 transparency including the correct sequencing of OAM cells on an 538 AAL5 flow. The payload AAL5 SDU mode is intended to provide more 539 transport efficiency than the PDU mode while foregoing some ATM 540 transparency. 542 It is important that the PEs be able to efficiently switch between 543 the frame and cell modes in order to support ATM OAM functions. 545 The agreement to transport transparent AAL5 PDUs or payload AAL5 546 SDUs may be accomplished via a Pseudo Wire specific signaling 547 mechanism or via static configuration. 549 6.2.1 Transparent AAL5 PDU Frame Service 551 In this mode, the ingress PE encapsulates the entire CPCS-PDU 552 including the PAD and trailer. 554 This mode MAY support fragmentation in order to maintain OAM cell 555 sequencing. 557 Like the ATM AAL5 payload VCC service, the AAL5 transparent VCC 558 service is intended to be more efficient than the VCC cell transport 559 service. However, the AAL5 transparent VCC service carries the 560 entire AAL5 CPCS-PDU, including the PAD and trailer. Note that the 561 AAL5 CPCS-PDU is not processed _ i.e. an AAL5 frame with an invalid 562 CRC or length field will be transported. One reason for this is 563 that there may be a security agent that has scrambled the ATM cell 564 payloads that form the AAL5 CPCS-PDU. 566 This service supports all OAM cell flows by using a fragmentation 567 procedure that ensures that OAM cells are not repositioned in 568 respect to AAL5 composite cells. 570 The AAL5 transparent VCC service is OPTIONAL. 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | PSN Transport Header (As Required) | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Pseudo Wire Header | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Optional Length and Sequence Number |M|V|Res|Frg|E|C| 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 + " | 582 | AAL5 CPCS-PDU | 583 | (n * 48 bytes) | 584 | " | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 Figure 5: AAL5 transparent service encapsulation 589 The first octet following the Pseudo Wire Header carries 590 control information. The M, V, Res, and C bits are as defined 591 earlier for VCC cell mode. 593 * Frg (Fragmentation) Bits 595 This field is used to support the fragmentation functionality 596 described later in this section. 598 - 11 Single Segment Message (Beginning and End of Message) 599 - 10 Beginning of Message 600 - 00 Continuation of Message 601 - 01 End of Message 603 * E (EFCI) bit 605 This field is used to convey the EFCI state of the ATM cells. 606 The EFCI state is indicated in the middle bit of each ATM 607 cell's PTI field. 609 ATM-to-PSN direction (ingress): The EFCI field of the 610 control byte is set to the EFCI state of the last cell of 611 the AAL5 PDU or AAL5 fragment. 613 PSN-to-ATM direction (egress): The EFCI state of all 614 constituent cells of the AAL5 PDU or AAL5 fragment is set to 615 the value of the EFCI field in the control byte. 617 * C (CLP) bit 619 This field is used to convey the cell loss priority of the ATM 620 cells. 622 ATM-to-PSN direction (ingress): The CLP field of the 623 control byte is set to 1 if any of the constituent cells of 624 the AAL5 PDU or AAL5 fragment has its CLP bit set to 1; 625 otherwise this field is set to 0. 627 PSN-to-ATM direction (egress): The CLP bit of all 628 constituent cells for an AAL5 PDU or AAL5 fragment is set to 629 the value of the CLP field in the control byte. 631 The payload consists of the re-assembled AAL5 CPCS-PDU, 632 including the AAL5 padding and trailer or the AAL5 fragment. 634 6.2.1.1 OAM Cell Support 636 When configured for the AAL5 transparent VCC service, both PE's 637 SHOULD act as a VC switch, in accordance with the OAM procedures 638 defined in [5]. 640 The PEs SHOULD be able to pass the following OAM cells 641 transparently: 642 - F5 AIS (segment and end-to-end) 643 - F5 RDI (segment and end-to-end) 644 - F5 loopback (segment and end-to-end) 645 - Resource Management 646 - Performance Management 647 - Continuity Check 648 - Security 650 The PEs SHALL use the single ATM VCC cell mode encapsulation 651 (Section 6.1) when passing an OAM cell. 653 The ingress PE SHOULD be able to generate an F5 AIS upon reception 654 of a corresponding F4 AIS or lower layer defect (such as LOS). 656 The egress PE SHOULD be able to generate an F5 AIS based on a PSN 657 failure (such as a PSN tunnel failure or LOS on the PSN port). 659 If the ingress PE cannot support the generation of OAM cells, it MAY 660 notify the egress PE using a Pseudo Wire specific maintenance 661 mechanism to be defined. For example, the ingress PE MAY withdraw 662 the Pseudo Wire (VC label) associated with the service. Upon 663 receiving such a notification, the egress PE SHOULD generate the 664 appropriate F5 AIS. 666 6.2.1.2 Fragmentation 668 The ingress PE may not always be able to reassemble a full AAL5 669 frame. This may be due to the AAL5 PDU exceeding the Pseudo Wire MTU 670 or when OAM cells arrive during reassembly of the AAL5 PDU. In these 671 cases, the AAL5 PDU shall be fragmented. In addition, fragmentation 672 may be desirable to bound ATM cell delay. 674 If no fragmentation occurs, then the fragmentation bits are set to 675 11 (SSM, Single Segment Message). 677 When fragmentation occurs, the procedures described in the following 678 subsections shall be followed. 680 6.2.1.2.1 Procedures in the ATM-to-MPLS Direction 682 The following procedures shall apply while fragmenting AAL5 PDUs: 683 - Fragmentation shall always occur at cell boundaries within the 684 AAL5 PDU. 685 - For the first fragment, the FRG bits shall be set to 10 (BOM, 686 Beginning Of Message). 687 - For the last fragment, the FRG bits shall be set to 01 (EOM, 688 End Of Message). 689 - For all other fragments, the FRG bits shall be set to 00 (COM, 690 Continuation Of Message). 691 - The E and C bits of the fragment shall be set as defined 692 earlier in section 6. 694 6.2.1.2.2 Procedures in the MPLS-to-ATM Direction 696 The following procedures shall apply: 697 - The 3-bit PTI field of each ATM cell header is constructed as 698 follows: 699 + The most significant bit is set to 0, indicating a user 700 data cell. 701 + The middle bit is set to the E bit value of the 702 fragment. 703 + The least significant bit is set to 1 for the last ATM 704 cell of a fragment where the FRG bits are 01 (EOM) or 705 11(SSM); otherwise this bit is set to 0. 706 - The C bit of each ATM cell header is set to the value of the C 707 bit of the control byte in Figure 5. 709 6.2.2 AAL5 SDU Frame Service 711 The AAL5 payload VCC service defines a mapping between the payload 712 of an AAL5 VCC and a single Pseudo Wire. This service is OPTIONAL. 714 The AAL5 payload VCC service requires ATM segmentation and 715 reassembly support on the PE. Once the ingress PE reassembles the 716 AAL5 CPCS-PDU, the PE discards the PAD and CPCS-PDU trailer and then 717 inserts the resulting payload into a Pseudo Wire PDU. Although any 718 AAL5 PDU may be transported using the VCC cell relay service and 719 cell mode encapsulation, the AAL5 payload VCC service is designed 720 for better transport efficiency. 722 The egress PE MUST regenerate the PAD and trailer before 723 transmitting the AAL5 frame on the egress ATM port. 725 This service does allow the transport of OAM and RM cells, but does 726 not attempt to maintain the relative order of these cells with 727 respect to the cells that comprise the AAL5 CPCS-PDU. OAM cells 728 that arrive during the reassembly of a single AAL5 CPCS-PDU are sent 729 immediately on the Pseudo Wire, followed by the AAL5 payload. 730 Therefore, the AAL5 payload VCC service may not be suitable for some 731 ATM applications that require strict ordering of OAM cells (such as 732 performance monitoring and security applications). 734 The AAL5 payload service encapsulation is shown below. 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | PSN Transport Header (As Required) | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Pseudo Wire Header | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Optional Length and Sequence Number |M|V|R|U|Frg|E|C| 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | " | 746 | AAL5 SDU payload | 747 | " | 748 | " | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Figure 6: AAL5 payload service encapsulation 753 The first octet following the Pseudo Wire Header carries 754 control information. The M, V, R (reserved), E and C bits are 755 as defined earlier for VCC cell mode. Since fragmentation is 756 not required, the fragmentation bits are set to 11 to indicate 757 a complete frame. 759 * U (UU Octet Command/Response) Bit 761 When FRF.8.1 Frame Relay / ATM PVC Service Interworking traffic 762 is being transported, the CPCS-UU Least Significant Bit (LSB) 763 of the AAL5 CPCS-PDU may contain the Frame Relay C/R bit. 764 The ingress PE device SHOULD copy this bit to the C bit of the 765 control byte. The egress PE device SHOULD copy the C bit to the 766 CPCS-UU Least Significant Bit (LSB) of the AAL5 payload. 768 6.2.2.1 OAM Cell Support 770 Similar to the VCC cell relay service, both PEs SHOULD act as a VC 771 switch in accordance with the OAM procedures defined in [5]. 773 The PEs SHOULD be able to pass the following OAM cells 774 transparently: 775 - F5 AIS (segment and end-to-end) 776 - F5 RDI (segment and end-to-end) 777 - F5 loopback (segment and end-to-end) 778 - Resource Management 779 - Continuity Check 781 Because this service does not guarantee the original OAM cell 782 position within the AAL5 composite cells, the following cell types 783 are discarded by the ingress PE: 784 - Performance Management 785 - Security 787 The PEs SHALL use the single ATM VCC cell mode encapsulation 788 (Section 6.1) when passing an OAM cell. 790 The ingress PE SHOULD be able to generate an F5 AIS upon reception 791 of a corresponding F4 AIS or lower layer defect (such as LOS). 793 The egress PE SHOULD be able to generate an F5 AIS based on a PSN 794 failure (such as a PSN tunnel failure or LOS on the PSN port). 796 If the ingress PE cannot support the generation of OAM cells, it MAY 797 notify the egress PE using a Pseudo Wire specific maintenance 798 mechanism to be defined. For example, the ingress PE MAY withdraw 799 the Pseudo Wire (VC label) associated with the service. Upon 800 receiving such a notification, the egress PE SHOULD generate the 801 appropriate F5 AIS. 803 7 ATM VPC Services 805 The VPC service is defined by mapping a single VPC (VPI) to a Pseudo 806 Wire. As such it emulates as Virtual Path cross-connect across the 807 PSN. All VCCs belonging to the VPC are carried transparently by the 808 VPC service. 810 The egress PE may choose to apply a different VPI other than the one 811 that arrived at the ingress PE. The egress PE MUST choose the 812 outgoing VPI based solely upon the Pseudo Wire header. As a VPC 813 service, the egress PE MUST NOT change the VCI field. 815 7.1 ATM VPC Cell Transport Services 817 The ATM VPC cell transport service is OPTIONAL. 819 This service MUST use the following cell mode encapsulation: 821 0 1 2 3 822 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 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | PSN Transport Header (As Required) | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Pseudo Wire Header | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Optional Length and Sequence Number |M|V|Res| PTI |C| 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | VCI | | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 832 | | 833 | ATM Cell Payload ( 48 bytes ) | 834 | | 835 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Figure 7: Single Cell VPC Encapsulation 841 The ATM control byte contains the same information as in the VCC 842 encapsulation except for the VCI field. 844 * VCI Bits 846 The 16-bit Virtual Circuit Identifier (VCI) incorporates ATM 847 Layer VCI value of the cell. 849 For increased transport efficiency, the ingress PE SHOULD be able to 850 encapsulate multiple ATM cells into a Pseudo Wire PDU. The ingress 851 and egress PE SHOULD agree to a maximum number of cells in a single 852 Pseudo Wire PDU. This agreement may be accomplished via a Pseudo 853 Wire specific signaling mechanism or via static configuration. 855 When multiple ATM cells are encapsulated in the same PSN packet, the 856 ATM control byte MUST be repeated for each cell. This means that 51 857 bytes are used to encapsulate each 53 byte ATM cell. 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | PSN Transport Header (As Required) | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Pseudo Wire Header | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Optional Length and Sequence Number |M|V|Res| PTI |C| 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | VCI | | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 870 | | 871 | ATM Cell Payload ( 48 bytes ) | 872 | | 873 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | |M|V|Res| PTI |C| VCI | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | VCI | | 877 +-+-+-+-+-+-+-+-+ | 878 | ATM Cell Payload ( 48 bytes ) | 879 | | 880 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | | 882 +-+-+-+-+-+-+-+-+ 884 Figure 8: Multiple Cell VPC Encapsulation 886 7.1.1 OAM Cell Support 888 When configured for a VPC cell relay service, both PE's SHOULD act 889 as a VP cross-connect in accordance with the OAM procedures defined 890 in [5]. 892 The PEs MUST be able to pass the following OAM cells transparently: 893 - F4 AIS (segment and end-to-end) 894 - F4 RDI (segment and end-to-end) 895 - F4 loopback (segment and end-to-end) 896 - F5 AIS (segment and end-to-end) 897 - F5 RDI (segment and end-to-end) 898 - F5 loopback (segment and end-to-end) 899 - Resource Management 900 - Performance Management 901 - Continuity Check 902 - Security 904 The PEs SHALL use the ATM VPC cell encapsulation (Section 7.1) when 905 passing an OAM cell. The OAM cell MAY be encapsulated together with 906 other user data cells if multiple cell encapsulation is used. 908 The ingress PE MUST be able to generate an F4 AIS upon reception of 909 a lower layer defect (such as LOS). 911 The egress PE SHOULD be able to generate an F4 AIS based on a PSN 912 failure (such as a PSN tunnel failure or LOS on the PSN port). 914 If the ingress PE cannot support the generation of OAM cells, it MAY 915 notify the egress PE using a Pseudo Wire specific maintenance 916 mechanism to be defined. For example, the ingress PE MAY withdraw 917 the Pseudo Wire (VC label) associated with the service. Upon 918 receiving such a notification, the egress PE SHOULD generate the 919 appropriate F4 AIS. 921 8 ILMI support 923 Integrated Local Management Interface (ILMI) typically is used in 924 ATM networks for neighbor resource availability detection, address 925 registration, auto-configuration, and loss of connectivity 926 detection. ILMI messages are sent as SNMP PDU's within ATM AAL5 927 cells. 929 A PE MAY provide an ATM ILMI to its attached CE. If the ingress PE 930 receives an ILMI message indicating that the ATM service (VCC or 931 VPC) is down, it MAY use a Pseudo Wire specific mechanism to notify 932 the egress PE of the ATM service status. For example, a PE using an 933 MPLS based Pseudo Wire may withdraw its advertised VC label. 935 When receiving such a notification, the egress PE MAY use ILMI to 936 signal the ATM service status to its attached CE. 938 9 QoS considerations 940 This section provides guidelines for the provision of QoS for the 941 individual ATM PWs over the PSN. The objective is to provide the 942 ability to support the traffic contracts and the QoS commitments 943 made to the ATM connections [8]. This section is informational and 944 the provided guidelines SHOULD be treated as good practices and the 945 mappings as examples only. 947 When ATM PW service is configured over a PSN, each ATM service 948 category SHOULD be mapped to a compatible class of service in the 949 PSN network. A compatible class of service maintains the integrity 950 of the service end to end. For example, the CBR service category 951 SHOULD be mapped to a class of service with stringent loss and delay 952 objectives. If the PSN implements the IP Diff-Serv framework to 953 provide QoS classes, a class of service based on the EF PHB is a 954 good candidate. 956 Furthermore, ATM service categories have support for multiple 957 conformance definitions. A conformance definition specifies the 958 conformance of cells of a connection at an interface, e.g., public 959 UNI, in relation to the conformance algorithm and corresponding 960 parameters specified in the connection traffic descriptor [15]. For 961 example, the conformance definition specifies if the requested QoS 962 parameters, e.g., CLR, apply to the aggregate CLP0+1 conforming cell 963 flow or to the CLP0 conforming flow only. Thus, the conformance 964 definition SHOULD be respected in the selected PSN class of service. 965 For example, a connection CLP1 cell flow in a VBR.3 conformance 966 definition is treated as excess traffic in the ATM network and thus 967 has no QoS guarantees associated with it. This flow SHOULD be 968 provided a treatment no better than the treatment of the CLP0 cell 969 flow in the PSN. This does not mean however that the PSN network 970 should mirror the various conformance definitions of the ATM service 971 categories. 973 In the remainder of this section, it is assumed that the PSN 974 implements IP Diff-Serv framework to provide QoS. 976 All ATM traffic management functions specified in [15] are 977 applicable for the ATM part of the ATM PW in the ingress PE and 978 egress PE. In the ATM-to-PSN direction, each ATM connection MAY be 979 policed and/or shaped to conform to its traffic descriptor in the 980 ATM endpoint of the ATM PW in the PE. Whenever allowed by the 981 conformance definition, a non-conforming CLP0 cell may be turned 982 into a CLP1 cell and becomes conforming. Connection admission 983 SHOULD be applied to make sure sufficient resources are available to 984 carry the ATM PW over the transport LSP. The mapping of ATM service 985 category and conformance definition to the Diff-Serv PHB determines 986 the outgoing PHB. This is the PHB to be applied to the cells or 987 packets of the ATM PW in the ingress PE and egress PE and inside the 988 PSN. The PSN transport header of the outgoing PSN packet SHOULD be 989 marked to identify the selected PHB. This consists of marking the 990 DS field in the IP header in the case of IP PSN, or the EXP field in 991 the transport shim header in the case of a MPLS PSN. 993 Figure 9 provides an example of mapping ATM service category and 994 conformance definition to a Diff-Serv PHB. 996 ATM Service Conformance CLP Diff-Serv DSCP 997 Category Definition Setting PHB Marking 998 ---------------------------------------------------------------- 999 CBR CBR.1 0/1 EF 101110 1000 rt-VBR VBR.1 0/1 EF 101110 1001 VBR.2/VBR.3 0 AF11 001010 1002 1 AF12 001100 1003 nrt-VBR VBR.1 0/1 AF21 010010 1004 VBR.2/VBR.3 0 AF21 010010 1005 1 AF22 010100 1006 ABR ABR 0 AF31 011010 1007 UBR+MDCR UBR.1/UBR.2 0/1 AF31 011010 1008 GFR GFR.1/GFR.2 0 AF31 011010 1009 1 AF32 011100 1010 UBR UBR.1/UBR.2 0/1 DF 000000 1012 Figure 9: Example of ATM Service Category to PHB Mapping 1014 Note that an alternative mapping may not distinguish between the 1015 conformance definitions in a given ATM service category. In this 1016 case, the CLP0 and CLP1 flows of a ATM connection are provided with 1017 the same QoS in the PSN. As an example, all conformance definitions 1018 of the nrt-VBR service category MAY be mapped to the AF21 PHB in 1019 Figure 9. 1021 When the PSN is MPLS based, the selected PHB for the ATM PW is 1022 conveyed in different ways depending if the transport LSP is an L- 1023 LSP or an E-LSP [16]. In the case of an L-LSP, the PHB Scheduling 1024 Class is signaled at the transport LSP establishment and is 1025 therefore inferred from the transport label value. The Drop 1026 Precedence of the individual PW packets is conveyed in the EXP field 1027 of the transport LSP shim header. In the case of an E-LSP, the PHB 1028 is conveyed in the EXP field of the transport LSP shim header. The 1029 actual values to be marked in the EXP field to reflect the example 1030 in Figure 9 is outside the scope of this document. 1032 In the presence of congestion, the PE MAY mark the EFCI bit and MAY 1033 perform selective cell discard based on CLP setting, if allowed by 1034 the conformance definition, and in accordance with [15]. The method 1035 used to transfer the CLP and EFCI information of the individual 1036 cells into the ATM specific field of the PW packet is described in 1037 details in sections 6 and 7. 1039 In the PSN-to-ATM direction, the ATM service category and 1040 conformance definition is obtained from the context accessed via the 1041 pseudo wire label of the ATM PW. The information needed to 1042 reconstruct the ATM header, including the setting of the CLP and 1043 EFCI fields, for the individual cells is contained in the ATM 1044 specific information field of the PW packet. The method used to 1045 determine the CLP and EFCI information of the individual cells from 1046 the ATM specific information field of the PW packet is described in 1047 details in sections 6 and 7. 1049 10 ATM Pseudo-Wire over MPLS specific requirements 1051 Figure 10 provides a general format for interworking between ATM and 1052 MPLS. The ATM information is encapsulated inside two MPLS labels as 1053 defined in [9]. 1055 The Pseudo Wire Endpoint uses a unique MPLS label, the pseudo wire 1056 label, to identify each direction of an ATM connection. This label 1057 allows the PWE to access context information for the connection. As 1058 an example, the context may contain the information regarding 1059 connection type such as VCC or VPC or VPI/VCI value that need to be 1060 inserted into the ATM cell header in the MPLS-to-ATM direction. 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | MPLS Transport Label | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | MPLS Pseudo Wire Label | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Optional Length and Sequence Number | ATM Specific | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | ATM Service Payload | 1072 | | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 Figure 10: Format for ATM PW over a MPLS PSN 1077 10.1 MPLS Transport Label 1079 The 4-octet MPLS transport label identifies an LSP used to transport 1080 traffic between two ATM-MPLS pseudo wire endpoints. This label is 1081 used to switch the transport LSP between core LSRs. 1083 Since an MPLS LSP is unidirectional, for the case of bi-directional 1084 traffic there will be two different pseudo wire LSPs, one for each 1085 direction of the connection. These may have different label values. 1086 Setting of the EXP and TTL is for further study. The S bit is set 1087 to 0 since this is not the last label in the MPLS label stack. 1089 10.2 MPLS Pseudo Wire Label 1091 The 4-octet interworking label uniquely identifies one pseudo wire 1092 LSP, carried inside a MPLS transport LSP. The pseudo wire label has 1093 the structure of a standard MPLS shim header. More than one pseudo 1094 wire LSP may be supported by one MPLS transport LSP. The pseudo 1095 wire endpoint provides the association between the ATM connection or 1096 the ATM port and MPLS LSP by means of the 20-bit label field of the 1097 pseudo wire LSP. In this association, in the ATM-to-MPLS direction 1098 a mapping of the VCI/VPI of the ATM connection or the Port to the 1099 20-bit label is performed, while in the MPLS-to-ATM direction the 1100 20-bit label is mapped to a VPI/VCI of the ATM connection or to a 1101 Port. This association is signalled or provisioned between the two 1102 pseudo-wire endpoints. 1104 Since an MPLS LSP is unidirectional, for the case of bi-directional 1105 ATM VCCs there will be two different pseudo wire LSPs, one for each 1106 direction of the connection. These may have different label values. 1107 Setting of the EXP and TTL is for further study. The S bit is set 1108 to 1 since this is the last label in the bottom of the MPLS stack. 1109 The pseudo wire label is not visible to the LSRs within the MPLS 1110 core network. 1112 11 ATM Pseudo-Wire over L2TP specific requirements 1114 Figure 11 provides a general format for interworking between ATM and 1115 L2TP. This draft refers to L2TPv3, or L2TP base, as described in 1116 [11]. L2TP base extends the original L2TP [12] to operate directly 1117 over a IP PSN and to further generalize the control procedures to 1118 carry any tunneled Layer 2 protocol other than PPP. Any further 1119 reference to L2TP in this document assumes L2TPv3 or L2TP base as 1120 specified in [11]. 1122 The ATM information is encapsulated inside a L2TP tunnel packet. The 1123 L2TP tunnel is setup over a IPv4 PSN. The IPv4 protocol in the IPv4 1124 header is set to 115 to indicate that the L2TP packet is 1125 encapsulated in a IPv4 packet [11]. Furthermore, L2TP can operate 1126 over IP or over UDP. The use of either mode is outside the scope of 1127 this document. The encapsulation format shown in Figure 11 1128 represents the common headers for carrying L2TP packet over UDP and 1129 IP. If UDP is used, additional header information is required and is 1130 defined in [11]. 1132 The Pseudo Wire Endpoint uses a unique L2TP session ID to identify 1133 each direction of an ATM connection. This session ID is local to 1134 each PE and allows the PWE to identify each ATM PW in the L2TP 1135 tunnel in order to access context information for the ATM 1136 connection. As an example, the context may contain the information 1137 regarding connection type such as VCC or VPC or VPI/VCI value that 1138 need to be inserted into the ATM cell header in the L2TP-to-ATM 1139 direction. Multiple PWs with locally unique Session IDs at each PE 1140 can be multiplexed into a L2TP tunnel. 1142 0 1 2 3 1143 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 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | L2TP Session ID | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Cookie (optional, up to 64 bits) | 1148 | | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Optional Length and Sequence Number | ATM Specific | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | ATM Service Payload | 1153 | | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 Figure 11: Format for ATM PW over a L2TP PSN 1158 11.1 L2TP Session ID 1160 This is 32-bit field containing a non-zero identifier for a session, 1161 or a PW in this case. L2TP sessions are named by identifiers that 1162 have local significance only at each PE [11]. 1164 The same PW will be given different Session IDs by each PE for the 1165 life of the session. Multiple PWs with locally unique Session IDs at 1166 each PE can be multiplexed into a L2TP tunnel. When the L2TP control 1167 connection is used for session establishment, Session IDs are 1168 selected and exchanged as Local Session ID Attribute Value Pairs 1169 (AVPs) during the creation of a PW. A session ID of zero is reserved 1170 for the carriage of L2TP control messages [11]. 1172 11.2 Cookie 1174 The optional Cookie field contains a variable length (maximum 64 1175 bits), long word-aligned value used to check the association of a 1176 received packet with the PW identified by the Session ID. The Cookie 1177 MUST be configured with a random value utilizing all bits in the 1178 field [11]. The Cookie provides an additional level of guarantee, 1179 beyond the Session ID lookup, that a packet has been directed to the 1180 proper PW identified by the Session ID. 1182 When the L2TP control connection is used for PW session 1183 establishment, random Cookie values are selected and exchanged as 1184 Assigned Cookie AVPs during the creation of a PW. The maximum size 1185 of the Cookie field is 64 bits. 1187 12 ATM Pseudo-Wire over IP specific requirements 1189 Figure 12 provides a general format for carrying a ATM PW over a IP 1190 PSN. This is an alternative encapsulation to the one using L2TP, as 1191 described in Section 11. The GRE encapsulation is used as specified 1192 in [13] and [14]. The IPv4 protocol in the IPv4 header is set to 47 1193 to indicate that the GRE packet is encapsulated in a IPv4 packet 1194 [13]. 1196 The ATM information is encapsulated inside a GRE/IP packet. The 1197 Pseudo Wire Endpoint uses a unique GRE Key to identify each 1198 direction of an ATM connection. As an example, the context may 1199 contain the information regarding connection type such as VCC or VPC 1200 or VPI/VCI value that need to be inserted into the ATM cell header 1201 in the IP-to-ATM direction. Multiple PWs with unique GRE Keys can be 1202 multiplexed into a GRE/IP tunnel. 1204 0 1 2 3 1205 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 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | IPv4 Header (N words) | 1208 | | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 |C| |K|S| Reserved0 | Ver | Protocol Type | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Key | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | GRE Sequence Number (Optional) | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | Optional Length and Sequence Number | ATM Specific | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | ATM Service Payload | 1219 | | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 Figure 12: Format for ATM PW over a IP PSN 1224 12.1 C, K, and S bits 1226 The Checksum field in the GRE header is not required for carrying 1227 ATM PW over IP PSN. Therefore the C bit is set to zero. 1229 The Key field in the GRE header is always used (see Section 12.3). 1230 Therefore, the K bit is always set to 1. 1232 If the GRE Sequence Number field is used, then the value of the K 1233 bit is set to 1. Otherwise, its value is set to zero. 1235 12.2 Protocol Type field 1237 The Protocol Type field is set to a number to be allocated by IEEE 1238 for the purpose of encapsulating ATM PW over GRE. 1240 12.3 Key Field 1242 The Key field contains a four octet number which is inserted by the 1243 transmitting PE. The Key field is used by the receiving PE for 1244 identifying an individual ATM PW within a GRE/IP tunnel. Multiple 1245 PWs with unique GRE Keys can be multiplexed into a GRE/IP tunnel. 1246 The method by which the Key field value is negotiated between the 1247 transmitting PE and a receiving PE is further study. 1249 12.4 GRE Sequence Number Field 1251 If the Sequence Number Present bit is set to 1, then it indicates 1252 that the Sequence Number field is present in the GRE header. 1253 Otherwise, the Sequence Number field is not present in the GRE 1254 header. The use of the Sequence Number field MUST comply to [14]. 1256 A specific ATM PWE network may choose to rely on the GRE protocol to 1257 track in-order delivery of ATM PW packets. Another way of tracking 1258 in-order delivery is to use the PW Sequence number field as 1259 explained in Section 5.1. 1261 13 Security Considerations 1263 This draft does not introduce any new security considerations to IP, 1264 L2TP or MPLS. 1266 14 Intellectual Property Disclaimer 1268 This document is being submitted for use in IETF standards 1269 discussions. 1271 15 References 1273 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1274 9, RFC 2026, October 1996. 1276 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1277 Levels", BCP 14, RFC 2119, March 1997 1279 [3] "Frame Relay / ATM PVC Service Interworking Implementation 1280 Agreement (FRF.8.1)", Frame Relay Forum, 2000. 1282 [4] "Frame Based ATM over SONET/SDH Transport (FAST)", af-fb-atm- 1283 0151.000, ATM Forum 2000. 1285 [5] _B-ISDN operation and maintenance principles and functions_, 1286 ITU-T Recommendation I.610, February 1999. 1288 [6] Xiao, X., et al., _Requirements for pseudo Wire Emulation Edge- 1289 to-Edge (PWE3)_, IETF draft-ietf-pwe3-requirements-02.txt, work 1290 in progress, November 2001. 1292 [7] Martini, L., et al., "Encapsulation Methods for Transport of 1293 Layer 2 Frames Over IP and MPLS Networks", draft-martini- 1294 l2circuit-encap-mpls-04.txt, Work in Progress, November 2001. 1296 [8] Koleyni, G., et al., "Requirements and framework for ATM network 1297 interworking over MPLS", draft-koleyni-pwe3-atm-over-mpls- 1298 04.txt, Work in Progress, January 2002. 1300 [9] Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032, 1301 January 2001. 1303 [10] _ATM-MPLS Network Interworking_, af-aic-0178.000, ATM Forum, 1304 2001. 1306 [11] Lau, J., et al., "Layer Two Tunneling Protocol "L2TP"", draft- 1307 ietf-l2tpext-l2tp-base-01.txt, Work in Progress, October 2001. 1309 [12] Townsley, W., et al., "Layer Two Tunneling Layer Two Tunneling 1310 Protocol (L2TP)", RFC 2661, August 1999. 1312 [13] Farinacci, D., et al., "Generic Routing Encapsulation (GRE)", 1313 RFC 2784, March 2000. 1315 [14] Dommety, G., et al., "Key and Sequence Number Extensions to 1316 GRE", RFC 2890, September 2000. 1318 [15] _Traffic Management Specification Version 4.1_, AF-TM-0121.000, 1319 ATM Forum, March 1999. 1321 [16] Le Faucheur, F., et al., "MPLS Support of Differentiated 1322 Services", draft-ietf-mpls-diff-ext-09.txt, Work in Progress, 1323 April 2001. 1325 16 Acknowledgments 1327 The authors like to acknowledge the contribution to this work by 1328 Fred Kaudel and Dr. Khalid Ahmad. 1330 17 Authors' Addresses 1332 John Fischer 1333 Alcatel 1334 600 March Rd 1335 Kanata, ON, Canada. K2K 2E6 1336 Email: john.fischer@alcatel.com 1338 Matthew Bocci 1339 Alcatel 1340 Voyager Place, Shoppenhangers Rd 1341 Maidenhead, Berks, UK SL6 2PJ 1342 Email: matthew.bocci@alcatel.co.uk 1344 Mustapha Aissaoui 1345 Alcatel 1346 600 March Rd 1347 Kanata, ON, Canada. K2K 2E6 1348 Email: mustapha.aissaoui@alcatel.com 1350 Mina Azad 1351 Nortel Networks 1352 P O Box 3511, Station C 1353 Ottawa, ON, Canada K1Y 4H7 1354 Email: mazad@nortelnetworks.com 1356 Ghassem Koleyni 1357 Nortel Networks 1358 P O Box 3511, Station C Ottawa, Ontario, 1359 K1Y 4H7 Canada 1360 Email: ghassem@nortelnetworks.com 1362 Adeel A. Siddiqui 1363 Cable & Wireless 1364 11700 Plaza America Drive 1365 Reston, Virginia 20190, USA 1366 Email: adeel.siddiqui@cwusa.com 1368 Anna Cui 1369 Advanced Fibre Communications 1370 3350 S.W. 148th Ave. Suite 300 1371 Miramar, FL 33027 USA 1372 Email: anna.cui@afc.com 1374 Jim Harford 1375 AdvanceNet Systems 1376 Research Triangle Park, NC 1377 E-mail: harford@atmware.com 1379 Dave Paw 1380 MCI WorldCom 1381 6929 N. Lakewood Ave. 1382 Tulsa, OK 74117 1383 Email: dave.paw@wcom.com 1385 Cheng C. Chen 1386 Network Systems Division, 1387 NEC America, Inc. 1388 6555 N. State Highway 161, 1389 Irving, TX 75039 1390 Email: cchen@necam.com 1392 Sat Sahota 1393 Telus Communications 1394 10020 100 Street 1395 Edmonton Alberta T5J 0N5 1396 Canada 1397 Email: Sat.Sahota@telus.com 1399 Sushil Shelly 1400 Avici Systems 1401 Email: sshelly@avici.com 1403 Eric Letourneau 1404 Bell Canada 1405 700, De LaGauchetiere W. 1406 Montreal, Quebec H3B 4L1 1407 Email: eric.letourneau@bellnexxia.com 1409 Phong Khuu 1410 Turin Networks 1411 1415 N McDowell Blvd 1412 Petaluma, CA 94954 USA 1413 Email: pkhuu@turinnetworks.com 1415 Dave King 1416 General Dynamics 1417 Email: dave.king@gsc.gte.com 1419 Jeffery See 1420 General Dynamics 1421 Email: Jeffery.See@GD-CS.COM 1423 Aditya Sehgal 1424 SBC 1425 530 McCullough Rm 10 M 03 1426 San Antonio, TX 78215 1427 Email: sehgal@tri.sbc.com 1429 Sohel Q. Khan 1430 Sprint 1431 7171 W 95th Street 1432 Overland Park, KS 66212 1433 Email: sohel.khan@mail.sprint.com