PWE3 Working Group Jixiong Dong Internet Draft Yang Yang Huawei Expires: August 2006 February 24, 2006 Operation and Maintenance for Multi-segment Pseudo Wire draft-dong-pwe3-mspw-oam-02.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 August 24, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 August 24, 2006 [Page 1] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 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 1.1. Terminology.............................................3 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. Forwarding Defect Indication............................6 3.3. Remote Defect Indication................................8 3.4. Misbranching Detection..................................8 3.5. OAM Extension..........................................11 3.5.1. Inband VCCV Extension.............................11 3.5.2. Out-of-band VCCV Extension........................12 3.5.3. Expiry TTL VCCV Extension.........................12 4. OAM Capability Indication for Multi-segment PW using MPLS...13 4.1. Introduction...........................................13 5. MS-PW OAM procedures in IP PSN..............................14 5.1. L2TPv3 VCCV FDI AVP Message............................14 5.2. L2TPv3 VCCV Capability Indication AVP Message..........14 6. IANA Considerations.........................................15 6.1. VCCV Parameter ID......................................15 6.1.1. CV Types..........................................15 6.2. L2TPv3 Assignments.....................................15 6.2.1. CV Types..........................................15 7. Security Considerations.....................................15 8. Acknowledgments.............................................15 9. References..................................................15 9.1. Normative References...................................15 9.2. Informative References.................................16 10. Author's Addresses.........................................17 11. Intellectual Property Statement............................17 Disclaimer of Validity.........................................18 Copyright Statement............................................18 Acknowledgment.................................................18 1. Introduction One pseudo-wire may transit 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 Dong Expires August 24, 2006 [Page 2] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 in only one packet switched network (PSN) domain and only one PSN tunnel. These pseudo-wires are called single-segment pseudo-wires (SS-PW). 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 only one 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]. In this draft, we introduce some MS-PW OAM mechanisms in details, including FDI, RDI, SEG/E2E OAM, PW misbranching detection. These functions are all very useful and can't be supported in [VCCV]. So it's very necessary to develop the new MS-PW OAM draft. This draft extends the VCCV mechanism described in [VCCV] to implement MS-PW OAM functions. It also define fault notifications such as FDI(Forwarding Defect Indication) and AIS(Alarm Indication Signal). 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 August 24, 2006 [Page 3] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 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 August 24, 2006 [Page 4] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 +----+ +-----+ +-----+ +----+ +----+ | 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 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. Dong Expires August 24, 2006 [Page 5] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 SEG OAM mechanism is as same as the existing OAM mechanism defined in [VCCV], [OAMMAP], [CTRL]. 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. If it's SEG OAM packet, it should be processed by local node. Otherwise, it should be forwarded transparently. For support the quick OAM process, we should make this decision by recognizing the OAM packet header. 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. Forwarding Defect Indication 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; Dong Expires August 24, 2006 [Page 6] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 - 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. 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, as the following section. 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 FDI packet format Fault Type (16 bits): Indicates the detected fault type. The fault types and their encoding are for further study. Dong Expires August 24, 2006 [Page 7] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 Address Family (16 bits): Indicates the family of the latter address field. Currently there are two types of address family: IPv4 and IPv6. 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. The unit is millisecond. 3.3. Remote Defect Indication T-PE may use remote defect indication (RDI) to notify the peer T-PE that a defect has been detected. Loss of Signaling and AIS may result in transmission RDI. RDI could be sent in data plane or control plane. It's preferred to send RDI in data plane if the MS-PW is established in stitching mode. In dynamic mode, LDP and RSVP-TE signaling could be used to propagate RDI. After detecting loss of connectivity/misbranching or receiving FDI from S-PE or being notified a server layer failure, T-PE will transmit RDI to the peer T-PE. The fault type may be contained in the RDI messages. The packet format of RDI is same as that of the above FDI. 3.4. Misbranching Detection PW misbranching means one PW segments connects another PW segments incorrectly. In fact, before introducing multi-segment PW, PW misbranching has existed. But it's caused by the server layer(s), such as tunnel LSP, and it's server layer(s). MPLS misbranch detection mechanisms[xxx itu-t y.1711, 1713] can detect this fault. Dong Expires August 24, 2006 [Page 8] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 Because it is not caused by PW layer, we don't care it in PWE3 WG. However, after introducing the multi-segment PW, S-PE has the PW switching function, which can lead to incorrect switching. There are two cases of PW misbranching. For example, See figure 6(a), it's the correct connection case. there are two MS-PWs, MS-PW1 traverses T-PE1, S-PE1, T-PE2, MS-PW2 traverses T-PE3, S-PE2, T-PE4. Figure 6(b) illustrates one case of PW misbranching. One MS-PW1 segment connects to a MS-PW2 segment at S-PE1 incorrectly, and one MS-PW2 segment connects to a MS-PW1 segment at S-PE2 incorrectly. Figure 6(c) illustrates another case of PW misbranching. One MS-PW1 segment connects to MS-PW2 at S-PE1 incorrectly, at the same time one MS-PW2 segment connects to a MS-PW2 segment at S-PE2 correctly. T-PE1 S-PE1 T-PE2 o--------o---------o o--------o---------o T-PE3 S-PE2 T-PE4 a) correct connection T-PE1 S-PE1 T-PE2 o--------o o \ / \ / /\ / \ o--------o o T-PE3 S-PE2 T-PE4 b) incorrect connection T-PE1 S-PE1 T-PE2 Dong Expires August 24, 2006 [Page 9] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 o--------o o \ \ \ \ o--------o--------o T-PE3 S-PE2 T-PE4 c) incorrect connection Figure 6 PW misbranching To detect PW misbranching, we can use the following VCCV oam PDU packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Sourece T-PE id | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PWE3 FEC 128/129 | | ,, | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved | BIP-16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 OAM packet format for PW misbranching Source T-PE id (16 octets): Indicates the PW source T-PE address. PWE3 FEC 128/129 (N bits): The FEC 128/129 contents when setup the PW. When PW is setup by using FEC 128, the field fills FEC 128 content. When PW is setup by using FEC 129, the field fills FEC 129 content. Dong Expires August 24, 2006 [Page 10] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 reserved (16 bits): Filled by zero. BIP-16 (16 bits): It use the polynomial G(x) = x**16 + 1. The fields before BIP- 16 field is all computed. The ST-PE send it to the TT-PE. If TT-PE receives the message with undesired field value(s), it will declare misbranching fault with the corresponding field mismatching information. 3.5. 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.5.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 8 PW Associated Channel Header The meaning of the fields of above PW Associated Channel Header (Figure 5) are as follows: FmtID: refer to [CW]. T: Dong Expires August 24, 2006 [Page 11] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 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.5.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 9 OAM payload format The meaning and value of T and F fields are as same as that in inband VCCV. 3.5.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. Dong Expires August 24, 2006 [Page 12] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 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 MS-PW OAM capabilities A CV type of 0x10 is part of the MS-PW OAM capabilities. It indicates if the PE supports the new MS-PW OAM capabilities, including FDI,RDI,SEG,E2E,PW misbranching functions. 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. Dong Expires August 24, 2006 [Page 13] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 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. 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 MS-PW OAM capabilities 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. Dong Expires August 24, 2006 [Page 14] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 6. IANA Considerations 6.1. VCCV Parameter ID VCCV 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 MS-PW OAM capabilities 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: 6.2.1. CV Types 0x04 MS-PW OAM capabilities 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. Dong Expires August 24, 2006 [Page 15] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 [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. [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. Dong Expires August 24, 2006 [Page 16] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 10. Author's Addresses Jixiong Dong Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, P.R.China Phone: +86-755-28970230 Email: dongjixiong@huawei.com Yang Yang Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, P.R.China Phone: +86-755-28978567 Email: healthinghearts@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 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 Dong Expires August 24, 2006 [Page 17] Internet-Draft draft-dong-pwe3-mspw-oam-02.txt February 2006 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 (2006). 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 August 24, 2006 [Page 18]