< draft-ietf-rtgwg-cl-requirement-14.txt   draft-ietf-rtgwg-cl-requirement-15.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: July 28, 2014 Verizon Expires: July 29, 2014 Verizon
S. Ning S. Ning
Tata Communications Tata Communications
A. Malis A. Malis
Consultant Consultant
L. Yong L. Yong
Huawei USA Huawei USA
January 25, 2014 January 25, 2014
Requirements for Advanced Multipath in MPLS Networks Requirements for Advanced Multipath in MPLS Networks
draft-ietf-rtgwg-cl-requirement-14 draft-ietf-rtgwg-cl-requirement-15
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 July 28, 2014. This Internet-Draft will expire on July 29, 2014.
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 22 skipping to change at page 2, line 22
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 . . . . 8
3.3. Component Links with Different Characteristics . . . . . 7 3.3. Component Links with Different Characteristics . . . . . 8
3.4. Considerations for Bidirectional Client LSP . . . . . . . 8 3.4. Considerations for Bidirectional Client LSP . . . . . . . 9
3.5. Multipath Load Balancing Dynamics . . . . . . . . . . . . 9 3.5. Multipath Load Balancing Dynamics . . . . . . . . . . . . 10
4. General Requirements for Protocol Solutions . . . . . . . . . 11 4. General Requirements for Protocol Solutions . . . . . . . . . 12
5. Management Requirements . . . . . . . . . . . . . . . . . . . 12 5. Management Requirements . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 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 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 capacities
of core networks today far exceed the capacity of a single physical of core networks today far exceed the capacity of a single physical
link or single packet 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.
Numerous forms of multipath exist today including MPLS Link Bundling
[RFC4201], Ethernet Link Aggregation [IEEE-802.1AX], and various
forms of Equal Cost Multipath (ECMP) such as for OSPF ECMP, IS-IS
ECMP, and BGP ECMP. Refer to the Appendices in
[I-D.ietf-rtgwg-cl-use-cases] for a description of existing
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 that are as independent as possible of of functional requirements that are as independent as possible of
protocol specifications in Section 3. A set of general protocol protocol specifications in Section 3. 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 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 interpreted
interpreted as follows. The implementation either MUST or SHOULD as follows. The implementation either MUST or SHOULD support the new
support the new functionality depending on the use of either MUST or functionality depending on the use of either MUST or SHOULD in the
SHOULD in the requirements statement. The implementation SHOULD in requirements statement. The implementation SHOULD in most or all
most or all cases allow any new functionality to be individually cases allow any new functionality to be individually enabled or
enabled or disabled through configuration. A service provider or disabled through configuration. A service provider or other
other deployment MAY choose to enable or disable any feature in their deployment MAY enable or disable any feature in their network,
network, subject to implementation limitations on sets of features subject to implementation limitations on sets of features which can
which can be disabled. be 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, or
b. specific paths across a network to a destination node, or
b. may be specific paths across a network to a destination c. links or paths to an intermediate node used to reach a
node, or common destination.
c. may be links or paths to an intermediate node used to
reach a 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 meets the requirements defined in this Advanced Multipath is a formalization of multipath techniques
document. A key capability of advanced multipath is the support that meets the requirements defined in this document. A key
of non-homogeneous component links. capability of Advanced Multipath is the support of non-
homogeneous component links.
Advanced Multipath Group (AMG)
An Advanced Multipath Group (AMG) is a collection of component
links where Advanced 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 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-T in [ITU-T.G.800]. The ITU-T 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
skipping to change at page 4, line 36 skipping to change at page 4, line 45
useful for very high bandwidth applications. 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
A client layer is the one immediately above a server layer.
Server Layer
A server layer is the latey immediately below a client layer.
Higher Layers
Relative to a particular layer, a client layer and any layer
above that is considered a higher layer. Upper layer is
synonymous with higher layer.
Lower Layers
Relative to a particular layer, a server layer and any layer
below that is considered a lower layer.
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 one or more
In the context of this discussion, a client LSP is a LSP which lower layers. In the context of this discussion, one type of
has been set up over a multipath as opposed to an LSP client LSP is a LSP which has been set up over an AMG.
representing the multipath itself or any LSP supporting a
component links of that multipath.
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 MAC address, etc.
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
skipping to change at page 5, line 30 skipping to change at page 6, line 5
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 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. layers, including those providing physical layer emulation, or 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
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
consistitutes 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 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
referring 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
skipping to change at page 6, line 14 skipping to change at page 6, line 43
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 Limiting the period of unavailability in response to failures or
transient events is extremely important as well as maintaining transient events is extremely important as well as maintaining
stability. The transient period between some service disrupting stability.
event and the convergence of the routing and/or signaling protocols
MUST occur within a time frame specified by Performance Objective
values.
FR#1 An advanced multipath MAY be announced in conjunction with FR#1 The transient period between some service disrupting event and
detailed parameters about its component links, such as bandwidth the convergence of the routing and/or signaling protocols MUST
and latency. The advanced multipath SHALL behave as a single IGP occur within a time frame specified by Performance Objective
adjacency. values.
FR#2 The solution SHALL provide a means to summarize some routing FR#2 An AMG MAY be announced in conjunction with detailed parameters
advertisements regarding the characteristics of an advanced about its component links, such as bandwidth and latency. The
multipath such that the updated protocol mechanisms maintain AMG SHALL behave as a single IGP adjacency.
convergence times within the timeframe needed to meet or not
significantly exceed existing Performance Objective for
convergence on the same network or convergence on a network with
a similar topology.
FR#3 The solution SHALL ensure that restoration operations happen FR#3 The solution SHALL provide a means to summarize some routing
advertisements regarding the characteristics of an AMG such that
the updated protocol mechanisms maintain convergence times within
the timeframe needed to meet or not significantly exceed existing
Performance Objective for convergence on the same network or
convergence on a network with a similar topology.
FR#4 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 restoration Objective for restoration time on the same network or restoration
time on a network with a similar topology. time on a network with a similar topology.
FR#4 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 of
the other requirements stated above. The solution SHOULD work in the other requirements stated above. The solution SHOULD work in
a manner similar to existing multipath techniques except as a manner similar to existing multipath techniques except as
necessary to accommodate advanced multipath requirements. necessary to accommodate Advanced Multipath requirements.
FR#5 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#6 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 stability
and traffic reordering continue to meet Performance Objective on and traffic reordering continue to meet Performance Objective on
the same network or on a network with a similar topology. Since the same network or on a network with a similar topology. Since
oscillation may cause reordering, there MUST be means to control oscillation may cause reordering, there MUST be means to control
the frequency of changing the component link over which a flow is the frequency of changing the component link over which a flow is
placed. placed.
FR#7 Management and diagnostic protocols MUST be able to operate FR#8 Management and diagnostic protocols MUST be able to operate
over advanced multipaths. 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 Multipaths. Scalability and networks which support Advanced Multipath. Scalability and stability
stability are covered in more detail in are covered in more detail in [I-D.ietf-rtgwg-cl-framework].
[I-D.ietf-rtgwg-cl-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-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#9 The solution SHALL specify a protocol means to allow a server
layer server network to communicate latency to the higher layer layer network to communicate latency to the client layer network.
client network.
FR#9 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 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 or ultimately
for a flow can be chosen from a set of candidate nodes connected via lead to a common destination.
advanced multipaths, other techniques have been developed. Refer to
the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a description of
existing techniques and a set of references.
FR#10 The solution SHALL provide a means to indicate that a client FR#11 In requirements that follow in this document the word
LSP will traverse a component link with the minimum latency "indicate" is used where information may be provided by either
value. This will provide a means by which minimum latency the combination of link state IGP advertisement and MPLS LSP
Performance Objectives of flows within the client LSP can be signaling or via management plane protocols. In later documents
supported. providing framework and protocol definitions both signaling and
management plane mechanisms MUST be defined.
FR#11 The solution SHALL provide a means to indicate that a client FR#12 The solution SHALL provide a means for the client layer to
LSP will traverse a component link with a maximum acceptable indicate a requirement that a client LSP will traverse a
latency value as specified by protocol. This will provide a component link with the minimum latency value. This will provide
means by which bounded latency Performance Objectives of flows a means by which minimum latency Performance Objectives of flows
within the client LSP can be supported. within the client LSP can be supported.
FR#12 The solution SHALL provide a means to indicate that a client FR#13 The solution SHALL provide a means for the client layer to
LSP will traverse a component link with a maximum acceptable indicate a requirement that a client LSP will traverse a
delay variation value as specified by protocol. component link with a maximum acceptable latency value as
specified by protocol. This will provide a means by which
bounded latency Performance Objectives of flows within the client
LSP can be supported.
FR#14 The solution SHALL provide a means for the client layer to
indicate a requirement that a client LSP will traverse a
component link with a maximum acceptable delay variation value as
specified by protocol.
The above set of requirements apply to component links with different The above set of requirements apply to component links with different
characteristics regardless as to whether those component links are characteristics regardless as to whether those component links are
provided by parallel physical links between nodes or provided by sets provided by parallel physical links between nodes or provided by sets
of paths across a network provided by server layer LSP. of paths across a network provided by 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.
skipping to change at page 9, line 5 skipping to change at page 10, line 5
any other case where symmetric delay is highly desirable. There may any other case where symmetric delay is highly desirable. There may
be other uses of this capability. 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 IPv4 Time to Live (TTL) or channel in cases such OAM protocols using IPv4 Time to Live (TTL) or
IPv4 Hop Limit to monitor or diagnose the underlying path. There may IPv4 Hop Limit to monitor or diagnose the underlying path. There may
be other uses of this capability. be other uses of this capability.
FR#13 The solution MUST support an optional means for client LSP FR#15 The solution SHALL provide a means for the client layer to
signaling to bind a client LSP to a particular component link indicate a requirement that a client LSP be bound to a particular
within an advanced multipath. If this option is not exercised, component link within an AMG. 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 carried over an AMG may be bound to any
bound to any component link matching all other signaled component link or set of component links matching all other
requirements, and different directions of a bidirectional client signaled requirements, and different directions of a
LSP can be bound to different component links. bidirectional client LSP can be bound to different component
links.
FR#14 The solution MUST support a means to indicate that both FR#16 The solution MUST support a means for the client layer to
directions of co-routed bidirectional client LSP MUST be bound to indicate a requirement that for a specific co-routed
the same set of nodes. bidirectional client LSP both directions of the co-routed
bidirectional client LSP MUST be bound to the same set of nodes.
FR#15 A client LSP which is bound to a specific component link SHOULD FR#17 A client LSP which 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 a
congested state if congestion is avoidable. 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 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 an bidirectional client LSP to take
skipping to change at page 9, line 40 skipping to change at page 10, line 42
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#16 The solution SHALL provide a means that indicates whether any FR#18 The solution SHALL provide a means for the client layer to
of the LSP within an client LSP MUST NOT be split across multiple indicate a requirement that a specific client LSP MUST NOT be
component links. split across multiple component links.
FR#17 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 the
advanced multipath such that Performance Objectives are met as AMG such that Performance Objectives are met as described in
described in prior requirements in Section 3.3. prior requirements in Section 3.3.
FR#18 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 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 AMG between a pair of nodes is overloaded.
overloaded.
FR#19 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 advanced multipath between a set of nodes, it MUST be in the same AMG between a set of nodes, it MUST be done so in a
done so in a minimally disruptive manner. minimally disruptive manner.
FR#20 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 of
power reduction. power reduction.
FR#21 The solution SHALL provide a means to identify client LSPs FR#23 The solution SHALL provide a means for the client layer to
containing traffic flows whose rearrangement frequency needs to indicate a requirement that a specific client LSP contains
be bounded by a specific value and MUST provide a means to bound traffic whose frequency of component link change due to load
the rearrangement frequency for traffic flows within these client balancing needs to be bounded by a specific value. The solution
LSP. MUST provide a means to bound the frequency of component link
change due to load balancing for subsets of traffic flow on AMGs.
FR#22 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 an client
LSP exceeds that of any component link in the advanced multipath. LSP exceeds that of any component link in the AMG.
FR#23 The solution SHOULD support the use case where an advanced FR#25 The solution SHOULD support the use case where an AMG itself is
multipath itself is a component link for a higher order advanced a component link for a higher order AMG. For example, an AMG
multipath. For example, an advanced multipath comprised of MPLS- comprised of MPLS-TP bi-directional tunnels viewed as logical
TP bi-directional tunnels viewed as logical links could then be links could then be used as a component link in yet another AMG
used as a component link in yet another advanced multipath that that connects MPLS routers.
connects MPLS routers.
FR#24 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 advanced multipath, the solution SHOULD define a capacity of the AMG, the solution SHOULD define a means to cause
means to cause some client LSP to move to an alternate set of some client LSP to move to an alternate set of paths that are not
paths that are not congested. These "preempted LSP" may not be congested. These "preempted LSP" may not be restored if there is
restored if there is no uncongested path in the network. 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 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 35 skipping to change at page 12, line 32
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 advanced multipath. Function requirements SHOULD, where on an AMG. Function requirements SHOULD, where possible, be
possible, be accommodated in a manner that supports LDP signaled accommodated in a manner that supports LDP signaled LSP, RSVP
LSP, RSVP signaled LSP, and LSP set up using management plane 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 AMG are in the same routing
same MPLS network topology, the solution MAY define extensions to domain, the solution MAY define extensions to the IGP.
the IGP.
GR#5 When the nodes are connected via an advanced multipath are in GR#5 When the nodes are connected via an AMG are in different MPLS
different MPLS network topologies, the solution SHALL NOT rely on network topologies, the solution SHALL NOT rely on extensions to
extensions to the IGP. the IGP.
GR#6 The solution SHOULD support advanced multipath IGP GR#6 The solution SHOULD support AMG IGP advertisement that results
advertisement that results in convergence time better than that in convergence time better than that of advertising the
of advertising the individual component links. The solution individual component links. The solution SHALL be designed so
SHALL be designed so that it represents the range of capabilities that it represents the range of capabilities of the individual
of the individual component links such that functional component links such that functional requirements are met, and
requirements are met, and also minimizes the frequency of also minimizes the frequency of advertisement updates which may
advertisement updates which may cause IGP convergence to occur. 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 in
component link characteristics (e.g., latency, up/down state), component link characteristics (e.g., latency, up/down state),
and/or bandwidth utilization. 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 RSVP-
TE client LSPs to be resignaled will cause a period of 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
skipping to change at page 12, line 28 skipping to change at page 13, line 25
without significantly relaxing those existing Performance without significantly relaxing those existing Performance
Objectives for the same network or for networks with similar Objectives for the same network or for networks with similar
topology. For example, the processing load due to IGP topology. For example, the processing load due to IGP
readvertisement MUST NOT increase significantly and the readvertisement MUST NOT increase significantly and the
resignaling time of the solution MUST NOT increase significantly resignaling time of the solution MUST NOT increase significantly
as compared with current methods. as compared with current methods.
5. Management Requirements 5. Management Requirements
MR#1 Management Plane MUST support polling of the status and MR#1 Management Plane MUST support polling of the status and
configuration of an advanced multipath and its individual configuration of an AMG and its individual component links and
advanced multipath 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 Management Plane MUST be able to activate or de-activate any
component link in an advanced multipath in order to facilitate component link in an AMG in order to facilitate operation
operation maintenance tasks. The routers at each end of an maintenance tasks. The routers at each end of an AMG MUST
advanced multipath MUST redistribute traffic to move traffic from redistribute traffic to move traffic from a de-activated link to
a de-activated link to other component links based on the traffic other component links based on the traffic flow TE criteria.
flow TE criteria.
MR#3 Management Plane MUST be able to configure a client LSP over an MR#3 Management Plane MUST be able to configure a client LSP over an
advanced multipath and be able to select a component link for the AMG and be able to select a component link for the client LSP.
client LSP.
MR#4 Management Plane MUST be able to trace which component link a MR#4 Management Plane MUST be able to trace which component link a
client LSP is assigned to and monitor individual component link client LSP is assigned to and monitor individual component link
and advanced multipath performance. and AMG performance.
MR#5 Management Plane MUST be able to verify connectivity over each MR#5 Management Plane MUST be able to verify connectivity over each
individual component link within an advanced multipath. 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 Advanced multipath fault notification MUST be sent to the MR#7 AMG fault notification MUST be sent to the management plane and
management plane and MUST be distributed via link state message 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.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
 End of changes. 55 change blocks. 
157 lines changed or deleted 186 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/