< draft-ietf-rtgwg-cl-requirement-13.txt   draft-ietf-rtgwg-cl-requirement-14.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: May 17, 2014 Verizon Expires: July 28, 2014 Verizon
S. Ning S. Ning
Tata Communications Tata Communications
A. Malis A. Malis
Consultant Consultant
L. Yong L. Yong
Huawei USA Huawei USA
November 13, 2013 January 25, 2014
Requirements for Advanced Multipath in MPLS Networks Requirements for Advanced Multipath in MPLS Networks
draft-ietf-rtgwg-cl-requirement-13 draft-ietf-rtgwg-cl-requirement-14
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 May 17, 2014. This Internet-Draft will expire on July 28, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 7 3.2. Component Links Provided by Lower Layer Networks . . . . 7
3.3. Component Links with Different Characteristics . . . . . 7 3.3. Component Links with Different Characteristics . . . . . 7
3.4. Considerations for Bidirectional Client LSP . . . . . . . 8 3.4. Considerations for Bidirectional Client LSP . . . . . . . 8
3.5. Multipath Load Balancing Dynamics . . . . . . . . . . . . 9 3.5. Multipath Load Balancing Dynamics . . . . . . . . . . . . 9
4. General Requirements for Protocol Solutions . . . . . . . . . 11 4. General Requirements for Protocol Solutions . . . . . . . . . 11
5. Management Requirements . . . . . . . . . . . . . . . . . . . 12 5. Management Requirements . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 Label Switched Paths (LSPs). In core
alternative since the aggregate capacities of core networks today far networks there is often no alternative since the aggregate capacities
exceed the capacity of a single physical link or single packet of core networks today far exceed the capacity of a single physical
processing element. link or 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 microflow as is current practice. within a microflow as is current practice.
skipping to change at page 7, line 42 skipping to change at page 7, line 42
FR#9 The precision of latency reporting SHOULD be configurable. A FR#9 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
it 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 tradeoff is discussed in detail in
[I-D.ietf-rtgwg-cl-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. When the path component links that connect the same pair of nodes. When the path
skipping to change at page 8, line 40 skipping to change at page 8, line 40
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 LSP 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 bidirectional
client LSP where time synchronization protocols such as PTP or NTP client LSP where time synchronization protocols such as Precision
are carried, or in any other case where symmetric delay is highly Time Protocol (PTP) or Network Time Protocol (NTP) are carried, or in
desirable. There may be other uses of this capability. any other case where symmetric delay is highly desirable. There may
be other uses of this capability.
Other client LSP may only require that the LSP path serve the same Other client LSP may only require that the LSP path serve the same
set of nodes in both directions. This is necessary if protocols are set of nodes in both directions. This is necessary if protocols are
carried which make use of the reverse direction of the LSP as a back 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 channel in cases such OAM protocols using IPv4 Time to Live (TTL) or
the underlying path. There may be other uses of this capability. IPv4 Hop Limit to monitor or diagnose the underlying path. There may
be other uses of this capability.
FR#13 The solution MUST support an optional means for client LSP FR#13 The solution MUST support an optional means for client LSP
signaling to bind a client LSP to a particular component link signaling to bind a client LSP to a particular component link
within an advanced multipath. If this option is not exercised, within an advanced multipath. If this option is not exercised,
then a client LSP that is bound to an advanced multipath may be then a client LSP that is bound to an advanced multipath may be
bound to any component link matching all other signaled bound to any component link matching all other signaled
requirements, and different directions of a bidirectional client requirements, and different directions of a bidirectional client
LSP can be bound to different component links. LSP can be bound to different component links.
FR#14 The solution MUST support a means to indicate that both FR#14 The solution MUST support a means to indicate that both
directions of co-routed bidirectional client LSP MUST be bound to directions of co-routed bidirectional client LSP MUST be bound to
the same set of nodes. the same set of nodes.
A client LSP which is bound to a specific component link SHOULD NOT FR#15 A client LSP which is bound to a specific component link SHOULD
exceed the capacity of a single component link. NOT exceed the capacity of a single component link. This is
inherent in the assumption that a network SHOULD NOT operate in a
congested state if congestion is avoidable.
For some large bidirectional client LSP it may not be necessary (or 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 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 may be necessary or desirable to constrain
the path taken by the LSP to the same set of nodes in both the path taken by the LSP to the same set of nodes in both
directions. Without and 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 an bidirectional client LSP to take
multiple paths and coordinate load balance on each side to keep both multiple paths and coordinate load balance on each side to keep both
directions of flows within such an LSP on common paths. 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
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
specific client LSP needs to be considered. specific client LSP needs to be considered.
FR#15 The solution SHALL provide a means that indicates whether any FR#16 The solution SHALL provide a means that indicates whether any
of the flows within an client LSP MUST NOT be split across of the LSP within an client LSP MUST NOT be split across multiple
multiple component links. component links.
FR#16 The solution SHALL provide a means local to a node that FR#17 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 the
advanced multipath such that Performance Objectives are met as advanced multipath such that Performance Objectives are met as
described in prior requirements in Section 3.3. described in prior requirements in Section 3.3.
FR#17 The solution SHALL measure traffic flows or groups of traffic FR#18 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 place
this traffic in order to balance the load so that no component this traffic in order to balance the load so that no component
link in the advanced multipath between a pair of nodes is link in the advanced multipath between a pair of nodes is
overloaded. overloaded.
FR#18 When a traffic flow is moved from one component link to another FR#19 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 in the same advanced multipath between a set of nodes, it MUST be
done so in a minimally disruptive manner. done so in a minimally disruptive manner.
FR#19 Load balancing MAY be used during sustained low traffic periods FR#20 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 of
power reduction. power reduction.
FR#20 The solution SHALL provide a means to identify client LSPs FR#21 The solution SHALL provide a means to identify client LSPs
containing traffic flows whose rearrangement frequency needs to containing traffic flows whose rearrangement frequency needs to
be bounded by a specific value and MUST provide a means to bound be bounded by a specific value and MUST provide a means to bound
the rearrangement frequency for traffic flows within these client the rearrangement frequency for traffic flows within these client
LSP. LSP.
FR#21 The solution SHALL provide a means to distribute traffic flows FR#22 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 an client
LSP exceeds that of any component link in the advanced multipath. LSP exceeds that of any component link in the advanced multipath.
FR#22 The solution SHOULD support the use case where an advanced FR#23 The solution SHOULD support the use case where an advanced
multipath itself is a component link for a higher order advanced multipath itself is a component link for a higher order advanced
multipath. For example, an advanced multipath comprised of MPLS- multipath. For example, an advanced multipath comprised of MPLS-
TP bi-directional tunnels viewed as logical links could then be TP bi-directional tunnels viewed as logical links could then be
used as a component link in yet another advanced multipath that used as a component link in yet another advanced multipath that
connects MPLS routers. connects MPLS routers.
FR#23 If the total demand offered by traffic flows exceeds the FR#24 If the total demand offered by traffic flows exceeds the
capacity of the advanced multipath, the solution SHOULD define a capacity of the advanced multipath, the solution SHOULD define a
means to cause some client LSP to move to an alternate set of means to cause some client LSP to move to an alternate set of
paths that are not congested. These "preempted LSP" may not be paths that are not congested. These "preempted LSP" may not be
restored if there is 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
skipping to change at page 11, line 25 skipping to change at page 11, line 31
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 specification 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 (without using TE methods as decided in [RFC3468]). requirements. This MUST be accomplished without defining LDP
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 advanced multipath. Function requirements SHOULD, where on an advanced multipath. Function requirements SHOULD, where
possible, be accommodated in a manner that supports LDP signaled possible, be accommodated in a manner that supports LDP signaled
LSP, RSVP signaled LSP, and LSP set up using management plane LSP, RSVP signaled LSP, and LSP set up using management plane
mechanisms. mechanisms.
GR#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 to same MPLS network topology, the solution MAY define extensions to
the IGP. the IGP.
 End of changes. 23 change blocks. 
32 lines changed or deleted 37 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/