draft-ietf-rtgwg-cl-requirement-00.txt   draft-ietf-rtgwg-cl-requirement-01.txt 
Routing Working Group N. So
Internet Draft A. Malis RTGWG C. Villamizar, Ed.
Intended Status: Standard D. McDysan Internet-Draft Infinera Corporation
Expires: Verizon Intended status: Informational D. McDysan, Ed.
Expires: January 9, 2011 S. Ning
A. Malis
Verizon
L. Yong L. Yong
Huawei Huawei USA
F. Jounay July 8, 2010
France Telecom
Y. Kamite
NTT
February 17, 2010
Requirements for MPLS Over a Composite Link Requirements for MPLS Over a Composite Link
draft-ietf-rtgwg-cl-requirement-01
draft-ietf-rtgwg-cl-requirement-00 Abstract
There is often a need to provide large aggregates of bandwidth that
is best provided using parallel links between routers or MPLS LSR.
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. Furthermore,
links may be composed of network elements operating across multiple
layers.
The presence of parallel links, potentially comprised of multiple
layers has resulted in a additional requirements. Certain services
may benefit from being restricted to a subset of the set of composite
link component links or a specific component link, where component
link characteristics, such as latency, differ. Certain services
require that LSP be treated as atomic and avoid reordering. Other
services will continue to require only that reordering not occur with
a microflow as is current practice.
Current practice related to multipath is described briefly in an
appendix.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 9, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 18, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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.
Abstract
This document presents motivation, a problem statement and
operational requirements for a traffic distribution problem in
today's IP/MPLS network when multiple links are configured between
two routers. It defines a composite link as a group of parallel links
that can be considered as a single traffic engineering link or as an
IP link, and used for MPLS. The framework described in a companion
document is used to organize the requirements.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document..............................4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.1. Acronyms..................................................4 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terminology...............................................4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation and Summary Problem Statement.......................5 4. Network Operator Functional Requirements . . . . . . . . . . . 5
3.1. Motivation................................................5 4.1. Availability, Stability and Transient Response . . . . . . 5
3.2. Summary of Problems Requiring Solution....................7 4.2. Component Links Provided by Lower Layer Networks . . . . . 6
4. Requirements...................................................7 4.3. Parallel Component Links with Different Characteristics . 7
4.1. Interior Functions........................................8 5. Derived Requirements . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Functions common to all LSP flows....................8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1.1. Traffic Flow and Connection Mapping.............9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
4.1.1.2. Management of Other Operational Aspects.........9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4.1.1.2.1. Resilience.................................9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1.2.2. Fault management requirement...............9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
4.1.1.2.3. Flow/Connection Mapping Change Frequency..10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
4.1.2. Functions specific to LSP flows with TE information.11 9.3. Appendix References . . . . . . . . . . . . . . . . . . . 11
4.1.3. Functions specific to LSP flows without TE information12 Appendix A. More Details on Existing Network Operator
4.1.4. Sets of LSP flows with and without TE information...12 Practices and Protocol Usage . . . . . . . . . . . . 12
4.1.4.1. Handling Bandwidth Shortage Events.............13 Appendix B. Existing Multipath Standards and Techniques . . . . . 14
4.2. Exterior Functions.......................................13 B.1. Common Multpath Load Spliting Techniques . . . . . . . . . 15
4.2.1. Functions common to all LSP flows...................13 B.2. Simple and Adaptive Load Balancing Multipath . . . . . . . 16
4.2.1.1. Signaling Protocol Extensions..................13 B.3. Traffic Split over Parallel Links . . . . . . . . . . . . 16
4.2.1.2. Routing Advertisement Extensions...............13 B.4. Traffic Split over Multiple Paths . . . . . . . . . . . . 17
4.2.2. Functions specific to LSP flows with TE information.14 Appendix C. ITU-T G.800 Composite Link Definitions and
4.2.2.1. Signaling Protocol Extensions Requirements.....14 Terminology . . . . . . . . . . . . . . . . . . . . . 17
4.2.2.2. Routing Advertisement Extensions...............15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.3. Functions specific to LSP flows without TE information15
4.2.3.1. Signaling Protocol Extensions..................15
4.2.3.2. Routing Advertisement Extensions...............16
4.2.4. Functions specific to LSP flows with and without TE
information................................................16
4.2.4.1. Signaling Protocol Extensions..................16
4.2.4.2. Routing Advertisement Extensions...............16
5. Security Considerations.......................................16
6. IANA Considerations...........................................16
7. References....................................................17
7.1. Normative References.....................................17
7.2. Informative References...................................17
8. Acknowledgments...............................................18
1. Introduction
IP/MPLS network traffic growth forces carriers to deploy multiple
parallel physical/logical links between adjacent routers as the total
capacity of all aggregated traffic flows exceed the capacity of a
single link. The network is expected to carry aggregated traffic
flows some of which approach the capacity of any single link, and
also some flows that may be very small compared to the capacity of a
single link.
Operating an MPLS network with multiple parallel links between all
adjacent routers causes scaling problems in the routing protocols.
This issue is addressed in [RFC4201] which defines the notion of a
Link Bundle -- a set of identical parallel traffic engineered (TE)
links (called component links) that are grouped together and
advertised as a single TE link within the routing protocol.
The Link Bundle concept is somewhat limited because of the
requirement that all component links must have identical
capabilities, and because it applies only to TE links. This document
sets out a more generic set of requirements for grouping together a
set of parallel data links that may have different characteristics,
and for advertising and operating them as a single TE or non-TE link
called a Composite Link.
First, there is a set of requirements related to the interior
functioning of a router, of which the operational requirement is to
have consistent configuration, reporting and alarm notification. The
functions that impact the routers other than those connected by the
composite link are control plane routing and signaling protocols. A
further subdivision of the requirements is based upon characteristics
of the combination of MPLS signaling protocols in use, namely RSVP-TE
only, LDP only, or a combination of RSVP_TE and LDP. Extension
requirements to IGP-related protocols are also described in this
document. Furthermore, there are requirements that relate to use of
signaling (and possibly routing) that can be used within the same
layer or between layers.
Applicability of the work within this document is focused on MPLS 1. Introduction
traffic as controlled through control plane protocols. Thus, this
document describes requirements related to the routing protocols that
advertise link parameters and the Resource Reservation Protocol
(RSVP-TE) and the Label Distribution Protocol (LDP) signaling
protocols that distribute MPLS labels and establish Label Switched
Paths (LSPs). Interactions between the control plane and the data and
management planes are also addressed. The focus of this document is
on MPLS traffic either signaled by RSVP-TE or LDP. IP traffic over
multiple parallel links is handled relatively well by ECMP or
LAG/hashing methods. The handling of IP control plane traffic is
within the scope of the requirements of this document.
A companion framework document [CLFRAMEWORK] further describes the The purpose of this document is to describe why network operators
overall context, a structure, and some standardization considerations. require certain functions in order to solve certain business problems
Specific protocol solutions are outside the scope of this document. (Section 2). The intent is to first describe why things need to be
done in terms of functional requirements that are as independent as
possible of protocol specifications (Section 4). For certain
functional requirements this document describes a set of derived
protocol requirements (Section 5). Three appendices provide
supporting details as a summary of existing/prior operator
approaches, a summary of implementation techniques and relevant
protocol standards, and a summary of G.800 terminology used to define
the concept of a composite link. (Appendix B).
2. Conventions used in this document 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. document are to be interpreted as described in RFC 2119 [RFC2119].
2.1. Acronyms
BW: Bandwidth
ECMP: Equal Cost Multi-Path
FRR: Fast Re-Route
LAG: Link Aggregation Group
LDP: Label Distribution Protocol
LSP: Label Switched Path
MPLS: Multi-Protocol Label Switching
OAM: Operation, Administration, and Management
PDU: Protocol Data Unit
PE: Provider Edge device
RSVP: ReSource reserVation Protocol
RTD: Real Time Delay
TE: Traffic Engineering
VRF: Virtual Routing and Forwarding
2.2. Terminology
Composite Link: a group of component links, which can be considered
as a single MPLS TE link or as a single IP link used for MPLS. is The
The ITU-T [ITU-T G.800] defines Composite Link Characteristics as
those which makes multiple parallel component links between two
transport nodes appear as a single logical link from the network
perspective. Each component link in a composite link can be
supported by a separate server layer trail, i.e., the component links
in a composite link can have the same or different properties such as
latency and capacity.
Component Link: a physical link (e.g., Lambda, Ethernet PHY, SONET/
SDH, OTN, etc.) with packet transport capability, or a logical link
(e.g., MPLS LSP, Ethernet VLAN, MPLS-TP LSP, etc.)
Connection: An aggregation of traffic flows which are treated
together as a single unit by the composite link Interior Function for
the purpose of routing onto a specific component link and measuring
traffic volume.
Exterior Functions: These are performed by an MPLS router that makes
a composite link useable by the network via control protocols, or by
an MPLS router that interacts with other routers to dynamically
control a component link as part a composite link. These functions
are those that interact via routing and/or signaling protocols with
other routers in the same layer network or other layer networks.
Interior Functions: Actions performed by the MPLS routers directly
connected by a composite link. This includes the determination of the
connection and component link on which a traffic flow is placed.
Although a local implementation matter, the configuration control of
certain aspects of these interior functions is an important
operational requirement.
Traffic Flow: A set of packets that with common identifier
characteristics that the composite link is able to use to aggregate
traffic into Connections. Identifiers can be an MPLS label stack or
any combination of IP addresses and protocol types for routing,
signaling and management packets.
Virtual Interface: Composite link characteristics advertised in IGP
3. Motivation and Summary Problem Statement
3.1. Motivation
There are several established approaches to using multiple parallel
links between a pair of routers. These have limitations as
summarized below.
o ECMP/Hashing/LAG: IP traffic composed of a large number of flows
with bandwidth that is small with respect to the individual link
capacity can be handled relatively well using ECMP/LAG approaches.
However, these approaches do not make use of MPLS control plane
information nor traffic volume information. Distribution
techniques applied only within the data plane can result in less
than ideal load balancing across component links of a composite
link.
o Advertisement of each component link into the IGP. Although this
would address the problem, it has a scaling impact on IGP routing,
and was an important motivation for the specification of link
bundling [RFC4201]. However, there are two gaps in link bundling:
o 1. It only supports RSVP-TE, not LDP.
o 2. It does not support a set of component links with different
characteristics (e.g., different bandwidth and/or latency).
For example, in practice carriers commonly use link bandwidth and
link latency to set link TE metrics for RSVP-TE. For RSVP-TE,
limiting the component links to same TE metric has the practical
effect of dis-allowing component links with different link
bandwidth and latencies.
o Inverse Multiplexing: Making multiple parallel links to appear as
a single link using inverse multiplexing techniques, such as
proposals under discussion in the [PWBONDING]. However, the
inverse multiplexed link will have a latency of the link with the
largest latency. When there is a mix of latency sensitive traffic
with other traffic that is less sensitive to latency, having all
traffic experience the latency of the worst link is not acceptable
to operators.
o Planning Tool LSP Assignment: Although theoretically optimal, an
external system that participates in the IGP, measures traffic and
assigns TE LSPs and/or adjusts IGP metrics has a potentially large
response time to certain failure scenarios. Furthermore, such a
system could make use of more information than provided by link
bundling IGP advertisements and could make use of mechanisms that
would allow pinning MPLS traffic to a particular component link in
a composite link.
o In a multi-layer network, the characteristics of a component link
can be altered by a lower layer network and this can create
significant operational impact in some cases. For example, if a
lower layer network performs restoration and markedly increases
the latency of a link in a link bundle, the traffic placed on this
longer latency link may generate user complaints and/or exceed the
parameters of a Service Level Agreement (SLA).
o In the case where multiple routing instances could share a
composite link, inefficiency can result if either 1) specific
component links are assigned to an individual routing instance, or
2) if statically assigned capacity is made to a logical/sub
interface in each component link of a composite link for each
routing instance. In other words, the issue is that unused
capacity in one routing instance cannot be used by another in
either of these cases.
o Unicast LDP signaled LSP flows follow the IGP determined topology
in a multipoint-to-point manner. The principal means of control of
LDP flows is through adjustment of the IGP metric. The simplicity
of this method is attractive. However, this means that the LDP
flow traffic level can change significantly in response to some
link and/or node failures, thus significantly change the traffic
level at points within a network. A means for operators to better
manage LDP signaled flows is therefore highly desirable.
3.2. Summary of Problems Requiring Solution
The following bullets highlight aspects of solutions for which
detailed requirements are stated in Section 5.
o Ensure the ability to transport both RSVP-TE and LDP signaled non-
TE LSPs on the same composite link (i.e., a single set of
component links) while maintaining acceptable service quality for
both RSVP-TE and LDP signaled LSPs.
o Extend a link bundling type function to scenarios with groups of
links having different characteristics (e.g., bandwidth, latency).
o When an end-to-end LSP signaled by RSVP-TE uses a composite link,
the composite link must select a component link that meets the
end-to-end requirements for the LSP. To perform this function, the
network elements at the end of a composite link must be made aware
of the required, desired, and acceptable link characteristics
(e.g., latency, optimization frequency) for each hop in the path.
The solution should be able to operate in a statically configured
or dynamically signaled manner.
o Support sets of component links between routers across
intermediate nodes at the same and/or lower layers where the
characteristics (e.g., latency) of said links may change
dynamically. The solution should support the case where the
changes in characteristics of these links are not communicated by
the IGP (e.g., a link in a lower layer network has a change in
latency or QoS due to a restoration action). The solution could
measure the performance (e.g., latency), and/or receive the
results of a measurement or computation from lower layer
configuration data via signaling.
4. Requirements
As defined in the terminology section a (traffic) flow is the
smallest unit of traffic assignable to a connection, and connections
are assigned to a component link that is part of a composite link.
The composite link has routing information, normal IGP that has no TE
information and IGP with TE extensions (IGP-TE) and signaling
information with TE information (RSVP-TE) and without TE information.
The following table summarizes the three cases covered in this
requirements section.
Flows IGP IGP-TE RSVP-TE LDP
----------------------- --- ------ ------- ---
With TE Info Y Y Y N
Wihtout TE Info Y N N Y
With & Without TE Info Y Y Y Y
Furthermore, if a requirement would be repeated for each of the above
three cases (e.g., IGP related routing information) it is described
in a section common to all flows.
Therefore, the outline of this section is structured as follows:
o Management/Measurement of Interior Functions
- Functions common to all LSP flows
- Functions specific to LSP flows with TE information
- Functions specific to LSP flows without TE information
- Sets of LSP flows with and without TE information
o Exterior Functions
- Functions common to all LSP flows
- Functions specific to LSP flows with TE information
- Functions specific to LSP flows without TE information
- Sets of LSP flows with and without TE information
4.1. Interior Functions
4.1.1. Functions common to all LSP flows
The operator SHALL be able to configure a "virtual interface"
corresponding to a composite link that has at least all of the normal
IGP routing parameters .
The solution SHALL allow configuration of virtual interface IGP
parameters for a non-TE (i.e., normal IP routing) link used for MPLS
(e.g., administrative cost or weight).
o The solution SHALL support configuration of a composite link
composed of set of component links that may be logical or
physical.
The "virtual interface" SHALL appear as a fully-featured routing
adjacency not just as an FA [RFC4206]. In particular, it needs to
work with at least the following IP/MPLS control protocols: OSPF/IS-
IS, LDP, IGPOSPF-TE/ISIS-TE, and RSVP-TE.
The solution SHALL accept a new component link or remove an existing
component link by operator provisioning or in response to signaling
at a lower layer (e.g., using GMPLS).
The solution SHALL support derivation of the advertised interface
parameters from configured component link parameters based on
operator policy.
A composite link SHALL be configurable as a numbered or unnumbered
link (virtual interface in IP/MPLS).
A component link SHALL be configurable as a numbered link or
unnumbered link. A component link should be not advertised in IGP.
4.1.1.1. Traffic Flow and Connection Mapping
The solution SHALL support operator assignment of traffic flows to
specific connections.
The solution SHALL support operator assignment of connections to
specific component links.
The solution SHALL support IP packet transport across a composite
link for control plane (signaling, routing) and management plane
functions.
In order to prevent packet loss, the solution must employ make- 2. Assumptions
before-break when a change in the mapping of a connection to a
component link mapping change has to occur.
4.1.1.2. Management of Other Operational Aspects The services supported include L3VPN, L2VPN (VPWS and VPLS), Internet
traffic encapsulated by at least one MPLS label, and dynamically
signaled MPLS-TP LSPs and pseudowires. The MPLS LSPs supporting
these services may be pt-pt, pt-mpt, or mpt-mpt.
4.1.1.2.1. Resilience The location in a network where these requirements apply are a Label
Edge Router (LER) or a Label Switch Router (LSR) as defined in RFC
3031 [RFC3031].
The component link recovery scheme SHALL perform equal to or better The IP DSCP cannot be used for flow identification since L3VPN
than existing local recovery methods. A short service disruption may requires Diffserv transparency (see RFC 4031 5.5.2 [RFC4031]), and in
occur during the recovery period. Fast ReRoute (FRR) SHALL be general network operators do not rely on the DSCP of Internet
configurable for a composite link. packets.
As part of FRR, a method to recover from composite link node failure 3. Definitions
is desirable. OAM Messaging Support
4.1.1.2.2. Fault management requirement Composite Link:
Section 6.9.2 of ITU-T-G.800 [ITU-T.G.800] defines composite link
as summarized in Appendix Appendix C. The following definitions
map the ITU-T G.800 terminology into IETF terminology which is
used in this document.
There are two aspects of fault management in the solution. One is Multiple parallel links: When multiple parallel component links
about composite link between two local adjacent routers. The other between the an LER/LSR and another LER/LSR.
is about the individual component link.
OAM protocols for fault management from the outside routers (e.g., Multi-layer Component Link: A component link that is formed by
LSP-Ping/Trace, IP-ping/Trace) SHALL be transparently treated. other network elements at other layers.
For example, it is expected that LSP-ping/trace message is able to Component Link: A physical link (e.g., Lambda, Ethernet PHY, SONET/
diagnose composite link status and its associated virtual interface SDH, OTN, etc.) with packet transport capability, or a logical
information; however, it is not required to directly treat individual link (e.g., MPLS LSP, Ethernet VLAN, MPLS-TP LSP, etc.)
component link and CL-connection because they are local matter of two
routers.
The solution SHALL support fault notification mechanism (e.g., Flow: A sequence of packets that must be transferred on one
syslog, SNMP trap to the management system/operators) with the component link.
granularity level of affected part as detailed below:
o Data-plane of component link level Flow identification: The label stack and other information that
uniquely identifies a flow. Other information in flow
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.
o Data-plane of composite link level (as a whole, and as a sum of 4. Network Operator Functional Requirements
associated component links)
o Control-plane of the virtual interface level (i.e., The Functional Requirements in this section are grouped in
routing/signaling on it) subsections starting with the highest priority.
o A composite link that believes that the underlying component link 4.1. Availability, Stability and Transient Response
server layers might not efficiently report failures, can run
Bidirectional Forwarding Detection (BFD) at the component link
layer.
Race conditions: The solution shall support configuration of timers Limiting the period of unavailability in response to failures or
so that lower layer methods have time to detect/restore faults before transient events is extremely important as well as maintaining
a composite link function would be invoked. stability. The transient period between some service disrupting
event and the convergence of the routing and/or signaling protocols
MUST occur within a time frame specified by SLA objectives. The
timeframes range from rapid restoration, on the order of 100 ms or
less (e.g., for VPWS), to several minutes (e.g., for L3VPN) and may
differ among the set of customers within a single service.
The solution SHALL allow operator or control plane to query the FR#1 The solution SHALL provide a means to summarize routing
component link to which an LSP is assigned. advertisements regarding the characteristics of a composite
link such that the routing protocol convergence within the
timeframe needed to meet the SLA objective..
4.1.1.2.3. Flow/Connection Mapping Change Frequency FR#2 The solution SHALL provide a means for aggregating signaling
such that in response to a failure in the worst case cross
section of the network that MPLS LSPs are restored within the
timeframe needed to meet the SLA objective.
The solution requires methods to dampen the frequency of flow to FR#3 The solution SHALL provide to select a path for a flow across a
connection mapping change, connection bandwidth change, and/or network that contains a number of paths comprised of pairs of
connection to component link mapping changes (e.g., for re- nodes connected by composite links in such a way as to
optimization). Operator imposed control policy regarding the automatically distribute the load over the network nodes
frequency of change for sets of flows SHALL be supported. connected by composite links while meeting all of the other
mandatory requirements stated above. The solution SHOULD work
in a manner similar to that when the characteristics of the
individual component links are advertised.
The solution SHALL support latency and delay variation sensitive FR#4 If extensions to existing protocols are specified and/or new
traffic and limit the mapping change for these flows, and place them protocols are defined, then the solution SHOULD provide a means
on component links that have lower latency. for a network operator to migrate an existing deployment in a
minimally disruptive manner.
The determination of latency sensitive traffic SHALL be determined by FR#5 Any automatic LSP routing and/or load balancing solutions MUST
any of the following methods: not oscillate such that performance observed by users changes
such that an SLA is violated. Since oscillation may cause
reordering, there MUST be means to control the frequency of
changing the component link over which a flow is placed.
o Use of a pre-defined local policy setting at composite link FR#6 Management and diagnostic protocols MUST be able to operate
ingress that can be mapped to a flow over composite links.
o A manually configured setting at composite link ingress that can 4.2. Component Links Provided by Lower Layer Networks
be mapped to a flow
The determination of latency sensitive traffic SHOULD be determined Case 3 as defined in [ITU-T.G.800] involves a component link
(if possible) by any of the following methods: supporting an MPLS layer network over another lower layer network
(e.g., circuit switched or another MPLS network (e.g., MPLS-TP)).
The lower layer network may change the latency (and/or other
performance parameters) seen by the MPLS layer network. Network
Operators have SLAs of which some components are based on performance
parameters. Currently, there is no protocol for the lower layer
network to inform the higher layer network of a change in a
performance parameter. Communication of the latency performance
parameter is a very important requirement. Communication of other
performance parameters (e.g., delay variation) is desirable.
o Pre-set bits in the Payload (e.g., DSCP bits for IP or Ethernet FR#7 In order to support network SLAs and provide acceptable user
user priority for Ethernet payload) which are typically assigned experience, the solution SHALL specify a protocol means to
by end-user allow a lower layer server network to communicate latency to
the higher layer client network.
o MPLS Traffic-Class Field (aka EXP) which is typically mapped by FR#8 The precision of latency reporting SHOULD be at least 10% of
the LER/LSR on the basis that its value is given for the one way latency for latency of 1 ms or more.
differentiating latency-sensitive traffic of end-users
4.1.2. Functions specific to LSP flows with TE information FR#9 The solution SHALL provide a means to limit the latency on a
per LSP basis between nodes within a network to meet an SLA
target when the path between these nodes contains one or more
pairs of nodes connected via a composite link.
The following requirements apply to the case of RSVP-TE signaled LSPs The SLAs differ across the services, and some services have
where the virtual interface is configured with IGP TE extensions. different SLAs for different QoS classes, for example, one QoS
class may have a much larger latency bound than another.
Overload can occur which would violate an SLA parameter (e.g.,
loss) and some remedy to handle this case for a composite
link.
The solution SHALL allow configuration of virtual interface FR#10 If the total demand offered by traffic flows exceeds the
parameters for TE extensions link (e.g., available bandwidth, maximum capacity of the composite link, the solution SHOULD define a
bandwidth, maximum allowable LSP bandwidth, TE metric, and resource means to cause the LSPs for some traffic flows to move to some
classes (i.e., administrative groups) or link colors). other point in the network that is not congested. These
"preempted LSPs" may not be restored if there is no
uncongested path in the network.
The solution SHALL support configuration of a composite link composed 4.3. Parallel Component Links with Different Characteristics
of set of component links , with each component link potentially
having at least the following characteristics which may differ:
o Bandwidth Corresponding to Case 1 of [ITU-T.G.800], as one means to provide
high availability, network operators deploy a topology in the MPLS
network using lower layer networks that have a certain degree of
diversity at the lower layer(s). Many techniques have been developed
to balance the distribution of flows across component links that
connect the same pair of nodes (See Appendix B.3). When the path for
a flow can be chosen from a set of candidate nodes connected via
composite links, other techniques have been developed (See
Appendix B.4).
o Latency FR#11 The solution SHALL measure traffic on a labeled traffic flow
and dynamically select the component link on which to place
this flow in order to balance the load so that no component
link in the composite link between a pair of nodes is
overloaded.
o QoS characteristics (e.g., jitter, error rate) FR#12 When a traffic flow is moved from one component link to
another in the same composite link between a set of nodes (or
sites), it MUST be done so in a minimally disruptive manner.
The solution SHALL support the admission control by RSVP-TE that is When a flow is moved from a current link to a target link with
signaled from the routers outside the composite link. Note that RSVP- different latency, reordering can occur if the target link
TE signaling need not specify the actual component link to be used? latency is less than that of the current or clumping can occur
because the selection of component link is the local matter of two if target link latency is greater than that of the current.
adjacent routers based upon signaled and locally configured Therefore, some flows (e.g., timing distribution, PW circuit
information. emulation) are quite sensitive to these effects, which may be
specified in an SLA or are needed to meet a user experience
objective (e.g. jitter buffer under/overrun).
The solution shall be able to receive, interpret and act upon at FR#13 The solution SHALL provide a means to identify flows whose
least the following RSVP-TE signaled parameters: bandwidth setup rearrangement frequency needs to be bounded by a configured
priority, and holding priority [RFC 3209, RFC 2215] preemption value.
priority and traffic class [RFC 4124], and apply them to the CL
connections where the LSP is mapped.
The solution shall support configuration of at least the following FR#14 The solution SHALL provide a means that communicates whether
parameters on a per composite link basis: the flows within an LSP can be split across multiple component
links. The solution SHOULD provide a means to indicate the
flow identification field(s) which can be used along the flow
path which can be used to perform this function.
o Local Bandwidth Oversubscription factor FR#15 The solution SHALL provide a means to indicate that a traffic
The determination of latency sensitive traffic SHALL be determined by flow shall select a component link with the minimum latency
any of the following methods: value.
o MPLS traffic class in a RSVP-TE signaling message (i.e., Diffserv- FR#16 The solution SHALL provide a means to indicate that a traffic
TE traffic class [RFC 4124]) flow shall select a component link with a maximum acceptable
latency value as specified by protocol.
4.1.3. Functions specific to LSP flows without TE information FR#17 The solution SHALL provide a means to indicate that a traffic
flow shall select a component link with a maximum acceptable
delay variation value as specified by protocol.
The following requirements apply to the case of LDP signaled LSPs FR#18 The solution SHALL provide a local means to a node which
when no signaled TE information is available. automatically distribute flows across the component links in
the composite link that connects to the other node such that
SLA objectives are met.
The solution shall map LDP-assigned labeled packets based upon local FR#19 The solution SHALL provide a means to distribute flows from a
configuration (e.g., label stack depth) to define a connection that single LSP across multiple component links to handle at least
is mapped to one of the component link. the case where the traffic carried in an LSP exceeds that of
any component link in the composite link.
The solution SHALL map LDP-assigned labeled packets that identify the 5. Derived Requirements
outer label's FEC.
The solution SHALL support entropy labels [Entropy Label] to map more This section takes the next step and derives high-level requirements
granular flows to connections. on protocol specification from the functional requirements.
The solution SHALL be able to measure the bandwidth actually used by DR#1 The solution SHOULD attempt to extend existing protocols
a particular connection and derive proper local traffic TE wherever possible, developing a new protocol only if this adds
information for the connection. a significant set of capabilities.
When the connection bandwidth exceeds the component link capacity, The vast majority of network operators have provisioned L3VPN
the solution SHALL be able to reassign the traffic flows to several services over LDP. Many have deployed L2VPN services over LDP
connections. as well. TE extensions to IGP and RSVP-TE are viewed as being
overly complex by some operators.
The solution SHALL support management plane controlled parameters DR#2 A solution SHOULD extend LDP capabilities to meet functional
that define at least a minimum bandwidth, maximum bandwidth, requirements (without using TE methods as decided in
preemption priority, and holding priority for each connection without [RFC3468]).
TE information (i.e., LDP signaled LSP that does not contain the same
information as an RSVP-TE signaled LSP).
4.1.4. Sets of LSP flows with and without TE information DR#3 Coexistence of LDP and RSVP-TE signaled LSPs MUST be supported
on a composite link. Other functional requirements should be
supported as independently of signaling protocol as possible.
The solution shall support separation of resources for traffic flows DR#4 When the nodes connected via a composite link are in the same
mapped to connections that have access to TE information (e.g., RSVP- MPLS network topology, the solution MAY define extensions to
TE signaled flows) from those that do not have access to TE the IGP.
information (e.g., LDP-signaled flows or RSVP-TE LSP with Zero
bandwidth).
Component links in a composite link may fail independently. The DR#5 When the nodes are connected via a composite link are in
failure of a component link may impact some connections. The different MPLS network topologies, the solution SHALL NOT rely
impacted connections shall be transferred to other active component on extensions to the IGP.
links using the same rules as for the original assignment of
connections to component links. In the event that all connections
cannot be recovered, configured priority and preemption parameters
SHOULD be employed.
4.1.4.1. Handling Bandwidth Shortage Events DR#6 When a worst case failure scenario occurs,the resulting number
of links advertised in the IGP causes IGP convergence to occur,
causing a period of unavailability as perceived by users. The
convergence time of the solution MUST meet the SLA objective
for the duration of unavailability.
The following requirements apply to a virtual interface that supports DR#7 The Solution SHALL summarize the characteristics of the
traffic flows both with and without TE information, in response to a component links as a composite link IGP advertisement that
bandwidth shortage event. A "bandwidth shortage" can arise in a results in convergence time better than that of advertising the
composite link if the total bandwidth of the connections with individual component links. This summary SHALL be designed so
provisioned/signaled TE information and those signaled without TE that it represents the range of capabilities of the individual
information (but with measured bandwidth) exceeds the bandwidth of component links such that functional requirements are met, and
the composite link that carries connections. also minimizes the frequency of advertisement updates which may
cause IGP convergence to occur. Examples of advertisement
update tiggering events to be considered include: LSP
establishment/release, changes in component link
characteristics (e.g., latency, up/down state), and/or
bandwidth utilization.
The solution shall support a policy-based preemption capability such DR#8 When a worst case failure scenario occurs,the resulting number
that, in the event of such a "bandwidth shortage", the signaled or of links advertised in the IGP causes IGP convergence to occur,
configured preemption and holding parameters can be applied to the causing a period of unavailability as perceived by users. The
following treatments to the connections: convergence time of the solution MUST meet the SLA objective
for the duration of unavailability.
o For a connection that has RSVP-TE LSPs, signal the router that the DR#9 When a worst case failure scenario occurs, the number of
LSP has been preempted. The solution shall support soft RSVP-TE LSPs to be resignaled will cause a period of
preemption (i.e., notify the preempted LSP source prior to unavailability as perceived by users. The resignaling time of
preemption). [Soft Preemption] the solution MUST meet the SLA objective for the duration of
unavailability. The resignaling time of the solution MUST not
increase significantly as compared with current methods.
o For a connection that has LDP(s), where the routers connected via 6. Acknowledgements
the composite link is aware of the LDP signaling involved to the
preempted label stack depth, signal release of the label to the
router
o For a connection that has non-re-routable RSVP-TE LSPs or non- Frederic Jounay of France Telecom and Yuji Kamite of NTT
releasable LDP labels, signal the router or operator that the LSP Communications Corporation co-authored a version of this document.
or LDP label has been lost.
4.2. Exterior Functions A rewrite of this document occurred after the IETF77 meeting.
Dimitri Papadimitriou, Lou Berger, Tony Li, the WG chairs John Scuder
and Alex Zinin, and others provided valuable guidance prior to and at
the IETF77 RTGWG meeting.
4.2.1. Functions common to all LSP flows Tony Li and John Drake have made numerous valuable comments on the
RTGWG mailing list that are reflected in versions following the
IETF77 meeting.
The solution MUST be able to interoperate with exiting IETF MPLS 7. IANA Considerations
[RFC3031] control and data planes where appropriate.
4.2.1.1. Signaling Protocol Extensions This memo includes no request to IANA.
The solution SHALL support signaling a composite link between two 8. Security Considerations
routers (e.g., P, P/PE, or PE).
The solution SHALL support signaling a component link as part of a This document specifies a set of requirements. The requirements
composite link. themselves do not pose a security threat. If these requirements are
met using MPLS signaling as commonly practiced today with
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.
The solution SHALL support signaling a composite link and 9. References
automatically injecting it into the IGP [LSP Hieararchy bis] or
connected two routers.
4.2.1.2. Routing Advertisement Extensions 9.1. Normative References
The solution SHALL support IGP extensions to identify that the [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
advertised routing adjacency as a composite link. Requirement Levels", BCP 14, RFC 2119, March 1997.
4.2.1.3. Multi-Layer Networking Aspects 9.2. Informative References
The solution MUST be able to interoperate with existing IETF [ITU-T.G.800]
GMPLS/MPLS-TP control and data planes where appropriate, for example, ITU-T, "Unified functional architecture of transport
when signaling a component link. networks", 2007, <http://www.itu.int/rec/T-REC-G/
recommendation.asp?parent=T-REC-G.800>.
The solution SHALL support derivation of the advertised interface [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
parameters from signaled component link parameters from a lower layer McManus, "Requirements for Traffic Engineering Over MPLS",
(e.g., latency, capacity) based on operator policy. RFC 2702, September 1999.
The solution SHALL be able to accept the GMPLS/MPLS-TP control plane [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
signaled component link. It SHALL be able to support the following Label Switching Architecture", RFC 3031, January 2001.
component link parameters
o Maximum (estimated or measured) acceptable latency [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS signaling
protocols", RFC 3468, February 2003.
o Actual(estimated or measured) assigned latency [RFC3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC 3809,
June 2004.
o Bandwidth [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer
3 Provider Provisioned Virtual Private Networks (PPVPNs)",
RFC 4031, April 2005.
o Delay Variation [RFC4665] Augustyn, W. and Y. Serbest, "Service Requirements for
Layer 2 Provider-Provisioned Virtual Private Networks",
RFC 4665, September 2006.
It SHOULD support the following component link parameter [RFC5254] Bitar, N., Bocci, M., and L. Martini, "Requirements for
Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)",
RFC 5254, October 2008.
o Loss rate 9.3. Appendix References
4.2.2. Functions specific to LSP flows with TE information [I-D.ietf-pwe3-fat-pw]
Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow Aware Transport of Pseudowires
over an MPLS PSN", draft-ietf-pwe3-fat-pw-03 (work in
progress), January 2010.
4.2.2.1. Signaling Protocol Extensions Requirements [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>.
The solution SHALL support per LSP signaling of at least the [ITU-T.Y.1541]
following additional parameters for an LSP ITU-T, "Network performance objectives for IP-based
services", 2006, <http://www.itu.int/rec/T-REC-Y.1541/en>.
o Maximum (estimated or measured) acceptable latency [RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The
PPP Multilink Protocol (MP)", RFC 1717, November 1994.
o Actual (estimated or measured) accumulated latency based upon the [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
actual component link assigned by the composite link and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
o Bandwidth of the highest and lowest speed [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
June 1999.
The solution SHOULD support per LSP signaling of at least the [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
following additional parameters: Multicast Next-Hop Selection", RFC 2991, November 2000.
o Delay Variation [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, November 2000.
o Loss rate [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
As part of determining the path of an LSP, the client may query a [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
Patch Computation Element (PCE) and use the response in determining in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
the (complete or partial) source route sent in the TE signaling
message.
Note that an LSP can be a component link or a client LSP. Since [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
component links may involve GMPLS, separate signaling protocol Internet Protocol", RFC 4301, December 2005.
extensions may be needed for particular switching capabilities.
4.2.2.2. Routing Advertisement Extensions [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
It SHALL be possible for the solution to represent multiple values, [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
or a range of values, for the composite link interface parameters in Cost Multipath Treatment in MPLS Networks", BCP 128,
order to communicate information about differences in the constituent RFC 4928, June 2007.
component links in an exterior function route advertisement
Some of these capabilities are specified for link bundling [RFC Appendix A. More Details on Existing Network Operator Practices and
4201], but some extensions may be needed. Techniques such as those Protocol Usage
described in [RFC 2676] for encoding latency and using it in routing
should be considered. LSA encoding techniques such as those described
in [RFC 3630] should also be considered.
For example, a range of latencies, a range of capacities and/or other Network operators have SLAs for services that are comprised of
characteristics for the component links that comprise the composite numerical values for performance measures, principally availability,
links could be advertised. When a range of characteristics is latency, delay variation. See [ITU-T.Y.1541], RFC 3809, Section 4.9
advertised, these can be used in a constrained path computation, that [RFC3809] for examples of the form of such SLAs. Note that the
is, certain composite links can be excluded since no component link numerical values of Y.1541 span multiple networks and may be looser
meets the characteristic as part of the overall path. than network operator SLAs. Applications and acceptable user
experience have a relationship to these performance parameters.
4.2.3. Functions specific to LSP flows without TE information Consider latency as an example. In some cases, minimizing latency
relates directly to the best customer experience (e.g., in TCP closer
is faster). I other cases, user experience is relatively insensitive
to latency, up to a specific limit at which point user perception of
quality degrades significantly (e.g., interactive human voice and
multimedia conferencing). A number of SLAs have. a bound on point-
point latency, and as long as this bound is met, the SLA is met --
decreasing the latency is not necessary. In some SLAs, if the
specified latency is not met, the user considers the service as
unavailable. An unprotected LSP can be manually provisioned on a set
of to meet this type of SLA, but this lowers availability since an
alternate route that meets the latency SLA cannot be determined.
A straightforward set of requirement would result if the same Historically, when an IP/MPLS network was operated over a lower layer
functions specified for RSVP-TE were also specified for LDP. However, circuit switched network (e.g., SONET rings), a change in latency
the IETF MPLS Working Group's decision on MPLS signaling protocols caused by the lower layer network (e.g., due to a maintenance action
[RFC 3468] to not pursue such an approach by not adding functions to or failure) this was not known to the MPLS network. This resulted in
CR-LDP means that a different approach must be taken. latency affecting end user experience, sometimes violating SLAs or
resulting in user complaints.
As described in the Interior Function section, 4.1.3, a basic A response to this problem was to provision IP/MPLS networks over
composite link capability when there is no TE information is to be unprotected circuits and set the metric and/or TE-metric proportional
able to measure the amount of LDP signaled traffic that is sent on an to latency. This resulted in traffic being directed over the least
LSP. It is highly desirable to be able to signal and advertise latency path, even if this was not needed to meet an SLA or meet user
certain aspects of these measurements, if they cannot be explicitly experience objectives. This results in reduced flexibility and
signaled via extensions to LDP. increased cost for network operators. Using lower layer networks to
provide restoration and grooming is expected to be more efficient,
but the inability to communicate performance parameters, in
particular latency, from the lower layer network to the higher layer
network is an important problem to be solved before this can be done.
4.2.3.1. Signaling Protocol Extensions Latency SLAs for pt-pt services are often tied closely to geographic
locations, while latency for multipoint services may be based upon a
worst case within a region.
The solution SHOULD allow addition of an object to an LDP label The presence of only three Traffic Class (TC) bits (previously known
mapping message that indicates how much measured capacity can be sent as EXP bits) in the MPLS shim header is limiting when a network
to a pair of nodes connected via a composite link. This signaling operator needs to support QoS classes for multiple services (e.g.,
should be conveyed at least to nodes which are adjacent to the pair L2VPN VPWS, VPLS, L3VPN and Internet), each of which has a set of QoS
of nodes connected via a composite link. classes that need to be supported. In some cases one bit is used to
indicate conformance to some ingress traffic classification, leaving
only two bits for indicating the service QoS classes. The approach
that has been taken is to aggregate these QoS classes into similar
sets on LER-LSR and LSR-LSR links.
Nodes SHOULD be able to use this information in conjunction with the Labeled LSPs have been and use of link layer encapsulation have been
IGP link information to decide which label mappings it will use for standardized in order to provide a means to meet these needs.
forwarding LDP signaled flows toward a pair of nodes connected via a
composite link.
4.2.3.2. Routing Advertisement Extensions The IP DSCP cannot be used for flow identification since RFC 4301
Section 5.5 [RFC4301] requires Diffserv transparency, and in general
network operators do not rely on the DSCP of Internet packets.
Signaling via LDP the available capacity on a composite link for A label is pushed onto Internet packets when they are carried along
flows without TE information is one method. A preferable method would with L2/L3VPN packets on the same link or lower layer network
be to extend the IGP to indicate the amount of capacity allocated by provides a mean to distinguish between the QoS class for these
an Interior function to flows without TE information so that nodes in packets.
the network using LDP can make better informed decisions about which
label mapping messages are used to form an LDP LSP.
4.2.4. Functions specific to LSP flows with and without TE information Operating an MPLS-TE network involves a different paradigm from
operating an IGP metric-based LDP signaled MPLS network. The mpt-pt
LDP signaled MPLS LSPs occur automatically, and balancing across
parallel links occurs if the IGP metrics are set "equally" (with
equality a locally definable relation).
As described in the Interior Function section, 4.1.4, the principal Traffic is typically comprised of a few large (some very large) flows
driver in this case is how to handle bandwidth shortage events when and many small flows. In some cases, separate LSPs are established
both RSVP-TE and LDP signaled LSPs are present in the composite link. for very large flows. This can occur even if the IP header
The requirements relevant to the nodes connected by the composite information is inspected by a router, for example an IPsec tunnel
link are described in section 4.1.4, and this section describes that carries a large amount of traffic. An important example of
additional desirable functions beyond these nodes. Since RSVP-TE large flows is that of a L2/L3 VPN customer who has an access line
signaling defines parameters and procedures for preemption, the focus bandwdith comparable to a client-client composite link bandwidth --
is on extensions to better support LDP signaled LSPs. there could be flows that are on the order of the access line
bandwdith.
4.2.4.1. Signaling Protocol Extensions Appendix B. Existing Multipath Standards and Techniques
The solution SHOULD allow addition of an object to an LDP label Today the requirement to handle large aggregations of traffic, much
mapping message that indicates that a node controlling the composite larger than a single component link, can be handled by a number of
link wants to preempt the traffic offered by an LSP. This should have techniques which we will collectively call multipath. Multipath
the effect of pruning label distribution for the LSP at the node pair applied to parallel links between the same set of nodes includes
connected via a composite link. Ethernet Link Aggregation [IEEE-802.1AX], link bundling [RFC4201], or
other aggregation techniques some of which may be vendor specific.
Multipath applied to diverse paths rather than parallel links
includes Equal Cost MultiPath (ECMP) as applied to OSPF, ISIS, or
even BGP, and equal cost LSP, as described in Appendix B.4. Various
mutilpath techniques have strengths and weaknesses.
4.2.4.2. Routing Advertisement Extensions The term composite link is more general than terms such as link
aggregate which is generally considered to be specific to Ethernet
and its use here is consistent with the broad definition in
[ITU-T.G.800]. The term multipath excludes inverse multiplexing and
refers to techniques which only solve the problem of large
aggregations of traffic, without addressing the other requirements
outlined in this document.
The solution SHOULD allow addition of an object to the IGP that B.1. Common Multpath Load Spliting Techniques
indicates that all LDP signaled traffic should avoid the advertised
composite link.
5. Security Considerations Identical load balancing techniqes are used for multipath both over
parallel links and over diverse paths.
The solution is a local function on the router to support traffic Large aggregates of IP traffic do not provide explicit signaling to
engineering management over multiple parallel links. It does not indicate the expected traffic loads. Large aggregates of MPLS
introduce a security risk for control plane and data plane. traffic are carried in MPLS tunnels supported by MPLS LSP. LSP which
are signaled using RSVP-TE extensions do provide explicit signaling
which includes the expected traffic load for the aggregate. LSP
which are signaled using LDP do not provide an expected traffic load.
The solution could change the frequency of routing update messages MPLS LSP may contain other MPLS LSP arranged hierarchically. When an
and therefore could change routing convergence time. The solution MPLS LSR serves as a midpoint LSR in an LSP carrying other LSP as
MUST provide controls to dampen the frequency of such changes so as payload, there is no signaling associated with these inner LSP.
to not destabilize routing protocols. Therefore even when using RSVP-TE signaling there may be insufficient
information provided by signaling to adequately distribute load
across a composite link.
6. IANA Considerations Generally a set of label stack entries that is unique across the
ordered set of label numbers can safely be assumed to contain a group
of flows. The reordering of traffic can therefore be considered to
be acceptable unless reordering occurs within traffic containing a
common unique set of label stack entries. Existing load splitting
techniques take advantage of this property in addition to looking
beyond the bottom of the label stack and determining if the payload
is IPv4 or IPv6 to load balance traffic accordingly.
IANA actions to provide solutions are for further study. MPLS-TP OAM violates the assumption that it is safe to reorder
traffic within an LSP. If MPLS-TP OAM is to be accommodated, then
existing multipth techniques must be modified. Such modifications
are outside the scope of this document.
7. References For example a large aggregate of IP traffic may be subdivided into a
large number of groups of flows using a hash on the IP source and
destination addresses. This is as described in [RFC2475] and
clarified in [RFC3260]. For MPLS traffic carrying IP, a similar hash
can be performed on the set of labels in the label stack. These
techniques are both examples of means to subdivide traffic into
groups of flows for the purpose of load balancing traffic across
aggregated link capacity. The means of identifying a flow should not
be confused with the definition of a flow.
7.1. Normative References Discussion of whether a hash based approach provides a sufficiently
even load balance using any particular hashing algorithm or method of
distributing traffic across a set of component links is outside of
the scope of this document.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate The current load balancing techniques are referenced in [RFC4385] and
Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4928]. The use of three hash based approaches are described in
[RFC2991] and [RFC2992]. A mechanism to identify flows within PW is
described in [I-D.ietf-pwe3-fat-pw]. The use of hash based
approaches is mentioned as an example of an existing set of
techniques to distribute traffic over a set of component links.
Other techniques are not precluded.
[RFC2215] S. Shenker, J. Wroclawski, "General Characterization B.2. Simple and Adaptive Load Balancing Multipath
Parameters for Integrated Service Network Elements."
September 1997
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Simple multipath generally relies on the mathematical probability
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," December that given a very large number of small microflows, these microflows
2001 will tend to be distributed evenly across a hash space. A common
simple multipath implementation assumes that all members (component
links) are of equal capacity and perform a modulo operation across
the hashed value. An alternate simple multipath technique uses a
table generally with a power of two size, and distributes the table
entries proportionally among members according to the capacity of
each member.
[RFC4206] Label Switched Paths (LSP) Hierarchy with Generalized Simple load balancing works well if there are a very large number of
Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) K. small microflows (i.e., microflow rate is much less than component
Kompella, Y. Rekhter October 2005 link capacity). However, the case where there are even a few large
microflows is not handled well by simple load balancing.
[RFC4090] Pan, P., "Fast Reroute Extensions to RSVP-TE for LSP An adaptive multipath technique is one where the traffic bound to
Tunnels", RFC 4090, May 2005. each member (component link) is measured and the load split is
adjusted accordingly. As long as the adjustment is done within a
single network element, then no protocol extensions are required and
there are no interoperability issues.
[RFC4124] Protocol Extensions for Support of Diffserv-aware MPLS Note that if the load balancing algorithm and/or its parameters is
Traffic Engineering F. Le Faucheur, Ed. June 2005 adjusted, then packets in some flows may be delivered out of
sequence.
[RFC4201] Kompella, K., "Link Bundle in MPLS Traffic Engineering", B.3. Traffic Split over Parallel Links
RFC 4201, March 2005.
7.2. Informative References The load spliting techniques defined in Appendix B.1 and Appendix B.2
are both used in splitting traffic over parallel links between the
same pair of nodes. The best known technique, though far from being
the first, is Ethernet Link Aggregation [IEEE-802.1AX]. This same
technique had been applied much earlier using OSPF or ISIS Equal Cost
MultiPath (ECMP) over parallel links between the same nodes.
Multilink PPP [RFC1717] uses a technique that provides inverse
multiplexing, however a number of vendors had provided proprietary
extensions to PPP over SONET/SDH [RFC2615] that predated Ethernet
Link Aggregation but are no longer used.
[Entropy Label] Kompella, K. and S. Amante, "The Use of Entropy Link bundling [RFC4201] provides yet another means of handling
Labels in MPLS Forwarding", November 2008, Work in Progress parallel LSP. RFC4201 explicitly allow a special value of all ones
to indicate a split across all members of the bundle.
[LSP Hierarchy] Shiomoto, K. and A. Farrel, "Procedures for B.4. Traffic Split over Multiple Paths
Dynamically Signaled Hierarchical Label Switched
Paths", November 2008, Work in Progress
[Soft Preemption] Meyer, M. and J. Vasseur, "MPLS Traffic Engineering OSPF or ISIS Equal Cost MultiPath (ECMP) is a well known form of
Soft Preemption", February 2009, Work in Progress traffic split over multiple paths that may traverse intermediate
nodes. ECMP is often incorrectly equated to only this case, and
multipath over multiple diverse paths is often incorrectly equated to
ECMP.
[CLFRAMEWORK] Yong, L. Ed, "Framework for MPLS Over Composite Link," Many implementations are able to create more than one LSP between a
work in progress. pair of nodes, where these LSP are routed diversely to better make
use of available capacity. The load on these LSP can be distributed
proportionally to the reserved bandwidth of the LSP. These multiple
LSP may be advertised as a single PSC FA and any LSP making use of
the FA may be split over these multiple LSP.
[RFC3468] L. Andersson, G. Swallow, "The Multiprotocol Label Link bundling [RFC4201] component links may themselves be LSP. When
Switching (MPLS) Working Group decision on MPLS signaling this technique is used, any LSP which specifies the link bundle may
protocols." be split across the multiple paths of the LSP that comprise the
bundle.
[PWBONDING] Stein, Y, "PW Bonding", Dec. 2008 Appendix C. ITU-T G.800 Composite Link Definitions and Terminology
[RFC3630] Katz, D., "Traffic Engineering (TE) Extension to OSPF Composite Link:
Version 2", RFC 3630, September 2003. 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".
[RFC 2676] G. Apostolopoulos, S. Kama, D. Williams, R. Guerin, A. Case 1: "Multiple parallel links between the same subnetworks
Orda, T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions," can be bundled together into a single composite link. Each
August, 1999 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."
[ITU-T G.800] ITU-T, "Unified functional architecture of transport Case 3: "A link can also be constructed by a concatenation of
networks," September, 2007. 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."
8. Acknowledgments 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.
Authors would like to thank Adrian Farrel from Olddog for his Forwarding Relationship: Configured forwarding between ports on a
extensive comments and suggestions, Ron Bonica from Juniper, Nabil subnetwork. It may be connectionless (e.g., IP, not considered
Bitar from Verizon, Eric Gray from Ericsson, Lou Berger from LabN, in this draft), or connection oriented (e.g., MPLS signaled or
and Kireeti Kompella from Juniper, for their reviews and great configured).
suggestions.
This document was prepared using 2-Word-v2.0.template.dot. Component Link: A topolological relationship between subnetworks
(i.e., a connection between nodes), which may be a wavelength,
circuit, virtual circuit or an MPLS LSP.
Copyright (c) 2010 IETF Trust and the persons identified as authors Authors' Addresses
of the code. All rights reserved.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS Curtis Villamizar (editor)
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT Infinera Corporation
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 169 W. Java Drive
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT Sunnyvale, CA 94089
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
This code was derived from IETF RFC [insert RFC number]. Please Email: cvillamizar@infinera.com
reproduce this note if possible.
Authors' Addresses Dave McDysan (editor)
Verizon
22001 Loudoun County PKWY
Ashburn, VA 20147
So Ning Email: dave.mcdysan@verizon.com
Verizon
2400 N. Glem Ave.,
Richerdson, TX 75082
Phone: +1 972-729-7905
Email: ning.so@verizonbusiness.com
Andrew Malis So Ning
Verizon Verizon
117 West St. 2400 N. Glenville Ave.
Waltham, MA 02451 Richardson, TX 75082
Phone: +1 781-466-2362
Email: andrew.g.malis@verizon.com
Dave McDysan Phone: +1 972-729-7905
Verizon Email: ning.so@verizonbusiness.com
22001 Loudoun County PKWY Andrew Malis
Ashburn, VA 20147 Verizon
Email: dave.mcdysan@verizon.com 117 West St.
Waltham, MA 02451
Lucy Yong Phone: +1 781-466-2362
Huawei USA Email: andrew.g.malis@verizon.com
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 469-229-5387
Email: lucyyong@huawei.com
Frederic Jounay Lucy Yong
France Telecom Huawei USA
2, avenue Pierre-Marzin 1700 Alma Dr. Suite 500
22307 Lannion Cedex, Plano, TX 75075
FRANCE
Email: frederic.jounay@orange-ftgroup.com
Yuji Kamite Phone: +1 469-229-5387
NTT Communications Corporation Email: lucyyong@huawei.com
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: y.kamite@ntt.com
 End of changes. 155 change blocks. 
771 lines changed or deleted 630 lines changed or added

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