< draft-ietf-rtgwg-cl-requirement-10.txt   draft-ietf-rtgwg-cl-requirement-11.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: September 23, 2013 Verizon Expires: January 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
March 22, 2013 July 11, 2013
Requirements for Composite Links in MPLS Networks Requirements for Advanced Multipath in MPLS Networks
draft-ietf-rtgwg-cl-requirement-10 draft-ietf-rtgwg-cl-requirement-11
Abstract Abstract
There is often a need to provide large aggregates of bandwidth that This document provides a set of requirements for Advanced Multipath
are best provided using parallel links between routers or MPLS LSR. in MPLS Networks.
In core networks there is often no alternative since the aggregate
capacities of core networks today far exceed the capacity of a single
physical link or single packet processing element.
The presence of parallel links, with each link potentially comprised Advanced Multipath is a formalization of multipath techniques
of multiple layers has resulted in additional requirements. Certain currently in use in IP and MPLS networks and a set of extensions to
services may benefit from being restricted to a subset of the existing multipath techniques.
component links or a specific component link, where component link
characteristics, such as latency, differ. Certain services require
that an LSP be treated as atomic and avoid reordering. Other
services will continue to require only that reordering not occur
within a microflow as is current practice.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 23, 2013.
This Internet-Draft will expire on January 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Functional Requirements . . . . . . . . . . . . . . . . . . . 6
4. Network Operator Functional Requirements . . . . . . . . . . . 5 3.1. Availability, Stability and Transient Response . . . . . . 6
4.1. Availability, Stability and Transient Response . . . . . . 5 3.2. Component Links Provided by Lower Layer Networks . . . . . 7
4.2. Component Links Provided by Lower Layer Networks . . . . . 6 3.3. Parallel Component Links with Different Characteristics . 8
4.3. Parallel Component Links with Different Characteristics . 8 4. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 11
5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 10 5. Management Requirements . . . . . . . . . . . . . . . . . . . 12
6. Management Requirements . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. ITU-T G.800 Composite Link Definitions and
Terminology . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The purpose of this document is to describe why network operators There is often a need to provide large aggregates of bandwidth that
require certain functions in order to solve certain business problems are best provided using parallel links between routers or carrying
(Section 2). The intent is to first describe why things need to be traffic over multiple MPLS LSP. In core networks there is often no
done in terms of functional requirements that are as independent as alternative since the aggregate capacities of core networks today far
possible of protocol specifications (Section 4). For certain exceed the capacity of a single physical link or single packet
functional requirements this document describes a set of derived processing element.
protocol requirements (Section 5). Appendix A provides a summary of
G.800 terminology used to define a composite link. The presence of parallel links, with each link potentially comprised
of multiple layers has resulted in additional requirements. Certain
services may benefit from being restricted to a subset of the
component links or a specific component link, where component link
characteristics, such as latency, differ. Certain services require
that an LSP be treated as atomic and avoid reordering. Other
services will continue to require only that reordering not occur
within a microflow as is current practice.
The purpose of this document is to clearly enumerate a set of
requirements related to the protocols and mechanisms that provide
MPLS based Advanced Multipath. The intent is to first provide a set
of functional requirements that are as independent as possible of
protocol specifications (Section 3). For certain functional
requirements this document describes a set of derived protocol
requirements (Section 4) and management requirements (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].
2. Assumptions Any statement which requires the solution to support some new
functionality through use of [RFC2119] keywords, SHOULD be
interpretted as follows. The implementation either MUST or SHOULD
support the new functionality depending on the use of either MUST or
SHOULD in the requirements statement. The implementation SHOULD in
most or all cases allow any new functionality to be individually
enabled or disabled through configuration. A service provider or
other deployment MAY choose to enable or disable any feature in their
network, subject to implementation limitations on sets of features
which can be disabled.
The services supported include pseudowire based services (RFC 3985 2. Definitions
[RFC3985]), including VPN services, Internet traffic encapsulated by Multipath
at least one MPLS label (RFC 3032 [RFC3032]), and dynamically The term multipath includes all techniques in which
signaled MPLS (RFC 3209 [RFC3209] or RFC 5036 [RFC5036]) or MPLS-TP
LSPs (RFC 5921 [RFC5921]). The MPLS LSPs supporting these services
may be point-to-point, point-to-multipoint, or multipoint-to-
multipoint.
The locations in a network where these requirements apply are a Label 1. Traffic can take more than one path from one node to a
Edge Router (LER) or a Label Switch Router (LSR) as defined in RFC destination.
3031 [RFC3031].
The IP DSCP cannot be used for flow identification since L3VPN 2. Individual packets take one path only. Packets are not
requires Diffserv transparency (see RFC 4031 5.5.2 [RFC4031]), and in subdivided and reassembled at the receiving end.
general network operators do not rely on the DSCP of Internet
packets.
3. Definitions 3. Packets are not resequenced at the receiving end.
ITU-T G.800 Based Composite and Component Link Definitions: 4. The paths may be:
Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite and
component links as summarized in Appendix A. The following
definitions for composite and component links are derived from
and intended to be consistent with the cited ITU-T G.800
terminology.
Composite Link: A composite link is a logical link composed of a a. parallel links between two nodes, or
set of parallel point-to-point component links, where all
links in the set share the same endpoints. A composite link
may itself be a component of another composite link, but only
a strict hierarchy of links is allowed.
Component Link: A point-to-point physical link (including one or b. may be specific paths across a network to a destination
more link layer) or a logical link that preserves ordering in node, or
the steady state. A component link may have transient out of
order events, but such events must not exceed the network's
specific NPO. Examples of a physical link are: any set of
link layers over a WDM wavelength or any supportable
combination of Ethernet PHY, PPP, SONET or OTN over a
physical link. Examples of a logical link are: MPLS LSP,
Ethernet VLAN, MPLS-TP LSP. A set of link layers supported
over pseudowire is a logical link that appears to the client
to be a physical link.
Flow: A sequence of packets that must be transferred in order on one c. may be links or paths to an intermediate node used to
component link. reach a common destination.
Flow identification: The label stack and other information that The paths need not have equal capacity. The paths may or may not
uniquely identifies a flow. Other information in flow have equal cost in a routing protocol.
identification may include an IP header, PW control word,
Ethernet MAC address, etc. Note that an LSP may contain one or
more Flows or an LSP may be equivalent to a Flow. Flow
identification is used to locally select a component link, or a
path through the network toward the destination.
Network Performance Objective (NPO): Numerical values for Advanced Multipath
performance measures, principally availability, latency, and Advanced Multipath meets the requirements defined in this
delay variation. See [I-D.ietf-rtgwg-cl-use-cases] for more document. A key capability of advanced multipath is the support
details. of non-homogeneous component links.
4. Network Operator Functional Requirements Composite Link
The term Composite Link had been a registered trademark of Avici
Systems, but was abandoned in 2007. The term composite link is
now defined by the ITU in [ITU-T.G.800]. The ITU definition
includes multipath as defined here, plus inverse multiplexing
which is explicitly excluded from the definition of multipath.
Inverse Multiplexing
Inverse multiplexing either transmits whole packets and
resequences the packets at the receiving end or subdivides
packets and reassembles the packets at the receiving end.
Inverse multiplexing requires that all packets be handled by a
common egress packet processing element and is therefore not
useful for very high bandwidth applications.
Component Link
The ITU definition of composite link in [ITU-T.G.800] and the
IETF definition of link bundling in [RFC4201] both refer to an
individual link in the composite link or link bundle as a
component link. The term component link is applicable to all
forms of multipath. The IEEE uses the term member rather than
component link in Ethernet Link Aggregation [IEEE-802.1AX].
Client LSP
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
has been set up over a multipath as opposed to an LSP
representing the multipath itself or any LSP supporting a
component links of that multipath.
Flow
A sequence of packets that should be transferred in order on one
component link of a multipath.
Flow identification
The label stack and other information that uniquely identifies a
flow. Other information in flow identification may include an IP
header, pseudowire (PW) control word, Ethernet MAC address, etc.
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
locally select a component link, or a path through the network
toward the destination.
Load Balance
Load split, load balance, or load distribution refers to
subdividing traffic over a set of component links such that load
is fairly evenly distributed over the set of component links and
certain packet ordering requirements are met. Some existing
techniques better acheive these objectives than others.
Performance Objective
Numerical values for performance measures, principally
availability, latency, and delay variation. Performance
objectives may be related to Service Level Agreements (SLA) as
defined in RFC2475 or may be strictly internal. Performance
objectives may span links, edge-to-edge, or end-to-end.
Performance objectives may span one provider or may span multiple
providers.
A Component Link may be a point-to-point physical link (where a
"physical link" includes one or more link layer plus a physical
layer) or a logical link that preserves ordering in the steady state.
A component link may have transient out of order events, but such
events must not exceed the network's Performance Objectives. For
example, a compoent link may be comprised of any supportable
combination of link layers over a physical layer or over logical sub-
layers, including those providing physical layer emulation.
The ingress and egress of a multipath may be midpoint LSRs with
respect to a given client LSP. A midpoint LSR does not participate
in the signaling of any clients of the client LSP. Therefore, in
general, multipath endpoints cannot determine requirements of clients
of a client LSP through participation in the signaling of the clients
of the client LSP.
The term Advanced Multipath is intended to be used within the context
of this document and the related documents,
[I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and
any other related document. Other advanced multipath techniques may
in the future arise. If the capabilities defined in this document
become commonplace, they would no longer be considered "advanced".
Use of the term "advanced multipath" outside this document, if
refering to the term as defined here, should indicate Advanced
Multipath as defined by this document, citing the current document
name. If using another definition of "advanced multipath", documents
may optionally clarify that they are not using the term "advanced
multipath" as defined by this document if clarification is deemed
helpful.
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.
4.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. The transient period between some service disrupting
event and the convergence of the routing and/or signaling protocols event and the convergence of the routing and/or signaling protocols
MUST occur within a time frame specified by NPO values. MUST occur within a time frame specified by Performance Objective
[I-D.ietf-rtgwg-cl-use-cases] provides references and a summary of values.
service types requiring a range of restoration times.
FR#1 The solution SHALL provide a means to summarize some routing FR#1 An advanced multipath MAY be announced in conjunction with
advertisements regarding the characteristics of a composite detailed parameters about its component links, such as
link such that the routing protocol converges within the bandwidth and latency. The advanced multipath SHALL behave as
timeframe needed to meet the network performance objective. A a single IGP adjacency.
composite link CAN be announced in conjunction with detailed
parameters about its component links, such as bandwidth and
latency. The composite link SHALL behave as a single IGP
adjacency.
FR#2 The solution SHALL ensure that all possible restoration FR#2 The solution SHALL provide a means to summarize some routing
operations happen within the timeframe needed to meet the NPO. advertisements regarding the characteristics of an advanced
The solution may need to specify a means for aggregating multipath such that the updated protocol mechanisms maintain
signaling to meet this requirement. convergence times within the timeframe needed to meet or no
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 provide a mechanism to select a path for a FR#3 The solution SHALL ensure that restoration operations happen
within the timeframe needed to meet existing Performance
Objective for restoration time on the same network or
restoration time on a network with a similar topology.
FR#4 The solution SHALL provide a mechanism to select a path for a
flow across a network that contains a number of paths comprised flow across a network that contains a number of paths comprised
of pairs of nodes connected by composite links in such a way as of pairs of nodes connected by advanced multipath in such a way
to automatically distribute the load over the network nodes as to automatically distribute the load over the network nodes
connected by composite links while meeting all of the other connected by advanced multipaths while meeting all of the other
mandatory requirements stated above. The solution SHOULD work mandatory requirements stated above. The solution SHOULD work
in a manner similar to that of current networks without any in a manner similar to that of current networks without any
composite link protocol enhancements when the characteristics advanced multipath protocol enhancements when the
of the individual component links are advertised. characteristics of the individual component links are
advertised.
FR#4 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#5 Any automatic LSP routing and/or load balancing solutions MUST FR#6 Any load balancing solutions MUST NOT oscillate. Some change
NOT oscillate such that performance observed by users changes in path MAY occur. The solution MUST ensure that path
such that an NPO is violated. Since oscillation may cause stability and traffic reordering continue to meet Performance
reordering, there MUST be means to control the frequency of Objective on the same network or on a network with a similar
changing the component link over which a flow is placed. topology. Since oscillation may cause reordering, there MUST
be means to control the frequency of changing the component
link over which a flow is placed.
FR#6 Management and diagnostic protocols MUST be able to operate FR#7 Management and diagnostic protocols MUST be able to operate
over composite links. over advanced multipaths.
Existing scaling techniques used in MPLS networks apply to MPLS Existing scaling techniques used in MPLS networks apply to MPLS
networks which support Composite Links. Scalability and stability networks which support Advanced Multipaths. Scalability and
are covered in more detail in [I-D.ietf-rtgwg-cl-framework]. stability are covered in more detail in
[I-D.ietf-rtgwg-cl-framework].
4.2. Component Links Provided by Lower Layer Networks 3.2. Component Links Provided by Lower Layer Networks
Case 3 as defined in [ITU-T.G.800] involves a component link A component link may be supported by a lower layer network. For
supporting an MPLS layer network over another lower layer network example, the lower layer may be a circuit switched network or another
(e.g., circuit switched or another MPLS network (e.g., MPLS-TP)). MPLS network (e.g., MPLS-TP)). The lower layer network may change
The lower layer network may change the latency (and/or other the latency (and/or other performance parameters) seen by the client
performance parameters) seen by the MPLS layer network. Network layer. Currently, there is no protocol for the lower layer network
Operators have NPOs of which some components are based on performance to inform the higher layer network of a change in a performance
parameters. Currently, there is no protocol for the lower layer parameter. Communication of the latency performance parameter is a
network to inform the higher layer network of a change in a very important requirement. Communication of other performance
performance parameter. Communication of the latency performance parameters (e.g., delay variation) is desirable.
parameter is a very important requirement. Communication of other
performance parameters (e.g., delay variation) is desirable.
FR#7 In order to support network NPOs and provide acceptable user FR#8 The solution SHALL specify a protocol means to allow a lower
experience, the solution SHALL specify a protocol means to layer server network to communicate latency to the higher
allow a lower layer server network to communicate latency to layer client network.
the higher layer client network.
FR#8 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 ms or more. latency of 1 ms or more.
FR#9 The solution SHALL provide a means to limit the latency on a FR#10 The solution SHALL provide a means to limit the latency to
per LSP basis between nodes within a network to meet an NPO meet a Performance Objective target on a per flow basis or
target when the path between these nodes contains one or more group of flow basis, where flows or groups of flows are
pairs of nodes connected via a composite link. identifiable in the forwarding plane and are signaled using in
the control plane or set up using the management plane.
The NPOs differ across the services, and some services have The Performance Objectives differ across the services, and
different NPOs for different QoS classes, for example, one QoS some services have different Performance Objectives for
class may have a much larger latency bound than another. different QoS classes, for example, one QoS class may have a
Overload can occur which would violate an NPO parameter (e.g., much larger latency bound than another. Overload can occur
loss) and some remedy to handle this case for a composite link which would violate a Performance Objective parameter (e.g.,
is required. loss) and some remedy to handle this case for an advanced
multipath is required.
FR#10 If the total demand offered by traffic flows exceeds the FR#11 If the total demand offered by traffic flows exceeds the
capacity of the composite link, the solution SHOULD define a capacity of the advanced multipath, the solution SHOULD define
means to cause the LSPs for some traffic flows to move to some a means to cause some traffic flows or groups of flows to move
other point in the network that is not congested. These to some other point in the network that is not congested.
"preempted LSPs" may not be restored if there is no These "preempted flows" may not be restored if there is no
uncongested path in the network. 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].
4.3. Parallel Component Links with Different Characteristics 3.3. Parallel Component Links with Different Characteristics
Corresponding to Case 1 of [ITU-T.G.800], as one means to provide As one means to provide high availability, network operators deploy a
high availability, network operators deploy a topology in the MPLS topology in the MPLS network using lower layer networks that have a
network using lower layer networks that have a certain degree of certain degree of diversity at the lower layer(s). Many techniques
diversity at the lower layer(s). Many techniques have been developed have been developed to balance the distribution of flows across
to balance the distribution of flows across component links that component links that connect the same pair of nodes. When the path
connect the same pair of nodes. When the path for a flow can be for a flow can be chosen from a set of candidate nodes connected via
chosen from a set of candidate nodes connected via composite links, advanced multipaths, other techniques have been developed. Refer to
other techniques have been developed. Refer to the Appendices in the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a description of
[I-D.ietf-rtgwg-cl-use-cases] for a description of existing existing techniques and a set of references.
techniques and a set of references.
FR#11 The solution SHALL measure traffic on a labeled traffic flow FR#12 The solution SHALL measure traffic flows or groups of traffic
and dynamically select the component link on which to place flows and dynamically select the component link on which to
this flow in order to balance the load so that no component place this traffic in order to balance the load so that no
link in the composite link between a pair of nodes is component link in the advanced multipath between a pair of
overloaded. nodes is overloaded.
FR#12 When a traffic flow is moved from one component link to FR#13 When a traffic flow is moved from one component link to
another in the same composite link between a set of nodes (or another in the same advanced multipath between a set of nodes
sites), it MUST be done so in a minimally disruptive manner. (or sites), it MUST be done so in a minimally disruptive
manner.
FR#13 Load balancing MAY be used during sustained low traffic FR#14 Load balancing MAY be used during sustained low traffic
periods to reduce the number of active component links for the periods to reduce the number of active component links for the
purpose of power reduction. purpose of power reduction.
FR#14 The solution SHALL provide a means to identify flows whose FR#15 The solution SHALL provide a means to identify flows whose
rearrangement frequency needs to be bounded by a configured rearrangement frequency needs to be bounded by a configured
value. value and MUST provide a means to bound the rearrangement
frequency for these flows.
FR#15 The solution SHALL provide a means that communicates whether FR#16 The solution SHALL provide a means that communicates whether
the flows within an LSP can be split across multiple component the flows within an client LSP can be split across multiple
links. The solution SHOULD provide a means to indicate the component links. The solution SHOULD provide a means to
flow identification field(s) which can be used along the flow indicate the flow identification field(s) which can be used
path which can be used to perform this function. along the flow path which can be used to perform this
function.
FR#16 The solution SHALL provide a means to indicate that a traffic FR#17 The solution SHALL provide a means to indicate that a traffic
flow shall select a component link with the minimum latency flow will traverse a component link with the minimum latency
value. value.
FR#17 The solution SHALL provide a means to indicate that a traffic FR#18 The solution SHALL provide a means to indicate that a traffic
flow shall select a component link with a maximum acceptable flow will traverse a component link with a maximum acceptable
latency value as specified by protocol. latency value as specified by protocol.
FR#18 The solution SHALL provide a means to indicate that a traffic FR#19 The solution SHALL provide a means to indicate that a traffic
flow shall select a component link with a maximum acceptable flow will traverse a component link with a maximum acceptable
delay variation value as specified by protocol. delay variation value as specified by protocol.
FR#19 The solution SHALL provide a means local to a node that FR#20 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 composite link such that NPOs are met. the advanced multipath such that Performance Objectives are
met as described in prior requirements.
FR#20 The solution SHALL provide a means to distribute flows from a FR#21 The solution SHALL provide a means to distribute flows from a
single LSP across multiple component links to handle at least single client LSP across multiple component links to handle at
the case where the traffic carried in an LSP exceeds that of least the case where the traffic carried in an client LSP
any component link in the composite link. As defined in exceeds that of any component link in the advanced multipath.
section 3, a flow is a sequence of packets that must be As defined in Section 2, a flow is a sequence of packets that
transferred on one component link. should be transferred on one component link and should be
transferred in order.
FR#21 The solution SHOULD support the use case where a composite FR#22 The solution SHOULD support the use case where an advanced
link itself is a component link for a higher order composite multipath itself is a component link for a higher order
link. For example, a composite link comprised of MPLS-TP bi- advanced multipath. For example, an advanced multipath
directional tunnels viewed as logical links could then be used comprised of MPLS-TP bi-directional tunnels viewed as logical
as a component link in yet another composite link that links could then be used as a component link in yet another
connects MPLS routers. advanced multipath that connects MPLS routers.
FR#22 The solution MUST support an optional means for LSP signaling FR#23 The solution MUST support an optional means for client LSP
to bind an LSP to a particular component link within a signaling to bind a client LSP to a particular component link
composite link. If this option is not exercised, then an LSP within an advanced multipath. If this option is not
that is bound to a composite link may be bound to any exercised, then a client LSP that is bound to an advanced
component link matching all other signaled requirements, and multipath may be bound to any component link matching all
different directions of a bidirectional LSP can be bound to other signaled requirements, and different directions of a
different component links. bidirectional client LSP can be bound to different component
links.
FR#23 The solution MUST support a means to indicate that both FR#24 The solution MUST support a means to indicate that both
directions of co-routed bidirectional LSP MUST be bound to the directions of co-routed bidirectional client LSP MUST be bound
same component link. 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
following effect. When a flow is moved from a current link to a following effect. When a flow is moved from a current link to a
target link with lower latency, reordering can occur. When a flow is target link with lower latency, reordering can occur. When a flow is
moved from a current link to a target link with a higher latency, a moved from a current link to a target link with a higher latency, a
time gap can occur. Some flows (e.g., timing distribution, PW time gap can occur. Some flows (e.g., timing distribution, PW
circuit emulation) are quite sensitive to these effects. A delay circuit emulation) are quite sensitive to these effects. A delay
discontinuity can also cause a jitter buffer underrun or overrun discontinuity can also cause a jitter buffer underrun or overrun
affecting user experience in real time voice services (causing an affecting user experience in real time voice services (causing an
audible click). These sensitivities may be specified in an NPO. audible click). These sensitivities may be specified in a
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.
5. Derived Requirements 4. Derived Requirements
This section takes the next step and derives high-level requirements This section takes the next step and derives high-level requirements
on protocol specification from the functional requirements. on protocol specification from the functional requirements.
DR#1 The solution SHOULD attempt to extend existing protocols DR#1 The solution SHOULD attempt to extend existing protocols
wherever possible, developing a new protocol only if this adds wherever possible, developing a new protocol only if this adds
a significant set of capabilities. a significant set of capabilities.
DR#2 A solution SHOULD extend LDP capabilities to meet functional DR#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 DR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported
on a composite link. Other functional requirements should be on an advanced multipath. Other functional requirements should
supported as independently of signaling protocol as possible. be supported as independently of signaling protocol as
possible.
DR#4 When the nodes connected via a composite link are in the same DR#4 When the nodes connected via an advanced multipath are in the
MPLS network topology, the solution MAY define extensions to same MPLS network topology, the solution MAY define extensions
the IGP. to the IGP.
DR#5 When the nodes are connected via a composite link are in DR#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 composite link IGP advertisement DR#6 The solution SHOULD support advanced multipath IGP
that results in convergence time better than that of advertisement that results in convergence time better than that
advertising the individual component links. The solution SHALL of advertising the individual component links. The solution
be designed so that it represents the range of capabilities of SHALL be designed so that it represents the range of
the individual component links such that functional capabilities of the individual component links such that
requirements are met, and also minimizes the frequency of functional requirements are met, and also minimizes the
advertisement updates which may cause IGP convergence to occur. frequency of advertisement updates which may cause IGP
convergence to occur.
Examples of advertisement update triggering events to be Examples of advertisement update triggering events to be
considered include: LSP establishment/release, changes in considered include: client LSP establishment/release, changes
component link characteristics (e.g., latency, up/down state), in component link characteristics (e.g., latency, up/down
and/or bandwidth utilization. state), and/or bandwidth utilization.
DR#7 When a worst case failure scenario occurs, the number of DR#7 When a worst case failure scenario occurs, the number of
RSVP-TE 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 meet the NPO objective for the duration of the solution MUST support protocol mechanisms meeting existing
unavailability. The resignaling time of the solution MUST NOT provider Performance Objective for the duration of
increase significantly as compared with current methods. unavailability without significantly relaxing those existing
Performance Objectives for the same network or for networks
6. Management Requirements with similar topology. For example, the processing load due to
IGP readvertisement MUST NOT increase significantly and the
resignaling time of the solution MUST NOT increase
significantly as compared with current methods.
MR#1 Management Plane MUST support polling of the status and 5. Management Requirements
configuration of a composite link and its individual composite
link and support notification of status change.
MR#2 Management Plane MUST be able to activate or de-activate any MR#1 Management Plane MUST support polling of the status and
component link in a composite link in order to facilitate configuration of an advanced multipath and its individual
operation maintenance tasks. The routers at each end of a advanced multipath and support notification of status change.
composite link MUST redistribute traffic to move traffic from
a de-activated link to other component links based on the
traffic flow TE criteria.
MR#3 Management Plane MUST be able to configure a LSP over a MR#2 Management Plane MUST be able to activate or de-activate any
composite link and be able to select a component link for the component link in an advanced multipath in order to facilitate
LSP. operation maintenance tasks. The routers at each end of an
advanced multipath MUST redistribute traffic to move traffic
from a de-activated link to other component links based on the
traffic flow TE criteria.
MR#4 Management Plane MUST be able to trace which component link a MR#3 Management Plane MUST be able to configure a client LSP over an
LSP is assigned to and monitor individual component link and advanced multipath and be able to select a component link for
composite link performance. the client LSP.
MR#5 Management Plane MUST be able to verify connectivity over each MR#4 Management Plane MUST be able to trace which component link a
individual component link within a composite link. client LSP is assigned to and monitor individual component link
and advanced multipath performance.
MR#6 Component link fault notification MUST be sent to the MR#5 Management Plane MUST be able to verify connectivity over each
management plane. individual component link within an advanced multipath.
MR#7 Composite link fault notification MUST be sent to management MR#6 Component link fault notification MUST be sent to the
plane and distribute via link state message in the IGP. management plane.
MR#8 Management Plane SHOULD provide the means for an operator to MR#7 Advanced multipath fault notification MUST be sent to the
initiate an optimization process. management plane and MUST be distributed via link state message
in the IGP.
MR#9 An operator initiated optimization MUST be performed in a MR#8 Management Plane SHOULD provide the means for an operator to
minimally disruptive manner as described in Section 4.3. initiate an optimization process.
MR#10 Any statement which requires the solution to support some new MR#9 An operator initiated optimization MUST be performed in a
functionality through use of the words new functionality, minimally disruptive manner as described in Section 3.3.
SHOULD be interpretted as follows. The implementation either
MUST or SHOULD support the new functionality depending on the
use of either MUST or SHOULD in the requirements statement.
The implementation SHOULD in most or all cases allow any new
functionality to be individually enabled or disabled through
configuration.
7. 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.
Tony Li and John Drake have made numerous valuable comments on the Tony Li and John Drake have made numerous valuable comments on the
skipping to change at page 12, line 40 skipping to change at page 13, line 34
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. Infinera continues to sponsor this work on a consulting
basis. basis.
8. IANA Considerations Tom Yu and Francis Dupont provided the SecDir and GenArt reviews
respectively. Both reviews provided useful comments. Lou Berger
provided the RtgDir review which resulted in substantial
clarification of terminology and document wording, particularly in
the Abstract, Introduction, and Definitions sections.
7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 8. Security Considerations
This document specifies a set of requirements. The requirements The security considerations for MPLS/GMPLS and for MPLS-TP are
themselves do not pose a security threat. If these requirements are documented in [RFC5920] and [RFC6941]. This document does not impact
met using MPLS signaling as commonly practiced today with the security of MPLS, GMPLS, or MPLS-TP.
authenticated but unencrypted OSPF-TE, ISIS-TE, and RSVP-TE or LDP,
then the requirement to provide additional information in this
communication presents additional information that could conceivably
be gathered in a man-in-the-middle confidentiality breach. Such an
attack would require a capability to monitor this signaling either
through a provider breach or access to provider physical transmission
infrastructure. A provider breach already poses a threat of numerous
tpes of attacks which are of far more serious consequence. Encrption
of the signaling can prevent or render more difficult any
confidentiality breach that otherwise might occur by means of access
to provider physical transmission infrastructure.
10. References The additional information that this document requires does not
provide significant additional value to an attacker beyond the
information already typically available from attacking a routing or
signaling protocol. If the requirements of this document are met by
extending an existing routing or signaling protocol, the security
considerations of the protocol being extended apply. If the
requirements of this document are met by specifying a new protocol,
the security considerations of that new protocol should include an
evaluation of what level of protection is required by the additional
information specified in this document, such as data origin
authentication.
10.1. Normative References 9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References 9.2. Informative References
[I-D.ietf-rtgwg-cl-framework] [I-D.ietf-rtgwg-cl-framework]
Ning, S., McDysan, D., Osborne, E., Yong, L., and C. Ning, S., McDysan, D., Osborne, E., Yong, L., and C.
Villamizar, "Composite Link Framework in Multi Protocol Villamizar, "Composite Link Framework in Multi Protocol
Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework-01 Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework-01
(work in progress), August 2012. (work in progress), August 2012.
[I-D.ietf-rtgwg-cl-use-cases] [I-D.ietf-rtgwg-cl-use-cases]
Ning, S., Malis, A., McDysan, D., Yong, L., and C. Ning, S., Malis, A., McDysan, D., Yong, L., and C.
Villamizar, "Composite Link Use Cases and Design Villamizar, "Composite Link Use Cases and Design
Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in Considerations", draft-ietf-rtgwg-cl-use-cases-01 (work in
progress), August 2012. progress), August 2012.
[IEEE-802.1AX]
IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE
Standard for Local and Metropolitan Area Networks - Link
Aggregation", 2006, <http://standards.ieee.org/getieee802/
download/802.1AX-2008.pdf>.
[ITU-T.G.800] [ITU-T.G.800]
ITU-T, "Unified functional architecture of transport ITU-T, "Unified functional architecture of transport
networks", 2007, <http://www.itu.int/rec/T-REC-G/ networks", 2007, <http://www.itu.int/rec/T-REC-G/
recommendation.asp?parent=T-REC-G.800>. recommendation.asp?parent=T-REC-G.800>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS signaling Switching (MPLS) Working Group decision on MPLS signaling
protocols", RFC 3468, February 2003. protocols", RFC 3468, February 2003.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
Edge (PWE3) Architecture", RFC 3985, March 2005. in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer
3 Provider Provisioned Virtual Private Networks (PPVPNs)",
RFC 4031, April 2005.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
Appendix A. ITU-T G.800 Composite Link Definitions and Terminology
Composite Link:
Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite link
in terms of three cases, of which the following two are relevant
(the one describing inverse (TDM) multiplexing does not apply).
Note that these case definitions are taken verbatim from section
6.9, "Layer Relationships".
Case 1: "Multiple parallel links between the same subnetworks
can be bundled together into a single composite link. Each
component of the composite link is independent in the sense
that each component link is supported by a separate server
layer trail. The composite link conveys communication
information using different server layer trails thus the
sequence of symbols crossing this link may not be preserved.
This is illustrated in Figure 14."
Case 3: "A link can also be constructed by a concatenation of
component links and configured channel forwarding
relationships. The forwarding relationships must have a 1:1
correspondence to the link connections that will be provided
by the client link. In this case, it is not possible to
fully infer the status of the link by observing the server
layer trails visible at the ends of the link. This is
illustrated in Figure 16."
Subnetwork: A set of one or more nodes (i.e., LER or LSR) and links.
As a special case it can represent a site comprised of multiple
nodes.
Forwarding Relationship: Configured forwarding between ports on a [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
subnetwork. It may be connectionless (e.g., IP, not considered Networks", RFC 5920, July 2010.
in this draft), or connection oriented (e.g., MPLS signaled or
configured).
Component Link: A topolological relationship between subnetworks [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R.
(i.e., a connection between nodes), which may be a wavelength, Graveman, "MPLS Transport Profile (MPLS-TP) Security
circuit, virtual circuit or an MPLS LSP. Framework", RFC 6941, April 2013.
Authors' Addresses Authors' Addresses
Curtis Villamizar (editor) Curtis Villamizar (editor)
OCCNC, LLC OCCNC, LLC
Email: curtis@occnc.com Email: curtis@occnc.com
Dave McDysan (editor) Dave McDysan (editor)
Verizon Verizon
22001 Loudoun County PKWY 22001 Loudoun County PKWY
Ashburn, VA 20147 Ashburn, VA 20147
USA
Email: dave.mcdysan@verizon.com Email: dave.mcdysan@verizon.com
So Ning So Ning
Tata Communications Tata Communications
Email: ning.so@tatacommunications.com Email: ning.so@tatacommunications.com
Andrew Malis Andrew Malis
Verizon Verizon
60 Sylvan Road 60 Sylvan Road
Waltham, MA 02451 Waltham, MA 02451
USA
Phone: +1 781-466-2362 Phone: +1 781-466-2362
Email: andrew.g.malis@verizon.com Email: andrew.g.malis@verizon.com
Lucy Yong Lucy Yong
Huawei USA Huawei USA
5340 Legacy Dr. 5340 Legacy Dr.
Plano, TX 75025 Plano, TX 75025
USA
Phone: +1 469-277-5837 Phone: +1 469-277-5837
Email: lucy.yong@huawei.com Email: lucy.yong@huawei.com
 End of changes. 89 change blocks. 
356 lines changed or deleted 401 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/