Routing Working Group N. So
Internet Draft A. Malis
Intended Status: Standard D. McDysan
Expires: Verizon
L. Yong
Huawei
F. Jounay
France Telecom
Y. Kamite
NTT
February 17, 2010
Requirements for MPLS Over a Composite Link
draft-ietf-rtgwg-cl-requirement-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
So, et al, Expires August 18, 2010 [Page 1]
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
1. Introduction...................................................3
2. Conventions used in this document..............................4
2.1. Acronyms..................................................4
2.2. Terminology...............................................4
3. Motivation and Summary Problem Statement.......................5
3.1. Motivation................................................5
3.2. Summary of Problems Requiring Solution....................7
4. Requirements...................................................7
4.1. Interior Functions........................................8
4.1.1. Functions common to all LSP flows....................8
4.1.1.1. Traffic Flow and Connection Mapping.............9
4.1.1.2. Management of Other Operational Aspects.........9
4.1.1.2.1. Resilience.................................9
4.1.1.2.2. Fault management requirement...............9
4.1.1.2.3. Flow/Connection Mapping Change Frequency..10
4.1.2. Functions specific to LSP flows with TE information.11
4.1.3. Functions specific to LSP flows without TE information12
4.1.4. Sets of LSP flows with and without TE information...12
4.1.4.1. Handling Bandwidth Shortage Events.............13
4.2. Exterior Functions.......................................13
4.2.1. Functions common to all LSP flows...................13
4.2.1.1. Signaling Protocol Extensions..................13
4.2.1.2. Routing Advertisement Extensions...............13
4.2.2. Functions specific to LSP flows with TE information.14
4.2.2.1. Signaling Protocol Extensions Requirements.....14
4.2.2.2. Routing Advertisement Extensions...............15
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
So, et al. Expires August 18, 2010 [Page 2]
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
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.
So, et al. Expires August 18, 2010 [Page 3]
A companion framework document [CLFRAMEWORK] further describes the
overall context, a structure, and some standardization considerations.
Specific protocol solutions are outside the scope of this document.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
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.
So, et al. Expires August 18, 2010 [Page 4]
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:
So, et al. Expires August 18, 2010 [Page 5]
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.
So, et al. Expires August 18, 2010 [Page 6]
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.
So, et al. Expires August 18, 2010 [Page 7]
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.
So, et al. Expires August 18, 2010 [Page 8]
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-
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
4.1.1.2.1. Resilience
The component link recovery scheme SHALL perform equal to or better
than existing local recovery methods. A short service disruption may
occur during the recovery period. Fast ReRoute (FRR) SHALL be
configurable for a composite link.
As part of FRR, a method to recover from composite link node failure
is desirable. OAM Messaging Support
4.1.1.2.2. Fault management requirement
There are two aspects of fault management in the solution. One is
about composite link between two local adjacent routers. The other
is about the individual component link.
So, et al. Expires August 18, 2010 [Page 9]
OAM protocols for fault management from the outside routers (e.g.,
LSP-Ping/Trace, IP-ping/Trace) SHALL be transparently treated.
For example, it is expected that LSP-ping/trace message is able to
diagnose composite link status and its associated virtual interface
information; however, it is not required to directly treat individual
component link and CL-connection because they are local matter of two
routers.
The solution SHALL support fault notification mechanism (e.g.,
syslog, SNMP trap to the management system/operators) with the
granularity level of affected part as detailed below:
o Data-plane of component link level
o Data-plane of composite link level (as a whole, and as a sum of
associated component links)
o Control-plane of the virtual interface level (i.e.,
routing/signaling on it)
o A composite link that believes that the underlying component link
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
so that lower layer methods have time to detect/restore faults before
a composite link function would be invoked.
The solution SHALL allow operator or control plane to query the
component link to which an LSP is assigned.
4.1.1.2.3. Flow/Connection Mapping Change Frequency
The solution requires methods to dampen the frequency of flow to
connection mapping change, connection bandwidth change, and/or
connection to component link mapping changes (e.g., for re-
optimization). Operator imposed control policy regarding the
frequency of change for sets of flows SHALL be supported.
The solution SHALL support latency and delay variation sensitive
traffic and limit the mapping change for these flows, and place them
on component links that have lower latency.
The determination of latency sensitive traffic SHALL be determined by
any of the following methods:
o Use of a pre-defined local policy setting at composite link
ingress that can be mapped to a flow
So, et al. Expires August 18, 2010 [Page 10]
o A manually configured setting at composite link ingress that can
be mapped to a flow
The determination of latency sensitive traffic SHOULD be determined
(if possible) by any of the following methods:
o Pre-set bits in the Payload (e.g., DSCP bits for IP or Ethernet
user priority for Ethernet payload) which are typically assigned
by end-user
o MPLS Traffic-Class Field (aka EXP) which is typically mapped by
the LER/LSR on the basis that its value is given for
differentiating latency-sensitive traffic of end-users
4.1.2. Functions specific to LSP flows with TE information
The following requirements apply to the case of RSVP-TE signaled LSPs
where the virtual interface is configured with IGP TE extensions.
The solution SHALL allow configuration of virtual interface
parameters for TE extensions link (e.g., available bandwidth, maximum
bandwidth, maximum allowable LSP bandwidth, TE metric, and resource
classes (i.e., administrative groups) or link colors).
The solution SHALL support configuration of a composite link composed
of set of component links , with each component link potentially
having at least the following characteristics which may differ:
o Bandwidth
o Latency
o QoS characteristics (e.g., jitter, error rate)
The solution SHALL support the admission control by RSVP-TE that is
signaled from the routers outside the composite link. Note that RSVP-
TE signaling need not specify the actual component link to be used?
because the selection of component link is the local matter of two
adjacent routers based upon signaled and locally configured
information.
The solution shall be able to receive, interpret and act upon at
least the following RSVP-TE signaled parameters: bandwidth setup
priority, and holding priority [RFC 3209, RFC 2215] preemption
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
parameters on a per composite link basis:
o Local Bandwidth Oversubscription factor
So, et al. Expires August 18, 2010 [Page 11]
The determination of latency sensitive traffic SHALL be determined by
any of the following methods:
o MPLS traffic class in a RSVP-TE signaling message (i.e., Diffserv-
TE traffic class [RFC 4124])
4.1.3. Functions specific to LSP flows without TE information
The following requirements apply to the case of LDP signaled LSPs
when no signaled TE information is available.
The solution shall map LDP-assigned labeled packets based upon local
configuration (e.g., label stack depth) to define a connection that
is mapped to one of the component link.
The solution SHALL map LDP-assigned labeled packets that identify the
outer label's FEC.
The solution SHALL support entropy labels [Entropy Label] to map more
granular flows to connections.
The solution SHALL be able to measure the bandwidth actually used by
a particular connection and derive proper local traffic TE
information for the connection.
When the connection bandwidth exceeds the component link capacity,
the solution SHALL be able to reassign the traffic flows to several
connections.
The solution SHALL support management plane controlled parameters
that define at least a minimum bandwidth, maximum bandwidth,
preemption priority, and holding priority for each connection without
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
The solution shall support separation of resources for traffic flows
mapped to connections that have access to TE information (e.g., RSVP-
TE signaled flows) from those that do not have access to TE
information (e.g., LDP-signaled flows or RSVP-TE LSP with Zero
bandwidth).
Component links in a composite link may fail independently. The
failure of a component link may impact some connections. The
impacted connections shall be transferred to other active component
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.
So, et al. Expires August 18, 2010 [Page 12]
4.1.4.1. Handling Bandwidth Shortage Events
The following requirements apply to a virtual interface that supports
traffic flows both with and without TE information, in response to a
bandwidth shortage event. A "bandwidth shortage" can arise in a
composite link if the total bandwidth of the connections with
provisioned/signaled TE information and those signaled without TE
information (but with measured bandwidth) exceeds the bandwidth of
the composite link that carries connections.
The solution shall support a policy-based preemption capability such
that, in the event of such a "bandwidth shortage", the signaled or
configured preemption and holding parameters can be applied to the
following treatments to the connections:
o For a connection that has RSVP-TE LSPs, signal the router that the
LSP has been preempted. The solution shall support soft
preemption (i.e., notify the preempted LSP source prior to
preemption). [Soft Preemption]
o For a connection that has LDP(s), where the routers connected via
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-
releasable LDP labels, signal the router or operator that the LSP
or LDP label has been lost.
4.2. Exterior Functions
4.2.1. Functions common to all LSP flows
The solution MUST be able to interoperate with exiting IETF MPLS
[RFC3031] control and data planes where appropriate.
4.2.1.1. Signaling Protocol Extensions
The solution SHALL support signaling a composite link between two
routers (e.g., P, P/PE, or PE).
The solution SHALL support signaling a component link as part of a
composite link.
The solution SHALL support signaling a composite link and
automatically injecting it into the IGP [LSP Hieararchy bis] or
connected two routers.
4.2.1.2. Routing Advertisement Extensions
The solution SHALL support IGP extensions to identify that the
advertised routing adjacency as a composite link.
So, et al. Expires August 18, 2010 [Page 13]
4.2.1.3. Multi-Layer Networking Aspects
The solution MUST be able to interoperate with existing IETF
GMPLS/MPLS-TP control and data planes where appropriate, for example,
when signaling a component link.
The solution SHALL support derivation of the advertised interface
parameters from signaled component link parameters from a lower layer
(e.g., latency, capacity) based on operator policy.
The solution SHALL be able to accept the GMPLS/MPLS-TP control plane
signaled component link. It SHALL be able to support the following
component link parameters
o Maximum (estimated or measured) acceptable latency
o Actual(estimated or measured) assigned latency
o Bandwidth
o Delay Variation
It SHOULD support the following component link parameter
o Loss rate
4.2.2. Functions specific to LSP flows with TE information
4.2.2.1. Signaling Protocol Extensions Requirements
The solution SHALL support per LSP signaling of at least the
following additional parameters for an LSP
o Maximum (estimated or measured) acceptable latency
o Actual (estimated or measured) accumulated latency based upon the
actual component link assigned by the composite link
o Bandwidth of the highest and lowest speed
The solution SHOULD support per LSP signaling of at least the
following additional parameters:
o Delay Variation
o Loss rate
As part of determining the path of an LSP, the client may query a
Patch Computation Element (PCE) and use the response in determining
the (complete or partial) source route sent in the TE signaling
message.
So, et al. Expires August 18, 2010 [Page 14]
Note that an LSP can be a component link or a client LSP. Since
component links may involve GMPLS, separate signaling protocol
extensions may be needed for particular switching capabilities.
4.2.2.2. Routing Advertisement Extensions
It SHALL be possible for the solution to represent multiple values,
or a range of values, for the composite link interface parameters in
order to communicate information about differences in the constituent
component links in an exterior function route advertisement
Some of these capabilities are specified for link bundling [RFC
4201], but some extensions may be needed. Techniques such as those
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
characteristics for the component links that comprise the composite
links could be advertised. When a range of characteristics is
advertised, these can be used in a constrained path computation, that
is, certain composite links can be excluded since no component link
meets the characteristic as part of the overall path.
4.2.3. Functions specific to LSP flows without TE information
A straightforward set of requirement would result if the same
functions specified for RSVP-TE were also specified for LDP. However,
the IETF MPLS Working Group's decision on MPLS signaling protocols
[RFC 3468] to not pursue such an approach by not adding functions to
CR-LDP means that a different approach must be taken.
As described in the Interior Function section, 4.1.3, a basic
composite link capability when there is no TE information is to be
able to measure the amount of LDP signaled traffic that is sent on an
LSP. It is highly desirable to be able to signal and advertise
certain aspects of these measurements, if they cannot be explicitly
signaled via extensions to LDP.
4.2.3.1. Signaling Protocol Extensions
The solution SHOULD allow addition of an object to an LDP label
mapping message that indicates how much measured capacity can be sent
to a pair of nodes connected via a composite link. This signaling
should be conveyed at least to nodes which are adjacent to the pair
of nodes connected via a composite link.
Nodes SHOULD be able to use this information in conjunction with the
IGP link information to decide which label mappings it will use for
forwarding LDP signaled flows toward a pair of nodes connected via a
composite link.
So, et al. Expires August 18, 2010 [Page 15]
4.2.3.2. Routing Advertisement Extensions
Signaling via LDP the available capacity on a composite link for
flows without TE information is one method. A preferable method would
be to extend the IGP to indicate the amount of capacity allocated by
an Interior function to flows without TE information so that nodes in
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
As described in the Interior Function section, 4.1.4, the principal
driver in this case is how to handle bandwidth shortage events when
both RSVP-TE and LDP signaled LSPs are present in the composite link.
The requirements relevant to the nodes connected by the composite
link are described in section 4.1.4, and this section describes
additional desirable functions beyond these nodes. Since RSVP-TE
signaling defines parameters and procedures for preemption, the focus
is on extensions to better support LDP signaled LSPs.
4.2.4.1. Signaling Protocol Extensions
The solution SHOULD allow addition of an object to an LDP label
mapping message that indicates that a node controlling the composite
link wants to preempt the traffic offered by an LSP. This should have
the effect of pruning label distribution for the LSP at the node pair
connected via a composite link.
4.2.4.2. Routing Advertisement Extensions
The solution SHOULD allow addition of an object to the IGP that
indicates that all LDP signaled traffic should avoid the advertised
composite link.
5. Security Considerations
The solution is a local function on the router to support traffic
engineering management over multiple parallel links. It does not
introduce a security risk for control plane and data plane.
The solution could change the frequency of routing update messages
and therefore could change routing convergence time. The solution
MUST provide controls to dampen the frequency of such changes so as
to not destabilize routing protocols.
6. IANA Considerations
IANA actions to provide solutions are for further study.
So, et al. Expires August 18, 2010 [Page 16]
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2215] S. Shenker, J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements."
September 1997
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," December
2001
[RFC4206] Label Switched Paths (LSP) Hierarchy with Generalized
Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE) K.
Kompella, Y. Rekhter October 2005
[RFC4090] Pan, P., "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", RFC 4090, May 2005.
[RFC4124] Protocol Extensions for Support of Diffserv-aware MPLS
Traffic Engineering F. Le Faucheur, Ed. June 2005
[RFC4201] Kompella, K., "Link Bundle in MPLS Traffic Engineering",
RFC 4201, March 2005.
7.2. Informative References
[Entropy Label] Kompella, K. and S. Amante, "The Use of Entropy
Labels in MPLS Forwarding", November 2008, Work in Progress
[LSP Hierarchy] Shiomoto, K. and A. Farrel, "Procedures for
Dynamically Signaled Hierarchical Label Switched
Paths", November 2008, Work in Progress
[Soft Preemption] Meyer, M. and J. Vasseur, "MPLS Traffic Engineering
Soft Preemption", February 2009, Work in Progress
[CLFRAMEWORK] Yong, L. Ed, "Framework for MPLS Over Composite Link,"
work in progress.
[RFC3468] L. Andersson, G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS signaling
protocols."
[PWBONDING] Stein, Y, "PW Bonding", Dec. 2008
So, et al. Expires August 18, 2010 [Page 17]
[RFC3630] Katz, D., "Traffic Engineering (TE) Extension to OSPF
Version 2", RFC 3630, September 2003.
[RFC 2676] G. Apostolopoulos, S. Kama, D. Williams, R. Guerin, A.
Orda, T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions,"
August, 1999
[ITU-T G.800] ITU-T, "Unified functional architecture of transport
networks," September, 2007.
8. Acknowledgments
Authors would like to thank Adrian Farrel from Olddog for his
extensive comments and suggestions, Ron Bonica from Juniper, Nabil
Bitar from Verizon, Eric Gray from Ericsson, Lou Berger from LabN,
and Kireeti Kompella from Juniper, for their reviews and great
suggestions.
This document was prepared using 2-Word-v2.0.template.dot.
Copyright (c) 2010 IETF Trust and the persons identified as authors
of the code. All rights reserved.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
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
reproduce this note if possible.
So, et al. Expires August 18, 2010 [Page 18]
Authors' Addresses
So Ning
Verizon
2400 N. Glem Ave.,
Richerdson, TX 75082
Phone: +1 972-729-7905
Email: ning.so@verizonbusiness.com
Andrew Malis
Verizon
117 West St.
Waltham, MA 02451
Phone: +1 781-466-2362
Email: andrew.g.malis@verizon.com
Dave McDysan
Verizon
22001 Loudoun County PKWY
Ashburn, VA 20147
Email: dave.mcdysan@verizon.com
Lucy Yong
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 469-229-5387
Email: lucyyong@huawei.com
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex,
FRANCE
Email: frederic.jounay@orange-ftgroup.com
Yuji Kamite
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Email: y.kamite@ntt.com
So, et al. Expires August 18, 2010 [Page 19]
