Network Working Group Thomas D. Nadeau Internet Draft Monique Morrow Expires: October 2003 George Swallow Cisco Systems, Inc. April 2003 Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV) draft-nadeau-pwe3-vccv-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [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. Abstract This document describes the Virtual Circuit Connection Verification Protocol (VCCV). VCCV supports connection verification applications for pseudowire VCs regardless of the underlying MPLS or IP tunnel technology. A network operator may use the VCCV protocol to test the network's forwarding plane liveliness. 1. Specification of Requirements 2 2. Acronyms 2 3. Introduction 2 4. Scope 4 5. L2TPv3/IP as PSN 4 6. MPLS as PSN 4 7. OAM Capability Negotiation 6 8. Security Considerations 7 9. Acknowledgments 7 10. References 8 11. Authors' Addresses 9 12. Intellectual Property Rights Notices 9 13. Full Copyright Statement 10 Nadeau et al. Expires October 2003 [Page 1] Internet Draft PWE3 VCCV April 1, 2003 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Acronyms CE Customer Edge CV Connection Verification FEC Forward Equivalency Class PE Provider Edge PSN Packet Service Network TLV Type Length Value VC Virtual Circuit VCCV Virtual Circuit Connection Verification 3. Introduction As network operators deploy pseudowire services, fault detection and diagnostic mechanisms particularly for the PSN portion of the network are pivotal. Specifically, the ability to provide end-to-end fault detection and diagnostics for an emulated pseudowire service is critical for the network operator. Operators have indicated in [MPLSOAMREQS] that such a tool is required for pseudowire deployments. This document describes a protocol for PSN-agnostic fault detection and diagnostics called virtual circuit connection verification (VCCV). |<------- pseudowire ------>| | |<-- PSN Tunnel -->| | PW V V V V PW End Service +----+ +----+ End Service +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|------------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|------------| | +-----+ | | |==================| | | +-----+ Customer | +----+ +----+ | Customer Edge 1 | Provider Edge 1 Provider Edge 2 | Edge 2 |<----------- Emulated Service ---------->| |<---------- VCCV ---------->| Figure 1: PWE3 VCCV Operation Reference Model Nadeau et al. Expires October 2003 [Page 2] Internet Draft PWE3 VCCV April 1, 2003 Figure 1 depicts the basic functionality of VCCV. The protocol runs between PEs that attaches the VC under test. The protocol encapsulates packets using the same encapsulation as is used for data. +-------------+ +-------------+ | Layer2 | | Layer2 | | Emulated | | Emulated | | Services | Emulated Service | Services | | |<==============================>| | +-------------+ VCCV/pseudowire +-------------+ |Demultiplexer|<==============================>|Demultiplexor| +-------------+ +-------------+ | PSN | PSN Tunnel | PSN | | MPLS |<==============================>| MPLS | +-------------+ +-------------+ | Physical | | Physical | +-----+-------+ +-----+-------+ | | | ____ ___ ____ | | _/ \___/ \ _/ \__ | | / \__/ \_ | | / \ | +========/ MPLS or IP Network |===+ \ / \ ___ ___ __ _/ \_/ \____/ \___/ \____/ Figure 2: PWE3 Protocol Stack Reference Model including VCCV. Figure 2 depicts how VCCV is run over the pseudowire to verify specific VCs. VCCV messages are encapsulated using the PWE3 encapsulation as described below in sections 5 and 6. These messages are exchanged only after the desire to exchange such traffic has been negotiated between the PEs (see section 8). The figure also illustrates how VCCV traffic should be routed and handled using the same data plane path as normal data traffic until it reaches the PE de-multiplextor point. When VCCV messages are intercepted at the de-multiplextor point, they are processed specially. Normal data traffic would be de-capsulated and forwarded to the emulated service at this point. This provides a true test of the data plane integrity of the pseudowire data traffic. Nadeau et al. Expires October 2003 [Page 3] Internet Draft PWE3 VCCV April 1, 2003 4. Scope VCCV is intended to provide connectivity verification of a psuedowire. As shown in figure 1, a pseudowire rides over a PSN and is used to provide an Emulated Serivce. Verification of the underlying PSN is specific to the PSN technology employed, and is therefore beyond the scope of this document. In all cases, connection verification of the Emulated Service between two CEs should be performed using the CV mechanism(s) provided by the emulated services running between the CEs. It may be necessary to inject indications of errors discovered by VCCV into the attachment circuits that are affected by those errors. In these cases an OAM message mapping mechanism is required. OAM mapping is beyond the scope of this document; it is discussed in [OAMMsgMap]. 5. L2TPv3/IP as PSN When IP is used as the underlying PSN, T.B.D. is used to perform connectivity verification and tracing functions between PEs. 6. MPLS as PSN In order to apply IP monitoring tools to PWE3 circuits, VCCV creates a control channel between PWE3 PEs[]. Packets sent across this channel are IP packets, allowing maximum flexibility. Ideally such a control channel would be completely in band. When a control word is present on virtual circuit, it is possible to indicate the control channel by setting a bit in the control header. This method is described in section 6.1 and is referred to as inband MPLS VCCV. However in order to address the case when the control header is not in use as well as to deal with a number of existent hardware devices, use of the MPLS Router Alert Label to indicate the IP control channel is also proposed. This is described in section 6.2. The actual channel type is agreed through signaling as described in section 8. 6.1. Inband MPLS VCCV The PWE control word [PWE-ENCAP] is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nadeau et al. Expires October 2003 [Page 4] Internet Draft PWE3 VCCV April 1, 2003 | Rsvd | Flags |Res| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ We propose that bit 7 of the control word (low order bit in the Flagsfield) of each PWE3 header type be allocated for the purpose of indicating control channel messages. 6.2. Router Alert Label Approach When the control word is not used, or the receiving hardware cannot divert control traffic, an IP control channel can be created by including the MPLS router alert label immediately above the VC label. If the control word is in use on this VC it is also included in the IP control flow. 0x1 OAM Flag in PWE header 0x2 Include the control channel label in stack above VC label 7. IP Probe Traffic For connectivity verification, both ICMP Ping and LSP-Ping packets may be used on the control channel. The type of packets used is agreed in signaling as described in section 8. 7.1. ICMP Ping When ICMP packets are used, the source address should be set to the source address of the LDP session and the destination address to the destination of the LDP session. The Identifier and Sequence Number fields of the ICMP Echo Request / Echo Reply messages are used to track what VCs are being tested. These fields are only interpreted by the sending PE. Specific use of these fields is an implementation matter. 7.2. MPLS Ping Packet The LSP Ping header must be used as described [LSP-PING] and must also contain the sub-TLV of 8 for PW circuits. This sub- TLV must be sent containing the circuit to be verified as the "VC ID" field: 7.2.1 L2 Circuit ID TLV for MPLS LSP Ping The value field consists of a remote PE address (the address of the targeted LDP session), the source address of the PE that originated this request, a VC ID and an encapsulation type, as follows. Nadeau et al. Expires October 2003 [Page 5] Internet Draft PWE3 VCCV April 1, 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote PE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source PE Address| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |PWID Type |PWID Length | PWID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameters | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Two PWID types are defined: 1. A FEC 128 VCID as defined in [MARTINISIG]. 2. A FEC 129 Attachment Identifier, as defined [L2SIG]. The PWID length field contains the length of the PWID field in bytes. Zero to three bytes of padding will follow the PWID field, so that the parameters field starts on a 64-bit boundary. Parameters are: - Interface parameters, as defined in [MARTINISIG]. ***Note that we propose that this field be removed from the LSP Ping draft [LSPPING] and defined here instead. 8. LDP OAM Capability Negotiation To permit negotiation of the use and type of OAM for Connectivity Verification, a VCCV parameter is defined below. When a PE signals a PWE VC and desires OAM, it must indicate this during VC establishment. Specifically for LDP it MUST include the VCCV parameter in the VC setup message. The requesting PE indicates its desire for the remote PE to support OAM capability by including the VCCV parameter with appropriate options set to indicate which methods of OAM are desired. The remote PE indicates it will support returning the VCCV parameter. The requesting PE MAY indicate multiple IP control channel options. The remote PE MUST respond with a single IP control channel selected. If it does not wish to support OAM functions, it MUST zero all bits of the control channel type field. The absence of the VCCV FEC TLV also indicates that no OAM functions are supported or desired by the requesting PE. This last method MUST be supported by all Nadeau et al. Expires October 2003 [Page 6] Internet Draft PWE3 VCCV April 1, 2003 PEs in order to handle backward-compatibility with older PEs. The requesting PE MAY indicate multiple IP control channel probe packets. The remote PE MAY respond with any or all of IP control channel probe packets selected. 8.1. Optional VCCV Parameter [PWE3CONTROL] defines a VC FEC TLV for LDP. Parameters can be carried within that TLV to signal different capabilities for specific PWs. We propose an optional parameter to be used to indicate the desire to use a control channel for VCCV as follows. As the overall method of PWE3 signaling is downstream, unsolicited, this leaves the decision of the type of IP control channel completely to the receiving control entity. OAM capability MUST be signaled BEFORE a PE may send OAM messages. If a PE receives OAM messages prior to reception of a VCCV parameter, it MUST discard these messages. In this case, the LSR SHOULD increment an error counter and optionally issues a system and/or SNMP notification to indicate to the system administrator that a mis-configuration exists. When included, this optional parameter MUST be used to validate that the LSRs, and the ingress and egress ports at the edges of the circuit, have the necessary capabilities to support VCCV. The TLV field structure is defined in [PWE3CONTROL] as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Parameter ID | Length | Variable Length Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Variable Length Value | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The VCCV parameter ID is defined as follows: Parameter ID Length Description 0x06 4 VCCV The format of the VCCV parameter TLV is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x06 | 0x04 | CC Type | CV Types | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The CC type field defines the type of IP control channel. The defined values are: 0x1 OAM Flag set in PWE header 0x2 MPLS Router Alert Label The CV Types field defines the types of IP control packets Nadeau et al. Expires October 2003 [Page 7] Internet Draft PWE3 VCCV April 1, 2003 that may be sent on the control channel. The defined values are: 0x1 ICMP Ping 0x2 LSP Ping 9. Security Considerations TBD 10. Acknowledgments The authors would like to thank Hari Rakotoranto, Michel Khouderchah, Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark Townsley, Eric Rosen, Dan Tappan, Rahul Aggarwal, and Danny McPherson for their valuable comments and suggestions. 11. References [PWREQ] Xiao, X., McPherson, D., Pate, P., Gill, V., Kompella, K., Nadeau, T., White, C., "Requirements for Pseudo Wire Emulation 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. [MARTINISIG] "Transport of Layer 2 Frames Over MPLS", Martini et. al., draft-martini-l2circuit-trans-mpls-10.txt, August 2002 [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. Nadeau et al. Expires October 2003 [Page 8] Internet Draft PWE3 VCCV April 1, 2003 [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 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 , January 2003. [OAMMsgMap] Nadeau, T., et al, " Pseudo Wire (PW) OAM Message Mapping, Internet Draft < draft-nadeau-pwe3-OAMMap.txt>, December, 2002. [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. 12. Authors' Addresses Thomas D. Nadeau Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Email: tnadeau@cisco.com George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Email: swallow@cisco.com Monique Morrow Cisco Systems, Inc. Glatt-com Nadeau et al. Expires October 2003 [Page 9] Internet Draft PWE3 VCCV April 1, 2003 CH-8301 Glattzentrum Switzerland Email: mmorrow@cisco.com 13. 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 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. 14. Full Copyright Statement Copyright (C) The Internet Society (2001). 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 Nadeau et al. Expires October 2003 [Page 10] Internet Draft PWE3 VCCV April 1, 2003 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 October 2003 [Page 11]