Network Working Group George Swallow Internet Draft Cisco Systems, Inc. Category: Standards Track Expiration Date: January 2005 Mickey Spiegel Cisco Systems, Inc. July 2004 Soft Permanent Virtual Circuit Interworking between PWE3 and ATM draft-swallow-pwe3-spvc-iw-01.txt Status of this Memo By submitting this Internet-Draft, the authors certify that any applicable patent or other IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 5 of RFC3667. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document defines interworking between Private Network Node Interface (PNNI) SPVC signaling and the Label Distribution Protocol Swallow & Spiegel Standards Track [Page 1] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 [LDP] as extended by [PWE3-CP] and [L2VPN-SIG]. Contents 1 Introduction ........................................... 3 1.1 Conventions ............................................ 3 1.2 Terminology ............................................ 3 2 Problem Statement ...................................... 4 2.1 Reference Network Diagram .............................. 5 3 Requirements ........................................... 5 3.1 Configuration .......................................... 6 3.2 Redundant ATM/PSN Interfaces ........................... 6 3.3 Re-assembly ............................................ 6 3.4 No Change to Existing ATM Signaling Protocols .......... 6 3.5 Frame Relay and ATM Circuits at the MPLS Network Edge .. 6 4 Non-Requirements ....................................... 7 4.1 Frame Relay / ATM Interworking ......................... 7 5 Background on identifiers .............................. 7 5.1 Pseudowire Identifiers ................................. 7 5.2 ATM SPVC Identifiers ................................... 8 6 Proposed Solution ...................................... 9 6.1 PSN / ATM Interface .................................... 9 6.2 Signaling .............................................. 9 6.3 Mapping Identifiers .................................... 10 6.3.1 Mapping Addresses ...................................... 10 6.3.2 Mapping Port and SPVC IEs to AIs ....................... 11 6.4 Configuration .......................................... 12 6.5 Procedures ............................................. 13 6.5.1 Procedures within the ATM Network ...................... 13 6.5.2 Procedures for the ME .................................. 13 6.5.3 Procedures for the PME ................................. 14 6.5.4 Call Completion ........................................ 14 6.6 Handling Re-assembly ................................... 14 7 Issues ................................................. 15 8 Security Considerations ................................ 15 9 Acknowledgments ........................................ 15 10 References ............................................. 15 10.1 Normative References ................................... 15 10.2 Informative References ................................. 16 11 Authors' Addresses ..................................... 16 12 Full Copyright and Intellectual Property Statements .... 17 Swallow & Spiegel Standards Track [Page 2] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 1. Introduction In current ATM deployments, Soft Permanent Virtual Connections (SPVCs) are used to provision both Asynchronous Transfer Mode (ATM) Permanent Virtual Channel Connections (PVCC) and Permanent Virtual Path Connections (PVPC) and Frame Relay (FR) PVCCs. Pseudowires over Multiprotocol Label Switching (MPLS) and L2TPv3 PSNs are current being introduced as backbone technologies to carry these same services. Mechanisms are being developed to enable a flexible provisioning model which incorporates elements of the SPVC model in that configuration of the end service exists only at the end-points. These mechanisms are described in [PWE3-CP] and [L2VPN-SIG]. As services are migrated from ATM to PSNs, any reasonable deployment scenario mandates that there be a period of time (possibly protracted or permanent) in which services will need to be established and maintained between end-users where one end of a circuit is attached to an ATM network and the other end is attached to a PSN. 1.1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 1.2. Terminology PAE Provider ATM Edge, a customer facing node which is part of the ATM network AE ATM Edge, a node of the ATM network which is attached to a node of the MPLS/IP network PSN Packet Switched Network PME Provider MPLS/IP Edge, a customer facing node which is part of the MPLS/IP PSN ME MPLS/IP Edge, a node of the MPLS/IP PSN which is attached to a node of the ATM network AI Attachment Identifier AGI Attachment Group Identifier Swallow & Spiegel Standards Track [Page 3] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 AII Attachment Individual Identifier SAI Source Attachment Identifier TAI Target Attachment Identifier SAII Source Attachment Individual Identifier TAII Target Attachment Individual Identifier PNNI Private Network-Network Interface UNI User Network Interface AINI ATM Inter-Network Interface PVCC Permanent Virtual Channel Connection PVPC Permanent Virtual Path Connection SPVC Soft Permanent Virtual Connection IE Information Element 2. Problem Statement To facilitate the migration of ATM and Frame Relay SPVCs to a PSN carrying pseudowires, a means of interoperating ATM and LDP signaling needs to be defined. Further this interoperation must preserve the essential reasons for using SPVCs, namely, keeping configuration limited to the edge nodes supporting a particular connection and allowing the network to be able to recover in the event of the failure of any facility between those two edge nodes. It is also useful to perform reassembly of AAL5 frames of Frame Relay connections at the boundary between the ATM network and the PSN. This serves to reduce dataplane protocol overhead in the PSN. Finally, any solution must not preclude any existing services. In particular, Frame Relay to ATM interworking is recognized to be in wide use. Swallow & Spiegel Standards Track [Page 4] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 2.1. Reference Network Diagram The diagram below shows an ATM network interfaced to a PSN. A soft PVC is to be set up between the two customer facing edge nodes, PAE, and PME. Two interconnections are shown, to indicate that the connection must be routable over either interconnection in the event of the failure of the preferred interconnection. The 'M' (for MPLS/IP PSN) was chosen over 'P' (for PSN) to allow 'P' to stand for provider. _______ _______ / % / % / % +-----+ +-----+ / % / % | | | | / % | |==| AE1 |==| ME1 |==| | +-----+ | | | | | | | | +-----+ | | | ATM | +-----+ +-----+ | MPLS/IP | | | | PAE |==| | | PSN |==| PME | | | | | +-----+ +-----+ | | | | +-----+ | | | | | | | | +-----+ | |==| AE2 |==| ME2 |==| | % / | | | | % / % / +-----+ +-----+ % / %_______/ %_______/ Key: All node acronyms are composed of the following letters P - Provider M - MPLS/IP PSN A - ATM E - Edge Figure 1: Reference Network 3. Requirements The purpose of Soft Permanent Virtual Connections is two-fold. First they confine circuit specific configuration to the edge nodes where the user access circuits are terminated. Second they allow the network to automatically reroute / re-establish the circuit when failures are encountered. The requirements for this solution follow directly from this as well as some of the common uses of SPVCs. Swallow & Spiegel Standards Track [Page 5] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 3.1. Configuration All per circuit configuration must be limited to the edge nodes. In particular the solution must not necessitate any per circuit configuration on the nodes which support the ATM/PSN interface. 3.2. Redundant ATM/PSN Interfaces The solution must support multiple inter-connections between the ATM network and the PSN. Upon failure of an ATM/PSN interface, it must be possible to re-route the SPVCs that had been traversing that interface over other ATM/PSN interfaces. 3.3. Re-assembly It must be possible to locate the AAL5 re-assembly at the ME. That is, a ME by default will perform AAL5 re-assembly for Frame Relay SPVCs. The ME's ATM/PSN interface may be configured to not perform re-assembly and leave the job to the target PME, when the target PME supports AAL5 re-assembly for Frame Relay circuits. No per circuit selection need be supported. 3.4. No Change to Existing ATM Signaling Protocols It is highly desirable that no changes be required to existing ATM signaling protocols. 3.5. Frame Relay and ATM Circuits at the MPLS Network Edge The solution must support both ATM and Frame Relay circuits at the Provider MPLS Edge. For the case of ATM at the PME and Frame Relay at the PAE, Frame Relay to ATM interworking is the responsibility of the ATM network. For the case of Frame Relay at both the PME and the PAE, FRF5 or FRF8.1 Frame Relay to ATM interworking capability is required at the PME (to be specific, Frame Relay to AAL5 SDU Frame encapsulation over PW) and is optional at the ME (Frame Relay over Pseudo Wire to ATM). For the case of Frame Relay at the PME and ATM at the PAE, Frame Relay to ATM interworking capability is required at the PME and is optional at the ME. Swallow & Spiegel Standards Track [Page 6] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 4. Non-Requirements 4.1. Frame Relay / ATM Interworking While Frame Relay to ATM interworking is recognized as an important and pervasive service, such a service is deemed to be beyond the scope of this document. This is not to imply that such a service cannot be supported by the means specified herein. It merely implies that when Frame Relay to ATM interworking is required in the PSN network, the interworking function (IWF) is located (and configured) at the PME. 5. Background on identifiers 5.1. Pseudowire Identifiers Pseudowires serve to connect a pair of attachment circuits (ACs). In the context of this document these ACs are either Frame Relay DLCIs or ATM VPI/VCIs. An AC is identified by an Attachment Identifier (AI) and the IP address of the egress node. AIs are defined in [PWE3-CP]. An AI is a logical reference for both the physical/logical port as well as the virtual circuit. That is an AC is fully identified by a node-ID (IP address) and an AI. The AI has further structure to designate groups of identifiers and individual identifiers within a group, these are called attachment group identifiers (AGI) and attachment individual identifiers (AII), respectively. When pairs of AIs are used in signaling, they are further designated by their role in the call, with the operative terms being source and target of the call. Thus we also have the terminology, source attachment identifier (SAI), source attachment individual identifier (SAII), target attachment identifier (TAI), and target attachment individual identifier (TAII). The source and target designations are only relevant from the perspective of the pseudowire control protocol. For example, a node receiving an LDP label mapping message from a remote node will swap the SAI and TAI values when it sends a label mapping message in the reverse direction back to the originating node. Swallow & Spiegel Standards Track [Page 7] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 5.2. ATM SPVC Identifiers In ATM, the identifying information of the attachment circuit at the destination interface consists of an ATM End-System Address (AESA) and the DLCI or VPI/VCI. The AESA identifies both the destination node and port where the end-user is attached. The DLCI or VPI/VCI are signaled in the Called party SPVC IE and are carried as literal values. The Called party SPVC IE has two formats depending on whether the service being signaled is a Frame Relay SPVC or an ATM SPVC. Furthermore, ATM SPVCCs and ATM SPVPCs are distinguished through the bearer class codepoint in the Broadband bearer capability IE. AESAs are based on the NSAP address format. Figure 2 shows the generic format. |--AFI (Authority & Format Identifier) | Selector | |--IDP (Initial Domain Part) | V V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | H O - D S P | E S I |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HO-DSP High Order Domain Specific Part ESI End System Identifier Figure 2: Generic AESA Format Although many formats are permitted within AESAs, all ATM Forum defined formats include a six byte End System Identifier or ESI. The ESI's role is to identify a host. Typically, the first 13 bytes of the AESA are common for all end systems attached to an ATM node. This is the default behavior in PNNI. In this case, the ESI is used to differentiate between end systems attached to the same switch. From the point of view of the egress ATM switch, the ESI maps to a physical or logical port. Thus common practice is to use the ESI to carry the port information. Swallow & Spiegel Standards Track [Page 8] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 6. Proposed Solution 6.1. PSN / ATM Interface The interface between the ATM network and the PSN can be any of the following: ATM Forum User Network Interface (UNI) ITU-T User Network Interface (UNI) Private Network-Network Interface (PNNI) ATM Inter-Network Interface (AINI) In the case of the UNI, there must be extensions to support the Called party soft PVPC or PVCC IE defined in [PNNI]. (In this document we refer to the Called party soft PVPC or PVCC IE as simply the SPVC IE.) There may be extensions to support: o the Calling party soft PVPC or PVCC IE, o signaled VPs, using the "transparent VP service" codepoint for the bearer class in the Broadband bearer capability IE, o crankback indication by setting the cause location in the Cause IE to a value other than "user", and o frame discard indication using either the Frame Discard bits or the ATM adaptation layer parameters IE. [Note: while the details of various versions of ATM signaling and the support for particular IEs is a subject for other Fori and thus beyond the scope of the WG (and IETF), an informative appendix appropriate references will be added if the WG so desires.] 6.2. Signaling In ATM soft PVCs are statically defined across the UNI interfaces, but are signaled across the ATM network using PNNI signaling. For the signaling part, one edge node is configured to be active for the SPVC and the other is defined to be passive. That is, one end always initiates the call. ATM signaling creates a bidirectional circuit in a single pass. Bandwidth parameters for each direction of the circuit are carried in the setup message. A paradigm analogous to the active/passive roles in SPVC setup above for pseudowires is known as single sided provisioning. These procedures are defined in draft-rosen-ppvpn-l2-signaling-03.txt [L2VPN-SIG] section 5.1.1.2. A small difference exists here in that Swallow & Spiegel Standards Track [Page 9] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 the "discovery" process occurs when an ATM SETUP message arrives. It should be noted, that the pseudowire setup remains a pair of unidirectional labels assigned by two essentially independent label requests. It is only the triggering of the reverse label request that is tied to the forward label request. Further [PWE3-CP] does not carry bandwidth parameters at all. 6.3. Mapping Identifiers In [PWE3-CP], an IP address identifies the egress node, and the (T)AI identifies the egress port and DLCI or VPI/VCI. In ATM, an AESA identifies both the egress node and port, and the DLCI or VPI/VCI is carried as a literal in the SPVC IE. Two issues must be addressed. First a mapping between ATM and IP addresses is needed. Second a means of translating between the ATM port and SPVC IE and the AI used in [PWE3-CP]. 6.3.1. Mapping Addresses OSI Network Service Access Point Addresses include an Authority and Format Identifier (AFI). The AFI value 35 has been assigned to the IANA. Within this format a two-octet Internet Code Point (ICP) field is available for assignment by the IANA. Currently there is one code point, 0, assigned for embedding IPv6 addresses. A format and code point assignment has been proposed by the ATM Forum in [ATM-ipaddr]. That format is shown below. |--AFI (Authority & | Format Identifier) Selector | |--IDP (Initial Domain Part) | V V |<---- HO-DSP ----->|<-- ESI -->|V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |3|0 0|I P v 4|0 0 0 0 0 0| |0| |5|0 1|Address|0 0 0 0 0 0| |0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HO-DSP High Order Domain Specific Part ESI End System Identifier Figure 3: NSAP with Embedded IPv4 Address While it is common practice to carry the port number in the ESI field, We note that there are six unused bytes in the HO-DSP as well Swallow & Spiegel Standards Track [Page 10] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 as the Selector Byte which could be used in a situation where the ESI was not available. The format to embed an IPv6 address in an NSAP address is defined in [RFC1888]. In this format the only unused space is the Selector Byte. This allows for the identification of 256 ports. If more ports are needed, multiple addresses must be assigned. |--AFI (Authority & | Format Identifier) Selector | |--IDP (Initial Domain Part) | V V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |3|0 0| I P v 6 A d d r e s s | | |5|0 0| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: NSAP with Embedded IPv6 Address While it is expected that for IPv4 the ESI will commonly be used and for IPv6 the Selector Byte must be used, the discussion below will simply refers to a generic port field. 6.3.2. Mapping Port and SPVC IEs to AIs It is proposed that the Port and SPVC IE values be mapped into the AII. The SPVC IE has three formats, one each for Frame Relay, ATM SPVC, and ATM SPVP. It is therefore proposed that three special AGIs be configured to serve as format identifiers for the necessary AII formats. As the values of these AGIs are completely under the control of the network operator, no specific values are specified. All that is required is that values be assigned which allow the parsing of the AII. We also note that if the AII is formatted as in the second suggestion below, only one AGI is absolutely necessary, since that AII is self identifying. The exact mapping between the port and SPVC IE is also beyond the scope of this document. All that is required is that the mapping preserve all the information contained in the port field and the SPVC IE. Since the resultant string will be compared with the AI information configured at the target node, it is highly recommended that the mapping be done in a human readable format. An example format for a mapping of an SPVC IE specifying an ATM VC, might be to translate the ESI, VPI, and VCI values to ASCII decimal Swallow & Spiegel Standards Track [Page 11] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 strings with any leading zeroes suppressed. And then format the TAII as a concatenation of the three strings with some delimiters. So for port 30, vpi 11, vc 232 one might format the TAII as 30/11/232 or as PORT30VPI11VCI232. We also note in passing that while we have referred to literal port, DLCI, VPI, and VCI values, we note that there is nothing in this solution that demands this be so. The discussion has been couched in these terms only because this is the common practice. Since an AI can be mapped to any arbitrary attachment circuit, the values could be symbolic. Operators may find this convenient, particularly for the port. Such indirection would allow the attachment port to be re-homed within a PWE edge box without reconfiguration on the ATM side. 6.4. Configuration PAEs: For each Permanent Virtual Connection, the PAE is configured with the target AESA and DLCI or VPI/VCI. AEs: AEs are configured with the AESA prefix representing the set of PSN nodes reachable through its link(s) to the PSN. Multiple prefixes may be configured to allow choices of optimum nodes to reach and to allow reachability to a larger set of nodes, should some other AE or ME fail. The advertisement into the ATM network's routing protocol (e.g.PNNI) should be withdrawn if the associated link(s) have failed. PMEs: PME are configured with the AGIs of each service they support and the (T)AII of each configured AC. MEs: MEs are configured with special AGI values for each service (FR PVCC, ATM PVCC, ATM PVPC) it supports. Associated with each of these AGI values is an AII format (used to form TAIIs) and rules for how to extract the port from the ATM called party address. Also associated with each AGI is a pool of (S)AIIs which can be assigned "on the fly" as SAIs to incoming ATM calls. Swallow & Spiegel Standards Track [Page 12] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 6.5. Procedures 6.5.1. Procedures within the ATM Network In an SPVC, one end is designated as the 'owner' and is responsible for initiating the connection. In order to simplify the interworking, this solution proposes that SPVCs always be initiated from the ATM side. {This alleviates any need to communicate bandwidth information across the PSN to the ATM network. better wording needed} The AEs as the owner of the connection, initiates PNNI signaling as it normally would. Finding a longest match associated with one or more of the AEs it performs normal PNNI routing selection and sends a SETUP message which includes the SPVC IE. When the SETUP message arrives at the AE, it performs normal PNNI signaling processing and forwards the message across the AINI or UNI to the ME. 6.5.2. Procedures for the ME When the ME receives a SETUP message, performs ATM admission control. Additionally, the ME may perform additional checks to determine if it has the necessary resources to support the pseudowire connection in the forward direction. For example, in some network deployments it may determine if a PSN tunnel can be established in order to satisfy QoS or restoration requirements. In the event that the call cannot be admitted, the ME SHOULD set an appropriate cause code, assuming that it is capable of supporting crankback procedures. When the ME has successfully performed ATM admission control, it splices the call to a pseudowire using the signaling procedures of [L2VPN-SIG]. First, it extracts the destination IP address from the ATM called party address. It then determines if a LDP session exists with this node. If not, one is initiated. It then examines the SPVC IE to determine the type of service which is being requested. Based on the service type it selects the configured AGI value and AII format. It then extracts the port, VPI, VCI, and/or DLCI information as appropriate to the service and formats a TAI. It then dynamically an AII from the pool associated with this AGI and forms a SAI. This AI becomes the handle which will be used to locate the context for this call. It then sends a Label Mapping message to the target node. When it receives a Label mapping message from the target node, it Swallow & Spiegel Standards Track [Page 13] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 uses the TAI to locate the call context and completes the ATM call. [Note: while the details of the ATM call processing and crankback codes is a subject for other Fori and thus beyond the scope of the WG (and IETF), an informative appendix will be added if the WG so desires.] 6.5.3. Procedures for the PME The procedures for the PME follow [L2VPN-SIG] with no changes. That is, the PME uses the TAI to identify interface and DLCI or VPI/VCI. No decoding of the TAII is necessary; the AI and AC are simply configured as in [L2VPN-SIG]. If the completed successfully, the PME responds with an LDP label mapping message in the reverse direction. The same encapsulation as the forward direction MUST be signaled. 6.5.4. Call Completion When the ME receives the label mapping message, it uses the TAI to locate the context for this call and then completes the ATM call by sending a CONNECT message back to the PAE. 6.6. Handling Re-assembly When an ME detects that the requested service is Frame Relay, by default it will perform AAL5 re-assembly for Frame Relay SPVCs. In this case the AAL5 SDU frame mode encapsulation as defined in [PWE3- ENCAPS] is RECOMMENDED. On a per ATM/PSN interface basis, an ME may be configured to not perform re-assembly for Frame Relay. No per circuit selection is provided. In this case the RECOMMENDED encapsulation is ATM N-to-1 Cell Mode. Both ATM SPVCCs and SPVPCs are encapsulated using one of the cell- mode encapsulations. The RECOMMENDED encapsulation is ATM N-to-1 Cell Mode. [As noted in the "Issues" section below, the Frame Relay format of the SPVC IE may not be available on some ATM equipment. Alternative means of determining that the service is Frame Relay can be achieved in many cases by examining some combination of the . Swallow & Spiegel Standards Track [Page 14] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 7. Issues 1. Should support for Frame Relay signaling be added to this draft? 2. The Frame Relay format for the SPVC IE was added later. Some ATM equipment still uses the ATM SPVC format with the DLCI encoded in the VPI/VCI fields. To support these switches without change, and still allow AAL5 reassembly to be done at the ME, some other means of indicating that the circuit is Frame Relay needs to be established. 3. The configuration of a per service pool of AIIs at the ME can be eliminated by formating a SAII on the fly based on the ME's incoming interface and the VPI/VCI in use on that interface. Details will be supplied in the next revision of this draft. 8. Security Considerations This document represents a straightforward application of [L2VPN- SIG]. It poses no new security considerations over and above those identified in that document. 9. Acknowledgments The authors would like to thank Chris Metz and Chandra Krishnamurthy for their input to this document. 10. References 10.1. Normative References [LDP] Andersson, L. et al., "LDP Specification", RFC 3036, January 2001. [L2VPN-SIG] Rosen, E.& Radoaca, V, "Provisioning Models and Endpoint Identifiers in L2VPN Signaling", draft-ietf-l2vpn-signaling-00.txt, September 2003. [PWE3-CP] Martini, L. & Rosen, E., "Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-04.txt, October 2003. Swallow & Spiegel Standards Track [Page 15] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 [PWE3-ENCAP] Martini, et al., "Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks", draft-ietf-pwe3-atm-encap-03.txt, October 2003. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [PWE3-IANA] Townsley, M., "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-04.txt, April 2004. [ATM-AINI] ATM Forum, "ATM Inter-Network Interface Specification Version 1.1 (AINI 1.1)", af-cs-0125.002, September 2002 [ATM-UNI] ATM Forum, "ATM User-Network Interface (UNI) Signalling Specification Version 4.1", af-sig-0061.002, April 2002 [PNNI] ATM Forum, "Private Network-Network Interface Specification Version 1.1", af-pnni-0055.001, April 2002 [ATM-ipaddr] ATM Forum, "IP-Based Addressing Version 1.0", str-cs-ipaddr-01.01, October 2003 [RFC1888] Bound, J., et al., "OSI NSAPs and IPv6", RFC 1888, August 1996. 11. Authors' Addresses George Swallow Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 Email: swallow@cisco.com Ethan Mickey Spiegel Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 Email: mspiegel@cisco.com Swallow & Spiegel Standards Track [Page 16] Internet Draft draft-swallow-pwe3-spvc-iw-01.txt July 2004 12. Full Copyright and Intellectual Property Statements Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Swallow & Spiegel Standards Track [Page 17]