One document matched: draft-jain-bess-p2mp-pw-lsp-ping-01.xml


<?xml version="1.0" encoding="US-ASCII"?>
<!-- $Id: draft-jain-pals-p2mp-pw-lsp-ping.xml 2014-07-03 paragj $ -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-jain-bess-p2mp-pw-lsp-ping-01"
     ipr="trust200902" updates="">
  <?rfc toc="yes" ?>

  <?rfc compact="yes"?>

  <?rfc subcompact="no"?>

  <?rfc symrefs="yes"?>

  <?rfc sortrefs="yes" ?>

  <front>
    <title abbrev="P2MP PW LSP Ping">Definition of P2MP PW TLV for LSP-Ping Mechanisms</title>

    <author fullname="Parag Jain" initials="P." surname="Jain">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>2000 Innovation Drive</street>

          <city>Kanata</city>

          <code>K2K-3E8</code>

          <region>ON</region>

          <country>Canada</country>
        </postal>

        <email>paragj@cisco.com</email>
      </address>
    </author>

    <author fullname="Sami Boutros" initials="S." surname="Boutros">
      <organization>Cisco Systems, Inc.</organization>

      <address>
        <postal>
          <street>3750 Cisco Way</street>

          <city>San Jose</city>

          <code>95134</code>

          <region>CA</region>

          <country>USA</country>
        </postal>

        <email>sboutros@cisco.com</email>
      </address>
    </author>

    <author fullname="Sam Aldrin" initials="S." surname="Aldrin">
      <organization>Goodle Inc.</organization>

      <address>
        <postal>
          <street></street>

          <city></city>

          <code></code>

          <region></region>

          <country>USA</country>
        </postal>

        <email>aldrin.ietf@gmail.com</email>
      </address>
    </author>

  
    <date year="2015"/>

    <area>Routing</area>

    <workgroup>BESS Workgroup</workgroup>

    <keyword>P2MP PW</keyword>

    <keyword>LSP Ping</keyword>

    <keyword>MPLS OAM</keyword>

    <abstract>
      <t>LSP-Ping is a widely deployed Operation, Administration, and 
        Maintenance (OAM) mechanism in MPLS networks. This document 
        describes a mechanism to verify connectivity of Point-to-Multipoint 
        (P2MP) Pseudowires (PW) using LSP Ping.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
     <t>A Point-to-Multipoint (P2MP) Pseudowire (PW) emulates the essential 
        attributes of a unidirectional P2MP Telecommunications service such 
        as P2MP ATM over PSN. Requirements for P2MP PW are described in 
        <xref target="RFC7338"/>. 
        P2MP PWs are carried over P2MP MPLS LSP. The Procedures for 
        P2MP PW signaling using BGP are described in <xref target="RFC7117"/> 
        and LDP for single segment P2MP PWs are described in 
        <xref target="I-D.ietf-pwe3-p2mp-pw"/>. 
        Many P2MP PWs can share the same P2MP MPLS 
        LSP and this arrangement is called Aggregate P-tree. The aggregate 
        P2MP trees require an upstream assigned label so that on the tail of 
        the P2MP LSP, the traffic can be associated with a VPN or a VPLS 
        instance. When a P2MP MPLS LSP carries only one VPN or VPLS service 
        instance, the arrangement is called Inclusive P-Tree. For Inclusive 
        P-Trees, P2MP MPLS LSP label itself can uniquely identify the VPN or 
        VPLS service being carried over P2MP MPLS LSP. The P2MP MPLS LSP can 
        also be used in Selective P-Tree arrangement for carrying multicast 
        traffic. In a Selective P-Tree arrangement, traffic to each 
        multicast group in a VPN or VPLS instance is carried by a separate 
        unique P-tree. In Aggregate Selective P-tree arrangement, traffic to 
        a set of multicast groups from different VPN or VPLS instances is 
        carried over a same shared P-tree.</t>

      <t>The P2MP MPLS LSP are setup either using P2MP RSVP-TE <xref target="RFC4875"/> 
        or Multipoint LDP (mDLP) <xref target="RFC6388"/>. 
        Mechanisms for fault detection and isolation for data 
        plane failures for P2MP MPLS LSPs are specified in [RFC6425]. This 
        document describes a mechanism to detect data plane failures for 
        P2MP PW carried over P2MP MPLS LSPs.</t>

      <t>This document defines a new P2MP Pseudowire sub-TLV for Target 
        FEC Stack for P2MP PW. The P2MP Pseudowire sub-TLV is added in 
        Target FEC Stack TLV by the originator of the Echo Request to inform 
        the receiver at P2MP MPLS LSP tail, of the P2MP PW being tested.</t> 

        <t>Multi-segment Pseudowires support is out of scope of this document 
        at present and may be included in future. </t>

    </section>

    <section title="Specification of Requirements">
      <t>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 <xref
      target="RFC2119"/>.</t>
    </section>

    <section title="Terminology">

   <t>ATM: Asynchronous Transfer Mode</t> 

   <t>LSR: Label Switching Router</t>  

   <t>MPLS-OAM: MPLS Operations, Administration and Maintenance</t> 

   <t>P2MP-PW: Point-to-Multipoint PseudoWire</t> 

   <t>PW: PseudoWire</t>  

   <t>TLV: Type Length Value</t>  
    
 </section>

    <section title="Identifying a P2MP PW">
      <t>This document introduces a new LSP Ping Target FEC Stack sub-TLV, 
        P2MP Pseudowire sub-TLV, to identify the P2MP PW under test at 
        the P2MP LSP Tail/Bud node.</t>


    <section title="P2MP Pseudowire Sub-TLV">
        <t>The P2MP Pseudowire sub-TLV has the format shown in Figure 1. 
        This TLV will be included in the echo request sent over P2MP PW by 
        the originator of request.</t>

        <t>The Attachment Group Identifier (AGI) in P2MP Pseudowire Sub-TLV 
        as described in  Section 3.4.2 in <xref target="RFC4446"/>, 
        identifies the VPLS instance. 
        The Originating Router's IP address is the IPv4 or IPv6 address of the
        P2MP PW root.</t>

   <figure align="left">
          <preamble/>

          <artwork align="left"><![CDATA[
                     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 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | AGI Type    |   AGI Length  |                                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                 |
     ~                          AGI Value                            ~
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | IP Addr Len |                                                 | 
     +-+-+-+-+-+-+-+                                                 |
     ~               Originating Routers IP Addr                     ~ 
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
                Figure 1: P2MP Pseudowire sub-TLV format 
]]></artwork>
        </figure>

        <t>For Inclusive and Selective P2MP MPLS P-trees, the echo request is
        sent using the P2MP MPLS LSP label. </t>

        <t>For Aggregate Inclusive and Aggregate Selective P-trees, the echo 
        request is sent using a label stack of [P2MP MPLS P-tree label, 
        upstream assigned P2MP PW label]. The P2MP MPLS P-tree label is the 
        outer label and upstream assigned P2MP PW label is inner label.</t>

    </section>
  </section>
<section title="Operations">

  <t>In this section, we explain the operation of the LSP Ping over P2MP 
       PW. Figure 2 shows a P2MP PW PW1 setup from T-PE1 to remote PEs (T-
       PE2, T-PE3 and T-PE4). The transport LSP associated with the P2MP PW1 
       can be MLDP P2MP MPLS LSP or P2MP TE tunnel.</t>  


    <figure align="left">
          <preamble/>

          <artwork align="left"><![CDATA[
       
        

                    |<--------------P2MP PW---------------->| 
             Native |                                       |  Native 
            Service |     |<--PSN1->|      |<--PSN2->|      |  Service 
             (AC)   V     V         V      V         V      V   (AC) 
               |    +-----+         +------+         +------+    | 
               |    |     |         |   P1 |=========|T-PE2 |AC3 |    +---+ 
               |    |     |         |   .......PW1.........>|-------->|CE3| 
               |    |T-PE1|=========|   .  |=========|      |    |    +---+ 
               |    |  .......PW1........  |         +------+    | 
               |    |  .  |=========|   .  |         +------+    | 
               |    |  .  |         |   .  |=========|T-PE3 |AC4 |    +---+ 
       +---+   |AC1 |  .  |         |   .......PW1.........>|-------->|CE4| 
       |CE1|------->|...  |         |      |=========|      |    |    +---+ 
       +---+   |    |  .  |         +------+         +------+    | 
               |    |  .  |         +------+         +------+    | 
               |    |  .  |=========|   P2 |=========|T-PE4 |AC5 |    +---+ 
               |    |  .......PW1..............PW1.........>|-------->|CE5| 
               |    |     |=========|      |=========|      |    |    +---+ 
               |    +-----+         +------+         +------+    | 
                                           
                                  Figure 2: P2MP PW 

 
            ]]></artwork>
        </figure>

   <t>When an operator wants to perform a connectivity check for the P2MP 
       PW1, the operator initiate a LSP-Ping request with the Target FEC 
       Stack TLV containing P2MP Pseudowire sub-TLV in the echo request 
       packet. The echo request packet is sent over the P2MP MPLS LSP using 
       the P2MP MPLS LSP label for Inclusive P-tree or with a label stack 
       with Upstream assigned P2MP PW label as inner label and P2MP MPLS 
       LSP label as the top label. The intermediate P router will do swap 
       and replication based on the MPLS LSP label. Once the packet reaches 
       remote terminating PEs, the T-PEs will process the packet and perform 
       checks for the P2MP Pseudowire sub-TLV present in the Target FEC 
       Stack TLV as described in Section 4.4 in <xref target="RFC4379"/> and respond 
       according to <xref target="RFC4379"/> processing rules.</t>  

  
    </section>

    <section title="Encapsulation of OAM Ping Packets">
      <t>The LSP Ping Echo request IPv4/UDP packets will be encapsulated with 
        the MPLS label stack as described in previous sections, followed by 
        the GAL Label <xref target="RFC6426"/>.
        The GAL label will be followed by the ACH with the Pseudowire Associated 
        Channel Type 16 bit value in the ACH set to IPv4 indicating that the 
        carried packet is an IPv4 packet.</t>

     </section>


     <section title="Controlling Echo Responses ">
      
        <t>The procedures described in <xref target="RFC6425"/> for preventing 
        congestion of Echo Responses (Echo Jitter TLV) and limiting the echo reply to a 
        single egress node (Node Address P2MP Responder Identifier TLV) can 
        be applied to P2MP PW LSP Ping.</t>  

     </section>

     <section title="Security Considerations">

     <t>The proposal introduced in this document does not introduce any new 
       security considerations beyond that already apply to [RFC6425].</t>

     </section>


    <section title="IANA Considerations">
      <t>This document defines a new sub-TLV type to be included in Target 
        FEC Stack TLV (TLV Type 1) [RFC4379] in LSP Ping.</t>

   <t>IANA is requested to assign a sub-TLV type value to the following 
        sub-TLV from the "Multiprotocol Label Switching (MPLS) Label 
        Switched Paths (LSPs) Parameters - TLVs" registry, "TLVs and sub-
        TLVs" sub-registry: </t>
   <t><list style="symbols">
          <t>P2MP Pseudowire sub-TLV</t>

        </list></t>
    
    </section>

     <section title="Acknowledgments">

        <t>The authors would like to thank Shaleen Saxena, Michael Wildt, 
        Tomofumi Hayashi, Danny Prairie for their valuable input and 
        comments.</t>
     </section>
  </middle>

  <back>
    <references title="Normative References">

      <?rfc include="reference.RFC.4379"?>
      <?rfc include="reference.RFC.7117"?>
      <?rfc include="reference.I-D.ietf-pwe3-p2mp-pw"?>
      <?rfc include="reference.RFC.6425"?>
      <?rfc include="reference.RFC.6426"?>
      <?rfc include="reference.RFC.4446"?>
  
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.5085"?>
      <?rfc include="reference.RFC.6388"?>
      <?rfc include="reference.RFC.4875"?>
      <?rfc include="reference.RFC.7338"?>


    </references>
  </back>
</rfc>

PAFTECH AB 2003-20262026-04-24 01:39:03