PWE3 Working Group Jixiong Dong Internet Draft Huawei Technologies Co., Ltd. Expires: April 2006 October 10, 2005 Operation and Maintenance for Multi-segment Pseudo Wire draft-dong-pwe3-mspw-oam-00.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 10, 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 10, 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........................................4 3.1. Segment OAM and End-to-end OAM........................4 3.2. Fault Notification....................................5 3.3. OAM Extension.........................................7 3.3.1. Inband VCCV Extension............................7 3.3.2. Out-of-band VCCV Extension.......................8 3.3.3. Expiry TTL VCCV Extension........................8 4. OAM Capability Indication for Multi-segment PW using MPLS..9 4.1. Introduction..........................................9 5. MS-PW OAM procedures in IP PSN.............................10 5.1. L2TPv3 VCCV FDI AVP Message...........................10 5.2. L2TPv3 VCCV Capability Indication AVP Message.........10 6. Security Considerations....................................11 7. Acknowledgments............................................11 8. References.................................................11 8.1. Normative References..................................11 8.2. Informative References................................12 9. Author's Addresses.........................................12 10. Intellectual Property Statement...........................12 Disclaimer of Validity........................................13 Copyright Statement...........................................13 Acknowledgment................................................13 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). 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 Dong Expires April 10, 2006 [Page 2] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 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. 2. Reference Model for MS-PW OAM The figure below describes PW switching reference model [MSPWREQ]. 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 SS-PWs and can be regarded as one logical pseudo wire. Each of the single SS-PW can be regarded as one individual physical link. From layer network point of view, MS-PW is a client sublayer and SS-PW is the server sublayer. Thus, the reference model above can be illustrated by the following figure. Dong Expires April 10, 2006 [Page 3] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 +----+ +-----+ +-----+ +----+ +----+ | 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 PE and the egress PE of a logic MS-PW. Segment OAM (SEG OAM) flow is used for the OAM communications between the ingress PE and the egress PE of a physical per-segment SS-PW. Refer to the above reference model, we can deduce the following MS-PW OAM reference model. +----+ +-----+ +-----+ +----+ +----+ | PE1|======|S-PE1|=======|S-PE2|=======| PE2| +----+ | |-----|..................E2E OAM...................|-----| | | CE1| | | | | | | | | |CE2 | | |-----|----SEG OAM-------SEG OAM-------SEG OAM-----|-----| | +----+ | |======| |=======| |=======| | +----+ +----+ +-----+ +-----+ +----+ Figure 3 MS-PW OAM layer reference model 3. MS-PW OAM functions 3.1. Segment OAM and End-to-end OAM End-to-end OAM (E2E OAM) packets are generated at U-PE of a MS-PW, transferred transparently across all S-PEs, and terminated at the remote end U-PE of the MS-PW. Segment OAM (SEG OAM) packets are generated at U-PE of a SS-PW, terminated at the remote end U-PE of the SS-PW, where U-PE can be U-PE of the SS-PW, or S-PE of the MS-PW. 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. Dong Expires April 10, 2006 [Page 4] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 Of course, we maybe perform E2E OAM and SEG OAM mechanisms over a MS- PW and its segment PWs 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 SS-PW 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 U-PE of the MS-PW. When a U-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 U-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 Dong Expires April 10, 2006 [Page 5] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 the three consecutive transmission periods (e.g., three seconds), the MS-PW will exit FDI state. When the U-PE of a MS-PW received a FDI packet, it will send PW status TLV to the peer side U-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 U-PE of the SS-PW to notify the current SS-PW status. To notify 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 4 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. 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 Dong Expires April 10, 2006 [Page 6] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 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 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 5 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: Indicates the segment type of OAM packet. T = 0 indicates it is SEG OAM packet. T = 1 indicates it is E2E OAM packet. Dong Expires April 10, 2006 [Page 7] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 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 6 OAM payload format The meaning and value of T and F fields are as same as that in inband VCCV. 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. Dong Expires April 10, 2006 [Page 8] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 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 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. Dong Expires April 10, 2006 [Page 9] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 Note that FDI packet must be E2E OAM packet. After the negotiation process of OAM capability, U-PE may adopt SEG OAM, or E2E OAM, or both of them. When U-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 [CTRL]. 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]) Dong Expires April 10, 2006 [Page 10] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 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. Security Considerations This draft does not have any additional impact on security of PWs in [VCCV]. 7. Acknowledgments The authors would like to thank Spencer Dawkins, Yuli Shi for their valuable comments and suggestions. 8. References 8.1. Normative References [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-martini-pwe3-mh-pw- requirements-01.txt, February 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 10, 2006 [Page 11] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 [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. 8.2. Informative References [ARCH] Bryant, S., Pate, P., "PWE3 Architecture", RFC 3985,March 2005. [REQ] Xiao, X., McPherson, D., Pate, P., "Requirements for Pseudo Wire Emulation Edge to-Edge (PWE3)", RFC 3916, September 2004. 9. Author's Addresses Jixiong Dong Huawei Technologies Co., Ltd. Bantian industry base, Longgang district Shenzhen, China Email: dongjixiong@huawei.com 10. 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 Dong Expires April 10, 2006 [Page 12] Internet-Draft draft-dong-pwe3-mspw-oam-00.txt October 2005 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 10, 2006 [Page 13]