idnits 2.17.1 draft-swallow-pwe3-spvc-iw-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 18 characters in excess of 72. ** The abstract seems to contain references ([PWE3-CP], [L2VPN-SIG], [LDP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 2005) is 7008 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) -- Looks like a reference, but probably isn't: '1' on line 281 == Missing Reference: 'PWE3-ENCAPS' is mentioned on line 575, but not defined == Unused Reference: 'PWE3-ENCAP' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'PWE3-IANA' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'ATM-AINI' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'ATM-UNI' is defined on line 641, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-08) exists of draft-ietf-l2vpn-signaling-00 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-04 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-atm-encap-03 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-04 -- Obsolete informational reference (is this intentional?): RFC 1888 (Obsoleted by RFC 4048) Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group George Swallow 2 Internet Draft Cisco Systems, Inc. 3 Category: Standards Track 4 Expiration Date: August 2005 5 Mickey Spiegel 6 Cisco Systems, Inc. 8 February 2005 10 Soft Permanent Virtual Circuit Interworking between PWE3 and ATM 12 draft-swallow-pwe3-spvc-iw-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, the authors certify that any 17 applicable patent or other IPR claims of which we are aware have been 18 disclosed, and any of which we become aware will be disclosed, in 19 accordance with RFC 3668. 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 5 of RFC3667. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document defines interworking between Private Network Node 45 Interface (PNNI) SPVC signaling and the Label Distribution Protocol 47 [LDP] as extended by [PWE3-CP] and [L2VPN-SIG]. 49 Contents 51 1 Introduction .............................................. 3 52 1.1 Conventions ............................................... 3 53 1.2 Terminology ............................................... 3 54 2 Problem Statement ......................................... 4 55 2.1 Reference Network Diagram ................................. 5 56 3 Requirements .............................................. 5 57 3.1 Configuration ............................................. 6 58 3.2 Redundant ATM/PSN Interfaces .............................. 6 59 3.3 Re-assembly ............................................... 6 60 3.4 No Change to Existing ATM Signaling Protocols ............. 6 61 3.5 Frame Relay and ATM Circuits at the MPLS Network Edge ..... 6 62 4 Non-Requirements .......................................... 7 63 4.1 Frame Relay / ATM Interworking ............................ 7 64 5 Background on identifiers ................................. 7 65 5.1 Pseudowire Identifiers .................................... 7 66 5.2 ATM SPVC Identifiers ...................................... 8 67 6 Proposed Solution ......................................... 9 68 6.1 PSN / ATM Interface ....................................... 9 69 6.2 Signaling ................................................. 9 70 6.3 Mapping Identifiers ....................................... 10 71 6.3.1 Mapping Addresses ......................................... 10 72 6.3.2 Mapping Port and SPVC IEs to AIs .......................... 11 73 6.4 Configuration ............................................. 12 74 6.5 Procedures ................................................ 12 75 6.5.1 Procedures within the ATM Network ......................... 12 76 6.5.2 Procedures for the ME ..................................... 13 77 6.5.3 Procedures for the PME .................................... 13 78 6.5.4 Call Completion ........................................... 14 79 6.6 Handling Re-assembly ...................................... 14 80 7 Issues .................................................... 14 81 8 Security Considerations ................................... 15 82 9 Acknowledgments ........................................... 15 83 10 References ................................................ 15 84 10.1 Normative References ...................................... 15 85 10.2 Informative References .................................... 15 86 /Users/swallow/ietf/pwe3/pwe/atmpwe050220:679: warning: escape character ignored before `' 87 11 Authors' Addresses ........................................ 16 88 12 Full Copyright and Intellectual Property Statements ....... 16 89 1. Introduction 91 In current ATM deployments, Soft Permanent Virtual Connections 92 (SPVCs) are used to provision both Asynchronous Transfer Mode (ATM) 93 Permanent Virtual Channel Connections (PVCC) and Permanent Virtual 94 Path Connections (PVPC) and Frame Relay (FR) PVCCs. 96 Pseudowires over Multiprotocol Label Switching (MPLS) and L2TPv3 PSNs 97 are current being introduced as backbone technologies to carry these 98 same services. Mechanisms are being developed to enable a flexible 99 provisioning model which incorporates elements of the SPVC model in 100 that configuration of the end service exists only at the end-points. 101 These mechanisms are described in [PWE3-CP] and [L2VPN-SIG]. 103 As services are migrated from ATM to PSNs, any reasonable deployment 104 scenario mandates that there be a period of time (possibly protracted 105 or permanent) in which services will need to be established and main- 106 tained between end-users where one end of a circuit is attached to an 107 ATM network and the other end is attached to a PSN. 109 1.1. Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 115 1.2. Terminology 117 PAE Provider ATM Edge, a customer facing node which is part of 118 the ATM network 120 AE ATM Edge, a node of the ATM network which is attached to a 121 node of the MPLS/IP network 123 PSN Packet Switched Network 125 PME Provider MPLS/IP Edge, a customer facing node which is part 126 of the MPLS/IP PSN 128 ME MPLS/IP Edge, a node of the MPLS/IP PSN which is attached to 129 a node of the ATM network 131 AI Attachment Identifier 133 AGI Attachment Group Identifier 134 AII Attachment Individual Identifier 136 SAI Source Attachment Identifier 138 TAI Target Attachment Identifier 140 SAII Source Attachment Individual Identifier 142 TAII Target Attachment Individual Identifier 144 PNNI Private Network-Network Interface 146 UNI User Network Interface 148 AINI ATM Inter-Network Interface 150 PVCC Permanent Virtual Channel Connection 152 PVPC Permanent Virtual Path Connection 154 SPVC Soft Permanent Virtual Connection 156 IE Information Element 158 2. Problem Statement 160 To facilitate the migration of ATM and Frame Relay SPVCs to a PSN 161 carrying pseudowires, a means of interoperating ATM and LDP signaling 162 needs to be defined. Further this interoperation must preserve the 163 essential reasons for using SPVCs, namely, keeping configuration lim- 164 ited to the edge nodes supporting a particular connection and allow- 165 ing the network to be able to recover in the event of the failure of 166 any facility between those two edge nodes. 168 It is also useful to perform reassembly of AAL5 frames of Frame Relay 169 connections at the boundary between the ATM network and the PSN. 170 This serves to reduce dataplane protocol overhead in the PSN. 172 Finally, any solution must not preclude any existing services. In 173 particular, Frame Relay to ATM interworking is recognized to be in 174 wide use. 176 2.1. Reference Network Diagram 178 The diagram below shows an ATM network interfaced to a PSN. A soft 179 PVC is to be set up between the two customer facing edge nodes, PAE, 180 and PME. Two interconnections are shown, to indicate that the con- 181 nection must be routable over either interconnection in the event of 182 the failure of the preferred interconnection. The 'M' (for MPLS/IP 183 PSN) was chosen over 'P' (for PSN) to allow 'P' to stand for 184 provider. 186 _______ _______ 187 / % / % 188 / % +-----+ +-----+ / % 189 / % | | | | / % 190 | |==| AE1 |==| ME1 |==| | 191 +-----+ | | | | | | | | +-----+ 192 | | | ATM | +-----+ +-----+ | MPLS/IP | | | 193 | PAE |==| | | PSN |==| PME | 194 | | | | +-----+ +-----+ | | | | 195 +-----+ | | | | | | | | +-----+ 196 | |==| AE2 |==| ME2 |==| | 197 % / | | | | % / 198 % / +-----+ +-----+ % / 199 %_______/ %_______/ 201 Key: 203 All node acronyms are composed of the following 204 letters 206 P - Provider 207 M - MPLS/IP PSN 208 A - ATM 209 E - Edge 211 Figure 1: Reference Network 213 3. Requirements 215 The purpose of Soft Permanent Virtual Connections is two-fold. First 216 they confine circuit specific configuration to the edge nodes where 217 the user access circuits are terminated. Second they allow the net- 218 work to automatically reroute / re-establish the circuit when fail- 219 ures are encountered. The requirements for this solution follow 220 directly from this as well as some of the common uses of SPVCs. 222 3.1. Configuration 224 All per circuit configuration must be limited to the edge nodes. In 225 particular the solution must not necessitate any per circuit configu- 226 ration on the nodes that support the ATM/PSN interface. 228 3.2. Redundant ATM/PSN Interfaces 230 The solution must support multiple inter-connections between the ATM 231 network and the PSN. Upon failure of an ATM/PSN interface, it must 232 be possible to re-route the SPVCs that had been traversing that 233 interface over other ATM/PSN interfaces. 235 3.3. Re-assembly 237 It must be possible to locate the AAL5 re-assembly at the ME. That 238 is, a ME by default will perform AAL5 re-assembly for Frame Relay 239 SPVCs. The ME's ATM/PSN interface may be configured to not perform 240 re-assembly and leave the job to the target PME, when the target PME 241 supports AAL5 re-assembly for Frame Relay circuits. No per circuit 242 selection need be supported. 244 3.4. No Change to Existing ATM Signaling Protocols 246 It is highly desirable that no changes be required to existing ATM 247 signaling protocols. 249 3.5. Frame Relay and ATM Circuits at the MPLS Network Edge 251 The solution must support both ATM and Frame Relay circuits at the 252 Provider MPLS Edge. For the case of ATM at the PME and Frame Relay 253 at the PAE, Frame Relay to ATM interworking is the responsibility of 254 the ATM network. For the case of Frame Relay at both the PME and the 255 PAE, FRF5 or FRF8.1 Frame Relay to ATM interworking capability is 256 required at the PME (to be specific, Frame Relay to AAL5 SDU Frame 257 encapsulation over PW) and is optional at the ME (Frame Relay over 258 Pseudo Wire to ATM). For the case of Frame Relay at the PME and ATM 259 at the PAE, Frame Relay to ATM interworking capability is required at 260 the PME and is optional at the ME. 262 4. Non-Requirements 264 4.1. Frame Relay / ATM Interworking 266 While Frame Relay to ATM interworking is recognized as an important 267 and pervasive service, such a service is deemed to be beyond the 268 scope of this document. This is not to imply that such a service 269 cannot be supported by the means specified herein. It merely implies 270 that when Frame Relay to ATM interworking is required in the PSN net- 271 work, the interworking function (IWF) is located (and configured) at 272 the PME. 274 5. Background on identifiers 276 5.1. Pseudowire Identifiers 278 Pseudowires serve to connect a pair of attachment circuits (ACs). In 279 the context of this document these ACs are either Frame Relay DLCIs 280 or ATM VPI/VCIs. An AC is identified by an Attachment Identifier 281 (AI) and the IP address of the egress node. AIs are defined in [1]. 282 An AI is a logical reference for both the physical/logical port as 283 well as the virtual circuit. That is an AC is fully identified by a 284 node-ID (IP address) and an AI. 286 The AI has further structure to designate groups of identifiers and 287 individual identifiers within a group, these are called attachment 288 group identifiers (AGI) and attachment individual identifiers (AII), 289 respectively. When pairs of AIs are used in signaling, they are fur- 290 ther designated by their role in the call, with the operative terms 291 being source and target of the call. Thus we also have the terminol- 292 ogy, source attachment identifier (SAI), source attachment individual 293 identifier (SAII), target attachment identifier (TAI), and target 294 attachment individual identifier (TAII). The source and target desig- 295 nations are only relevant from the perspective of the pseudowire con- 296 trol protocol. For example, a node receiving an LDP label mapping 297 message from a remote node will swap the SAI and TAI values when it 298 sends a label mapping message in the reverse direction back to the 299 originating node. 301 Attachment Identifiers (AIs) are carried in the Generalized ID FEC 302 Element of LDP. Each AI encoded as two fields, the Attachment Group 303 Identifier (AGI) and an Attachment Individual Identifier (AII), each 304 encoded using a type-length-value (TLV) format as defined in Section 305 5.2.2/[PWE3-CP]. In particular: 307 "Note that the interpretation of a particular field as AGI, SAII, or 308 TAII depends on the order of its occurrence. The type field identi- 309 fies the type of the AGI, SAII, or TAII. 311 The rules for constructing the AGI and AII are left to the specifica- 312 tion of applications and/or models." 314 5.2. ATM SPVC Identifiers 316 In ATM, the identifying information of the attachment circuit at the 317 destination interface consists of an ATM End-System Address (AESA) 318 and the DLCI or VPI/VCI. The AESA identifies both the destination 319 node and port where the end-user is attached. The DLCI or VPI/VCI 320 are signaled in the Called party SPVC IE and are carried as literal 321 values. The Called party SPVC IE has two formats depending on 322 whether the service being signaled is a Frame Relay SPVC or an ATM 323 SPVC. Furthermore, ATM SPVCCs and ATM SPVPCs are distinguished 324 through the bearer class codepoint in the Broadband bearer capability 325 IE. 327 AESAs are based on the NSAP address format. Figure 2 shows the 328 generic format. 330 |--AFI (Authority & Format Identifier) 331 | Selector 332 | |--IDP (Initial Domain Part) | 333 V V V 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | | H O - D S P | E S I |0| 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 HO-DSP High Order Domain Specific Part 339 ESI End System Identifier 341 Figure 2: Generic AESA Format 343 Although many formats are permitted within AESAs, all ATM Forum 344 defined formats include a six byte End System Identifier or ESI. The 345 ESI's role is to identify a host. Typically, the first 13 bytes of 346 the AESA are common for all end systems attached to an ATM node. 347 This is the default behavior in PNNI. In this case, the ESI is used 348 to differentiate between end systems attached to the same switch. 349 From the point of view of the egress ATM switch, the ESI maps to a 350 physical or logical port. 352 Thus common practice is to use the ESI to carry the port information. 354 6. Proposed Solution 356 6.1. PSN / ATM Interface 358 The interface between the ATM network and the PSN can be any of the 359 following: 361 ATM Forum User Network Interface (UNI) 362 ITU-T User Network Interface (UNI) 363 Private Network-Network Interface (PNNI) 364 ATM Inter-Network Interface (AINI) 366 In the case of the UNI, there must be extensions to support the 367 Called party soft PVPC or PVCC IE defined in [PNNI]. (In this docu- 368 ment we refer to the Called party soft PVPC or PVCC IE as simply the 369 SPVC IE.) There may be extensions to support: 371 o the Calling party soft PVPC or PVCC IE, 373 o signaled VPs, using the "transparent VP service" codepoint for 374 the bearer class in the Broadband bearer capability IE, 376 o crankback indication by setting the cause location in the Cause 377 IE to a value other than "user", and 379 o frame discard indication using either the Frame Discard bits 380 or the ATM adaptation layer parameters IE. 382 [Note: while the details of various versions of ATM signaling and the 383 support for particular IEs is a subject for other Fori and thus 384 beyond the scope of the WG (and IETF), an informative appendix 385 appropriate references will be added if the WG so desires.] 387 6.2. Signaling 389 In ATM soft PVCs are statically defined across the UNI interfaces, 390 but are signaled across the ATM network using PNNI signaling. For 391 the signaling part, one edge node is configured to be active for the 392 SPVC and the other is defined to be passive. That is, one end always 393 initiates the call. ATM signaling creates a bidirectional circuit in 394 a single pass. Bandwidth parameters for each direction of the cir- 395 cuit are carried in the setup message. 397 A paradigm analogous to the active/passive roles in SPVC setup above 398 for pseudowires is known as single sided provisioning. These proce- 399 dures are defined in draft-rosen-ppvpn-l2-signaling-03.txt [L2VPN- 400 SIG] section 5.1.1.2. A small difference exists here in that the 401 "discovery" process occurs when an ATM SETUP message arrives. 403 It should be noted, that the pseudowire setup remains a pair of uni- 404 directional labels assigned by two essentially independent label 405 requests. It is only the triggering of the reverse label request 406 that is tied to the forward label request. Further [PWE3-CP] does 407 not carry bandwidth parameters at all. 409 6.3. Mapping Identifiers 411 In [PWE3-CP], an IP address identifies the egress node, and the (T)AI 412 identifies the egress port and DLCI or VPI/VCI. In ATM, an AESA 413 identifies both the egress node and port, and the DLCI or VPI/VCI is 414 carried as a literal in the SPVC IE. 416 Two issues must be addressed. First a mapping between ATM and IP 417 addresses is needed. Second a means of translating between the ATM 418 port and SPVC IE and the AI used in [PWE3-CP]. 420 6.3.1. Mapping Addresses 422 OSI Network Service Access Point Addresses include an Authority and 423 Format Identifier (AFI). The AFI value 35 has been assigned to the 424 IANA. Within this format a two-octet Internet Code Point (ICP) field 425 is available for assignment by the IANA. Currently there is one code 426 point, 0, assigned for embedding IPv6 addresses. A format and code 427 point assignment has been proposed by the ATM Forum in [ATM-ipaddr]. 428 That format is shown below. 430 |--AFI (Authority & 431 | Format Identifier) Selector 432 | |--IDP (Initial Domain Part) | 433 V V |<---- HO-DSP ----->|<-- ESI -->|V 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 |3|0 0|I P v 4|0 0 0 0 0 0| |0| 436 |5|0 1|Address|0 0 0 0 0 0| |0| 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 HO-DSP High Order Domain Specific Part 440 ESI End System Identifier 442 Figure 3: NSAP with Embedded IPv4 Address 444 While it is common practice to carry the port number in the ESI 445 field, We note that there are six unused bytes in the HO-DSP as well 446 as the Selector Byte which could be used in a situation where the ESI 447 was not available. 449 The format to embed an IPv6 address in an NSAP address is defined in 450 [RFC1888]. In this format the only unused space is the Selector 451 Byte. This allows for the identification of 256 ports. If more 452 ports are needed, multiple addresses must be assigned. 454 |--AFI (Authority & 455 | Format Identifier) Selector 456 | |--IDP (Initial Domain Part) | 457 V V V 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 |3|0 0| I P v 6 A d d r e s s | | 460 |5|0 0| | | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 4: NSAP with Embedded IPv6 Address 465 While it is expected that for IPv4 the ESI will commonly be used and 466 for IPv6 the Selector Byte must be used, the discussion below will 467 simply refers to a generic port field. 469 6.3.2. Mapping Port and SPVC IEs to AIs 471 It is proposed that the Port and SPVC IE values be mapped into the 472 AII. The SPVC IE has three formats, one each for Frame Relay, ATM 473 SPVC, and ATM SPVP. Each of these will be mapped into three [to be 474 assigned] AII types. [If there is an issue with IANA allocating 475 three, one, with some form of sub-typing will do.] 477 6.4. Configuration 479 PAEs: For each Permanent Virtual Connection, the PAE is configured 480 with the target AESA and DLCI or VPI/VCI. 482 AEs: AEs are configured with the AESA prefix representing the set of 483 PSN nodes reachable through its link(s) to the PSN. Multiple 484 prefixes may be configured to allow choices of optimum nodes to 485 reach and to allow reachability to a larger set of nodes, 486 should some other AE or ME fail. The advertisement into the 487 ATM network's routing protocol (e.g.PNNI) should be withdrawn 488 if the associated link(s) have failed. 490 PMEs: PME require no special configuration. They are simply 491 configured with the (T)AII of each of their ACs. 493 MEs: MEs must be able to encode and parse the [to be assigned] AII 494 types. Associated with each of these AII type is an AII format 495 (used to form TAIIs) and rules for how to extract the port from 496 the ATM called party address. .fi 498 6.5. Procedures 500 6.5.1. Procedures within the ATM Network 502 In an SPVC, one end is designated as the 'owner' and is responsible 503 for initiating the connection. In order to simplify the interwork- 504 ing, this solution proposes that SPVCs always be initiated from the 505 ATM side. This obviates any need to communicate bandwidth informa- 506 tion across the PSN to the ATM network. 508 The AEs as the owner of the connection, initiates PNNI signaling as 509 it normally would. Finding a longest match associated with one or 510 more of the AEs it performs normal PNNI routing selection and sends a 511 SETUP message which includes the SPVC IE. 513 When the SETUP message arrives at the AE, it performs normal PNNI 514 signaling processing and forwards the message across the PNNI, AINI 515 or UNI to the ME. 517 6.5.2. Procedures for the ME 519 When the ME receives a SETUP message, performs ATM admission control. 520 Additionally, the ME may perform additional checks to determine if it 521 has the necessary resources to support the pseudowire connection in 522 the forward direction. For example, in some network deployments it 523 may determine if a PSN tunnel can be established in order to satisfy 524 QoS or restoration requirements. 526 In the event that the call cannot be admitted, the ME SHOULD set an 527 appropriate cause code, assuming that it is capable of supporting 528 crankback procedures. 530 When the ME has successfully performed ATM admission control, it 531 splices the call to a pseudowire using the signaling procedures of 532 [L2VPN-SIG]. First, it extracts the destination IP address from the 533 ATM called party address. It then determines if a LDP session exists 534 with this node. If not, one is initiated. It then examines the SPVC 535 IE to determine the type of service which is being requested. Based 536 on the service type it selects AII type and format. It then extracts 537 the port, VPI, VCI, and/or DLCI information as appropriate to the 538 service and formats an AII. It formats an SAI using the same encod- 539 ing rules, using the port the setup message was received on and the 540 Connection Identifier. This AI becomes the handle which will be used 541 to locate the context for this call. It then sends a Label Mapping 542 message to the target node. 544 When it receives a Label mapping message from the target node, it 545 uses the TAI to locate the call context and completes the ATM call. 547 [Note: while the details of the ATM call processing and crankback 548 codes is a subject for other Fori and thus beyond the scope of the WG 549 (and IETF), an informative appendix will be added if the WG so 550 desires.] 552 6.5.3. Procedures for the PME 554 The procedures for the PME follow [L2VPN-SIG] with no changes. That 555 is, the PME uses the TAI to identify interface and DLCI or VPI/VCI. 556 No decoding of the TAII is necessary; the AI and AC are simply con- 557 figured as in [L2VPN-SIG]. 559 If the forward label mapping completed successfully, the PME responds 560 with an LDP label mapping message in the reverse direction. The same 561 encapsulation as the forward direction MUST be signaled. 563 6.5.4. Call Completion 565 When the ME receives the label mapping message, it uses the TAI to 566 (i.e. what it sent as the SAI) locate the context for this call and 567 then completes the ATM call by sending a CONNECT message back to the 568 PAE. 570 6.6. Handling Re-assembly 572 When an ME detects that the requested service is Frame Relay, by 573 default it will perform AAL5 re-assembly for Frame Relay SPVCs. In 574 this case the AAL5 SDU frame mode encapsulation as defined in 575 [PWE3-ENCAPS] is RECOMMENDED. 577 On a per ATM/PSN interface basis, an ME may be configured to not per- 578 form re-assembly for Frame Relay. No per circuit selection is pro- 579 vided. In this case the RECOMMENDED encapsulation is ATM N-to-1 Cell 580 Mode. 582 Both ATM SPVCCs and SPVPCs are encapsulated using one of the cell- 583 mode encapsulations. The RECOMMENDED encapsulation is ATM N-to-1 584 Cell Mode. 586 [As noted in the "Issues" section below, the Frame Relay format of 587 the SPVC IE may not be available on some ATM equipment. Alternative 588 means of determining that the service is Frame Relay can be achieved 589 in many cases by examining some combination of the . 591 7. Issues 593 The Frame Relay format for the SPVC IE was added later. Some ATM 594 equipment still uses the ATM SPVC format with the DLCI encoded in the 595 VPI/VCI fields. To support these switches without change, and still 596 allow AAL5 reassembly to be done at the ME, some other means of indi- 597 cating that the circuit is Frame Relay needs to be established. 599 8. Security Considerations 601 This document represents a straightforward application of [L2VPN- 602 SIG]. It poses no new security considerations over and above those 603 identified in that document. 605 9. Acknowledgments 607 The authors would like to thank Chris Metz and Chandra Krishnamurthy 608 for their input to this document. 610 10. References 612 10.1. Normative References 614 [LDP] Andersson, L. et al., "LDP Specification", RFC 3036, 615 January 2001. 617 [L2VPN-SIG] Rosen, E.& Radoaca, V, "Provisioning Models and Endpoint 618 Identifiers in L2VPN Signaling", 619 draft-ietf-l2vpn-signaling-00.txt, September 2003. 621 [PWE3-CP] Martini, L. & Rosen, E., "Pseudowire Setup and Maintenance 622 using LDP", draft-ietf-pwe3-control-protocol-04.txt, 623 October 2003. 625 [PWE3-ENCAP] Martini, et al., "Encapsulation Methods for Transport of 626 ATM Cells/Frame Over IP and MPLS Networks", 627 draft-ietf-pwe3-atm-encap-03.txt, October 2003. 629 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", BCP 14, RFC 2119, March 1997. 632 10.2. Informative References 634 [PWE3-IANA] Townsley, M., "IANA Allocations for pseudo Wire Edge to 635 Edge Emulation (PWE3)", 636 draft-ietf-pwe3-iana-allocation-04.txt, April 2004. 638 [ATM-AINI] ATM Forum, "ATM Inter-Network Interface Specification 639 Version 1.1 (AINI 1.1)", af-cs-0125.002, September 2002 641 [ATM-UNI] ATM Forum, "ATM User-Network Interface (UNI) Signalling 642 Specification Version 4.1", af-sig-0061.002, April 2002 644 [PNNI] ATM Forum, "Private Network-Network Interface Specification 645 Version 1.1", af-pnni-0055.001, April 2002 647 [ATM-ipaddr] ATM Forum, "IP-Based Addressing Version 1.0", 648 str-cs-ipaddr-01.01, October 2003 650 [RFC1888] Bound, J., et al., "OSI NSAPs and IPv6", RFC 1888, 651 August 1996. 653 11. Authors' Addresses 655 George Swallow 656 Cisco Systems, Inc. 657 1414 Massachusetts Ave 658 Boxborough, MA 01719 660 Email: swallow@cisco.com 662 Ethan Mickey Spiegel 663 Cisco Systems, Inc. 664 3700 Cisco Way 665 San Jose, CA 95134 667 Email: mspiegel@cisco.com 669 12. Full Copyright and Intellectual Property Statements 671 Copyright (C) The Internet Society (2004). This document is subject 672 to the rights, licenses and restrictions contained in BCP 78, and 673 except as set forth therein, the authors retain all their rights. 675 This document and the information contained herein are provided on an 676 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 677 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 678 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 679 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 680 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 681 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 683 Intellectual Property 684 The IETF takes no position regarding the validity or scope of any 685 Intellectual Property Rights or other rights that might be claimed to 686 pertain to the implementation or use of the technology described in 687 this document or the extent to which any license under such rights 688 might or might not be available; nor does it represent that it has 689 made any independent effort to identify any such rights. Information 690 on the procedures with respect to rights in RFC documents can be 691 found in BCP 78 and BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any assur- 694 ances of licenses to be made available, or the result of an attempt 695 made to obtain a general license or permission for the use of such 696 proprietary rights by implementers or users of this specification can 697 be obtained from the IETF on-line IPR repository at 698 http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention any 701 copyrights, patents or patent applications, or other proprietary 702 rights that may cover technology that may be required to implement 703 this standard. Please address the information to the IETF at ietf- 704 ipr@ietf.org. 706 Acknowledgement 708 Funding for the RFC Editor function is currently provided by the 709 Internet Society.