PWE3 Working Group Jixiong Dong Internet Draft Huawei Expires: April 2006 October 27, 2005 Operation and Maintenance for Multi-segment Pseudo Wire draft-dong-pwe3-mspw-oam-01.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 April 27, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This draft proposes a method for operation and maintenance on the multi-segment pseudo wires (MS-PWs). It extends and is compatible with the existing single-segment pseudo wire OAM mechanism [VCCV]. Dong Expires April 27, 2006 [Page 1] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 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. Table of Contents 1. Introduction................................................2 2. Reference Model for MS-PW OAM...............................3 3. MS-PW OAM functions.........................................5 3.1. Segment OAM and End-to-end OAM.........................5 3.2. Fault Notification.....................................6 3.3. OAM Extension..........................................8 3.3.1. Inband VCCV Extension.............................8 3.3.2. Out-of-band VCCV Extension........................9 3.3.3. Expiry TTL VCCV Extension........................10 4. OAM Capability Indication for Multi-segment PW using MPLS..10 4.1. Introduction..........................................10 5. MS-PW OAM procedures in IP PSN.............................11 5.1. L2TPv3 VCCV FDI AVP Message...........................11 5.2. L2TPv3 VCCV Capability Indication AVP Message.........11 6. IANA Considerations........................................12 6.1. VCCV Parameter ID.....................................12 6.1.1. CV Types.........................................12 6.2. L2TPv3 Assignments....................................12 6.2.1. CV Types.........................................13 7. Security Considerations....................................13 8. Acknowledgments............................................13 9. References.................................................13 9.1. Normative References..................................13 9.2. Informative References................................14 10. Author's Addresses........................................14 11. Intellectual Property Statement...........................14 Disclaimer of Validity........................................15 Copyright Statement...........................................15 Acknowledgment................................................15 1. Introduction One pseudo-wire may reach across more than one packet switched network (PSN) domain and more than one PSN tunnel. These pseudo-wires are called multi-segment pseudo-wires (MS-PW). One pseudo-wire may exist in only one packet switched network (PSN) domain and only one PSN tunnel. These pseudo-wires are called single-segment pseudo-wires (SS-PW). Dong Expires April 27, 2006 [Page 2] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 The interworking of operation and maintenance (OAM) mechanisms for SS-PWs between ACs and PWs is defined in [OAMMAP], which enables defect states to be propagated across a PWE3 network. OAM mechanisms for MS-PWs MUST provide at least the same capabilities as those for SS-PWs, i.e., which must comply with SS-PW OAM mechanisms. In addition, it should be possible to support the other OAM requirements described in [MSPWREQ]. This draft extends the VCCV mechanism described in [VCCV] to implement MS-PW OAM functions. To support FDI function, new FDI payload packet type is introduced. 1.1. Terminology The terminology specified in [MSPW-ARCH] and [L2VPN-OAMFRM] applies. In addition, we define the following terms: o E2E OAM(end-to-end OAM): the OAM mechanisms apply between the two T-PEs. S-PE MUST transfer the E2E OAM packets transparently. o SEG OAM(Segment OAM): the OAM mechanisms apply on PW segment. All of the PW segment, which is set up between T-PE and S-PE, S-PE and S-PE, can use the SEG OAM mechanisms. The SEG OAM packets MUST be terminated at the end of the PW segment, i.e., S-PE or T-PE. 2. Reference Model for MS-PW OAM The figure below describes PW switching reference model [MSPWREQ]. There are four PW segments in the figure, that is, PW1, PW2, PW3 and PW4. Dong Expires April 27, 2006 [Page 3] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 Native |<-----------Pseudo Wire----------->| Native Service | | Service (AC) | |<-PSN1-->| |<--PSN2->| | (AC) | V V V V V V | | +----+ +-----+ +----+ | +----+ | | PE1|=========| PE2 |=========| PE3| | +----+ | |----------|........PW1.........|...PW3........|----------| | | CE1| | | | | | | | | |CE2 | | |----------|........PW2.........|...PW4........|----------| | +----+ | | |=========| |=========| | | +----+ ^ +----+ +-----+ +----+ | ^ | Provider Edge 1 ^ Provider Edge 3 | | | | | | | | PW switching point | | | | | |<------------------- Emulated Service ------------------>| Figure 1 PW switching Reference Model One MS-PW may consist of multiple PW segments, e.g., MS-PW1 contains two PW segments, PW1 and PW3. One MS-PW can be regarded as one logical pseudo wire. Each PW segment can be regarded as one individual physical link. From layer network point of view, MS-PW is a client sublayer and PW segment is the server sublayer. Thus, the reference model above can be illustrated by the following figure. +----+ +-----+ +-----+ +----+ +----+ | PE1|======|S-PE1|=======|S-PE2|=======| PE2| +----+ | |-----|...................MS-PW....................|-----| | | CE1| | | | | | | | | |CE2 | | |-----|-------PW1----------PW2------------PW3------|-----| | +----+ | |======| |=======| |=======| | +----+ +----+ +-----+ +-----+ +----+ Figure 2 MS-PW layered reference model End-to-end OAM (E2E OAM) flow is used for the OAM communications between the ingress T-PE and the egress T-PE of a logical MS-PW. Segment OAM (SEG OAM) flow is used for the OAM communications between the ingress PE and the egress PE of a physical PW segment. SS-PW MUST be regarded as one type of special PW segment. Therefore SS-PW should use SEG OAM mechanisms. Refer to the above reference model, we can deduce the following MS-PW OAM reference model. Dong Expires April 27, 2006 [Page 4] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 +----+ +-----+ +-----+ +----+ +----+ | PE1|======|S-PE1|=======|S-PE2|=======| PE2| +----+ | |-----| +................E2E OAM.................+ |-----| | | CE1| | | | | | | | | |CE2 | | |-----| +---SEG OAM-+ +---SEG OAM-+ +---SEG OAM--+ |-----| | +----+ | |======| |=======| |=======| | +----+ +----+ +-----+ +-----+ +----+ Figure 3 MS-PW OAM layer reference model [OAM-APP] introduces the notion of OAM domain, ME, MEP and MIP to the PWE3 field to build the PWE3 OAM framework. Based on these work, we can define the MEPs and MIPs in the PW layer of AC/PW/AC layer. +----+ +-----+ +-----+ +----+ +----+ | PE1|======|S-PE1|=======|S-PE2|=======| PE2| +----+ | |-----| ..................MS-PW.................. |-----| | | CE1| | | | | | | | | |CE2 | | |-----| | | | | | | | | | +----+ | |======| |=======| |=======| | +----+ +----+ +-----+ +-----+ +----+ C MEP---------MIP-----------MIP-----------MEP ^ ^ ^ ^ ^ ^ | | | | | | D MEP MEP MEP MEP MEP MEP C is the MS-PW OAM sublayer D is the PW segment sublayer Figure 4 MEPs and MIPs definition for the MS-PW OAM layer 3. MS-PW OAM functions 3.1. Segment OAM and End-to-end OAM End-to-end OAM (E2E OAM) packets are generated at T-PE of a MS-PW, transferred transparently across all S-PEs, and terminated at the peer T-PE of the MS-PW. Segment OAM (SEG OAM) packets are generated at the one end of a PW segment, terminated at the other end of the PW segment, where the end of PW segment can be T-PE or S-PE of the MS-PW. SEG OAM mechanism is as same as the existing OAM mechanism defined in [VCCV], [OAMMAP], [CTRL]. Dong Expires April 27, 2006 [Page 5] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 For each SS-PW, SEG OAM mechanisms could be adopted. For each MS-PW, E2E OAM mechanisms could be used as described in following. For example, when we use one MS-PW to protect another MS-PW, we can use the E2E OAM mechanisms. If only one segment of the MS-PW, for some reasons such as management/resource/environment conditions, need be protected, SEG OAM must only be used at some specific PW segment. Of course, we maybe perform E2E OAM mechanisms over a MS-PW and SEG OAM mechanisms over its PW segments at the same time. When S-PE receives one OAM packet, it must determine whether it is a SEG OAM packet or an E2E OAM packet. The existing OAM mechanism can't perform this, so it must be enhanced. The ingress PE or the egress PE that belongs to one PW segment shall discard all the segment OAM packets coming from another PW segment. 3.2. Fault Notification A PE can receive all kinds of faults reported. The PE may receive physical layer fault report, such as loss of signal. The PE itself may also detect segment fault by VCCV mechanism. An S-PE is also a PE. When an S-PE receives fault report from server layer or a segment fault is detected, the S-PE must forward the fault information to the remote end T-PE of the MS-PW. When a T-PE receives such fault information, it can suppress other alarm information or trigger protection switching. This mechanism is called FDI (Forwarding Defect Indication). At the S-PE, defects in a PSN tunnel must be propagated to all PWs that utilize the tunnel. And FDI OAM packets should be sent to all these PWs. The S-PE which detects a fault shall generate and send out FDI packets to all effected active PWs in the forwarding direction. These faults include, without limit to: - transport tunnel faults; - faults coming from PW status notification; - faults detected by local OAM mechanisms, such as BFD; - local PE faults, such as control software faults. The FDI packets shall be generated and sent to the downstream T-PE of the MS-PW from S-PE as soon as possible when any fault is detected. Dong Expires April 27, 2006 [Page 6] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 The FDI packets shall be sent periodically until the fault is recovered. The transmission speed should be one packet per second. The egress PE of a MS-PW will maintain the status of FDI for each MS- PW. When the egress PE receives a valid FDI packet, the corresponding MS-PW will enter into the FDI state. If the egress PE received E2E OAM packets from the ingress PE, or no FDI packets are received in the three consecutive transmission periods (e.g., three seconds), the MS-PW will exit FDI state. When the T-PE of a MS-PW received a FDI packet, it will send PW status TLV to the peer side T-PE of the MS-PW to notify the current MS-PW status. When an S-PE detected a fault, if the S-PE supports segment OAM functions, it will send PW status TLV to the peer side PE of the PW segment to notify the current status of the PW segment. Note that the above backward fault notification mechanism can also use the specific remote defect indication packet, that is, RDI mechanism. The detailed RDI procedure will be discussed in the future version of this draft. To notify the fault information to the remote side PE, the following new OAM packet format is proposed. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fault Type | Address Family | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | | ,, | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 proposed FDI packet format Fault Type (16 bits): Indicates the detected fault type. The fault types and their encoding are for further study. Address Family (16 bits): Indicates the family of the latter address field. Currently there are two types of address family: IPv4 and IPv6. Dong Expires April 27, 2006 [Page 7] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 Address Family Address Encoding IPv4 4 octet full IPv4 address IPv6 16 octet full IPv6 address Address (16 octets): Indicates the location information of the PE that generates the FDI packet. Its value is the IP address of this PE. When the address family is IPv4, the first 12 octets of this field are filled with zero. Lifetime (32 bits): Indicates the transmission period of FDI packets to the receiver. Its unit is millisecond. 3.3. OAM Extension There are three kinds of OAM data channel [VCCV], which are inband VCCV, out-of-band VCCV, and TTL expiry VCCV. The first one uses the first four nibbles 0001 of the control word to identify OAM packets. The second one uses router alert label to identify the OAM packets. The last one uses TTL= 1 to force the PE process the OAM packets. Because both SEG OAM and E2E OAM have BFD/LSP PING/ICMP PING packet, the type of segment OAM packet must be distinguished, i.e. , SEG OAM packet or E2E OAM packet. When a PE receives an OAM packet, it must determine the packet type (FDI, or others), because FDI checking procedure is different from the procedure of other packet types. 3.3.1. Inband VCCV Extension The following PW Associated Channel Header format is proposed to extend the OAM. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| FmtID |T|F| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 PW Associated Channel Header The meaning of the fields of above PW Associated Channel Header (Figure 5) are as follows: Dong Expires April 27, 2006 [Page 8] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 FmtID: refer to [CW]. T: Indicates the segment type of OAM packet. T = 0 indicates it is SEG OAM packet. T = 1 indicates it is E2E OAM packet. F: Indicates the FDI type of OAM packet. F = 0 indicates it is not a FDI packet. F = 1 indicates it is a FDI packet. Reserved: MUST be set 0, and ignored in reception. Channel Type: Refer to [CW]. 3.3.2. Out-of-band VCCV Extension The out-of-band OAM is generally used when the control word is not used, or the receiving hardware can't process the control word, in the out-of-band VCCV channel. The VCCV control channel can be created via using the MPLS router alert label [RFC3032]. The indicator flag in the payload header may be added to identify the type of OAM packet as the following format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|F| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAM payload | | ,, | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 OAM payload format The meaning and value of T and F fields are as same as that in inband VCCV. Dong Expires April 27, 2006 [Page 9] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 3.3.3. Expiry TTL VCCV Extension For expiry TTL VCCV, it is possible that using control word or not using control word. The OAM payload format described in section 3.3.2 is proposed. 4. OAM Capability Indication for Multi-segment PW using MPLS 4.1. Introduction For a MPLS-PSN, the PE negotiates the utilization of the VCCV when the label mapping messages are exchanged to establish the PW. A new OAM TLV is signaled as part of the PW FEC interface parameters TLV [VCCV].If LDP PW ID FEC (FEC 128) is used, the OAM capability TLV is carried in the Interface Parameter's field. If the LDP Generalized PW ID FEC (FEC 129) is used, it is carried as a sub-TLV in the Interface Parameter's TLV. The CV Type Indicator's field in this TLV defines a bit-mask used to indicate the specific OAM capabilities that the PE can make use of over the PW being established. The defined values are: 0x01 ICMP Ping (predefined in [VCCV]) 0x02 LSP Ping (predefined in [VCCV]) 0x04 BFD for PW Fault Detection only (predefined in [VCCV]) 0x08 BFD for PW Fault Detection and AC/PW Fault Status Signaling (predefined in [VCCV]) 0x10 FDI 0x20 SEG OAM 0x40 E2E OAM A CV type of 0x08 is part of the MS-PW OAM capabilities. It indicates that the PE supports FDI function. When S-PE detects the fault, it will notify the remote side PE of the fault and the latter enters into the proper PW defect state and triggers the appropriate actions. A CV type of 0x10 is part of the MS-PW OAM capabilities. It indicates that the PE supports segment OAM function. In general, PE will Dong Expires April 27, 2006 [Page 10] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 support segment OAM function, this CV type provides an option to open or close the function. It benefits in saving the OAM bandwidth. A CV type of 0x20 is part of the MS-PW OAM capabilities. It indicates that the PE supports end-to-end OAM function. When S-PE receives a E2E OAM packet, it will forward the packet transparently. Note that FDI packet must be E2E OAM packet. After the negotiation process of OAM capability, T-PE may adopt SEG OAM, or E2E OAM, or both of them. When T-PE adopted both, it must send the two types of OAM packet at the same time. S-PE only generates the SEG OAM packets and the FDI packets, forwards the E2E OAM packets including the FDI packets, and terminates the received SEG OAM packets. If S-PE doesn't adopt SEG OAM, it should drop the received SEG OAM packet and doesn't generate any SEG OAM packets. If S-PE does not adopt E2E OAM, it should drop the received E2E OAM packet. This case is for further study if S-PE should generate the FDI packets. 5. MS-PW OAM procedures in IP PSN When L2TPv3 is used to setup a PW over an IP PSN, [VCCV] uses L2- Specific sublayer to carry VCCV messages, and describes an L2TPv3 VCCV capability AVP which provides the equivalent means to signal OAM capabilities between PEs for PW over a L2TP-IP PSN. To support FDI function of the MS-PW OAM capability, a new type of FDI AVP message is defined. To support the new MS-PW OAM capability indicators, a new CV type in VCCV Capability AVP message is defined. 5.1. L2TPv3 VCCV FDI AVP Message The VCCV message MUST contain a VCCV AVP. It does not contain a message header. This could either be a new VCCV ICMP Ping AVP or VCCV BFD AVP or VCCV FDI AVP. The former two are described in [VCCV]. The VCCV FDI AVP encodes the FDI Packet. This AVP may be followed by the L2TPv3 Remote End Identifier AVP to identify the PW associated with the session. 5.2. L2TPv3 VCCV Capability Indication AVP Message A LCCE or a LAC should be able to indicate whether the session is capable of processing VCCV packets by including the optional VCCV capability AVP in an ICRQ, ICRP, OCRQ or OCRP. Dong Expires April 27, 2006 [Page 11] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 The CV Type Indicators field in this AVP message defines a bitmask used to indicate the specific type or types (i.e.: none, one or more) of IP control packets that may be sent on the specified control channel. The defined values are: 0x01 ICMP Ping (predefined in [VCCV]) 0x02 BFD (predefined in [VCCV]) 0x04 FDI 0x08 SEG OAM 0x10 E2E OAM The meaning of the CV type is as same as described in section 4.1. The OAM procedure after negotiation of OAM capability is as same as described in section 4.1. 6. IANA Considerations 6.1. VCCV Parameter ID VCCC parameter ID codepoint is defined in [PWE3IANA]. IANA is requested to maintain a registry for the CC Types and CV Types, bit- masks in the VCCV parameter ID. The allocations must be done using the "First Come First Served" policy defined in RFC2434. IANA is requested to reserve the following bits in this registry: 6.1.1. CV Types 0x10 FDI 0x20 SEG OAM 0x40 E2E OAM 6.2. L2TPv3 Assignments L2TPv3 VCCV FDI AVP must also be assigned by IANA. IANA is requested to maintain a registry for the CV Types, bit-mask in the VCCV Capability AVP. The allocations must be done using the "First Come First Served" policy defined in RFC2434. IANA is requested to reserve the following bits in this registry: Dong Expires April 27, 2006 [Page 12] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 6.2.1. CV Types 0x04 FDI 0x08 SEG OAM 0x10 E2E OAM 7. Security Considerations This draft does not have any additional impact on security of PWs in [VCCV]. 8. Acknowledgments The authors would like to thank Simon Delord, Spencer Dawkins, Yuli Shi for their valuable comments and suggestions. 9. References 9.1. Normative References [MSPW-ARCH] M. Bocci, S.Bryant, " An Architecture for Multi-Segment Pseudo Wire Emulation Edge-to-Edge ", draft-bocci-bryant- pwe3-ms-pw-arch-01.txt, October 2005. [VCCV] T. D. Nadeau, R. Aggarwal, "Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)", draft-ietf-pwe3-vccv- 07.txt, August 2005. [CTRL] Luca Martini (ED), Toby Smith, "Pseudowire Setup and Maintenance using the Label Distribution Protocol", draft- ietf-pwe3-control-protocol-17.txt, June 2005. [OAMMAP] Thomas D. Nadeau, Peter Busschbach, Mustapha Aissaoui, "Pseudo Wire (PW) OAM Message Mapping", draft-ietf-pwe3- oam-msg-map-02.txt, February 2005. [MSPWREQ] Luca Martini, Matthew Bocci, Nabil Bitar, "Requirements for inter domain Pseudo-Wires", draft-ietf-pwe3-ms-pw- requirements-01.txt, October 2005. [CW] S. Bryant, G. Swallow, D. McPherson, "PWE3 Control Word for use over an MPLS PSN", draft-ietf-pwe3-cw-05.txt, July 2005. Dong Expires April 27, 2006 [Page 13] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 [PWE3IANA] Martini, L., Townsley, M., "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-12.txt, June 2005. [OAM-APP] Simon Delord, Philippe Niger, Yuichi Ikejiri, Yuichiro Wada, et al., "PWE3 Applications & OAM Scenarios", draft- delord-pwe3-oam-applications-01.txt, May 2005. [L2VPN-OAMFRM] Dinesh Mohan, Ali Sajassi, "L2VPN OAM Requirements and Framework", draft-ietf-l2vpn-oam-req-frmk-03.txt, July 2005. 9.2. Informative References [REQ] Xiao, X., McPherson, D., Pate, P., "Requirements for Pseudo Wire Emulation Edge to-Edge (PWE3)", RFC 3916, September 2004. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC3031, January 2001. [RFC3032] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D., Fedorkow,G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC3032, January 2001. 10. Author's Addresses Jixiong Dong Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: dongjixiong@huawei.com 11. 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 Dong Expires April 27, 2006 [Page 14] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 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 (2005). 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. Dong Expires April 27, 2006 [Page 15]