< draft-ietf-rtgwg-cl-requirement-11.txt   draft-ietf-rtgwg-cl-requirement-12.txt >
RTGWG C. Villamizar, Ed. RTGWG C. Villamizar, Ed.
Internet-Draft OCCNC, LLC Internet-Draft OCCNC, LLC
Intended status: Informational D. McDysan, Ed. Intended status: Informational D. McDysan, Ed.
Expires: January 12, 2014 Verizon Expires: April 12, 2014 Verizon
S. Ning S. Ning
Tata Communications Tata Communications
A. Malis A. Malis
Verizon Verizon
L. Yong L. Yong
Huawei USA Huawei USA
July 11, 2013 October 9, 2013
Requirements for Advanced Multipath in MPLS Networks Requirements for Advanced Multipath in MPLS Networks
draft-ietf-rtgwg-cl-requirement-11 draft-ietf-rtgwg-cl-requirement-12
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.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2014. This Internet-Draft will expire on April 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 21
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . 7 3.2. Component Links Provided by Lower Layer Networks . . . . . 7
3.3. Parallel Component Links with Different Characteristics . 8 3.3. Component Links with Different Characteristics . . . . . . 8
4. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 11 3.4. Considerations for Bidirectional Client LSP . . . . . . . 9
5. Management Requirements . . . . . . . . . . . . . . . . . . . 12 3.5. Multipath Load Balancing Dynamics . . . . . . . . . . . . 10
4. General Requirements for Protocol Solutions . . . . . . . . . 11
5. Management Requirements . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 LSP. In core networks there is often no traffic over multiple MPLS LSP. In core networks there is often no
alternative since the aggregate capacities of core networks today far alternative since the aggregate capacities of core networks today far
exceed the capacity of a single physical link or single packet exceed the capacity of a single physical link or single packet
processing element. processing element.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
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 microflow as is current practice. within a microflow as is current practice.
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 that are as independent as possible of of functional requirements that are as independent as possible of
protocol specifications (Section 3). For certain functional protocol specifications in Section 3. A set of general protocol
requirements this document describes a set of derived protocol requirements are defined in Section 4. A set of network management
requirements (Section 4) and management requirements (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 RFC 2119 [RFC2119].
Any statement which requires the solution to support some new Any statement which requires the solution to support some new
functionality through use of [RFC2119] keywords, SHOULD be functionality through use of [RFC2119] keywords, SHOULD be
interpretted as follows. The implementation either MUST or SHOULD interpreted as follows. The implementation either MUST or SHOULD
support the new functionality depending on the use of either MUST or support the new functionality depending on the use of either MUST or
SHOULD in the requirements statement. The implementation SHOULD in SHOULD in the requirements statement. The implementation SHOULD in
most or all cases allow any new functionality to be individually most or all cases allow any new functionality to be individually
enabled or disabled through configuration. A service provider or enabled or disabled through configuration. A service provider or
other deployment MAY choose to enable or disable any feature in their other deployment MAY choose to enable or disable any feature in their
network, subject to implementation limitations on sets of features network, subject to implementation limitations on sets of features
which can be disabled. which can be disabled.
2. Definitions 2. Definitions
Multipath Multipath
skipping to change at page 4, line 36 skipping to change at page 4, line 36
have equal cost in a routing protocol. have equal cost in a routing protocol.
Advanced Multipath Advanced Multipath
Advanced Multipath meets the requirements defined in this Advanced Multipath meets the requirements defined in this
document. A key capability of advanced multipath is the support document. A key capability of advanced multipath is the support
of non-homogeneous component links. of non-homogeneous component links.
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 Avici
Systems, but was abandoned in 2007. The term composite link is Systems, but was abandoned in 2007. The term composite link is
now defined by the ITU in [ITU-T.G.800]. The ITU definition now defined by the ITU-T in [ITU-T.G.800]. The ITU-T definition
includes multipath as defined here, plus inverse multiplexing includes multipath as defined here, plus inverse multiplexing
which is explicitly excluded from the definition of multipath. which is explicitly excluded from the definition of multipath.
Inverse Multiplexing Inverse Multiplexing
Inverse multiplexing either transmits whole packets and Inverse multiplexing either transmits whole packets and
resequences the packets at the receiving end or subdivides resequences the packets at the receiving end or subdivides
packets and reassembles the packets at the receiving end. packets and reassembles the packets at the receiving end.
Inverse multiplexing requires that all packets be handled by a Inverse multiplexing requires that all packets be handled by a
common egress packet processing element and is therefore not common egress packet processing element and is therefore not
useful for very high bandwidth applications. useful for very high bandwidth applications.
Component Link Component Link
The ITU 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 LSP Client LSP
A client LSP is an LSP which has been set up over a server layer. A client LSP is an LSP which has been set up over a server layer.
In the context of this discussion, a client LSP is a LSP which In the context of this discussion, a client LSP is a LSP which
has been set up over a multipath as opposed to an LSP has been set up over a multipath as opposed to an LSP
skipping to change at page 5, line 33 skipping to change at page 5, line 33
Note that a client LSP may contain one or more Flows or a client Note that a client LSP may contain one or more Flows or a client
LSP may be equivalent to a Flow. Flow identification is used to LSP may be equivalent to a Flow. Flow identification is used to
locally select a component link, or a path through the network locally select a component link, or a path through the network
toward the destination. 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 acheive 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 (SLA) 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, edge-to-edge, or end-to-end.
Performance objectives may span one provider or may span multiple Performance objectives may span one provider or may span 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 layer 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 compoent 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. layers, including those providing physical layer emulation.
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.
The term Advanced Multipath is intended to be used within the context The term Advanced Multipath is intended to be used within the context
of this document and the related documents, of this document and the related documents,
[I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and
any other related document. Other advanced multipath techniques may any other related document. Other advanced multipath techniques may
in the future arise. If the capabilities defined in this document in the future arise. If the capabilities defined in this document
become commonplace, they would no longer be considered "advanced". become commonplace, they would no longer be considered "advanced".
Use of the term "advanced multipath" outside this document, if Use of the term "advanced multipath" outside this document, if
refering to the term as defined here, should indicate Advanced referring to the term as defined here, should indicate Advanced
Multipath as defined by this document, citing the current document Multipath as defined by this document, citing the current document
name. If using another definition of "advanced multipath", documents name. If using another definition of "advanced multipath", documents
may optionally clarify that they are not using the term "advanced may optionally clarify that they are not using the term "advanced
multipath" as defined by this document if clarification is deemed multipath" as defined by this document if clarification is 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.
skipping to change at page 6, line 48 skipping to change at page 6, line 48
values. values.
FR#1 An advanced multipath MAY be announced in conjunction with FR#1 An advanced multipath MAY be announced in conjunction with
detailed parameters about its component links, such as detailed parameters about its component links, such as
bandwidth and latency. The advanced multipath SHALL behave as bandwidth and latency. The advanced multipath SHALL behave as
a single IGP adjacency. a single IGP adjacency.
FR#2 The solution SHALL provide a means to summarize some routing FR#2 The solution SHALL provide a means to summarize some routing
advertisements regarding the characteristics of an advanced advertisements regarding the characteristics of an advanced
multipath such that the updated protocol mechanisms maintain multipath such that the updated protocol mechanisms maintain
convergence times within the timeframe needed to meet or no convergence times within the timeframe needed to meet or not
significantly exceed existing Performance Objective for significantly exceed existing Performance Objective for
convergence on the same network or convergence on a network convergence on the same network or convergence on a network
with a similar topology. with a similar topology.
FR#3 The solution SHALL ensure that restoration operations happen FR#3 The solution SHALL ensure that restoration operations happen
within the timeframe needed to meet existing Performance within the timeframe needed to meet existing Performance
Objective for restoration time on the same network or Objective for restoration time on the same network or
restoration time on a network with a similar topology. restoration time on a network with a similar topology.
FR#4 The solution SHALL provide a mechanism to select a path for a FR#4 The solution shall provide a mechanism to select a set of paths
flow across a network that contains a number of paths comprised for an LSP across a network in such a way that flows within the
of pairs of nodes connected by advanced multipath in such a way LSP are distributed across the set of paths while meeting all
as to automatically distribute the load over the network nodes of the other requirements stated above. The solution SHOULD
connected by advanced multipaths while meeting all of the other work in a manner similar to existing multipath techniques
mandatory requirements stated above. The solution SHOULD work except as necessary to accommodate advanced multipath
in a manner similar to that of current networks without any requirements.
advanced multipath protocol enhancements when the
characteristics of the individual component links are
advertised.
FR#5 If extensions to existing protocols are specified and/or new FR#5 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#6 Any load balancing solutions MUST NOT oscillate. Some change FR#6 Any load balancing solutions MUST NOT oscillate. Some change
in path MAY occur. The solution MUST ensure that path in path MAY occur. The solution MUST ensure that path
stability and traffic reordering continue to meet Performance stability and traffic reordering continue to meet Performance
Objective on the same network or on a network with a similar Objective on the same network or on a network with a similar
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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-TP)). The lower layer network may change
the latency (and/or other performance parameters) seen by the client the latency (and/or other performance parameters) seen by the client
layer. Currently, there is no protocol for the lower layer network layer. Currently, there is no protocol for the lower layer network
to inform the higher layer network of a change in a performance to inform the higher layer network of a change in a performance
parameter. Communication of the latency performance parameter is a parameter. Communication of the latency performance parameter is a
very important requirement. Communication of other performance very important requirement. Communication of other performance
parameters (e.g., delay variation) is desirable. parameters (e.g., delay variation) is desirable.
FR#8 The solution SHALL specify a protocol means to allow a lower FR#8 The solution SHALL specify a protocol means to allow a lower
layer server network to communicate latency to the higher layer server network to communicate latency to the higher layer
layer client network. client network.
FR#9 The precision of latency reporting SHOULD be configurable. A
reasonable default SHOULD be provided. Implementations SHOULD
support precision of at least 10% of the one way latencies for
latency of 1 ms or more.
FR#10 The solution SHALL provide a means to limit the latency to
meet a Performance Objective target on a per flow basis or
group of flow basis, where flows or groups of flows are
identifiable in the forwarding plane and are signaled using in
the control plane or set up using the management plane.
The Performance Objectives differ across the services, and
some services have different Performance Objectives for
different QoS classes, for example, one QoS class may have a
much larger latency bound than another. Overload can occur
which would violate a Performance Objective parameter (e.g.,
loss) and some remedy to handle this case for an advanced
multipath is required.
FR#11 If the total demand offered by traffic flows exceeds the FR#9 The precision of latency reporting SHOULD be configurable. A
capacity of the advanced multipath, the solution SHOULD define reasonable default SHOULD be provided. Implementations SHOULD
a means to cause some traffic flows or groups of flows to move support precision of at least 10% of the one way latencies for
to some other point in the network that is not congested. latency of 1 msec or more.
These "preempted flows" may not be restored if there is no
uncongested path in the network.
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
it if used in routing decisions it can result in routing instability. it if used in routing decisions it can result in routing instability.
This tradeoff is discussed in detail in This tradeoff is discussed in detail in
[I-D.ietf-rtgwg-cl-framework]. [I-D.ietf-rtgwg-cl-framework].
3.3. Parallel 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. When the path component links that connect the same pair of nodes. When the path
for a flow can be chosen from a set of candidate nodes connected via for a flow can be chosen from a set of candidate nodes connected via
advanced multipaths, other techniques have been developed. Refer to advanced multipaths, other techniques have been developed. Refer to
the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a description of the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a description of
existing techniques and a set of references. existing techniques and a set of references.
FR#12 The solution SHALL measure traffic flows or groups of traffic FR#10 The solution SHALL provide a means to indicate that a client
flows and dynamically select the component link on which to LSP will traverse a component link with the minimum latency
place this traffic in order to balance the load so that no value. This will provide a means by which minimum latency
component link in the advanced multipath between a pair of Performance Objectives of flows within the client LSP can be
nodes is overloaded. supported.
FR#13 When a traffic flow is moved from one component link to FR#11 The solution SHALL provide a means to indicate that a client
another in the same advanced multipath between a set of nodes LSP will traverse a component link with a maximum acceptable
(or sites), it MUST be done so in a minimally disruptive latency value as specified by protocol. This will provide a
manner. means by which bounded latency Performance Objectives of flows
within the client LSP can be supported.
FR#14 Load balancing MAY be used during sustained low traffic FR#12 The solution SHALL provide a means to indicate that a client
periods to reduce the number of active component links for the LSP will traverse a component link with a maximum acceptable
purpose of power reduction. delay variation value as specified by protocol.
FR#15 The solution SHALL provide a means to identify flows whose The above set of requirements apply to component links with different
rearrangement frequency needs to be bounded by a configured characteristics regardless as to whether those component links are
value and MUST provide a means to bound the rearrangement provided by parallel physical links between nodes or provided by sets
frequency for these flows. of paths across a network provided by server layer LSP.
FR#16 The solution SHALL provide a means that communicates whether Allowing multipath to contain component links with different
the flows within an client LSP can be split across multiple characteristics can improve the overall load balance and can be
component links. The solution SHOULD provide a means to accomplished while still accommodating the more strict requirements
indicate the flow identification field(s) which can be used of a subset of client LSP.
along the flow path which can be used to perform this
function.
FR#17 The solution SHALL provide a means to indicate that a traffic 3.4. Considerations for Bidirectional Client LSP
flow will traverse a component link with the minimum latency
value.
FR#18 The solution SHALL provide a means to indicate that a traffic Some client LSP MAY require a path bound to a specific set of
flow will traverse a component link with a maximum acceptable component links. This case is most likely to occur in bidirectional
latency value as specified by protocol. client LSP where time synchronization protocols such as PTP or NTP
are carried, or in any other case where symmetric delay is highly
desirable. There may be other uses of this capability.
FR#19 The solution SHALL provide a means to indicate that a traffic Other client LSP may only require that the LSP path serve the same
flow will traverse a component link with a maximum acceptable set of nodes in both directions. This is necessary if protocols are
delay variation value as specified by protocol. carried which make use of the reverse direction of the LSP as a back
channel in cases such OAM protocols using TTL to monitor or diagnose
the underlying path. There may be other uses of this capability.
FR#20 The solution SHALL provide a means local to a node that FR#13 The solution MUST support an optional means for client LSP
signaling to bind a client LSP to a particular component link
within an advanced multipath. If this option is not
exercised, then a client LSP that is bound to an advanced
multipath may be bound to any component link matching all
other signaled requirements, and different directions of a
bidirectional client LSP can be bound to different component
links.
FR#14 The solution MUST support a means to indicate that both
directions of co-routed bidirectional client LSP MUST be bound
to the same set of nodes.
A client LSP which is bound to a specific component link SHOULD NOT
exceed the capacity of a single component link.
For some large bidirectional client LSP it may not be necessary (or
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
the path taken by the LSP to the same set of nodes in both
directions. Without and entirely new and highly dynamic protocol, it
is not feasible to constrain such an bidirectional client LSP to take
multiple paths and coordinate load balance on each side to keep both
directions of flows within such an LSP on common paths.
3.5. Multipath Load Balancing Dynamics
Multipath load balancing attempts to keep traffic levels on all
component links below congestion levels if possible and preferably
well balanced. Load balancing is minimally disruptive (see
discussion below this section's list of requirements). The
sensitivity to these minimal disruptions of traffic flows within
specific client LSP needs to be considered.
FR#15 The solution SHALL provide a means that indicates whether any
of the flows within an client LSP MUST NOT be split across
multiple component links.
FR#16 The solution SHALL provide a means local to a node that
automatically distributes flows across the component links in automatically distributes flows across the component links in
the advanced multipath such that Performance Objectives are the advanced multipath such that Performance Objectives are
met as described in prior requirements. met as described in prior requirements in Section 3.3.
FR#21 The solution SHALL provide a means to distribute flows from a FR#17 The solution SHALL measure traffic flows or groups of traffic
single client LSP across multiple component links to handle at flows and dynamically select the component link on which to
least the case where the traffic carried in an client LSP place this traffic in order to balance the load so that no
exceeds that of any component link in the advanced multipath. component link in the advanced multipath between a pair of
As defined in Section 2, a flow is a sequence of packets that nodes is overloaded.
should be transferred on one component link and should be
transferred in order. FR#18 When a traffic flow is moved from one component link to
another in the same advanced multipath between a set of nodes,
it MUST be done so in a minimally disruptive manner.
FR#19 Load balancing MAY be used during sustained low traffic
periods to reduce the number of active component links for the
purpose of power reduction.
FR#20 The solution SHALL provide a means to identify client LSPs
containing traffic flows whose rearrangement frequency needs
to be bounded by a specific value and MUST provide a means to
bound the rearrangement frequency for traffic flows within
these client LSP.
FR#21 The solution SHALL provide a means to distribute traffic flows
from a single client LSP across multiple component links to
handle at least the case where the traffic carried in an
client LSP exceeds that of any component link in the advanced
multipath.
FR#22 The solution SHOULD support the use case where an advanced FR#22 The solution SHOULD support the use case where an advanced
multipath itself is a component link for a higher order multipath itself is a component link for a higher order
advanced multipath. For example, an advanced multipath advanced multipath. For example, an advanced multipath
comprised of MPLS-TP bi-directional tunnels viewed as logical comprised of MPLS-TP bi-directional tunnels viewed as logical
links could then be used as a component link in yet another links could then be used as a component link in yet another
advanced multipath that connects MPLS routers. advanced multipath that connects MPLS routers.
FR#23 The solution MUST support an optional means for client LSP FR#23 If the total demand offered by traffic flows exceeds the
signaling to bind a client LSP to a particular component link capacity of the advanced multipath, the solution SHOULD define
within an advanced multipath. If this option is not a means to cause some client LSP to move to an alternate set
exercised, then a client LSP that is bound to an advanced of paths that are not congested. These "preempted LSP" may
multipath may be bound to any component link matching all not be restored if there is no uncongested path in the
other signaled requirements, and different directions of a network.
bidirectional client LSP can be bound to different component
links.
FR#24 The solution MUST support a means to indicate that both
directions of co-routed bidirectional client LSP MUST be bound
to the same component link.
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 which may greatly exceed
the normal delay variation (jitter). A delay discontinuity has the the normal delay variation (jitter). A delay discontinuity has the
skipping to change at page 11, line 11 skipping to change at page 11, line 41
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. The
network operator when configuring a network for power reduction network operator when configuring a network for power reduction
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. Derived Requirements 4. General Requirements for Protocol Solutions
This section takes the next step and derives high-level requirements This section defines requirements for protocol specification used to
on protocol specification from the functional requirements. meet the functional requirements specified in Section 3.
DR#1 The solution SHOULD attempt to extend existing protocols GR#1 The solution SHOULD extend existing protocols wherever
wherever possible, developing a new protocol only if this adds possible, developing a new protocol only where doing so adds a
a significant set of capabilities. significant set of capabilities.
DR#2 A solution SHOULD extend LDP capabilities to meet functional GR#2 A solution SHOULD extend LDP capabilities to meet functional
requirements (without using TE methods as decided in requirements (without using TE methods as decided in
[RFC3468]). [RFC3468]).
DR#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 advanced multipath. Other functional requirements should on an advanced multipath. Function requirements SHOULD, where
be supported as independently of signaling protocol as possible, be accommodated in a manner that supports LDP
possible. signaled LSP, RSVP signaled LSP, and LSP set up using
management plane mechanisms.
DR#4 When the nodes connected via an advanced multipath are in the GR#4 When the nodes connected via an advanced multipath are in the
same MPLS network topology, the solution MAY define extensions same MPLS network topology, the solution MAY define extensions
to the IGP. to the IGP.
DR#5 When the nodes are connected via an advanced multipath are in GR#5 When the nodes are connected via an advanced multipath are in
different MPLS network topologies, the solution SHALL NOT rely different MPLS network topologies, the solution SHALL NOT rely
on extensions to the IGP. on extensions to the IGP.
DR#6 The solution SHOULD support advanced multipath IGP GR#6 The solution SHOULD support advanced multipath IGP
advertisement that results in convergence time better than that advertisement that results in convergence time better than that
of advertising the individual component links. The solution of advertising the individual component links. The solution
SHALL be designed so that it represents the range of SHALL be designed so that it represents the range of
capabilities of the individual component links such that capabilities of the individual component links such that
functional requirements are met, and also minimizes the functional requirements are met, and also minimizes the
frequency of advertisement updates which may cause IGP frequency of advertisement updates which may cause IGP
convergence to occur. 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 considered include: client LSP establishment/release, changes
in component link characteristics (e.g., latency, up/down in component link characteristics (e.g., latency, up/down
state), and/or bandwidth utilization. state), and/or bandwidth utilization.
DR#7 When a worst case failure scenario occurs, the number of GR#7 When a worst case failure scenario occurs, the number of
RSVP-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 provider Performance Objective for the duration of
unavailability without significantly relaxing those existing unavailability without significantly relaxing those existing
Performance Objectives for the same network or for networks Performance Objectives for the same network or for networks
with similar topology. For example, the processing load due to with similar topology. For example, the processing load due to
IGP readvertisement MUST NOT increase significantly and the IGP readvertisement MUST NOT increase significantly and the
resignaling time of the solution MUST NOT increase resignaling time of the solution MUST NOT increase
significantly as compared with current methods. significantly as compared with current methods.
skipping to change at page 13, line 6 skipping to change at page 13, line 40
management plane. management plane.
MR#7 Advanced multipath fault notification MUST be sent to the MR#7 Advanced multipath fault notification MUST be sent to the
management plane and MUST be distributed via link state message management plane and MUST be distributed via link state message
in the IGP. in the IGP.
MR#8 Management Plane SHOULD provide the means for an operator to MR#8 Management Plane SHOULD provide the means for an operator to
initiate an optimization process. 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.3. 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 co-authored a version of this document.
A rewrite of this document occurred after the IETF77 meeting. A rewrite of this document occurred after the IETF77 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 IETF77 RTGWG meeting.
skipping to change at page 13, line 31 skipping to change at page 14, line 18
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 IETF82 that identified a new requirement.
Iftekhar Hussain made numerous valuable comments on the RTGWG mailing Iftekhar Hussain made numerous valuable comments on the RTGWG mailing
list that resulted in improvements to document clarity. list that resulted in improvements to document 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. 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 Much of the work done by Curtis Villamizar occurred while at
Infinera. Infinera continues to sponsor this work on a consulting Infinera.
basis.
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. Lou Berger respectively. Both reviews provided useful comments. The current
provided the RtgDir review which resulted in substantial wording of the security section is based on suggested wording from
clarification of terminology and document wording, particularly in Tom Yu. Lou Berger provided the RtgDir review which resulted in the
the Abstract, Introduction, and Definitions sections. document being renamed and substantial clarification of terminology
and document wording, particularly in the Abstract, Introduction, and
Definitions sections.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. 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.
 End of changes. 42 change blocks. 
136 lines changed or deleted 167 lines changed or added

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