Routing Working Group N. So
Internet Draft A. Malis
Intended Status: Informational D. McDysan
Expires: Verizon
L. Yong
Huawei
F. Jounay
France Telecom
Y. Kamite
NTT
October 16, 2009
Framework for MPLS Over Composite Link
draft-so-yong-mpls-ctg-framework-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
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 December 17, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
So, et al, Expires April 16, 2010 [Page 1]
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes a framework for managing aggregated traffic
over a composite link. A composite link consists of a group of non-
homogenous links that have the same forward adjacency and can be
considered as a single TE link or an IP link used for MPLS. The
document primarily focuses on MPLS data plane and control plane
traffic over a composite link and composite link advertisement within
IGP. MPLS traffic can be set up by either RSVP-TE or LDP signaling.
Applicability is described for a single pair of MPLS-capable nodes, a
sequence of MPLS-capable nodes, or a set of layer networks connecting
MPLS-capable nodes.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................3
2.1. Acronyms..................................................3
2.2. Terminology...............................................4
3. Composite Link Framework.......................................4
3.1. Composite Link Architecture...............................4
3.2. Interior Functions........................................6
3.2.1. Functions specific to LSP flows with TE information..7
3.2.2. Functions specific to LSP flows without TE information7
3.2.3. Functions for LSP flows with and without TE information
............................................................7
3.3. Exterior Functions........................................8
3.3.1. Composite Link Advertisement and Component Link Setup8
3.3.2. Functions specific to LSP flows with TE information..8
3.3.3. Functions specific to LSP flows without TE information8
3.3.4. Functions to LSP flows with and without TE information9
4. Applicability..................................................9
4.1. Single-Layer Scenarios....................................9
4.2. Multi-Layer Scenario.....................................10
5. Security Considerations.......................................10
6. IANA Considerations...........................................11
7. References....................................................11
7.1. Normative References.....................................11
7.2. Informative References...................................11
8. Acknowledgments...............................................11
1. Introduction
This document describes a framework of Composite Link in IP/MPLS
network. Single link and link bundle [RFC4201] have been widely used
So, et al. Expires April 16, 2010 [Page 2]
in today's IP/MPLS networks. A link bundle bundles a group of
homogeneous links as a TE link to make routing approach more
scalable. A composite link allows bundling non-homogenous links
together as a single logical link. The motivations for using a
composite link are descried in the document [CL Requirement]. This
document states composite link framework in the context of MPLS
network with MPLS control plane.
A composite link is a single logical link that contains multiple
parallel component links between two routers. Unlike a link bundle
[RFC4201], the component links in a composite link can have different
properties such as cost or capacity. A composite link can transport
aggregated traffic as other physical links from the network
perspective and use its component links to carry the traffic
internally. 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 also describes the advertisement of a composite link as a
routing interface in MPLS control plane and the addition of component
links to a composite link.
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
CTG: Composite Transport Group
ECMP: Equal Cost Multi-Path
FRR: Fast Re-Route
LAG: Link Aggregation Group
LDP: Label Distribution Protocol
LSA: Link State Advertisements
LSP: Label Switched Path
MPLS: Multi-Protocol Label Switching
OAM: Operation, Administration, and Management
So, et al. Expires April 16, 2010 [Page 3]
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.
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 Composite Link Interior Functions 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
configure a component link within 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
component link on which a traffic flow is placed. This is local
implementation.
Traffic Flow: A set of packets with a common identifier and
characteristics that is used by Composite link interior functions to
place the set of packets on the same component link. 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 is advertised as a interface in IGP
3. Composite Link Framework
3.1. Composite Link Architecture
Composite Link Characteristics is defined at a high level in ITU-T
[ITU-T G.800] that makes multiple parallel component links between
So, et al. Expires April 16, 2010 [Page 4]
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. Composite link framework is illustrated in
Figure 1, where a composite link is configured between routers R1 and
R2. The composite link has three component links. Individual
component links in a composite link may be supported by different
transport technologies such as wavelength, Ethernet VLAN, or can be a
logical link configured on a LSP [LSP Hierarchy]. Even if the
transport technology implementing the component links is identical,
the characteristics (e.g., bandwidth, latency) of the component links
may differ.
Composite Link can apply to MPLS network. As shown in Figure 1, the
composite link may carry LSP traffic flows and control plane packets.
A LSP may be established over the link by either RSVP-TE or LDP
signaling protocols. All component links in a composite link have the
same forwarding adjacency. The composite link forms one routing
interface between two connected routers for MPLS control plane. In
other words, two routers connected via a composite link have
forwarding adjacency and routing adjacency. Each component link only
has significance to the composite link, i.e. it does not appear as a
link in the control plane.
Composite link relies on its component links to carry the traffic. An
important framework concept is the connection shown in Figure 1. The
connection only exists within the composite link and is controlled by
the composite link function. At the transmitting end (R1 in Figure
1), composite link maps a set of traffic flows including control
plane packets into one connection and routes the connection on a
specific component link. This method enables connection based routing
over component links and traffic volume measurement on a per
connection basis. As a result, it guarantees the ordering per traffic
flow. One component link may carry one or more connections. At the
receiving end (R2 in Figure 1), composite link receives traffic flows
from its component links and sends them to MPLS forwarding engine
like a regular link. Note that a special case of this model is where
a single flow is mapped to a single connection.
So, et al. Expires April 16, 2010 [Page 5]
Management Plane
Configuration and Measurement <------------+
^ |
| |
| |
| |
+-------+-+ +-+-------+
| | | | | |
CP Packets V | | V CP Packets
| V +-+-+ Component Link 1 +-+-+ ^ |
| | | |===========================| | | |
| +--|-|*|****** connections ********|*|-|--+ |
~~|~~>~~|~| |===========================| |~|~~>~~|~~
LSP ~~|~~>~~|~| | Component Link 2 | |~|~~>~~|~~ LSP
Traffic~|~~>~~|~| |===========================| |~|~~>~~|~~ Traffic
Flows ~~|~~>~~|~|*|****** connections ********|*|~|~~>~~|~~ Flows
~~|~~>~~|~| |===========================| |~|~~>~~|~~
~~|~~>~~|~| | Component Link 3 | |~|~~>~~|~~
~~|~~>~~|~| |===========================| |~|~~>~~|~~
| | |*|****** connections ********|*| | |
| | | |===========================| | |
| +---+ +---+ |
+---------+ +---------+
! ! ! !
! !<---- Component Links ---->! !
!<------- Composite Link ---------->!
Figure 1: Composite Link Architecture Model
3.2. Interior Functions
The interior functions are implemented within the interior of MPLS
routers connected via a composite link. This includes local
determination of the component link on which a traffic flow is
placed, i.e. the flow to the interface mapping. Although this
assignment is local, management configuration for some aspects of
these interior functions is important to achieve operational
consistency.
As described in section 3.1, the Interior Functions map traffic flows
to a connection and route connections to component links based on
traffic flow parameters, connection parameters, and component link
parameters. The connection parameters may be calculated from the
parameters of the flows mapped to the connection or may derive from
the measurement of the traffic volume on the connection plus
configured connection parameters via the management plane.
So, et al. Expires April 16, 2010 [Page 6]
A component link in a composite link may fail independently. The
interior functions are able to detect component link failure and re-
assign impacted flows to other active component links. When a
composite link can't recover some impacted flows, it notifies control
plane about the flows. When a composite link is not able to transport
all flows, it preempts some flows based upon local management
configuration and informs the control plane on these preempted flows.
This action ensures the remaining traffic is transported properly.
The interior functions provide component link fault notification and
composite link fault notification upon the failure of a component
link or a composite link. Component link fault notification is sent
to the management plane. Composite link fault notification is sent to
the control plane and management plane. Composite link allows
operator to trace which component link a LSP is assigned to.
3.2.1. Functions specific to LSP flows with TE information
When a composite link is deployed in a MPLS-TE network, LSPs are
signaled by RSVP-TE protocol. The protocol message contains LSP
parameters like BW, setting/holding priority, latency, etc. The
composite link will take these parameters into account when assigning
LSP to a connection and a connection to a component link.
3.2.2. Functions specific to LSP flows without TE information
When a composite link is deployed in a non-TE MPLS network, LSPs are
signaled by LDP. LDP message does not provide LSP TE information.
These LSPs can be mapped to local configured connections with minimum
bandwidth, maximum bandwidth, preemption priority, and holding
priority parameters. The interior function measures the traffic
volume on the connection and derives the BW parameter for the
connection. The interior functions use these parameters to assign the
connection to a component link.
When the connection bandwidth exceeds the component link capacity,
the interior functions are able to reassign the traffic flows to
other connections that are over different component links.
3.2.3. Functions for LSP flows with and without TE information
When a composite link carries LSPs that are signaled by LDP or RSVP-
TE, the interior functions separates them into different connections
that have independent parameters. If there is a shortage of capacity
in a composite link, interior functions perform preemption, rerouting
or termination of flows based on the traffic flow priority.
So, et al. Expires April 16, 2010 [Page 7]
3.3. Exterior Functions
The Exterior Functions have the aspects that are applicable exterior
to the connected MPLS routers. These exterior functions apply to
routing and signaling protocols. Protocol solutions are for further
study.
3.3.1. Composite Link Advertisement and Component Link Setup
In IGP, a composite Link is advertised as a single virtual routable
interface between two connected routers, which forms routing and
forwarding adjacency between the connected routers. A composite link
must be advertised as a link in IGP.[RFC2328] The interface
parameters for the composite link can be pre-configured by operator
or be derived from its component links. Composite link latency may be
advertised for other routers to perform route computation.
A composite link may contain the set of component links. A component
link may be configured by operator or signaled by the control plane.
In both cases, it is necessary to convey component link parameters to
the composite link.
When a component link is supported by lower layer network as
described in section 4.2, the control plane that the composite link
resides is able to interoperate with the GMPLS or MPLS-TP control
plane that lower layer network uses for component link addition and
deletion.
Composite link advertisement and component link setup requirements
are specified in [CTG Requirement]
3.3.2. Functions specific to LSP flows with TE information
When RSVP-TE [RFC3209] signals a LSP over a composite link, the
composite link takes the signaled LSP parameters as the flow
parameters and sends the PATH message to the downstream router of the
composite link. The downstream router selects the LSP label that is
used over the composite link and sends RESV message with the label
info. to the upstream LSR. The forward engine at the upstream LSR
will push the label into the LSP packets. Composite link interior
functions map the label to a connection that is assigned to a
component link.
When a composite link is advertised as a TE link in MPLS-TE network
[RFC3630], composite link capacity is advertised. It is possible to
advertise multiple capacities and latencies to reflect individual
component link property. [CTG requirement]
3.3.3. Functions specific to LSP flows without TE information
When LDP [RFC5036] is used to signal LSPs over a composite link, a
LDP session has to be established between two LSRs connected via a
So, et al. Expires April 16, 2010 [Page 8]
composite link. When signaling a LSP for a FEC over the composite
link, the upstream LSR sends label request message to the downstream
LSR, the downstream LSR selects a label for the FEC and sends the
label mapping message back to the upstream LSR.
3.3.4. Functions to LSP flows with and without TE information
When there is a shortage of capacity in a composite link which
supports LSP flows with and without TE information, interior
functions are able to perform preemption, rerouting or termination of
flows to ensure transport quality, the exterior functions are able to
inform LSR control plan preempted flows. Thus the control plan
informs the LSP head-end if it is singled by RSVP-TE or prunes label
distribution for the LSP that is singled by LDP.
4. Applicability
A composite link may be deployed between two Ps, P and PE, and two
PEs. Two routers connected via a composite link forms forwarding
adjacency and routing adjacency. It can be used in MPLS-TE only, MPLS
non-TE only, or combined environment.
In MPLS-TE application, the composite link is advertised as a link in
IGP and a TE link in IGP TE extension that uses either OSPF-TE or IS-
IS-TE. RSVP-TE signaling protocol is used to establish a LSP. TE
tunnel and private line are examples of applications.
In MPLS non-TE application, the composite link is advertised as a
link within the IGP that uses either OSPF or IS-IS as routing
protocol. In this case, LDP signaling protocol is used to establish a
LSP. L3VPN is the most popular application for this case.
In the hybrid application, the composite link is advertised as a link
and a TE link within IGP by using different types of LSA and both
RSVP-TE and LDP signaling for LSP establishment, as described in
section 3.
4.1. Single-Layer Scenarios
The component links of Figure 1 applies to at least the scenarios
illustrated in Figure 2. The component links may be physical or
logical, or supported by different technologies. In the first
scenario, a set of physical links connect adjacent (P) routers
(R1/R2).
In the second scenario, a set of logical links connect adjacent (P or
PE) routers over other equipment (i.e., R3/R4) that may implement
RSVP-TE signaled MPLS tunnels which may be in the same IGP as R1/R2.
In this case, R3/R4 provides a TE-LSP segment of TE-LSP from R1 and
R2. In another case, R3/R4 are in different IGP from R1/R2, R3 and R4
provide connectivity for R1 and R2. The connectivity provides a
So, et al. Expires April 16, 2010 [Page 9]
component link in the composite link of R1/R2. R3 and P4 may
implement MPLS-TP.
+----+---+ 1. Physical Link +---+----+
| | |----------------------------------------------| | |
| | | | | |
| | | +------+ +------+ | C | |
| | C | | MPLS | 2. Logical Link | MPLS | | | |
| | |.... |......|.....................|......|....| | |
| | |-----| R3 |---------------------| R4 |----| | |
| | T | +------+ +------+ | T | |
| | | | | |
| | | | | |
| | G | +------+ +------+ | G | |
| | | |GMPLS | 3. Lower Layer Link |GMPLS | | | |
| | |. ...|......|.....................|......|....| | |
| | |-----| R5 |---------------------| R6 |----| | |
| | | +------+ +------+ | | |
| R1 | | | | R2 |
+----+---+ +---+----+
|<---------- Composite Link ----------------->|
Figure 4: Illustration of Component Link Types
4.2. Multi-Layer Scenario
In the third scenario in Figure 2, GMPLS lower layer LSPs (e.g.,
Fiber, Wavelength, TDM) as determined by a lower layer network in a
multi-layer network deployment as illustrated by R5/R6. In this case,
R5 and R6 would usually not be part of the same IGP as R1/R2 and may
have a static interface, or may have a signaling but not a routing
association with R1 and R2. Note that in scenarios 2 and 3 when the
intermediate routers are not part of the same IGP as R1/R2 (i.e., can
be viewed as operating at a lower layer) that the characteristics of
these links (e.g., latency) may change dynamically, and there is an
operational desire to handle this type of situation in a more
automated fashion than is currently possible with existing protocols.
Note that this problem currently occurs with a single lower-layer
link in existing networks and it would be desirable for the solution
to handle the case of a single lower-layer component link as well.
Note that the interfaces at R1 and R2 are associated with these
different component links can be configured with IP addresses or use
unnumbered links as an interior, local function since the individual
component links are not advertised as the virtual interface.
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.
So, et al. Expires April 16, 2010 [Page 10]
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.
7. References
7.1. Normative References
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," December
2001
[RFC3630] Katz, D., "Traffic Engineering (TE) Extension to OSPF
Version 2", RFC 3630, September 2003.
[RFC4201] Kompella, K., "Link Bundle in MPLS Traffic Engineering",
RFC 4201, March 2005.
[RFC5036] Andersson, L., "LDP Specification", RFC 5036 , October
2007.
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
[CTG Requirement] So, N. and Yong, L, "Requirements for MPLS Over
Composite Link", Oct. 2009, Work in Progress
8. Acknowledgments
Authors would like to thank Adrian Farrel for his extensive comments
and suggestions, Ron Bonica, Nabil Bitar, Eric Gray, Lou Berger, and
Kireeti Kompella for their reviews and great suggestions.
So, et al. Expires April 16, 2010 [Page 11]
This document was prepared using 2-Word-v2.0.template.dot.
Copyright (c) 2009 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 April 16, 2010 [Page 12]
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 April 16, 2010 [Page 13]