idnits 2.17.00 (12 Aug 2021) /tmp/idnits29101/draft-koleyni-pwe3-app-cell-over-psn-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 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 ([15], [17], [18]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 31 has weird spacing: '... at any ti...' == Line 34 has weird spacing: '... The list ...' == Line 264 has weird spacing: '... of the proce...' == Line 265 has weird spacing: '...hin the corre...' == Line 1140 has weird spacing: '...nternet organ...' == (1 more instance...) -- 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 (May 2002) is 7304 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1064, 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: draft-ietf-pwe3-requirements has been published as RFC 3916 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-requirements (ref. '6') == Outdated reference: draft-martini-l2circuit-encap-mpls has been published as RFC 4905 ** 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: draft-ietf-l2tpext-l2tp-base has been published as RFC 3931 -- Possible downref: Non-RFC (?) normative reference: ref. '15' == Outdated reference: draft-ietf-mpls-diff-ext has been published as RFC 3270 -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Normative reference to a draft: ref. '18' Summary: 9 errors (**), 0 flaws (~~), 17 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Working Group Ghassem Koleyni 3 Khalid Ahmad 4 Mina Azad 5 Internet Draft Nortel Networks 7 Expiration Date: November 2002 John Fischer 8 Matthew Bocci 9 Mustapha Aissaoui 10 Alcatel 12 May 2002 14 Applicability Statement for ATM Cell Encapsulation over PSN (the basic 15 mode) 17 < draft-koleyni-pwe3-app-cell-over-psn-01.txt > 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026 [1]. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet- Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 1. Abstract 42 This draft provides an applicability statement for the basic cell 43 mode encapsulation in draft-fischer [18]. 45 Internet draft-koleyni-pwe3-app-cell-over-PSN-01.txt May 2002 47 Draft-fischer describes methods to carry ATM services over IP, L2TP 48 or MPLS. The PSN (e.g., MPLS) is used to transport ATM layer 49 services such as those defined by ITU-T as ATM transfer capabilities 50 [17] and ATM Forum as ATM service categories [15]. The basic 51 requirement is to transparently transport the ATM VCC or VPC service 52 related information (e.g., traffic parameters, QoS, OAM, etc.) over 53 the Pseudo Wire (PW), over the packet network. 55 Table of contents 57 1. Abstract 1 58 2 Conventions used in this document 2 59 3 Introduction 3 60 4 Terminology and abbreviations 3 61 5 Applicability Statement 4 62 5.1 Applicability 4 63 5.2. Implementation and deployment considerations 6 64 5.3. Limitations 6 65 6 ATM Service Encapsulation 6 66 6.1 Length and Sequence Number 7 67 6.1.1 Setting the length field 8 68 6.1.2 Processing the length field 8 69 6.1.3 Setting the sequence number 8 70 6.1.4 Processing the sequence number 8 71 7 ATM VCC Services 9 72 7.1 ATM VCC Cell Transport Service 9 73 7.1.1 ATM OAM Cell Support 11 74 8 ATM VPC Services 12 75 8.1 ATM VPC Cell Transport Services 12 76 8.1.1 OAM Cell Support 13 77 9 ILMI support 14 78 10 QoS considerations14 79 11 ATM Pseudo-Wire over MPLS specific requirements 16 80 11.1 MPLS Transport Label 17 81 11.2 MPLS Pseudo Wire Label 17 82 12 ATM Pseudo-Wire over L2TP specific requirements 17 83 12.1 L2TP Session ID 18 84 12.2 Cookie 18 85 13 ATM Pseudo-Wire over IP specific requirements 19 86 13.1 C, K, and S bits19 87 13.2 Protocol Type field 20 88 13.3 Key Field 20 89 13.4 GRE Sequence Number Field 20 90 14 Security Considerations 20 91 15 Intellectual Property Disclaimer 20 92 16 References20 93 17 Acknowledgments 21 94 18 Authors' Addresses21 96 2 Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [1]. 101 3 Introduction 103 This draft provides an applicability statement for the basic cell 104 mode encapsulation in draft-fischer [18]. 106 Draft-fischer describes methods to carry ATM services over a IP, 107 L2TP or MPLS based PSN. The PSN is used to transport ATM layer 108 services such as those defined by ITU-T as ATM transfer capabilities 109 [17] and by the ATM Forum as ATM service categories [15]. The basic 110 requirement is to transparently transport the ATM VCC or VPC service 111 related information (e.g., traffic parameters, QoS, OAM, etc.) over 112 the Pseudo Wire (PW), over the packet network. 114 Section 5 of this draft presents the applicability statement. 115 Sections 6 to 13 are taken from draft-fischer [18]. They provide the 116 details of the encapsulation methods as well as the OAM, ILMI, and 117 QoS procedures for the basic cell mode. 119 4 Terminology and abbreviations 121 Packet Switched Network - A Packet Switched Network (PSN) is a 122 network using IP, MPLS or L2TP as the unit of switching. 124 Pseudo Wire Emulation Edge to Edge - Pseudo Wire Emulation Edge to 125 Edge (PWE3) is a mechanism that emulates the essential attributes of 126 a service (such as a T1 leased line or Frame Relay) over a PSN. 128 Customer Edge - A Customer Edge (CE) is a device where one end of an 129 emulated service originates and terminates. The CE is not aware that 130 it is using an emulated service rather than a "real" service. 132 Provider Edge - A Provider Edge (PE) is a device that provides PWE3 133 to a CE. 135 Pseudo Wire - A Pseudo Wire (PW) is a connection between two PEs 136 carried over a PSN. The PE provides the adaptation between the CE 137 and the PW. 139 Pseudo Wire PDU - A Pseudo Wire PDU is a PDU sent on the PW that 140 contains all of the data and control information necessary to provide 141 the desired service. 143 PSN Tunnel - A PSN Tunnel is a tunnel inside which multiple PWs can 144 be nested so that they are transparent to core network devices. 146 Ingress - The point where the ATM service is encapsulated into a 147 Pseudo Wire PDU (ATM to PSN direction.) 148 Egress - The point where the ATM service is de-capsulated from a 149 Pseudo Wire PDU (PSN to ATM direction.) 151 CTD Cell Transfer Delay 152 MTU Maximum Transfer Unit 153 OAM Operations, Administration, and Maintenance. 154 PVC Permanent Virtual Connection. An ATM connection that is 155 provisioning via a network management interface. The 156 connection is not signalled. 157 VCC Virtual Circuit Connection. An ATM connection that is 158 switched based on the cell header's VCI. 159 VPC Virtual Path Connection. An ATM connection that is switched 160 based on the cell header's VPI. 162 5 Applicability Statement 164 5.1 Applicability 166 The primary application of ATM cell encapsulation over PSN is the 167 transparent carriage of ATM layer services over a PSN. An ATM layer 168 service is the transfer of ATM cells over a VCC or a VPC between 169 communicating upper layer entities. The nature of the service, as 170 defined by the ATM service category [15] or ATM transfer capability 171 [17], should be preserved. To provide this, the basic requirement of 172 the ATM-PSN interworking function is to map the ATM cells belonging 173 to either VCC or VPC, together with any related OAM and protocol 174 control information into a PW. 176 Two network applications that utilize the cell mode encapsulation 177 described in draft-fischer [18] are: 179 a. The transport of multiservice ATM over a packet core network. 180 Many service providers have multiple service networks and the 181 Operational Support System capabilities needed to support these 182 existing service offerings. Packet Switched Networks (PSNs) 183 have the potential to reduce the complexity of a service 184 provider's infrastructure by allowing virtually any existing 185 digital service to be supported over a single networking 186 infrastructure. 188 The benefits of this model to a service provider are threefold: 190 i. Leveraging of the existing systems and services to 191 provide increased capacity from a packet switched core. 192 ii. Preserving existing network operational processes and 193 procedures used to maintain the legacy services. 194 iii. Using the common packet switched network infrastructure 195 to support both the core capacity requirements of 196 existing services and the requirements of new services 197 supported natively over the packet switched network. 199 b. L2 VPN service over a PSN infrastructure. In this case, VPN 200 sites are connected through ATM VCCs or VPCs, as in today's L2 201 VPNs. The basic cell encapsulation allows the VPN service 202 provider to transparently extend this L2 connectivity over its 203 PSN while still providing the contracted SLS with the VPN 204 customer. The advantage is for the service provider to combine 205 L2 and L3 services over the same PSN. 207 Figure 1 shows the reference model for carrying ATM services over a 208 PSN. This model is adapted from [6]. 210 |<------- Pseudo Wire ------>| 211 | | 212 | |<-- PSN Tunnel -->| | 213 V V V V 214 ATM Service+----+ +----+ ATM Service 215 +-----+ | | PE1|==================| PE2| | +-----+ 216 | |----------|............PW1.............|----------| | 217 | CE1 | | | | | | | | CE2 | 218 | |----------|............PW2.............|----------| | 219 +-----+ | | |==================| | | +-----+ 220 ^ | +----+ +----+ | ^ 221 | | Provider Provider | | 222 | | Edge 1 Edge 2 | | 223 | | 224 |<-------------- Emulated Service ---------------->| 226 Customer Customer 227 Edge 1 Edge 2 229 Figure 1: ATM-over-PSN Service Reference Model 231 An ATM VCC or VPC is carried over a PW. The PW corresponding to any 232 VCC or VPC may be further tunneled in a transport PSN tunnel to 233 achieve multiplexing gain and bandwidth efficiency. 235 When the QoS considerations in Section 10 are respected, this ATM 236 over PSN service provides end users with the same quality of service 237 on any given VPC or VCC as per the QoS commitments in the ATM 238 service traffic contract. 240 One important consideration to make when interworking is to allow 241 OAM information to be treated as in the original network. The 242 interworking function allows this transparency while performing cell 243 encapsulation. 245 Resource management cells are used extensively in certain service 246 categories like ABR. Encapsulating ATM cells to PW allows this 247 capability to be kept. 249 Cell Loss priority (CLP) is used to provide discard information and 250 Payload Type Indicator (PTI) provides information regarding the 251 payload being transported. Information on both of these is obtained 252 from the ATM cell header. CLP and PTI are both part of the service 253 specific information fields. 255 Concatenation of ATM cells belonging to a VCC or a VPC provides 256 added bandwidth efficiency while preserving the specific information 257 (CLP/PTI) of each cell. 259 5.2. Implementation and deployment considerations 261 Although the Single ATM cell encapsulation provides the simplest way 262 for encapsulating ATM cells within a single MPLS packet, it lacks 263 bandwidth efficiency. This can be improved substantially by the use 264 of the procedures enabling cells from any given VCC or VPC to be 265 concatenated within the corresponding ATM PW. 267 5.3. Limitations 269 Cell encapsulation only supports point-to-point LSPs. Multi- point- 270 to-point and point-to-multi-point are for further study (FFS). 272 When PSN is MPLS network, to have bi-directional connectivity, as 273 required in ATM, two LSPs should be configured, one for each 274 direction (ATM-to-MPLS and MPLS-to-ATM) of the ATM connection. 276 The number of concatenated ATM cells is limited by the MTU (Maximum 277 Transfer Unit) size and the cell transfer delay (CTD) and cell delay 278 variation (CDV) objectives. 280 6 ATM Service Encapsulation 282 This section describes the general encapsulation format for ATM over 283 PSN pseudo wires, such as IP, L2TP, or MPLS. The specifics pertaining 284 to each packet technology are covered in later sections. All 285 encapsulation formats and procedures contained in the following 286 sections are from draft-fischer [18]. 288 Figure 2 provides a general format for encapsulation of ATM cells 289 into packets. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | PSN Transport Header (As Required) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Pseudo Wire Header | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Optional Length and Sequence Number | ATM Specific | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | ATM Service Payload | 302 Internet draft-koleyni-pwe3-app-cell-over-PSN-01.txt May 2002 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Figure 2: General format for ATM encapsulation over PSNs 309 The PSN Transport Header depends on the packet technology: IP, L2TP 310 or MPLS. This header is used to transport the encapsulated ATM 311 information through the packet switched core. This header is always 312 present if the Pseudo Wire is MPLS. 314 The Pseudo Wire Header depends on the packet technology: IP, L2TP or 315 MPLS. It identifies a particular ATM service within the PSN tunnel. 317 The Length and Sequence Number is inserted after the Pseudo Wire 318 Header. This field is optional. 320 The ATM Specific Header is inserted before the ATM service payload. 321 The ATM Specific Header contains control bits needed to carry the 322 service. These are defined in the ATM service descriptions below. 323 The length of ATM specific header may not always be one octet. It 324 depends on the service type. 326 The ATM payload octet group is the payload of the service that is 327 being encapsulated. 329 6.1 Length and Sequence Number 331 The length and sequence number are not required for all services. 332 Length and sequence number are to satisfy these requirements. 334 - Sequentiality may need to be preserved. 335 - Small packets may need to be padded in order to be transmitted on a 336 medium where the minimum transport unit is larger than the actual 337 packet size. 339 The one-octet Length indicates length of the packet payload that 340 includes, length of the length field, Sequence number length, the ATM 341 specific header length and the payload length (i.e., Pseudo Wire 342 PDU). The Length field is set to 0 by the ingress PE if not used and 343 is ignored by the egress PE. 345 If the Pseudo Wire traverses a network link that requires a minimum 346 frame size such as Ethernet as a practical example, with a minimum 347 frame size of 64 octets, then such links will apply padding to the 348 Pseudo Wire PDU to reach its minimum frame size. In this case the 349 length field MUST be set to the PDU length. A mechanism is required 350 for the egress PE to detect and remove such padding. 352 The Sequence Number is a 2-octet field that may be used to track 353 packet order delivery. This field is set to 0 by the ingress PE if 354 not used and is ignored by the egress PE. The sequence number space 355 is a 16-bit, unsigned circular space. Processing of the sequence 356 number field is OPTIONAL. 358 In all cases the egress PE MUST be aware of whether the ingress PE 359 will send the length and sequence number over a specific Pseudo Wire. 360 This may be achieved using static configuration or using Pseudo Wire 361 specific signaling. 363 Length field is not required for the cell mode. 365 6.1.1 Setting the length field 367 The length field is required to enable the egress PE to remove any 368 padding that may have resulted if the pseudo-wire traversed a network 369 link that enforces a minimum frame size (e.g. Ethernet). Ethernet 370 applies padding to frames that are smaller than 64 bytes, where this 371 includes a minimum of 18 bytes for the Ethernet header and trailer. 373 The length field represents the size of the packet in bytes including 374 the length, sequence number, ATM specific header and ATM service 375 payload. If the size of the packet is larger than can be 376 represented by the length field, the field MUST be set to 0. In 377 addition, the length field MAY be set to 0 if the size of the packet 378 prevents any padding from being applied. 380 The AAL5 SDU Frame service is the only service that can generate 381 packets smaller than the Ethernet minimum and MUST set the length 382 field accordingly. The length field MUST either be set to the size 383 of the packet if the size is less than 46 bytes or to 0. 385 All cell transport services MUST always set the length field to 0 to 386 indicate to the remote PE that no padding was applied. 388 6.1.2 Processing the length field 390 Since length field is not used for cell mode, no processing is 391 required. 393 6.1.3 Setting the sequence number 395 The following procedures SHOULD be used by the ingress PE if 396 sequencing is desired for a given ATM service: 398 - the initial PDU transmitted on the Pseudo Wire MUST use sequence 399 number 1 400 - the PE MUST increment the sequence number by one for each 401 subsequent PDU 402 - when the transmit sequence number reaches the maximum 16 bit value 403 (65535) the sequence number MUST wrap to 1 405 If the ingress PE does not support sequence number processing, then 406 the sequence number field in the control word MUST be set to 0. 408 6.1.4 Processing the sequence number 409 If the egress PE supports receive sequence number processing, then 410 the following procedures SHOULD be used: 412 When an ATM service is initially created, the "expected sequence 413 number" associated with it MUST be initialized to 1. 415 When a PDU is received on the Pseudo Wire associated with the ATM 416 service, the sequence number SHOULD be processed as follows: 418 - if the sequence number on the packet is 0, then the PDU passes the 419 sequence number check 421 - otherwise if the PDU sequence number >= the expected sequence 422 number and the PDU sequence number - the expected sequence number < 423 32768, then the PDU is in order. 425 - otherwise if the PDU sequence number < the expected sequence 426 number and the expected sequence number - the PDU sequence number >= 427 32768, then the PDU is in order. 429 - otherwise the PDU is out of order. 431 If a PDU passes the sequence number check, or is in order then, it 432 can be delivered immediately. If the PDU is in order, then the 433 expected sequence number SHOULD be set using the algorithm: 435 expected_sequence_number := PDU_sequence_number + 1 mod 2**16 436 if (expected_sequence_number = 0) 437 then expected_sequence_number := 1; 439 Pseudo Wire PDUs that are received out of order MAY be dropped or 440 reordered at the discretion of the egress PE. 442 If the egress PE does not support receive sequence number processing, 443 then the sequence number field MAY be ignored. 445 7 ATM VCC Services 447 This section defines ATM cell VCC services that may be supported over 448 the PSN. 450 7.1 ATM VCC Cell Transport Service 452 The VCC cell transport service is characterized by the mapping of a 453 single ATM VCC (VPI/VCI) to a Pseudo Wire. This service is fully 454 transparent to the ATM Adaptation Layer. The VCC single cell 455 transport service is MANDATORY. 457 This service MUST use the following encapsulation format: 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | PSN Transport Header (As Required) | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Pseudo Wire Header | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Optional Length and Sequence Number |M|V|Res| PTI |C| 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 | ATM Cell Payload ( 48 bytes ) | 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 3: Single ATM VCC Cell Encapsulation 475 * M (transport mode) bit 477 Bit (M) of the control byte indicates whether the packet contains an 478 ATM cell or a frame payload. If set to 0, the packet contains an ATM 479 cell. If set to 1, the PDU contains an AAL5 payload. 481 * V (VCI present) bit 483 Bit (V) of the control byte indicates whether the VCI field is 484 present in the packet. If set to 1, the VCI field is present for the 485 cell. If set to 0, no VCI field is present. In the case of a VCC, 486 the VCI field is not required. For VPC, the VCI field is required 487 and is transmitted with each cell. 489 * Reserved bits 491 The reserved bits should be set to 0 at the transmitter and ignored 492 upon reception. 494 * PTI Bits 496 The 3-bit Payload Type Identifier (PTI) incorporates ATM Layer PTI 497 coding of the cell. These bits are set to the value of the PTI of 498 the encapsulated ATM cell. 500 * C (CLP) Bit 502 The Cell Loss Priority (CLP) field indicates CLP value of the 503 encapsulated cell. 505 For increased transport efficiency, the ingress PE SHOULD be able to 506 encapsulate multiple ATM cells into a Pseudo Wire PDU. The ingress 507 and egress PE SHOULD agree to a maximum number of cells in a single 508 Pseudo Wire PDU. This agreement may be accomplished via a Pseudo 509 Wire specific signaling mechanism or via static configuration. 511 When multiple cells are encapsulated in the same PSN packet, the ATM 512 control byte MUST be repeated for each cell. This means that 49 513 bytes are used to encapsulate each 53 byte ATM cell. 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | PSN Transport Header (As Required) | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Pseudo Wire Header | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Optional Length and Sequence Number |M|V|Res| PTI |C| 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | | 525 | ATM Cell Payload ( 48 bytes ) | 526 | | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 |M|V|Res| PTI |C| | 529 +-+-+-+-+-+-+-+-+ | 530 | ATM Cell Payload ( 48 bytes ) | 531 | | 532 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | | 534 +-+-+-+-+-+-+-+-+ 536 Figure 4: Multiple ATM VCC Cell Encapsulation 538 7.1.1 ATM OAM Cell Support 540 When configured for a VCC cell relay service, both PE's SHOULD act as 541 a VC switch in accordance with the OAM procedures defined in [5]. 543 The PEs MUST be able to pass the following OAM cells transparently: 544 - F5 AIS (segment and end-to-end) 545 - F5 RDI (segment and end-to-end) 546 - F5 loopback (segment and end-to-end) 547 - Resource Management 548 - Performance Management 549 - Continuity Check 550 - Security 552 The PEs SHALL use the ATM VCC cell mode encapsulation (Section 6.1) 553 when passing an OAM cell. The OAM cell MAY be encapsulated together 554 with other user data cells if multiple cell encapsulation is used. 556 The ingress PE SHOULD be able to generate an F5 AIS upon reception of 557 a corresponding F4 AIS or lower layer defect (such as LOS). 559 The egress PE SHOULD be able to generate an F5 AIS based on a PSN 560 failure (such as a PSN tunnel failure or LOS on the PSN port). 562 If the ingress PE cannot support the generation of OAM cells, it MAY 563 notify the egress PE using a Pseudo Wire specific maintenance 564 mechanism (to be defined). For example, the ingress PE MAY withdraw 565 the Pseudo Wire (VC label) associated with the service. Upon 566 receiving such a notification, the egress PE SHOULD generate the 567 appropriate F5 AIS. 569 8 ATM VPC Services 571 The VPC service is defined by mapping a single VPC (VPI) to a Pseudo 572 Wire. As such it emulates as Virtual Path cross-connect across the 573 PSN. All VCCs belonging to the VPC are carried transparently by the 574 VPC service. 576 The egress PE may choose to apply a different VPI other than the one 577 that arrived at the ingress PE. The egress PE MUST choose the 578 outgoing VPI based solely upon the Pseudo Wire header. As a VPC 579 service, the egress PE MUST NOT change the VCI field. 581 8.1 ATM VPC Cell Transport Services 583 The ATM VPC cell transport service is OPTIONAL. 585 This service MUST use the following cell mode encapsulation: 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | PSN Transport Header (As Required) | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Pseudo Wire Header | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Optional Length and Sequence Number |M|V|Res| PTI |C| 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | VCI | | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 598 | | 599 | ATM Cell Payload ( 48 bytes ) | 600 | | 601 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Figure 5: Single Cell VPC Encapsulation 607 The ATM control byte contains the same information as in the VCC 608 encapsulation except for the VCI field. 610 * VCI Bits 612 The 16-bit Virtual Circuit Identifier (VCI) incorporates ATM Layer 613 VCI value of the cell. 615 For increased transport efficiency, the ingress PE SHOULD be able to 616 encapsulate multiple ATM cells into a Pseudo Wire PDU. The ingress 617 and egress PE SHOULD agree to a maximum number of cells in a single 618 Pseudo Wire PDU. This agreement may be accomplished via a Pseudo 619 Wire specific signaling mechanism or via static configuration. 621 When multiple ATM cells are encapsulated in the same PSN packet, the 622 ATM control byte MUST be repeated for each cell. This means that 51 623 bytes are used to encapsulate each 53 byte ATM cell. 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | PSN Transport Header (As Required) | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | Pseudo Wire Header | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Optional Length and Sequence Number |M|V|Res| PTI |C| 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | VCI | | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 636 | | 637 | ATM Cell Payload (48 bytes) | 638 | | 639 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | |M|V|Res| PTI |C| VCI | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | VCI | | 643 +-+-+-+-+-+-+-+-+ | 644 | ATM Cell Payload (48 bytes) | 645 | | 646 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | | 648 +-+-+-+-+-+-+-+-+ 650 Figure 6: Multiple Cell VPC Encapsulation 652 8.1.1 OAM Cell Support 654 When configured for a VPC cell relay service, both PE's SHOULD act as 655 a VP cross-connect in accordance with the OAM procedures defined in 656 [5]. 658 The PEs MUST be able to pass the following OAM cells transparently: 659 - F4 AIS (segment and end-to-end) 660 - F4 RDI (segment and end-to-end) 661 - F4 loopback (segment and end-to-end) 662 - F5 AIS (segment and end-to-end) 663 - F5 RDI (segment and end-to-end) 664 - F5 loopback (segment and end-to-end) 665 - Resource Management 666 - Performance Management 667 - Continuity Check 668 - Security 670 The PEs SHALL use the ATM VPC cell encapsulation (Section 7.1) when 671 passing an OAM cell. The OAM cell MAY be encapsulated together with 672 other user data cells if multiple cell encapsulation is used. 674 The ingress PE MUST be able to generate an F4 AIS upon reception of a 675 lower layer defect (such as LOS). 677 The egress PE SHOULD be able to generate an F4 AIS based on a PSN 678 failure (such as a PSN tunnel failure or LOS on the PSN port). 680 If the ingress PE cannot support the generation of OAM cells, it MAY 681 notify the egress PE using a Pseudo Wire specific maintenance 682 mechanism to be defined. For example, the ingress PE MAY withdraw 683 the Pseudo Wire (VC label) associated with the service. Upon 684 receiving such a notification, the egress PE SHOULD generate the 685 appropriate F4 AIS. 687 9 ILMI support 689 Integrated Local Management Interface (ILMI) typically is used in ATM 690 networks for neighbor resource availability detection, address 691 registration, auto-configuration, and loss of connectivity detection. 692 ILMI messages are sent as SNMP PDU's within ATM AAL5 cells. 694 A PE MAY provide an ATM ILMI to its attached CE. If the ingress PE 695 receives an ILMI message indicating that the ATM service (VCC or VPC) 696 is down, it MAY use a Pseudo Wire specific mechanism to notify the 697 egress PE of the ATM service status. For example, a PE using an MPLS 698 based Pseudo Wire may withdraw its advertised VC label. 700 When receiving such a notification, the egress PE MAY use ILMI to 701 signal the ATM service status to its attached CE. 703 10 QoS considerations 705 This section provides guidelines for the provision of QoS for the 706 individual ATM PWs over the PSN. The objective is to provide the 707 ability to support the traffic contracts and the QoS commitments made 708 to the ATM connections [8]. This section is informational and the 709 provided guidelines SHOULD be treated as good practices and the 710 mappings as examples only. 712 When ATM PW service is configured over a PSN, each ATM service 713 category SHOULD be mapped to a compatible class of service in the PSN 714 network. A compatible class of service maintains the integrity of 715 the service end to end. For example, the CBR service category SHOULD 716 be mapped to a class of service with stringent loss and delay 717 objectives. If the PSN implements the IP Diff-Serv framework to 718 provide QoS classes, a class of service based on the EF PHB is a good 719 candidate. 721 Furthermore, ATM service categories have support for multiple 722 conformance definitions. A conformance definition specifies the 723 conformance of cells of a connection at an interface, e.g., public 724 UNI, in relation to the conformance algorithm and corresponding 725 parameters specified in the connection traffic descriptor [15]. For 726 example, the conformance definition specifies if the requested QoS 727 parameters, e.g., CLR, apply to the aggregate CLP0+1 conforming cell 728 flow or to the CLP0 conforming flow only. Thus, the conformance 729 definition SHOULD be respected in the selected PSN class of service. 731 For example, a connection CLP1 cell flow in a VBR.3 conformance 732 definition is treated as excess traffic in the ATM network and thus 733 has no QoS guarantees associated with it. This flow SHOULD be 734 provided a treatment no better than the treatment of the CLP0 cell 735 flow in the PSN. This does not mean however that the PSN network 736 should mirror the various conformance definitions of the ATM service 737 categories. 739 In the remainder of this section, it is assumed that the PSN 740 implements IP Diff-Serv framework to provide QoS. 742 All ATM traffic management functions specified in [15] are applicable 743 for the ATM part of the ATM PW in the ingress PE and egress PE. In 744 the ATM-to-PSN direction, each ATM connection MAY be policed and/or 745 shaped to conform to its traffic descriptor in the ATM endpoint of 746 the ATM PW in the PE. Whenever allowed by the conformance 747 definition, a non-conforming CLP0 cell may be turned into a CLP1 cell 748 and becomes conforming. Connection admission SHOULD be applied to 749 make sure sufficient resources are available to carry the ATM PW over 750 the transport LSP. The mapping of ATM service category and 751 conformance definition to the Diff-Serv PHB determines the outgoing 752 PHB. This is the PHB to be applied to the cells or packets of the 753 ATM PW in the ingress PE and egress PE and inside the PSN. The PSN 754 transport header of the outgoing PSN packet SHOULD be marked to 755 identify the selected PHB. This consists of marking the DS field in 756 the IP header in the case of IP PSN, or the EXP field in the 757 transport shim header in the case of a MPLS PSN. 759 Figure 9 provides an example of mapping ATM service category and 760 conformance definition to a Diff-Serv PHB. 762 ATM Service Conformance CLP Diff-Serv DSCP 763 Category Definition Setting PHB Marking 764 ---------------------------------------------------------------- 765 CBR CBR.1 0/1 EF 101110 766 rt-VBR VBR.1 0/1 EF 101110 767 VBR.2/VBR.3 0 AF11 001010 768 1 AF12 001100 769 nrt-VBR VBR.1 0/1 AF21 010010 770 VBR.2/VBR.3 0 AF21 010010 771 1 AF22 010100 772 ABR ABR 0 AF31 011010 773 UBR+MDCR UBR.1/UBR.2 0/1 AF31 011010 774 GFR GFR.1/GFR.2 0 AF31 011010 775 1 AF32 011100 776 UBR UBR.1/UBR.2 0/1 DF 000000 778 Figure 9: Example of ATM Service Category to PHB Mapping 780 Note that an alternative mapping may not distinguish between the 781 conformance definitions in a given ATM service category. In this 782 case, the CLP0 and CLP1 flows of a ATM connection are provided with 783 the same QoS in the PSN. As an example, all conformance definitions 784 of the nrt-VBR service category MAY be mapped to the AF21 PHB in 785 Figure 9. 787 When the PSN is MPLS based, the selected PHB for the ATM PW is 788 conveyed in different ways depending if the transport LSP is an L- 789 LSP or an E-LSP [16]. In the case of an L-LSP, the PHB Scheduling 790 Class is signaled at the transport LSP establishment and is therefore 791 inferred from the transport label value. The Drop Precedence of the 792 individual PW packets is conveyed in the EXP field of the transport 793 LSP shim header. In the case of an E-LSP, the PHB is conveyed in the 794 EXP field of the transport LSP shim header. The actual values to be 795 marked in the EXP field to reflect the example in Figure 9 is outside 796 the scope of this document. 798 In the presence of congestion, the PE MAY mark the EFCI bit and MAY 799 perform selective cell discard based on CLP setting, if allowed by 800 the conformance definition, and in accordance with [15]. The method 801 used to transfer the CLP and EFCI information of the individual cells 802 into the ATM specific field of the PW packet is described in details 803 in sections 7 and 8. 805 In the PSN-to-ATM direction, the ATM service category and conformance 806 definition is obtained from the context accessed via the pseudo wire 807 label of the ATM PW. The information needed to reconstruct the ATM 808 header, including the setting of the CLP and EFCI fields, for the 809 individual cells is contained in the ATM specific information field 810 of the PW packet. The method used to determine the CLP and EFCI 811 information of the individual cells from the ATM specific information 812 field of the PW packet is described in details in sections 6 and 7. 814 11 ATM Pseudo-Wire over MPLS specific requirements 816 Figure 7 provides a general format for interworking between ATM and 817 MPLS. The ATM information is encapsulated inside two MPLS labels as 818 defined in [9]. 820 The Pseudo Wire Endpoint uses a unique MPLS label, the pseudo wire 821 label, to identify each direction of an ATM connection. This label 822 allows the PWE to access context information for the connection. As 823 an example, the context may contain the information regarding 824 connection type such as VCC or VPC or VPI/VCI value that need to be 825 inserted into the ATM cell header in the MPLS-to-ATM direction. 827 0 1 2 3 828 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 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | MPLS Transport Label | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | MPLS Pseudo Wire Label | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Optional Length and Sequence Number | ATM Specific | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | ATM Service Payload | 837 | | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 Figure 7: Format for ATM PW over a MPLS PSN 842 11.1 MPLS Transport Label 844 The 4-octet MPLS transport label identifies an LSP used to transport 845 traffic between two ATM-MPLS pseudo wire endpoints. This label is 846 used to switch the transport LSP between core LSRs. Since an MPLS LSP 847 is unidirectional, for the case of bi-directional traffic there will 848 be two different pseudo wire LSPs, one for each direction of the 849 connection. These may have different label values. Setting of the 850 EXP and TTL is for further study. The S bit is set to 0 since this 851 is not the last label in the MPLS label stack. 853 11.2 MPLS Pseudo Wire Label 855 The 4-octet interworking label uniquely identifies one pseudo wire 856 LSP, carried inside a MPLS transport LSP. The pseudo wire label has 857 the structure of a standard MPLS shim header. More than one pseudo 858 wire LSP may be supported by one MPLS transport LSP. The pseudo wire 859 endpoint provides the association between the ATM connection or the 860 ATM port and MPLS LSP by means of the 20-bit label field of the 861 pseudo wire LSP. In this association, in the ATM-to-MPLS direction a 862 mapping of the VCI/VPI of the ATM connection or the Port to the 20- 863 bit label is performed, while in the MPLS-to-ATM direction the 20-bit 864 label is mapped to a VPI/VCI of the ATM connection or to a Port. This 865 association is signalled or provisioned between the two pseudo-wire 866 endpoints. 868 Since an MPLS LSP is unidirectional, for the case of bi-directional 869 ATM VCCs there will be two different pseudo wire LSPs, one for each 870 direction of the connection. These may have different label values. 871 Setting of the EXP and TTL is for further study. The S bit is set to 872 1 since this is the last label in the bottom of the MPLS stack. The 873 pseudo wire label is not visible to the LSRs within the MPLS core 874 network. 876 12 ATM Pseudo-Wire over L2TP specific requirements 878 Figure 8 provides a general format for interworking between ATM and 879 L2TP. This draft refers to L2TPv3, or L2TP base, as described in 880 [11]. L2TP base extends the original L2TP [12] to operate directly 881 over an IP PSN and to further generalize the control procedures to 882 carry any tunneled Layer 2 protocol other than PPP. Any further 883 reference to L2TP in this document assumes L2TPv3 or L2TP base as 884 specified in [11]. 886 The ATM information is encapsulated inside a L2TP tunnel packet. The 887 L2TP tunnel is setup over an IPv4 PSN. The IPv4 protocol in the IPv4 888 header is set to 115 to indicate that the L2TP packet is encapsulated 889 in an IPv4 packet [11]. Furthermore, L2TP can operate over IP or over 890 UDP. The use of either mode is outside the scope of this document. 891 The encapsulation format shown in Figure 11 represents the common 892 headers for carrying L2TP packet over UDP and IP. If UDP is used, 893 additional header information is required and is defined in [11]. 895 The Pseudo Wire Endpoint uses a unique L2TP session ID to identify 896 each direction of an ATM connection. This session ID is local to each 897 PE and allows the PWE to identify each ATM PW in the L2TP tunnel in 898 order to access context information for the ATM connection. As an 899 example, the context may contain the information regarding connection 900 type such as VCC or VPC or VPI/VCI value that need to be inserted 901 into the ATM cell header in the L2TP-to-ATM direction. Multiple PWs 902 with locally unique Session IDs at each PE can be multiplexed into a 903 L2TP tunnel. 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | L2TP Session ID | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Cookie (optional, up to 64 bits) | 911 | | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Optional Length and Sequence Number | ATM Specific | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | ATM Service Payload | 916 | | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 Figure 8: Format for ATM PW over a L2TP PSN 921 12.1 L2TP Session ID 923 This is 32-bit field containing a non-zero identifier for a session, 924 or a PW in this case. L2TP sessions are named by identifiers that 925 have local significance only at each PE [11]. 927 Each PE for the life of the session will give different Session IDs 928 the same PW. Multiple PWs with locally unique Session IDs at each PE 929 can be multiplexed into a L2TP tunnel. When the L2TP control 930 connection is used for session establishment, Session IDs are 931 selected and exchanged as Local Session ID Attribute Value Pairs 932 (AVPs) during the creation of a PW. A session ID of zero is reserved 933 for the carriage of L2TP control messages [11]. 935 12.2 Cookie 936 The optional Cookie field contains a variable length (maximum 64 937 bits), long word-aligned value used to check the association of a 938 received packet with the PW identified by the Session ID. The Cookie 939 MUST be configured with a random value utilizing all bits in the 940 field [11]. The Cookie provides an additional level of guarantee, 941 beyond the Session ID lookup, that a packet has been directed to the 942 proper PW identified by the Session ID. 944 When the L2TP control connection is used for PW session 945 establishment, random Cookie values are selected and exchanged as 946 Assigned Cookie AVPs during the creation of a PW. The maximum size 947 of the Cookie field is 64 bits. 949 13 ATM Pseudo-Wire over IP specific requirements 951 Figure 9 provides a general format for carrying an ATM PW over an IP 952 PSN. This is an alternative encapsulation to the one using L2TP, as 953 described in Section 11. The GRE encapsulation is used as specified 954 in [13] and [14]. The IPv4 protocol in the IPv4 header is set to 47 955 to indicate that the GRE packet is encapsulated in an IPv4 packet 956 [13]. 958 The ATM information is encapsulated inside a GRE/IP packet. The 959 Pseudo Wire Endpoint uses a unique GRE Key to identify each direction 960 of an ATM connection. As an example, the context may contain the 961 information regarding connection type such as VCC or VPC or VPI/VCI 962 value that need to be inserted into the ATM cell header in the IP-to- 963 ATM direction. Multiple PWs with unique GRE Keys can be multiplexed 964 into a GRE/IP tunnel. 966 0 1 2 3 967 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 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | IPv4 Header (N words) | 970 | | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 |C| |K|S| Reserved0 | Ver | Protocol Type | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Key | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | GRE Sequence Number (Optional) | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Optional Length and Sequence Number | ATM Specific | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | ATM Service Payload | 981 | | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Figure 9: Format for ATM PW over an IP PSN 986 13.1 C, K, and S bits 988 The Checksum field in the GRE header is not required for carrying 989 ATM PW over IP PSN. Therefore the C bit is set to zero. 991 The Key field in the GRE header is always used (see Section 12.3). 992 Therefore, the K bit is always set to 1. 994 If the GRE Sequence Number field is used, then the value of the K 995 bit is set to 1. Otherwise, its value is set to zero. 997 13.2 Protocol Type field 999 The Protocol Type field is set to a number to be allocated by IEEE 1000 for the purpose of encapsulating ATM PW over GRE. 1002 13.3 Key Field 1004 The Key field contains a four-octet number that is inserted by the 1005 transmitting PE. The Key field is used by the receiving PE for 1006 identifying an individual ATM PW within a GRE/IP tunnel. Multiple PWs 1007 with unique GRE Keys can be multiplexed into a GRE/IP tunnel. The 1008 method by which the Key field value is negotiated between the 1009 transmitting PE and a receiving PE is further study. 1011 13.4 GRE Sequence Number Field 1013 If the Sequence Number Present bit is set to 1, then it indicates 1014 that the Sequence Number field is present in the GRE header. 1015 Otherwise, the Sequence Number field is not present in the GRE 1016 header. The use of the Sequence Number field MUST comply to [14]. 1018 A specific ATM PWE network may choose to rely on the GRE protocol to 1019 track in-order delivery of ATM PW packets. Another way of tracking 1020 in-order delivery is to use the PW Sequence number field as explained 1021 in Section 5.1. 1023 14 Security Considerations 1025 This draft does not introduce any new security considerations to IP, 1026 L2TP or MPLS. 1028 15 Intellectual Property Disclaimer 1030 This document is being submitted for use in IETF standards 1031 discussions. 1033 16 References 1035 [1] IETF BCP 9, RFC 2026 (1996), The Internet Standards Process -- 1036 Revision 3. 1038 [2] IETF BCP 14, RFC 2119 (1997), Key words for use in RFCs to 1039 Indicate Requirement Levels. 1041 [3] Frame Relay Forum FRF.8.1 (2000), Frame Relay / ATM PVC Service 1042 Interworking Implementation Agreement. 1044 [4] ATM Forum af-fb-atm- 0151.000 (2000), Frame Based ATM over 1045 SONET/SDH Transport (FAST). 1047 [5] ITU-T Recommendation I.610, (1999), B-ISDN operation and 1048 maintenance principles and functions. 1050 [6] IETF draft-ietf-pwe3-requirements-02.txt (November 2001, work in 1051 progress,), Requirements for pseudo Wire Emulation Edge-to-Edge 1052 (PWE3). 1054 [7] IETF draft-martini-l2circuit-encap-mpls-04.txt Martini (November 1055 2001, Work in Progress), Encapsulation Methods for Transport of Layer 1056 2 Frames Over IP and MPLS Networks. 1058 [8] IETF draft-koleyni-pwe3-atm-over-mpls-04.txt (January 2002, Work 1059 in Progress), Requirements and framework for ATM network interworking 1060 over MPLS 1062 [9] IETF RFC 3032 (2001), MPLS Label Stack Encoding. 1064 [10] ATM Forum af-aic-0178.000 (2001), ATM-MPLS Network Interworking. 1066 [11] IETF draft-ietf-l2tpext-l2tp-base-01.txt (October 2001, Work in 1067 Progress), Layer Two Tunneling Protocol (L2TP). 1069 [12] IETF RFC 2661 (1999), Layer Two Tunneling Layer Two Tunneling 1070 Protocol (L2TP). 1072 [13] IETF RFC 2784(2000), Generic Routing Encapsulation (GRE). 1074 [14] IETF RFC 2890(2000), Key and Sequence Number Extensions to GRE. 1076 [15] ATM Forum Specification af-tm-0121.000 (1999), Traffic 1077 Management Specification Version 4.1. 1079 [16] IETF draft-ietf-mpls-diff-ext-09.txt (April 2001, Work in 1080 Progress), MPLS Support of Differentiated Services. 1081 . 1082 [17] ITU-T Recommendation I.371 (2000), Traffic control and 1083 congestion control in B-ISDN. 1085 [18] IETF draft-fischer-pwe3-atm-service-03.txt(March 2002, work in 1086 progress), PWE3: ATM service description 1088 17 Acknowledgments 1090 The authors like to acknowledge the contribution to this work by TBD. 1092 18 Authors' Addresses 1093 Ghassem Koleyni 1094 Nortel Networks 1095 P O Box 3511, Station C Ottawa, Ontario, 1096 K1Y 4H7 Canada 1097 Email: ghassem@nortelnetworks.com 1099 Khalid Ahmad 1100 Nortel Networks 1101 P O Box 3511, Station C Ottawa, Ontario, 1102 K1Y 4H7 Canada 1103 Email: kmad@nortelnetworks.com 1105 Mina Azad 1106 Nortel Networks 1107 P O Box 3511, Station C 1108 Ottawa, ON, Canada K1Y 4H7 1109 Email: mazad@nortelnetworks.com 1111 John Fischer 1112 Alcatel 1113 600 March Rd 1114 Kanata, ON, Canada. K2K 2E6 1115 Email: john.fischer@alcatel.com 1117 Matthew Bocci 1118 Alcatel 1119 Voyager Place, Shoppenhangers Rd 1120 Maidenhead, Berks, UK SL6 2PJ 1121 Email: matthew.bocci@alcatel.co.uk 1123 Mustapha Aissaoui 1124 Alcatel 1125 600 March Rd 1126 Kanata, ON, Canada. K2K 2E6 1127 Email: mustapha.aissaoui@alcatel.com 1129 Full Copyright Statement 1131 "Copyright (C) The Internet Society (date). All Rights Reserved. 1132 This document and translations of it may be copied and furnished to 1133 others, and derivative works that comment on or otherwise explain it 1134 or assist in its implementation may be prepared, copied, published 1135 and distributed, in whole or in part, without restriction of any 1136 kind, provided that the above copyright notice and this paragraph 1137 are included on all such copies and derivative works. However, this 1138 document itself may not be modified in any way, such as by removing 1139 the copyright notice or references to the Internet Society or other 1140 Internet organizations, except as needed for the purpose of 1141 developing Internet standards in which case the procedures for 1142 copyrights defined in the Internet Standards process must be 1143 followed, or as required to translate it into