Network Working Group M. Bocci, Ed. Internet-Draft Alcatel Expires: January 13, 2005 M. Jensen Equipe Communications D. Proch Marconi Communications J. Sugimoto Nortel Networks H. Shah Ciena Corp. July 15, 2004 Signalling Interworking for Asynchronous Transfer Mode Virtual Private Wire Service draft-bocci-l2vpn-pnni-mpls-iw-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 13, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This Internet Draft describes the ATM Forum method [8] for control plane interworking for Asynchronous Transfer Mode (ATM) pseudo wires, Bocci, et al. Expires January 13, 2005 [Page 1] Internet-Draft PNNI-L2VPN Interworking July 2004 where Provider Edge nodes (PEs) on both sides of an MPLS Packet Switched Network (PSN) connect edge ATM networks using the Private Network-Network Interface (PNNI)[10] or the ATM Inter-Network Interface (AINI) [11]. In this method, ATM signalling and routing messages are tunnelled over the PSN using dedicated pseudo wires, enabling ATM pseudo wires carrying user traffic to be established and release dynamically by ATM. The method does not require changes to existing IETF defined protocols in order to support all features of PNNI and AINI. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Conventions Used in this Document . . . . . . . . . . . . 3 1.2 Additional Contributors and Acknowledgements . . . . . . . 3 1.3 Objectives and Scope . . . . . . . . . . . . . . . . . . . 3 1.4 Relevance . . . . . . . . . . . . . . . . . . . . . . . . 4 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.6 A Note on Terminology Differences . . . . . . . . . . . . 5 2. ATM Signalled to ATM Signalled Networks . . . . . . . . . . . 7 2.1 Tunnelling of the ATM Control Plane . . . . . . . . . . . 7 2.1.1 Extending ATM Signalling Across the PSN . . . . . . . 8 2.1.2 Extending PNNI Routing Across the PSN . . . . . . . . 9 2.1.3 ATM Control Plane Association to PSN Tunnels . . . . . 9 2.1.4 Encapsulation Format . . . . . . . . . . . . . . . . . 10 2.1.5 Quality of Service . . . . . . . . . . . . . . . . . . 10 2.2 Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1 PSN-based Protection of the PSN Tunnel . . . . . . . . 11 2.2.2 PNNI-based Protection of the Pseudo Wires . . . . . . 11 2.3 Operations, Administration and Maintenance . . . . . . . . 12 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 16 Bocci, et al. Expires January 13, 2005 [Page 2] Internet-Draft PNNI-L2VPN Interworking July 2004 1. Introduction 1.1 Conventions Used in this Document 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 [1]. 1.2 Additional Contributors and Acknowledgements Additional contributors to this document are: Mustapha Aissaoui, Alcatel, mustapha.aissaoui@alcatel.com David Watkinson, Alcatel, david.watkinson@alcatel.com George Matey, Equipe Communications, george@equipecom.com John Rutemiller, Marconi Communications, john.rutemiller@marconi.com Ghassem Koleyni, Nortel Networks, ghassem@nortelnetworks.com The authors also gratefully acknowledge the input of Peter Roberts, Dimitri Papadimitriou and Jack Pugaczewski. 1.3 Objectives and Scope This informative document extends [6] by including mechanisms for interworking with attachment circuits that are Asynchronous Transfer Mode (ATM) Soft Permanent Virtual Channels or Soft Permanent Virtual Paths (SPVCs/SPVPs) and ATM Switched Virtual Channels or Switched Virtual Paths (SVCs/SPVCs) for Multi Protocol Labels Switching (MPLS) based Packet Switched Networks (PSNs). Service providers are introducing new PSN based networks and are looking for a seamless way to extend the reach of existing ATM services to new sites attached to this PSN network. One important capability which is used in the existing ATM networks is ATM switched services. These are mainly SPVC services, and to a lesser extent SVC services. SPVC services are critical in today's networks as they allow simplified provisioning of the ATM services by configuring the endpoints only. They also allow dynamic traffic engineering and a faster restoration in the case of a network failure. Finally, ATM SPVCs extend connectivity to non-ATM endpoints, such as Frame Relay and Ethernet, on an ATM switch. Thus ATM SPVCs support both native ATM, and non-ATM services and are used in both network and service interworking deployment scenarios. Non-ATM services continue to drive deployments of ATM SPVCs. By transparently supporting ATM switched services over the PSN, existing provisioning tools and operational procedures may be used. It is therefore important to provide methods for interworking ATM switched services and PSN based services such as Virtual Private Wire Service (VPWS). Bocci, et al. Expires January 13, 2005 [Page 3] Internet-Draft PNNI-L2VPN Interworking July 2004 In this document, the attachment circuits on both the ingress and egress Provider Ede Nodes (PEs) are either ATM SPVCs/SPVPs or ATM SVCs/SVPs. In addition, ATM Private Network-Network Interface (PNNI) routing may run between the ingress and egress PEs. There are no methods to signal port connections in ATM, and thus there is no intent to provide VPWS services for transporting an entire ATM port across the PSN using these services. These services should use standard VPWS services instead. This may include the tunnelling of many VC's including PNNI Routing Control Channels (RCCs) and signalling channels within the same port pseudo wire. There are no control plane interactions between ATM signalling/ routing and the underlying PSN, and therefore there are no protocol considerations. This document describes methods and procedures specified in ATM Forum Specification "ATM-MPLS Network Interworking Signalling Specification, Version 1.0"[8]. 1.4 Relevance This informative document shows how the existing Layer 2 Virtual Private Network framework (L2VPN)[6] and the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture [4] can be leveraged to tunnel ATM signalling and routing through the PSN. We show how ATM pseudo wires can be established and released as required by the ATM switched service, without requiring changes to existing IETF protocols e.g. [2], [3], [7]. This addresses work item 2 of the Layer 2 VPN working group charter for signalling layer 2 information. 1.5 Terminology This document uses the following terms. Formal definitions of some of these terms can be found in [4] Bocci, et al. Expires January 13, 2005 [Page 4] Internet-Draft PNNI-L2VPN Interworking July 2004 ATM Inter Network ATM Forum specification for signaling to Interface (AINI) establish point-to-point and point-to- multipoint connections across an ATM network Attachment Circuit The physical or virtual circuit attaching a PE (AC) to a CE. In the context of the application described here, this will be an ATM VCI or VPI. Integrated ATM Forum specification allowing any ATM device Link Management to be provided with status and configuration Interface (ILMI) information Private Network ATM Forum specification to establish point-to- to Network Interface point and point-to-multipoint connections across an ATM network including source routing, crankback, and alternate routing Provider Edge (PE) A device that provides PWE3 to a CE. Pseudo Wire (PW) A mechanism that carries the essential elements of an emulated service from one PE to one or more other PEs over a PSN. Pseudo Wire A mechanism that emulates the essential attributes of a service (such as an ATM VCC) Emulation Edge to Edge (PWE3) over a PSN. PSN Tunnel A tunnel across a PSN inside which one or more PWs can be carried. Routing Control An ATM connection that carries PNNI routing Channel (RCC) messages between PNNI neighbouring peer nodes Tunnel A method of transparently carrying information over a network. Virtual Private A point-to-point circuit (link) connecting two Wire Service (VPWS) Customer Edge devices. 1.6 A Note on Terminology Differences There are some differences in terminology between the IETF, and that used by the ATM Forum in [8]. Figure 2 summarizes the main terms. Bocci, et al. Expires January 13, 2005 [Page 5] Internet-Draft PNNI-L2VPN Interworking July 2004 IETF Term | ATM Forum Term -------------------|-------------------- Pseudo Wire | Interworking LSP Pseudo Wire Label | Interworking Label PSN Tunnel | Transport LSP Provider Edge | Interworking Network Element Figure 2: Terminology Bocci, et al. Expires January 13, 2005 [Page 6] Internet-Draft PNNI-L2VPN Interworking July 2004 2. ATM Signalled to ATM Signalled Networks ACs PSN ACs ATM ATM +------+ Tunnel +------+ +-----+ | PE1 |==============| PE2 | +-----+ | CE1 |-----------.........PW..........-------------| CE2 | +-----+ | VPWS | | VPWS | +-----+ | |==============| | +------+ +------+ Figure 3: Architecture Figure 3 shows the general architecture for ATM VPWS. The attachment circuits are ATM VCCs or VPCs that span an ATM network. ATM connections are mapped to Pseudo Wires (PWs) in the PSN tunnel. ATM SVC services start and terminate on the attached CE devices, while the signalling for the SPVC services originates and terminates on the ATM switches in the ATM networks that the CEs are physically attached to, or on the PE where there is only a single hop path netween the CE and the PE. The objective is to provide service over a PSN without impacting the ATM signalling that occurs between the CE devices, and without requiring changes to non-ATM protocols between PE1 and PE2 e.g. MPLS [2], the PWE3 control protocol [7], or RSVP-TE [3]. ATM signalling and routing typically operates over PNNI [10] or AINI [11] interfaces. Signalling and routing messages for these protocols are carried on dedicated ATM VCCs. These are known as Signalling Channels for signalling messages and Routing Control Channels (RCCs) for PNNI routing messages. For ATM link managent messages, an ILMI channel [13] may be used. For AINI, static ATM routing is assumed and so no RCC is present. 2.1 Tunnelling of the ATM Control Plane The terminology used in this section follows the L2VPN naming conventions. The use of the pseudo wire label in this section can be related to the use of the interworking label within [8]. Bocci, et al. Expires January 13, 2005 [Page 7] Internet-Draft PNNI-L2VPN Interworking July 2004 ACs PSN ACs ATM ATM +-----+ Tunnel +------+ _____ | PE1 |=============| PE2 | _____ ( )--Sig---- ......PW.(SIG)..... ------Sig---( ) ( ATM ) |VPWS | | VPWS | ( ATM ) (network) | | | | (network) ( )--RCC---- ......PW.(RCC)..... ------RCC---( ) ~~~~~~~ | |=============| | ~~~~~~~ +-----+ +------+ Figure 4: Extending ATM Signalling and Routing Across the PSN Figure 4 shows how ATM signalling and routing is extended across the PSN between attached ATM networks. In the case of ILMI, a PW would also be present that represents an ILMI channel in the ATM network. 2.1.1 Extending ATM Signalling Across the PSN In the case of signalling, a bidirectional PW is established using the PW signalling protocol [7], or by configuration. These PWs carry the ATM signalling channel messages transparently across the PSN for either PNNI or AINI. This allows all of the existing and future ATM signalling capabilities to be carried transparently. [8] explains how ATM signalling is extended across the PSN to advertise PW labels between PE1 and PE2. The PNNI and AINI protocol extensions described in [8] add an Interworking Information Element (IE) which supports label exchange between the PE pair for the ATM connection pseudo wire and the negotiation of encapsulation methods for the connection. There is no requirement for any ATM capable system, other than the PEs, to understand or support the Interworking IE. Therefore legacy systems can take advantage of the interworking capabilities without need for software modifications. Since ATM signalling messages are carried transparently between the PE pairs, there are no protocol considerations for the PSN related to the signalling and establishment of ATM connection pseudo wires. The pseudo wire label for an ATM connection is carried between the two PEs in the Interworking IE within the PNNI or AINI signalling messages. As the label is significant only to the PE devices at either end of the PSN tunnel, this IE can be added to the signalling message by the PE. Where other non-ATM VPWS services are also supported by the PE and pseudo wire labels are allocated from the same label space as ATM pseudo wires, the PE will need to manage common resources between multiple control plane protocols e.g. [8] Bocci, et al. Expires January 13, 2005 [Page 8] Internet-Draft PNNI-L2VPN Interworking July 2004 and [7]. This is a common capability in current PE devices. 2.1.2 Extending PNNI Routing Across the PSN ATM Routing is also extended between PE1 and PE2 as explained in [8]. Before the ATM routing can start exchanging ATM reachability across the PSN tunnel, a PNNI RCC must be set up between PE1 and PE2 in Figure 4. As in the case of signalling, the PW control protocol [7], or configuration, sets up a bidirectional PW to carry the ATM routing messages in each direction. This PW represents an RCC between PE1 and PE2. For PNNI, the PSN tunnel can be modelled as a PNNI link between PE1 and PE2, thus extending ATM reachability across the MPLS network using any desired meshing. Therefore, PNNI Routing can take advantage of any parallel or alternate tunnels through the MPLS network. This includes the use of multiple hops (i.e. a sparse mesh), whereby the pseudo wire leaves one PSN tunnel at a given PE, is processed by the ATM signalling on that PE, and enters another PSN tunnel before terminating at the egress PE. PNNI Routing can also properly traffic engineer the usage of any traffic engineered MPLS PSN tunnels. This is achieved by PNNI Routing advertising the available bandwidth of an MPLS PSN tunnel for use by the pseudo wires to the attached ATM networks. Any of the ATM addressing formats can be used in these network situations and is fully transparent to the PSN. This method supports all currently deployed PNNI network scenarios, including PNNI Hierarchy. Note that signalling of the PSN tunnel is beyond the scope of this document. 2.1.3 ATM Control Plane Association to PSN Tunnels There is no stipulation or restriction on how PSN Tunnels are established between two PE devices. The architecture requires at least one bidirectional PSN Tunnel between two PE devices, but can also support multiple PSN Tunnels modeled as a single PNNI or AINI link. In its simplest default case, a single PSN Tunnel is represented as a single PNNI or AINI link. The control pseudo wires i.e those representing Signalling Channels and RCCs, are carried "in-band" - that is within the PSN tunnel whose ATM PWs they control. In other cases, where multiple PSN Tunnels may be used to support QoS guarantees, resiliency requirements or more efficient usage of PSN resources, a single set of control pseudo wires may be used to manage Bocci, et al. Expires January 13, 2005 [Page 9] Internet-Draft PNNI-L2VPN Interworking July 2004 the resources of all PSN tunnels available for ATM established between the two PEs. These control pseudo wires may be carried within one of the PSN Tunnel pairs, but are not required to be associated directly with the tunnels they control. 2.1.4 Encapsulation Format Any of the ATM PW encapsulations can be used for both PWs carrying user data, and those used for RCC, ILMI or Signalling channels. The PW types as defined in [5] are used for user connections based on the signalled ATM parameters, as defined in [8]. The choice of encapsulation will depend on its ability to support the requirements of the ATM service, as described in [5]. Negotiation of an encapsulation mode is a local matter between a pair of PEs. While an ATM end system may add the Interworking IE to request a specific encapsulation mode at any interworking interface, it is not required. The PE should support a default mode for connections signalled without a specific encapsulation indicated. Alternatively, the PE may select from among its supported encapsulations based on local policies. It is expected that the default will be to use a cell mode pseudo wire. 2.1.5 Quality of Service Many of the ATM QoS guarantees can continue to be met through the PSN core. This is possible with the use of traffic-engineered MPLS DiffServ PSN tunnels [14]. This is discussed in more detail in [9] section 9 and Appendix V. PNNI can use these mappings to advertise the resources available for ATM connections on the PSN tunnel to the attached ATM networks. The attached ATM networks will see these resources as native ATM resources. Generalized Connection Admission Control (GCAC) of PNNI running in the attached ATM networks can then use these advertised resources as a part of the route selection decision. Note that the translation of ATM traffic parameters into bandwidth parameters for utilization in the PSN needs to take into account the overhead associated with the PW type. 2.2 Resiliency The tunnelling of PNNI through the PSN means that either PSN-based protection mechanisms may be used to provide resiliency, or optionally PNNI-based mechanisms, or both. Failure detection timers of each mechanism may need to be adjusted in order to allow one mechanism priority over the other. Bocci, et al. Expires January 13, 2005 [Page 10] Internet-Draft PNNI-L2VPN Interworking July 2004 2.2.1 PSN-based Protection of the PSN Tunnel The PSN tunnel can be protected from failures in the PSN using PSN specific mechanisms, for example MPLS Fast Reroute [12]. Whichever mechanism is chosen, the PSN tunnel needs to continue to support any QoS guarantees given to the ATM connections following any restorative action. 2.2.2 PNNI-based Protection of the Pseudo Wires PNNI has its own mechanisms to provide resiliency in a native ATM network. These same mechanisms can be used without modification to provide protection for the ATM pseudo wires carried through the PSN. Two examples are given below. ACs PSN ACs ATM ATM PNNI +------+ PSN Tunnel +------+ PNNI +-----+ | PE1 |==============| PE2 | +-----+ | CE1 |-RCC------ ........PW.......... ----------| CE2 | | |-SIG------ .................... ----------| | | |\ | | | | /| | | |\\ | VPWS | | VPWS | //| | +-----+ \RCC | |==============| | // +-----+ \\ +------+ | | // SIG\\ +------+ PSN Tunnel | | // \\ | PE3 |==============| | // \\--- .................... ---// \--- .................... ---/ | |==============| | +------+ +------+ Figure 5: Dual Homing Example Figure 5 shows an example of multi-homing of the ATM network into the PSN cloud, using PNNI rerouting to protect against failures of PE1 or the PSN tunnel. An additional PE, PE3. is shown in the network above that is connected to the ATM network, together with an additional PSN tunnel from PE3 to PE2. Both PSN tunnels are configured as PNNI links, with associated RCCs and Signalling Channels. If PSN tunnel PE1->PE2 fails, then PNNI can automatically reroute all ATM connections on PSN tunnel PE1->PE2 to PSN tunnel PE3->PE2. Bocci, et al. Expires January 13, 2005 [Page 11] Internet-Draft PNNI-L2VPN Interworking July 2004 ACs PSN ACs ATM ATM PNNI +------+ Tunnel +------+ PNNI +-----+ | PE1 |==============| PE2 | +-----+ | CE1 |-----------.........PW..........-------------| CE2 | +-----+ | VPWS |==============| VPWS | +-----+ | | | | | |======| |=====| | | |===== | | ====| | +------+ || || +------+ || || +-------+ | | | PE3 | | | +-------+ Figure 6: Multi-Hop ATM Routing Figure 6 shows a third PE, PE3, attached to an additional ATM network. PE3 is connected to PE1 and PE2 using PSN tunnels. All three tunnels (PE1->PE2, PE1->PE3, PE3->PE2) can be configured as PNNI links so that PNNI can automatically use the alternate path formed by PSN tunnels PE1->PE3 and then PE3->PE2 if tunnel PE1->PE2 fails. PE3 simply acts as a transit ATM/PNNI node in this scenario. 2.3 Operations, Administration and Maintenance ATM OAM is tunnelled through the PSN, as described in [5]. ATM OAM is notified of PSN tunnel failures in the same way as it handles port or virtual port failures in an ATM switched network. The mechanisms for detecting tunnel failures depends on the PSN mechanisms used and is outside the scope of this document. Fault management procedures for homogeneous attachement circuits, as applicable to this document, are detailed in [15]. Bocci, et al. Expires January 13, 2005 [Page 12] Internet-Draft PNNI-L2VPN Interworking July 2004 3. Summary This informational document has introduced the method for extending ATM signalling and routing across an MPLS PSN. This is specified in [8]. Simple extensions to PNNI and AINI signalling are described that enable ATM signalling on each PE attached to the PSN to allocate PW labels and to negotiate the encapsulation format used by ATM PWs. ATM routing can also be extended between the PEs in the case of PNNI. These extensions to PNNI and AINI allow end to end ATM switched services across a PSN, including transparent support for all currently deployed features of PNNI and AINI. Future enhancements to PNNI and AINI can also be supported. This is possible without requiring changes to, or direct protocol interactions with, IETF protocols specified for the PSN connecting the two PEs. No changes are required to the PSN itself, or to the attached ATM networks. This is particularly important in the case of the migration of existing ATM services to an MPLS based PSN, because it minimises changes to mechanisms used to provide resiliency to end to end ATM services, and other services such as frame relay and Ethernet that may rely on the underlying ATM infrastructure. The extensions to PNNI and AINI thus provide a natural migration path to enable a PSN to support the complete range of services provided by core ATM network infrastructure today. 4 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels, RFC2119", March 1997. [2] Rosen, E., "Multiprotocol Label Switching Architecture, RFC3031", January 2001. [3] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC3209", December 2001. [4] Bryant, S., "The PWE3 Architecture, draft-ietf-pwe3-arch-06.txt", October 2003. [5] Martini, L., "Encapsulation Methods for Transport of ATM Cells/ Frame Over IP and MPLS Networks, draft-ietf-pwe3-atm-encap-03.txt", October 2003. [6] Andersson, L., "L2VPN Framework, draft-ietf-l2vpn-l2-framework-03.txt", October 2003. Bocci, et al. Expires January 13, 2005 [Page 13] Internet-Draft PNNI-L2VPN Interworking July 2004 [7] Martini, L., "Pseudowire Setup and Maintenance using LDP, draft-ietf-pwe3-control-protocol-05.txt", December 2003. [8] ATM Forum Technical Committee, "ATM-MPLS Network Interworking Signalling Specification, Version 1.0, AF-CS-0197.000", August 2003. [9] ATM Forum Technical Committee, "ATM-MPLS Network Interworking, Version 2.0, AF-AIC-0178.001", August 2003. [10] ATM Forum Technical Committee, "Private Network-Network Interface Specification, Version 1.1 (PNNI 1.1), af-pnni-0055.002", April 2003. [11] ATM Forum Technical Committee, "ATM Inter-Network Interface Specification, Version 1.1 (ANNI 1.1), af-cs-0125.002", September 2002. [12] Pan, P., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels, draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt", December 2003. [13] ATM Forum Technical Committee, "ILMI (Integrated Link Management Interface)", September 1996. [14] Le Faucheur, F., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services, RFC3270", May 2002. [15] Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping, draft-ietf-pwe3-oam-msg-map-00.txt", July 2004. Authors' Addresses Matthew Bocci (editor) Alcatel Phone: +44 20 8883 2782 EMail: matthew.bocci@alcatel.co.uk Martin Jensen Equipe Communications Phone: +1 978 795 2140 EMail: martin@equipecom.com Bocci, et al. Expires January 13, 2005 [Page 14] Internet-Draft PNNI-L2VPN Interworking July 2004 Daniel Proch Marconi Communications Phone: +1 724 742 7746 EMail: daniel.proch@marconi.com Jeff Sugimoto Nortel Networks Phone: +1 613 763 1392 EMail: sugimoto@nortelnetworks.com Himanshu Shah Ciena Corp. Phone: +1 508 489 2196 EMail: hshah@ciena.com Bocci, et al. Expires January 13, 2005 [Page 15] Internet-Draft PNNI-L2VPN Interworking July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Bocci, et al. Expires January 13, 2005 [Page 16] Internet-Draft PNNI-L2VPN Interworking July 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bocci, et al. Expires January 13, 2005 [Page 17]