Internet DRAFT - draft-hart-pwe3-segmented-pw-vccv

draft-hart-pwe3-segmented-pw-vccv



Network Working Group                                         Neil Hart 
Internet Draft                                        Mustapha Aissaoui 
Expires: May 2008                                         Matthew Bocci 
                                                        Tiberiu Grigoriu 
                                                             Michael Hua 
                                                          Alcatel-Lucent  
                                                          
                                    
                                                       November 18, 2007 
                                      
                 VCCV Extensions for Segmented Pseudo-Wire 


                 draft-hart-pwe3-segmented-pw-vccv-02.txt  


Status of this Memo 

    

   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware 
   have been or will be disclosed, and any of which he or she becomes 
   aware will be disclosed, in accordance with Section 6 of BCP 79. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet-Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/1id-abstracts.html 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 

   This Internet-Draft will expire on May 18, 2008. 

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-
   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. 
 
 
 
Hart et al.              Expires May 18, 2008                  [Page 1] 

Internet-Draft        Segmented Pseudo Wire VCCV          November 2007 
    

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. 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........................................9 
   6. IANA Considerations............................................9 
   7. Acknowledgments................................................9 
   8. References.....................................................9 
      8.1. Normative References......................................9 
      8.2. Informative References....................................9 
   Author's Addresses................................................9 
   Full Copyright Statement.........................................10 
   Intellectual Property 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 

 
 
Hart et al.              Expires May 18, 2008                  [Page 2] 

Internet-Draft        Segmented Pseudo Wire VCCV          November 2007 
    

   function as a single point-to-point PW. Each end of a MS-PW by 
   definition MUST terminate on a T-PE.  

   - 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 

 
 
Hart et al.              Expires May 18, 2008                  [Page 3] 

Internet-Draft        Segmented Pseudo Wire VCCV          November 2007 
    

   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 
   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 May 18, 2008                  [Page 4] 

Internet-Draft        Segmented Pseudo Wire VCCV          November 2007 
    

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 May 18, 2008                  [Page 5] 

Internet-Draft        Segmented Pseudo Wire VCCV          November 2007 
    

   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 May 18, 2008                  [Page 6] 

Internet-Draft        Segmented Pseudo Wire VCCV          November 2007 
    

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 May 18, 2008                  [Page 7] 

Internet-Draft        Segmented Pseudo Wire VCCV          November 2007 
    

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. If FEC Stack      
      Validation is enabled, the request may also include additional       
      subTLV such as LDP Prefix and/or RSVP LSP dependent on the type 
      of transport tunnel the segmented PW is riding on. 

   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. If FEC stack validation is requested the       
      S-PE validates the received FEC stack and builds the echo reply       
      with the downstream target FEC stack which includes FEC128 subTLV       
      and any addition target FEC stack subTLVs required for the next 
      hop FEC stack validation. 

   3. T-PE1 builds a second VCCV echo request based on the target FEC       
      stack 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, or 
      the target FEC stack if the FEC stack validation is required, 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) 
 
 
Hart et al.              Expires May 18, 2008                  [Page 8] 

Internet-Draft        Segmented Pseudo Wire VCCV          November 2007 
    

   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]. 

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)", draft-ietf-pwe3-vccv-15.txt, September 
         2007. 
   
  [PWE3-MS] Martini, L., et al., "Segmented Pseudo Wire", draft-ietf-
         pwe3-segmented-pw-05.txt, July 2007. 
    

  [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-lucent  
   600 March Rd  
   Kanata, ON, Canada. K2K 2E6  
   Email: neil.hart@alcatel-lucent.com  
    




 
 
Hart et al.              Expires May 18, 2008                  [Page 9] 

Internet-Draft        Segmented Pseudo Wire VCCV          November 2007 
    

   Tiberiu Grigoriu 
   Alcatel-lucent  
   600 March Rd  
   Kanata, ON, Canada. K2K 2E6  
   Email: tiberiu.grigoriu@alcatel-lucent.com  
    

   Mustapha Aissaoui  
   Alcatel-lucent  
   600 March Rd  
   Kanata, ON, Canada. K2K 2E6  
   Email: mustapha.aissaoui@alcatel-lucent.com  
    

   Matthew Bocci  
   Alcatel-lucent  
   Voyager Place, Shoppenhangers Rd  
   Maidenhead, Berks, UK SL6 2PJ  
   Email: matthew.bocci@alcatel-lucent.co.uk 
    

   Michael Hua  
   Alcatel-lucent  
   600 March Rd  
   Kanata, ON, Canada. K2K 2E6  
   Email: michael.hua@alcatel-lucent.com  
    

    
Full Copyright Statement 

   Copyright (C) The IETF Trust (2007). 

   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.  

   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, THE 
   IETF TRUST 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. 

 
 
Hart et al.              Expires May 18, 2008                 [Page 10] 

Internet-Draft        Segmented Pseudo Wire VCCV          November 2007 
    

    

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. 

       

Acknowledgment 

   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 

    













 
 
Hart et al.              Expires May 18, 2008                 [Page 11]