Network Working Group Thomas D. Nadeau Internet Draft Monique Morrow Expires: November 2003 Cisco Systems, Inc. June 2003 Pseudo Wire (PW) OAM Message Mapping draft-nadeau-pwe3-oam-msg-map-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright (C) The Internet Society (2001). All rights reserved. Abstract This document enumerates the OAM message mapping from pseudo wire emulated edge-to-edge services over MPLS and IP transport networks to their native attached services. Table of Contents Abstract 1. Scope....................................................2 2. Terminology..............................................2 3. Introduction.............................................3 4. Overview of ATM and Frame Relay Management functions.....7 5. Like-to-Like Scenarios..................................10 6. L2TPv3 Message Mapping..................................11 7. Ethernet Interworking Mapping...........................11 Nadeau et al. Expires November 2003 [Page 1] Internet Draft PWE3 OAM Message Mapping June 29, 2003 8. VPLS....................................................11 9. Security Considerations.................................11 10. Intellectual Property Rights Notices...................14 11. Full Copyright Statement...............................14 1. Scope L2TPV3 OAM message mapping will be added to this document in a future version. OAM message mapping related to Ethernet interworking will be added to this document in a future version. 2. Terminology AIS Alarm Indication Signal AOM Administration, Operation and Maintenance CC Continuity Check CE Customer Edge CPCS Common Part Convergence Sublayer FRBS Frame Relay Bearer Service IWF Interworking Function LB Loopback NE Network Element OAM Operations and Maintenance PE Provider Edge PW Pseudowire PSN Packet Service Node RDI Remote Defect Indicator SDU Service Data Unit VCC Virtual Channel Connection VPC Virtual Path Connection 3. Introduction This document describes the mapping to/from of faults detected in pseudo-wires carrying emulated services to OAM messages native to those services. This includes multiple networks involving ATM, MPLS, IP and Frame-Relay either in a like-to- like (ATM-MPLS-ATM) or an interworking configuration (i.e: FR- MPLS-ATM). While management interworking is well defined for ATM/Frame Relay [FRF.8.1, ITU-T I.555], the mapping of PW failures to the equivalent ATM/Frame Relay OAM messages when pseudo wires are used to interconnect these technologies is not well defined. Nadeau et al. Expires November 2003 [Page 2] Internet Draft PWE3 OAM Message Mapping June 29, 2003 For example, in the case of ATM like-to-like pseudowire, the transport of OAM cells depends on the defined modes, but interworking with packet services node failures is not defined. A summary of these modes and OAM transport capabilities will be shown TBD. Since local OAM termination interpretation and reporting is in some cases optional, certain failures may be detected by the customer edge without the knowledge of the carrier. |<--ATM-->| |<-MPLS-->| |<-ATM->| | | | | | | ATMv v ATM v v ATM v V ATM UNI UNI UNI UNI +----+ | | | NNI | | NNI | | | +----+ |ATM |----|..................| |................|---|ATM | | CPE| | | | | | | | | |CPE | | |----|..................| |................|---| | +----+ | | | | | | | | +----+ Customer^ ^Customer Edge 1| <-ATMoMPLS-> | Edge 2 |<-----------ATM PVC----------->|<-----ATM PVC------>| Figure 1 ATM Like-to-Like over MPLS The mapping of MPLS data-plane failures can also be useful in some deployment scenarios where the provider edge terminates OAM messages and no means are defined to transport them across the pseudowire, management interworking will be lost. Such an application exists when transporting services over MPLS in an any-to-any interworking configuration. This involves two provider edge devices interconnected by a pseudowire using MPLS as a transport. One provider edge might terminate a Frame Relay service and another provider edge terminates an ATM service. In this case Frame Relay and ATM OAM is terminated locally without transport over the pseudo-wire. Thus a data- plane failure in the pseudowire is neither detected nor reported to the ATM/Frame Relay networks which view the pseudo- wire as if it were a native interface. For more details on this application please see [SAJASSI]. Even though this application has some merits as described in the aforementioned draft, the lack of management interworking is a major drawback. However, with the introduction of LSP ping [LSPPING], VCCV [VCCV] and additional techniques described herein, it is possible to retain native OAM message mechanisms when using a packet switched network as described in [PWEARCH]. Nadeau et al. Expires November 2003 [Page 3] Internet Draft PWE3 OAM Message Mapping June 29, 2003 The following figures are provided to illustrate the above point. |<--FR-->| |<-ATM->| | | | | FR v v FR IWF ATM v v ATM UNI UNI +----+ UNI UNI +----+ | | | NNI | | NNI | | | +---+ | FR |---|......... ........| |...................|---|ATM | | CPE| | | | | | | | | |CPE | | |---|..................| |...................|---| | +----+ | | | | | | | | +----+ Customer^ +----+ ^Customer Edge 1| | Edge 2 |<---------FR PVC-------->| |<------- ATM PVC------>| | | | | |<-Q933-><-Q933-> <-Q933->| |<- F5/F4 end to end -->| | <------------| |---------------------->| | Interworking Q933| |Interworking OAM cells | | | | | | | | --------->| | | | AIS | | | |<----------------------| | | | RDI | | | |<--------------------->| | | | CC | | | | | |------------------------>| |---------------------->| |<------------------------v |<----------------------v Loopback (ITU-T I.620) Loopback Figure 2: Basic Frame Relay/ATM interworking without IP/MPLS F4 flows transpire between network elements and are used within virtual paths to report an unavailable path or virtual path that cannot be guaranteed. F5 flows transpire between network elements used within virtual connections to report degraded virtual channel performance such as late arriving cells, lost cells and cell insertion problems. Both F4 and F5 flows can be configured as either end-to-end or segment-loopback and used with an alarm indication signal (AIS) and remote defect indication (RDI) functions. Frame Relay/ATM IWF is performed at one of the provider edges, and management interworking is transported/extended across the Frame Relay pseudowire. Figure 3 is an example of Frame Relay extended across the MPLS network. Nadeau et al. Expires November 2003 [Page 4] Internet Draft PWE3 OAM Message Mapping June 29, 2003 |<--FR-->| |<-MPLS-->| |<-ATM->| | | | | | | FR V v FR v v ATM v V ATM UNI UNI UNI UNI +----+ | | | NNI | | NNI | | | +----+ | FR |---|......... ........| |................|---|ATM | | CPE| | | | | | | | | |CPE | | |---|..................| |................|---| | +----+ | | | | | | | | +----+ Customer^ ^Customer Edge1| <-FRoMPLS-> |Edge2 |<-----------FR PVC------------>|<-----ATM PVC------>| Figure 3 FR/ATM interworking with IP Frame Relay/ATM Interworking function is performed at one of the provider edges and management interworking is transported and extended across the Frame Relay pseudowire. Figure 4 depicts ATM extended across the MPLS network |<--FR-->| |<-MPLS->| |<-ATM->| | | | | | | FR V v FR v v ATM v V ATM UNI UNI UNI UNI +----+ | | NNI | | NNI | | | +----+ | FR |-|......... ........| |................|---|ATM | | CPE| | | | | | | | | |CPE | | |-|..................| |................|---| | +----+ | | | | | | | | +----+ Customer^ ^Customer Edge 1 | | Edge 2 |<-----------FR PVC--->|<--------ATM PVC----->| Figure 4: Frame Relay/ATM Interworking with IP/MPLS Frame Relay/ATM Interworking function is performed at one of the provider edges and management interworking is transported and extended across the ATM pseudowire. When extending Frame Relay or ATM across the MPLS network, the mapping of OAM functionality between ATM and Frame Relay is the same as in the basic Frame Relay/ATM interworking without ATM case. Nevertheless, in the MPLS cloud, when Frame Relay (resp. ATM) extends across the MPLS network it is necessary to define Frame Relay OAM (resp. ATM OAM) mapping to MPLS OAM on this "segment". In Figure 5 MPLS OAM is performed by MPLS LSP PING and Tunnel trace functions. Nadeau et al. Expires November 2003 [Page 5] Internet Draft PWE3 OAM Message Mapping June 29, 2003 || |<-MPLS->| || | | | | | | FR v v FR v v ATM v vATM UNI UNI UNI UNI +---+ | | | NNI| | NNI | | | +----+ |FR |---|..............| |.................|---|ATM | |CPE| | | | | | | | | |CPE | | |---|..............| |.................|---| | +---+ | | | | | | | | +----+ Cust^ ^Cust Edge1| |Edge2 |<----FR PVC----> | |<----ATM PVC-------->| | | | | | ||< F5/F4 end to end> | | <------------ | |-------------------->| |InterworkingQ933 | |Interworking OAM cell| | | | | | | | ---------> | | | | AIS | | | |<--------------------| | | | RDI | | | |<------------------->| | | | CC | | | | | |---------------> | |-------------------->| |<--------------- | |<--------------------| Loopback (ITU-T I.620) Loopback Figure 5: FR/ATM interworking with IP/MPLS 4. Overview of ATM and Frame Relay Management functions 4.1. Frame Relay Management The management of Frame Relay Bearer Service (FRBS)[ITU-T I.555] connections can be accomplished through two distinct methodologies: 1. Based on ITU-T Q.933 Annex A, Link Integrity Verification procedure, where STATUS and STATUS ENQUIRY signaling messages are sent using DLCI=0 over a given UNI and NNI physical link. [ITU-T Q.933] 2. Based on FRBS LMI, and similar to ATM ILMI where LMI is common in private Frame Relay networks. Nadeau et al. Expires November 2003 [Page 6] Internet Draft PWE3 OAM Message Mapping June 29, 2003 In addition, ITU-T I.620 addresses Frame Relay loopback, but the deployment of this standard is relatively limited. [ITU-T I.620] It is possible to use either, or both, of the above options to manage Frame Relay interfaces. However, from the perspective of ATM/Frame Relay interworking, Q.933 messages are used and mapped to the corresponding ATM OAM when possible. The status of any provisioned Frame Relay PVC may be updated through: STATUS messages in response to STATUS ENQUIRY messages, these are mandatory. Optional unsolicited STATUS updates independent of STATUS ENQUIRY (typically under the control of management system, these updates can be sent periodically (continuous monitoring) or only upon detection of specific defects based on configuration. Note that in contrast to ATM, monitoring the status of Frame Relay PVC end-to-end requires coordination with management systems since Q.933 messages are link-to-link between nodes. Frame Relay/ATM management interworking is defined in [FRF.8.1] and [ITU-T I.555]. 4.2. ATM management ATM management and OAM mechanisms are much more evolved than those of Frame Relay. There are five broad management-related categories, including fault management (FT), Performance management (PM), configuration management (CM), Accounting management (AC), and Security management (SM). ITU-T Recommendation I.610 describes the functions for the operation and maintenance of the physical layer and the ATM layer, that is, management at the bit and cell levels. The document scope is to focus on fault management interworking between Frame Relay, ATM and MPLS, we will therefore concentrate on ATM fault management functions. [ITU-T I.610] Fault management functions include the following: 1) Alarm indication signal (AIS) 2) Remote Defect indication (RDI). 3) Continuity check (CC). 4) Loopback (LB) Some of the basic ATM fault management functions are described as follows: Alarm indication signal (AIS) sends a message in the same direction as that of the signal, to the effect that an error Nadeau et al. Expires November 2003 [Page 7] Internet Draft PWE3 OAM Message Mapping June 29, 2003 has been detected. Remote defect indication (RDI) sends a message to the transmitting terminal that an error has been detected. RDI is also referred to as the far-end reporting failure. Alarms related to the physical layer are indicated using path AIS/RDI. Virtual path AIS/RDI and virtual channel AIS/RDI are also generated for the ATM layer. OAM cells (F4 and F5 cells) are used for the control of virtual paths and virtual channels with regard to their performance and availability. F4 cells are used to monitor a VPC, F5 cells for a VCC. OAM cells in the F4 and F5 flows are used for monitoring a segment of the network and end-to-end monitoring. OAM cells in F4 flows have the same VPI as that of the connection being monitored. OAM cells in F5 flows have the same VCI as that of the connection being monitored. The AIS and RDI messages of the F4 and F5 flows are sent to the other network nodes via the VPC or the VCC to which the message refers. The type of error and its location can be indicated in the OAM cells. Continuity check is another fault management function. To check whether a VCC that has been idle for a period of time is still functioning, the network elements can send continuity-check cells along that VCC. Please note that in Frame Relay/ATM service interworking specified in FRF.8.1 and ITU-T I.555 only some of the above functions are mapped, but not loopback. Other functions are not simple to map due to lack of equivalent procedures and functions. 4.3. Mapping of Management Messages In general, fault management interworking between Frame Relay and ATM may be summarized as down to STATUS "up" or "down" on the frame relay side and AIS on the ATM side. Although on the ATM side fault management and localization is much more advanced than that of Frame Relay, at the service interworking level the limitation is the least common denominator (FR). In cases where OAM is terminated at the PEs and the PW is not capable of transporting OAM VCCV[VCCV] proposes a mechanism that supports this function. 4.4. Mapping of MPLS data-plane failures MPLS LSP Ping and VCCV failure handling and the associated OAM messages at both ATM and Frame Relay network sides is illustrated below. Since MPLS ping detects various kinds of data-plane problems, it is assumed that the L2-circuit-ID Nadeau et al. Expires November 2003 [Page 8] Internet Draft PWE3 OAM Message Mapping June 29, 2003 option would be used to detect failure of the PW before any drastic measure is taken (Vc label withdraw). Also it is recommended to try multiple LSP pings before tearing down all the associated PW and impacting all the associated attachment circuits. Ideally the number of ping failures that triggers the PW break up would be user configured (1-x). Once the failure is confirmed and the associated PW are torn down, the PE attached to the ATM network must generate AIS on all the corresponding PVCs at a nominal rate of one AIS/sec/Vc. The PE that is attached to the Frame Relay network can optionally send asynchronous STATUS messages indicating inactive state of all the corresponding DLCIs, or STATUS messages could be sent as response to STATUS ENQUIRY messages. Please note that even though the fault condition is, in this case, external to the ATM and Frame Relay networks, this will not be known to the downstream ATM or FR NEs. This ambiguity is also present in the case of ATM/Frame Relay interworking [FRF.8.1, I.555] without MPLS. There are two possible mechanisms to resolve this issue: 1) Use optional codepoint in the defect location or defect type fields in the AIS/RDI OAM cells to indicate external defect source. 2) Use new type of interworking OAM cells. 4.5. Mapping of ATM PVC management procedures In this section it is assumed that both Frame Relay and MPLS networks are in working order, and the problem is initiated from the ATM network. The fault management functions considered include: 1) AIS/RDI OAM cells 2) End-to-end CC cells, if this option is supported. 3) Loopback cells, under System Management control. For items 1 and 2, these fault conditions should trigger PW tear down without the involvement of MPLS ping. However, Loopback may be used to initiate automatic MPLS Ping. Each of the above conditions is discussed below. 4.6. Mapping of AIS/RDI ATM network faults leading to AIS/RDI cells being received at Nadeau et al. Expires November 2003 [Page 9] Internet Draft PWE3 OAM Message Mapping June 29, 2003 the PE's ATM interface will result in the tear down of the associated PWs. It is recommended to allow user configurable trigger (1-X, AIS/RDI cells) before PW is torn down to prevent transient failures from tearing down the PW. The ATM PVC is considered inactive "down" when it is not deleted from the ATM network and ASI/RDI cells are received. In order to take the appropriate action at the Frame Relay side, the tear down of the PW is used as the trigger. The PE connected to the Frame Relay network must send Active bit = 0 in the full status report for the corresponding Frame Relay PVCs if configured. Optionally this status update could use the async status message for the corresponding FR PVCs. Recovery from the AIS state is initiated by one of the following conditions: 1. No AIS/RDI Cells are received for 2.5+ - 0.5 sec, while no user-data or CC cells are received during the period. [ITU-T, I.610] 2. User-data cells are received. 3. CC cells are received. After recovery on the ATM side, the following steps are taken: Re-establish PW by the PE at the ATM side. PE at the FR side must send "active" STATUS messages for the corresponding DLCIs. 4.7. Mapping of Continuity Check Continuity check, if supported, can be mapped as described in the AIS/RDI case. In this case, the absence of CC cells or user data cells for the specified period (3.5 + - 0.5 sec nominally) indicates the ATM PVC is "down" [ITU-T I.610]. 4.8. Mapping of Loopback Loopback procedure is typically initiated under the control of NE Management system or the end user management system for in- service or pre-service connectivity verification and fault localization. The ATM PVC is considered inactive if loopback test is unsuccessful, i.e. cells are not received back to the originating point within 5 seconds (nominally). The mapping of LB tests on the ATM side to Frame Relay side is not typically done since I.620 (Frame Relay loopback) is not widely Nadeau et al. Expires November 2003 [Page 10] Internet Draft PWE3 OAM Message Mapping June 29, 2003 deployed. However, in FRF.8.1, unsuccessful LB tests are mapped into STATUS inactive for the corresponding FR DLCI(s). Thus, similar functionality can be achieved, if the PE on the ATM side tears down the associated PW, which will result in similar treatment to the AIS/RDI or CC faults.[ITU-T I.620, FRF.8.1] Some potential improvements can be achieved if ATM LB test happens to be successful, but the PE at the ATM side uses the LB test to trigger automatic MPLS ping. In this case, if we assume that the ATM network is functional but there is a problem in the MPLS data-plane, then invoking ATM LB test will result in successful LB, but the PE at the ATM side will generate AIS if the MPLS ping fails. 4.9. Mapping of Frame Relay PVC management procedures This is the simplest case, since only STATUS "up" or "down" are relevant. 5. Like-to-Like Scenarios In the case of like-to-like PWs, MPLS ping can also be useful in detecting and reporting problems. The following sections will use ATMoMPLS as an example. Even though mechanisms for transporting ATM OAM cells over the PW are well defined, as described in the introduction, the support of such function is optional. If OAM transport is supported and enabled, MPLS data- plane failures may not be detected in time unless CC or loopback OAM cells are used. Thus, MPLS ping can be very useful, especially if the PE routers do not support transport of OAM. 5.1. Mapping of MPLS Data Plane Failures MPLS LSP Ping and VCCV failure can be used to generate the appropriate alarms at the edges as shown below. In this case, it is assumed that either the PEs do not support OAM transport or that they do, but CC/LB is not enabled. Otherwise, if the PEs support OAM transport and CC is enabled, it is likely that MPLS data-plane failure will be detected within 3.5+ - 0.5 sec (CC timeout). 5.2. Mapping of Continuity Check If PEs do not support transport of OAM cells, and segment CC is supported/enabled but terminated at the PEs, then MPLS data- plane failure can be detected by MPLS ping. Ping failure Nadeau et al. Expires November 2003 [Page 11] Internet Draft PWE3 OAM Message Mapping June 29, 2003 should be used to trigger AIS States at the two PEs. i.e. generate AIS on the corresponding PW PVCs at a rate of 1 AIS per sec per VC. 5.3. Mapping of Loopback As described in section 4.8 some potential improvements can be achieved if ATM segment LB tests happen to be successful, but the PEs use the ATM LB test to trigger automatic MPLS ping. In this case, if we assume that the ATM network is functional but there is a problem in the MPLS data-plane, then invoking ATM segment LB test will result in successful LB, but the PE at the ATM side will generate AIS if the MPLS ping fails. 6. L2TPv3 Message Mapping [TBD] 7. Ethernet Interworking Mapping [TBD] 8. VPLS [TBD] 9. Security Considerations The mapping messages described in this document do not change the security functions inherent in the actual messages. 10. Acknowledgments Hari Rakotoranto, Eric Rosen, Mark Townsely, Michel Khouderchah, Bertrand Duvivier, Vanson Lim and Chris Metz Cisco Systems. 11. References [VCCV] Nadeau, T., et al. " Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV)", Internet Draft , February 2003. [PWREQ] Xiao, X., McPherson, D., Pate, P., Gill, V., Kompella, K., Nadeau, T., White, C., "Requirements for Pseudo Wire Emulation Nadeau et al. Expires November 2003 [Page 12] Internet Draft PWE3 OAM Message Mapping June 29, 2003 Edge-to-Edge (PWE3)", , November 2001. [PWE3FW] Prayson Pate, et al., Internet draft, Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3), draft- ietf-pwe3-framework-01.txt, work in progress. [PWEARCH] Bryant, S., Pate, P., Johnson, T., Kompella, K., Malis, A., McPherson, D., Nadeau, T., So, T., Townsley, W., Systems, White., C., Wood, L., Xiao, X., Internet draft, Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3), draft- ietf-pwe3-framework-01.txt, work in progress. [L2SIG] Rosen, E., LDP-based Signaling for L2VPNs, Internet Draft , September 2002. [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow, G., Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS", Internet Draft , April 2003. [GTTP] Bonica, R., Kompella, K., Meyer, D., "Generic Tunnel Tracing Protocol (GTTP) Specification", Internet Draft , April, 2003 [FRF 8.1] Frame Relay Forum, Frame Relay / ATM PVC Service Interworking Implementation Agreement,February 2000 [ITU-T] "Draft Recommendation Y.17fw" (MPLS Management Framework), July 2002. [ITU-T] "Frame Relay Bearer Service Interworking," I.555, September 2997. [ITU-T], "Frame Relay Operations Principles and Functions, " I.620, October, 1996. [ITU-T] Q.933, ISDN Digital Subscriber Signalling System No. 1 (DSS 1) - Signalling specification for frame mode basic call control, November 1995. [ICMP] Postel, J. "Internet Control Message Protocol, " RFC 792 [PWEATM] Martini, L., et al., "Encapsulation Methods for Nadeau et al. Expires November 2003 [Page 13] Internet Draft PWE3 OAM Message Mapping June 29, 2003 Transport of ATM Cells/Frame Over IP and MPLS Networks," Internet Draft , October 2002 [MPLSOAMREQS] Nadeau, T., et al, OAM Requirements for MPLS Networks, Internet Draft , February 2003. [PWE3CONTROL] L.Martini et al., Transport of Layer 2 Frames over MPLS, Internet Draft, , May 2003 [PPVPNFW] Callon, R., Suzuki, M., Gleeson, B., Malis, A., Muthukrishnan, K., Rosen, E., Sargor, C., and J. Yu, "A Framework for Provider Provisioned Virtual Private Networks", Internet Draft , July 2001. [SAJASSI] A.Sajassi et al., "L2VPN Interworking," Internet Draft , November 2002. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. Author's Addresses Thomas D. Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Email: tnadeau@cisco.com Monique Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com 12. Intellectual Property Rights Notices 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 Nadeau et al. Expires November 2003 [Page 14] Internet Draft PWE3 OAM Message Mapping June 29, 2003 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 implementers 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. 13. Full Copyright Statement Copyright (C) The Internet Society (2000). 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 assigns. 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Nadeau et al. Expires November 2003 [Page 15]