Network Working Group M. Bocci, Ed. Internet-Draft Alcatel Expires: May 16, 2005 M. Jensen Equipe Communications D. Proch Marconi Communications J. Sugimoto Nortel Networks H. Shah Ciena Corp. November 15, 2004 Signalling Interworking for Asynchronous Transfer Mode Virtual Private Wire Service draft-bocci-l2vpn-pnni-mpls-iw-02 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 May 16, 2005. Copyright Notice Bocci, et al. Expires May 16, 2005 [Page 1] Copyright (C) The Internet Society (2004). Internet-Draft PNNI-L2VPN Interworking November 2004 Abstract This Internet Draft describes a method for control plane interworking for Asynchronous Transfer Mode (ATM) pseudo wires, 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) or the ATM Inter-Network Interface (AINI). 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 . . . . . . . . . . . 6 2.1 Tunnelling of the ATM Control Plane . . . . . . . . . . . 6 2.1.1 Extending ATM Signalling Across the PSN . . . . . . . 7 2.1.2 Extending PNNI Routing Across the PSN . . . . . . . . 8 2.1.3 ATM Control Plane Association to PSN Tunnels . . . . . 8 2.1.4 Encapsulation Format . . . . . . . . . . . . . . . . . 9 2.1.5 Quality of Service . . . . . . . . . . . . . . . . . . 9 2.2 Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2.1 PSN-based Protection of the PSN Tunnel . . . . . . . . 10 2.2.2 PNNI-based Protection of the Pseudo Wires . . . . . . 10 2.3 Operations, Administration and Maintenance . . . . . . . . 11 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 5.2 Informative References . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Bocci, et al. Expires May 16, 2005 [Page 2] Internet-Draft PNNI-L2VPN Interworking November 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 [7] 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 May 16, 2005 [Page 3] Internet-Draft PNNI-L2VPN Interworking November 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"[5]. 1.4 Relevance This informative document shows how the existing Layer 2 Virtual Private Network framework (L2VPN)[7] and the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture [3] 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], [6], [8]. 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 [3] ATM Inter Network An 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 (AC) a PE to a CE. In the context of the application described here, this will be an ATM VCI or VPI. Integrated An ATM Forum specification allowing any ATM Link Management device to be provided with status and Interface (ILMI) configuration information. Bocci, et al. Expires May 16, 2005 [Page 4] Internet-Draft PNNI-L2VPN Interworking November 2004 Private Network ATM Forum specification to establish point to Network Interface to 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 Emulation A mechanism that emulates the essential Edge to Edge (PWE3) attributes of a service (such as an ATM VCC) 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 Wire Service (VPWS) two 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 [5]. Figure 2 summarizes the main terms. 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 May 16, 2005 [Page 5] Internet-Draft PNNI-L2VPN Interworking November 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 [8], or RSVP-TE [6]. 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 [5]. Bocci, et al. Expires May 16, 2005 [Page 6] Internet-Draft PNNI-L2VPN Interworking November 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 MUST established, using the PW signalling protocol [8], or by configuration. to 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. [5] 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 [5] 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. [5] Bocci, et al. Expires May 16, 2005 [Page 7] Internet-Draft PNNI-L2VPN Interworking November 2004 and [8]. This is a common capability in current PE devices. Implementations should provide a mechanism to restrict the maximum the number of PWs that can be established on the PSN tunnel so that the PW label space in the downstream PE does not become exhausted. The details of this mechanism are outside the scope of this document. 2.1.2 Extending PNNI Routing Across the PSN ATM Routing is also extended between PE1 and PE2 as explained in [5]. 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 [8], 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 Bocci, et al. Expires May 16, 2005 [Page 8] Internet-Draft PNNI-L2VPN Interworking November 2004 "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 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 [4] are used for user connections based on the signalled ATM parameters, as defined in [5]. The choice of encapsulation will depend on its ability to support the requirements of the ATM service, as described in [4]. 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 Bocci, et al. Expires May 16, 2005 [Page 9] Internet-Draft PNNI-L2VPN Interworking November 2004 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. 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 Bocci, et al. Expires May 16, 2005 [Page 10] Internet-Draft PNNI-L2VPN Interworking November 2004 reroute all ATM connections on PSN tunnel PE1->PE2 to PSN tunnel PE3->PE2. 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 [4]. 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 ATM PWs are outside the scope of this document. Bocci, et al. Expires May 16, 2005 [Page 11] Internet-Draft PNNI-L2VPN Interworking November 2004 3. Security Considerations Extended PNNI uses pseudo wires to transport ATM signalling and routing across a PSN. The security of the transported ATM service will only be as good as the security of the PSN. This level of security might be less rigorous then a native ATM service. Bocci, et al. Expires May 16, 2005 [Page 12] Internet-Draft PNNI-L2VPN Interworking November 2004 4. IANA Considerations This document has no IANA actions. Bocci, et al. Expires May 16, 2005 [Page 13] Internet-Draft PNNI-L2VPN Interworking November 2004 5. References 5.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Rosen, E., "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [3] Bryant, S., "The PWE3 Architecture, draft-ietf-pwe3-arch-07.txt", March 2004. [4] Martini, L., "Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks, draft-ietf-pwe3-atm-encap-07.txt", October 2004. [5] ATM Forum Technical Committee, "ATM-MPLS Network Interworking Signalling Specification, Version 1.0, AF-CS-0197.000", August 2003. 5.2 Informative References [6] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [7] Andersson, L., "L2VPN Framework, draft-ietf-l2vpn-l2-framework-05.txt", June 2004. [8] Martini, L., "Pseudowire Setup and Maintenance using LDP, draft-ietf-pwe3-control-protocol-11.txt", October 2004. [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-07.txt", September 2004. [13] ATM Forum Technical Committee, "ILMI (Integrated Link Management Interface)", September 1996. Bocci, et al. Expires May 16, 2005 [Page 14] Internet-Draft PNNI-L2VPN Interworking November 2004 [14] Le Faucheur, F., "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. 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 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 May 16, 2005 [Page 15] Internet-Draft PNNI-L2VPN Interworking November 2004 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bocci, et al. Expires May 16, 2005 [Page 16]