[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 draft-ietf-rtgwg-cl-framework

RTGWG                                                            S. Ning
Internet-Draft                                       Tata Communications
Intended status: Informational                                D. McDysan
Expires: December 31, 2012                                       Verizon
                                                              E. Osborne
                                                                   Cisco
                                                                 L. Yong
                                                              Huawei USA
                                                           C. Villamizar
                                                  Outer Cape Cod Network
                                                              Consulting
                                                           June 29, 2012


   Composite Link Framework in Multi Protocol Label Switching (MPLS)
                  draft-so-yong-rtgwg-cl-framework-06

Abstract

   This document specifies a framework for support of composite link in
   MPLS networks.  A composite link consists of a group of homogenous or
   non-homogenous links that have the same forward adjacency and can be
   considered as a single TE link or an IP link in routing.  A composite
   link relies on its component links to carry the traffic over the
   composite link.  Applicability is described for a single pair of
   MPLS-capable nodes, a sequence of MPLS-capable nodes, or a set of
   layer networks connecting MPLS-capable nodes.

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 December 31, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the



Ning, et al.            Expires December 31, 2012               [Page 1]


Internet-Draft          Composite Link Framework               June 2012


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Architecture Summary . . . . . . . . . . . . . . . . . . .  4
     1.2.  Conventions used in this document  . . . . . . . . . . . .  5
       1.2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . .  5
   2.  Composite Link Key Characteristics . . . . . . . . . . . . . .  5
     2.1.  Flow Identification  . . . . . . . . . . . . . . . . . . .  6
     2.2.  Composite Link in Control Plane  . . . . . . . . . . . . .  8
     2.3.  Composite Link in Data Plane . . . . . . . . . . . . . . . 11
   3.  Architecture Tradeoffs . . . . . . . . . . . . . . . . . . . . 11
     3.1.  Scalability Motivations  . . . . . . . . . . . . . . . . . 12
     3.2.  Reducing Routing Information and Exchange  . . . . . . . . 12
     3.3.  Reducing Signaling Load  . . . . . . . . . . . . . . . . . 13
       3.3.1.  Reducing Signaling Load using LDP  . . . . . . . . . . 14
       3.3.2.  Reducing Signaling Load using Hierarchy  . . . . . . . 14
       3.3.3.  Using Both LDP and RSVP-TE Hierarchy . . . . . . . . . 14
     3.4.  Reducing Forwarding State  . . . . . . . . . . . . . . . . 14
     3.5.  Avoiding Route Oscillation . . . . . . . . . . . . . . . . 15
   4.  New Challenges . . . . . . . . . . . . . . . . . . . . . . . . 16
     4.1.  Control Plane Challenges . . . . . . . . . . . . . . . . . 16
       4.1.1.  Delay and Jitter Sensitive Routing . . . . . . . . . . 17
       4.1.2.  Local Control of Traffic Distribution  . . . . . . . . 17
       4.1.3.  Path Symmetry Requirements . . . . . . . . . . . . . . 17
       4.1.4.  Requirements for Contained LSP . . . . . . . . . . . . 18
       4.1.5.  Retaining Backwards Compatibility  . . . . . . . . . . 19
     4.2.  Data Plane Challenges  . . . . . . . . . . . . . . . . . . 19
       4.2.1.  Very Large LSP . . . . . . . . . . . . . . . . . . . . 20
       4.2.2.  Very Large Microflows  . . . . . . . . . . . . . . . . 20
       4.2.3.  Traffic Ordering Constraints . . . . . . . . . . . . . 20
       4.2.4.  Accounting for IP and LDP Traffic  . . . . . . . . . . 21
       4.2.5.  IP and LDP Limitations . . . . . . . . . . . . . . . . 21
   5.  Existing Mechanisms  . . . . . . . . . . . . . . . . . . . . . 22
     5.1.  Link Bundling  . . . . . . . . . . . . . . . . . . . . . . 22
     5.2.  Classic Multipath  . . . . . . . . . . . . . . . . . . . . 24



Ning, et al.            Expires December 31, 2012               [Page 2]


Internet-Draft          Composite Link Framework               June 2012


   6.  Mechanisms Proposed in Other Documents . . . . . . . . . . . . 24
     6.1.  Loss and Delay Measurement . . . . . . . . . . . . . . . . 24
     6.2.  Link Bundle Extensions . . . . . . . . . . . . . . . . . . 25
     6.3.  Fat PW and Entropy Labels  . . . . . . . . . . . . . . . . 26
     6.4.  Multipath Extensions . . . . . . . . . . . . . . . . . . . 26
   7.  Required Protocol Extensions and Mechanisms  . . . . . . . . . 27
     7.1.  Brief Review of Requirements . . . . . . . . . . . . . . . 27
     7.2.  Required Document Coverage . . . . . . . . . . . . . . . . 28
       7.2.1.  Component Link Grouping  . . . . . . . . . . . . . . . 28
       7.2.2.  Delay and Jitter Extensions  . . . . . . . . . . . . . 29
       7.2.3.  Path Selection and Admission Control . . . . . . . . . 29
       7.2.4.  Dynamic Multipath Balance  . . . . . . . . . . . . . . 30
       7.2.5.  Frequency of Load Balance  . . . . . . . . . . . . . . 30
       7.2.6.  Inter-Layer Communication  . . . . . . . . . . . . . . 30
       7.2.7.  Packet Ordering Requirements . . . . . . . . . . . . . 31
       7.2.8.  Minimally Disruption Load Balance  . . . . . . . . . . 31
       7.2.9.  Path Symmetry  . . . . . . . . . . . . . . . . . . . . 31
       7.2.10. Performance, Scalability, and Stability  . . . . . . . 32
       7.2.11. IP and LDP Traffic . . . . . . . . . . . . . . . . . . 32
       7.2.12. LDP Extensions . . . . . . . . . . . . . . . . . . . . 32
       7.2.13. Pseudowire Extensions  . . . . . . . . . . . . . . . . 33
       7.2.14. Multi-Domain Composite Link  . . . . . . . . . . . . . 33
     7.3.  Open Issues Regarding Requirements . . . . . . . . . . . . 34
     7.4.  Framework Requirement Coverage by Protocol . . . . . . . . 34
       7.4.1.  OSPF-TE and ISIS-TE Protocol Extensions  . . . . . . . 35
       7.4.2.  PW Protocol Extensions . . . . . . . . . . . . . . . . 35
       7.4.3.  LDP Protocol Extensions  . . . . . . . . . . . . . . . 35
       7.4.4.  RSVP-TE Protocol Extensions  . . . . . . . . . . . . . 35
       7.4.5.  RSVP-TE Path Selection Changes . . . . . . . . . . . . 35
       7.4.6.  RSVP-TE Admission Control and Preemption . . . . . . . 35
       7.4.7.  Flow Identification and Traffic Balance  . . . . . . . 35
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 35
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 36
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 36
     10.2. Informative References . . . . . . . . . . . . . . . . . . 37
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40














Ning, et al.            Expires December 31, 2012               [Page 3]


Internet-Draft          Composite Link Framework               June 2012


1.  Introduction

   Composite Link functional requirements are specified in
   [I-D.ietf-rtgwg-cl-requirement].  Composite Link use cases are
   described in [I-D.symmvo-rtgwg-cl-use-cases].  This document
   specifies a framework to meet these requirements.

   Classic multipath, including Ethernet Link Aggregation has been
   widely used in today's MPLS networks [RFC4385][RFC4928].  Classic
   multipath using non-Ethernet links are often advertised using MPLS
   Link bundling.  A link bundle [RFC4201] bundles a group of
   homogeneous links as a TE link to make IGP-TE information exchange
   and RSVP-TE signaling more scalable.  A composite link allows
   bundling non-homogenous links together as a single logical link.  The
   motivations for using a composite link are descried in
   [I-D.ietf-rtgwg-cl-requirement] and [I-D.symmvo-rtgwg-cl-use-cases].

   This document describes a composite link framework in the context of
   MPLS networks using an IGP-TE and RSVP-TE MPLS control plane with
   GMPLS extensions [RFC3209][RFC3630][RFC3945][RFC5305].

   A composite link is a single logical link in MPLS network that
   contains multiple parallel component links between two MPLS LSR.
   Unlike a link bundle [RFC4201], the component links in a composite
   link can have different properties such as cost or capacity.

   Specific protocol solutions are outside the scope of this document,
   however a framework for the extension of existing protocols is
   provided.  Backwards compatibility is best achieved by extending
   existing protocols where practical rather than inventing new
   protocols.  The focus is on examining where existing protocol
   mechanisms fall short with respect to [I-D.ietf-rtgwg-cl-requirement]
   and on extensions that will be required to accommodate functionality
   that is called for in [I-D.ietf-rtgwg-cl-requirement].

1.1.  Architecture Summary

   Networks aggregate information, both in the control plane and in the
   data plane, as a means to achieve scalability.  A tradeoff exists
   between the needs of scalability and the needs to identify differing
   path and link characteristics and differing requirements among flows
   contained within further aggregated traffic flows.  These tradeoffs
   are discussed in detail in Section 3.

   Some aspects of Composite Link requirements present challenges for
   which multiple solutions may exist.  In Section 4 various challenges
   and potential approaches are discussed.




Ning, et al.            Expires December 31, 2012               [Page 4]


Internet-Draft          Composite Link Framework               June 2012


   A subset of the functionality called for in
   [I-D.ietf-rtgwg-cl-requirement] is available through MPLS Link
   Bundling [RFC4201].  Link bundling and other existing standards
   applicable to Composite Link are covered in Section 5.

   The most straightforward means of supporting Composite Link
   requirements is to extend MPLS protocols and protocol semantics and
   in particular to extend link bundling.  Extensions which have already
   been proposed in other documents which are applicable to Composite
   Link are discussed in Section 6.

   Goals of most new protocol work within IETF is to reuse existing
   protocol encapsulations and mechanisms where they meet requirements
   and extend existing mechanisms such that additional complexity is
   minimized while meeting requirements and such that backwards
   compatibility is preserved to the extent it is practical to do so.
   These goals are considered in proposing a framework for further
   protocol extensions and mechanisms in Section 7.

1.2.  Conventions used in this document

   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.2.1.  Terminology

   Terminology defined in [I-D.ietf-rtgwg-cl-requirement] is used in
   this document.

   The abbreviation IGP-TE is used as a shorthand indicating either
   OSPF-TE [RFC3630] or ISIS-TE [RFC5305].


2.  Composite Link Key Characteristics

   [I-D.ietf-rtgwg-cl-requirement] defines external behavior of
   Composite Links.  The overall framework approach involves extending
   existing protocols in a backwards compatible manner and reusing
   ongoing work elsewhere in IETF where applicable, defining new
   protocols or semantics only where necessary.  Given the requirements,
   and this approach of extending MPLS, Composite Link key
   characteristics can be described in greater detail than given
   requirements alone.







Ning, et al.            Expires December 31, 2012               [Page 5]


Internet-Draft          Composite Link Framework               June 2012


2.1.  Flow Identification

   Traffic mapping to component links is a data plane operation.
   Control over how the mapping is done may be directly dictated or
   constrained by the control plane or by the management plane.  When
   unconstrained by the control plane or management plane, distribution
   of traffic is entirely a local matter.  Regardless of constraints or
   lack or constraints, the traffic distribution is required to keep
   packets belonging to individual flows in sequence and meet QoS
   criteria specified per LSP by either signaling or management
   [RFC2475][RFC3260].  A key objective of the traffic distribution is
   to not overload any component link, and be able to perform local
   recovery when one of component link fails.

   The network operator may have other objectives such as placing a
   bidirectional flow or LSP on the same component link in both
   direction, load balance over component links, composite link energy
   saving, and etc.  These new requirements are described in
   [I-D.ietf-rtgwg-cl-requirement].

   Examples of means to identify a flow may in principle include:

   1.  an LSP identified by an MPLS label,

   2.  a sub-LSP [I-D.kompella-mpls-rsvp-ecmp] identified by an MPLS
       label,

   3.  a pseudowire (PW) [RFC3985] identified by an MPLS PW label,

   4.  a flow or group of flows within a pseudowire (PW) [RFC6391]
       identified by an MPLS flow label,

   5.  a flow or flow group in an LSP [I-D.ietf-mpls-entropy-label]
       identified by an MPLS entropy label,

   6.  all traffic between a pair of IP hosts, identified by an IP
       source and destination pair,

   7.  a specific connection between a pair of IP hosts, identified by
       an IP source and destination pair, protocol, and protocol port
       pair,

   8.  a layer-2 conversation within a pseudowire (PW), where the
       identification is PW payload type specific, such as Ethernet MAC
       addresses and VLAN tags within an Ethernet PW (RFC4448).

   Although in principle a layer-2 conversation within a pseudowire
   (PW), may be identified by PW payload type specific information, in



Ning, et al.            Expires December 31, 2012               [Page 6]


Internet-Draft          Composite Link Framework               June 2012


   practice this is impractical at LSP midpoints when PW are carried.
   The PW ingress may provide equivalent information in a PW flow label
   [RFC6391].  Therefore, in practice, item #8 above is covered by
   [RFC6391] and may be dropped from the list.

   An LSR must at least be capable of identifying flows based on MPLS
   labels.  Most MPLS LSP do not require that traffic carried by the LSP
   are carried in order.  MPLS-TP is a recent exception.  If it is
   assumed that no LSP require strict packet ordering of the LSP itself
   (only of flows within the LSP), then the entire label stack can be
   used as flow identification.  If some LSP may require strict packet
   ordering but those LSP cannot be distinguished from others, then only
   the top label can be used as a flow identifier.  If only the top
   label is used (for example, as specified by [RFC4201] when the "all-
   ones" component described in [RFC4201] is not used), then there may
   not be adequate flow granularity to accomplish well balanced traffic
   distribution and it will not be possible to carry LSP that are larger
   than any individual component link.

   The number of flows can be extremely large.  This may be the case
   when the entire label stack is used and is always the case when IP
   addresses are used in provider networks carrying Internet traffic.
   Current practice for native IP load balancing at the time of writing
   were documented in [RFC2991], [RFC2992].  These practices as
   described, make use of IP addresses.  The common practices were
   extended to include the MPLS label stack and the common practice of
   looking at IP addresses within the MPLS payload.  These extended
   practices are described in [RFC4385] and [RFC4928] due to their
   impact on pseudowires without a PWE3 Control Word.  Additional detail
   on current multipath practices can be found in the appendices of
   [I-D.symmvo-rtgwg-cl-use-cases].

   Using only the top label supports too coarse a traffic balance.
   Using the full label stack or IP addresses as flow identification
   provides a sufficiently fine traffic balance, but is capable of
   identifying such a high number of distinct flows, that a technique of
   grouping flows, such as hashing on the flow identification criteria,
   becomes essential to reduce the stored state, and is an essential
   scaling technique.  Other means of grouping flows may be possible.

   In summary:

   1.  Load balancing using only the MPLS label stack provides too
       coarse a granularity of load balance.

   2.  Tracking every flow is not scalable due to the extremely large
       number of flows in provider networks.




Ning, et al.            Expires December 31, 2012               [Page 7]


Internet-Draft          Composite Link Framework               June 2012


   3.  Existing techniques, IP source and destination hash in
       particular, have proven in over two decades of experience to be
       an excellent way of identifying groups of flows.

   4.  If a better way to identify groups of flows is discovered, then
       that method can be used.

   5.  IP address hashing is not required, but use of this technique is
       strongly encouraged given the technique's long history of
       successful deployment.

2.2.  Composite Link in Control Plane

   A composite Link is advertised as a single logical interface between
   two connected routers, which forms forwarding adjacency (FA) between
   the routers.  The FA is advertised as a TE-link in a link state IGP,
   using either OSPF-TE or ISIS-TE.  The IGP-TE advertised interface
   parameters for the composite link can be preconfigured by the network
   operator or be derived from its component links.  Composite link
   advertisement requirements are specified in
   [I-D.ietf-rtgwg-cl-requirement].

   In IGP-TE, a composite link is advertised as a single TE link between
   two connected routers.  This is similar to a link bundle [RFC4201].
   Link bundle applies to a set of homogenous component links.
   Composite link allows homogenous and non-homogenous component links.
   Due to the similarity, and for backwards compatibility, extending
   link bundling is viewed as both simple and as the best approach.

   In order for a route computation engine to calculate a proper path
   for a LSP, it is necessary for composite link to advertise the
   summarized available bandwidth as well as the maximum bandwidth that
   can be made available for single flow (or single LSP where no finer
   flow identification is available).  If a composite link contains some
   non-homogeneous component links, the composite link also should
   advertise the summarized bandwidth and the maximum bandwidth for
   single flow per each homogeneous component link group.

   Both LDP [RFC5036] and RSVP-TE [RFC3209] can be used to signal a LSP
   over a composite link.  LDP cannot be extended to support traffic
   engineering capabilities [RFC3468].

   When an LSP is signaled using RSVP-TE, the LSP MUST be placed on the
   component link that meets the LSP criteria indicated in the signaling
   message.

   When an LSP is signaled using LDP, the LSP MUST be placed on the
   component link that meets the LSP criteria, if such a component link



Ning, et al.            Expires December 31, 2012               [Page 8]


Internet-Draft          Composite Link Framework               June 2012


   is available.  LDP does not support traffic engineering capabilities,
   imposing restrictions on LDP use of Composite Link.  See
   Section 4.2.5 for further details.

   A composite link may contain non-homogeneous component links.  The
   route computing engine may select one group of component links for a
   LSP.  The routing protocol MUST make this grouping available in the
   TE-LSDB.  The route computation used in RSVP-TE MUST be extended to
   include only the capacity of groups within a composite link which
   meet LSP criteria.  The signaling protocol MUST be able to indicate
   either the criteria, or which groups may be used.  A composite link
   MUST place the LSP on a component link or group which meets or
   exceeds the LSP criteria.

   Composite link capacity is aggregated capacity.  LSP capacity MAY be
   larger than individual component link capacity.  Any aggregated LSP
   can determine a bounds on the largest microflow that could be carried
   and this constraint can be handled as follows.

   1.  If no information is available through signaling, management
       plane, or configuration, the largest microflow is bound by one of
       the following:

       A.  the largest single LSP if most traffic is RSVP-TE signaled
           and further aggregated,

       B.  the largest pseudowire if most traffic is carrying pseudowire
           payloads that are aggregated within RSVP-TE LSP,

       C.  or the largest source and sink interface if a large amount of
           IP or LDP traffic is contained within the aggregate.

       If a very large amount of traffic being aggregated is IP or LDP,
       then the largest microflow is bound by the largest component link
       on which IP traffic can arrive.  For example, if an LSR is acting
       as an LER and IP and LDP traffic is arrving on 10 Gb/s edge
       interfaces, then no microflow larger than 10 Gb/s will be present
       on the RSVP-TE LSP that aggregate traffic across the core, even
       if the core interfaces are 100 Gb/s interfaces.

   2.  The prior conditions provide a bound on the largest microflow
       when no signaling extensions indicate a bounds.  If an LSP is
       aggregating smaller LSP for which the largest expected microflow
       carried by the smaller LSP is signaled, then the largest
       microflow expected in the containing LSP (the aggregate) is the
       maximum of the largest expected microflow for any contained LSP.
       For example, RSVP-TE LSP may be large but aggregate traffic for
       which the source or sink are all 1 Gb/s or smaller interfaces



Ning, et al.            Expires December 31, 2012               [Page 9]


Internet-Draft          Composite Link Framework               June 2012


       (such as in mobile applications in which cell sites backhauls are
       no larger than 1 Gb/s).  If this information is carried in the
       LSP originated at the cell sites, then further aggregates across
       a core may make use of this information.

   3.  The IGP must provide the bounds on the largest microflow that a
       composite link can accommodate, which is the maximum capacity on
       a component link that can be made available by moving other
       traffic.  This information is needed by the ingress LER for path
       determination.

   4.  A means to signal an LSP whose capacity is larger than individual
       component link capacity is needed [I-D.ietf-rtgwg-cl-requirement]
       and also signal the largest microflow expected to be contained in
       the LSP.  If a bounds on the largest microflow is not signaled
       there is no means to determine if an LSP which is larger than any
       component link can be subdivided into flows and therefore should
       be accepted by admission control.

   When a bidirectional LSP request is signaled over a composite link,
   if the request indicates that the LSP must be placed on the same
   component link, the routers of the composite link MUST place the LSP
   traffic in both directions on a same component link.  This is
   particularly challenging for aggregated capacity which makes use of
   the label stack for traffic distribution.  The two requirements are
   mutually exclusive for any one LSP.  No one LSP may be both larger
   than any individual component link and require symmetrical paths for
   every flow.  Both requirements can be accommodated by the same
   composite link for different LSP, with any one LSP requiring no more
   than one of these two features.

   Individual component link may fail independently.  Upon component
   link failure, a composite link MUST support a minimally disruptive
   local repair, preempting any LSP which can no longer be supported.
   Available capacity in other component links MUST be used to carry
   impacted traffic.  The available bandwidth after failure MUST be
   advertised immediately to avoid looped crankback.

   When a composite link is not able to transport all flows, it preempts
   some flows based upon local management configuration and informs the
   control plane on these preempted flows.  The composite link MUST
   support soft preemption [RFC5712].  This action ensures the remaining
   traffic is transported properly.  FR#10 requires that the traffic be
   restored.  FR#12 requires that any change be minimally disruptive.
   These two requirements are interpreted to include preemption among
   the types of changes that must be minimally disruptive.





Ning, et al.            Expires December 31, 2012              [Page 10]


Internet-Draft          Composite Link Framework               June 2012


2.3.  Composite Link in Data Plane

   The data plane must first identify groups of flows.  Flow
   identification is covered in Section 2.1.  Having identified groups
   of flows the groups must be placed on individual component links.
   This second step is called traffic distribution or traffic placement.
   The two steps together are known as traffic balancing or load
   balancing.

   Traffic distribution may be determined by or constrained by control
   plane or management plane.  Traffic distribution may be changed due
   to component link status change, subject to constraints imposed by
   either the management plane or control plane.  The distribution
   function is local to the routers in which a composite link belongs to
   and is not specified here.

   When performing traffic placement, a composite link does not
   differentiate multicast traffic vs. unicast traffic.

   In order to maintain scalability, existing data plane forwarding
   retains state associated with the top label only.  The use of flow
   group identification is in a second step in the forwarding process.
   Data plane forwarding makes use of the top label to select a
   composite link, or a group of components within a composite link or
   for the case where an LSP is pinned (see [RFC4201]), a specific
   component link.  For those LSP for which the LSP selects only the
   composite link or a group of components within a composite link, the
   load balancing makes use of the flow group identification.

   The most common traffic placement techniques uses the a flow group
   identification as an index into a table.  The table provides an
   indirection.  The number of bits of hash is constrained to keep table
   size small.  While this is not the best technique, it is the most
   common.  Better techniques exist but they are outside the scope of
   this document and some are considered proprietary.

   Requirements to limit frequency of load balancing can be adhered to
   by keeping track of when a flow group was last moved and imposing a
   minimum period before that flow group can be moved again.  This is
   straightforward for a table approach.  For other approaches it may be
   less straightforward but is acheivable.


3.  Architecture Tradeoffs

   Scalability and stability are critical considerations in protocol
   design where protocols may be used in a large network such as today's
   service provider networks.  Composite Link is applicable to networks



Ning, et al.            Expires December 31, 2012              [Page 11]


Internet-Draft          Composite Link Framework               June 2012


   which are large enough to require that traffic be split over multiple
   paths.  Scalability is a major consideration for networks that reach
   a capacity large enough to require Composite Link.

   Some of the requirements of Composite Link could potentially have a
   negative impact on scalability.  For example, Composite Link requires
   additional information to be carried in situations where component
   links differ in some significant way.

3.1.  Scalability Motivations

   In the interest of scalability information is aggregated in
   situations where information about a large amount of network capacity
   or a large amount of network demand provides is adequate to meet
   requirements.  Routing information is aggregated to reduce the amount
   of information exchange related to routing and to simplify route
   computation (see Section 3.2).

   In an MPLS network large routing changes can occur when a single
   fault occurs.  For example, a single fault may impact a very large
   number of LSP traversing a given link.  As new LSP are signaled to
   avoid the fault, resources are consumed elsewhere, and routing
   protocol announcements must flood the resource changes.  If
   protection is in place, there is less urgency to converging quickly.
   If multiple faults occur that are not covered by shared risk groups
   (SRG), then some protection may fail, adding urgency to converging
   quickly even where protection was deployed.

   Reducing the amount of information allows the exchange of information
   during a large routing change to be accomplished more quickly and
   simplifies route computation.  Simplifying route computation improves
   convergence time after very significant network faults which cannot
   be handled by preprovisioned or precomputed protection mechanisms.
   Aggregating smaller LSP into larger LSP is a means to reduce path
   computation load and reduce RSVP-TE signaling (see Section 3.3).

   Neglecting scaling issues can result in performance issues, such as
   slow convergence.  Neglecting scaling in some cases can result in
   networks which perform so poorly as to become unstable.

3.2.  Reducing Routing Information and Exchange

   Link bundling at the very least provides a means of aggregating
   control plane information.  Even where the all-ones component link
   supported by link bundling is not used, the amount of control
   information is reduced by the average number of component links in a
   bundle.




Ning, et al.            Expires December 31, 2012              [Page 12]


Internet-Draft          Composite Link Framework               June 2012


   Fully deaggregating link bundle information would negate this
   benefit.  If there is a need to deaggregate, such as to distinguish
   between groups of links within specified ranges of delay, then no
   more deaggregation than is necessary should be done.

   For example, in supporting the requirement for heterogeneous
   component links, it makes little sense to fully deaggregate link
   bundles when adding support for groups of component links with common
   attributes within a link bundle can maintain most of the benefit of
   aggregation while adequately supporting the requirement to support
   heterogeneous component links.

   Routing information exchange is also reduced by making sensible
   choices regarding the amount of change to link parameters that
   require link readvertisement.  For example, if delay measurements
   include queuing delay, then a much more coarse granularity of delay
   measurement would be called for than if the delay does not include
   queuing and is dominated by geographic delay (speed of light delay).

3.3.  Reducing Signaling Load

   Aggregating traffic into very large hierarchical LSP in the core very
   substantially reduces the number of LSP that need to be signaled and
   the number of path computations any given LSR will be required to
   perform when a major network fault occurs.

   In the extreme, applying MPLS to a very large network without
   hierarchy could exceed the 20 bit label space.  For example, in a
   network with 4,000 nodes, with 2,000 on either side of a cutset,
   would have 4,000,000 LSP crossing the cutset.  Even in a degree four
   cutset, an uneven distribution of LSP across the cutset, or the loss
   of one link would result in a need to exceed the size of the label
   space.  Among provider networks, 4,000 access nodes is not at all
   large.

   In less extreme cases, having each node terminate hundreds of LSP to
   achieve a full mesh creates a very large computational load.  The
   time complexity of one CSPF computation is order(N log N), where L is
   proportional to N, and N and L are the number of nodes and number of
   links, respectively.  If each node must perform order(N) computations
   when a fault occurs, then the computational load increases as
   order(N^2 log N) as the number of nodes increases.  In practice at
   the time of writing, this imposes a limit of a few hundred nodes in a
   full mesh of MPLS LSP before the computational load is sufficient to
   result in unacceptable convergence times.

   Two solutions are applied to reduce the amount of RSVP-TE signaling.
   Both involve subdividing the MPLS domain into a core and a set of



Ning, et al.            Expires December 31, 2012              [Page 13]


Internet-Draft          Composite Link Framework               June 2012


   regions.

3.3.1.  Reducing Signaling Load using LDP

   LDP can be used for edge-to-edge LSP, using RSVP-TE to carry the LDP
   intra-core traffic and also optionally also using RSVP-TE to carry
   the LDP intra-region traffic within each region.  LDP does not
   support traffic engineering, but does support multipoint-to-point
   (MPTP) LSP, which require less signaling than edge-to-edge RSVP-TE
   point-to-point (PTP) LSP.  A drawback of this approach is the
   inability to use RSVP-TE protection (FRR or GMPLS protection) against
   failure of the border LSR sitting at a core/region boundary.

3.3.2.  Reducing Signaling Load using Hierarchy

   When the number of nodes grows too large, the amount of RSVP-TE
   signaling can be reduced using the MPLS PSC hierarchy [RFC4206].  A
   core within the hierarchy can divide the topology into M regions of
   on average N/M nodes.  Within a region the computational load is
   reduced by more than M^2.  Within the core, the computational load
   generally becomes quite small since M is usually a fairly small
   number (a few tens of regions) and each region is generally attached
   to the core in typically only two or three places on average.

   Using hierarchy improves scaling but has two consequences.  First,
   hierarchy effectively forces the use of platform label space.  When a
   containing LSP is rerouted, the labels assigned to the contained LSP
   cannot be changed but may arrive on a different interface.  Second,
   hierarchy results in much larger LSP.  These LSP today are larger
   than any single component link and therefore force the use of the
   all-ones component in link bundles.

3.3.3.  Using Both LDP and RSVP-TE Hierarchy

   It is also possible to use both LDP and RSVP-TE hierarchy.  MPLS
   networks with a very large number of nodes may benefit from the use
   of both LDP and RSVP-TE hierarchy.  The two techniques are certainly
   not mutually exclusive.

3.4.  Reducing Forwarding State

   Both LDP and MPLS hierarchy have the benefit of reducing the amount
   of forwarding state.  Using the example from Section 3.3, and using
   MPLS hierarchy, the worst case generally occurs at borders with the
   core.

   For example, consider a network with approximately 1,000 nodes
   divided into 10 regions.  At the edges, each node requires 1,000 LSP



Ning, et al.            Expires December 31, 2012              [Page 14]


Internet-Draft          Composite Link Framework               June 2012


   to other edge nodes.  The edge nodes also require 100 intra-region
   LSP.  Within the core, if the core has only 3 attachments to each
   region the core LSR have less than 100 intra-core LSP.  At the border
   cutset between the core and a given region, in this example there are
   100 edge nodes with inter-region LSP crossing that cutset, destined
   to 900 other edge nodes.  That yields forwarding state for on the
   order of 90,000 LSP at the border cutset.  These same routers need
   only reroute well under 200 LSP when a multiple fault occurs, as long
   as only links are affected and a border LSR does not go down.

   In the core, the forwarding state is greatly reduced.  If inter-
   region LSP have different characteristics, it makes sense to make use
   of aggregates with different characteristics.  Rather than exchange
   information about every inter-region LSP within the intra-core LSP it
   makes more sense to use multiple intra-core LSP between pairs of core
   nodes, each aggregating sets of inter-region LSP with common
   characteristics or common requirements.

3.5.  Avoiding Route Oscillation

   Networks can become unstable when a feedback loop exists such that
   moving traffic to a link causes a metric such as delay to increase,
   which then causes traffic to move elsewhere.  For example, the
   original ARPANET routing used a delay based cost metric and proved
   prone to route oscillations [DBP].

   Delay may be used as a constraint in routing for high priority
   traffic, where the movement of traffic cannot impact the delay.  The
   safest way to measure delay is to make measurements based on traffic
   which is prioritized such that it is queued ahead of the traffic
   which will be affected.  This is a reasonable measure of delay for
   high priority traffic for which constraints have been set which allow
   this type of traffic to consume only a fraction of link capacities
   with the remaining capacity available to lower priority traffic.

   Any measurement of jitter (delay variation) that is used in route
   decision is likely to cause oscillation.  Jitter that is caused by
   queuing effects and cannot be measured using a very high priority
   measurement traffic flow.

   It may be possible to find links with constrained queuing delay or
   jitter using a theoretical maximum or a probability based bound on
   queuing delay or jitter at a given priority based on the types and
   amounts of traffic accepted and combining that theoretical limit with
   a measured delay at very high priority.

   Instability can occur due to poor performance and interaction with
   protocol timers.  In this way a computational scaling problem can



Ning, et al.            Expires December 31, 2012              [Page 15]


Internet-Draft          Composite Link Framework               June 2012


   become a stability problem when a network becomes sufficiently large.
   For this reason, [I-D.ietf-rtgwg-cl-requirement] has a number of
   requirements focusing on minimally impacting scalability.


4.  New Challenges

   New technical challenges are posed by [I-D.ietf-rtgwg-cl-requirement]
   in both the control plane and data plane.

   Among the more difficult challenges are the following.

   1.  requirements related delay or jitter (see Section 4.1.1),

   2.  the combination of ingress control over LSP placement and
       retaining an ability to move traffic as demands dictate can pose
       challenges and such requirements can even be conflicting (see
       target="sect.local-control" />),

   3.  path symmetry requires extensions and is particularly challenging
       for very large LSP (see Section 4.1.3),

   4.  accommodating a very wide range of requirements among contained
       LSP can lead to inefficiency if the most stringent requirements
       are reflected in aggregates, or reduce scalability if a large
       number of aggregates are used to provide a too fine a reflection
       of the requirements in the contained LSP (see Section 4.1.4),

   5.  backwards compatibility is somewhat limited due to the need to
       accommodate legacy multipath interfaces which provide too little
       information regarding their configured default behavior, and
       legacy LSP which provide too little information regarding their
       requirements (see Section 4.1.5),

   6.  data plane challenges include those of accommodating very large
       LSP, large microflows, traffic ordering constraints imposed by a
       subsent of LSP, and accounting for IP and LDP traffic (see
       Section 4.2).

4.1.  Control Plane Challenges

   Some of the control plane requirements are particularly challenging.
   Handling large flows which aggregate smaller flows must be
   accomplished with minimal impact on scalability.  Potentially
   conflicting are requirements for jitter and requirements for
   stability.  Potentially conflicting are the requirements for ingress
   control of a large number of parameters, and the requirements for
   local control needed to achieve traffic balance across a composite



Ning, et al.            Expires December 31, 2012              [Page 16]


Internet-Draft          Composite Link Framework               June 2012


   link.  These challenges and potential solutions are discussed in the
   following sections.

4.1.1.  Delay and Jitter Sensitive Routing

   Delay and jitter sensitive routing are called for in
   [I-D.ietf-rtgwg-cl-requirement] in requirements FR#2, FR#7, FR#8,
   FR#9, FR#15, FR#16, FR#17, FR#18.  Requirement FR#17 is particularly
   problematic, calling for constraints on jitter.

   A tradeoff exists between scaling benefits of aggregating
   information, and potential benefits of using a finer granularity in
   delay reporting.  To maintain the scaling benefit, measured link
   delay for any given composite link SHOULD be aggregated into a small
   number of delay ranges.  IGP-TE extensions MUST be provided which
   advertise the available capacities for each of the selected ranges.

   For path selection of delay sensitive LSP, the ingress SHOULD bias
   link metrics based on available capacity and select a low cost path
   which meets LSP total path delay criteria.  To communicate the
   requirements of an LSP, the ERO MUST be extended to indicate the per
   link constraints.  To communicate the type of resource used, the RRO
   SHOULD be extended to carry an identification of the group that is
   used to carry the LSP at each link bundle hop.

4.1.2.  Local Control of Traffic Distribution

   Many requirements in [I-D.ietf-rtgwg-cl-requirement] suggest that a
   node immediately adjacent to a component link should have a high
   degree of control over how traffic is distributed, as long as network
   performance objectives are met.  Particularly relevant are FR#18 and
   FR#19.

   The requirements to allow local control are potentially in conflict
   with requirement FR#21 which gives full control of component link
   select to the LSP ingress.  While supporting this capability is
   mandatory, use of this feature is optional per LSP.

   A given network deployment will have to consider this pair of
   conflicting requirements and make appropriate use of local control of
   traffic placement and ingress control of traffic placement to best
   meet network requirements.

4.1.3.  Path Symmetry Requirements

   Requirement FR#21 in [I-D.ietf-rtgwg-cl-requirement] includes a
   provision to bind both directions of a bidirectional LSP to the same
   component.  This is easily achieved if the LSP is directly signaled



Ning, et al.            Expires December 31, 2012              [Page 17]


Internet-Draft          Composite Link Framework               June 2012


   across a composite link.  This is not as easily achieved if a set of
   LSP with this requirement are signaled over a large hierarchical LSP
   which is in turn carried over a composite link.  The basis for load
   distribution in such as case is the label stack.  The labels in
   either direction are completely independent.

   This could be accommodated if the ingress, egress, and all midpoints
   of the hierarchical LSP make use of an entropy label in the
   distribution, and use only that entropy label.  A solution for this
   problem may add complexity with very little benefit.  There is little
   or no true benefit of using symmetrical paths rather than component
   links of identical characteristics.

   Traffic symmetry and large LSP capacity are a second pair of
   conflicting requirements.  Any given LSP can meet one of these two
   requirements but not both.  A given network deployment will have to
   make appropriate use of each of these features to best meet network
   requirements.

4.1.4.  Requirements for Contained LSP

   [I-D.ietf-rtgwg-cl-requirement] calls for new LSP constraints.  These
   constraints include frequency of load balancing rearrangement, delay
   and jitter, packet ordering constraints, and path symmetry.

   When LSP are contained within hierarchical LSP, there is no signaling
   available at midpoint LSR which identifies the contained LSP let
   alone providing the set of requirements unique to each contained LSP.
   Defining extensions to provide this information would severely impact
   scalability and defeat the purpose of aggregating control information
   and forwarding information into hierarchical LSP.  For the same
   scalability reasons, not aggregating at all is not a viable option
   for large networks where scalability and stability problems may occur
   as a result.

   As pointed out in Section 4.1.3, the benefits of supporting symmetric
   paths among LSP contained within hierarchical LSP may not be
   sufficient to justify the complexity of supporting this capability.

   A scalable solution which accommodates multiple sets of LSP between
   given pairs of LSR is to provide multiple hierarchical LSP for each
   given pair of LSR, each hierarchical LSP aggregating LSP with common
   requirements and a common pair of endpoints.  This is a network
   design technique available to the network operator rather than a
   protocol extension.  This technique can accommodate multiple sets of
   delay and jitter parameters, multiple sets of frequency of load
   balancing parameters, multiple sets of packet ordering constraints,
   etc.



Ning, et al.            Expires December 31, 2012              [Page 18]


Internet-Draft          Composite Link Framework               June 2012


4.1.5.  Retaining Backwards Compatibility

   Backwards compatibility and support for incremental deployment
   requires considering the impact of legacy LSR in the role of LSP
   ingress, and considering the impact of legacy LSR advertising
   ordinary links, advertising Ethernet LAG as ordinary links, and
   advertising link bundles.

   Legacy LSR in the role of LSP ingress cannot signal requirements
   which are not supported by their control plane software.  The
   additional capabilities supported by other LSR has no impact on these
   LSR.  These LSR however, being unaware of extensions, may try to make
   use of scarce resources which support specific requirements such as
   low delay.  To a limited extent it may be possible for a network
   operator to avoid this issue using existing mechanisms such as link
   administrative attributes and attribute affinities [RFC3209].

   Legacy LSR advertising ordinary links will not advertise attributes
   needed by some LSP.  For example, there is no way to determine the
   delay or jitter characteristics of such a link.  Legacy LSR
   advertising Ethernet LAG pose additional problems.  There is no way
   to determine that packet ordering constraints would be violated for
   LSP with strict packet ordering constraints, or that frequency of
   load balancing rearrangement constraints might be violated.

   Legacy LSR advertising link bundles have no way to advertise the
   configured default behavior of the link bundle.  Some link bundles
   may be configured to place each LSP on a single component link and
   therefore may not be able to accommodate an LSP which requires
   bandwidth in excess of the size of a component link.  Some link
   bundles may be configured to spread all LSP over the all-ones
   component.  For LSR using the all-ones component link, there is no
   documented procedure for correctly setting the "Maximum LSP
   Bandwidth".  There is currently no way to indicate the largest
   microflow that could be supported by a link bundle using the all-ones
   component link.

   Having received the RRO, it is possible for an ingress to look for
   the all-ones component to identify such link bundles after having
   signaled at least one LSP.  Whether any LSR collects this information
   on legacy LSR and makes use of it to set defaults, is an
   implementation choice.

4.2.  Data Plane Challenges

   Flow identification is briefly discussed in Section 2.1.  Traffic
   distribution is briefly discussed in Section 2.3.  This section
   discusses issues specific to particular requirements specified in



Ning, et al.            Expires December 31, 2012              [Page 19]


Internet-Draft          Composite Link Framework               June 2012


   [I-D.ietf-rtgwg-cl-requirement].

4.2.1.  Very Large LSP

   Very large LSP may exceed the capacity of any single component of a
   composite link.  In some cases contained LSP may exceed the capacity
   of any single component.  These LSP may the use of the equivalent of
   the all-ones component of a link bundle, or may use a subset of
   components which meet the LSP requirements.

   Very large LSP can be accommodated as long as they can be subdivided
   (see Section 4.2.2).  A very large LSP cannot have a requirement for
   symetric paths unless complex protocol extensions are proposed (see
   Section 2.2 and Section 4.1.3).

4.2.2.  Very Large Microflows

   Within a very large LSP there may be very large microflows.  A very
   large microflow is a very large flows which cannot be further
   subdivided.  Flows which cannot be subdivided must be no larger that
   the capacity of any single component.

   Current signaling provides no way to specify the largest microflow
   that a can be supported on a given link bundle in routing
   advertisements.  Extensions which address this are discussed in
   Section 6.4.  Absent extensions of this type, traffic containing
   microflows that are too large for a given composite link may be
   present.  There is no data plane solution for this problem that would
   not require reordering traffic at the composite link egress.

   Some techniques are susceptible to statistical collisions where an
   algorithm to distribute traffic is unable to disambiguate traffic
   among two or more very large microflow where their sum is in excess
   of the capacity of any single component.  Hash based algorithms which
   use too small a hash space are particularly susceptible and require a
   change in hash seed in the event that this were to occur.  A change
   in hash seed is highly disruptive, causing traffic reordering among
   all traffic flows over which the hash function is applied.

4.2.3.  Traffic Ordering Constraints

   Some LSP have strict traffic ordering constraints.  Most notable
   among these are MPLS-TP LSP.  In the absence of aggregation into
   hierarchical LSP, those LSP with strict traffic ordering constraints
   can be placed on individual component links if there is a means of
   identifying which LSP have such a constraint.  If LSP with strict
   traffic ordering constraints are aggregated in hierarchical LSP, the
   hierarchical LSP capacity may exceed the capacity of any single



Ning, et al.            Expires December 31, 2012              [Page 20]


Internet-Draft          Composite Link Framework               June 2012


   component link.  In such a case the load balancing for the containing
   may be constrained to look only at the top label and the first
   contained label.  This and related issues are discussed further in
   Section 6.4.

4.2.4.  Accounting for IP and LDP Traffic

   Networks which carry RSVP-TE signaled MPLS traffic generally carry
   low volumes of native IP traffic, often only carrying control traffic
   as native IP.  There is no architectural guarantee of this, it is
   just how network operators have made use of the protocols.

   [I-D.ietf-rtgwg-cl-requirement] requires that native IP and native
   LDP be accommodated.  In some networks, a subset of services may be
   carried as native IP or carried as native LDP.  Today this may be
   accommodated by the network operator estimating the contribution of
   IP and LDP and configuring a lower set of available bandwidth figures
   on the RSVP-TE advertisements.

   The only improvement that Composite Link can offer is that of
   measuring the IP and LDP traffic levels and automatically reducing
   the available bandwidth figures on the RSVP-TE advertisements.  The
   measurements would have to be significantly filtered.  This is
   similar to a feature in existing LSR, commonly known as
   "autobandwidth" with a key difference.  In the "autobandwidth"
   feature, the bandwidth request of an RSVP-TE signaled LSP is adjusted
   in response to traffic measurements.  In this case the IP or LDP
   traffic measurements are used to reduce the link bandwidth directly,
   without first encapsulating in an RSVP-TE LSP.

   This may be a subtle and perhaps even a meaningless distinction if
   Composite Link is used to form a Sub-Path Maintenance Element (SPME).
   A SPME is in practice essentially an unsignaled single hop LSP with
   PHP enabled [RFC5921].  A Composite Link SPME looks very much like
   classic multipath, where there is no signaling, only management plane
   configuration creating the multipath entity (of which Ethernet Link
   Aggregation is a subset).

4.2.5.  IP and LDP Limitations

   IP does not offer traffic engineering.  LDP cannot be extended to
   offer traffic engineering [RFC3468].  Therefore there is no traffic
   engineered fallback to an alternate path for IP and LDP traffic if
   resources are not adequate for the IP and/or LDP traffic alone on a
   given link in the primary path.  The only option for IP and LDP would
   be to declare the link down.  Declaring a link down due to resource
   exhaustion would reduce traffic to zero and eliminate the resource
   exhaustion.  This would cause oscillations and is therefore not a



Ning, et al.            Expires December 31, 2012              [Page 21]


Internet-Draft          Composite Link Framework               June 2012


   viable solution.

   Congestion caused by IP or LDP traffic loads is a pathologic case
   that can occur if IP and/or LDP are carried natively and there is a
   high volume of IP or LDP traffic.  This situation can be avoided by
   carrying IP and LDP within RSVP-TE LSP.

   It is also not possible to route LDP traffic differently for
   different FEC.  LDP traffic engineering is specifically disallowed by
   [RFC3468].  It may be possible to support multi-topology IGP
   extensions to accommodate more than one set of criteria.  If so, the
   additional IGP could be bound to the forwarding criteria, and the LDP
   FEC bound to a specific IGP instance, inheriting the forwarding
   criteria.  Alternately, one IGP instance can be used and the LDP SPF
   can make use of the constraints, such as delay and jitter, for a
   given LDP FEC.  [Note: WG needs to discuss this and decide first
   whether to solve this at all and then if so, how.]


5.  Existing Mechanisms

   In MPLS the one mechanisms which support explicit signaling of
   multiple parallel links is Link Bundling [RFC4201].  The set of
   techniques known as "classis multipath" support no explicit
   signaling, except in two cases.  In Ethernet Link Aggregation the
   Link Aggregation Control Protocol (LACP) coordinates the addition or
   removal of members from an Ethernet Link Aggregation Group (LAG).
   The use of the "all-ones" component of a link bundle indicates use of
   classis multipath, however the ability to determine if a link bundle
   makes use of classis multipath is not yet supported.

5.1.  Link Bundling

   Link bundling supports advertisement of a set of homogenous links as
   a single route advertisement.  Link bundling supports placement of an
   LSP on any single component link, or supports placement of an LSP on
   the all-ones component link.  Not all link bundling implementations
   support the all-ones component link.  There is no way for an ingress
   LSR to tell which potential midpoint LSR support this feature and use
   it by default and which do not.  Based on [RFC4201] it is unclear how
   to advertise a link bundle for which the all-ones component link is
   available and used by default.  Common practice is to violate the
   specification and set the Maximum LSP Bandwidth to the Available
   Bandwidth.  There is no means to determine the largest microflow that
   could be supported by a link bundle that is using the all-ones
   component link.

   [RFC6107] extends the procedures for hierarchical LSP but also



Ning, et al.            Expires December 31, 2012              [Page 22]


Internet-Draft          Composite Link Framework               June 2012


   extends link bundles.  An LSP can be explicitly signaled to indicate
   that it is an LSP to be used as a component of a link bundle.  Prior
   to that the common practice was to simply not advertise the component
   link LSP into the IGP, since only the ingress and egress of the link
   bundle needed to be aware of their existence, which they would be
   aware of due to the RSVP-TE signaling used in setting up the
   component LSP.

   While link bundling can be the basis for composite links, a
   significant number of small extension needs to be added.

   1.  To support link bundles of heterogeneous links, a means of
       advertising the capacity available within a group of homogeneous
       needs to be provided.

   2.  Attributes need to be defined to support the following parameters
       for the link bundle or for a group of homogeneous links.

       A.  delay range

       B.  jitter (delay variation) range

       C.  group metric

       D.  all-ones component capable

       E.  capable of dynamically balancing load

       F.  largest supportable microflow

       G.  abilities to support strict packet ordering requirements
           within contained LSP

   3.  For each of the prior extended attributes, the constraint based
       routing path selection needs to be extended to reflect new
       constraints based on the extended attributes.

   4.  For each of the prior extended attributes, LSP admission control
       needs to be extended to reflect new constraints based on the
       extended attributes.

   5.  Dynamic load balance must be provided for flows within a given
       set of links with common attributes such that NPO are not
       violated including frequency of load balance adjustment for any
       given flow.






Ning, et al.            Expires December 31, 2012              [Page 23]


Internet-Draft          Composite Link Framework               June 2012


5.2.  Classic Multipath

   Classic multipath is defined in [I-D.symmvo-rtgwg-cl-use-cases].

   Classic multipath refers to the most common current practice in
   implementation and deployment of multipath.  The most common current
   practice makes use of a hash on the MPLS label stack and if IPv4 or
   IPv6 are indicated under the label stack, makes use of the IP source
   and destination addresses [RFC4385] [RFC4928].

   Classic multipath provides a highly scalable means of load balancing.
   Adaptive multipath has proven value in assuring an even loading on
   component link and an ability to adapt to change in offerred load
   that occurs over periods of hundreds of milliseconds or more.
   Classic multipath scalability is due to the ability to effectively
   work with an extremely large number of flows (IP host pairs) using
   relatively little resources (a data structure accessed using a hash
   result as a key or using ranges of hash results).

   Classic multipath meets a small subset of Composite Link
   requirements.  Due to scalability of the approach, classic multipath
   seems to be an excellent candidate for extension to meet the full set
   of Composite Link forwarding requirements.

   Additional detail can be found in [I-D.symmvo-rtgwg-cl-use-cases].


6.  Mechanisms Proposed in Other Documents

   A number of documents which at the time of writing are works in
   progress address parts of the requirements of Composite Link, or
   assist in making some of the goals achievable.

6.1.  Loss and Delay Measurement

   Procedures for measuring loss and delay are provided in [RFC6374].
   These are OAM based measurements.  This work could be the basis of
   delay measurements and delay variation measurement used for metrics
   called for in [I-D.ietf-rtgwg-cl-requirement].

   Currently there are two additional Internet-Drafts that address delay
   and delay variation metrics.

   draft-wang-ccamp-latency-te-metric
       [I-D.wang-ccamp-latency-te-metric] is designed specifically to
       meet this requirement.  OSPF-TE and ISIS-TE extensions are
       defined to indicate link delay and delay variance.  The RSVP-TE
       ERO is extended to include service level requirements.  A latency



Ning, et al.            Expires December 31, 2012              [Page 24]


Internet-Draft          Composite Link Framework               June 2012


       accumulation object is defined to provide a means of verification
       of the service level requirements.  This draft is intended to
       proceed in the CCAMP WG.  It is currently and individual
       submission.  The 03 version of this draft expired in September
       2012.

   draft-giacalone-ospf-te-express-path
       This document proposes to extend OSPF-TE only.  Extensions
       support delay, delay variance, loss, residual bandwidth, and
       available bandwidth.  No extensions to RSVP-TE are proposed.
       This draft is intended to proceed in the CCAMP WG.  It is
       currently and individual submission.  The 02 version will expire
       in March 2012.

   A possible course of action may be to combine these two drafts.  The
   delay variance, loss, residual bandwidth, and available bandwidth
   extensions are particular prone to network instability.  The question
   as to whether queuing delay and delay variation should be considered,
   and if so for which diffserv Per-Hop Service Class (PSC) is not
   addressed.

   Note to co-authors: The ccamp-latency-te-metric draft refers to
   [I-D.ietf-rtgwg-cl-requirement] and is well matched to those
   requirements, including stability.  The ospf-te-express-path draft
   refers to the "Alto Protocol" (draft-ietf-alto-protocol) and
   therefore may not be intended for RSVP-TE use.  The authors of the
   two drafts may be able to resolve this.  It may be best to drop ospf-
   te-express-path from this framework document.

6.2.  Link Bundle Extensions

   A set of link bundling extensions are defined in
   [I-D.ietf-mpls-explicit-resource-control-bundle].  This document
   provides extensions to the ERO and RRO to explicitly control the
   labels and resources within a bundle used by an LSP.

   The extensions in this document could be further extended to support
   indicating a group of component links in the ERO or RRO, where the
   group is given an interface identification like the bundle itself.
   The extensions could also be further extended to support
   specification of the all-ones component link in the ERO or RRO.

   [I-D.ietf-mpls-explicit-resource-control-bundle] does not provide a
   means to advertise the link bundle components.  It is not certain how
   the ingress LSR would determine the set of link bundle component
   links available for a given link bundle.

   [I-D.ospf-cc-stlv] provides a baseline draft for extending link



Ning, et al.            Expires December 31, 2012              [Page 25]


Internet-Draft          Composite Link Framework               June 2012


   bundling to advertise components.  A new component TVL (C-TLV) is
   proposed, which must reference a Composite Link Link TLV.
   [I-D.ospf-cc-stlv] is intended for the OSPF WG and submitted for the
   "Experimental" track.  The 00 version expired in February 2012.

6.3.  Fat PW and Entropy Labels

   Two documents provide a means to add entropy for the purpose of
   improving load balance.  MPLS encapsulation can bury information that
   is needed to identify microflows.  These two documents allow a
   pseudowire ingress and LSP ingress respectively to add a label solely
   for the purpose of providing a finer granularity of microflow groups.

   [RFC6391] allows pseudowires which carry a large volume of traffic,
   where microflows can be identified to be load balanced across
   multiple members of an Ethernet LAG or an MPLS link bundle.  This is
   accomplished by adding a flow label below the pseudowire label in the
   MPLS label stack.  For this to be effective the link bundle load
   balance must make use of the label stack up to and including this
   flow label.

   [I-D.ietf-mpls-entropy-label] provides a means for a LER to put an
   additional label known as an entropy label on the MPLS label stack.
   As defined, only the LER can add the entropy label.

   Core LSR acting as LER for aggregated LSP can add entropy labels
   based on deep packet inspection and place an entropy label indicator
   (ELI) and entropy label (EL) just below the label being acted on.
   This would be helpful in situations where the label stack depth to
   which load distribution can operate is limited by implementation or
   is limited for other reasons such as carrying both MPLS-TP and MPLS
   with entropy labels within the same hierarchical LSP.

6.4.  Multipath Extensions

   The multipath extensions drafts address one aspect of Composite Link.
   These drafts deal with the issue of accommodating LSP which have
   strict packet ordering constraints in a network containing multipath.
   MPLS-TP has become the one important instance of LSP with strict
   packet ordering constraints and has driven this work.

   [I-D.villamizar-mpls-tp-multipath] outlines requirements and gives a
   number of options for dealing with the apparent incompatibility of
   MPLS-TP and multipath.  A preferred option is described.

   [I-D.villamizar-mpls-tp-multipath-te-extn] provides protocol
   extensions needed to implement the preferred option described in
   [I-D.villamizar-mpls-tp-multipath].



Ning, et al.            Expires December 31, 2012              [Page 26]


Internet-Draft          Composite Link Framework               June 2012


   Other issues pertaining to multipath are also addressed.  Means to
   advertise the largest microflow supportable are defined.  Means to
   indicate the largest expected microflow within an LSP are defined.
   Issues related to hierarchy are addressed.


7.  Required Protocol Extensions and Mechanisms

   Prior sections have reviewed key characteristics, architecture
   tradeoffs, new challenges, existing mechanisms, and relevant
   mechanisms proposed in existing new documents.

   This section first summarizes and groups requirements.  A set of
   documents coverage groupings are proposed with existing works-in-
   progress noted where applicable.  The set of extensions are then
   grouped by protocol affected as a convenience to implementors.

7.1.  Brief Review of Requirements

   The following list provides a categorization of requirements
   specified in [I-D.ietf-rtgwg-cl-requirement] along with a short
   phrase indication what topic the requirement covers.

   routing information aggregation
       FR#1 (routing summarization), FR#20 (composite link may be a
       component of another composite link)

   restoration speed
       FR#2 (restoration speed meeting NPO), FR#12 (minimally disruptive
       load rebalance), DR#6 (fast convergence), DR#7 (fast worst case
       failure convergence)

   load distribution, stability, minimal disruption
       FR#3 (automatic load distribution), FR#5 (must not oscillate),
       FR#11 (dynamic placement of flows), FR#12 (minimally disruptive
       load rebalance), FR#13 (bounded rearrangement frequency), FR#18
       (flow placement must satisfy NPO), FR#19 (flow identification
       finer than per top level LSP), MR#6 (operator initiated flow
       rebalance)

   backward compatibility and migration
       FR#4 (smooth incremental deployment), FR#6 (management and
       diagnostics must continue to function), DR#1 (extend existing
       protocols), DR#2 (extend LDP, no LDP TE)







Ning, et al.            Expires December 31, 2012              [Page 27]


Internet-Draft          Composite Link Framework               June 2012


   delay and delay variation
       FR#7 (expose lower layer measured delay), FR#8 (precision of
       latency reporting), FR#9 (limit latency on per LSP basis), FR#15
       (minimum delay path), FR#16 (bounded delay path), FR#17 (bounded
       jitter path)

   admission control, preemption, traffic engineering
       FR#10 (admission control, preemption), FR#14 (packet ordering),
       FR#21 (ingress specification of path), FR#22 (path symmetry),
       DR#3 (IP and LDP traffic), MR#3 (management specification of
       path)

   single vs multiple domain
       DR#4 (IGP extensions allowed within single domain), DR#5 (IGP
       extensions disallowed in multiple domain case)

   general network management
       MR#1 (polling, configuration, and notification), MR#2 (activation
       and de-activation)

   path determination, connectivity verification
       MR#4 (path trace), MR#5 (connectivity verification)

   The above list is not intended as a substitute for
   [I-D.ietf-rtgwg-cl-requirement], but rather as a concise grouping and
   reminder or requirements to serve as a means of more easily
   determining requirements coverage of a set of protocol documents.

7.2.  Required Document Coverage

   The primary areas where additional protocol extensions and mechanisms
   are required include the topics described in the following
   subsections.

   There are candidate documents for a subset of the topics below.  This
   grouping of topics does not require that each topic be addressed by a
   separate document.  In some cases, a document may cover multiple
   topics, or a specific topic may be addressed as applicable in
   multiple documents.

7.2.1.  Component Link Grouping

   An extension to link bundling is needed to specify a group of
   components with common attributes.  This can be a TLV defined within
   the link bundle that carries the same encapsulations as the link
   bundle.  Two interface indices would be needed for each group.





Ning, et al.            Expires December 31, 2012              [Page 28]


Internet-Draft          Composite Link Framework               June 2012


   a.  An index is needed that if included in an ERO would indicate the
       need to place the LSP on any one component within the group.

   b.  A second index is needed that if included in an ERO would
       indicate the need to balance flows within the LSP across all
       components of the group.  This is equivalent to the "all-ones"
       component for the entire bundle.

   [I-D.ospf-cc-stlv] can be extended to include multipath treatment
   capabilities.  An ISIS solution is also needed.  An extension of
   RSVP-TE signaling is needed to indicate multipath treatment
   preferences.

   If a component group is allowed to support all of the parameters of a
   link bundle, then a group TE metric would be accommodated.  This can
   be supported with the component TLV (C-TLV) defined in
   [I-D.ospf-cc-stlv].

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 is the "routing information aggregation" set of
   requirements.  The "restoration speed", "backward compatibility and
   migration", and "general network management" requirements must also
   be considered.

7.2.2.  Delay and Jitter Extensions

   A extension is needed in the IGP-TE advertisement to support delay
   and delay variation for links, link bundles, and forwarding
   adjacencies.  Whatever mechanism is described must take precautions
   that insure that route oscillations cannot occur.
   [I-D.wang-ccamp-latency-te-metric] may be a good starting point.

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 is the "delay and delay variation" set of
   requirements.  The "restoration speed", "backward compatibility and
   migration", and "general network management" requirements must also
   be considered.

7.2.3.  Path Selection and Admission Control

   Path selection and admission control changes must be documented in
   each document that proposes a protocol extension that advertises a
   new capability or parameter that must be supported by changes in path
   selection and admission control.

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 are the "load distribution, stability, minimal
   disruption" and "admission control, preemption, traffic engineering"



Ning, et al.            Expires December 31, 2012              [Page 29]


Internet-Draft          Composite Link Framework               June 2012


   sets of requirements.  The "restoration speed" and "path
   determination, connectivity verification" requirements must also be
   considered.  The "backward compatibility and migration", and "general
   network management" requirements must also be considered.

7.2.4.  Dynamic Multipath Balance

   FR#11 explicitly calls for dynamic load balancing similar to existing
   adaptive multipath.  In implementations where flow identification
   uses a coarse granularity, the adjustments would have to be equally
   coarse, in the worst case moving entire LSP.  The impact of flow
   identification granularity and potential adaptive multipath
   approaches may need to be documented in greater detail than provided
   here.

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 are the "restoration speed" and the "load
   distribution, stability, minimal disruption" sets of requirements.
   The "path determination, connectivity verification" requirements must
   also be considered.  The "backward compatibility and migration", and
   "general network management" requirements must also be considered.

7.2.5.  Frequency of Load Balance

   IGP-TE and RSVP-TE extensions are needed to support frequency of load
   balancing rearrangement called for in FR#13, and FR#15-FR#17.
   Constraints are not defined in RSVP-TE, but could be modeled after
   administrative attribute affinities in RFC3209 and elsewhere.

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 is the "load distribution, stability, minimal
   disruption" set of requirements.  The "path determination,
   connectivity verification" must also be considered.  The "backward
   compatibility and migration" and "general network management"
   requirements must also be considered.

7.2.6.  Inter-Layer Communication

   Lower layer to upper layer communication called for in FR#7 and
   FR#20.  This is addressed for a subset of parameters related to
   packet ordering in [I-D.villamizar-mpls-tp-multipath] where layers
   are MPLS.  Remaining parameters, specifically delay and delay
   variation, need to be addressed.  Passing information from a lower
   non-MPLS layer to an MPLS layer needs to be addressed, though this
   may largely be generic advice encouraging a coupling of MPLS to lower
   layer management plane or control plane interfaces.  This topic can
   be addressed in each document proposing a protocol extension, where
   applicable.



Ning, et al.            Expires December 31, 2012              [Page 30]


Internet-Draft          Composite Link Framework               June 2012


   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 is the "restoration speed" set of requirements.
   The "backward compatibility and migration" and "general network
   management" requirements must also be considered.

7.2.7.  Packet Ordering Requirements

   A document is needed to define extensions supporting various packet
   ordering requirements, ranging from requirements to preservce
   microflow ordering only, to requirements to preservce full LSP
   ordering (as in MPLS-TP).  This is covered by
   [I-D.villamizar-mpls-tp-multipath] and
   [I-D.villamizar-mpls-tp-multipath-te-extn].

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 are the "admission control, preemption, traffic
   engineering" and the "path determination, connectivity verification"
   sets of requirements.  The "backward compatibility and migration" and
   "general network management" requirements must also be considered.

7.2.8.  Minimally Disruption Load Balance

   The behavior of hash methods used in classic multipath needs to be
   described in terms of FR#12 which calls for minimally disruptive load
   adjustments.  For example, reseeding the hash violates FR#12.  Using
   modulo operations is significantly disruptive if a link comes or goes
   down, as pointed out in [RFC2992].  In addition, backwards
   compatibility with older hardware needs to be accommodated.

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 is the "load distribution, stability, minimal
   disruption" set of requirements.

7.2.9.  Path Symmetry

   Protocol extensions are needed to support dynamic load balance as
   called for to meet FR#22 (path symmetry) and to meet FR#11 (dynamic
   placement of flows).  Currently path symmetry can only be supported
   in link bundling if the path is pinned.  When a flow is moved both
   ingress and egress must make the move as close to simultaneously as
   possible to satisfy FR#22 and FR#12 (minimally disruptive load
   rebalance).  If a group of flows are identified using a hash, then
   the hash must be identical on the pair of LSR at the endpoint, using
   the same hash seed and with one side swapping source and destination.
   If the label stack is used, then either the entire label stack must
   be a special case flow identification, since the set of labels in
   either direction are not correlated, or the two LSR must conspire to
   use the same flow identifier.  For example, using a common entropy



Ning, et al.            Expires December 31, 2012              [Page 31]


Internet-Draft          Composite Link Framework               June 2012


   label value, and using only the entropy label in the flow
   identification would satisfy this requirement.

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 are the "load distribution, stability, minimal
   disruption" and the "admission control, preemption, traffic
   engineering" sets of requirements.  The "backward compatibility and
   migration" and "general network management" requirements must also be
   considered.  Path symetry simplifies support for the "path
   determination, connectivity verification" set of requirements, but
   with significant complexity added elsewhere.

7.2.10.  Performance, Scalability, and Stability

   A separate document providing analysis of performance, scalability,
   and stability impacts of changes may be needed.  The topic of traffic
   adjustment oscillation must also be covered.  If sufficient coverage
   is provided in each document covering a protocol extension, a
   separate document would not be needed.

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 is the "restoration speed" set of requirements.
   This is not a simple topic and not a topic that is well served by
   scattering it over multiple documents, therefore it may be best to
   put this in a separate document and put citations in documents called
   for in Section 7.2.1, Section 7.2.2, Section 7.2.3, Section 7.2.9,
   Section 7.2.11, Section 7.2.12, Section 7.2.13, and Section 7.2.14.
   Citation may also be helpful in Section 7.2.4, and Section 7.2.5.

7.2.11.  IP and LDP Traffic

   A document is needed to define the use of measurements native IP and
   native LDP traffic levels to reduce link advertised bandwidth
   amounts.

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 are the "load distribution, stability, minimal
   disruption" and the "admission control, preemption, traffic
   engineering" set of requirements.  The "path determination,
   connectivity verification" must also be considered.  The "backward
   compatibility and migration" and "general network management"
   requirements must also be considered.

7.2.12.  LDP Extensions

   Extending LDP is called for in DR#2.  LDP can be extended to couple
   FEC admission control to local resource availability without
   providing LDP traffic engineering capability.  Other LDP extensions



Ning, et al.            Expires December 31, 2012              [Page 32]


Internet-Draft          Composite Link Framework               June 2012


   such as signaling a bound on microflow size and LDP LSP requirements
   would provide useful information without providing LDP traffic
   engineering capability.

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 is the "admission control, preemption, traffic
   engineering" set of requirements.  The "backward compatibility and
   migration" and "general network management" requirements must also be
   considered.

7.2.13.  Pseudowire Extensions

   PW extensions such as signaling a bound on microflow size and PW
   requirements would provide useful information.

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 is the "admission control, preemption, traffic
   engineering" set of requirements.  The "backward compatibility and
   migration" and "general network management" requirements must also be
   considered.

7.2.14.  Multi-Domain Composite Link

   DR#5 calls for Composite Link to span multiple network topologies.
   Component LSP may already span multiple network topologies, though
   most often in practice these are LDP signaled.  Component LSP which
   are RSVP-TE signaled may also span multiple network topologies using
   at least three existing methods (per domain [RFC5152], BRPC
   [RFC5441], PCE [RFC4655]).  When such component links are combined in
   a Composite Link, the Composite Link spans multiple network
   topologies.  It is not clear in which document this needs to be
   described or whether this description in the framework is sufficient.
   The authors and/or the WG may need to discuss this.  DR#5 mandates
   that IGP-TE extension cannot be used.  This would disallow the use of
   [RFC5316] or [RFC5392] in conjunction with [RFC5151].

   The primary focus of this document, among the sets of requirements
   listed in Section 7.1 are "single vs multiple domain" and "admission
   control, preemption, traffic engineering".  The "routing information
   aggregation" and "load distribution, stability, minimal disruption"
   requirements need attention due to their use of the IGP in single
   domain Composite Link.  Other requirements such as "delay and delay
   variation", can more easily be accomodated by carrying metrics within
   BGP.  The "path determination, connectivity verification"
   requirements need attention due to requirements to restrict
   disclosure of topology information across domains in multi-domain
   deployments.  The "backward compatibility and migration" and "general
   network management" requirements must also be considered.



Ning, et al.            Expires December 31, 2012              [Page 33]


Internet-Draft          Composite Link Framework               June 2012


7.3.  Open Issues Regarding Requirements

   Note to co-authors: This section needs to be reduced to an empty
   section and then removed.

   The following topics in the requirements document are not addressed.
   Since they are explicitly mentioned in the requirements document some
   mention of how they are supported is needed, even if to say nother
   needed to be done.  If we conclude any particular topic is
   irrelevant, maybe the topic should be removed from the requirement
   document.  At that point we could add the management requirements
   that have come up and were missed.

   1.  L3VPN RFC 4364, RFC 4797,L2VPN RFC 4664, VPWS, VPLS RFC 4761, RFC
       4762 and VPMS VPMS Framework
       (draft-ietf-l2vpn-vpms-frmwk-requirements).  It is not clear what
       additional Composite Link requirements these references imply, if
       any.  If no additional requirements are implied, then these
       references are considered to be informational only.

   2.  Migration may not be adequately covered in Section 4.1.5.  It
       might also be necessary to say more here on performance,
       scalability, and stability as it related to migration.  Comments
       on this from co-authors or the WG?

   3.  We may need a performance section in this document to
       specifically address #DR6 (fast convergence), and #DR7 (fast
       worst case failure convergence), though we do already have
       scalability discussion.  The performance section would have to
       say "no worse than before, except were there was no alternative
       to make it very slightly worse" (in a bit more detail than that).
       It would also have to better define the nature of the performance
       criteria.

7.4.  Framework Requirement Coverage by Protocol

   As an aid to implementors, this section summarizes requirement
   coverage listed in Section 7.2 by protocol or LSR functionality
   affected.

   Some documentation may be purely informational, proposing no changes
   and proposing usage at most.  This includes Section 7.2.3,
   Section 7.2.8, Section 7.2.10, and Section 7.2.14.

   Section 7.2.9 may require a new protocol.






Ning, et al.            Expires December 31, 2012              [Page 34]


Internet-Draft          Composite Link Framework               June 2012


7.4.1.  OSPF-TE and ISIS-TE Protocol Extensions

   Many of the changes listed in Section 7.2 require IGP-TE changes,
   though most are small extensions to provide additional information.
   This set includes Section 7.2.1, Section 7.2.2, Section 7.2.5,
   Section 7.2.6, and Section 7.2.7.  An adjustment to existing
   advertised parameters is suggested in Section 7.2.11.

7.4.2.  PW Protocol Extensions

   The only suggestion of pseudowire (PW) extensions is in
   Section 7.2.13.

7.4.3.  LDP Protocol Extensions

   Potential LDP extensions are described in Section 7.2.12.

7.4.4.  RSVP-TE Protocol Extensions

   RSVP-TE protocol extensions are called for in Section 7.2.1,
   Section 7.2.5, Section 7.2.7, and Section 7.2.9.

7.4.5.  RSVP-TE Path Selection Changes

   Section 7.2.3 calls for path selection to be addressed in individual
   documents that require change.  These changes would include those
   proposed in Section 7.2.1, Section 7.2.2, Section 7.2.5, and
   Section 7.2.7.

7.4.6.  RSVP-TE Admission Control and Preemption

   When a change is needed to path selection, a corresponding change is
   needed in admission control.  The same set of sections applies:
   Section 7.2.1, Section 7.2.2, Section 7.2.5, and Section 7.2.7.  Some
   resource changes such as a link delay change might trigger
   preemption.  The rules of preemption remain unchanged, still based on
   holding priority.

7.4.7.  Flow Identification and Traffic Balance

   The following describe either the state of the art in flow
   identification and traffic balance or propose changes: Section 7.2.4,
   Section 7.2.5, Section 7.2.7, and Section 7.2.8.


8.  Security Considerations

   The security considerations for MPLS/GMPLS and for MPLS-TP are



Ning, et al.            Expires December 31, 2012              [Page 35]


Internet-Draft          Composite Link Framework               June 2012


   documented in [RFC5920] and [I-D.ietf-mpls-tp-security-framework].

   The types protocol extensions proposed in this framework document
   provide additional information about links, forwarding adjacencies,
   and LSP requirements.  The protocol semantics changes described in
   this framework document propose additional LSP constraints applied at
   path computation time and at LSP admission at midpoints LSR.  The
   additional information and constraints provide no additional security
   considerations beyond the security considerations already documented
   in [RFC5920] and [I-D.ietf-mpls-tp-security-framework].


9.  Acknowledgments

   Authors would like to thank Adrian Farrel, Fred Jounay, Yuji Kamite
   for his extensive comments and suggestions regarding early versions
   of this document, Ron Bonica, Nabil Bitar, Eric Gray, Lou Berger, and
   Kireeti Kompella for their reviews of early versions and great
   suggestions.

   Authors would like to thank Iftekhar Hussain for review and
   suggestions regarding recent versions of this document.

   In the interest of full disclosure of affiliation and in the interest
   of acknowledging sponsorship, past affiliations of authors are noted.
   Much of the work done by Ning So occurred while Ning was at Verizon.
   Much of the work done by Curtis Villamizar occurred while at
   Infinera.  Infinera continues to sponsor this work on a consulting
   basis.


10.  References

10.1.  Normative References

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

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, December 2001.

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              September 2003.

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



Ning, et al.            Expires December 31, 2012              [Page 36]


Internet-Draft          Composite Link Framework               June 2012


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

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, October 2008.

   [RFC5712]  Meyer, M. and JP. Vasseur, "MPLS Traffic Engineering Soft
              Preemption", RFC 5712, January 2010.

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

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374, September 2011.

   [RFC6391]  Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
              J., and S. Amante, "Flow-Aware Transport of Pseudowires
              over an MPLS Packet Switched Network", RFC 6391,
              November 2011.

10.2.  Informative References

   [DBP]      Bertsekas, D., "Dynamic Behavior of Shortest Path Routing
              Algorithms for Communication Networks", IEEE Trans. Auto.
              Control 1982.

   [I-D.ietf-mpls-entropy-label]
              Drake, J., Kompella, K., Yong, L., Amante, S., and W.
              Henderickx, "The Use of Entropy Labels in MPLS
              Forwarding", draft-ietf-mpls-entropy-label-01 (work in
              progress), October 2011.

   [I-D.ietf-mpls-explicit-resource-control-bundle]
              Zamfir, A., Ali, Z., and P. Dimitri, "Component Link
              Recording and Resource Control for TE Links",
              draft-ietf-mpls-explicit-resource-control-bundle-10 (work
              in progress), April 2011.

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



Ning, et al.            Expires December 31, 2012              [Page 37]


Internet-Draft          Composite Link Framework               June 2012


   [I-D.ietf-rtgwg-cl-requirement]
              Malis, A., Villamizar, C., McDysan, D., Yong, L., and N.
              So, "Requirements for MPLS Over a Composite Link",
              draft-ietf-rtgwg-cl-requirement-05 (work in progress),
              January 2012.

   [I-D.kompella-mpls-rsvp-ecmp]
              Kompella, K., "Multi-path Label Switched Paths Signaled
              Using RSVP-TE", draft-kompella-mpls-rsvp-ecmp-01 (work in
              progress), October 2011.

   [I-D.ospf-cc-stlv]
              Osborne, E., "Component and Composite Link Membership in
              OSPF", draft-ospf-cc-stlv-00 (work in progress),
              August 2011.

   [I-D.symmvo-rtgwg-cl-use-cases]
              Malis, A., Villamizar, C., McDysan, D., Yong, L., and N.
              So, "Composite Link USe Cases and Design Considerations",
              draft-symmvo-rtgwg-cl-use-cases-00 (work in progress),
              February 2012.

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

   [I-D.villamizar-mpls-tp-multipath-te-extn]
              Villamizar, C., "Multipath Extensions for MPLS Traffic
              Engineering",
              draft-villamizar-mpls-tp-multipath-te-extn-00 (work in
              progress), July 2011.

   [I-D.wang-ccamp-latency-te-metric]
              Fu, X., Betts, M., Wang, Q., McDysan, D., and A. Malis,
              "GMPLS extensions to communicate latency as a traffic
              engineering performance metric",
              draft-wang-ccamp-latency-te-metric-03 (work in progress),
              March 2011.

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

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

   [RFC2992]  Hopps, C., "Analysis of an Equal-Cost Multi-Path



Ning, et al.            Expires December 31, 2012              [Page 38]


Internet-Draft          Composite Link Framework               June 2012


              Algorithm", RFC 2992, November 2000.

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

   [RFC3468]  Andersson, L. and G. Swallow, "The Multiprotocol Label
              Switching (MPLS) Working Group decision on MPLS signaling
              protocols", RFC 3468, February 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.

   [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", RFC 4385, February 2006.

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, August 2006.

   [RFC4928]  Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
              Cost Multipath Treatment in MPLS Networks", BCP 128,
              RFC 4928, June 2007.

   [RFC5151]  Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain
              MPLS and GMPLS Traffic Engineering -- Resource Reservation
              Protocol-Traffic Engineering (RSVP-TE) Extensions",
              RFC 5151, February 2008.

   [RFC5152]  Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
              Path Computation Method for Establishing Inter-Domain
              Traffic Engineering (TE) Label Switched Paths (LSPs)",
              RFC 5152, February 2008.

   [RFC5316]  Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
              Support of Inter-Autonomous System (AS) MPLS and GMPLS
              Traffic Engineering", RFC 5316, December 2008.

   [RFC5392]  Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
              Support of Inter-Autonomous System (AS) MPLS and GMPLS
              Traffic Engineering", RFC 5392, January 2009.

   [RFC5441]  Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A
              Backward-Recursive PCE-Based Computation (BRPC) Procedure
              to Compute Shortest Constrained Inter-Domain Traffic
              Engineering Label Switched Paths", RFC 5441, April 2009.



Ning, et al.            Expires December 31, 2012              [Page 39]


Internet-Draft          Composite Link Framework               June 2012


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

   [RFC5921]  Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
              Berger, "A Framework for MPLS in Transport Networks",
              RFC 5921, July 2010.


Authors' Addresses

   So Ning
   Tata Communications

   Email: ning.so@tatacommunications.com


   Dave McDysan
   Verizon
   22001 Loudoun County PKWY
   Ashburn, VA  20147

   Email: dave.mcdysan@verizon.com


   Eric Osborne
   Cisco

   Email: eosborne@cisco.com


   Lucy Yong
   Huawei USA
   5340 Legacy Dr.
   Plano, TX  75025

   Phone: +1 469-277-5837
   Email: lucy.yong@huawei.com


   Curtis Villamizar
   Outer Cape Cod Network Consulting

   Email: curtis@occnc.com








Ning, et al.            Expires December 31, 2012              [Page 40]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/