One document matched: draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01.xml


<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc3978.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4379 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4379.xml">
<!ENTITY RFC4385 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4385.xml">
<!ENTITY RFC5884 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5884.xml">
<!ENTITY RFC5885 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5885.xml">
<!ENTITY RFC5586 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5586.xml">
<!ENTITY RFC5860 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5860.xml">
<!ENTITY ACH-TLV SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-tp-ach-tlv.xml">
<!ENTITY BFD-MPLS-P2MP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.katz-ward-bfd-multipoint.xml">
<!ENTITY MPLS-TP-IDENTIFIERS SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-tp-identifiers.xml">
<!ENTITY MPLS-TP-ROSETTA SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-tp-rosetta-stone.xml">
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" docName="draft-ietf-mpls-tp-lsp-ping-bfd-procedures-01"
     ipr="trust200902">
  <front>
    <title>LSP-Ping and BFD encapsulation over ACH</title>

    <author fullname="Nitin Bahadur" initials="N.B." role="editor"
            surname="Bahadur">
      <organization>Juniper Networks, Inc.</organization>

      <address>
        <postal>
          <street>1194 N. Mathilda Avenue</street>

          <city>Sunnyvale</city>

          <region>CA</region>

          <code>94089</code>

          <country>US</country>
        </postal>

        <phone>+1 408 745 2000</phone>

        <email>nitinb@juniper.net</email>

        <uri>www.juniper.net</uri>
      </address>
    </author>

    <author fullname="Rahul Aggarwal" initials="R.A." role="editor"
            surname="Aggarwal">
      <organization>Juniper Networks, Inc.</organization>

      <address>
        <postal>
          <street>1194 N. Mathilda Avenue</street>

          <city>Sunnyvale</city>

          <region>CA</region>

          <code>94089</code>

          <country>US</country>
        </postal>

        <phone>+1 408 745 2000</phone>

        <email>rahul@juniper.net</email>

        <uri>www.juniper.net</uri>
      </address>
    </author>

    <author fullname="David Ward" initials="D.W" role="editor" surname="Ward">
      <organization>Juniper Networks, Inc.</organization>

      <address>
        <postal>
          <street>1194 N. Mathilda Avenue</street>

          <city>Sunnyvale</city>

          <region>CA</region>

          <code>94089</code>

          <country>US</country>
        </postal>

        <phone>+1 408 745 2000</phone>

        <facsimile></facsimile>

        <email>dward@juniper.net</email>

        <uri>www.juniper.net</uri>
      </address>
    </author>

    <author fullname="Thomas D. Nadeau" initials="T.N." surname="Nadeau">
      <organization>BT</organization>

      <address>
        <postal>
          <street>BT Centre</street>

          <street>81 Newgate Street</street>

          <city>London</city>

          <code>EC1A 7AJ</code>

          <country>United Kingdom</country>
        </postal>

        <email>tom.nadeau@bt.com</email>
      </address>
    </author>

    <author fullname="Nurit Sprecher" initials="N.S." surname="Sprecher">
      <organization>Nokia Siemens Networks</organization>

      <address>
        <postal>
          <street>3 Hanagar St. Neve Ne'eman B</street>

          <city>Hod Hasharon</city>

          <code>45241</code>

          <country>Israel</country>
        </postal>

        <phone>+972-9-775 1229</phone>

        <email>nurit.sprecher@nsn.com</email>
      </address>
    </author>

    <author fullname="Yaacov Weingarten" initials="Y.W." surname="Weingarten">
      <organization>Nokia Siemens Networks</organization>

      <address>
        <postal>
          <street>3 Hanagar St. Neve Ne'eman B</street>

          <city>Hod Hasharon</city>

          <code>45241</code>

          <country>Israel</country>
        </postal>

        <phone>+972-9-775 1827</phone>

        <email>yaacov.weingarten@nsn.com</email>
      </address>
    </author>

    <date day="22" month="August" year="2010" />

    <area>Routing</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>Internet-Draft</keyword>

    <keyword>MPLS-TP OAM</keyword>

    <keyword>lsp ping</keyword>

    <abstract>
      <t>LSP-Ping and BFD for MPLS are existing and widely deployment OAM
      mechanisms for MPLS LSPs. This document describes an ACH encapsulation
      for LSP-Ping, that would enable use of LSP-Ping for networks where IP
      addressing is not in use. This document also clarifies the use of BFD
      for MPLS LSPs using ACH encapsulation, when IP addressing may not be
      available and/or it may not be desirable to encapsulate BFD packets in
      IP.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>LSP-Ping <xref target="RFC4379"></xref> and BFD for MPLS <xref
      target="RFC5884"></xref> are OAM mechanisms for MPLS LSPs. This document
      describes an ACH encapsulation for LSP-Ping for networks that do not use
      IP addressing. When IP addressing is in use, the LSP-Ping procedures
      specified in <xref target="RFC4379"></xref> apply as is. This document
      also clarifies the use of BFD for MPLS LSPs using ACH encapsulation
      <xref target="RFC5586"></xref>, when IP addressing may not be available
      and/or it may not be desirable to encapsulate BFD packets in IP.</t>

      <section title="Conventions used in this document">
        <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"></xref>.</t>
      </section>

      <section title="LSP-Ping and BFD over ACH">
        <t>In certain MPLS-TP deployment scenarios IP addressing might not be
        available or it may be preferred to use non-IP encapsulation for
        LSP-Ping and BFD packets. The remainder of this document defines
        extensions to LSP-Ping and procedures for using BFD, for such
        scenarios.</t>

        <t><xref target="ach-header"></xref> and <xref
        target="pw-ach-header"></xref> describe a new ACH code-point for
        performing LSP-Ping over ACH. <xref
        target="bfd-mpls-tp"></xref> describes procedures for using BFD over
        ACH.</t>
      </section>
    </section>

    <section title="LSP-Ping extensions" toc="default">
      <section anchor="ach-header" title="LSP-Ping packet over ACH for LSPs"
               toc="default">
        <t><xref target="RFC5586"></xref> defines an ACH mechanism for MPLS
        LSPs. This document defines a new ACH channel type for LSP-Ping, when
        IP addressing is not in use, for LSP-Ping over associated
        bi-directional LSPs and co-routed bi-directional LSPs. ACH TLVs MAY be
        associated with this channel type.</t>

        <figure align="left" anchor="channel-type-fig"
                title="LSP-Ping ACH Channel Type">
          <artwork><![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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|   Reserved    |     LSP-Ping Channel Type     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>

        <t></t>

        <t>When ACH header is used, an LSP-Ping packet will look as
        follows:</t>

        <figure align="left" anchor="lsp-ping-payload-fig"
                title="LSP-Ping packet with ACH">
          <artwork><![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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         MPLS Label stack                      |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          GAL                                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|   Reserved    |     LSP-Ping Channel Type     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      ACH TLV Header                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          ACH TLVs                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      LSP-Ping payload                         |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
        </figure>

        <t>When using LSP-Ping over the ACH header, the LSP-Ping Reply mode
        <xref target="RFC4379"></xref> in the LSP-Ping echo request MUST be
        set to 4 (Reply via application level control channel).</t>
      </section>

      <section anchor="pw-ach-header" title="LSP-Ping packet over ACH for PWs"
               toc="default">
        <t><xref target="RFC4385"></xref> defines an PW-ACH mechanism for
        pseudowires. The ACH channel type for LSP-Ping defined in <xref
        target="ach-header"></xref> will be re-used for pseudowires so that IP
        addressing is not needed when using LSP-Ping OAM over pseudowires.</t>
      </section>

      <section anchor="src-addr-tlv" title="Source Address TLV">
        <t>When sending LSP-Ping packets using ACH, without IP encapsulation,
        there MAY be a need to identify the source address of the packet. This
        source address will be specified via the Source Address TLV, being
        defined in <xref target="I-D.ietf-mpls-tp-ach-tlv"></xref>. No more
        than 1 source address TLV MAY be present in a LSP-Ping packet. The
        source address MUST specify the address of the originator of the
        packet. If more than 1 such TLV is present in a LSP-Ping request
        packet, then an error code of 1 (Malformed echo request received), [
        Section 3.1 <xref target="RFC4379"></xref>], SHOULD be returned. If
        more than 1 source address TLV is present, then the packet SHOULD be
        dropped without further processing.</t>
      </section>

      <section title="MEP and MIP Identifier">
        <t>When sending LSP-Ping packets using ACH, there MAY be a need to
        identify the maintenance end point (MEP) and/or the maintenance
        intermediate point (MIP) being monitored <xref
        target="I-D.ietf-mpls-tp-rosetta-stone"></xref>. The MEP/MIP
        identifiers defined in <xref
        target="I-D.ietf-mpls-tp-identifiers"></xref> MAY be carried in the
        ACH TLVs <xref target="I-D.ietf-mpls-tp-ach-tlv"></xref> for
        identification.</t>
      </section>
    </section>

    <section anchor="bfd-mpls-tp" title="Running BFD over MPLS-TP LSPs">
      <t><xref target="RFC5884"></xref> describes how BFD can be used for
      Continuity Check of MPLS LSPs. The procedures described in <xref
      target="RFC5884"></xref> MUST be used when IP encapsulation is in use.
      This section clarifies the usage of BFD in the context of MPLS-TP LSPs
      when it is not desirable to use IP encapsulation. When using BFD over
      MPLS-TP LSPs, the BFD discriminator MUST either be signaled via LSP-Ping
      or be statically configured. The BFD packets MUST be sent over ACH when
      IP encapsulation is not used.</t>

      <t>This document defines a new ACH channel type for BFD over G-ACH, when
      IP addressing is not in use, for running BFD over associated
      bi-directional LSPs and co-routed bi-directional LSPs. ACH TLVs MAY be
      associated with this channel type.</t>

      <figure align="left" anchor="bfd-channel-type-fig"
              title="BFD over G-ACH Channel Type">
        <artwork><![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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|   Reserved    |  BFD over G-ACH Channel Type  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
      </figure>

      <t>BFD packets, for both directions, MUST be sent over the MPLS-TP LSP
      and IP forwarding SHOULD NOT be used for the reverse path. The format of
      a BFD packet when using it as an OAM tool for MPLS-TP LSPs SHOULD be as
      follows:</t>

      <figure align="left" anchor="bfd-payload-fig"
              title="BFD packet over MPLS-TP LSPs">
        <artwork><![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 2
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         MPLS Label stack                      |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          GAL                                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0 0 0 1|Version|   Reserved    |  BFD over G-ACH Channel Type  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      ACH TLV Header                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            ACH TLVs                           |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          BFD payload                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
      </figure>

      <t><xref target="RFC5885"></xref> specifies how BFD can be used over
      MPLS PWs. One MAY use BFD over G-ACH channel type to run BFD over PWs if
      ACH TLV support is needed.</t>

      <t>BFD supports continuous fault monitoring and thus meets the
      pro-active Continuity Check and verification requirement specified in
      <xref target="RFC5860"></xref>. BFD SHOULD be run pro-actively. This
      function SHOULD be performed between End Points (MEPs) of PWs, LSPs and
      Sections. For point to multipoint Continuity Check, there is work in
      progress on using BFD for P2MP MPLS LSPs ( <xref
      target="I-D.katz-ward-bfd-multipoint"></xref>) and this can be leveraged
      for MPLS-TP LSPs as well. Failure of a BFD session over a LSP can be
      used to trigger protection switching or other fault remedial
      procedures.</t>

      <t>When sending BFD packets using ACH, there MAY be a need to identify
      the maintenance end point (MEP) being monitored. The MEP identifier
      defined in <xref target="I-D.ietf-mpls-tp-identifiers"></xref> can be
      carried in the ACH TLVs <xref target="I-D.ietf-mpls-tp-ach-tlv"></xref>
      for identification.</t>
    </section>

    <section title="Security Considerations">
      <t>The draft does not introduce any new security considerations. Those
      discussed in <xref target="RFC4379"></xref> are also applicable to this
      document.</t>
    </section>

    <section title="IANA Considerations">
      <section title="New ACH Channel Types">
        <t>New Channels type are defined in <xref target="ach-header"></xref>
        and <xref target="bfd-mpls-tp"></xref>. IANA is requested to assign
        new values from the "PW Associated Channel Type" registry, as per IETF
        consensus policy.</t>

        <figure>
          <artwork><![CDATA[
    Value    Meaning
    -----    -------
     TBD     Associated Channel carries LSP-Ping packet
     TBD     Associated Channel carries BFD over G-ACH

]]></artwork>
        </figure>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      &RFC4379;

      &RFC4385;
    </references>

    <references title="Informative References">
      &RFC5860;

      &RFC5884;

      &RFC5885;

      &RFC5586;

      &ACH-TLV;

      &MPLS-TP-IDENTIFIERS;

      &MPLS-TP-ROSETTA;

      &BFD-MPLS-P2MP;
    </references>
  </back>
</rfc>

PAFTECH AB 2003-20262026-04-21 20:26:58