MPLS                                                  C. Villamizar, Ed.
Internet-Draft                                      Infinera Corporation
Intended status: Standards Track                            July 4, 2011
Expires: January 5, 2012


           Multipath Extensions for MPLS Traffic Engineering
             draft-villamizar-mpls-tp-multipath-te-extn-00

Abstract

   Extensions to OSPF-TE, ISIS-TE, and RSVP-TE are defined in support of
   carrying LSP with strict packet ordering requirements over multipath
   and and carrying LSP with strict packet ordering requirements within
   LSP without violating requirements to maintain packet ordering.  LSP
   with strict packet ordering requirements include MPLS-TP LSP.

   OSPF-TE and ISIS-TE extensions defined here indicate node and link
   capability reagrding support for ordered aggregates of traffic,
   multipath traffic distribution, and abilities to support multipath
   load distribution differently per LSP.

   RSVP-TE extensions either identifies an LSP as requiring strict
   packet order, or identifies an LSP as carrying one or more LSP that
   requires strict packet order at a given depth in the label stack, or
   identifies an LSP as having no restrictions on packet ordering except
   the restriction to avoid reordering microflows.  In addition an
   extension indicates whether the first nibble of payload will reliably
   indicate whether payload is IPv4, IPv6, or other type of payload,
   most notably pseudowire using a pseudowire control word.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 5, 2012.




Villamizar               Expires January 5, 2012                [Page 1]


Internet-Draft              MPLS TE Multipath                  July 2011


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





































Villamizar               Expires January 5, 2012                [Page 2]


Internet-Draft              MPLS TE Multipath                  July 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Architecture Summary . . . . . . . . . . . . . . . . . . .  4
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
     1.3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Protocol Extensions  . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Multipath Node Capability sub-TLV  . . . . . . . . . . . .  6
     2.2.  Multipath Link Capability sub-TLV  . . . . . . . . . . . .  9
     2.3.  Contained Ordered Aggregate Attributes TLV . . . . . . . .  9
     2.4.  LSP Multipath Attributes TLV . . . . . . . . . . . . . . . 11
   3.  Multipath Extension Protocol Mechanisms  . . . . . . . . . . . 12
     3.1.  OSPF-TE and ISIS-TE Advertisement  . . . . . . . . . . . . 12
       3.1.1.  Node Capability Advertisement  . . . . . . . . . . . . 12
       3.1.2.  Link Capability Advertisement  . . . . . . . . . . . . 13
       3.1.3.  Setting Max Depth and IP Depth . . . . . . . . . . . . 13
       3.1.4.  Hierarchical LSP Link Advertisement  . . . . . . . . . 13
     3.2.  RSVP-TE LSP Attributes . . . . . . . . . . . . . . . . . . 14
       3.2.1.  LSP Attributes for Ordered Aggregates  . . . . . . . . 14
       3.2.2.  LSP Attributes for Ordered Aggregates  . . . . . . . . 15
       3.2.3.  Attributes for LSP without Packet Ordering . . . . . . 15
     3.3.  Path Computation Constraints . . . . . . . . . . . . . . . 16
       3.3.1.  Link Multipath Capabilities and Path Computation . . . 16
         3.3.1.1.  Path Computation with Ordering Constraints . . . . 17
         3.3.1.2.  Path Computation with No Ordering Constraint . . . 17
         3.3.1.3.  Path Computation for MPLS containing MPLS-TP . . . 17
       3.3.2.  Link IP Capabilities and Path Computation  . . . . . . 18
         3.3.2.1.  LSP without Packet Ordering Requirements . . . . . 18
         3.3.2.2.  LSP with Ordering Requirements . . . . . . . . . . 19
         3.3.2.3.  LSP containing LSP with Ordering Requirements  . . 19
       3.3.3.  Link Depth Limitations and Path Computation  . . . . . 19
   4.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . . 20
     4.1.  Legacy Multipath Behavior  . . . . . . . . . . . . . . . . 20
     4.2.  Networks without Multipath Extensions  . . . . . . . . . . 21
       4.2.1.  Netowrks with MP Capability on all Multipath . . . . . 21
       4.2.2.  Netowrks with OA Capability on all Multipath . . . . . 22
       4.2.3.  Legacy Netowrks with Mixed MP and OA Links . . . . . . 22
     4.3.  Transition to Multipath Extension Support  . . . . . . . . 22
       4.3.1.  Simple Transitions . . . . . . . . . . . . . . . . . . 23
       4.3.2.  More Challenging Transitions . . . . . . . . . . . . . 23
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26





Villamizar               Expires January 5, 2012                [Page 3]


Internet-Draft              MPLS TE Multipath                  July 2011


1.  Introduction

   Today the requirement to handle large aggregations of traffic, can be
   handled by a number of techniques which we will collectively call
   multipath.  Multipath is very similar to composite link as defined in
   [ITU-T.G.800], except multipath specifically excludes inverse
   multiplexing.  Some types of LSP, including but potentially not
   limited to MPLS-TP LSP, require strict packet ordering.

   Requirements to carry MPLS-TP LSP over multipath and a framework
   giving a number of methods to do so are defined in
   [I-D.villamizar-mpls-tp-multipath].  This document defines protocol
   extensions which provide a means of supporting MPLS as a server layer
   for MPLS-TP, or to carry MPLS-TP directly over a network which makes
   use of multipath.

1.1.  Architecture Summary

   Advertisements in a link state routing protocol, such as OSPF or
   ISIS, support a topology map known as a link state database (LSDB).
   When traffic engineering information is included in the LSDB the
   topology map is known as a TE-LSDB or traffic engineering database
   (TED).

   A common MPLS LSP path computation is known as a constrained shortest
   path first computation (CSPF) (see [RFC3945]).  Other algorithms may
   be used for path computation.  Constraint-based routing was first
   introduced in [RFC2702]).

   OSPF-TE or ISIS-TE extensions are defined in Section 2.1 and
   Section 2.2.  OSPF-TE or ISIS-TE advertisements serve to populate the
   TE-LSDB and provide the basis for constraint-based routing path
   computation.  Section 3.1 describes the use of OSPF-TE or ISIS-TE
   multipath extensions in routing advertisements.

   RSVP-TE extensions are defined in Section 2.3 and Section 2.4.
   Section 3.2 describes the use of RSVP-TE extensions in setting up LSP
   including signaling constraints on LSP which contain other LSP which
   specify RSVP-TE extensions.

   Section 3.3 describes the constraints on LSP path computation imposed
   by the advertised ordered aggregate and multipath capabilities of
   links.  Section 3.3.2 describes the constraints on LSP path
   computation imposed by link advertisements regarding use of IP
   headers in multipath traffic distribution.  Section 3.3.3 describes
   the impact of label stack depth limitations.





Villamizar               Expires January 5, 2012                [Page 4]


Internet-Draft              MPLS TE Multipath                  July 2011


1.2.  Requirements Language

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

1.3.  Definitions

   Please refer to [I-D.villamizar-mpls-tp-multipath].

   Ordered Aggregate (OA)
      An ordered aggregate (OA) requires that packets be delivered in
      the order in which they were received.  Please refer to [RFC3260].

   Microflow
      A microflow is a single instance of an application-to- application
      flow.  Please refer to [RFC2475].  Reordering packets within a
      microflow can cause service disruption.  Please refer to
      [RFC2991].

   Multipath Traffic Distribution
      Multipath traffic distribution refers to the mechanism which
      distributes traffic among a set of component links or component
      lower layer paths which together comprise a multipath.  No
      assumptions are made about the algorithms used in multipath
      traffic distribution.  This document only discusses constraints of
      the type of information which can be used as the basis for
      multipath traffic distribution in specific circumstances.

   The phrase "strict packet ordering requirements" refers to the
   requirement to deliver all packet in the order that they were
   received.  The absense of strict packet ordering requirements does
   not imply total absense of packet ordering requirements.  The
   requirement to avoid reordering traffic within any given microflow,
   as described in [RFC2991] applies to all traffic aggregates including
   all MPLS LSP.


2.  Protocol Extensions

   This section defined protocol extensions to OSPR-TE, ISIS-TE, and
   RSVP-TE to address requirements described in
   [I-D.villamizar-mpls-tp-multipath].

   Two capability sub-TLV are added to two TLV that are used in both
   OSPF-TE and ISIS-TE.  The Multipath Node Capability sub-TLV is added
   to the Node Attribute TLV (Section 2.1) The Multipath Link Capability
   sub-TLV is added to the Link Identification TLV (Section 2.2).



Villamizar               Expires January 5, 2012                [Page 5]


Internet-Draft              MPLS TE Multipath                  July 2011


   Two TLV are added to the LSP_ATTRIBUTES object defined in [RFC5420].

2.1.  Multipath Node Capability sub-TLV

   The Node Attribute TLV is defined in [RFC5786].  A new sub-TLV, the
   Multipath Node Capability sub-TLV, is defined for inclusion in the
   Node Attribute TLV.

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type             |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Flags            |    Reserved   |  Min Depth    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Max Depth   |   IP Depth    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: Multipath Capability Sub-TLV

   The fields in the Multipath Capability sub-TLV are defined as
   follows.

   Type
      The Type field is asigned a value of IANA-TBD-1.  The Type field
      is a two octet value.

   Length
      The Length field indicates the length of the sub-TLV in octets,
      excluding the Type and Length fields.  The Length field is a two
      octet value.

   Flags
      The Flags field is a two octet (16 bit) value.  The following
      single bit fields are assinged within this value, starting at the
      most significant bit, which is the bit transmitted first.

      0x8000  Ordered Aggregate Enabled
         Setting the Ordered Aggregate Enabled bit indicates that an LSP
         can be carried as an Ordered Aggregate Enabled on one or more
         links.

      0x4000  Multipath Enabled
         Setting the Multipath Enabled bit indicates that an LSP can be
         spread across component links at one or more multipath links.






Villamizar               Expires January 5, 2012                [Page 6]


Internet-Draft              MPLS TE Multipath                  July 2011


      0x2000  IPv4 Enabled Multipath
         Setting the IPv4 Enabled Multipath bit indicates that the IPv4
         header information can be used in multipath load balance.  The
         Multipath Enabled bit must be set if the IPv4 Enabled Multipath
         bit is set.

      0x1000  IPv6 Enabled Multipath
         Setting the IP bit indicates that the IPv6 header information
         can be used in multipath load balance.  The Multipath Enabled
         bit must be set if the IPv6 Enabled Multipath bit is set.

      0x0800  UDPIPv4 Multipath
         Setting the UDPIPv4 Multipath bit indicates that the UDP port
         numbers carried in UDP over IPv4 can be used in multipath load
         balance.  The IPv4 Enabled Multipath bit must be set if UDPIPv4
         Multipath is set.  If the IPv4 Enabled Multipath bit is set and
         the UDPIPv4 Multipath bit is clear, then only source and
         destination IP addresses are used.

      0x0400  UDP/IPv6 Multipath
         Setting the UDP/IPv6 Multipath bit indicates that the UDP port
         numbers carried in UDP over IPv6 can be used in multipath load
         balance.  The IPv6 Enabled Multipath bit must be set if UDP/
         IPv6 Multipath is set.  The IPv4 Enabled Multipath bit must be
         set if UDPIPv4 Multipath is set.  If the IPv6 Enabled Multipath
         bit is set and the UDP/IPv6 Multipath bit is clear, then only
         source and destination IP addresses are used.

      0x0200  TDPIPv4 Multipath
         Setting the TDPIPv4 Multipath bit indicates that the TCP port
         numbers carried in TCP over IPv4 can be used in multipath load
         balance.  The IPv4 Enabled Multipath bit must be set if TDPIPv4
         Multipath is set.  If the IPv4 Enabled Multipath bit is set and
         the TDPIPv4 Multipath bit is clear, then only source and
         destination IP addresses are used.

      0x0100  TCP/IPv6 Multipath
         Setting the TCP/IPv6 Multipath bit indicates that the TCP port
         numbers carried in TCP over IPv6 can be used in multipath load
         balance.  The IPv6 Enabled Multipath bit must be set if TCP/
         IPv6 Multipath is set.  The IPv4 Enabled Multipath bit must be
         set if TDPIPv4 Multipath is set.  If the IPv6 Enabled Multipath
         bit is set and the TCP/IPv6 Multipath bit is clear, then only
         source and destination IP addresses are used.







Villamizar               Expires January 5, 2012                [Page 7]


Internet-Draft              MPLS TE Multipath                  July 2011


      0x0080  Default to Multipath
         Setting the Default to Multipath bit indicates that for an LSP
         which does not signal a desired behavior the traffic for that
         LSP will be spread across component links at one or more
         multipath links.  If the Default to Multipath bit is not set,
         then an LSP which does not signal otherwise will be treated as
         an ordered aggregate.

      0x0040  Default to IP/MPLS Multipath
         Setting the Default to IP/MPLS Multipath indicates that for an
         LSP which does not signal a desired behavior, the IP header
         information will be used in the multipath load distribution.
         If the Default to IP/MPLS Multipath is clear it indicates that
         the the IP header information will not be used by default.

      0x0020  Variable Depth Multipath
         Setting the Variable Depth Multipath bit indicates that when
         multipath is enabled for a given LSP, the stack depth beyond
         which multipath will not extract information for use in the
         multipath load distribution can be set on a per LSP basis.

      0x0010  IP Optioal Multipath
         Setting the IP Optioal Multipath bit indicates that when
         multipath is enabled for a given LSP, whether the IP header
         information is used in the multipath load distribution can be
         set on a per LSP basis.

      The remaining bits in the Flags field are reserved.

   Reserved
      The Reserved field MUST be set to zero and MUST be ignored unless
      implementing an extension.

   Min Depth
      The Min Depth field indicates the minimum stack depth which can be
      supported in the multipath traffic distribution.  For links which
      are not PSC LSP, the Min Depth field is set to zero.  For FA
      advertised for PSC LSP, this field will be set to one or more.
      See Section 3.1.4 for further details.

   Max Depth
      The Max Depth field is a one octet field indicating the maximum
      label stack depth beyond which the multipath load distribution
      cannot make use of further label stack entries.







Villamizar               Expires January 5, 2012                [Page 8]


Internet-Draft              MPLS TE Multipath                  July 2011


   IP Depth
      The IP Depth field is a one octet field indicating the maximum
      label stack depth beyond which the multipath load distribution
      cannot make use of IP information.

   The reserved bits in the Flags field and the Reserved fiedl MUST be
   set to zero and MUST be ignored unless implementing an extension
   which redifines one or more of the reserved bits.  Any further
   extension which redefines one or more reserved Flags bit should
   maintain backwards compatibility with prior implementations.

2.2.  Multipath Link Capability sub-TLV

   The Link Identificaion TLV is defined in [RFC3471].  The Link
   Identificaion TLV is updated in [RFC4201] to support a form of
   multipath known as Link Bundling.

   A new sub-TLV, the Multipath Link Capability sub-TLV, is defined
   here.  The Multipath Link Capability sub-TLV is optionally included
   in the Link Identification TLV.  The format of the Multipath Link
   Capability sub-TLV is identical to the Multipath Node Capability sub-
   TLV defined in Section 2.1, with one exception.  In the Multipath
   Link Capability sub-TLV the Type field value is IANA-TBD-2.

   If a Multipath Link Capability sub-TLV is advertised for any link,
   then a Multipath Node Capability sub-TLV MUST be advertised for the
   node.

2.3.  Contained Ordered Aggregate Attributes TLV

   The LSP_ATTRIBUTES object is defined in [RFC5420].  A new Contained
   Ordered Aggregate Attributes TLV is defined for the LSP_ATTRIBUTES
   object.  The TLV Type is IANA_TBD_3.  The format is described below.

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type             |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Flags     |    OA Depth   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 2: Contained Ordered Aggregate Attributes TLV

   The fields in the Contained Ordered Aggregate Attributes TLV are
   defined as follows.





Villamizar               Expires January 5, 2012                [Page 9]


Internet-Draft              MPLS TE Multipath                  July 2011


   Type
      The Type field is asigned a value of IANA-TBD-3.  The Type field
      is a two octet value.

   Length
      The Length field indicates the length of the sub-TLV in octets,
      excluding the Type and Length fields.  The Length field is a two
      octet value.

   Flags
      The Flags field is a three octet (24 bit) value.  The following
      single bit fields are assinged within this value, starting at the
      most significant bit, which is the bit transmitted first.

      0x80 IP Multipath Allowed
         Setting the IP Multipath Allowed bit indicates that it is safe
         to enable the use of a potential IP payload in the multipath
         traffic distribution.

      0x40 May Contain IPv4
         Setting the May Contain IPv4 bit indicates that IPv4 traffic
         may be contained within this LSP.

      0x40 May Contain IPv6
         Setting the May Contain IPv6 bit indicates that IPv6 traffic
         may be contained within this LSP.

      The remaining bits in the Flags field are reserved.

   OA Depth
      The OA Depth field is set as follows

      0  An OA Depth value of zero indicates that no ordered aggreagates
         are carried within the LSP.

      1  An OA Depth value of one indicates that the LSP is an ordered
         aggregate of traffic (the LSP requires strict ordering of
         packets).

      >1 An OA Depth value greater than one indicates that the LSP does
         not have strict packet ordering requirements but contains
         ordered aggregates at the label stack depth indicated.

   The reserved bits in the Flags field MUST be set to zero and MUST be
   ignored unless implementing an extension which redifines one or more
   of the reserved bits.  Any further extension which redefines one or
   more reserved Flags bit should maintain backwards compatibility with
   prior implementations.



Villamizar               Expires January 5, 2012               [Page 10]


Internet-Draft              MPLS TE Multipath                  July 2011


2.4.  LSP Multipath Attributes TLV

   The LSP_ATTRIBUTES object is defined in [RFC5420].  A new LSP
   Multipath Attributes TLV is defined for the LSP_ATTRIBUTES object.
   The TLV Type is IANA_TBD_4.  The format is described below.

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type             |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    MP Depth   |                    Reserved                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                  Largest Microflow Capacities                 |
    |                        (variable length)                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3: LSP Multipath Attributes TLV

   The fields in the LSP Multipath Attributes TLV are defined as
   follows.

   Type
      The Type field is asigned a value of IANA-TBD-4.  The Type field
      is a two octet value.

   Length
      The Length field indicates the length of the sub-TLV in octets,
      excluding the Type and Length fields.  The Length field is a two
      octet value.

   MP Depth
      The MP Depth field indicates the depth at which the Largest
      Microflow Capacities parameters are applicable.

   Largest Microflow Capacities
      The Largest Microflow Capacities field contains, one, two, or
      three IEEE 32 bit floating point values.  Each value is a capacity
      expressed in bytes per second.

      Largest LSE Microflow
         The first value, the Largest LSE Microflow, is the capacity of
         the largest microflow if only the label stack entries are used
         in multipath traffic distribution.  If a Largest LSE Microflow
         is not included, the LSP bandwidth request MUST be used.






Villamizar               Expires January 5, 2012               [Page 11]


Internet-Draft              MPLS TE Multipath                  July 2011


      Largest IP Microflow
         The second value, the Largest IP Microflow, if present, is the
         capacity of the largest microflow if the label stack entries
         and any potiential IP source and dsstination address are used
         in multipath traffic distribution.  If the Largest IP Microflow
         is not included, the value of the Largest LSE Microflow MUST be
         used.

      Largest L4 Microflow
         The third, the Largest L4 Microflow, if present, is the
         capacity of the largest microflow if the label stack entries
         and any potiential IP addresses and TCP or UDP port numbers are
         used in multipath traffic distribution.  If a Largest L4
         Microflow is not included, the value of the Largest IP
         Microflow MUST be used.

   The Reserved field MUST be set to zero and MUST be ignored unless
   implementing an extension which redifines all or part of this field.
   Any further extension which redefines all or part of this field
   should maintain backwards compatibility with prior implementations.

   If one or more LSP Multipath Attributes TLV is present, a Contained
   Ordered Aggregate Attributes TLV MUST be presnet.  There SHOULD be no
   more than one LSP Multipath Attributes TLV for any value of the MP
   Depth field in any given LSP_ATTRIBUTES object.  If additional LSP
   Multipath Attributes TLV are encountered they MUST be ignored.

   The value of the MP Depth field must be greater than zero and less
   than the value of the OA Depth field in the Contained Ordered
   Aggregate Attributes TLV, unless the OA Depth field is set to zero.


3.  Multipath Extension Protocol Mechanisms

3.1.  OSPF-TE and ISIS-TE Advertisement

   Every node MUST advertise exactly one Multipath Node Capability sub-
   TLV and may advertise zero of more Multipath Link Capability sub-TLV
   as needed.

3.1.1.  Node Capability Advertisement

   Every LSR which is adjacent to one or more multipath link MUST
   advertise a Multipath Node Capability sub-TLV (see Section 2.1).  The
   capabilities advertised for the node SHOULD reflect the capabilies of
   the majority of multipath links adjacent to the node.





Villamizar               Expires January 5, 2012               [Page 12]


Internet-Draft              MPLS TE Multipath                  July 2011


3.1.2.  Link Capability Advertisement

   For all of the links whose capability does not exactly match the
   Multipath Node Capability sub-TLV advertised by that same LSR, the
   LSR MUST advertise a Multipath Link Capability sub-TLV (see
   Section 2.2).

   For all of the links whose capability does exactly match the
   Multipath Node Capability sub-TLV advertised by that same LSR, the
   LSR SHOULD NOT advertise a Multipath Link Capability sub-TLV (see
   Section 2.2).  In this case the Multipath Link Capability sub-TLV is
   redundant, but harmless.

3.1.3.  Setting Max Depth and IP Depth

   The Max Depth and IP Depth field are intended to capture
   architectural limits.  Most forwarding hardware will only use a
   limited number of labels in the multipath traffic distribution.  This
   limit is reflected in the Max Depth field.  Most forwarding hardware
   will limit the number of labels that it will look past before looking
   for an IP header to be used in the multipath traffic distribution.
   This limit is reflected in the IP Depth field.

3.1.4.  Hierarchical LSP Link Advertisement

   A PSC LSP, as defined in [RFC4206] and updated in [RFC6107], may
   carry other LSP.  When signaling a PSC LSP that is expected to carry
   MPLS-TP LSP or other LSP with strict packet reordering requirements
   at some label depth, the minimum label stack depth at which an LSP
   with strict packet reordering requirements can be carried must be
   signaled.

   A tradeoff must be considered.  If allowed to look deep into the
   label stack, multipath traffic distribution is able to distribute
   traffic more evenly.  It is impractical to carry LSP very deep in the
   stack solely for this purpose.  When carrying LSP that has strict
   packet order requirements, the depth at which these LSP will be
   carried is a network design tradeoff.

   For example, if an MPLS-TP LSP is signaled as a PSC LSP, the the
   depth needs to be limited to one.  To directly carry an LSP that
   requires strict packet ordering, the depth needs to be limited to
   two, where the two label stack entries are for the MPLS LSP with no
   packet order requirements other than for microflows and the contained
   LSP with strict packet order requirements.

   When the Forwarding Adjacency (FA) is advertised, the depth at which
   the label stack will inspected indicated in signaling at setup time



Villamizar               Expires January 5, 2012               [Page 13]


Internet-Draft              MPLS TE Multipath                  July 2011


   is expressed in the Min Depth field of the Multipath Link Capability
   sub-TLV.

   The advertised Max Depth and IP Depth of a PSC LSP must be one less
   that the minimum of the Max Depth and IP Depth of any link that the
   PSC LSP traverses.  The Max Depth and IP Depth are considered
   independently of each other.

3.2.  RSVP-TE LSP Attributes

   All LSP SHOULD advertise a Contained Ordered Aggregate Attributes
   TLV.  LSP with strict packet order requirements MUST set the OA Depth
   field to one to indicate that the LSP MUST be treated as ordered
   aggregate.  LSP which do not have strict packet order requirements
   MUST only carry LSP whose requirements are reflected in the
   containing LSP Contained Ordered Aggregate Attributes TLV and LSP
   Multipath Attributes TLVs or the containing LSP MUST either resignal
   appropriate TLVs using make-before-break semantics, or the contained
   LSP signaling must be rejected with a PathErr message.  Three cases
   are described in the following subsections.

3.2.1.  LSP Attributes for Ordered Aggregates

   The Flags field in the Contained Ordered Aggregate Attributes TLV
   MUST be set as follows.

   1.   If the LSP may directly contain IPv4 traffic, then the May
        Contain IPv4 bit in the Flags field MUST be set.

   2.   If the LSP may directly contain IPv6 traffic, then the May
        Contain IPv6 bit in the Flags field MUST be set.

   3.   If the LSP contains an LSP which has the May Contain IPv4 bit in
        the Flags field then the May Contain IPv4 bit in the Flags field
        MUST be set.

   4.   If the LSP contains an LSP which has the May Contain IPv6 bit in
        the Flags field then the May Contain IPv6 bit in the Flags field
        MUST be set.

   5.   If the LSP may contain psuedowires that do not use a pseudowire
        control word, or may contain IPv4 or IPv6 traffic, then the IP
        Multipath Allowed bit in the Flags field MUST be cleared.

   6.   If the LSP is known not to contain psuedowires that do not use a
        pseudowire control word, and is known not to contain IPv4 or
        IPv6 traffic, then the IP Multipath Allowed bit in the Flags
        field SHOULD be set unless disallowed due to a contained LSP.



Villamizar               Expires January 5, 2012               [Page 14]


Internet-Draft              MPLS TE Multipath                  July 2011


   7.   If the LSP is known not to contain psuedowires that do not use a
        pseudowire control word, and does not have strict packet
        ordering requirements, then the IP Multipath Allowed bit in the
        Flags field SHOULD be set unless disallowed due to a contained
        LSP.

   8.   If the IP Multipath Allowed bit in the Flags is set and the LSP
        has strict packet order requirements, the May Contain IPv4 and
        May Contain IPv6 MUST be clear.

   9.   If the LSP contains any LSP with the IP Multipath Allowed bit in
        the Flags field clear, then the IP Multipath Allowed bit in the
        Flags field MUST be clear.

   10.  If the LSP contains any LSP with either the May Contain IPv4 bit
        or the May Contain IPv6 bit in the Flags field set, and the
        containing LSP has strict packet ordering requirements, then the
        IP Multipath Allowed bit in the Flags field MUST be clear.

   If the LSP does not contain other LSP, then it can only contain
   pseudowire that terminate on that LSR.  If the LSP does not contain
   other LSP, then it should be known whether the LSP is used in an IP
   LER capacity.  Therefore, when a LSP does not contain other LSP, it
   should always be possible to accurately set the Flags field in the
   Contained Ordered Aggregate Attributes TLV.

   See Section 4 for guidelines for handling LSP which contain LSP that
   do not have a Contained Ordered Aggregate Attributes TLV.  The most
   conservative approach in this case is to clear the IP Multipath
   Allowed bit and set the May Contain IPv4 bit and the May Contain IPv6
   bit, however this may not always be necessary.

3.2.2.  LSP Attributes for Ordered Aggregates

   An LSP with strict packet order requirements SHOULD always include a
   Contained Ordered Aggregate Attributes TLV.  The OA Depth field MUST
   be set to one.  The LSP SHOULD NOT include any LSP Multipath
   Attributes TLV.

3.2.3.  Attributes for LSP without Packet Ordering

   If an LSP does not have strict packet order constraints, then the
   LSR_ATTRIBUTE object SHOULD always include a Contained Ordered
   Aggregate Attributes TLV.  The OA Depth MUST be either set to zero or
   set to a configured value that is greater than one.

   If the OA Depth is set to a configured value, then any setup attempt
   for a contained LSP with a depth greater than or equal to that value



Villamizar               Expires January 5, 2012               [Page 15]


Internet-Draft              MPLS TE Multipath                  July 2011


   SHOULD be rejected and a PathErr message sent.  Otherwise, if a setup
   attempt for a contained LSP with a depth greater that the current
   value included in the containing LSP OA Depth field, then the
   containing LSP MUST be rerouted with a OA Depth field value greater
   than any of the contained OA Depth field values.

   The values in the LSP Multipath Attributes TLV may be constrained to
   upper limits by configuration.  If an attempt to setup a contained
   LSP would result in exceeding one of these limits, then the LSR
   SHOULD reject the signaling attempt and send a PathErr message.

   If an LSP does not have strict packet order constraints, then the
   LSR_ATTRIBUTE object MAY contain one or more LSP Multipath Attributes
   TLV.  If the LSP does not contain any other LSP, then one LSP
   Multipath Attributes TLV MAY be contained, with the MP Depth field
   set to one.  In this case, the Largest LSE Microflow in the Largest
   Microflow Capacities field MUST be set to the requested bandwith of
   the LSP.  The optional Largest IP Microflow and Largest L4 Microflow
   MAY be included and set to configured values.

   If an LSP that does not have strict packet order constraints contains
   other LSP, then the LSP Multipath Attributes TLV advertised by the
   set of contained LSP MUST be used to set the LSP Multipath Attributes
   TLV Largest Microflow Capacities values for LSP Multipath Attributes
   TLV.  The value of Largest LSE Microflow, Largest IP Microflow, and
   Largest L4 Microflow in the LSP Multipath Attributes TLV of the
   containing LSP with an MP Depth of N cannot be less than the maximum
   effective value of the same parameter for any contained LSP Multipath
   Attributes TLV with an MP Depth value of N-1.

3.3.  Path Computation Constraints

   The RSVP-TE extensions provides a set of requirements to be met by
   the links which the LSP is to traverse.  This set of requirements
   also serves as the basis for path computation constraints and for
   admission control constraints.

3.3.1.  Link Multipath Capabilities and Path Computation

   Three cases are considered.  An LSP may have strict ordering
   constraints.  An MPLS-TP LSP is an example of an LSP with strict
   ordering constraints.  This first type of LSP is covered in
   Section 3.3.1.1.  An LSP may have no ordering constraints at all
   other than the constraint that microflows cannot be reordered.  This
   second case is covered in Section 3.3.1.2.  The remaining case is
   where an LSP has no ordering constraints but carries traffic for
   other LSP which do have ordering constraints.  This third case is
   covered in Section 3.3.1.3.



Villamizar               Expires January 5, 2012               [Page 16]


Internet-Draft              MPLS TE Multipath                  July 2011


3.3.1.1.  Path Computation with Ordering Constraints

   For an MPLS-TP LSP or other LSP with a strict packet ordering
   constraint, any link for which the Ordered Aggregate Enabled bit is
   not set must be excluded from the path computation.  If the Default
   to Multipath bit is set on a link, then extensions to RSVP-TE to
   indicate a requirement to maintain packet order must be used in
   signaling to override the default.

3.3.1.2.  Path Computation with No Ordering Constraint

   For an MPLS LSP which has no constraint on packet ordering except
   that microflows must remain in order and does not contain other LSP
   with ordering constraints, any link for which the Multipath Enabled
   bit is set SHOULD use an available bandwidth taken from the
   "Unreserved Bandwidth" rather than the "Maximum LSP Bandwidth" (see
   [RFC4201]).

   For most LSP, the bandwidth requirement of the largest microflow is
   not known but an upper bound is known.  For example if the LSP
   aggregates PW or other LSP of no more than some maximum capacity or
   LSP which have signaled a microflow upper bound, then an upper bound
   on the largest microflow is known.  If this upper bound exceeds the
   "Maximum LSP Bandwidth" of a given link, then that link SHOULD be
   excluded from the path computation.

3.3.1.3.  Path Computation for MPLS containing MPLS-TP

   To carry LSP which have strict packet ordering requirements within
   LSP that do not have strict packet ordering requirements, the label
   stack depth at which multipath traffic distribution is allowed to
   take information must be limited.  To set up such an LSP, the minimum
   label stack depth at which an MPLS-TP LSP or other LSP with strict
   ordering constraints will be carried must be known.

   For links which have the Variable Depth Multipath bit clear, the MPLS
   LSP MUST be treated as if the containing LSP has ordering
   constraints, unless the Max Depth for the link is equal to the
   minimum label stack depth at which an MPLS-TP LSP or other LSP with
   strict ordering constraints will be carried.  If the LSP is treated
   as if the containing LSP has ordering constraints, bandwidth
   contraints MUST be applied as described in Section 3.3.1.1.  Failing
   to do so would violate the ordering contraints of contained LSP.

   For links which have the Variable Depth Multipath bit set, contraints
   may be applied to links in the path computation as described in
   Section 3.3.1.2.  The minimum label stack depth at which an MPLS-TP
   LSP or other LSP with strict ordering constraints is carried MUST be



Villamizar               Expires January 5, 2012               [Page 17]


Internet-Draft              MPLS TE Multipath                  July 2011


   signaled when the LSP is set up.

   The minimum label stack depth at which an MPLS-TP LSP or other LSP
   with strict ordering constraints is carried limits the multipath load
   balance and therefore requires an additional constraint.  For LSP
   that cannot be further subdivided using information in IP headers
   below the MPLS stack, those LSP are effectively equivalent to
   microflows from a multipath load distribution standpoint.  If the
   largest bandwidth requirement for any such LSP carried at that depth
   is known, then any link for which the "Maximum LSP Bandwidth" is less
   than that bandwidth requirement SHOULD be excluded from the path
   computation.

3.3.2.  Link IP Capabilities and Path Computation

   An MPLS-TP LSP cannot be reordered.  There may be other types of LSP
   with strict packet ordering requirements.  If LSP with strict packet
   ordering requirements carry IP, using IP headers in the multipath
   load distribution would violate the packet ordering requirements.

   Some LSP cannot be reordered but do not carry IP, and do not carry
   payloads which could be mistaken as IP.  For example, any LSP
   carrying only pseudowire traffic, where all pseudowires are using a
   control word carries no payloads which could be mistaken as IP.
   These type of LSP can be carried within MPLS LSP that allow use of IP
   header information in multipath load distribution.

3.3.2.1.  LSP without Packet Ordering Requirements

   Many LSP carry only IP or predominatly IP, use no hierarchy or have
   little diversity in the MPLS label stack, and carry far more traffic
   than can be carried over a single component link in a multipath.
   Many LSP due to their high capacity, must traverse only multipath
   which will use IP header information in the multipath traffic
   distribution.

   For these LSP, links must be excluded from the path computation which
   do not have the IPv4 Enabled Multipath and IPv6 Enabled Multipath bit
   set (if carrying both IPv4 and IPv6) and do not have either the
   Default to IP/MPLS Multipath bit set or the IP Optioal Multipath bit
   set.

   Hierarchical PSC LSP which require the use IP header information in
   the multipath traffic distribution MUST NOT set the Ordered Aggregate
   Enabled bit, MUST set the Default to IP/MPLS Multipath bit, and MUST
   NOT set the VARIP bit in the FA advertisement.





Villamizar               Expires January 5, 2012               [Page 18]


Internet-Draft              MPLS TE Multipath                  July 2011


3.3.2.2.  LSP with Ordering Requirements

   In some cases an MPLS-TP may carry no IP traffic directly under the
   label stack.  For example, if only pseudowire service ([RFC3985]) is
   being supported by an LSP, and all pseudowires are using a control
   word, and all control and management information is carried in a
   generic associated channel ([RFC5586]), then no IP traffic is carried
   directly under the label stack.  In this case, it is highly desirable
   to signal the MPLS-TP LSP to allow IP header information to be used
   in the multpath load distribution.  Doing so will allow any MPLS LSP
   containing this MPLS-TP LSP to allow the use of IP header information
   in the multipath load distribution.

   Where MPLS-TP LSP are carrying IP, for any link for which the use of
   IP header information is not disabled or cannot be disabled on a per
   LSP basis, that link must be excluded from the path computation.
   Links which do not have to be excluded include link with the IPv4
   Enabled Multipath and IPv6 Enabled Multipath bits clear, links with
   the Default to IP/MPLS Multipath clear, and links with the IP Optioal
   Multipath bit set.  For those links with the IP Optioal Multipath
   set, MPLS-TP LSP which carry IP MUST explicitly disable the use of IP
   in the multipath load distribution in signaling if the Default to IP/
   MPLS Multipath is set and SHOULD explicitly disable the use o\ f IP
   in the multipath load distribution in signaling if the Default to IP/
   MPLS Multipath is clear.

3.3.2.3.  LSP containing LSP with Ordering Requirements

   The largest effective microflow with respect to a given multipath
   link can depend on whether the link can use IP header information in
   the multipath traffic distribution.

   If a PSC LSP will need to carry traffic which cannot use IP header
   information in the multipath traffic distribution, then all links for
   which this capability is supported and enabled and cannot be
   disabled, must be excluded from the LSP path computation.  Links
   which can be included in the LSP path computation include those with
   the IPv4 Enabled Multipath and IPv6 Enabled Multipath bits clear,
   those with the Default to IP/MPLS Multipath clear, or those with the
   VARIP set.  For links with the IPv4 Enabled Multipath or IPv6 Enabled
   Multipath bit set, the Default to IP/MPLS Multipath bit set, and the
   VAR IP bit set, the requirement to disable use of IP in the multipath
   traffic distribution must be indicated in signaling.

3.3.3.  Link Depth Limitations and Path Computation

   For any LSP which does not have strict packet ordering constraints,
   LSP configuration SHOULD include the following parameters.



Villamizar               Expires January 5, 2012               [Page 19]


Internet-Draft              MPLS TE Multipath                  July 2011


   LSP Min Depth
      a minimal acceptable number of label used in multipath traffic
      distribution,

   LSP IP Depth
      a minimal label stack depth where the IP header can be used in
      multipath traffic distribution

   For example, if a PSC LSP will carry LSP which in turn carry very
   high capacity pseudowires using the pseudowire flow label (see
   [I-D.ietf-pwe3-fat-pw]), the flow label is four labels deep.  In this
   case, LSP Min Depth should be configured at four or higher.

   For example, if the same PSC LSP will carry LSP which carry IP
   traffic with no additional labels, then the IP header is two labels
   deep.  In this case, LSP IP Depth should be configured at two or
   higher.

   For an LSP with LSP Min Depth configured, all links with Max Depth
   set to a value below LSP Min Depth MUST be excluded from the LSP Path
   Computation.

   For an LSP with LSP IP Depth configured, all links with IP Depth set
   to a value below LSP IP Depth MUST be excluded from the LSP Path
   Computation.


4.  Backwards Compatibility

   Networks today use three forms of multipath.

   1.  IP ECMP, including IP ECMP at LER using more than one LSP.

   2.  Ethernet Link Aggregation [IEEE-802.1AX].

   3.  MPLS Link Bundling [RFC4201].

4.1.  Legacy Multipath Behavior

   IP ECMP and Ethernet Link Aggregation always distribute traffic over
   the entire multipath either using information in the MPLS label
   stack, or using information in a potential IP header, or using both
   types of information.

   One of two behaviors is assumed for link bundles.  Either the link
   bundles place each LSP in its entirety on a single link bundle
   component link for all LSP, or link bundles distribute traffic over
   the entire link bundle using the same techniques used for ECMP and



Villamizar               Expires January 5, 2012               [Page 20]


Internet-Draft              MPLS TE Multipath                  July 2011


   Ethernet Link Aggregation.  This second behavior is known as the "all
   ones" component link (see [RFC4201]).

4.2.  Networks without Multipath Extensions

   Networks exist that are comprised entirely of LSR which do not
   support these multipath extensions.  In these networks there is no
   way of telling how multipath links will behave.  Since an Ethernt
   Link Aggregation Goup (LAG) is advertised as an ordinary link, there
   is no way to tell that it is a form of multipath.

4.2.1.  Netowrks with MP Capability on all Multipath

   Most large core network today rely heavily on the use of multipath.
   Ethernet Link Aggregation and configure LSR to use the "all ones"
   component link for all LSP.  The "all ones" component link is the
   default for many Link Bundling implementations used in core networks.

   This is equivalent to the following setting in the Multipath Node
   Capabilities sub-TLV or Multipath Link Capabilities sub-TLV.

      Clear the Ordered Aggregate Enabled bit,

      set the Multipath Enabled bit, set the Default to Multipath bit,
      and clearing the Variable Depth Multipath bit.

      If the label stack is used in the multipath traffic distribution,
      set Max Depth to the number of label stack entries supported,
      otherwise set it to one.

      If an IP packet under the label stack can be used in the multipath
      traffic distribution, set IPv4 Enabled Multipath, set IPv6 Enabled
      Multipath, set Default to IP/MPLS Multipath, and set IP Depth to
      the maximum number of label stack entries which can be skipped
      over before finding the IP stack.  Otherwise clear IPv4 Enabled
      Multipath, clear IPv6 Enabled Multipath and clear Default to IP/
      MPLS Multipath.

   These networks can support very large LSP but cannot support LSP
   which require strict packet ordering with other labels below such an
   LSP, such as pseudowire labels.  They may also misroute OAM packet
   which use GAL (see [RFC5586]).  Generally the Link Bundle
   advertisements indicate a "Maximum LSP Bandwidth" that is equal to
   the "Unreserved Bandwidth".







Villamizar               Expires January 5, 2012               [Page 21]


Internet-Draft              MPLS TE Multipath                  July 2011


4.2.2.  Netowrks with OA Capability on all Multipath

   Somc networks, particularly edge networks which tend to be lower
   capacity, do not use Link Aggregation, and if they use Link Bundling
   at all, configure each LSR to place each LSP in its entirety on a
   single link bundle component link for all LSP.  Some edge equipment
   only supports this link bundle behavior.

   This is equivalent to the following setting in the Multipath Node
   Capabilities sub-TLV or Multipath Link Capabilities sub-TLV.

      Clear the Ordered Aggregate Enabled bit,

      Clear the Multipath Enabled bit.

      All remaining bits in the Flags field should be clear.

      The Min Depth, Max Depth, and IP Depth should be set to zero.

   These networks can support LSP which require strict packet ordering,
   but cannot support very large LSP.

4.2.3.  Legacy Netowrks with Mixed MP and OA Links

   Some netowrk may support Ethernet Link Aggregation and all or a
   subset of LSR which place each LSP in its entirety on a single link
   bundle component link for all LSP.

   If the "Maximum LSP Bandwidth" is set as described in Section 4.2.1,
   then very large LSP can be supported.  Very large LSP cannot be
   supported on LSR which place each LSP in its entirety on a single
   link bundle component link for all LSP, but these are clearly
   indicated in signaling,

   In these mixed netowrks it is not possible to reliably support LSP
   which require strict packet ordering.  It is not possible to know
   where Ethernet Link Aggregation is used and it is not possible to
   accurately determine Link Bundling behavior on link bundles where
   "Maximum LSP Bandwidth" is equal to "Unreserved Bandwidth".

4.3.  Transition to Multipath Extension Support

   If a Multipath Node Capability sub-TLV is not advertised (see
   Section 2.1), then the LSR does not support these multipath
   extensions, or is not adjacent to any multipath.  This allows
   detection of such nodes and if necessary application of defaults to
   cover Ethernet Link Aggregation Behavior.




Villamizar               Expires January 5, 2012               [Page 22]


Internet-Draft              MPLS TE Multipath                  July 2011


4.3.1.  Simple Transitions

   For networks with LSR that do not support for multipath extensions,
   transition is easiest if all legacy LSR support and are configured
   with a common link bundling behavior.  If Ethernet Link Aggregation
   is not used, a single configured default is needed to cover LSR that
   do not advertise a Multipath Node Capability sub-TLV.

   If Ethernet Link Aggregation had been previously used on Legacy LSR,
   if possible LAG should be disabled and the members of the former LAG
   configured and advertised as a link bundle which uses the equivalent
   "all ones" behavior.

   The transition network in this case lacks the ability to determine
   the largest microflow that can pass through legacy nodes, but this
   was the case prior to transition for the entire network prior to
   transition.

4.3.2.  More Challenging Transitions

   Transition is made more difficult if legacy LSR in a network support
   Ethernet Link Aggregation but do not support Link Bundle.  This
   situation is most easily handled if a small upgrade to such an LSR
   can advertise a fixed Multipath Node Capability sub-TLV giveing the
   characteristics of the Ethernet Link Aggregation on implementation on
   that node.  Absent of such cooperation, the problem can be solved by
   configuration on newer LSR which allows association of a Multipath
   Node Capability sub-TLV with a specific legacy router ID and possibly
   a legacy router ID and link.

   LSR supporting Multipath Extensions assign default values assigned by
   configuration to these legacy LSR running Ethernet Link Aggregation.
   These default values serve to allow LSP which require strict packet
   ordering to avoid these legacy LSR.

   LSR which do not support [RFC4201] may be sufficiently rare that the
   ability to assign default values per legacy LSR may not be needed in
   practice.


5.  IANA Considerations

   [ ... to be completeed ... ]

   The symbolic constants IANA-TBD-1 through IANA-TBD-4 need to be
   replaced.  Complete instructions, including identification of the
   number space for each of these will be added to a later version of
   this internet-draft.



Villamizar               Expires January 5, 2012               [Page 23]


Internet-Draft              MPLS TE Multipath                  July 2011


6.  Security Considerations

   The combination of MPLS, MPLS-TP, and multipath does not introduce
   any new security threats.  The security considerations for MPLS/GMPLS
   and for MPLS-TP are documented in [RFC5920] and
   [I-D.ietf-mpls-tp-security-framework].


7.  References

7.1.  Normative References

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

7.2.  Informative References

   [I-D.ietf-mpls-tp-security-framework]
              Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP
              Security Framework",
              draft-ietf-mpls-tp-security-framework-01 (work in
              progress), May 2011.

   [I-D.ietf-pwe3-fat-pw]
              Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
              J., and S. Amante, "Flow Aware Transport of Pseudowires
              over an MPLS Packet Switched Network",
              draft-ietf-pwe3-fat-pw-06 (work in progress), May 2011.

   [I-D.villamizar-mpls-tp-multipath]
              Villamizar, C., "Use of Multipath with MPLS-TP and MPLS",
              draft-villamizar-mpls-tp-multipath-01 (work in progress),
              March 2011.

   [IEEE-802.1AX]
              IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE
              Standard for Local and Metropolitan Area Networks - Link
              Aggregation", 2006, <http://standards.ieee.org/getieee802/
              download/802.1AX-2008.pdf>.

   [ITU-T.G.800]
              ITU-T, "Unified functional architecture of transport
              networks", 2007, <http://www.itu.int/rec/T-REC-G/
              recommendation.asp?parent=T-REC-G.800>.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.



Villamizar               Expires January 5, 2012               [Page 24]


Internet-Draft              MPLS TE Multipath                  July 2011


   [RFC2702]  Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
              McManus, "Requirements for Traffic Engineering Over MPLS",
              RFC 2702, September 1999.

   [RFC2991]  Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
              Multicast Next-Hop Selection", RFC 2991, November 2000.

   [RFC3260]  Grossman, D., "New Terminology and Clarifications for
              Diffserv", RFC 3260, April 2002.

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [RFC3945]  Mannie, E., "Generalized Multi-Protocol Label Switching
              (GMPLS) Architecture", RFC 3945, October 2004.

   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", RFC 3985, March 2005.

   [RFC4201]  Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
              in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
              Hierarchy with Generalized Multi-Protocol Label Switching
              (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

   [RFC5420]  Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
              Ayyangarps, "Encoding of Attributes for MPLS LSP
              Establishment Using Resource Reservation Protocol Traffic
              Engineering (RSVP-TE)", RFC 5420, February 2009.

   [RFC5586]  Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
              Associated Channel", RFC 5586, June 2009.

   [RFC5786]  Aggarwal, R. and K. Kompella, "Advertising a Router's
              Local Addresses in OSPF Traffic Engineering (TE)
              Extensions", RFC 5786, March 2010.

   [RFC5920]  Fang, L., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

   [RFC6107]  Shiomoto, K. and A. Farrel, "Procedures for Dynamically
              Signaled Hierarchical Label Switched Paths", RFC 6107,
              February 2011.






Villamizar               Expires January 5, 2012               [Page 25]


Internet-Draft              MPLS TE Multipath                  July 2011


Author's Address

   Curtis Villamizar (editor)
   Infinera Corporation
   169 W. Java Drive
   Sunnyvale, CA  94089

   Email: curtis@occnc.com











































Villamizar               Expires January 5, 2012               [Page 26]