Network Working Group Thomas D. Nadeau Internet Draft Cisco Systems, Inc. Expires: April 2004 =20 Rahul Aggarwal Juniper Networks Editors =20 October 2003 Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV) draft-ietf-pwe3-vccv-01.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. 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 Distribution of this document is unlimited. Please send comments to the Multiprotocol Label Switching (mpls) Working Group, mpls@uu.net. Abstract This document describes Virtual Circuit Connection Verification=20 (VCCV) procedures for use with pseudowire connections. VCCV=20 supports connection verification applications for pseudowire=20 VCs regardless of the underlying MPLS or IP tunnel technology. =20 VCCV makes use of IP based protocols such as Ping and MPLS LSP Ping to perform operations and maintenance functions. This=20 is accomplished by providing an IP control channel associated with each pseudowire. A network operator may use the VCCV=20 procedures to test the network's forwarding plane liveliness. Nadeau et al. Expires April 2004 [Page 1] =0C Internet Draft PWE3 VCCV October 25, 2003 Contents =20 Abstract...............................................................1 1. Contributors...........................................................1 2. Introduction...........................................................2 3. Overview of VCCV Modes of Operation....................................3 4. MPLS as PSN............................................................3 5. IP Probe Traffic.......................................................5 6. OAM Capability Indication..............................................6 7. L2TPv3/IP as PSN.......................................................8 8. Acknowledgments.......................................................11 9. References............................................................11 9.2 Normative References.................................................11 9.2 Informative References...............................................11 10. Security Considerations..............................................12 11. Intellectual Property Rights Notices.................................12=20 12. Full Copyright Statement.............................................13 1. Contributors Thomas D. Nadeau Rahul Aggarwal Cisco Systems, Inc. Juniper Networks 250 Apollo Drive 1194 North Mathilda Ave. Chelmsford, MA 01824 Sunnyvale, CA 94089 Email: tnadeau@cisco.com Email: rahul@juniper.net George Swallow Monique Morrow Cisco Systems, Inc. Cisco Systems, Inc. 250 Apollo Drive Glatt-com Chelmsford, MA 01824 CH-8301 Glattzentrum Email: swallow@cisco.com Switzerland Email: mmorrow@cisco.com =20 Yuichi Ikejiri Kenji Kumaki NTT Communications Corporation KDDI Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku KDDI Bldg. 2-3-2, Tokyo 100-8019 Nishishinjuku, Shinjuku-ku,=20 JAPAN Tokyo 163-8003, Email: y.ikejiri@ntt.com JAPAN E-mail : ke-kumaki@kddi.com=20 Peter B. Busschbach Lucent Technologies 67 Whippany Road Whippany, NJ, 07981 E-mail: busschbach@lucent.com 2. Introduction Nadeau et al. Expires April 2004 [Page 2] =0C Internet Draft PWE3 VCCV October 25, 2003 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 procedures 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|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| PE2| | = +-----+ | |----------|............PW1.............|------------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|------------| | +-----+ | | = |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| | | = +-----+ Customer | +----+ +----+ | Customer Edge 1 | Provider Edge 1 Provider Edge 2 | Edge 2 |<----------- Emulated Service ---------->| |<---------- VCCV ---------->| Figure 1: PWE3 VCCV Operation Reference Model Figure 1 depicts the basic functionality of VCCV. VCCV provides=20 several means of creating a control channel between PEs that=20 attaches the VC under test.=20 =20 +-------------+ +-------------+ | Layer2 | | Layer2 | | Emulated | | Emulated | | Services | Emulated Service | Services | | = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D>| | +-------------+ VCCV/pseudowire +-------------+ = |Demultiplexer|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|Demultiplexor| +-------------+ +-------------+ | PSN | PSN Tunnel | PSN | | MPLS = |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D>| MPLS | +-------------+ +-------------+ | Physical | | Physical | +-----+-------+ +-----+-------+ | | | ____ ___ ____ | Nadeau et al. Expires April 2004 [Page 3] =0C Internet Draft PWE3 VCCV October 25, 2003 | _/ \___/ \ _/ \__ | | / \__/ \_ | | / \ | +=3D=3D=3D=3D=3D=3D=3D=3D/ MPLS or IP Network = |=3D=3D=3D+ \ / \ ___ ___ __ _/ \_/ \____/ \___/ \____/ Figure 2: PWE3 Protocol Stack Reference Model=20 including the VCCV control channel. Figure 2 depicts how the VCCV IP control channel is associated=20 with the pseudowire. Ping and other IP messages are encapsulated=20 using the PWE3 encapsulation as described below in sections 5 and=20 6. These messages, referred to as VCCV messages, are exchanged=20 only after the desire to exchange such traffic has been=20 negotiated between the PEs (see section 8). 3. Overview of VCCV Modes of Operation VCCV defines a set of messages that are exchanged between PEs to=20 verify connectivity of the pseudowire. To make sure that pseudowire packets follow the same path as the data flow, they are encapsulated=20 with the same labels. Operators can use VCCV in two ways: 1) as a diagnostic tool 2) as a fault detection tool In the diagnostic mode, the operator triggers LSP-Ping, L2TPV3, or ICMP Ping modes depending on the underlying PSN. Since a=20 pseudowire is bi-directional, it makes sense to require that the=20 reply is send over the PSN tunnel that makes up the other half=20 of the PW under test. For example, if the PSN is an MPLS LSP, the reply should be sent on the LSP representing the reverse path. If this fails, the operator can use other reply modes to=20 determine what is wrong. The fault detection mode is provides a way to emulate fault=20 detection mechanisms in other technologies, such as ATM for=20 example. In the fault detection mode, the upstream PE sends=20 BFD control messages periodically. When the downstream PE=20 doesn't receive these message for a defined period of time, it=20 declares that direction of the PW down and it notifies the=20 upstream PE. Based on the emulated service, the PEs may send=20 FDI and RDI indications over the related attachment circuits to notify the end points of the fault condition. 3.1 LSP Ping Nadeau et al. Expires April 2004 [Page 4] =0C Internet Draft PWE3 VCCV October 25, 2003 When the PSN is MPLS, the LSP Ping header is used as described=20 in [LSP-PING] for verifying the connectivity status of pseudo wires.=20 3.2 L2TPV3 When L2TPv3 is used as the underlying PSN, a VCCV mechanism is needed for the L2TPv3 session. The L2TPv3 control connection does employ a keepalive mechanism; however, this mechanism isn't=20 sufficent for fault detection and diagnostic of the L2TPv3 session i.e. data plane. In L2TPv3, a session is analogous to a PW. A L2TPv3=20 VCCV mechanism is needed in particular for verifying the session=20 forwarding state at the egress router.=20 3.3 ICMP Ping When IP is used as the PSN, ICMP ECHO packets can be used=20 as the means by which connectivity verificaiton is achived using VCCV.=20 3.4 Bidirectional Forwarding Detection When heart-beat indication is necessary for one or more pseudowires, the Bidirectional Forwarding Detection (BFD) [BFD] provides a light-weight means of continuous monitoring and propagation of forward and reverse defect indications. BFD can be used regardless of the underlying PSN technology. 4. MPLS as PSN In order to apply IP monitoring tools to PWE3 circuits, VCCV creates a control channel between PWE3 PEs[PWEARCH]. Packets=20 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 7.1 and is referred to as PWE3 inband 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=20 the IP control channel is also proposed. This is described in section 7.2. The actual channel type is agreed through signaling as Nadeau et al. Expires April 2004 [Page 5] =0C Internet Draft PWE3 VCCV October 25, 2003 described in section 8. 4.1. PWE3 Inband VCCV The PW set-up protocol determines whether a PW uses a control word. When a control word is used, it SHOULD have the following preferred form: 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 0| Flags |FRG| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ for the purpose of indicating VCCV control channel messages.=20 Note that for data, one uses the control word defined just above the MPLS payload [PWEARCH]. The PWE3 payload type identifier 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved | PPP DLL Protocol Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As defined by PPP DLL protocol definition | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first nibble 0000 indicates data. When the first nibble is=20 0001, the protocol of the frame is indicated by the Protocol Number. IP OAM flows are identified by either an IPv4 or IPv6 codepoint.=20 4.2. Router Alert Label Approach When the control word is not used, or the receiving hardware cannot divert control traffic based on information in the control word (i.e.: older hardware), 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. 5. IP Probe Traffic For connectivity verification, both ICMP Ping and LSP-Ping packets may be used on the control channel. The type of Nadeau et al. Expires April 2004 [Page 6] =0C Internet Draft PWE3 VCCV October 25, 2003 packets used is indicated during signaling as described in=20 section 6. 5.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. 5.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: 5.3 Bidirectional Forwarding Detection When heart-beat indication is necessary for one or more pseudowires, the Bidirectional Forwarding Detection (BFD) [BFD] provides a light-weight means of continuous monitoring and propagation of forward and reverse defect indications. =20 In order to use BFD, both ends of the pseudowire connection must have signaled the existence of a control channel and the ability to run BFD. Once a node has both signaled and received signaling from its peer of these capabilities, it MUST begin sending BFD control packets. The packets MUST be sent on the control channel. The use of the control channel provides the context required to bind the=20 BFD session to a particular pseudowire (FEC). Thus normal BFD=20 initialization procedures are followed. BFD MUST be run in=20 asynchronous mode. When one of the PEs (PE2) doesn't receive control messages=20 from PE1 during the specified amount of time, or if it=20 determines in another way that communication is lost , it=20 declares that the PW in the direction from PE1 to PE2 is down.=20 It stores the cause (e.g. control detection time expired) and=20 sends a message to PE1 with H=3D0 (i.e. "I don't hear you"). In=20 turn, PE1 declares the PW in the direction from PE1 to PE2=20 down and stores as cause: neighbor signaled session down.=20 Depending on the emulated services, PE2 may send a FDI=20 indication on its attachment circuits and PE1 may send an RDI=20 Nadeau et al. Expires April 2004 [Page 7] =0C Internet Draft PWE3 VCCV October 25, 2003 indication on its attachment circuits. BFD defines the following diagnostics: 0 -- No Diagnostic 1 -- Control Detection Time Expired 2 -- Echo Function Failed 3 -- Neighbor Signaled Session Down 4 -- Forwarding Plane Reset (Local equipment failure) 5 -- Path Down (Alarm Suppression) 6 -- Concatenated Path Down (Propagating access link alarm) 7 -- Administratively Down Of these, 0 is used when the PW is up and 2 is not applicable=20 to asynchronous mode. =20 6. OAM Capability Indication To permit negotiation of the use and type of OAM for Connectivity Verification, a VCCV parameter is defined below. When a PE signals a PWE3 VC and desires OAM for that VC, it MUST indicate this during VC establishment using the messages defined below. Specifically for LDP it MUST include the VCCV=20 parameter in the VC setup message. As the overall method of PWE3 signaling is downstream, unsolicited, the decision of the type of IP control channel is left 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 sending a VCCV parameter, it MUST discard these messages and not reply to them. In this case, the LSR SHOULD increment an error counter=20 and optionally issues a system and/or SNMP notification to indicate=20 to the system administrator that a mis-configuration exists. 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 acceptable. The requesting PE MAY indicate multiple IP control IP control channel options. The absence of the VCCV FEC TLV=20 indicates that no OAM functions are supported or desired by the requesting PE. This last method MUST be supported by all PEs in order to handle backward-compatibility with older PEs. The receiving PE agrees to accept any of the indicated=20 OAM types and options by virtue of establishing the VC. If it does not or cannot support at least one of the options specified, it MUST not establish the VC. If the requesting PE wishes to continue, it may choose different options and try to signal the PE again. Nadeau et al. Expires April 2004 [Page 8] =0C Internet Draft PWE3 VCCV October 25, 2003 6.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. 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 in [PWE3IANA]: Parameter ID Length Description 0x0a 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0a | 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 that may be sent on the control channel. The defined values=20 are: 0x01 ICMP Ping 0x02 LSP Ping=20 0x03 BFD Nadeau et al. Expires April 2004 [Page 9] =0C Internet Draft PWE3 VCCV October 25, 2003 7. L2TPV3 as PSN When L2TPv3 is used as the underlying PSN, a VCCV mechanism is needed for the L2TPv3 session. The L2TPv3 control connection does employ a keepalive mechanism. However this mechanism is not sufficent for fault detection and diagnostic of the L2TPv3 session i.e. data plane. In L2TPv3 a session is analogous to a PW. A L2TPv3=20 VCCV mechanism is needed in particular for verifying the session=20 forwarding state at the egress router.=20 When a PE verifies the connection status of a L2TPv3 session it must transmit a L2TPv3 VCCV message encoded in the L2TPv3 session packet. The presence of a VCCV message in a L2TPv3 session packet can be indicated by reserving a bit in the default L2-specific sublayer=20 format.=20 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|S|V|x|x|x|x|x| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Default L2-Specific Sublayer Format with V bit. The 'V' bit indicates that this is a VCCV session packet. If the PW=20 has not been signaled to include a L2-specific sublayer format, other mechanisms are needed to indicate the VCCV message. Such mechanisms are for further study. 7.1. L2TPv3 VCCV Message The VCCV message MUST contain a VCCV AVP. It does not contain a message header. A new AVP, called the VCCV AVP is defined. The usage of the=20 L2TPv3 AVP format leaves room for adding further AVPs to this message in the future as needed.=20 7.1.1. L2TPv3 VCCV AVP This AVP encodes the LSP Ping header as defined in [LSP-PING]. M and H=20 bits must not be set. The attribute type is TBD. The LSP Ping header is=20 not encapsulated in UDP. The modifications to the semantics of the=20 fields of this header are specified here. Unless otherwise specified=20 the semantics of the fields as explained in [LSP-PING] are to be=20 followed. For reference the format of the LSP Ping header is shown=20 below. 0 1 2 3 Nadeau et al. Expires April 2004 [Page 10] =0C Internet Draft PWE3 VCCV October 25, 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version Number | Must Be Zero | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Reply mode | Return Code | Return Subcode| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Handle | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Sent (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Sent (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Received (seconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TimeStamp Received (microseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs ... | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The version number is currently 1. The message type is one of the=20 following: 1 - L2TPv3 VCCV Echo Request 2 - L2TPv3 VCCV Echo Reply The Reply Mode is: 1 - Do not reply 2 - Reply using the L2TPv3 session As explained in [LSP-PING] a reply mode of "do not reply" can be used for one way connectivity tests. The VCCV message will normally contain=20 a reply mode of "reply using the L2TPv3 session".=20 The return code can be set to the following by the receiver: 1 - Malformed echo request received 2 - One or more of the TLVs was not understood 3 - Replying router has a session mapping for the verified pseudo wire 4 - Replying router does not have a mapping for the verified pseudo=20 wire The LSP Ping header must contain the L2 Circuit ID TLV as defined in=20 Nadeau et al. Expires April 2004 [Page 11] =0C Internet Draft PWE3 VCCV October 25, 2003 section 8.2. This TLV identifies the pseudo wire associated with the session, that is being verified. For L2TPv3 the remote PE address is=20 the address of the session's remote end. A new PWID type is defined for L2TPv3, in addition to the ones defined in section 8.2: 3. L2TPv3 Remote End Identifier AVP 7.2. L2TPv3 VCCV Capability Negotiation A LCCE or a LAC should be able to indicate whether the session is capable of processing VCCV packets. This is done by including the optional VCCV capability AVP in an ICRQ, ICRP, OCRQ or OCRP. 7.2.1. L2TPv3 VCCV Capability AVP This AVP specifies the VCCV capability. Its attribute type is TBD. The value field has the following format: 0 1 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20 7.3. L2TPv3 VCCV Operation A PE sends VCCV echo requests on a L2TPv3 signaled pseudo wire for=20 fault detection and diagnostic of the L2TPv3 session. The destination IP address in the echo request is set to the remote PE's IP address,=20 while the source IP address is set to the local PE's IP address. The=20 egress of the L2TPv3 session verifies the signaling and forwarding state of the pseudo wire, on reception of the VCCV message. Any faults=20 detected can be signaled in the VCCV echo response. Its to be noted=20 that the VCCV mechanism for L2TPv3 is primarily targeted at verifying the pseudo wire forwarding and signaling state at the egress PE. It=20 also helps when L2TPv3 control and session paths are not identical.=20 A PE must send VCCV packets on a L2TPv3 session only if it has signaled VCCV capability to the remote end and received VCCV capability from the=20 remote end. If a PE receives VCCV packets and its not VCCV capable or it has not received VCCV capability indication from the remote end, it=20 must discard these messages. In addition if a PE receives VCCV messages and it has not received VCCV capability from the remote end, it should=20 increment an error counter. In this case the PE can optionally issue a system and/or SNMP notification. Nadeau et al. Expires April 2004 [Page 12] =0C Internet Draft PWE3 VCCV October 25, 2003 8. Acknowledgments The authors would like to thank Hari Rakotoranto, Michel Khouderchah, Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark Townsley, Eric Rosen, Dan Tappan, and Danny McPherson for their valuable comments and suggestions. 9. References 9.1 Normative References [BFD] Katz, D., Ward, D., Bidirectional Forwarding Indication, draft-katz-ward-bfd-00.txt, December 2003, work in progress. [PWREQ] Xiao, X., McPherson, D., Pate, P., Gill, V., Kompella, K., Nadeau, T., White, C., "Requirements=20 for Pseudo Wire Emulation Edge-to-Edge (PWE3)",=20 , 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.=20 [PWEARCH] Bryant, S., Pate, P., Johnson, T., Kompella, K., Malis, A., McPherson, D., Nadeau, T., So, T., Townsley,=20 W., Systems, White., C., Wood, L., Xiao, X., Internet=20 draft, Framework for Pseudo Wire Emulation Edge-to-Edge=20 (PWE3), draft-ietf-pwe3-framework-01.txt, work in=20 progress. [PWE3IANA] Martini, L., Townsley, M., "IANA Allocations for=20 pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-01.txt, June 2003, work in progress. [L2SIG] Rosen, E., LDP-based Signaling for L2VPNs, Internet Draft ,=20 September 2002. [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow, G., Wadhwa, S., Bonica, R., " Detecting=20 Data Plane Liveliness in MPLS", Internet Draft=20 , April 2003.=20 [MARTINISIG] "Transport of Layer 2 Frames Over MPLS", Martini et. al., draft-martini-l2circuit-trans-mpls-10.txt,=20 August 2002 Nadeau et al. Expires April 2004 [Page 13] =0C Internet Draft PWE3 VCCV October 25, 2003 [GTTP] Bonica, R., Kompella, K., Meyer, D., "Generic Tunnel Tracing Protocol (GTTP) Specification", Internet=20 Draft , April, 2003=20 [FRF 8.1] Frame Relay Forum, Frame Relay / ATM PVC Service Interworking Implementation Agreement, February 2000 [ITU-T] "Draft Recommendation Y.17fw" (MPLS Management Framework), July 2002. [ITU-T] "Frame Relay Bearer Service Interworking," I.555, September 2997. [ITU-T], "Frame Relay Operations Principles and Functions",=20 I.620, October, 1996. [ITU-T] Q.933, ISDN Digital Subscriber Signalling System No. 1 (DSS 1) - Signalling specification for frame=20 mode basic call control, November 1995. 9.2 Informative References [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=20 Networks", Internet Draft , October 2002 [MPLSOAMREQS] Nadeau, T., et al,"OAM Requirements for MPLS Networks, Internet Draft , June 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,=20 "A Framework for Provider Provisioned Virtual=20 Private Networks", Internet Draft , July 2001. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC=20 3031, January 2001. 10. Security Considerations TBD. Nadeau et al. Expires April 2004 [Page 14] =0C Internet Draft PWE3 VCCV October 25, 2003 11. 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=20 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=20 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=20 Executive Director. 11. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Nadeau et al. Expires April 2004 [Page 15] =0C Internet Draft PWE3 VCCV October 25, 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Nadeau et al. Expires April 2004 [Page 16]