< draft-ietf-rtgwg-cl-use-cases-04.txt   draft-ietf-rtgwg-cl-use-cases-05.txt >
RTGWG S. Ning RTGWG S. Ning
Internet-Draft Tata Communications Internet-Draft Tata Communications
Intended status: Informational A. Malis Intended status: Informational A. Malis
Expires: January 14, 2014 D. McDysan Expires: May 17, 2014 Consultant
D. McDysan
Verizon Verizon
L. Yong L. Yong
Huawei USA Huawei USA
C. Villamizar C. Villamizar
Outer Cape Cod Network Outer Cape Cod Network Consulting
Consulting November 13, 2013
July 13, 2013
Advannced Multipath Use Cases and Design Considerations Advanced Multipath Use Cases and Design Considerations
draft-ietf-rtgwg-cl-use-cases-04 draft-ietf-rtgwg-cl-use-cases-05
Abstract Abstract
This document provides a set of use cases and design considerations
for Advanced Multipath.
Advanced Multipath is a formalization of multipath techniques Advanced Multipath is a formalization of multipath techniques
currently in use in IP and MPLS networks and a set of extensions to currently in use in IP and MPLS networks and a set of extensions to
existing multipath techniques. existing multipath techniques.
Status of this Memo This document provides a set of use cases and design considerations
for Advanced Multipath. Existing practices are described. Use cases
made possible through Advanced Multipath extensions are described.
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 January 14, 2014. This Internet-Draft will expire on May 17, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Multipath Foundation Use Cases . . . . . . . . . . . . . . . . 5 4. Multipath Foundation Use Cases . . . . . . . . . . . . . . . 5
5. Delay Sensitive Applications . . . . . . . . . . . . . . . . . 8 5. Advanced Multipath Use Cases . . . . . . . . . . . . . . . . 7
6. Large Volume of IP and LDP Traffic . . . . . . . . . . . . . . 9 5.1. Delay Sensitive Applications . . . . . . . . . . . . . . 7
7. Multipath and Packet Ordering . . . . . . . . . . . . . . . . 9 5.2. Large Volume of IP and LDP Traffic . . . . . . . . . . . 8
7.1. MPLS-TP in network edges only . . . . . . . . . . . . . . 11 5.3. Multipath and Packet Ordering . . . . . . . . . . . . . . 9
7.2. Multipath at core LSP ingress/egress . . . . . . . . . . . 12 5.3.1. MPLS-TP in network edges only . . . . . . . . . . . . 10
7.3. MPLS-TP as a MPLS client . . . . . . . . . . . . . . . . . 13 5.3.2. Multipath at core LSP ingress/egress . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.3.3. MPLS-TP as a MPLS client . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. Informative References . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. More Details on Existing Network Operator 9. Informative References . . . . . . . . . . . . . . . . . . . 13
Practices and Protocol Usage . . . . . . . . . . . . 17 Appendix A. Network Operator Practices and Protocol Usage . . . 16
Appendix B. Existing Multipath Standards and Techniques . . . . . 19 Appendix B. Existing Multipath Standards and Techniques . . . . 18
B.1. Common Multpath Load Spliting Techniques . . . . . . . . . 19 B.1. Common Multpath Load Spliting Techniques . . . . . . . . 19
B.2. Static and Dynamic Load Balancing Multipath . . . . . . . 21 B.2. Static and Dynamic Load Balancing Multipath . . . . . . . 20
B.3. Traffic Split over Parallel Links . . . . . . . . . . . . 21 B.3. Traffic Split over Parallel Links . . . . . . . . . . . . 20
B.4. Traffic Split over Multiple Paths . . . . . . . . . . . . 22 B.4. Traffic Split over Multiple Paths . . . . . . . . . . . . 21
Appendix C. Characteristics of Transport in Core Networks . . . . 22 Appendix C. Characteristics of Transport in Core Networks . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Advanced Multipath requirements are specified in Advanced Multipath requirements are specified in
[I-D.ietf-rtgwg-cl-requirement]. An Advanced Multipath framework is [I-D.ietf-rtgwg-cl-requirement]. An Advanced Multipath framework is
defined in [I-D.ietf-rtgwg-cl-framework]. defined in [I-D.ietf-rtgwg-cl-framework].
Multipath techniques have been widely used in IP networks for over Multipath techniques have been widely used in IP networks for over
two decades. The use of MPLS began more than a decade ago. two decades. The use of MPLS began more than a decade ago.
Multipath has been widely used in IP/MPLS networks for over a decade Multipath has been widely used in IP/MPLS networks for over a decade
skipping to change at page 4, line 7 skipping to change at page 3, line 49
Edge Router (LER) or a Label Switch Router (LSR) as defined in Edge Router (LER) or a Label Switch Router (LSR) as defined in
[RFC3031]. [RFC3031].
The IP DSCP field [RFC2474] [RFC2475] cannot be used for flow The IP DSCP field [RFC2474] [RFC2475] cannot be used for flow
identification since L3VPN requires Diffserv transparency (see RFC identification since L3VPN requires Diffserv transparency (see RFC
4031 5.5.2 [RFC4031]), and in general network operators do not rely 4031 5.5.2 [RFC4031]), and in general network operators do not rely
on the DSCP of Internet packets. on the DSCP of Internet packets.
3. Terminology 3. Terminology
Terminology defined in [I-D.ietf-rtgwg-cl-requirement] is used in Terminology defined in [I-D.ietf-rtgwg-cl-requirement] and
this document. [I-D.ietf-mpls-multipath-use] is used in this document.
In addition, the following terms are used: In addition, the following terms are used:
classic multipath: classic multipath:
Classic multipath refers to the most common current practice in Classic multipath refers to the most common current practice in
implementation and deployment of multipath (see Appendix B). The implementation and deployment of multipath (see Appendix B). The
most common current practice makes use of a hash on the MPLS most common current practice when applied to MPLS traffic makes
label stack and if IPv4 or IPv6 are indicates under the label use of a hash on the MPLS label stack, and if IPv4 or IPv6 are
stack, makes use of the IP source and destination addresses indicated under the label stack, makes use of the IP source and
[RFC4385] [RFC4928]. destination addresses [RFC4385] [RFC4928].
classic link bundling: classic link bundling:
Classic link bundling refers to the use of [RFC4201] where the Classic link bundling refers to the use of [RFC4201] where the
"all ones" component is not used. Where the "all ones" component "all ones" component is not used. Where the "all ones" component
is used, link bundling behaves as classic multipath does. is used, link bundling behaves as classic multipath does.
Classic link bundling selects a single component link to carry Classic link bundling selects a single component link to carry
all of the traffic for a given LSP. all of the traffic for a given LSP.
Among the important distinctions between classic multipath or classic Among the important distinctions between classic multipath or classic
link bundling and Advanced Multipath are: link bundling and Advanced Multipath are:
skipping to change at page 4, line 44 skipping to change at page 4, line 37
Advanced Multipath allows per LSP control of load split Advanced Multipath allows per LSP control of load split
characteristics. characteristics.
2. Classic multipath and classic link bundling do not provide a 2. Classic multipath and classic link bundling do not provide a
means to put some LSP on component links with lower delay. means to put some LSP on component links with lower delay.
Advanced Multipath does. Advanced Multipath does.
3. Classic multipath will provide a load balance for IP and LDP 3. Classic multipath will provide a load balance for IP and LDP
traffic. Classic link bundling will not. Neither classic traffic. Classic link bundling will not. Neither classic
multipath or classic link bundling will measure IP and LDP multipath or classic link bundling will measure IP and LDP
traffic and reduce the advertised "Available Bandwidth" as a traffic and reduce the RSVP-TE advertised "Available Bandwidth"
result of that measurement. Advanced Multipath better supports as a result of that measurement. Advanced Multipath better
RSVP-TE used with significant traffic levels of native IP and supports RSVP-TE used with significant traffic levels of native
native LDP. IP and native LDP.
4. Classic link bundling cannot support an LSP that is greater in 4. Classic link bundling cannot support an LSP that is greater in
capacity than any single component link. Classic multipath capacity than any single component link. Classic multipath
supports this capability but may reorder traffic on such an LSP. supports this capability but may reorder traffic on such an LSP.
Advanced Multipath can retain order of an LSP that is carried Advanced Multipath can retain order of an LSP that is carried
within an LSP that is greater in capacity than any single within an LSP that is greater in capacity than any single
component link if the contained LSP has such a requirement. component link if the contained LSP has such a requirement.
None of these techniques, classic multipath, classic link bundling, None of these techniques, classic multipath, classic link bundling,
or Advanced Multipath, will reorder traffic among IP microflows. or Advanced Multipath, will reorder traffic among IP microflows.
skipping to change at page 6, line 5 skipping to change at page 5, line 32
one TE-Link advertised into the IGP by the multipath end points (the one TE-Link advertised into the IGP by the multipath end points (the
LER if the multipath is MPLS based). This information is used in LER if the multipath is MPLS based). This information is used in
path computation when a full MPLS control plane is in use. path computation when a full MPLS control plane is in use.
If Advanced Multipath techniques are used, then the individual If Advanced Multipath techniques are used, then the individual
component links or groups of component links may optionally be component links or groups of component links may optionally be
advertised into the IGP as sub-TLV of the multipath FA advertisement advertised into the IGP as sub-TLV of the multipath FA advertisement
to indicate capacity available with various characteristics, such as to indicate capacity available with various characteristics, such as
a delay range. a delay range.
Management Plane Management Plane
Configuration and Measurement <------------+ Configuration and Measurement <------------+
^ | ^ |
| | | |
+-------+-+ +-+-------+ +-------+-+ +-+-------+
| | | | | | | | | | | |
CP Packets V | | V CP Packets CP Packets V | | V CP Packets
| V | | Component Link 1 | | ^ | | V | | Component Link 1 | | ^ |
| | |=|===========================|=| | | | | |=|===========================|=| | |
| +----| | Component Link 2 | |----+ | | +----| | Component Link 2 | |----+ |
| |=|===========================|=| | | |=|===========================|=| |
Aggregated LSPs | | | | | Aggregated LSPs | | | | |
~|~~~~~~>| | Component Link 3 | |~~~~>~~|~~ ~|~~~~~~>| | Component Link 3 | |~~~~>~~|~~
| |=|===========================|=| | | |=|===========================|=| |
| | | | | | | | | | | |
| LSR1 | | LSR2 | | LSR1 | | LSR2 |
+---------+ +---------+ +---------+ +---------+
! ! ! !
! ! ! !
!<-------- Multipath ---------->! !<-------- Multipath ---------->!
Figure 1: a multipath constructed with multiple physical links Figure 1: a multipath constructed with multiple physical links
between two LSR between two LSR
[I-D.ietf-rtgwg-cl-requirement] specifies that component links may [I-D.ietf-rtgwg-cl-requirement] specifies that component links may
themselves be multipath. This is true for most implementations even themselves be multipath. This is true for most implementations even
prior to the Advanced Multipath work in prior to the Advanced Multipath work in
[I-D.ietf-rtgwg-cl-requirement]. For example, a component of a pre- [I-D.ietf-rtgwg-cl-requirement]. For example, a component of a pre-
Advanced Multipath MPLS Link Bundle or ISIS or OSPF ECMP could be an Advanced Multipath MPLS Link Bundle or ISIS or OSPF ECMP could be an
Ethernet LAG. In some implementations many other combinations or Ethernet LAG. In some implementations many other combinations or
even arbitrary combinations could be supported. Figure 2 shows three even arbitrary combinations could be supported. Figure 2 shows three
three forms of component links which may be deployed in a network. three forms of component links which may be deployed in a network.
+-------+ 1. Physical Link +-------+ +-------+ 1. Physical Link +-------+
| |-|----------------------------------------------|-| | | |-|----------------------------------------------|-| |
| | | | | | | | | | | |
| | | +------+ +------+ | | | | | | +------+ +------+ | | |
| | | | MPLS | 2. Logical Link | MPLS | | | | | | | | MPLS | 2. Logical Link | MPLS | | | |
| |.|.... |......|.....................|......|....|.| | | |.|.... |......|.....................|......|....|.| |
| | |-----| LSR3 |---------------------| LSR4 |----| | | | | |-----| LSR3 |---------------------| LSR4 |----| | |
| | | +------+ +------+ | | | | | | +------+ +------+ | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
| | | +------+ +------+ | | | | | | +------+ +------+ | | |
| | | |GMPLS | 3. Logical Link |GMPLS | | | | | | | |GMPLS | 3. Logical Link |GMPLS | | | |
| |.|. ...|......|.....................|......|....|.| | | |.|. ...|......|.....................|......|....|.| |
| | |-----| LSR5 |---------------------| LSR6 |----| | | | | |-----| LSR5 |---------------------| LSR6 |----| | |
| | +------+ +------+ | | | | +------+ +------+ | |
| LSR1 | | LSR2 | | LSR1 | | LSR2 |
+-------+ +-------+ +-------+ +-------+
|<---------------- Multipath --------------------->| |<---------------- Multipath --------------------->|
Figure 2: Illustration of Various Component Link Types Figure 2: Illustration of Various Component Link Types
The three forms of component link shown in Figure 2 are: The three forms of component link shown in Figure 2 are:
1. The first component link is configured with direct physical media 1. The first component link is configured with direct physical media
plus a link layer protocol. This case also includes emulated plus a link layer protocol. This case also includes emulated
physical links, for example using pseudowire emulation. physical links, for example using pseudowire emulation.
2. The second component link is a TE tunnel that traverses LSR3 and 2. The second component link is a TE tunnel that traverses LSR3 and
skipping to change at page 8, line 12 skipping to change at page 7, line 25
sends them to MPLS forwarding engine with no attempt to reorder sends them to MPLS forwarding engine with no attempt to reorder
packets arriving on different component links. The traffic in the packets arriving on different component links. The traffic in the
opposite direction, from LSR2 to LSR1, is distributed across the set opposite direction, from LSR2 to LSR1, is distributed across the set
of component links by the LSR2. of component links by the LSR2.
These three forms of component link are a limited set of very simple These three forms of component link are a limited set of very simple
examples. Many other examples are possible. A component link may examples. Many other examples are possible. A component link may
itself be a multipath. A segment of an LSP (single hop for that LSP) itself be a multipath. A segment of an LSP (single hop for that LSP)
may be a multipath. may be a multipath.
5. Delay Sensitive Applications 5. Advanced Multipath Use Cases
The following subsections provide some uses of the Advanced Multipath
extensions. These are not the only uses, simply a set of examples.
5.1. Delay Sensitive Applications
Most applications benefit from lower delay. Some types of Most applications benefit from lower delay. Some types of
applications are far more sensitive than others. For example, real applications are far more sensitive than others. For example, real
time bidirectional applications such as voice communication or two time bidirectional applications such as voice communication or two
way video conferencing are far more sensitive to delay than way video conferencing are far more sensitive to delay than
unidirectional streaming audio or video. Non-interactive bulk unidirectional streaming audio or video. Non-interactive bulk
transfer is almost insensitive to delay if a large enough TCP window transfer is almost insensitive to delay if a large enough TCP window
is used. is used.
Some applications are sensitive to delay but users of those Some applications are sensitive to delay but users of those
skipping to change at page 8, line 36 skipping to change at page 8, line 5
time. time.
Other applications are sensitive to delay and willing to pay extra to Other applications are sensitive to delay and willing to pay extra to
insure lower delay. For example, financial trading applications are insure lower delay. For example, financial trading applications are
extremely sensitive to delay and with a lot at stake are willing to extremely sensitive to delay and with a lot at stake are willing to
go to great lengths to reduce delay. go to great lengths to reduce delay.
Among the requirements of Advanced Multipath are requirements to Among the requirements of Advanced Multipath are requirements to
support non-homogeneous links. One solution in support of lower support non-homogeneous links. One solution in support of lower
delay links is to advertise capacity available within configured delay links is to advertise capacity available within configured
ranges of delay within a given multipath and the support the ability ranges of delay within a given multipath and then support the ability
to place an LSP only on component links that meeting that LSP's delay to place an LSP only on component links that meeting that LSP's delay
requirements. requirements.
The Advanced Multipath requirements to accommodate delay sensitive The Advanced Multipath requirements to accommodate delay sensitive
applications are analogous to Diffserv requirements to accommodate applications are analogous to Diffserv requirements to accommodate
applications requiring higher quality of service on the same applications requiring higher quality of service on the same
infrastructure as applications with less demanding requirements. The infrastructure as applications with less demanding requirements. The
ability to share capacity with less demanding applications, with best ability to share capacity with less demanding applications, with best
effort applications being the least demanding, can greatly reduce the effort applications generally being the least demanding, can greatly
cost of delivering service to the more demanding applications. reduce the cost of delivering service to the more demanding
applications.
6. Large Volume of IP and LDP Traffic 5.2. Large Volume of IP and LDP Traffic
IP and LDP do not support traffic engineering. Both make use of a IP and LDP do not support traffic engineering. Both make use of a
shortest (lowest routing metric) path, with an option to use equal shortest (lowest routing metric) path, with an option to use equal
cost multipath (ECMP). Note that though ECMP is prohibited in LDP cost multipath (ECMP). Note that though ECMP is prohibited in LDP
specifications, it is widely implemented. Where implemented for LDP, specifications, it is widely implemented. Where implemented for LDP,
ECMP is generally disabled by default for standards compliance, but ECMP is generally disabled by default for standards compliance, but
often enabled in LDP deployments. often enabled in LDP deployments.
Without traffic engineering capability, there must be sufficient Without traffic engineering capability, there must be sufficient
capacity to accommodate the IP and LDP traffic. If not, persistent capacity to accommodate the IP and LDP traffic. If not, persistent
queuing delay and loss will occur. Unlike RSVP-TE, a subset of queuing delay and loss will occur. Unlike RSVP-TE, a subset of
traffic cannot be routed using constraint based routing to avoid a traffic cannot be routed using constraint based routing to avoid a
congested portion of an infrastructure. congested portion of an infrastructure.
In existing networks which accommodate IP and/or LDP with RSVP-TE, In existing networks which accommodate IP and/or LDP with RSVP-TE,
either the IP and LDP can be carried over RSVP-TE, or where the either the IP and LDP can be carried over RSVP-TE, or where the
traffic contribution of IP and LDP is small, IP and LDP can be traffic contribution of IP and LDP is small, IP and LDP can be
carried native and the effect on RSVP-TE can be ignored. Ignoring carried native and the effect on RSVP-TE can be ignored. Ignoring
the traffic contribution of IP is certainly valid on high capacity the traffic contribution of IP is valid on high capacity networks
networks where native IP is used primarily for control and network where a very low volume of native IP is used primarily for control
management and customer IP is carried within RSVP-TE. and network management and customer IP is carried within RSVP-TE.
Where it is desirable to carry native IP and/or LDP and IP and/or LDP Where it is desirable to carry native IP and/or LDP and IP and/or LDP
traffic volumes are not negligible, RSVP-TE needs improvement. An traffic volumes are not negligible, RSVP-TE needs improvement. An
enhancement offered by Advanced Multipath is an ability to measure enhancement offered by Advanced Multipath is an ability to measure
the IP and LDP, filter the measurements, and reduce the capacity the IP and LDP, filter the measurements, and reduce the capacity
available to RSVP-TE to avoid congestion. The treatment given to the available to RSVP-TE to avoid congestion. The treatment given to the
IP or LDP traffic is similar to the treatment when using the "auto- IP or LDP traffic is similar to the treatment when using the "auto-
bandwidth" feature in some RSVP-TE implementations on that same bandwidth" feature in some RSVP-TE implementations on that same
traffic, and giving a higher priority (numerically lower setup traffic, and giving a higher priority (numerically lower setup
priority and holding priority value) to the "auto-bandwidth" LSP. priority and holding priority value) to the "auto-bandwidth" LSP.
The difference is that the measurement is made at each hop and the The difference is that the measurement is made at each hop and the
reduction in advertised bandwidth is made more directly. reduction in advertised bandwidth is made more directly.
7. Multipath and Packet Ordering 5.3. Multipath and Packet Ordering
A strong motivation for multipath is the need to provide LSP capacity A strong motivation for multipath is the need to provide LSP capacity
in IP backbones that exceeds the capacity of single wavelengths in IP backbones that exceeds the capacity of single wavelengths
provided by transport equipment and exceeds the practical capacity provided by transport equipment and exceeds the practical capacity
limits achievable through inverse multiplexing. Appendix C describes limits achievable through inverse multiplexing. Appendix C describes
characteristics and limitations of transport systems today. characteristics and limitations of transport systems today.
Section 3 defines the terms "classic multipath" and "classic link Section 3 defines the terms "classic multipath" and "classic link
bundling" used in this section. bundling" used in this section.
For purpose of discussion, consider two very large cities, city A and For purpose of discussion, consider two very large cities, city A and
city Z. For example, in the US high traffic cities might be New York city Z. For example, in the US high traffic cities might be New York
and Los Angeles and in Europe high traffic cities might be London and and Los Angeles and in Europe high traffic cities might be London and
Amsterdam. Two other high volume cities, city B and city Y may share Amsterdam. Two other high volume cities, city B and city Y may share
common provider core network infrastructure. Using the same common provider core network infrastructure. Using the same
examples, the city B and Y may Washington DC and San Francisco or examples, the city B and Y may Washington DC and San Francisco or
Paris and Stockholm. In the US, the common infrastructure may span Paris and Stockholm. In the US, the common infrastructure may span
Denver, Chicago, Detroit, and Cleveland. Other major traffic Denver, Chicago, Detroit, and Cleveland. Other major traffic
contributors on either US coast include Boston, northern Virginia on contributors on either US coast include Boston, northern Virginia on
the east coast, and Seattle, and San Diego on the west coast. The the east coast, and Seattle, and San Diego on the west coast. The
capacity of IP/MPLS links within the shared infrastructure, for capacity of IP/MPLS links within the shared infrastructure, for
example city to city links in the Denver, Chicago, Detroit, and example city to city links in the Denver, Chicago, Detroit, and
skipping to change at page 11, line 17 skipping to change at page 10, line 31
Advanced Multipath at core LSP ingress/egress Advanced Multipath at core LSP ingress/egress
The interior of the core network may use classic link bundling, The interior of the core network may use classic link bundling,
with the limitation that no LSP can exceed the capacity of a with the limitation that no LSP can exceed the capacity of a
single circuit. Larger non-MPLS-TP LSP can be configured using single circuit. Larger non-MPLS-TP LSP can be configured using
multiple ingress to egress component MPLS-TP LSP. This can be multiple ingress to egress component MPLS-TP LSP. This can be
accomplished using existing IP source and destination address accomplished using existing IP source and destination address
hashing configured at LSP ingress and egress. Each component hashing configured at LSP ingress and egress. Each component
LSP, if constrained to be no larger than the capacity of a single LSP, if constrained to be no larger than the capacity of a single
circuit. can make use of MPLS-TP and offer OAM for all top level circuit, can make use of MPLS-TP and offer OAM for all top level
LSP across the core. LSP across the core.
MPLS-TP as a MPLS client MPLS-TP as a MPLS client
A third approach involves making use of Entropy Labels [RFC6790] A third approach involves making use of Entropy Labels [RFC6790]
on all MPLS-TP LSP such that the entire MPLS-TP LSP is treated as on all MPLS-TP LSP such that the entire MPLS-TP LSP is treated as
a microflow by midpoint LSR, even if further encapsulated in very a microflow by midpoint LSR, even if further encapsulated in very
large server layer MPLS LSP. large server layer MPLS LSP.
The above list of alternatives allow packet ordering within an LSP to The above list of alternatives allow packet ordering within an LSP to
be maintained in some circumstances and allow very large LSP be maintained in some circumstances and allow very large LSP
capacities. Each of these alternatives are discussed further in the capacities. Each of these alternatives are discussed further in the
following subsections. following subsections.
7.1. MPLS-TP in network edges only 5.3.1. MPLS-TP in network edges only
Classic MPLS link bundling is defined in [RFC4201] and has existed Classic MPLS link bundling is defined in [RFC4201] and has existed
since early in the 2000s decade. Classic MPLS link bundling place since early in the 2000s decade. Classic MPLS link bundling place
any given LSP entirely on a single component link. Classic MPLS link any given LSP entirely on a single component link. Classic MPLS link
bundling is not in widespread use as the means to accommodate large bundling is not in widespread use as the means to accommodate large
link capacities in core networks due to the simplicity and better link capacities in core networks due to the simplicity and better
multiplexing gain, and therefore lower network cost of classic multiplexing gain, and therefore lower network cost of classic
multipath. multipath.
If MPLS-TP OAM capability in the IP/MPLS network core LSP is not If MPLS-TP OAM capability in the IP/MPLS network core LSP is not
skipping to change at page 12, line 6 skipping to change at page 11, line 19
which use classic multipath and both label stack and IP source and which use classic multipath and both label stack and IP source and
destination address based hashing as a basis for load splitting. destination address based hashing as a basis for load splitting.
If MPLS-TP is needed for a subset of LSP, then those LSP can be If MPLS-TP is needed for a subset of LSP, then those LSP can be
carried within pseudowires. The pseudowires adds a thin layer of carried within pseudowires. The pseudowires adds a thin layer of
encapsulation and therefore a small overhead. If only a subset of encapsulation and therefore a small overhead. If only a subset of
LSP need MPLS-TP OAM, then some LSP must make use of the pseudowires LSP need MPLS-TP OAM, then some LSP must make use of the pseudowires
and other LSP avoid them. A straightforward way to accomplish this and other LSP avoid them. A straightforward way to accomplish this
is with administrative attributes [RFC3209]. is with administrative attributes [RFC3209].
7.2. Multipath at core LSP ingress/egress 5.3.2. Multipath at core LSP ingress/egress
Multipath can be configured for large LSP that are made of smaller Multipath can be configured for large LSP that are made of smaller
MPLS-TP component LSP. Some implementations already support this MPLS-TP component LSP. Some implementations already support this
capability, though until Advanced Multipath no IETF document required capability, though until Advanced Multipath no IETF document required
it. This approach is capable of supporting MPLS-TP OAM over the it. This approach is capable of supporting MPLS-TP OAM over the
entire set of component link LSP and therefore the entire set of top entire set of component link LSP and therefore the entire set of top
level LSP traversing the core. level LSP traversing the core.
There are two primary disadvantage of this approach. One is the There are two primary disadvantage of this approach. One is the
number of top level LSP traversing the core can be dramatically number of top level LSP traversing the core can be dramatically
skipping to change at page 13, line 29 skipping to change at page 12, line 42
There are two situations which can motivate the use of this approach. There are two situations which can motivate the use of this approach.
This design is favored if the provider values MPLS-TP OAM across the This design is favored if the provider values MPLS-TP OAM across the
core more than efficiency (or is unaware of the efficiency issue). core more than efficiency (or is unaware of the efficiency issue).
This design can also make sense if transport equipment or very low This design can also make sense if transport equipment or very low
cost core LSR are available which support only classic link bundling cost core LSR are available which support only classic link bundling
and regardless of loss of multiplexing gain, are more cost effective and regardless of loss of multiplexing gain, are more cost effective
at carrying transit traffic than using equipment which supports IP at carrying transit traffic than using equipment which supports IP
source and destination address hashing. source and destination address hashing.
7.3. MPLS-TP as a MPLS client 5.3.3. MPLS-TP as a MPLS client
Accommodating MPLS-TP as a MPLS client requires the small change to Accommodating MPLS-TP as a MPLS client requires the small change to
forwarding behavior necessary to support [RFC6790] and is therefore forwarding behavior necessary to support [RFC6790] and is therefore
most applicable to major network overbuilds or new deployments. This most applicable to major network overbuilds or new deployments. This
approach is described in [I-D.ietf-mpls-multipath-use] and makes use approach is described in [I-D.ietf-mpls-multipath-use] and makes use
of Entropy Labels [RFC6790] to prevent reordering of MPLS-TP LSP or of Entropy Labels [RFC6790] to prevent reordering of MPLS-TP LSP or
any other LSP which requires that its traffic not be reordered for any other LSP which requires that its traffic not be reordered for
OAM or other reasons. OAM or other reasons.
The advantage of this approach is an ability to accommodate MPLS-TP The advantage of this approach is an ability to accommodate MPLS-TP
as a client LSP but retain the high multiplexing gain and therefore as a client LSP but retain the high multiplexing gain and therefore
efficiency and low network cost of a pure MPLS deployment. The efficiency and low network cost of a pure MPLS deployment. The
disadvantage is the need for a small change in forwarding to support disadvantage is the need for a small change in forwarding to support
[RFC6790]. [RFC6790].
8. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 7. Security Considerations
This document is a use cases document. Existing protocols are This document is a use cases document. Existing protocols are
referenced such as MPLS. Existing techniques such as MPLS link referenced such as MPLS. Existing techniques such as MPLS link
bundling and multipath techniques are referenced. These protocols bundling and multipath techniques are referenced. These protocols
and techniques are documented elsewhere and contain security and techniques are documented elsewhere and contain security
considerations which are unchanged by this document. considerations which are unchanged by this document.
This document also describes use cases for multipath and Advanced This document also describes use cases for multipath and Advanced
Multipath. Advanced Multipath requirements are defined in Multipath. Advanced Multipath requirements are defined in
[I-D.ietf-rtgwg-cl-requirement]. [I-D.ietf-rtgwg-cl-framework] [I-D.ietf-rtgwg-cl-requirement]. [I-D.ietf-rtgwg-cl-framework]
defines a framework for Advanced Multipath. Advanced Multipath bears defines a framework for Advanced Multipath. Advanced Multipath bears
many similarities to MPLS link bundling and multipath techniques used many similarities to MPLS link bundling and multipath techniques used
with MPLS. Additional security considerations, if any, beyond those with MPLS. Additional security considerations, if any, beyond those
already identified for MPLS, MPLS link bundling and multipath already identified for MPLS, MPLS link bundling and multipath
techniques, will be documented in the framework document if specific techniques, will be documented in the framework document if specific
to the overall framework of Advanced Multipath, or in protocol to the overall framework of Advanced Multipath, or in protocol
extensions if specific to a given protocol extension defined later to extensions if specific to a given protocol extension defined later to
support Advanced Multipath. support Advanced Multipath.
10. Acknowledgments 8. Acknowledgments
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. Much of the work done by Andy Malis occurred while Andy
was at Verizon.
11. Informative References 9. Informative References
[I-D.ietf-mpls-multipath-use] [I-D.ietf-mpls-multipath-use]
Villamizar, C., "Use of Multipath with MPLS-TP and MPLS", Villamizar, C., "Use of Multipath with MPLS-TP and MPLS",
draft-ietf-mpls-multipath-use-00 (work in progress), draft-ietf-mpls-multipath-use-00 (work in progress),
February 2013. February 2013.
[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-03 Label Switching (MPLS)", draft-ietf-rtgwg-cl-framework-03
skipping to change at page 15, line 13 skipping to change at page 14, line 23
progress), July 2013. progress), July 2013.
[IEEE-802.1AX] [IEEE-802.1AX]
IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE
Standard for Local and Metropolitan Area Networks - Link Standard for Local and Metropolitan Area Networks - Link
Aggregation", 2006, <http://standards.ieee.org/getieee802/ Aggregation", 2006, <http://standards.ieee.org/getieee802/
download/802.1AX-2008.pdf>. download/802.1AX-2008.pdf>.
[ITU-T.G.694.2] [ITU-T.G.694.2]
ITU-T, "Spectral grids for WDM applications: CWDM ITU-T, "Spectral grids for WDM applications: CWDM
wavelength grid", 2003, wavelength grid ", 2003,
<http://www.itu.int/rec/T-REC-G.694.2-200312-I>. <http://www.itu.int/rec/T-REC-G.694.2-200312-I>.
[RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The [RFC1717] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The
PPP Multilink Protocol (MP)", RFC 1717, November 1994. PPP Multilink Protocol (MP)", RFC 1717, November 1994.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474, December
December 1998. 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
June 1999. June 1999.
skipping to change at page 16, line 11 skipping to change at page 15, line 22
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, April 2002.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002. Services", RFC 3270, May 2002.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630, September
September 2003. 2003.
[RFC3809] Nagarajan, A., "Generic Requirements for Provider [RFC3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC 3809, Provisioned Virtual Private Networks (PPVPN)", RFC 3809,
June 2004. June 2004.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005. Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer
3 Provider Provisioned Virtual Private Networks (PPVPNs)", 3 Provider Provisioned Virtual Private Networks (PPVPNs)",
RFC 4031, April 2005. RFC 4031, April 2005.
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
June 2005. 2005.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006. Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128, Cost Multipath Treatment in MPLS Networks", BCP 128, RFC
RFC 4928, June 2007. 4928, June 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, October 2008.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", RFC
Berger, "A Framework for MPLS in Transport Networks", 5921, July 2010.
RFC 5921, July 2010.
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow-Aware Transport of Pseudowires J., and S. Amante, "Flow-Aware Transport of Pseudowires
over an MPLS Packet Switched Network", RFC 6391, over an MPLS Packet Switched Network", RFC 6391, November
November 2011. 2011.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, November 2012.
Appendix A. More Details on Existing Network Operator Practices and Appendix A. Network Operator Practices and Protocol Usage
Protocol Usage
Often, network operators have a contractual Service Level Agreement Often, network operators have a contractual Service Level Agreement
(SLA) with customers for services that are comprised of numerical (SLA) with customers for services that are comprised of numerical
values for performance measures, principally availability, latency, values for performance measures, principally availability, latency,
delay variation. Additionally, network operators may have delay variation. Additionally, network operators may have
performance objectives for internal use by the operator. See performance objectives for internal use by the operator. See
RFC3809, Section 4.9 [RFC3809] for examples of the form of such SLA RFC3809, Section 4.9 [RFC3809] for examples of the form of such SLA
and performance objective specifications. In this document we use and performance objective specifications. In this document we use
the term Performance Objective as defined in the term Performance Objective as defined in
[I-D.ietf-rtgwg-cl-requirement]. Applications and acceptable user [I-D.ietf-rtgwg-cl-requirement]. Applications and acceptable user
experience have an important relationship to these performance experience have an important relationship to these performance
parameters. parameters.
Consider latency as an example. In some cases, minimizing latency Consider latency as an example. In some cases, minimizing latency
relates directly to the best customer experience (for example, in relates directly to the best customer experience (for example, in
interactive applications closer is faster). In other cases, user interactive applications closer is faster). In other cases, user
experience is relatively insensitive to latency, up to a specific experience is relatively insensitive to latency, up to a specific
limit at which point user perception of quality degrades limit at which point user perception of quality degrades
significantly (e.g., interactive human voice and multimedia significantly (e.g., interactive human voice and multimedia
conferencing). A number of Performance Objectives have. a bound on conferencing). A number of Performance Objectives have a bound on
point-to-point latency, and as long as this bound is met, the point-to-point latency and as long as this bound is met the
Performance Objective is met -- decreasing the latency is not Performance Objective is met; decreasing the latency is not
necessary. In some Performance Objectives, if the specified latency necessary. In some Performance Objectives, if the specified latency
is not met, the user considers the service as unavailable. An is not met, the user considers the service as unavailable. An
unprotected LSP can be manually provisioned on a set of links to meet unprotected LSP can be manually provisioned on a set of links to meet
this type of Performance Objective, but this lowers availability this type of Performance Objective, but this lowers availability
since an alternate route that meets the latency Performance Objective since an alternate route that meets the latency Performance Objective
cannot be determined. cannot be determined.
Historically, when an IP/MPLS network was operated over a lower layer Historically, when an IP/MPLS network was operated over a lower layer
circuit switched network (e.g., SONET rings), a change in latency circuit switched network (e.g., SONET rings), a change in latency
caused by the lower layer network (e.g., due to a maintenance action caused by the lower layer network (e.g., due to a maintenance action
skipping to change at page 19, line 6 skipping to change at page 18, line 14
The IP DSCP cannot be used for flow identification. The use of IP The IP DSCP cannot be used for flow identification. The use of IP
DSCP for flow identification is incompatible with Assured Forwarding DSCP for flow identification is incompatible with Assured Forwarding
services [RFC2597] or any other service which may use more than one services [RFC2597] or any other service which may use more than one
DSCP code point to carry traffic for a given microflow. In general DSCP code point to carry traffic for a given microflow. In general
network operators do not rely on the DSCP of Internet packets in core network operators do not rely on the DSCP of Internet packets in core
networks but must preserve DSCP values for use closer to network networks but must preserve DSCP values for use closer to network
edges. edges.
A label is pushed onto Internet packets when they are carried along A label is pushed onto Internet packets when they are carried along
with L2/L3VPN packets on the same link or lower layer network with L2VPN or L3VPN packets on the same link or lower layer network
provides a mean to distinguish between the QoS class for these provides a mean to distinguish between the QoS class for these
packets. packets.
Operating an MPLS-TE network involves a different paradigm from Operating an MPLS-TE network involves a different paradigm from
operating an IGP metric-based LDP signaled MPLS network. The operating an IGP metric-based LDP signaled MPLS network. The
multipoint-to-point LDP signaled MPLS LSPs occur automatically, and multipoint-to-point LDP signaled MPLS LSPs occur automatically, and
balancing across parallel links occurs if the IGP metrics are set balancing across parallel links occurs if the IGP metrics are set
"equally" (with equality a locally definable relation) and if ECMP is "equally" (with equality a locally definable relation) and if ECMP is
enabled for LDP, which it large network operators generally do. enabled for LDP, which network operators generally do in large
networks.
Traffic is typically comprised of large (some very large) flows and a Traffic is typically comprised of large (some very large) flows and a
much larger number of small flows. In some cases, separate LSPs are much larger number of small flows. In some cases, separate LSPs are
established for very large flows. Very large microflows can occur established for very large flows. Very large microflows can occur
even if the IP header information is inspected by a LSR. For example even if the IP header information is inspected by a LSR. For example
an IPsec tunnel that carries a large amount of traffic must be an IPsec tunnel that carries a large amount of traffic must be
carried as a single large flow. An important example of large flows carried as a single large flow. An important example of large flows
is that of a L2/L3 VPN customer who has an access line bandwidth is that of a L2VPN or L3VPN customer who has an access line bandwidth
comparable to a client-client component link bandwidth -- there could comparable to a client-client component link bandwidth -- there could
be flows that are on the order of the access line bandwidth. be flows that are on the order of the access line bandwidth.
Appendix B. Existing Multipath Standards and Techniques Appendix B. Existing Multipath Standards and Techniques
Today the requirement to handle large aggregations of traffic, much Today the requirement to handle large aggregations of traffic, much
larger than a single component link, can be handled by a number of larger than a single component link, can be handled by a number of
techniques which we will collectively call multipath. Multipath techniques which we will collectively call multipath. Multipath
applied to parallel links between the same set of nodes includes applied to parallel links between the same set of nodes includes
Ethernet Link Aggregation [IEEE-802.1AX], link bundling [RFC4201], or Ethernet Link Aggregation [IEEE-802.1AX], link bundling [RFC4201], or
other aggregation techniques some of which may be vendor specific. other aggregation techniques some of which may be vendor specific.
Multipath applied to diverse paths rather than parallel links Multipath applied to diverse paths rather than parallel links
includes Equal Cost MultiPath (ECMP) as applied to OSPF, ISIS, LDP, includes Equal Cost MultiPath (ECMP) as applied to OSPF, ISIS, LDP,
or even BGP, and equal cost LSP, as described in Appendix B.4. or even BGP, and equal cost LSP, as described in Appendix B.4.
Various multipath techniques have strengths and weaknesses. Various multipath techniques have strengths and weaknesses.
Existing multipath techniques solve the problem of large aggregations Existing multipath techniques solve the problem of large aggregations
of traffic, without addressing the other requirements outlined in of traffic, without addressing the other requirements outlined in
this document, particularly those described in Section 5 and this document, particularly those described in Section 5.
Section 6.
B.1. Common Multpath Load Spliting Techniques B.1. Common Multpath Load Spliting Techniques
Identical load balancing techniques are used for multipath both over Identical load balancing techniques are used for multipath both over
parallel links and over diverse paths. parallel links and over diverse paths.
Large aggregates of IP traffic do not provide explicit signaling to Large aggregates of IP traffic do not provide explicit signaling to
indicate the expected traffic loads. Large aggregates of MPLS indicate the expected traffic loads. Large aggregates of MPLS
traffic are carried in MPLS tunnels supported by MPLS LSP. LSP which traffic are carried in MPLS tunnels supported by MPLS LSP. LSP which
are signaled using RSVP-TE extensions do provide explicit signaling are signaled using RSVP-TE extensions do provide explicit signaling
skipping to change at page 23, line 51 skipping to change at page 23, line 12
the decade but more IP/MPLS core networks had only a small number of the decade but more IP/MPLS core networks had only a small number of
IP/MPLS links requiring 4-8 parallel 10 Gb/s circuits. However, the IP/MPLS links requiring 4-8 parallel 10 Gb/s circuits. However, the
use of multipath was necessary, was deemed the simplest and most cost use of multipath was necessary, was deemed the simplest and most cost
effective alternative, and became thoroughly entrenched. By the end effective alternative, and became thoroughly entrenched. By the end
of the 2000s decade nearly all major IP/MPLS core service provider of the 2000s decade nearly all major IP/MPLS core service provider
networks and a few content provider networks had IP/MPLS links which networks and a few content provider networks had IP/MPLS links which
exceeded 100 Gb/s, long before 40GbE was available and 40 Gb/s exceeded 100 Gb/s, long before 40GbE was available and 40 Gb/s
transport in widespread use. transport in widespread use.
It is less clear when IP/MPLS LSP exceeded 10 Gb/s, 40 Gb/s, and 100 It is less clear when IP/MPLS LSP exceeded 10 Gb/s, 40 Gb/s, and 100
Gb/s. By 2010, many service providers have LSP in excess of 100 Gb/s. By 2010, many service providers have LSP in excess of 100 Gb/
Gb/s, but few are willing to disclose how many LSP have reached this s, but few are willing to disclose how many LSP have reached this
capacity. capacity.
By 2012 40GbE and 100GbE LSR products had become available, but were By 2012 40GbE and 100GbE LSR products had become available, but were
mostly still being evaluated or in trial use by service providers and mostly still being evaluated or in trial use by service providers and
contect providers. The cost of components required to deliver 100GbE contect providers. The cost of components required to deliver 100GbE
products remained high making these products less cost effective. products remained high making these products less cost effective.
This is expected to change within years. This is expected to change within years.
The important point is that IP/MPLS core network links have long ago The important point is that IP/MPLS core network links have long ago
exceeded 100 Gb/s and some may have already exceeded a Tb/s and a exceeded 100 Gb/s and some may have already exceeded a Tb/s and a
skipping to change at page 24, line 30 skipping to change at page 23, line 40
to do so. Therefore multipath techniques are likely here to stay. to do so. Therefore multipath techniques are likely here to stay.
Authors' Addresses Authors' Addresses
So Ning So Ning
Tata Communications Tata Communications
Email: ning.so@tatacommunications.com Email: ning.so@tatacommunications.com
Andrew Malis Andrew Malis
Verizon Consultant
60 Sylvan Road
Waltham, MA 02451
USA
Phone: +1 781-466-2362
Email: andrew.g.malis@verizon.com
Email: agmalis@gmail.com
Dave McDysan Dave McDysan
Verizon Verizon
22001 Loudoun County PKWY 22001 Loudoun County PKWY
Ashburn, VA 20147 Ashburn, VA 20147
USA USA
Email: dave.mcdysan@verizon.com Email: dave.mcdysan@verizon.com
Lucy Yong Lucy Yong
Huawei USA Huawei USA
5340 Legacy Dr. 5340 Legacy Dr.
Plano, TX 75025 Plano, TX 75025
USA USA
Phone: +1 469-277-5837 Phone: +1 469-277-5837
Email: lucy.yong@huawei.com Email: lucy.yong@huawei.com
Curtis Villamizar Curtis Villamizar
 End of changes. 45 change blocks. 
134 lines changed or deleted 136 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/