draft-ietf-rtgwg-cl-requirement-16.txt   rfc7226.txt 
RTGWG C. Villamizar, Ed. Internet Engineering Task Force (IETF) C. Villamizar, Ed.
Internet-Draft OCCNC, LLC Request for Comments: 7226 OCCNC, LLC
Intended status: Informational D. McDysan, Ed. Category: Informational D. McDysan, Ed.
Expires: August 10, 2014 Verizon ISSN: 2070-1721 Verizon
S. Ning S. Ning
Tata Communications Tata Communications
A. Malis A. Malis
Huawei Huawei
L. Yong L. Yong
Huawei USA Huawei USA
February 06, 2014 May 2014
Requirements for Advanced Multipath in MPLS Networks Requirements for Advanced Multipath in MPLS Networks
draft-ietf-rtgwg-cl-requirement-16
Abstract Abstract
This document provides a set of requirements for Advanced Multipath This document provides a set of requirements for Advanced Multipath
in MPLS Networks. in MPLS networks.
Advanced Multipath is a formalization of multipath techniques Advanced Multipath is a formalization of multipath techniques
currently in use in IP and MPLS networks and a set of extensions to currently in use in IP and MPLS networks and a set of extensions to
existing multipath techniques. existing multipath techniques.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on August 10, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7226.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6 3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6
3.1. Availability, Stability and Transient Response . . . . . 6 3.1. Availability, Stability, and Transient Response . . . . . 6
3.2. Component Links Provided by Lower Layer Networks . . . . 8 3.2. Component Links Provided by Lower-Layer Networks . . . . 7
3.3. Component Links with Different Characteristics . . . . . 8 3.3. Component Links with Different Characteristics . . . . . 8
3.4. Considerations for Bidirectional Client LSP . . . . . . . 9 3.4. Considerations for Bidirectional Client LSP . . . . . . . 9
3.5. Multipath Load Balancing Dynamics . . . . . . . . . . . . 10 3.5. Multipath Load-Balancing Dynamics . . . . . . . . . . . . 10
4. General Requirements for Protocol Solutions . . . . . . . . . 12 4. General Requirements for Protocol Solutions . . . . . . . . . 12
5. Management Requirements . . . . . . . . . . . . . . . . . . . 13 5. Management Requirements . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
There is often a need to provide large aggregates of bandwidth that There is often a need to provide large aggregates of bandwidth that
are best provided using parallel links between routers or carrying are best provided using parallel links between routers or carrying
traffic over multiple MPLS Label Switched Paths (LSPs). In core traffic over multiple MPLS Label Switched Paths (LSPs). In core
networks there is often no alternative since the aggregate capacities networks, there is often no alternative since the aggregate
of core networks today far exceed the capacity of a single physical capacities of core networks today far exceed the capacity of a single
link or single packet processing element. physical link or a single packet-processing element.
The presence of parallel links, with each link potentially comprised The presence of parallel links, with each link potentially comprised
of multiple layers has resulted in additional requirements. Certain of multiple layers, has resulted in additional requirements. Certain
services may benefit from being restricted to a subset of the services may benefit from being restricted to a subset of the
component links or a specific component link, where component link component links or a specific component link, where component link
characteristics, such as latency, differ. Certain services require characteristics, such as latency, differ. Certain services require
that an LSP be treated as atomic and avoid reordering. Other that an LSP be treated as atomic and avoid reordering. Other
services will continue to require only that reordering not occur services will continue to require only that reordering not occur
within a flow as is current practice. within a flow as is current practice.
Numerous forms of multipath exist today including MPLS Link Bundling Numerous forms of multipath exist today, including MPLS Link Bundling
[RFC4201], Ethernet Link Aggregation [IEEE-802.1AX], and various [RFC4201], Ethernet Link Aggregation [IEEE-802.1AX], and various
forms of Equal Cost Multipath (ECMP) such as for OSPF ECMP, IS-IS forms of Equal Cost Multipath (ECMP) such as for OSPF ECMP, IS-IS
ECMP, and BGP ECMP. Refer to the Appendices in ECMP, and BGP ECMP. Refer to the appendices in [USE-CASES] for a
[I-D.ietf-rtgwg-cl-use-cases] for a description of existing description of existing techniques and a set of references.
techniques and a set of references.
The purpose of this document is to clearly enumerate a set of The purpose of this document is to clearly enumerate a set of
requirements related to the protocols and mechanisms that provide requirements related to the protocols and mechanisms that provide
MPLS based Advanced Multipath. The intent is to first provide a set MPLS-based Advanced Multipath. The intent is to first provide a set
of functional requirements, in Section 3, that are as independent as of functional requirements, in Section 3, that are as independent as
possible of protocol specifications . A set of general protocol possible of protocol specifications. A set of general protocol
requirements are defined in Section 4. A set of network management requirements are defined in Section 4. A set of network management
requirements are defined in Section 5. requirements are defined in Section 5.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in [RFC2119].
Any statement which requires the solution to support some new Any statement that requires the solution to support some new
functionality through use of [RFC2119] keywords should be interpreted functionality through use of [RFC2119] keywords should be interpreted
as follows. The implementation either MUST or SHOULD support the new as follows. The implementation either MUST or SHOULD support the new
functionality depending on the use of either MUST or SHOULD in the functionality, depending on the use of either MUST or SHOULD in the
requirements statement. The implementation SHOULD in most or all requirements statement. The implementation SHOULD, in most or all
cases allow any new functionality to be individually enabled or cases, allow any new functionality to be individually enabled or
disabled through configuration. A service provider or other disabled through configuration. A service provider or other
deployment MAY enable or disable any feature in their network, deployment MAY enable or disable any feature in their network,
subject to implementation limitations on sets of features which can subject to implementation limitations on sets of features that can be
be disabled. disabled.
2. Definitions 2. Definitions
Multipath Multipath
The term multipath includes all techniques in which The term "multipath" includes all techniques in which:
1. Traffic can take more than one path from one node to a 1. Traffic can take more than one path from one node to a
destination. destination.
2. Individual packets take one path only. Packets are not 2. Individual packets take one path only. Packets are not
subdivided and reassembled at the receiving end. subdivided and reassembled at the receiving end.
3. Packets are not resequenced at the receiving end. 3. Packets are not resequenced at the receiving end.
4. The paths may be: 4. The paths may be:
a. parallel links between two nodes, or a. parallel links between two nodes,
b. specific paths across a network to a destination node, or b. specific paths across a network to a destination node, or
c. links or paths to an intermediate node used to reach a c. links or paths to an intermediate node used to reach a
common destination. common destination.
The paths need not have equal capacity. The paths may or may not The paths need not have equal capacity. The paths may or may not
have equal cost in a routing protocol. have equal cost in a routing protocol.
Advanced Multipath Advanced Multipath
Advanced Multipath is a formalization of multipath techniques Advanced Multipath is a formalization of multipath techniques
that meets the requirements defined in this document. A key that meets the requirements defined in this document. A key
capability of Advanced Multipath is the support of non- capability of Advanced Multipath is the support of non-
homogeneous component links. homogeneous component links.
Advanced Multipath Group (AMG) Advanced Multipath Group (AMG)
An Advanced Multipath Group (AMG) is a collection of component An AMG is a collection of component links where Advanced
links where Advanced Multipath techniques are applied. Multipath techniques are applied.
Composite Link Composite Link
The term Composite Link had been a registered trademark of Avici The term "composite link" had been a registered trademark of
Systems, but was abandoned in 2007. The term composite link is Avici Systems, but it was abandoned in 2007. The term "composite
now defined by the ITU-T in [ITU-T.G.800]. The ITU-T definition link" is now defined by the ITU-T in [ITU-T.G.800]. The ITU-T
includes multipath as defined here, plus inverse multiplexing definition includes multipath as defined here, plus inverse
which is explicitly excluded from the definition of multipath. multiplexing, which is explicitly excluded from the definition of
multipath.
Inverse Multiplexing Inverse Multiplexing
Inverse multiplexing is another method of sending traffic over Inverse multiplexing is another method of sending traffic over
multiple links. Inverse multiplexing either transmits whole multiple links. Inverse multiplexing either transmits whole
packets and resequences the packets at the receiving end or packets and resequences the packets at the receiving end or
subdivides packets and reassembles the packets at the receiving subdivides packets and reassembles the packets at the receiving
end. Inverse multiplexing requires that all packets be handled end. Inverse multiplexing requires that all packets be handled
by a common egress packet processing element and is therefore not by a common egress packet processing element and is, therefore,
useful for very high bandwidth applications. not useful for very high-bandwidth applications.
Component Link Component Link
The ITU-T definition of composite link in [ITU-T.G.800] and the The ITU-T definition of composite link in [ITU-T.G.800] and the
IETF definition of link bundling in [RFC4201] both refer to an IETF definition of link bundling in [RFC4201] both refer to an
individual link in the composite link or link bundle as a individual link in the composite link or link bundle as a
component link. The term component link is applicable to all component link. The term "component link" is applicable to all
forms of multipath. The IEEE uses the term member rather than forms of multipath. The IEEE uses the term "member" rather than
component link in Ethernet Link Aggregation [IEEE-802.1AX]. "component link" in Ethernet Link Aggregation [IEEE-802.1AX].
Client Layer Client Layer
A client layer is the layer immediately above a server layer. A client layer is the layer immediately above a server layer.
Server Layer Server Layer
A server layer is the layer immediately below a client layer. A server layer is the layer immediately below a client layer.
Higher Layers Higher Layers
Relative to a particular layer, a client layer and any layer Relative to a particular layer, a client layer and any layer
above that is considered a higher layer. Upper layer is above that is considered a higher layer. Upper layer is
synonymous with higher layer. synonymous with higher layer.
Lower Layers Lower Layers
Relative to a particular layer, a server layer and any layer Relative to a particular layer, a server layer and any layer
below that is considered a lower layer. below that is considered a lower layer.
Client LSP Client LSP
A client LSP is an LSP which has been set up over one or more A client LSP is an LSP that has been set up over one or more
lower layers. In the context of this discussion, one type of lower layers. In the context of this discussion, one type of
client LSP is a LSP which has been set up over an AMG. client LSP is an LSP that has been set up over an AMG.
Flow Flow
A sequence of packets that should be transferred in order on one A sequence of packets that should be transferred in order on one
component link of a multipath. component link of a multipath.
Flow Identification Flow Identification
The label stack and other information that uniquely identifies a The label stack and other information that uniquely identifies a
flow. Other information in flow identification may include an IP flow. Other information in flow identification may include an IP
header, pseudowire (PW) control word, Ethernet MAC address, etc. header, pseudowire (PW) control word, Ethernet Media Access
Note that a client LSP may contain one or more Flows or a client Control (MAC) address, etc. Note that a client LSP may contain
LSP may be equivalent to a Flow. Flow identification is used to one or more flows, or a client LSP may be equivalent to a flow.
locally select a component link, or a path through the network Flow identification is used to locally select a component link or
toward the destination. a path through the network toward the destination.
Load Balance Load Balance
Load split, load balance, or load distribution refers to Load split, load balance, or load distribution refers to
subdividing traffic over a set of component links such that load subdividing traffic over a set of component links such that load
is fairly evenly distributed over the set of component links and is fairly evenly distributed over the set of component links and
certain packet ordering requirements are met. Some existing certain packet ordering requirements are met. Some existing
techniques better achieve these objectives than others. techniques better achieve these objectives than others.
Performance Objective Performance Objective
Numerical values for performance measures, principally Numerical values for performance measures: principally
availability, latency, and delay variation. Performance availability, latency, and delay variation. Performance
objectives may be related to Service Level Agreements (SLA) as objectives may be related to Service Level Agreements (SLAs) as
defined in RFC2475 or may be strictly internal. Performance defined in [RFC2475] or may be strictly internal. Performance
objectives may span links, edge-to-edge, or end-to-end. objectives may span links from edge to edge or from end to end.
Performance objectives may span one provider or may span multiple Performance objectives may span one provider or multiple
providers. providers.
A Component Link may be a point-to-point physical link (where a A component link may be a point-to-point physical link (where a
"physical link" includes one or more link layer plus a physical "physical link" includes one or more link layers, plus a physical
layer) or a logical link that preserves ordering in the steady state. layer) or a logical link that preserves ordering in the steady state.
A component link may have transient out of order events, but such A component link may have transient out-of-order events, but such
events must not exceed the network's Performance Objectives. For events must not exceed the network's performance objectives. For
example, a component link may be comprised of any supportable example, a component link may be comprised of any supportable
combination of link layers over a physical layer or over logical sub- combination of link layers over a physical layer or over logical sub-
layers, including those providing physical layer emulation, or over layers -- including those providing physical-layer emulation -- or
MPLS server layer LSP. over MPLS server-layer LSP.
The ingress and egress of a multipath may be midpoint LSRs with The ingress and egress of a multipath may be midpoint LSRs with
respect to a given client LSP. A midpoint LSR does not participate respect to a given client LSP. A midpoint LSR does not participate
in the signaling of any clients of the client LSP. Therefore, in in the signaling of any clients of the client LSP. Therefore, in
general, multipath endpoints cannot determine requirements of clients general, multipath endpoints cannot determine requirements of clients
of a client LSP through participation in the signaling of the clients of a client LSP through participation in the signaling of the clients
of the client LSP. of the client LSP.
This document makes no statement on whether Advanced Multipath is This document makes no statement on whether Advanced Multipath is
itself a layer or whether an instance of AMG is itself a layer. This itself a layer or whether an instance of AMG is itself a layer. This
is to avoid engaging in long and pointless discussions about what is to avoid engaging in long and pointless discussions about what
consistitutes a proper layer. constitutes a proper layer.
The term Advanced Multipath is intended to be used within the context The term "Advanced Multipath" is intended to be used within the
of this document and the related documents, context described in this document and related documents, for
[I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and example, [USE-CASES] and [FRAMEWORK]. Other Advanced Multipath
any other related document. Other advanced multipath techniques may techniques may arise in the future. If the capabilities defined in
in the future arise. If the capabilities defined in this document this document become commonplace, they would no longer be considered
become commonplace, they would no longer be considered "advanced". "advanced". Use of the term "advanced multipath" outside this
Use of the term "advanced multipath" outside this document, if document, if referring to the term as defined here, should indicate
referring to the term as defined here, should indicate Advanced Advanced Multipath as defined by this document, citing the current
Multipath as defined by this document, citing the current document document name. If using another definition of "advanced multipath",
name. If using another definition of "advanced multipath", documents documents may optionally clarify that they are not using the term
may optionally clarify that they are not using the term "advanced "advanced multipath" as defined by this document if clarification is
multipath" as defined by this document if clarification is deemed deemed helpful.
helpful.
3. Functional Requirements 3. Functional Requirements
The Functional Requirements in this section are grouped in The functional requirements in this section are grouped in
subsections starting with the highest priority. subsections, starting with the highest priority.
3.1. Availability, Stability and Transient Response 3.1. Availability, Stability, and Transient Response
Limiting the period of unavailability in response to failures or In addition to maintaining stability, limiting the period of
transient events is extremely important as well as maintaining unavailability in response to failures or transient events is
stability. extremely important.
FR#1 The transient period between some service disrupting event and FR#1 The transient period between some service disrupting event and
the convergence of the routing and/or signaling protocols MUST the convergence of the routing and/or signaling protocols MUST
occur within a time frame specified by Performance Objective occur within a time frame specified by performance objective
values. values.
FR#2 An AMG MAY be announced in conjunction with detailed parameters FR#2 An AMG MAY be announced in conjunction with detailed parameters
about its component links, such as bandwidth and latency. The about its component links, such as bandwidth and latency. The
AMG SHALL behave as a single IGP adjacency. AMG SHALL behave as a single IGP adjacency.
FR#3 The solution SHALL provide a means to summarize some routing FR#3 The solution SHALL provide a means to summarize some routing
advertisements regarding the characteristics of an AMG such that advertisements regarding the characteristics of an AMG such
the updated protocol mechanisms maintain convergence times within that the updated protocol mechanisms maintain convergence times
the timeframe needed to meet or not significantly exceed existing within the time frame needed to meet or not significantly
Performance Objective for convergence on the same network or exceed existing performance objectives for convergence on the
convergence on a network with a similar topology. same network or convergence on a network with a similar
topology.
FR#4 The solution SHALL ensure that restoration operations happen FR#4 The solution SHALL ensure that restoration operations happen
within the timeframe needed to meet existing Performance within the time frame needed to meet existing performance
Objective for restoration time on the same network or restoration objectives for restoration time on the same network or
time on a network with a similar topology. restoration time on a network with a similar topology.
FR#5 The solution shall provide a mechanism to select a set of paths FR#5 The solution shall provide a mechanism to select a set of paths
for an LSP across a network in such a way that flows within the for an LSP across a network in such a way that flows within the
LSP are distributed across the set of paths while meeting all of LSP are distributed across the set of paths, while meeting all
the other requirements stated above. The solution SHOULD work in of the other requirements stated above. The solution SHOULD
a manner similar to existing multipath techniques except as work in a manner similar to existing multipath techniques,
necessary to accommodate Advanced Multipath requirements. except as necessary to accommodate Advanced Multipath
requirements.
FR#6 If extensions to existing protocols are specified and/or new FR#6 If extensions to existing protocols are specified and/or new
protocols are defined, then the solution SHOULD provide a means protocols are defined, then the solution SHOULD provide a means
for a network operator to migrate an existing deployment in a for a network operator to migrate an existing deployment in a
minimally disruptive manner. minimally disruptive manner.
FR#7 Any load balancing solutions MUST NOT oscillate. Some change FR#7 Any load-balancing solutions MUST NOT oscillate. Some change
in path MAY occur. The solution MUST ensure that path stability in path MAY occur. The solution MUST ensure that path
and traffic reordering continue to meet Performance Objective on stability and traffic reordering continue to meet performance
the same network or on a network with a similar topology. Since objectives on the same network or on a network with a similar
oscillation may cause reordering, there MUST be means to control topology. Since oscillation may cause reordering, there MUST
the frequency of changing the component link over which a flow is be means to control the frequency of changing the component
placed. link over which a flow is placed.
FR#8 Management and diagnostic protocols MUST be able to operate FR#8 Management and diagnostic protocols MUST be able to operate
over AMGs. over AMGs.
Existing scaling techniques used in MPLS networks apply to MPLS Existing scaling techniques used in MPLS networks apply to MPLS
networks which support Advanced Multipath. Scalability and stability networks that support Advanced Multipath. Scalability and stability
are covered in more detail in [I-D.ietf-rtgwg-cl-framework]. are covered in more detail in [FRAMEWORK].
3.2. Component Links Provided by Lower Layer Networks 3.2. Component Links Provided by Lower-Layer Networks
A component link may be supported by a lower layer network. For A component link may be supported by a lower-layer network. For
example, the lower layer may be a circuit switched network or another example, the lower layer may be a circuit-switched network or another
MPLS network (e.g., MPLS-TP)). The lower layer network may change MPLS network (e.g., MPLS Transport Profile (MPLS-TP)). The lower-
the latency (and/or other performance parameters) seen by the client layer network may change the latency (and/or other performance
layer. Currently, there is no protocol for the lower layer network parameters) seen by the client layer. Currently, there is no
to inform the higher layer network of a change in a performance protocol for the lower-layer network to inform the higher-layer
parameter. Communication of the latency performance parameter is a network of a change in a performance parameter. Communication of the
very important requirement. Communication of other performance latency performance parameter is a very important requirement.
parameters (e.g., delay variation) is desirable. Communication of other performance parameters (e.g., delay variation)
is desirable.
FR#9 The solution SHALL specify a protocol means to allow a server FR#9 The solution SHALL specify a protocol means to allow a server-
layer network to communicate latency to the client layer network. layer network to communicate latency to the client-layer
network.
FR#10 The precision of latency reporting SHOULD be configurable. A FR#10 The precision of latency reporting SHOULD be configurable. A
reasonable default SHOULD be provided. Implementations SHOULD reasonable default SHOULD be provided. Implementations SHOULD
support precision of at least 10% of the one way latencies for support precision of at least 10% of the one-way latencies for
latency of 1 msec or more. latency of 1 msec or more.
The intent is to measure the predominant latency in uncongested The intent is to measure the predominant latency in uncongested
service provider networks, where geographic delay dominates and is on service-provider networks, where geographic delay dominates and is on
the order of milliseconds or more. The argument for including the order of milliseconds or more. The argument for including
queuing delay is that it reflects the delay experienced by queuing delay is that it reflects the delay experienced by
applications. The argument against including queuing delay is that applications. The argument against including queuing delay is that
if used in routing decisions it can result in routing instability. if used in routing decisions, it can result in routing instability.
This tradeoff is discussed in detail in This trade-off is discussed in detail in [FRAMEWORK].
[I-D.ietf-rtgwg-cl-framework].
3.3. Component Links with Different Characteristics 3.3. Component Links with Different Characteristics
As one means to provide high availability, network operators deploy a As one means to provide high availability, network operators deploy a
topology in the MPLS network using lower layer networks that have a topology in the MPLS network using lower-layer networks that have a
certain degree of diversity at the lower layer(s). Many techniques certain degree of diversity at the lower layer(s). Many techniques
have been developed to balance the distribution of flows across have been developed to balance the distribution of flows across
component links that connect the same pair of nodes or ultimately component links that connect the same pair of nodes or ultimately
lead to a common destination. lead to a common destination.
FR#11 In requirements that follow in this document the word FR#11 In the requirements that follow in this document, the word
"indicate" is used where information may be provided by either "indicate" is used where information may be provided by either
the combination of link state IGP advertisement and MPLS LSP the combination of link state IGP advertisement and MPLS LSP
signaling or via management plane protocols. In later documents signaling or via management plane protocols. In later
providing framework and protocol definitions both signaling and documents, providing framework and protocol definitions, both
management plane mechanisms MUST be defined. signaling and management plane mechanisms, MUST be defined.
FR#12 The solution SHALL provide a means for the client layer to FR#12 The solution SHALL provide a means for the client layer to
indicate a requirement that a client LSP will traverse a indicate a requirement that a client LSP will traverse a
component link with the minimum latency value. This will provide component link with the minimum-latency value. This will
a means by which minimum latency Performance Objectives of flows provide a means by which minimum latency performance objectives
within the client LSP can be supported. of flows within the client LSP can be supported.
FR#13 The solution SHALL provide a means for the client layer to FR#13 The solution SHALL provide a means for the client layer to
indicate a requirement that a client LSP will traverse a indicate a requirement that a client LSP will traverse a
component link with a maximum acceptable latency value as component link with a maximum acceptable latency value as
specified by protocol. This will provide a means by which specified by protocol. This will provide a means by which
bounded latency Performance Objectives of flows within the client bounded latency performance objectives of flows within the
LSP can be supported. client LSP can be supported.
FR#14 The solution SHALL provide a means for the client layer to FR#14 The solution SHALL provide a means for the client layer to
indicate a requirement that a client LSP will traverse a indicate a requirement that a client LSP will traverse a
component link with a maximum acceptable delay variation value as component link with a maximum acceptable delay variation value
specified by protocol. as specified by protocol.
The above set of requirements apply to component links with different The above set of requirements applies to component links with
characteristics regardless as to whether those component links are different characteristics, regardless of whether those component
provided by parallel physical links between nodes or provided by sets links are provided by parallel physical links between nodes or by
of paths across a network provided by server layer LSP. sets of paths across a network provided by a server-layer LSP.
Allowing multipath to contain component links with different Allowing multipath to contain component links with different
characteristics can improve the overall load balance and can be characteristics can improve the overall load balance and can be
accomplished while still accommodating the more strict requirements accomplished while still accommodating the more strict requirements
of a subset of client LSP. of a subset of client LSP.
3.4. Considerations for Bidirectional Client LSP 3.4. Considerations for Bidirectional Client LSP
Some client LSP MAY require a path bound to a specific set of Some client LSPs MAY require a path bound to a specific set of
component links. This case is most likely to occur in bidirectional component links. This case is most likely to occur in a
client LSP where time synchronization protocols such as Precision bidirectional client LSP where time synchronization protocols such as
Time Protocol (PTP) or Network Time Protocol (NTP) are carried, or in the Precision Time Protocol (PTP) or the Network Time Protocol (NTP)
any other case where symmetric delay is highly desirable. There may are carried or in any other case where symmetric delay is highly
be other uses of this capability. desirable. There may be other uses of this capability.
Other client LSP may only require that the LSP path serve the same Other client LSPs may only require that the LSP serve the same set of
set of nodes in both directions. This is necessary if protocols are nodes in both directions. This is necessary if protocols are carried
carried which make use of the reverse direction of the LSP as a back that make use of the reverse direction of the LSP as a back channel
channel in cases such OAM protocols using IPv4 Time to Live (TTL) or in cases such Operations, Administration, and Maintenance (OAM)
IPv4 Hop Limit to monitor or diagnose the underlying path. There may protocols using IPv4 Time to Live (TTL) or IPv4 Hop Limit to monitor
be other uses of this capability. or diagnose the underlying path. There may be other uses of this
capability.
FR#15 The solution SHALL provide a means for the client layer to FR#15 The solution SHALL provide a means for the client layer to
indicate a requirement that a client LSP be bound to a particular indicate a requirement that a client LSP be bound to a
component link within an AMG. If this option is not exercised, particular component link within an AMG. If this option is not
then a client LSP that is carried over an AMG may be bound to any exercised, then a client LSP that is carried over an AMG may be
component link or set of component links matching all other bound to any component link or set of component links matching
signaled requirements, and different directions of a all other signaled requirements, and different directions of a
bidirectional client LSP can be bound to different component bidirectional client LSP can be bound to different component
links. links.
FR#16 The solution MUST support a means for the client layer to FR#16 The solution MUST support a means for the client layer to
indicate a requirement that for a specific co-routed indicate a requirement that for a specific co-routed
bidirectional client LSP both directions of the co-routed bidirectional client LSP, both directions of the co-routed
bidirectional client LSP MUST be bound to the same set of nodes. bidirectional client LSP MUST be bound to the same set of
nodes.
FR#17 A client LSP which is bound to a specific component link SHOULD FR#17 A client LSP that is bound to a specific component link SHOULD
NOT exceed the capacity of a single component link. This is NOT exceed the capacity of a single component link. This is
inherent in the assumption that a network SHOULD NOT operate in a inherent in the assumption that a network SHOULD NOT operate in
congested state if congestion is avoidable. a congested state if congestion is avoidable.
For some large bidirectional client LSP it may not be necessary (or For some large bidirectional client LSPs, it may not be necessary (or
possible due to the client LSP capacity) to bind the LSP to a common possible due to the client LSP capacity) to bind the LSP to a common
set of component links but may be necessary or desirable to constrain set of component links, but it may be necessary or desirable to
the path taken by the LSP to the same set of nodes in both constrain the path taken by the LSP to the same set of nodes in both
directions. Without an entirely new and highly dynamic protocol, it directions. Without an entirely new and highly dynamic protocol, it
is not feasible to constrain such an bidirectional client LSP to take is not feasible to constrain such a bidirectional client LSP from
multiple paths and coordinate load balance on each side to keep both taking multiple paths and coordinating load balance on each side in
directions of flows within such an LSP on common paths. order to keep both directions of flows within such an LSP on common
paths.
3.5. Multipath Load Balancing Dynamics 3.5. Multipath Load-Balancing Dynamics
Multipath load balancing attempts to keep traffic levels on all Multipath load balancing attempts to keep traffic levels on all
component links below congestion levels if possible and preferably component links below congestion levels if possible and preferably
well balanced. Load balancing is minimally disruptive (see well balanced. Load balancing is minimally disruptive (see the
discussion below this section's list of requirements). The discussion below this section's list of requirements). The
sensitivity to these minimal disruptions of traffic flows within sensitivity to these minimal disruptions of traffic flows within a
specific client LSP needs to be considered. specific client LSP needs to be considered.
FR#18 The solution SHALL provide a means for the client layer to FR#18 The solution SHALL provide a means for the client layer to
indicate a requirement that a specific client LSP MUST NOT be indicate a requirement that a specific client LSP MUST NOT be
split across multiple component links. split across multiple component links.
FR#19 The solution SHALL provide a means local to a node that FR#19 The solution SHALL provide a means local to a node that
automatically distributes flows across the component links in the automatically distributes flows across the component links in
AMG such that Performance Objectives are met as described in the AMG such that performance objectives are met, as described
prior requirements in Section 3.3. in the prior requirements in Section 3.3.
FR#20 The solution SHALL measure traffic flows or groups of traffic FR#20 The solution SHALL measure traffic flows or groups of traffic
flows and dynamically select the component link on which to place flows and dynamically select the component link on which to
this traffic in order to balance the load so that no component place this traffic in order to balance the load so that no
link in the AMG between a pair of nodes is overloaded. component link in the AMG between a pair of nodes is
overloaded.
FR#21 When a traffic flow is moved from one component link to another FR#21 When a traffic flow is moved from one component link to another
in the same AMG between a set of nodes, it MUST be done so in a in the same AMG between a set of nodes, it MUST be done so in a
minimally disruptive manner. minimally disruptive manner.
FR#22 Load balancing MAY be used during sustained low traffic periods FR#22 Load balancing MAY be used during sustained low-traffic periods
to reduce the number of active component links for the purpose of to reduce the number of active component links for the purpose
power reduction. of power reduction.
FR#23 The solution SHALL provide a means for the client layer to FR#23 The solution SHALL provide a means for the client layer to
indicate a requirement that a specific client LSP contains indicate a requirement that a specific client LSP contains
traffic whose frequency of component link change due to load traffic whose frequency of component link change due to load
balancing needs to be bounded by a specific value. The solution balancing needs to be bounded by a specific value. The
MUST provide a means to bound the frequency of component link solution MUST provide a means to bound the frequency of a
change due to load balancing for subsets of traffic flow on AMGs. component link change due to load balancing for subsets of
traffic flow on AMGs.
FR#24 The solution SHALL provide a means to distribute traffic flows FR#24 The solution SHALL provide a means to distribute traffic flows
from a single client LSP across multiple component links to from a single client LSP across multiple component links to
handle at least the case where the traffic carried in an client handle at least the case where the traffic carried in a client
LSP exceeds that of any component link in the AMG. LSP exceeds that of any component link in the AMG.
FR#25 The solution SHOULD support the use case where an AMG itself is FR#25 The solution SHOULD support the use case where an AMG itself is
a component link for a higher order AMG. For example, an AMG a component link for a higher order AMG. For example, an AMG
comprised of MPLS-TP bi-directional tunnels viewed as logical comprised of MPLS-TP bidirectional tunnels viewed as logical
links could then be used as a component link in yet another AMG links could then be used as a component link in yet another AMG
that connects MPLS routers. that connects MPLS routers.
FR#26 If the total demand offered by traffic flows exceeds the FR#26 If the total demand offered by traffic flows exceeds the
capacity of the AMG, the solution SHOULD define a means to cause capacity of the AMG, the solution SHOULD define a means to
some client LSP to move to an alternate set of paths that are not cause some client LSPs to move to an alternate set of paths
congested. These "preempted LSP" may not be restored if there is that are not congested. These "preempted LSPs" may not be
no uncongested path in the network. restored if there is no uncongested path in the network.
A minimally disruptive change implies that as little disruption as is A minimally disruptive change implies that as little disruption as is
practical occurs. Such a change can be achieved with zero packet practical occurs. Such a change can be achieved with zero packet
loss. A delay discontinuity may occur, which is considered to be a loss. A delay discontinuity may occur, which is considered to be a
minimally disruptive event for most services if this type of event is minimally disruptive event for most services if this type of event is
sufficiently rare. A delay discontinuity is an example of a sufficiently rare. A delay discontinuity is an example of a
minimally disruptive behavior corresponding to current techniques. minimally disruptive behavior corresponding to current techniques.
A delay discontinuity is an isolated event which may greatly exceed A delay discontinuity is an isolated event that may greatly exceed
the normal delay variation (jitter). A delay discontinuity has the the normal delay variation (jitter). A delay discontinuity has the
following effect. When a flow is moved from a current link to a following effect. When a flow is moved from a current link to a
target link with lower latency, reordering can occur. When a flow is target link with lower latency, reordering can occur. When a flow is
moved from a current link to a target link with a higher latency, a moved from a current link to a target link with a higher latency, a
time gap can occur. Some flows (e.g., timing distribution, PW time gap can occur. Some flows (e.g., timing distribution and PW
circuit emulation) are quite sensitive to these effects. A delay circuit emulation) are quite sensitive to these effects. A delay
discontinuity can also cause a jitter buffer underrun or overrun discontinuity can also cause a jitter buffer underrun or overrun,
affecting user experience in real time voice services (causing an affecting user experience in real-time voice services (causing an
audible click). These sensitivities may be specified in a audible click). These sensitivities may be specified in a
Performance Objective. performance objective.
As with any load balancing change, a change initiated for the purpose As with any load-balancing change, a change initiated for the purpose
of power reduction may be minimally disruptive. Typically the of power reduction may be minimally disruptive. Typically, the
disruption is limited to a change in delay characteristics and the disruption is limited to a change in delay characteristics and the
potential for a very brief period with traffic reordering. The potential for a very brief period with traffic reordering. When
network operator when configuring a network for power reduction configuring a network for power reduction, the network operator
should weigh the benefit of power reduction against the disadvantage should weigh the benefit of power reduction against the disadvantage
of a minimal disruption. of a minimal disruption.
4. General Requirements for Protocol Solutions 4. General Requirements for Protocol Solutions
This section defines requirements for protocol specification used to This section defines requirements for protocol specifications used to
meet the functional requirements specified in Section 3. meet the functional requirements specified in Section 3.
GR#1 The solution SHOULD extend existing protocols wherever GR#1 The solution SHOULD extend existing protocols wherever
possible, developing a new protocol only where doing so adds a possible, developing a new protocol only where doing so adds a
significant set of capabilities. significant set of capabilities.
GR#2 A solution SHOULD extend LDP capabilities to meet functional GR#2 A solution SHOULD extend LDP capabilities to meet functional
requirements. This MUST be accomplished without defining LDP requirements. This MUST be accomplished without defining LDP
Traffic Engineering (TE) methods as decided in [RFC3468]). Traffic Engineering (TE) methods as decided in [RFC3468].
GR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported GR#3 Coexistence of LDP- and RSVP-TE-signaled LSPs MUST be supported
on an AMG. Function requirements SHOULD, where possible, be on an AMG. Function requirements SHOULD, where possible, be
accommodated in a manner that supports LDP signaled LSP, RSVP accommodated in a manner that supports LDP-signaled LSP, RSVP-
signaled LSP, and LSP set up using management plane mechanisms. signaled LSP, and LSP setup using management plane mechanisms.
GR#4 When the nodes connected via an AMG are in the same routing GR#4 When the nodes connected via an AMG are in the same routing
domain, the solution MAY define extensions to the IGP. domain, the solution MAY define extensions to the IGP.
GR#5 When the nodes are connected via an AMG are in different MPLS GR#5 When the nodes are connected via an AMG are in different MPLS
network topologies, the solution SHALL NOT rely on extensions to network topologies, the solution SHALL NOT rely on extensions
the IGP. to the IGP.
GR#6 The solution SHOULD support AMG IGP advertisement that results GR#6 The solution SHOULD support AMG IGP advertisement that results
in convergence time better than that of advertising the in convergence time better than that of advertising the
individual component links. The solution SHALL be designed so individual component links. The solution SHALL be designed so
that it represents the range of capabilities of the individual that it represents the range of capabilities of the individual
component links such that functional requirements are met, and component links such that functional requirements are met, and
also minimizes the frequency of advertisement updates which may it also minimizes the frequency of advertisement updates that
cause IGP convergence to occur. may cause IGP convergence to occur.
Examples of advertisement update triggering events to be Examples of advertisement-update-triggering events to be
considered include: client LSP establishment/release, changes in considered include: client LSP establishment/release, changes
component link characteristics (e.g., latency, up/down state), in component-link characteristics (e.g., latency and up/down
and/or bandwidth utilization. state), and/or bandwidth utilization.
GR#7 When a worst case failure scenario occurs, the number of RSVP- GR#7 When a worst-case failure scenario occurs, the number of
TE client LSPs to be resignaled will cause a period of RSVP-TE client LSPs to be resignaled will cause a period of
unavailability as perceived by users. The resignaling time of unavailability as perceived by users. The resignaling time of
the solution MUST support protocol mechanisms meeting existing the solution MUST support protocol mechanisms meeting existing
provider Performance Objective for the duration of unavailability provider performance objectives for the duration of
without significantly relaxing those existing Performance unavailability without significantly relaxing those existing
Objectives for the same network or for networks with similar performance objectives for the same network or for networks
topology. For example, the processing load due to IGP with similar topology. For example, the processing load due to
readvertisement MUST NOT increase significantly and the IGP readvertisement MUST NOT increase significantly, and the
resignaling time of the solution MUST NOT increase significantly resignaling time of the solution MUST NOT increase
as compared with current methods. significantly as compared with current methods.
5. Management Requirements 5. Management Requirements
MR#1 Management Plane MUST support polling of the status and MR#1 The Management Plane MUST support polling of the status and
configuration of an AMG and its individual component links and configuration of an AMG and its individual component links and
support notification of status change. support notification of status change.
MR#2 Management Plane MUST be able to activate or de-activate any MR#2 The Management Plane MUST be able to activate or deactivate any
component link in an AMG in order to facilitate operation component link in an AMG in order to facilitate operation
maintenance tasks. The routers at each end of an AMG MUST maintenance tasks. The routers at each end of an AMG MUST
redistribute traffic to move traffic from a de-activated link to redistribute traffic to move traffic from a deactivated link to
other component links based on the traffic flow TE criteria. other component links based on the traffic flow TE criteria.
MR#3 Management Plane MUST be able to configure a client LSP over an MR#3 The Management Plane MUST be able to configure a client LSP
AMG and be able to select a component link for the client LSP. over an AMG and be able to select a component link for the
client LSP.
MR#4 Management Plane MUST be able to trace which component link a MR#4 The Management Plane MUST be able to trace which component link
client LSP is assigned to and monitor individual component link a client LSP is assigned to and monitor individual component
and AMG performance. link and AMG performance.
MR#5 Management Plane MUST be able to verify connectivity over each MR#5 The Management Plane MUST be able to verify connectivity over
individual component link within an AMG. each individual component link within an AMG.
MR#6 Component link fault notification MUST be sent to the MR#6 Component link fault notification MUST be sent to the
management plane. management plane.
MR#7 AMG fault notification MUST be sent to the management plane and MR#7 AMG fault notification MUST be sent to the management plane and
MUST be distributed via link state message in the IGP. MUST be distributed via a link state message in the IGP.
MR#8 Management Plane SHOULD provide the means for an operator to MR#8 The Management Plane SHOULD provide the means for an operator
initiate an optimization process. to initiate an optimization process.
MR#9 An operator initiated optimization MUST be performed in a MR#9 An operator-initiated optimization MUST be performed in a
minimally disruptive manner as described in Section 3.5. minimally disruptive manner, as described in Section 3.5.
6. Acknowledgements 6. Acknowledgements
Frederic Jounay of France Telecom and Yuji Kamite of NTT Frederic Jounay of France Telecom and Yuji Kamite of NTT
Communications Corporation co-authored a version of this document. Communications Corporation coauthored a version of this document.
A rewrite of this document occurred after the IETF77 meeting. A rewrite of this document occurred after the IETF 77 meeting.
Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG chairs John Dimitri Papadimitriou, Lou Berger, Tony Li, the former WG Chairs John
Scuder and Alex Zinin, the current WG chair Alia Atlas, and others Scuder and Alex Zinin, the current WG Chair Alia Atlas, and others
provided valuable guidance prior to and at the IETF77 RTGWG meeting. provided valuable guidance prior to and at the IETF 77 RTGWG meeting.
Tony Li and John Drake have made numerous valuable comments on the Tony Li and John Drake have made numerous valuable comments on the
RTGWG mailing list that are reflected in versions following the RTGWG mailing list that are reflected in versions following the IETF
IETF77 meeting. 77 meeting.
Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG Iftekhar Hussain and Kireeti Kompella made comments on the RTGWG
mailing list after IETF82 that identified a new requirement. mailing list after the IETF 82 meeting that identified a new
Iftekhar Hussain made numerous valuable comments on the RTGWG mailing requirement. Iftekhar Hussain made numerous valuable comments on the
list that resulted in improvements to document clarity. RTGWG mailing list that resulted in improvements to the document's
clarity.
In the interest of full disclosure of affiliation and in the interest In the interest of full disclosure of affiliation and in the interest
of acknowledging sponsorship, past affiliations of authors are noted. of acknowledging sponsorship, past affiliations of authors are noted
Much of the work done by Ning So occurred while Ning was at Verizon. here. Much of the work done by Ning So and Andrew Malis occurred
Much of the work done by Curtis Villamizar occurred while at while they were at Verizon. Much of the work done by Curtis
Infinera. Much of the work done by Andy Malis occurred while Andy Villamizar occurred while he was at Infinera.
was at Verizon.
Tom Yu and Francis Dupont provided the SecDir and GenArt reviews Tom Yu and Francis Dupont provided the SecDir and GenArt reviews,
respectively. Both reviews provided useful comments. The current respectively. Both reviews provided useful comments. The current
wording of the security section is based on suggested wording from wording of the security section is based on suggested wording from
Tom Yu. Lou Berger provided the RtgDir review which resulted in the Tom Yu. Lou Berger provided the RtgDir review, which resulted in the
document being renamed and substantial clarification of terminology document being renamed and the substantial clarification of
and document wording, particularly in the Abstract, Introduction, and terminology and document wording, particularly in the Abstract,
Definitions sections. Introduction, and Definitions sections.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations 7. Security Considerations
The security considerations for MPLS/GMPLS and for MPLS-TP are The security considerations for MPLS/GMPLS and for MPLS-TP are
documented in [RFC5920] and [RFC6941]. This document does not impact documented in [RFC5920] and [RFC6941]. This document does not impact
the security of MPLS, GMPLS, or MPLS-TP. the security of MPLS, GMPLS, or MPLS-TP.
The additional information that this document requires does not The additional information that this document requires does not
provide significant additional value to an attacker beyond the provide significant additional value to an attacker beyond the
information already typically available from attacking a routing or information already typically available from attacking a routing or
signaling protocol. If the requirements of this document are met by signaling protocol. If the requirements of this document are met by
extending an existing routing or signaling protocol, the security extending an existing routing or signaling protocol, the security
considerations of the protocol being extended apply. If the considerations of the protocol being extended apply. If the
requirements of this document are met by specifying a new protocol, requirements of this document are met by specifying a new protocol,
the security considerations of that new protocol should include an the security considerations of that new protocol should include an
evaluation of what level of protection is required by the additional evaluation of what level of protection is required by the additional
information specified in this document, such as data origin information specified in this document, such as data origin
authentication. authentication.
9. References 8. References
9.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References 8.2. Informative References
[I-D.ietf-rtgwg-cl-framework] [FRAMEWORK]
Ning, S., McDysan, D., Osborne, E., Yong, L., and C. Ning, S., McDysan, D., Osborne, E., Yong, L., and C.
Villamizar, "Advanced Multipath Framework in MPLS", draft- Villamizar, "Advanced Multipath Framework in MPLS", Work
ietf-rtgwg-cl-framework-04 (work in progress), July 2013. in Progress, July 2013.
[I-D.ietf-rtgwg-cl-use-cases]
Ning, S., Malis, A., McDysan, D., Yong, L., and C.
Villamizar, "Advanced Multipath Use Cases and Design
Considerations", draft-ietf-rtgwg-cl-use-cases-05 (work in
progress), November 2013.
[IEEE-802.1AX] [IEEE-802.1AX]
IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE
Standard for Local and Metropolitan Area Networks - Link Standard for Local and Metropolitan Area Networks - Link
Aggregation", 2006, <http://standards.ieee.org/getieee802/ Aggregation", 2006, <http://standards.ieee.org/getieee802/
download/802.1AX-2008.pdf>. download/802.1AX-2008.pdf>.
[ITU-T.G.800] [ITU-T.G.800]
ITU-T, "Unified functional architecture of transport ITU-T, "Unified functional architecture of transport
networks", 2007, <http://www.itu.int/rec/T-REC-G/ networks", ITU-T Recommendation G.800, February 2012,
<http://www.itu.int/rec/T-REC-G/
recommendation.asp?parent=T-REC-G.800>. recommendation.asp?parent=T-REC-G.800>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS signaling Switching (MPLS) Working Group decision on MPLS signaling
protocols", RFC 3468, February 2003. protocols", RFC 3468, February 2003.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
Graveman, "MPLS Transport Profile (MPLS-TP) Security Graveman, "MPLS Transport Profile (MPLS-TP) Security
Framework", RFC 6941, April 2013. Framework", RFC 6941, April 2013.
[USE-CASES]
Ning, S., Malis, A., McDysan, D., Yong, L., and C.
Villamizar, "Advanced Multipath Use Cases and Design
Considerations", Work in Progress, November 2013.
Authors' Addresses Authors' Addresses
Curtis Villamizar (editor) Curtis Villamizar (editor)
OCCNC, LLC OCCNC, LLC
Email: curtis@occnc.com EMail: curtis@occnc.com
Dave McDysan (editor) Dave McDysan (editor)
Verizon Verizon
22001 Loudoun County PKWY 22001 Loudoun County PKWY
Ashburn, VA 20147 Ashburn, VA 20147
USA USA
Email: dave.mcdysan@verizon.com EMail: dave.mcdysan@verizon.com
So Ning So Ning
Tata Communications Tata Communications
Email: ning.so@tatacommunications.com EMail: ning.so@tatacommunications.com
Andrew Malis Andrew G. Malis
Huawei Technologies Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: agmalis@gmail.com EMail: agmalis@gmail.com
Lucy Yong Lucy Yong
Huawei USA Huawei USA
5340 Legacy Dr. 5340 Legacy Dr.
Plano, TX 75025 Plano, TX 75025
USA USA
Phone: +1 469-277-5837 Phone: +1 469-277-5837
Email: lucy.yong@huawei.com EMail: lucy.yong@huawei.com
 End of changes. 127 change blocks. 
340 lines changed or deleted 348 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/