Both of your questions are related to the motivation of the draft. From
carrier/operator's point of view, we have thought long and hard about
this, and we have detailed our motivations in the previous drafts,
although not in this one because we thought they were well understood
since we have presented it numerous times in several WGs and meetings.
I have copied and pasted what we had in the last draft below. I think
it addressed your questions in detail.
Appendix A. Problem Statements
Two applications are described here that encounter problems when
multiple parallel links are deployed between two routers in today's
A.1. Incomplete/Inefficient Utilization
An MPLS-TE network is deployed to carry traffic on RSVP-TE LSPs, i.e.
traffic engineered flows. When traffic volume exceeds the capacity
of a single physical link, multiple physical links are deployed
between two routers as a single backbone trunk. How to assign LSP
traffic over multiple links and maintain this backbone trunk as a
higher capacity and higher availability trunk than a single physical
link becomes an extremely difficult task for carriers today. Three
methods that are available today are described here.
1. A hashing method is a common practice for traffic distribution
over multiple paths. Equal Cost Multi-Path (ECMP) for IP
services and IEEE-defined Link Aggregation Group (LAG) for
Ethernet traffic are two of the widely deployed hashing based
technologies. However, two common occurrences in carrier
networks often prevent hashing being used efficiently. First,
for MPLS networks carrying mostly Virtual Private Network (VPN)
traffic, the incoming traffic are usually highly encrypted, so
that hashing depth is severely limited. Second, the traffic in
an MPLS-TE network typically contain a certain number of traffic
flows that have vast differences in the bandwidth requirements.
Furthermore, the links may be of different speeds. In those
cases hashing can cause some links to be congested while others
are partially filled because hashing can only distinguish the
flows but not the flow rates. A TE based solution better applies
for these cases. IETF has always had two technology tracks for
traffic distribution: TE-based and non-TE based. A TE based
solution provides a natural compliment to non-TE based hashing
2. Assigning individual LSPs to each link through constrained
routing. A planning tool can track the utilization of each link
and assignment of LSPs to the links. The lag time between
measurement and action may be large relative to the fluctuations
in LSP utilization, and the availability and performance of the
planning tool are also important operational factors.
Furthermore, the flexibility in response to failure scenarios is
limited as summarized in the following. To gain high
availability, FRR [RFC4090] is used to create a bypass tunnel on
a link to protect traffic on another link or to create a detour
LSP to protect another LSP. If BW is reserved for the bypass
tunnels or the detour LSPs, the network will need to reserve a
large amount of capacity for failure recovery, which reduces the
capacity to carry other traffic. If BW is not reserved for the
bypass tunnels and the detour LSPs, the planning tool can not
assign LSPs properly to avoid the congestion during link failure
when there are more than two parallel links. This is because
during the link failure, the impacted traffic is simply put on a
bypass tunnel or detour LSPs which does not have enough reserved
bandwidth to carry the extra traffic during the failure recovery
phase. An alternative is to use prioritized queuing so that
premium traffic sees good performance during a congestion
interval. The LSP sources will receive an RSVP-TE path error and
reoptimize the new LSP . After a configurable period of time the
LSPs will reoptimize and all traffic will experience good
performance. However, it will not work well when support is
needed for both RSVP-TE signaled and LDP signaled traffic.
3. Facility protection, also called 1:1 protection. Dedicate one
link to protect another link. Only assign traffic to one link in
the normal condition. When the working link fails, switch
traffic over the protection link. This requires 50% capacity for
failure recovery. This works when there are only two links.
Under the multiple parallel link condition, this causes
inefficient use of network capacity because there is no
protection capacity sharing. In addition, due to traffic
burstiness, having one link fully loaded and another link idle
increases transport latency and packet loss, which lowers the
link performance quality for transport.
None of these methods satisfies carrier requirement either because of
poor link utilization or poor performance. This forces carriers to
go with the solution of deploying single higher capacity link.
However, a higher capacity link can be expensive as compared with
parallel low capacity links of equivalent aggregate capacity; a high
capacity link can not be deployed in some circumstances due to
physical impairments; or the highest capacity link may not large
enough for some carriers.
An LDP network can encounter the same issue as an MPLS-TE enabled
network when multiple parallel links are deployed as a backbone
trunk. An LDP network can have large variance in flow rates where,
for example, the small flows may be carrying stock tickers at a few
kbps per flow while the large flows can be near 10 Gbps per flow
carrying machine to machine and server to server traffic from
individual customers. Those large traffic flows often cannot be
broken into micro flows. Therefore, hashing would not work well for
the networks carrying such flows. Without per-flow TE information,
this type of network has even more difficulty to use multiple
parallel links and keep high link utilization.
A.2. Inefficiency/Inflexibility of Logical Interface Bandwidth
Using logically-separate routing instances in some implementations
further complicates the situation. Dedicating separate physical
backbone links, or, in the case of sharing of a single common link,
dedicating a portion of the link, to each routing instance is not
efficient. Assume that each routing instance must have at least the
capacity of a single link, and also must have equal access to unused
capacity. Then, for example, if there are 2 routing instances and 3
parallel links and half of each link bandwidth is assigned to a
routing instance, neither routing instance can support an LSP with
bandwidth greater than half the link bandwidth. The same problem is
also present in the case of the sharing of a single common link using
the dedicated logical interface and link bandwidth method. An
alternative in dealing with multiple parallel links is to assign a
logical interface and bandwidth on each of the parallel physical
links to each routing instance, which improves efficiency as compared
to dedicating physical links to each routing instance.
Note that the traffic flows and LSPs from these different routing
instances effectively operate in a Ships-in-the-Night mode, where
they are unaware of each other. Inflexibility results if there are
multiple sets of LSPs (e.g., from different routing instances)
sharing one link or a set of parallel links, and at least one set of
LSPs can preempt others, in this case more efficient sharing of the
link set between the routing instances is highly desirable.
A.3. Additional Functions Required Beyond Link Bundling
A link bundle [RFC4201] is a collection of TE links. It is a logical
construct that represents a way to group/map the information about
certain physical resources that interconnect routers. The purpose of
link bundle is to improve routing scalability by reducing the amount
of information that has to be handled by OSPF/IS-IS. Each physical
link in the link bundle is an IGP link in OSPF/IS-IS if numbered link
is used. A link bundle only has the significance at the router
control plane. The mapping of LSP to component link in a bundle is
determined at LSP setup time and this mapping does not change due to
newly configured LSP/LDP traffic on the same component link. A link
bundle only applies to RSVP-TE signaled traffic, which implies no mix
of RSVP-TE and LDP traffic on a same interface. CTG can handle
RSVP-TE and LDP signaled traffic.
Link bundling does not support groups of links with different
characteristics (e.g., bandwidth, latency). Furthermore, link
bundling only supports RSVP-TE signaled LSPs and not LDP signaled
Enterprise Data Network and Traffic Planning
From: [email protected] [mailto:[email protected]] On Behalf
Of PAPADIMITRIOU Dimitri
Sent: Sunday, December 06, 2009 4:11 AM
To: John G. Scudder; [email protected]
Cc: [email protected]; ZININ Alex
Subject: RE: Composite Link Requirements as WG document
Two comments on this document:
"Unlike a link bundle [RFC4201], the component links in a
composite link can have different properties such as cost
Component link "capacity" heterogeneity is "allowed" in 4201 I can
understand the potential limitation of identical TE metrics (for each
component) unfortunately limited explanation are given to sustain why it
should be addressed.
"This document describes a framework for managing aggregated
traffic over a composite link."
"To achieve the better component link utilization and avoid
component link congestion, the document describes some new
aspects on the traffic flow assignment to component links."
The document is specifically dealing to TE control but does not explain
why "measuring" component link capacity is assumed impossible (cf. 4201
Section 4) ?
Bottom-line: not clear if this document is intended to improve
applicability of bundling TE control in IP/MPLS or if the current
bundling approach is not fulfilling expected functionality (and this
document would outline the why/what). The issue is that the document
describes "modeling" but does not provide an answer to this question.
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of John G. Scudder
> Sent: Tuesday, November 10, 2009 10:08 AM
> To: [email protected]
> Cc: [email protected]; ZININ Alex
> Subject: Composite Link Requirements as WG document
> At today's meeting we received a request to adopt draft-so-yong-mpls-
> ctg-requirement-00 as a working group document. There was
> strong support in the room for doing so. Please respond to the
> mailing list with your discussion, support or opposition (please do
> this even if you did so in person). The deadline for comments is
> November 30.
> Note that accepting the document simply means that the working group
> would begin working on requirements. It does not imply blanket
> acceptance of the document as it now stands.
> rtgwg mailing list
> [email protected]
rtgwg mailing list
rtgwg mailing list