Extensions to RFC4379 in Support of Link Bundles
draft-nadeau-rfc4379-bis-link-bundle-00

Versions: 00                                                            
Network Working Group                                         Tom Nadeau
Internet Draft                                            George Swallow
Category: Standards Track                                     David Ward
Expiration Date: May 2007                                  Danny Prairie
                                                     Cisco Systems, Inc.

                                                            October 2006


            Extensions to RFC4379 in Support of Link Bundles

              draft-nadeau-rfc4379-bis-link-bundle-00.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


Abstract

   This document specifies extensions to MPLS LSP Ping's
   tracing function as specified in IETF RFC4379 to support
   link bundle constructs. In particular, we extend the
   Echo Request packet format to include a new Link Bundle TLV
   that can contain both the virtual link bundle interface
   ID, as well as a description of the ECMP algorithm used by
   said interface. The existing downstream mapping processing
   algorithm for midpoints is modified to specify that when link
   bundles are encountered, that the component links should be
   revealed as would non-component links in the existing
   algorithm.





Nadeau, et al.               Expires April 2007              [Page 1]


        Extensions to RFC4379 for link bundles       October 15, 2006



Contents

 1      Introduction  ..............................................   3
 1.1    Conventions  ...............................................   3
 1.2    Terminology  ...............................................   3
 2      Overview  ..................................................   3
 3      Connectivity Verification Bootstrapping  ...................   4
 3.1    Connectivity Verification Session Object  ..................   4
 6      Security Considerations  ...................................  11
 7      IANA Considerations  .......................................  11
 8      Acknowledgments  ...........................................  11
 9      References  ................................................  11
 9.1    Normative References  ......................................  11
 9.2    Informative References  ....................................  12
10      Authors' Addresses  ........................................  12



1. Introduction

   Link bundling is a technology that allows a device
   to group or "bundle" together multiple, dislike or like
   interfaces into a single link bundle interface. The
   constituent interfaces that are bundled together
   are referred to as component interfaces or links. The
   set of component links or interfaces all connect one
   router/switch to another. When associated under the
   umbrella of a single, virtual link bundle interface,
   they are still viewed in this way, but only as a single
   pipe to the adjacent neighbor, consisting of the combined
   bandwidth and other attributes of the component links. For
   example, a single set of transmit and receive counters reflect
   the aggregate behavior of the individual component links, and
   provide a single point of management for the operator.

   The algorithm used to share traffic across component links is
   often identical to the one used for spreading the load across
   adjacent IGP equal cost links, which is referred to as Equal Cost
   Multi-Path (ECMP).  The most common algorithms are:

        1) per-packet, which uses some form of round-robin
           scheduling to push each packet over a different
           component link or

        2) per-destination, which sends all packets destined to
           a particular IP destination over the same component
           link. There are of course, pros and cons to using either
           algorithm, but the most common used is per-destination.




Nadeau, et al.               Expires April 2007              [Page 2]


        Extensions to RFC4379 for link bundles       October 15, 2006



   The motivation behind link bundling is to improve routing
   scalability by reducing the amount of information that has to be
   processed and advertised by the routing protocols such as OSPF or
   IS-IS.  This reduction is accomplished by performing
   information aggregation/abstraction as described above.
   However, as well as the benefits to information aggregation,
   some negative side-effects result. Specifically, in cases where
   trouble-shooting or diagnosing failures related to malfunctioning
   link bundles, this information hiding compounds the time
   it takes a network manager to uncover the failure. For instance,
   if the failure has to do with one of the component links failing,
   depending on the hashing algorithm used to move traffic onto those
   component links, errors may appear random, or may be difficult
   to stimulate.

   This document specifies extensions to MPLS LSP Ping's
   tracing functions [RFC4379] to support link bundle constructs.
   To this end, we extend the Echo Request packet format to
   include a new options Link Bundle TLV (i.e.: U bit set to 1)
   will contain both the virtual link bundle interface ID, as
   well as a description of the ECMP algorithm used by link
   bundling interfaces on an MPLS Label Switching Router (LSR). The
   existing downstream mapping processing algorithm for midpoints
   is modified to specify that when link bundles are encountered,
   that the component links should be revealed as would non-component
   links in the existing algorithm.


1.1. Conventions

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


1.2. Terminology

   Definitions of key terms for MPLS OAM are found in [RFC4379] and
   [RFC4201]. The reader is assumed to be familiar with those
   definitions which are not repeated here.

   The following additional terms are useful to understand this
   document.

1.3 Acronyms

   The following list of acronyms is a repeat of common acronyms defined
   in many other documents, and is provided here for convenience.




Nadeau, et al.               Expires April 2007              [Page 3]


        Extensions to RFC4379 for link bundles       October 15, 2006



     CE: Customer Edge
     PE: Provider Edge
   ECMP: Equal Cost Multipath
    LDP: Label Distribution Protocol
    LSP: Label Switch Path
    LSR: Label Switch Router
    OAM: Operations and Management
   OA&M: Operations, Administration and Maintenance.
   RSVP: Resource reSerVation Protocol
     SP: Service Provider


2. Overview

   In section 3, we extend the Echo Request packet format to
   include a new (optional) Link Bundle TLV that will contain
   both the virtual link bundle interface ID, as well as a
   description of the ECMP algorithm used by said interface.
   The the existing downstream mapping processing algorithm for
   midpoints is modified to specify that when link bundles
   are encountered, that the component links should be
   revealed as would non-component links in the existing
   algorithm.  The error processing algorithm will also be
   modified to indicate that a component of a virtual
   link bundle interface has failed. The presence of the
   Link Bundle TLV will indicate that a link bundle
   virtual interface is associated with those component links,
   and that special processing and consideration at the
   head-end LSR of the LSP should be taken when processing this
   information.  The head-end LSR's processing algorithm is
   modified to understand the new aforementioned Link Bundle TLV,
   as well as to modify its processing algorithm for how it
   investigiates the LSP's tree when tracing either the entire tree
   using ECMP tree trace, or tracing a single path
   (also known as a path selector) of the LSP.  This is
   all detailed below.


4. Downstream Mapping Processing For Link Bundles

   Use the algorithm as stated in RFC4379 with the following
   modifications:

   [At the receiver of an Echo Request containing a Downstream Map TLV]

   1) When encoding the downstream map tlv, and encountering
      a link bundle virtual interface, recurse through
      to each one of its component link interfaces and
      include those (their IP address and IfNumber) in



Nadeau, et al.               Expires April 2007              [Page 4]


        Extensions to RFC4379 for link bundles       October 15, 2006



      the Downstream Map TLV. For each one included, also
      set the DS Flag to indicate that it is a component link
      interface.  The multipath type specified is used to fully
      resolve the outgoing path to a particular component link
      of the bundle. In other words, multipath type A is not
      used to perform resolution to a bundle, and then multipath
      type B used to further resolve to a component link.
      That is, run the ECMP algorithm twice, once using the
      virtual link bundle interface as the next-hop,
      and then again through that interface to the component link
      bundle interfaces. In most cases, the ECMP algorithm
      used for the link bundles will be identical to the one
      used to get from the link bundle interface to the
      component interfaces, and thus can simply be run twice
      by the control plane.

   2) Include one copy of the Downstream Map Link Bundle TLV
      for each link bundle virtual interface.  For each
      TLV, fill in the component links herein to "point"
      back at the link bundle component links specified
      in #1.

   [At the receiver of an Echo Reply containing a Downstream
    Map TLV]

   1) Ensure that for each Downstream Map TLV containing
      an interface with the DS Flag of "L" set, verify that
      a Downstream Map Link Bundle TLV exists that contains
      this interface, or return an error.  Older versions of
      code will ignore this flag.

   2) For each component interface present in the Downstream
      Mapping TLV, process as normal. This facilitates
      backwards compatibility with older code.

   3) For each Downstream Map Link Bundle TLV, iterate
      through the component interfaces specified therein,
      and ensure they match the ones specified in the
      Downstream Map TLV discussed in 1.


3.3.  Downstream Mapping When Supporting Link Bundles

   The description of interfaces in Section 3.3 "Downstream Mapping"
   of [RFC4379] must be changed to reflect each set of link bundle
   component interfaces belonging to a link bundle as follows. The
   entire section has been copied here and modified in place
   for completeness.




Nadeau, et al.               Expires April 2007              [Page 5]


        Extensions to RFC4379 for link bundles       October 15, 2006



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

   Address Type

      The Address Type indicates if the interface is numbered or
      unnumbered.  It also determines the length of the Downstream IP



Nadeau, et al.               Expires April 2007              [Page 6]


        Extensions to RFC4379 for link bundles       October 15, 2006



      Address and Downstream Interface fields.  The resulting total for
      the initial part of the TLV is listed in the table below as "K
      Octets".

      In the case where the interface is a virtual link bundle
      interface, the LSR MUST include its component interfaces
      addresses here and MUST NOT include the virtual link bundle.
      It must also indicate that it is a component link by
      setting the L bit in the DS Flags. Under this condition, the LSR
      MUST then include a corresponding Link Bundle TLV (see below) to
      indicate which component interfaces are associated with which
      component links returned in the DS Map TLV.


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


   DS Flags

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

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

      Three flags are defined currently, I, N and L. 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



Nadeau, et al.               Expires April 2007              [Page 7]


        Extensions to RFC4379 for link bundles       October 15, 2006



            requests that the router treat this as it would if the
            determination of an IP payload had failed.

         L  Link Bundle Component Interface

            When this flag is set, it indicates that the interface
            indicated in the Downstream Interface Address field
            is a member of a link bundle (i.e.: a component link
            bundle interface).

   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.

   Multipath Type



Nadeau, et al.               Expires April 2007              [Page 8]


        Extensions to RFC4379 for link bundles       October 15, 2006




      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.
      In the case where the L bit is set in the DS Flags, the multipath
      information MUST also be set to reflect the multipath address or
      label value encoding that link bundle interface will use
      to load share traffic onto this component interface. The
      parameters used to get traffic from the inbound interface to the
      link bundle virtual interface will be described in the Multipath
      Information for Link Bundles section below.

      See the next section below 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.




Nadeau, et al.               Expires April 2007              [Page 9]


        Extensions to RFC4379 for link bundles       October 15, 2006



      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 EXP bits are bits 20-22, and bit 23 is the S
      bit.  The replying router SHOULD fill in the EXP and S bits; the
      LSR receiving the echo reply MAY choose to ignore these bits.

   Protocol

      The Protocol is taken from the following table:

      Protocol #        Signaling Protocol
      ----------        ------------------
               0        Unknown
               1        Static
               2        BGP
               3        LDP
               4        RSVP-TE
               5        Link Bundle Component Interface

     In the case where a link bundle's component interface is
     specified (as indicated by DS Flag L), the value of 5
     (Link Bundle Component Interface MUST be used as the
     protocol identifier.


10.  Downstream Mapping Link Bundle TLV

   The Downstream Mapping Link Bundle object is a TLV that
   SHOULD NOT be included in an echo request message.
   This TLV is used to specify the link bundle virtual interface,
   as well as which link bundle virtual interface corresponds to
   which link bundle component interfaces that were specified in
   the Downstream Mapping TLV.  If the replying router is the
   destination of the FEC, then a Downstream Mapping Link Bundle
   TLV SHOULD NOT be included in the Echo Reply. Otherwise the replying
   router MUST include a Downstream Mapping Link Bundle object for
   each link bundle virtual interface over which this FEC could be
   forwarded. Furthermore, this TLV will be present once for
   every Downstream Mapping TLV present that contains a DS Flag set
   to L. For a more precise definition of the notion of "downstream",
   see section 3.3.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



Nadeau, et al.              Expires April 2007              [Page 10]


        Extensions to RFC4379 for link bundles       October 15, 2006



      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               MTU             | Address Type  |    DS Flags   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Downstream IP Address (4 or 16 octets)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Downstream Interface Address (4 or 16 octets)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Multipath Type|    Reserved   |        Multipath Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                     (Multipath Information)                   .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Component Interface Address     |    Protocol   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Component Interface's Downstream Map TLV index            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      .                                                               .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Component Interface Address     |    Protocol   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Component Interface's Downstream Map TLV index            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Maximum Transmission Unit (MTU)

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

   Address Type

      The Address Type indicates if the virtual 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

   DS Link Bundle Flags



Nadeau, et al.              Expires April 2007              [Page 11]


        Extensions to RFC4379 for link bundles       October 15, 2006




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

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

      All flags are reserved for future use and MUST be set to zero when
      sending and ignored on receipt.

   Downstream IP Address and Downstream Component Interface Address

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

      If the link bundle component 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. The interface index is set to the value
      assigned by the LSR.

      If the link bundle 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 interface
      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 Link Bundle 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.



Nadeau, et al.              Expires April 2007              [Page 12]


        Extensions to RFC4379 for link bundles       October 15, 2006




   Multipath Type

      This field specifies an additional multipath type
      if it differs from the one specified for the
      link bundle component interfaces specified in the
      Downstream Map TLV. Definition is the same as those
      from RFC4379.

   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 the next section below 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 EXP bits are bits 20-22, and bit 23 is the S
      bit.  The replying router SHOULD fill in the EXP and S bits; the
      LSR receiving the echo reply MAY choose to ignore these bits.

   Protocol

      The Protocol is taken from the following table:

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




Nadeau, et al.              Expires April 2007              [Page 13]


        Extensions to RFC4379 for link bundles       October 15, 2006



3.3.2.  Downstream Router and Interface

   Section 3 of RFC3479 contains a description of TLV types. The
   Downstream Mapping Link Bundle TLV will be assigned a Type value of
   11 as follows.

   A description of the Types and Values of the top-level TLVs for LSP
   ping are given below:

          Type #                  Value Field
          ------                  -----------
               1                  Target FEC Stack
               2                  Downstream Mapping
               3                  Pad
               4                  Not Assigned
               5                  Vendor Enterprise Number
               6                  Not Assigned
               7                  Interface and Label Stack
               8                  Not Assigned
               9                  Errored TLVs
              10                  Reply TOS Byte
              11                  Downstream Mapping Link Bundle



6. Security Considerations

   TBD


7. IANA Considerations

   This document makes the following code point assignments (pending
   IANA action):

       Registry             Code point    Purpose

       UDP Port                tba        MPLS Verification Request

       LSP Ping Message Type   5          MPLS Connectivity Verification
                                          Probe

       LSP Ping Object Type    13         Connectivity Verification
                                          Parameters


       LSP Ping FEC Stack      tba        Multicast LDP FEC
       Sub-object Type




Nadeau, et al.              Expires April 2007              [Page 14]


        Extensions to RFC4379 for link bundles       October 15, 2006





8. Acknowledgments

   The authors would like to thank Vanson Lim for his comments and
   suggestions.



9. References

9.1. Normative References

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

   [SELF-TST] Swallow, G. et al., "Label Switching Router Self-Test",
              <draft-ietf-mpls-lsr-self-test-07.txt>, June 2006.


   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [MCSTPING] "Detecting Data Plane Failures in Point-to-Multipoint
              MPLS Traffic Engineering - Extensions to LSP Ping",
              <draft-ietf-mpls-p2mp-lsp-ping-01.txt>, April 2006.



9.2. Informative References

   [MPLS-BFD] Aggarwal, R., et al., "



10. Authors' Addresses

      George Swallow
      Cisco Systems, Inc.
      1414 Massachusetts Ave
      Boxborough, MA 01719 USA
      Email:  swallow@cisco.com


      Tom Nadeau
      Cisco Systems, Inc.
      1414 Massachusetts Ave
      Boxborough, MA 01719 USA



Nadeau, et al.              Expires April 2007              [Page 15]


        Extensions to RFC4379 for link bundles       October 15, 2006



      Email:  tnadeau@cisco.com

      Dave Ward
      Cisco Systems
      170 W. Tasman Dr.
      San Jose, CA 95134 USA
      Phone: +1-408-526-4000

      Email: dward@cisco.com

      Danny Prairie
      Cisco Systems
      2000 Innovation Drive
      Kanata, Ontario K2K 3E8 CANADA
      Phone: +1.613.274.3544
      Email: dprairie@cisco.com



























Copyright Notice

   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.




Nadeau, et al.              Expires April 2007              [Page 16]


        Extensions to RFC4379 for link bundles       October 15, 2006




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
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   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.




















Nadeau, et al.              Expires April 2007              [Page 17]