Network Working Group Neil Hart Internet Draft Mustapha Aissaoui Expires: April 2007 Tiberiu Grigoriu Matthew Boccci Michael Hua Alcatel VCCV Extensions for Segmented Pseudo-Wire draft-hart-pwe3-segmented-pw-vccv-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. 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 22, 2007. Abstract This document describes extensions to Single Hop Virtual Circuit Connectivity Verification (SH-VCCV) procedures for segmented pseudo wires to test the end-to-end forwarding datapath and to provide a MS- Hart et al. Expires April 22, 2007 [Page 1] Internet-Draft Segmented Pseudo Wire VCCV October 2006 PW segment trace capability. This is accomplished by changing the adaptation function for the Single Hop VCCV parameter at the switching point between two distinct PW control planes. Table of Contents 1. Terminology....................................................2 2. Introduction...................................................3 3. Adaptation of the Single-Hop CW VCCV for end to end verification4 3.1. VCCV Capability Signaling for MS-PW.......................4 3.2. End-to-end VCCV...........................................5 3.3. Partial tracing from T-PE.................................5 3.4. Partial Tracing between S-PEs.............................6 3.5. Automated VCCV Trace from T-PE............................6 4. Control Plane Processing of an VCCV Echo Message in a MS-PW....6 4.1. Sending a VCCV Echo Request...............................7 4.2. Receiving an VCCV Echo Request............................7 4.3. Receiving an VCCV Echo Reply..............................7 4.4. VCCV Trace Operations.....................................8 5. Security Considerations........................................8 6. IANA Considerations............................................9 7. Acknowledgments................................................9 8. References.....................................................9 8.1. Normative References......................................9 8.2. Informative References....................................9 Author's Addresses................................................9 Intellectual Property Statement..................................10 Disclaimer of Validity...........................................10 Copyright Statement..............................................11 Acknowledgment...................................................11 1. Terminology - PW Terminating Provider Edge (T-PE). A PE where the customer- facing attachment circuits (ACs) are bound to a PW forwarder. A Terminating PE is present in the first and last segments of a MS-PW. This incorporates the functionality of a PE as defined in [RFC3985]. - Single-Segment Pseudo Wire (SS-PW). A PW setup directly between two T-PE devices. Each PW in one direction of a SS-PW traverses one PSN tunnel that connects the two T-PEs. - Multi-Segment Pseudo Wire (MS-PW). A static or dynamically configured set of two or more contiguous PW segments that behave and function as a single point-to-point PW. Each end of a MS-PW by definition MUST terminate on a T-PE. Hart et al. Expires April 22, 2007 [Page 2] Internet-Draft Segmented Pseudo Wire VCCV October 2006 - PW Segment. A part of a single-segment or multi-segment PW, which is set up between two PE devices, T-PEs and/or S-PEs. - PW Switching Provider Edge (S-PE). A PE capable of switching the control and data planes of the preceding and succeeding PW segments in a MS-PW. The S-PE terminates the PSN tunnels of the preceding and succeeding segments of the MS-PW. - PW switching point for a MS-PW. A PW Switching Point is never the S-PE and the T-PE for the same MS-PW. A PW switching point runs necessary protocols to setup and manage PW segments with other PW switching points and terminating PEs 2. Introduction Virtual Circuit Connectivity Verification (VCCV) allows network operators to test the forwarding datapath of pseudo wire (PW) services. As pseudo wires are extended to cover multiple segments, it is required to be able to continue operating VCCV end-to-end across a switching point and to provide the ability to trace the path of the multi-segment PW (MS-PW) over any number of segments.. Figure 1 illustrates a multi-segment pseudo wire providing connectivity from T-PE1 to T-PE2 through the switching point S-PE. By suitable implementation at the S-PEs and with no modification to the T-PE single-segment PW (SS-PW) implementation, VCCV can be simply extended to provide both end to end and segment connection verification. Native |<-----------Pseudo Wire----------->| Native Layer2 | | Layer2 Service | |<-PSN1-->| |<--PSN2->| | Service (AC) V V V V V V (AC) | +----+ +-----+ +----+ | +----+ | | |=========| |=========| | | +----+ | |----------|........PW1.........|...PW3........|----------| | | CE1| | | | | | | | | |CE2 | | |----------|........PW2.........|...PW4........|----------| | +----+ | |=========| |=========| | +----+ ^ +----+ +-----+ +----+ ^ | T-PE1 S-PE T-PE2 | | | |<------------------- Emulated Service -------->| Figure 1 MS-PW Service The method proposed in this document adapts the SS-PW Control Word method such that S-PE nodes decrement the TTL in the PW label and pass forward the VCCV packet to the next segment of the PW. Packets Hart et al. Expires April 22, 2007 [Page 3] Internet-Draft Segmented Pseudo Wire VCCV October 2006 for which the TTL expires have their payload examined and are identified as VCCV packets due to the presence of the CW. They are then diverted to the control plane for further processing. This method is a variant to the one described in [PWE3-MS] which is based on defining a new VCCV sub-TLV in the optional PW switching point TLV. The advantages of the proposed method are that it limits the processing of the VCCV packet payload only to the S-PE/T-PE node which is the target for the message. All other S-PE nodes in between are not required to inspect the VCCV CW and are only required to decrement the TTL of the PW label. Also, this method does not require upgrading the SS-PW CW method supported by T-PE nodes. Finally, it provides a model of operation consistent with the operation of MPLS LSP Ping and LSP Trace. 3. Adaptation of the Single-Hop CW VCCV for end to end verification 3.1. VCCV Capability Signaling for MS-PW In Figure 1 T-PE1 uses the VCCV parameter included in the interface parameter field of the PW ID FEC TLV or the sub-TLV interface parameter of the Generalized PW ID FEC TLV to indicate to the far end T-PE2 what VCCV capabilities T-PE1 supports. This is the same VCCV parameter as would be used if T-PE1 and T-PE2 were connected directly by T-LDP. S-PE, which is a PW switching point, as part of the adaptation function for interface parameters, processes locally the VCCV parameter then passes it to T-PE2. If there were multiple S-PEs on the path between T-PE1 and T-PE2, each would carry out the same processing, passing along the VCCV parameter. The local processing of the VCCV parameter removes CC Types specified by the originating T-PE, except PWE3 Control Word that is passed unchanged. In other words, VCCV for MS-PW will not support other CC types, i.e., TTL=1 and Router Alert. For example, if T-PE1 indicates as supported CC Types both Control Word and Router Alert then the S- PE removes the Router Alert CC Type, leaving Control Word CC Type unchanged and then passes the modified VCCV parameter to the next S- PE along the path. The far end T-PE (T-PE2) receives the VCCV parameter indicating the Control Word CC Type only if that is supported by the initial T-PE (T-PE1) and all S-PEs along the PW path. In that case, T-PE2 knows that T-PE1 is capable of receiving the CW CC type and that each S-PE node in the path of the MS-PW is capable of relaying and generating/ terminating the VCCV messages. Hart et al. Expires April 22, 2007 [Page 4] Internet-Draft Segmented Pseudo Wire VCCV October 2006 3.2. End-to-end VCCV In Figure 1, if T-PE1, S-PE and T-PE2 support Control Word for VCCV, then as described in section 3.1. the control plane negotiates the common use of Control Word for VCCV end to end. Thus, the end-to-end connectivity of the multi-segment pseudowire can be verified as follows: a) T-PE forms an MPLS echo request message with the FEC matching that of the last segment PW to the destination T-PE. In Figure 1, this would be the FEC of segment PW3 for example. See Section 4. for details on how this FEC is obtained by T-PE1. b) T-PE sets inner PW label TTL to a large enough value to allow the packet to reach the far end T-PE c) T-PE sends a VCCV packet that will follow the exact same data path at each S-PE as that taken by data packets, d) S-PE performs an outer label pop, an inner label swap with TTL decrement, and new outer label push. e) there is no requirement for the S-PE to inspect the CW f) VCCV packet is diverted to VCCV control processing at the destination T-PE g) Destination T-PE replies using the specified reply mode, i.e., reverse PW path or IGP path 3.3. Partial tracing from T-PE In order to trace part of the multi-segment pseudowire, the TTL of the PW label may be used to force the VCCV message to 'pop out' at an intermediate node. When the TTL expires, the S-PE can determine that the packet is a VCCV packet by checking the control word. If the control word format matches that specified in [VCCV], the packet should be diverted to VCCV processing. In Figure 1, if T-PE1 sends a VCCV message with the TTL of the PW label equal to 1, the TTL will expire at the S-PE. T-PE1 can thus verify the first segment of the pseudo wire. Note that this use of the TTL is subject to the caution expressed in [VCCV]. If a penultimate LSR between S-PEs or between an S-PE and a Hart et al. Expires April 22, 2007 [Page 5] Internet-Draft Segmented Pseudo Wire VCCV October 2006 T-PE manipulates the PW label TTL, the VCCV message may not emerge from the MS-PW at the correct S-PE. 3.4. Partial Tracing between S-PEs Assuming that all nodes along an MS-PW support the Control Word CC Type, VCCV between S-PEs may be accomplished using the PW label TTL as in section 3.3. In Figure-1, the S-PE may verify the path between it and T-PE2 by sending a VCCV message with the PW label TTL set to 1. Given a more complex network with multiple S-PEs, an S-PE may verify the connectivity between it and an S-PE two segments away by sending a VCCV message with the PW label TTL set to 2. Thus, an S-PE can diagnose connectivity problems by successively increasing the TTL. 3.5. Automated VCCV Trace from T-PE Although tracing of the MS-PW path is possible using the methods explained in sections 3.3. and 3.4. , these require multiple manual iterations and that the FEC of the last PW segment to the target T- PE/S-PE be known a priori at the node originating the echo request message for each iteration. This mode of operation will be referred to as the "ping" mode. A full automated path tracing capability that iteratively probes the segments the MS-PW to learn the target FEC information is required. This will be referred to as the "trace" mode of operation. The details of this method are described in Section 4.4. 4. Control Plane Processing of an VCCV Echo Message in a MS-PW The challenge for the control plane is to be able to build the VCCV echo request packet with the necessary information such as the target FEC 128 PW sub-TLV (FEC128) of the downstream PW segment which the packet is destined for. This could be even more difficult in situations in which the MS-PW spans different providers and Autonomous Systems. For example, in Figure 1, T-PE1 has the required information to compose the FEC128 of the PW1 segment but it does not readily have the information required to compose the FEC128 of the PW3 segment if a VCCV echo request is supposed to be destined to T-PE2. This challenge can be overcome by the methods described in the following subsections 4.1. , 4.2. and 4.4. . Hart et al. Expires April 22, 2007 [Page 6] Internet-Draft Segmented Pseudo Wire VCCV October 2006 4.1. Sending a VCCV Echo Request When in the "ping" mode of operation, the sender of the echo request message requires the FEC of the last segment to the target S-PE/T-PE node. This information can either be configured manually or be obtained by inspecting the corresponding sub-TLV's of the PW switching point TLV. However, the PW switching point TLV is optional and there is no guarantee that all S-PE nodes will populate it with their system address and the PWid of the last PW segment traversed by the label mapping message. Thus a manual configuration is always preferred. When in the "trace" mode operation, the T-PE will automatically learn the target FEC by probing one by one the hops of the MS-PW path. Each S-PE node includes the FEC to the downstream node in the echo reply message in a similar way that LSP trace will have the probed node return the downstream interface and label stack in the echo reply message. The details of this method are described in the following sections. 4.2. Receiving an VCCV Echo Request Upon receiving a VCCV echo request the control plane on S-PEs (or the target node of each segment of the MS-PW) validates the request and responds to the request with an echo reply consisting of the FEC128 of the next downstream segment and a return code of 8 (label switched at stack-depth) indicating that it is an S-PE and not the egress router for the MS-PW. If the node is the T-PE or the egress node of the MS-PW, it responds to the echo request with an echo reply with a return code of 3 (egress router) and no FEC128 is included. 4.3. Receiving an VCCV Echo Reply The operation to be taken by the node that receives the echo reply in response to its echo request depends on its current mode of operation such as "ping" or "trace". In "ping" mode, the node may choose to ignore the target FEC128 in the echo reply and report only the return code to the operator. However, in "trace" mode, the node builds and sends the subsequent VCCV echo request with a incrementing TTL and the information (such as the downstream FEC128) it received in the echo request to the next downstream PW segment. Hart et al. Expires April 22, 2007 [Page 7] Internet-Draft Segmented Pseudo Wire VCCV October 2006 4.4. VCCV Trace Operations As an example, in Figure 1, VCCV trace can be performed on the MS-PW originating from T-PE1 by a single operational command. The following process ensues: 1. T-PE1 sends a VCCV echo request with TTL set to 1 and a FEC128 containing the pseudo-wire information of the first segment (PW1 between T-PE1 and S-PE) to S-PE for validation. 2. S-PE validates the echo request with the FEC128. Since it is a switching point between the first and second segment it builds an echo reply with a return code of 8 and includes the FEC128 of the second segment (PW3 between S-PE and T-PE2) and sends the echo reply back to T-PE1. 3. T-PE1 builds a second VCCV echo request based on the FEC128 in the echo reply from the S-PE. It increments the TTL and sends the next echo request out to T-PE2. Note that the VCCV echo request packet is switched at the S-PE datapath and forwarded to the next downstream segment without any involvement from the control plane. 4. T-PE2 receives and validates the echo request with the FEC128 of the PW3 from T-PE1. Since T-PE2 is the destination node or the egress node of the MS-PW it replies to T-PE1 with an echo reply with a return code of 3 (Egress Router) and no FEC128 is included. 5. T-PE1 receives the echo reply from T-PE2. T-PE1 is made aware that T-PE2 is the destination of the MS-PW because the echo reply does not contain the FEC128 and because its return code is 3. The trace process is completed. Note that the above example assumes only FEC128 sub-TLV is exchanged but it is possible that the exchanged information could also involve other TLV or Target FEC sub-TLVs (such as FEC129, LDP Prefix or RSVP LSP). For more detail on the format of the VCCV echo packet, refer to [VCCV] and [RFC4379]. The TTL here refers to that of the inner (VC) label TTL but it is also possible that the methods described in this section could use the MH-TTL as described in [PW3-MS]. 5. Security Considerations Same as security concerns described in [VCCV]. Hart et al. Expires April 22, 2007 [Page 8] Internet-Draft Segmented Pseudo Wire VCCV October 2006 6. IANA Considerations All the values of the CC, CV and channel types are as described in [VCCV]. 7. Acknowledgments The authors would like to thank Vach Kompella and Kendall Harvey for their valuable comments and suggestions. 8. References 8.1. Normative References [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection Verification (VCCV)", Internet Draft [PWE3-MS] Martini L., "Segmented Pseudo Wire", Internet Draft [RFC4379] Kompella, K., et al., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC4379, February 2006. 8.2. Informative References Author's Addresses Neil Hart Alcatel 600 March Rd Kanata, ON, Canada. K2K 2E6 Email: neil.hart@alcatel.com Tiberiu Grigoriu Alcatel 600 March Rd Kanata, ON, Canada. K2K 2E6 Email: tiberiu.grigoriu@alcatel.com Mustapha Aissaoui Alcatel 600 March Rd Kanata, ON, Canada. K2K 2E6 Email: mustapha.aissaoui@alcatel.com Hart et al. Expires April 22, 2007 [Page 9] Internet-Draft Segmented Pseudo Wire VCCV October 2006 Matthew Bocci Alcatel Voyager Place, Shoppenhangers Rd Maidenhead, Berks, UK SL6 2PJ Email: matthew.bocci@alcatel.co.uk Michael Hua Alcatel 600 March Rd Kanata, ON, Canada. K2K 2E6 Email: michael.hua@alcatel.com 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. 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 Hart et al. Expires April 22, 2007 [Page 10] Internet-Draft Segmented Pseudo Wire VCCV October 2006 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. Hart et al. Expires April 22, 2007 [Page 11]