tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8029

 
 
 

Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures

Part 4 of 4, p. 61 to 78
Prev Section

 


prevText      Top      ToC       Page 61 
6.  IANA Considerations

6.1.  TCP and UDP Port Number

   The TCP and UDP port number 3503 has been allocated by IANA for LSP
   echo requests and replies.

6.2.  MPLS LSP Ping Parameters

   IANA maintains the "Multiprotocol Label Switching (MPLS) Label
   Switched Paths (LSPs) Ping Parameters" registry at
   [IANA-MPLS-LSP-PING].

   The following subsections detail the name spaces managed by IANA.
   For some of these name spaces, the space is divided into assignment
   ranges; the following terms are used in describing the procedures by
   which IANA allocates values: "Standards Action" (as defined in
   [RFC5226]), "Specification Required", and "Vendor Private Use".

   Values from "Specification Required" ranges MUST be registered with
   IANA.  The request MUST be made via an RFC that describes the format
   and procedures for using the code point; the actual assignment is
   made during the IANA actions for the RFC.

   Values from "Vendor Private" ranges MUST NOT be registered with IANA;
   however, the message MUST contain an enterprise code as registered
   with the IANA SMI Private Network Management Private Enterprise
   Numbers.  For each name space that has a Vendor Private range, it
   must be specified where exactly the SMI Private Enterprise Number
   resides; see below for examples.  In this way, several enterprises
   (vendors) can use the same code point without fear of collision.

6.2.1.  Message Types, Reply Modes, Return Codes

   IANA has created and will maintain registries for Message Types,
   Reply Modes, and Return Codes.  Each of these can take values in the
   range 0-255.  Assignments in the range 0-191 are via Standards
   Action; assignments in the range 192-251 are made via "Specification
   Required"; values in the range 252-255 are for Vendor Private Use and
   MUST NOT be allocated.

   If any of these fields fall in the Vendor Private range, a top-level
   Vendor Enterprise Number TLV MUST be present in the message.

Top      Up      ToC       Page 62 
   Message Types defined in this document are the following:

      Value    Meaning
      -----    -------
          1    MPLS Echo Request
          2    MPLS Echo Reply

   Reply Modes defined in this document are the following:

      Value    Meaning
      -----    -------
          1    Do not reply
          2    Reply via an IPv4/IPv6 UDP packet
          3    Reply via an IPv4/IPv6 UDP packet with Router Alert
          4    Reply via application-level control channel

   Return Codes defined in this document are listed in Section 3.1.

   IANA has updated the reference for each these values to this
   document.

6.2.2.  TLVs

   IANA has created and maintains a registry for the Type field of top-
   level TLVs as well as for any associated sub-TLVs.  Note that the
   meaning of a sub-TLV is scoped by the TLV.  The number spaces for the
   sub-TLVs of various TLVs are independent.

   The valid range for TLVs and sub-TLVs is 0-65535.  Assignments in the
   ranges 0-16383 and 32768-49161 are made via Standards Action as
   defined in [RFC5226]; assignments in the ranges 16384-31743 and
   49162-64511 are made via "Specification Required"; values in the
   ranges 31744-32767 and 64512-65535 are for Vendor Private Use and
   MUST NOT be allocated.

   If a TLV or sub-TLV has a Type that falls in the range for Vendor
   Private Use, the Length MUST be at least 4, and the first four octets
   MUST be that vendor's SMI Private Enterprise Number, in network octet
   order.  The rest of the Value field is private to the vendor.

Top      Up      ToC       Page 63 
   TLVs and sub-TLVs defined in this document are the following:

      Type     Sub-Type        Value Field
      ----     --------        -----------
         1                     Target FEC Stack
                      1        LDP IPv4 prefix
                      2        LDP IPv6 prefix
                      3        RSVP IPv4 LSP
                      4        RSVP IPv6 LSP
                      5        Unassigned
                      6        VPN IPv4 prefix
                      7        VPN IPv6 prefix
                      8        L2 VPN endpoint
                      9        "FEC 128" Pseudowire - IPv4 (Deprecated)
                     10        "FEC 128" Pseudowire - IPv4
                     11        "FEC 129" Pseudowire -  IPv4
                     12        BGP labeled IPv4 prefix
                     13        BGP labeled IPv6 prefix
                     14        Generic IPv4 prefix
                     15        Generic IPv6 prefix
                     16        Nil FEC
                     24        "FEC 128" Pseudowire - IPv6
                     25        "FEC 129" Pseudowire - IPv6
         2                     Downstream Mapping (Deprecated)
         3                     Pad
         4                     Unassigned
         5                     Vendor Enterprise Number
         6                     Unassigned
         7                     Interface and Label Stack
         8                     Unassigned
         9                     Errored TLVs
              Any value        The TLV not understood
        10                     Reply TOS Byte
        20                     Downstream Detailed Mapping

   IANA has updated the reference for each of these values to this
   document.

Top      Up      ToC       Page 64 
6.2.3.  Global Flags

   IANA has created a "Global Flags" subregistry of the "Multiprotocol
   Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
   registry.

   This registry tracks the assignment of 16 flags in the Global Flags
   field of the MPLS LSP ping echo request message.  The flags are
   numbered from 0 (most significant bit, transmitted first) to 15.

   New entries are assigned by Standards Action.

   Initial entries in the registry are as follows:

      Bit number  |  Name                      | Reference
      ------------+----------------------------+--------------
        15        |  V Flag                    | [RFC8029]
        14        |  T Flag                    | [RFC6425]
        13        |  R Flag                    | [RFC6426]
        12-0      |  Unassigned                | [RFC8029]

6.2.4.  Downstream Detailed Mapping Address Type

   This document extends RFC 4379 by defining a new address type for use
   with the Downstream Mapping and Downstream Detailed Mapping TLVs.
   IANA has established a registry to assign address types for use with
   the Downstream Mapping and Downstream Detailed Mapping TLVs, which
   initially allocates the following assignments:

      Type #     Address Type      K Octets    Reference
      ------     ------------      --------    ---------
           1     IPv4 Numbered           16    [RFC8029]
           2     IPv4 Unnumbered         16    [RFC8029]
           3     IPv6 Numbered           40    [RFC8029]
           4     IPv6 Unnumbered         28    [RFC8029]
           5     Non IP                  12    [RFC6426]

             Downstream Detailed Mapping Address Type Registry

   Because the field in this case is an 8-bit field, the allocation
   policy for this registry is "Standards Action".

Top      Up      ToC       Page 65 
6.2.5.  DS Flags

   This document defines the Downstream Mapping (DSMAP) TLV and the
   Downstream Detailed Mapping (DDMAP) TLV, which have Type 2 and Type
   20, respectively, assigned from the "TLVs" subregistry of the
   "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
   Ping Parameters" registry.

   DSMAP has been deprecated by DDMAP, but both TLVs share a field: DS
   Flags.

   IANA has created and now maintains a registry entitled "DS Flags".

   The registration policy for this registry is Standards Action
   [RFC5226].

   IANA has made the following assignments:

    Bit Number Name                                         Reference
    ---------- -------------------------------------------  ---------
          7    N: Treat as a Non-IP Packet                  [RFC8029]
          6    I: Interface and Label Stack Object Request  [RFC8029]
          5    E: ELI/EL push indicator                     [RFC8012]
          4    L: Label-based load balance indicator        [RFC8012]
        3-0    Unassigned

Top      Up      ToC       Page 66 
6.2.6.  Multipath Types

   IANA has created and now maintains a registry entitled "Multipath
   Types".

   The registration policy [RFC5226] for this registry is Standards
   Action.

   IANA has made the following assignments:

    Value      Meaning                                  Reference
    ---------- ---------------------------------------- ---------
          0    no multipath                             [RFC8029]
          1    Unassigned
          2    IP address                               [RFC8029]
          3    Unassigned
          4    IP address range                         [RFC8029]
        5-7    Unassigned
          8    Bit-masked IP address set                [RFC8029]
          9    Bit-masked label set                     [RFC8029]
         10    IP and label set                         [RFC8012]
     11-250    Unassigned
    251-254    Reserved for Experimental Use            [RFC8029]
        255    Reserved                                 [RFC8029]

6.2.7.  Pad Type

   IANA has created and now maintains a registry entitled "Pad Types".

   The registration policy [RFC5226] for this registry is Standards
   Action.

   IANA has made the following initial assignments:

   Registry Name: Pad Types

    Value      Meaning                                  Reference
    ---------- ---------------------------------------- ---------
          0    Reserved                                 [RFC8029]
          1    Drop Pad TLV from reply                  [RFC8029]
          2    Copy Pad TLV to reply                    [RFC8029]
      3-250    Unassigned
    251-254    Experimental Use                         [RFC8029]
        255    Reserved                                 [RFC8029]

Top      Up      ToC       Page 67 
6.2.8.  Interface and Label Stack Address Type

   IANA has created and now maintains a registry entitled "Interface and
   Label Stack Address Types".

   The registration policy [RFC5226] for this registry is Standards
   Action.

   IANA has made the following initial assignments:

   Registry Name: Interface and Label Stack Address Types

    Value      Meaning                                  Reference
    ---------- ---------------------------------------- ---------
          0    Reserved                                 [RFC8029]
          1    IPv4 Numbered                            [RFC8029]
          2    IPv4 Unnumbered                          [RFC8029]
          3    IPv6 Numbered                            [RFC8029]
          4    IPv6 Unnumbered                          [RFC8029]
      5-250    Unassigned
    251-254    Experimental Use                         [RFC8029]
        255    Reserved                                 [RFC8029]

6.3.  IPv4 Special-Purpose Address Registry

   IANA has updated the reference in Note 1 of the "IANA IPv4 Special-
   Purpose Address Registry" [IANA-SPECIAL-IPv4] to point to this
   document.

7.  References

7.1.  Normative References

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <http://www.rfc-editor.org/info/rfc1122>.

   [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
              RFC 1812, DOI 10.17487/RFC1812, June 1995,
              <http://www.rfc-editor.org/info/rfc1812>.

   [RFC2113]  Katz, D., "IP Router Alert Option", RFC 2113,
              DOI 10.17487/RFC2113, February 1997,
              <http://www.rfc-editor.org/info/rfc2113>.

Top      Up      ToC       Page 68 
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
              <http://www.rfc-editor.org/info/rfc3032>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <http://www.rfc-editor.org/info/rfc4271>.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              DOI 10.17487/RFC4379, February 2006,
              <http://www.rfc-editor.org/info/rfc4379>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <http://www.rfc-editor.org/info/rfc5905>.

   [RFC6424]  Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
              Performing Label Switched Path Ping (LSP Ping) over MPLS
              Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011,
              <http://www.rfc-editor.org/info/rfc6424>.

   [RFC7506]  Raza, K., Akiya, N., and C. Pignataro, "IPv6 Router Alert
              Option for MPLS Operations, Administration, and
              Maintenance (OAM)", RFC 7506, DOI 10.17487/RFC7506, April
              2015, <http://www.rfc-editor.org/info/rfc7506>.

7.2.  Informative References

   [Err108]   RFC Errata, Erratum ID 108, RFC 4379.

   [Err742]   RFC Errata, Erratum ID 742, RFC 4379.

   [Err1418]  RFC Errata, Erratum ID 1418, RFC 4379.

Top      Up      ToC       Page 69 
   [Err1714]  RFC Errata, Erratum ID 1714, RFC 4379.

   [Err1786]  RFC Errata, Erratum ID 1786, RFC 4379.

   [Err2978]  RFC Errata, Erratum ID 2978, RFC 4379.

   [Err3399]  RFC Errata, Erratum ID 3399, RFC 4379.

   [IANA-ENT] IANA, "PRIVATE ENTERPRISE NUMBERS",
              <http://www.iana.org/assignments/enterprise-numbers>.

   [IANA-MPLS-LSP-PING]
              IANA, "Multiprotocol Label Switching (MPLS) Label Switched
              Paths (LSPs) Ping Parameters",
              <http://www.iana.org/assignments/
              mpls-lsp-ping-parameters>.

   [IANA-SPECIAL-IPv4]
              IANA, "IANA IPv4 Special-Purpose Address Registry",
              <http://www.iana.org/assignments/
              iana-ipv4-special-registry>.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <http://www.rfc-editor.org/info/rfc792>.

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
              <http://www.rfc-editor.org/info/rfc3107>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <http://www.rfc-editor.org/info/rfc3209>.

   [RFC3443]  Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing
              in Multi-Protocol Label Switching (MPLS) Networks",
              RFC 3443, DOI 10.17487/RFC3443, January 2003,
              <http://www.rfc-editor.org/info/rfc3443>.

   [RFC4026]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", RFC 4026,
              DOI 10.17487/RFC4026, March 2005,
              <http://www.rfc-editor.org/info/rfc4026>.

Top      Up      ToC       Page 70 
   [RFC4365]  Rosen, E., "Applicability Statement for BGP/MPLS IP
              Virtual Private Networks (VPNs)", RFC 4365,
              DOI 10.17487/RFC4365, February 2006,
              <http://www.rfc-editor.org/info/rfc4365>.

   [RFC4461]  Yasukawa, S., Ed., "Signaling Requirements for Point-to-
              Multipoint Traffic-Engineered MPLS Label Switched Paths
              (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006,
              <http://www.rfc-editor.org/info/rfc4461>.

   [RFC4761]  Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
              LAN Service (VPLS) Using BGP for Auto-Discovery and
              Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
              <http://www.rfc-editor.org/info/rfc4761>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <http://www.rfc-editor.org/info/rfc5036>.

   [RFC5085]  Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
              Circuit Connectivity Verification (VCCV): A Control
              Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
              December 2007, <http://www.rfc-editor.org/info/rfc5085>.

   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
              Label Assignment and Context-Specific Label Space",
              RFC 5331, DOI 10.17487/RFC5331, August 2008,
              <http://www.rfc-editor.org/info/rfc5331>.

   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
              2009, <http://www.rfc-editor.org/info/rfc5462>.

   [RFC5885]  Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional
              Forwarding Detection (BFD) for the Pseudowire Virtual
              Circuit Connectivity Verification (VCCV)", RFC 5885,
              DOI 10.17487/RFC5885, June 2010,
              <http://www.rfc-editor.org/info/rfc5885>.

   [RFC6425]  Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
              Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
              Failures in Point-to-Multipoint MPLS - Extensions to LSP
              Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
              <http://www.rfc-editor.org/info/rfc6425>.

Top      Up      ToC       Page 71 
   [RFC6426]  Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
              On-Demand Connectivity Verification and Route Tracing",
              RFC 6426, DOI 10.17487/RFC6426, November 2011,
              <http://www.rfc-editor.org/info/rfc6426>.

   [RFC6829]  Chen, M., Pan, P., Pignataro, C., and R. Asati, "Label
              Switched Path (LSP) Ping for Pseudowire Forwarding
              Equivalence Classes (FECs) Advertised over IPv6",
              RFC 6829, DOI 10.17487/RFC6829, January 2013,
              <http://www.rfc-editor.org/info/rfc6829>.

   [RFC7537]  Decraene, B., Akiya, N., Pignataro, C., Andersson, L., and
              S. Aldrin, "IANA Registries for LSP Ping Code Points",
              RFC 7537, DOI 10.17487/RFC7537, May 2015,
              <http://www.rfc-editor.org/info/rfc7537>.

   [RFC8012]  Akiya, N., Swallow, G., Pignataro, C., Malis, A., and S.
              Aldrin, "Label Switched Path (LSP) and Pseudowire (PW)
              Ping/Trace over MPLS Networks Using Entropy Labels (ELs)",
              RFC 8012, DOI 10.17487/RFC8012, November 2016,
              <http://www.rfc-editor.org/info/rfc8012>.

   [RFC8077]  Martini, L., Ed., and G. Heron, Ed., "Pseudowire Setup and
              Maintenance Using the Label Distribution Protocol (LDP)",
              STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
              <http://www.rfc-editor.org/info/rfc8077>.

Top      Up      ToC       Page 72 
Appendix A.  Deprecated TLVs and Sub-TLVs (Non-normative)

   This appendix describes deprecated elements, which are non-normative
   for an implementation.  They are included in this document for
   historical and informational purposes.

A.1.  Target FEC Stack

A.1.1.  FEC 128 Pseudowire - IPv4 (Deprecated)

   FEC 128 (0x80) is defined in [RFC4447], as are the terms PW ID
   (Pseudowire ID) and PW Type (Pseudowire Type).  A PW ID is a non-zero
   32-bit connection ID.  The PW Type is a 15-bit number indicating the
   encapsulation type.  It is carried right justified in the field below
   termed encapsulation type with the high-order bit set to zero.  Both
   of these fields are treated in this protocol as opaque values.

   When a FEC 128 is encoded in a label stack, the following format is
   used.  The Value field consists of the Remote PE IPv4 Address (the
   destination address of the targeted LDP session), the PW ID, and the
   encapsulation type 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Remote PE IPv4 Address                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             PW ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            PW Type            |          Must Be Zero         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This FEC is deprecated and is retained only for backward
   compatibility.  Implementations of LSP ping SHOULD accept and process
   this TLV, but SHOULD send LSP ping echo requests with the new TLV
   (see Section 3.2.9), unless explicitly configured to use the old TLV.

   An LSR receiving this TLV SHOULD use the source IP address of the LSP
   echo request to infer the sender's PE address.

A.2.  Downstream Mapping (Deprecated)

   The Downstream Mapping object is a TLV that MAY be included in an
   echo request message.  Only one Downstream Mapping object may appear
   in an echo request.  The presence of a Downstream Mapping object is a
   request that Downstream Mapping objects be included in the echo
   reply.  If the replying router is the destination of the FEC, then a
   Downstream Mapping TLV SHOULD NOT be included in the echo reply.

Top      Up      ToC       Page 73 
   Otherwise, the replying router SHOULD include a Downstream Mapping
   object for each interface over which this FEC could be forwarded.
   For a more precise definition of the notion of "downstream", see
   Section 3.4.2, "Downstream Router and Interface".

   The Length is K + M + 4*N octets, where M is the Multipath Length,
   and N is the number of downstream labels.  Values for K are found in
   the description of Address Type below.  The Value field of a
   Downstream Mapping has the following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               MTU             | Address Type  |    DS Flags   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Downstream IP Address (4 or 16 octets)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Downstream Interface Address (4 or 16 octets)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Multipath Type| Depth Limit   |        Multipath Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                     (Multipath Information)                   .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Downstream Label                |    Protocol   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Downstream Label                |    Protocol   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Maximum Transmission Unit (MTU)

      The MTU is the size in octets of the largest MPLS frame (including
      label stack) that fits on the interface to the downstream LSR.

Top      Up      ToC       Page 74 
   Address Type

      The Address Type indicates if the interface is numbered or
      unnumbered.  It also determines the length of the Downstream IP
      Address and Downstream Interface fields.  The resulting total for
      the initial part of the TLV is listed in the table below as "K
      Octets".  The Address Type is set to one of the following values:

       Type #        Address Type           K Octets
       ------        ------------           --------
            1        IPv4 Numbered                16
            2        IPv4 Unnumbered              16
            3        IPv6 Numbered                40
            4        IPv6 Unnumbered              28
            5        Non IP                       12

   DS Flags

      The DS Flags field is a bit vector with the following format:

        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       | Rsvd(MBZ) |I|N|
       +-+-+-+-+-+-+-+-+

   Two flags are defined currently, I and N.  The remaining flags MUST
   be set to zero when sending and ignored on receipt.

   Flag  Name and Meaning
   ----  ----------------
      I  Interface and Label Stack Object Request

         When this flag is set, it indicates that the replying
         router SHOULD include an Interface and Label Stack
         Object in the echo reply message.

      N  Treat as a Non-IP Packet

         Echo request messages will be used to diagnose non-IP
         flows.  However, these messages are carried in IP
         packets.  For a router that alters its ECMP algorithm
         based on the FEC or deep packet examination, this flag
         requests that the router treat this as it would if the
         determination of an IP payload had failed.

Top      Up      ToC       Page 75 
   Downstream IP Address and Downstream Interface Address

      IPv4 addresses and interface indices are encoded in 4 octets; IPv6
      addresses are encoded in 16 octets.

      If the interface to the downstream LSR is numbered, then the
      Address Type MUST be set to IPv4 or IPv6, the Downstream IP
      Address MUST be set to either the downstream LSR's Router ID or
      the interface address of the downstream LSR, and the Downstream
      Interface Address MUST be set to the downstream LSR's interface
      address.

      If the interface to the downstream LSR is unnumbered, the Address
      Type MUST be IPv4 Unnumbered or IPv6 Unnumbered, the Downstream IP
      Address MUST be the downstream LSR's Router ID, and the Downstream
      Interface Address MUST be set to the index assigned by the
      upstream LSR to the interface.

      If an LSR does not know the IP address of its neighbor, then it
      MUST set the Address Type to either IPv4 Unnumbered or IPv6
      Unnumbered.  For IPv4, it must set the Downstream IP Address to
      127.0.0.1; for IPv6, the address is set to 0::1.  In both cases,
      the interface index MUST be set to 0.  If an LSR receives an Echo
      Request packet with either of these addresses in the Downstream IP
      Address field, this indicates that it MUST bypass interface
      verification but continue with label validation.

      If the originator of an echo request packet wishes to obtain
      Downstream Mapping information but does not know the expected
      label stack, then it SHOULD set the Address Type to either IPv4
      Unnumbered or IPv6 Unnumbered.  For IPv4, it MUST set the
      Downstream IP Address to 224.0.0.2; for IPv6, the address MUST be
      set to FF02::2.  In both cases, the interface index MUST be set to
      0.  If an LSR receives an echo request packet with the all-routers
      multicast address, then this indicates that it MUST bypass both
      interface and label stack validation, but return Downstream
      Mapping TLVs using the information provided.

Top      Up      ToC       Page 76 
   Multipath Type

      The following Multipath Types are defined:

      Key   Type                  Multipath Information
      ---   ----------------      ---------------------
       0    no multipath          Empty (Multipath Length = 0)
       2    IP address            IP addresses
       4    IP address range      low/high address pairs
       8    Bit-masked IP         IP address prefix and bit mask
              address set
       9    Bit-masked label set  Label prefix and bit mask

      Type 0 indicates that all packets will be forwarded out this one
      interface.

      Types 2, 4, 8, and 9 specify that the supplied Multipath
      Information will serve to exercise this path.

   Depth Limit

      The Depth Limit is applicable only to a label stack and is the
      maximum number of labels considered in the hash; this SHOULD be
      set to zero if unspecified or unlimited.

   Multipath Length

      The length in octets of the Multipath Information.

   Multipath Information

      Address or label values encoded according to the Multipath Type.
      See Section 3.4.1.1.1 for encoding details.

   Downstream Label(s)

      The set of labels in the label stack as it would have appeared if
      this router were forwarding the packet through this interface.
      Any Implicit Null labels are explicitly included.  Labels are
      treated as numbers, i.e., they are right justified in the field.

      A downstream label is 24 bits, in the same format as an MPLS label
      minus the TTL field, i.e., the MSBit of the label is bit 0, the
      LSBit is bit 19, the TC bits are bits 20-22, and bit 23 is the S
      bit.  The replying router SHOULD fill in the TC and S bits; the
      LSR receiving the echo reply MAY choose to ignore these bits.

Top      Up      ToC       Page 77 
   Protocol

      The protocol is taken from the following table:

      Protocol #        Signaling Protocol
      ----------        ------------------
               0        Unknown
               1        Static
               2        BGP
               3        LDP
               4        RSVP-TE

Acknowledgements

   The original acknowledgements from RFC 4379 state the following:

      This document is the outcome of many discussions among many
      people, including Manoj Leelanivas, Paul Traina, Yakov Rekhter,
      Der-Hwa Gan, Brook Bailey, Eric Rosen, Ina Minei, Shivani
      Aggarwal, and Vanson Lim.

      The description of the Multipath Information sub-field of the
      Downstream Mapping TLV was adapted from text suggested by Curtis
      Villamizar.

   We would like to thank Loa Andersson for motivating the advancement
   of this specification.

   We also would like to thank Alexander Vainshtein, Yimin Shen, Curtis
   Villamizar, David Allan, Vincent Roca, Mirja Kuhlewind, and Elwyn
   Davies for their review and useful comments.

Contributors

   A mechanism used to detect data-plane failures in MPLS LSPs was
   originally published as RFC 4379 in February 2006.  It was produced
   by the MPLS Working Group of the IETF and was jointly authored by
   Kireeti Kompella and George Swallow.

   The following made vital contributions to all aspects of the original
   RFC 4379, and much of the material came out of debate and discussion
   among this group.

      Ronald P. Bonica, Juniper Networks, Inc.
      Dave Cooper, Global Crossing
      Ping Pan, Hammerhead Systems
      Nischal Sheth, Juniper Networks, Inc.
      Sanjay Wadhwa, Juniper Networks, Inc.

Top      Up      ToC       Page 78 
Authors' Addresses

   Kireeti Kompella
   Juniper Networks, Inc.

   Email: kireeti.kompella@gmail.com


   George Swallow
   Cisco Systems, Inc.

   Email: swallow.ietf@gmail.com


   Carlos Pignataro (editor)
   Cisco Systems, Inc.

   Email: cpignata@cisco.com


   Nagendra Kumar
   Cisco Systems, Inc.

   Email: naikumar@cisco.com


   Sam Aldrin
   Google

   Email: aldrin.ietf@gmail.com


   Mach(Guoyi) Chen
   Huawei

   Email: mach.chen@huawei.com