CCAMP Working Group D. Brungard
Internet-Draft AT&T
Expires: April 25, 2005 J-L. Le Roux
FT
E. Oki
NTT
D. Papadimitriou
Alcatel
D. Shimazaki
K. Shiomoto
NTT
October 25, 2004
IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration
draft-oki-ccamp-gmpls-ip-interworking-04.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 April 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Brungard, et al. Expires April 25, 2005 [Page 1]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
This document addresses the migration from Multiprotocol Label
Switching (MPLS) to Generalized MPLS (GMPLS) networks. In order to
expand the capacity of existing MPLS-based controlled infrastructure,
networks consisting of L2SC, TDM, LSC, and FSC devices will be
deployed, and these will be controlled by the GMPLS protocols. GMPLS
protocols are, however, subtly different from MPLS protocols. This
document describes possible migration scenarios, the mechanisms to
compensate for the differences between MPLS and GMPLS protocols, and
how the mechanisms are applied to migrate from a MPLS to a GMPLS
network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Migration scenarios . . . . . . . . . . . . . . . . . . . . . 4
2.1 MPLS-GMPLS(non-PSC)-MPLS . . . . . . . . . . . . . . . . . 4
2.2 MPLS-GMPLS(PSC)-MPLS . . . . . . . . . . . . . . . . . . . 5
2.3 GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) . . . . . . . . . . . . 5
2.4 GMPLS(PSC)-MPLS-GMPLS(PSC) . . . . . . . . . . . . . . . . 6
2.5 GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) . . . . . . . . . . . 6
3. Difference between MPLS and GMPLS protocols . . . . . . . . . 7
3.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Control plane/data plane separation . . . . . . . . . . . 9
3.4 Bi-directional LSPs . . . . . . . . . . . . . . . . . . . 9
4. Required mechanisms . . . . . . . . . . . . . . . . . . . . . 9
4.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1 TE link . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.2 Forwarding adjacencies . . . . . . . . . . . . . . . . 10
4.1.3 Segment Stitching . . . . . . . . . . . . . . . . . . 13
4.2 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1 LSP nesting . . . . . . . . . . . . . . . . . . . . . 15
4.2.2 Contiguous LSPs . . . . . . . . . . . . . . . . . . . 16
4.2.3 LSP stitching . . . . . . . . . . . . . . . . . . . . 16
4.2.4 Discovery of GMPLS signalling capability . . . . . . . 17
5. Security considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1 Normative references . . . . . . . . . . . . . . . . . . . . 18
8.2 Informative references . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 22
Brungard, et al. Expires April 25, 2005 [Page 2]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
1. Introduction
Multi-protocol label switching (MPLS) is widely deployed with
applications such as traffic engineering and virtual private networks
(VPN). Various kinds of services such as VoIP, IPv6, L2VPN/L3VPN,
and pseudo wire emulation are expected to be converged over the
MPLS-based controlled infrastructure network.
Many service providers report that traffic volume is increasing
tremendously as broadband services enabled by ADSL and FTTH are
rapidly penetrating the market, and the processing performance of
terminal and server is ever increasing. In order to cope with such
an increase in the traffic volume, optical networks, which consist of
TDM, LSC, and FSC devices, are being introduced.
Generalized MPLS (GMPLS) is being standardized by extending MPLS to
control such optical networks (see [2], [3], [9], [10], [11], [12])
in addition to Layer-2 Switching Capable (L2SC) and Packet Switching
Capable (PSC) networks [6]). GMPLS networks will be deployed as a
part of the existing MPLS infractructure. MPLS and GMPLS devices
will coexist in the network until the existing MPLS network is
completely migrated to the GMPLS network.
GMPLS protocols are, however, subtly extending the capablities of the
MPLS protocols. In order to migrate from the existing MPLS to the
GMPLS network, we need to define mechanisms to compensate the
difference between MPLS and GMPLS. In this document we discuss the
migration scenarios from MPLS to GMPLS networks, the mechanisms to
compensate for the differences between MPLS and GMPLS, and the
applicability of the mechanisms to the possible migration scenarios.
Note that GMPLS covers Packet Switching Capable (PSC) networks [6].
In the rest of this document, the term GMPLS includes both PSC and
non-PSC. Otherwise the term "PSC GMPLS" or "non-PSC GMPLS" is
explicitly used.
GMPLS introduces new features such as bi-directional LSPs, label
suggestion, label restriction, graceful restart, graceful teardown,
and forwarding adjacencies (see [6] ). Also, GMPLS provides several
features in a distinct manner from MPLS. For instance local
protection is provided using distinct mechanisms in MPLS (see [17]) )
and GMPLS (see [18] ). Migration from MPLS to GMPLS should bring
these features and such distinct mechanisms into the existing
MPLS-based controlled infrastructure network.
The rest of this document is organized as follows. Section 2
outlines the migration scenarios from MPLS to GMPLS networks.
Section 3 describes the problems caused by the differences between
Brungard, et al. Expires April 25, 2005 [Page 3]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
MPLS and GMPLS protocols. Section 4 presents the required mechanisms
which bridge the differences between MPLS and GMPLS protocols. Some
of those mechanisms are available today and others are not.
2. Migration scenarios
Three categories of migration scenarios are considered: (1)
MPLS-GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS and (3) MPLS-GMPLS. In the
case of the MPLS-GMPLS-MPLS scenario, source and destination nodes of
the Label Switched Path (LSP) are in MPLS networks, and a set of the
LSP's transit nodes are in a GMPLS network. In the case of the
GMPLS-MPLS-GMPLS scenario, the LSP source and destination nodes are
in a GMPLS network, and a set of the LSP's transit nodes are in an
MPLS network. Each category is subdivided in two sub-categories as
to whether GMPLS is PSC or non-PSC except the category (3). Finally
in the case of the MPLS-GMPLS migration scenario, LSP starts/ends in
an MPLS network and ends/starts in a GMPLS PSC network.
2.1 MPLS-GMPLS(non-PSC)-MPLS
The introduction of a GMPLS-based controlled optical core network to
increase the capacity is an example of this scenario. TDM, LSC,
and/or FSC LSPs are established between MPLS networks across the
GMPLS network. A set of those LSPs provide virtual network topology
to connect the MPLS networks. This topology may be reconfigurable by
adding and/or removing those LSPs [15][16] MPLS LSRs and subnetworks
interconnected at the edges of the virtual network topology may form
a single MPLS network.
Figure 1 shows the reference network model for the
MPLS-GMPLS(non-PSC)-MPLS migration. The model consists of three
regions: ingress, transit, and egress. Both the ingress and egress
regions are MPLS-based while the transit region is GMPLS-based. The
nodes at the boundary of the MPLS and GMPLS regions (G1, G2, G5, and
G6) are referred to as "border nodes". All nodes except the border
nodes in the GMPLS-based transit region (G3 and G4) are non-PSC
devices, i.e., optical equipment (TDM, LSC, and FSC). An MPLS LSP
can be provisioned from a node in the ingress MPLS-based region (say,
R2) to a node in the egress MPLS-based region (say, R4). The LSP is
referred to as the end-to-end (e2e) LSP. The switching capability of
both end points of the e2e LSP are the same (PSC).
Brungard, et al. Expires April 25, 2005 [Page 4]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
................. .............................. ..................
: MPLS : : GMPLS (non-PSC) : : MPLS :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
:| / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
|<-------------------------------------------------------->|
e2e LSP
Figure 1: MPLS-GMPLS(non-PSC)-MPLS migration model.
2.2 MPLS-GMPLS(PSC)-MPLS
An MPLS-based network can be migrated to GMPLS (PSC)-based network.
The rationale of this type of migration scenario is supported by two
factors:
1. to provide GMPLS-based advanced features in the network
2. to facilitate stepwise migration from MPLS to a GMPLS-based
optical core network.
Numerous advanced features are being developed in GMPLS and MPLS, but
many are only currently available in a GMPLS context, such as
bi-directional LSPs, label control, graceful restart, graceful
teardown, and forwarding adjacencies. An existing MPLS-based network
could be migrated to become a GMPLS (PSC)-based network to deliver
the advanced features. Once the PSC network has been migrated to use
GMPLS, it could be migrated to be or work with a GMPLS-based optical
core network with less effort.
2.3 GMPLS(non-PSC)-MPLS-GMPLS(non-PSC)
In this scenario, TDM or L2SC e2e LSPs are provisioned in the GMPLS
network, which is disconnected. Since the MPLS-based controlled
infrastructure network is widely deployed, it is used to bridge the
disconnected GMPLS network. Pseudo wire emulation is used
edge-to-edge in the MPLS-based converged network to carry those LSPs
[13].
Figure 2 shows the reference network model for the
GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) migration. Both the ingress and
egress regions are GMPLS-based while the transit region is
MPLS-based. All nodes in the GMPLS-based regions except the border
Brungard, et al. Expires April 25, 2005 [Page 5]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
nodes (G1, G11, G2, G21, G71, G7, G81, and G8) are non-PSC devices.
An e2e GMPLS LSP can be provisioned from a node in the ingress
GMPLS-based region (say, G2) to a node in the egress GMPLS-based
region (say, G8). The switching capability of both end points of e2e
LSP must be the same.
.................. ............................. ..................
: GMPLS(non-PSC) : : MPLS : : GMPLS(non-PSC) :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|G1 |__|G11|___|G3 |__________|R1 |__________|G5 |___|G71|__|G7 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
:| / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|G2 |__|G21|___|G4 |__________|R2 |__________|G6 |___|G81|__|G8 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
|<-------------------------------------------------------->|
e2e LSP
Figure 2: GMPLS(non-PSC)-MPLS-GMPLS(non-PSC) migration model.
2.4 GMPLS(PSC)-MPLS-GMPLS(PSC)
In this scenario, GMPLS PSC e2e LSPs are provisioned in the GMPLS
network, which is disconnected. The MPLS-based controleed
infrastructure is used to bridge the disconnected GMPLS network.
Since the MPLS-based controlled network is PSC, the GMPLS PSC LSP can
cross MPLS-based converged network without extra treatment in data
plane.
2.5 GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC)
In this scenario a LSP starts/ends in the GMPLS (PSC) network and
ends/starts in the MPLS network. Some signaling conversion is
required on border LSRs. Since both networks are PSC there is no
data plane conversion at network boundaries.
Figure 3 shows the reference model for this migration scenario.
Head-End and Tail-end LSR are in distinct control plane regions."
Brungard, et al. Expires April 25, 2005 [Page 6]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
................. ..............................
: MPLS : : GMPLS (PSC) :
:+---+ +---+ +---+ +---+ +---+
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |
:+---+ +---+ +---+ +-+-+ +---+
: ________/ : : ________/ | ________/ : :
:| / : : / | / : :
:+---+ +---+ +---+ +-+-+ +---+
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |
:+---+ +---+ +---+ +---+ +---+
:................: :...........................:
|<-------------------------------------------->|
e2e LSP
Figure 3: GMPLS-MPLS migration model..
3. Difference between MPLS and GMPLS protocols
3.1 Routing
TE-link information is advertised by the IGP using TE extensions.
This allows LSRs to collect topology information for the whole
network and to store it in the traffic-engineering data base (TEDB).
Best-effort routes and/or traffic-engineered explicit routes are
calculated using the TEDB.
GMPLS extends the TE information advertised by the IGPs to include
non-PSC information. The GMPLS extensions also apply to PSC
networks. The GMPLS extensions may be carried transparently across
MPLS networks and may be used to compute a traffic-engineered
explicit route across a mixed network, however, it is likely that a
path computation component in an MPLS network will only be aware of
MPLS TE information. This may mean that it is impossible to compute
a correct e2e LSP from one MPLS domain to another acorss a GMPLS
domain.
Figure 4 illustrates this problem. Suppose that an e2e LSP is
provisioned between R2 and R4 and that we need to compute the path
between R2 and R4. The TE link information for the links R2-R21,
R21-G2, G6-R41 and R41-R4 is MPLS-based, while the information for
the links G2-G4, G2-G3, G3-G4 and G4-G6 is GMPLS-based. The node in
the MPLS-based ingress region (say, R2) may compute a path using the
TE link information that it is aware of, and may produce a path
R2-R21-G2-G4-G6-R41-R4. But it may be the case that the links G2-G4
and G4-G6 cannot be connected because they have different switching
Brungard, et al. Expires April 25, 2005 [Page 7]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
capablities. A path from G2 to G4 through G3 would, however, be
successful. If R2 was able to process the GMPLS TE information
advertised by the IGP it would see the switching capability
information and would select the correct path, but since it is an
MPLS node it selects the wrong path based on the limited MPLS TE
information.
................. .............................. ..................
: MPLS : : GMPLS (non-PSC) : : MPLS :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
: / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
|<---->|<----->|<------------>|<------------>|<----->|<---->|
MPLS-TE-link GMPLS-TE-link GMPLS-TE-link MPLS-TE-link
Figure 4: Problem mismatch of TE-link information in MPLS and GMPLS.
MPLS and GMPLS use the same set of link state advertisements, to
communicate network link state information, but the GMPLS network
uses several additional TLVs/sub-TLVs not defined for MPLS (see [4],
[5], [10], [11]).
3.2 Signaling
GMPLS RSVP-TE signalling ([2]) introduces new objects, and their
associated procedures, that can not be processed/inserted by MPLS
LSRs:
o The (Generalized) Label Request object (new C-Type), used to
identify the LSP encoding type, the switching type and the
generalized protocol ID (G-PID) associated with the LSP.
o The IF_ID RSVP_HOP objects, IF_ID ERROR_SPEC objects, and IF_ID
ERO/RRO subobjects that handle the Control plane/Data plane
separation in GMPLS network.
o The Suggested Label Object, used to reduce LSP setup delays.
o The Label Set Object, used to restrict label allocation to a set
of labels, (particularly useful for wavelength conversion
incapable nodes)
o The Upstream Label Object, used for bi-directional LSP setup (see
also Section 3.4)
o The Restart Cap object, used for graceful restart.
Brungard, et al. Expires April 25, 2005 [Page 8]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
o The Admin Status object, used for LSP administration, and
particularly for graceful LSP teardown.
o The Recovery Label object used for Graceful Restart
o The ADMIN-STATUS objedct used for administation and graceful
deletion
Also GMPLS introduces a new message, the Notify message, that is not
supported by MPLS nodes."
3.3 Control plane/data plane separation
TDM, LSC, FSC networks do not recognize packet delineation. In
GMPLS, the control channel can be logically (in-band) or physically
(out-of- band) separated from the data channel in those networks.
The control channels between adjacent nodes constitute a control
plane network. Control packets of routing and signaling protocols
are transmitted over the control plane network.
If the GMPLS network consists of only PSC devices, there can be no
control plane/data plane separation. If the GMPLS network consists
of PSC and non-PSC devices, there is at least a logical C/D
separation between non-PSC devices, and between PSC and non-PSC
devices.
The GMPLS control plane, which is designed to carry the control
packet in GMPLS network, is not likely to have enough capacity to
carry the user-data traffic from MPLS network. Therefore, the
control plane must ensure is it not carrying data traffic from the
MPLS network (see [9]).
3.4 Bi-directional LSPs
GMPLS provides bi-directional LSP setup - a single signaling session
manages the bi-directional LSP, and forward and reverse paths follow
the same route in the GMPLS network. There is no equivalent in MPLS
networks, forward and backward LSPs must be created in different
signaling sessions - the route taken by those LSPs may be different
from each other, and their sessions are treated differently from each
other. Common routes and fate sharing require additional,
higher-level coordination in MPLS.
If MPLS and GMPLS networks are inter-connected, bi-directional LSPs
from GMPLS network need to be carried in MPLS network.
4. Required mechanisms
This section details the set of routing and signalling mechanisms
required in order to bridge the difference between MPLS and GMPLS
protocols.
Brungard, et al. Expires April 25, 2005 [Page 9]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
The entire network consisting of ingress, transit, and egress regions
(See Figure 1 or Figure 2 for instance) may be managed either as a
single area or as multiple areas from the IGP perspective. A simple
migration approach can also consist of separating MPLS and GMPLS
networks into distinct IGP areas (possibly in distinct ASs), and then
relying on multi-area (multi-AS) routing, path computation, and
signaling solutions worked on in the CCAMP WG.
Note: This section only proposes mechanisms for MPLS-GMPLS-MPLS
migration scenario. GMPLS-MPLS-GMPLS and MPLS-GMPLS migration
scenarios requirements will be addressed in a future revision of this
document
4.1 Routing
4.1.1 TE link
If the entire network is a single area, the partial topology of
GMPLS-based region which consists of PSC-links should be made visible
to the MPLS regions. GMPLS TE-links are advertised into the MPLS
regions as MPLS TE-links using MPLS-based TE link information. This
requires some TE-link information conversion at the border nodes.
If the GMPLS-based region contains non-PSC links or devices (for
example, if the whole region is non-PSC with the exception of the
edge devices) PSC links should be set up between the PSC capable
devices (for example, the border nodes). For example, in Figure 3, a
PSC-link can be set up between G2 and G6.
MPLS TE-links may be understood by the nodes in the GMPLS network,
which can transform MPLS-based TE-link information into GMPLS-based
TE-link information. This transformation can be performed by the
border nodes or left to the individual GMPLS nodes.
There is no backward compatibility issue when MPLS and GMPLS LSRs
resides in distinct IGP areas, as TE-link information is not leaked
across area boundary (see see [24] and [21]).
4.1.2 Forwarding adjacencies
FAs may be established within or across the GMPLS region. The FAs
may be full FAs [19] or virtual FAs (see Section 4.1.2.2) and are
advertised into the MPLS regions, by the routing protocol using MPLS
TE-link information ( [10] and [11]).
4.1.2.1 Provisioned FAs
PSC links may be advertised as forwarding adjacencies (FAs) in the
Brungard, et al. Expires April 25, 2005 [Page 10]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
GMPLS-based region and advertised in the MPLS regions as TE links
using MPLS-based TE information. Any FA that is established across
the GMPLS region must be of type PSC so that is can be used by the
MPLS PSC network. If the GMPLS network is not PSC, the border nodes
are responsible for the appropriate adaptation.
An e2e MPLS LSP may be tunnelled through one or more FAs across the
GMPLS-based transit region. Multiple e2e MPLS LSPs may be tunnelled
through a single FA [19]. Statistical multiplexing can be used to
carry multiple e2e MPLS LSPs through a single FA-LSP thus making full
use of bandwidth in the GMPLS region.
Traffic engineering can be achieved within the GMPLS region by
repositioning the FA-LSPs without impacting the e2e MPLS LSPs.
Traffic engineering within the MPLS regions is performed by
repositioning the e2e MPLS LSPs and possibly utilizing different
FA-LSPs.
A full mesh of FAs may be created between every border node. The
merit of a full mesh of PSC FAs is that it provides stability to the
MPLS-level routing. That is, the forwarding table of an MPLS LSR is
not impacted by re-routing changes within the GMPLS region. Further,
there is always full MPLS reachability and immediate access to
bandwidth to support MPLS LSPs. However, the full mesh approach
means that bandwidth is always pre-allocated within the GMPLS region.
This might lead to congestion in the core of the region depending on
the topology and number of border nodes. If the traffic demand does
not necessitate a full mesh of FAs, the congestion could be avoided.
4.1.2.2 Virtual FAs
If PSC FAs are used to enable MPLS PSC connectivity over part or all
of a non-PSC GMPLS region it may be considered disadvantageous to
pre-provision the FA-LSPs since this may reserve bandwidth within the
GMPLS network that could be used for other LSPs in the absence of
MPLS packet-based traffic.
However, in order that the MPLS regions can route traffic across the
GMPLS region, the FAs must still be advertised into the MPLS regions
as TE links. Such TE links that represent the possibility of an FA
are termed "virtual FAs".
If an MPLS LSP is set up that makes use of a virtual FA, the
underlying FA-LSP is immediately instantiated. The virtual FA-LSP
may be initially pre-provisioned using techniques described in [8]
for secondary LSPs in shared mesh restoration.
A set of virtual FAs combined with a PSC links and pre-established
Brungard, et al. Expires April 25, 2005 [Page 11]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
FAs forms the virtual topology for best-effort and/or
traffic-engineered routes across the GMPLS region. The virtual
topology may be designed taking into account the (forecast) traffic
demand and the available resources in the GMPLS transit region. The
virtual topology may change dynamically according to variations in
the (forecast) traffic demand and the available resources to optimize
the tradeoff between network performance and the residual network
capacity. The virtual topology can be changed by setting up and/or
tearing down virtual FA-LSP as well as by changes to real links and
to real FAs. How to design the virtual topology and its changes is
out of scope of this document.
If virtual FAs are used in place of FAs, the TE links across the
GMPLS-based transit region can remain stable using pre-computed paths
while wastage of bandwidth within the GMPLS region, and unnecessary
reservation of adaptation ports at the border nodes is avoided. Some
consideration might be given to assigning higher costs to the TE
links for virtual FAs when the underlying FA-LSP has not been
established. This ensures that traffic is placed on existing FA-LSPs
before new FA-LSPs are established.
Note that, as for FAs, a virtual FA do not give rise to a routing
adjacency. Further, until the supporting FA-LSP is established there
can be no exchange of routing or signaling (e.g. RSVP Hello)
messages between the end points of the virtual FA.
4.1.2.3 FA Utilization
There are several possible schemes for determining how many FAs to
provision, when to enable the FAs, and whether to choose FAs of
virtual FAs, leading to specific mechanisms required for
transitioning:
1. If there is low traffic demand, some FAs, which do not carry any
e2e MPLS LSPs may be released so that resources in the GMPLS
region are released. Alternatively, the FAs may be retained for
future usage. Release or retention of under utilized FAs is a
policy decision. Additional FAs may also be created based on
policy, which might consider residual resources in the
GMPLS-based transit region and the change of traffic demand
across the region. By creating the new FAs, the network
performance such as maximum residual capacity may be improved.
2. As the number of FAs grows, the residual resource in the
GMPLS-based transit region may decrease. In this case,
re-optimization may be invoked in the GMPLS-based transit region
according the the policy. As part of the reoptimization process,
FA-LSPs may be rerouted while keeping interface identifiers of FA
links unchanged. The routing at the MPLS level is unaffected
since there is no change to the topology of TE links composed of
Brungard, et al. Expires April 25, 2005 [Page 12]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
FAs across the GMPLS-based transit region.
3. When residual resource in the GMPLS-based transit region
decreases to a certain level, some FAs may be released according
to policy. Ideally, only FAs that are not carrying e2e MPLS LSPs
would be released, but in some cases it may be necessary to
release FAs that are carrying traffic. The FA should be released
only after the LSA associated with the FA has been withdrawn
throughout the entire (MPLS and GMPLS) network. Once the LSA has
been withdrawn, any e2e MPLS LSPs routed over the FA will be
rerouted to use other FAs (by using other border nodes). The
effect of this process on e2e MPLS LSPs that use the FAs that are
being withdrawn can be reduced by using the graceful link
withdrawal procedures described in [22].
4.1.3 Segment Stitching
There is a direct, one to one relationship between the e2e MPLS LSP
and the stitched segment LSP that carries it across the transit
region. In the control plane it is clear that there are two LSPs,
but in the data plane, the stitching process means that there is
actually a single end-to-end label switched path.
If the transit region is PSC, the composite LSP is a simple PSC path
from ingress to egress. But stitching is also applicable with
non-PSC transit domains if appropriate adaptation function is
available to map (or encapsulate) the packets to the appropriate
signal.
4.1.3.1 Stitchable Segments with associated FAs
Stitchable transit segments may be managed as FAs or virtual FAs with
the consequent advertisement into the MPLS regions as TE links.
Note, however, that because of the one-to-one relationship between
the stitched segment and the e2e LSP, the TE link must be advertised
as fully utilised as soon as a single e2e LSP is carried regardless
of the relative bandwidths. Thus a stitching technique in a non-PSC
GMPLS transit region may make inefficient use of resources.
As an FA is in use, the ingress region will attempt to use
make-before-break with resource sharing to modify the e2e LSP as
required, and this may result in the e2e LSP being moved to a
distinct FA TE link.
4.1.3.2 Stitchable Segments without associated FAs
Stitching may also be used in the absence of FAs (or virtual FAs).
This is particularly feasible when the network is partitioned into
areas or ASs and the responsibility for routing the e2e MPLS LSP
Brungard, et al. Expires April 25, 2005 [Page 13]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
across the transit domain is delegated to the border node. See [21]
for more details of this applicability.
As FAs are not used, the change in bandwidth requirement will be
signaled as for the contiguous case with the expectation that the e2e
MPLS LSP will be modified using resource sharing. When this happens
the control plane managing the stitched segment must also act to
increase the reserved bandwidth. This operation might not be
necessary if cross-technology stitching (such as PSC to TDM) is in
use.
4.2 Signaling
Three basic cases for the MPLS-GMPLS-MPLS environment are described
in Figure 4 : LSP nesting, LSP converting, and LSP stitching.
1. LSP nesting: One or more e2e MPLS packet LSPs is nested into one
GMPLS LSP that may be PSC or non-PSC.
2. Contiguous LSP: The e2e MPLS packet LSP signaling messages ([7])
are translated at the GMPLS region border into GMPLS RSVP-TE
messages (see [3]), and are converted back again at the MPLS
region border. The GMPLS RSVP-TE segment MUST also be PSC. This
case requires a service interworking function mapping between [1]
and [3] at the control plane level.
3. LSP stitching: An e2e packet LSP is constructed by stitching MPLS
PSC LSP segments together with a transit GMPLS LSP. The transit
LSP would normally be PSC, but there is no reason to exclude
non-PSC LSPs provided that the right adaptation is available in
the data plane at the border nodes. The stitching model requires
identical function in the control plane to that used for nesting,
but a strict one-to-one relationship between LSP segments must be
maintained.
................. .............................. ..................
: MPLS : : GMPLS (PSC) : : MPLS :
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:|R1 |__|R11|___|G1 |__________|G3 |__________|G5 |___|R31|__|R3 |:
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
: ________/ : : ________/ | ________/ : : ________/ :
:| / : : / | / : : / :
:+---+ +---+ +---+ +-+-+ +---+ +---+ +---+:
:|R2 |__|R21|___|G2 |__________|G4 |__________|G6 |___|R41|__|R4 |:
:+---+ +---+ +---+ +---+ +---+ +---+ +---+:
:................: :...........................: :................:
session for e2e LSPs
|<-------------------------------------------------------->|
|<-------------------------------------------------------->|
Brungard, et al. Expires April 25, 2005 [Page 14]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
|<-------------------------------------------------------->|
session for FA/LSP tunnel
|<-------------------------->|
e2e LSP _____________________________
<------------ | FA/LSP tunnel | ----------->
<------------ | | ----------->
<------------ | | ----------->
|_____________________________|
(a) LSP nesting
e2e session
|<-------------------------------------------------------->|
____________ ____________________________ ____________
| MPLS seg. || GMPLS segment || MPLS seg. |
|____________||____________________________||____________|
(b) Contiguous LSP
e2e session
|<-------------------------------------------------------->|
transit session
|<-------------------------->|
____________ ____________________________ ____________
| MPLS seg. || GMPLS segment || MPLS seg. |
|____________||____________________________||____________|
(c) LSP stitching
Figure 5: Comparisons of signaling in MPLS-GMPLS-MPLS migration
model.
4.2.1 LSP nesting
LSP nesting applies to the MPLS-GMPLS(non PSC)-MPLS and the
MPLS-GMPLS(PSC)-MPLS migration scenarios.
Figure 5 (a) illustrates LSP nesting in the MPLS-GMPLS-MPLS reference
network. An FA-LSP is created across the GMPLS region to carry one
or more e2e MPLS PSC LSPs. The FA-LSP is advertised as a TE link.
Signaling messages are used to exchange the link identifiers for
FAs/virtual FAs in a similar way to that described in [7] and [19]
for FA-LSPs. The LSP_TUNNEL_INTERFACE_ID object is forwarded
transparently by transit LSRs to the FA tail-end (see [7]).
Brungard, et al. Expires April 25, 2005 [Page 15]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
Activation of the virtual FA may use techniques similar to those
described in [8] for secondary LSPs in mesh recovery and is for
further study.
Both unnumbered and numbered link identifiers for FAs/virtual FAs
should be supported.
4.2.2 Contiguous LSPs
The contiguous LSP technique is only applicable when the GMPLS-based
transit region is PSC i.e. only applicable for the
MPLS-GMPLS(PSC)-MPLS migration scenario. Figure 5 (b) illustrates a
contiguous LSP in the MPLS-GMPLS-MPLS reference network model. The
e2e LSP consists of three segments: ingress, transit, egress. The
transit segment is GMPLS-based and therefore it is referred to as
GMPLS-segment while others are referred to as MPLS-segments. The e2e
MPLS LSP is associated with the single session, which is referred to
as the "e2e" session.
Contiguous LSPs rely on the availability of control plane conversion
or mapping of the signaling messages as they cross the region
boundaries and are, therefore, only available when a significant set
of border nodes have this capability. Specifically the entry and
exit points to the GMPLS-based transit region used by an e2e MPLS LSP
must be capable of converting the signaling messages. If either node
is not capable of this function, the LSP setup will fail. Therefore,
the node capabilities SHOULD be advertised by the border nodes give
sufficient information to enable an operational path to be computed,
or that suitable crankback mechanisms are used. Another option is to
make all border nodes capable of this conversion so that there are no
issues.
Contiguous LSPs may be modified according to traffic demand changes
for the e2e LSP just as modifications may be made to a simple MPLS
LSP. That is, make-before-break with resource sharing may be used to
increase or decrease the bandwidth of the whole LSP.
4.2.3 LSP stitching
LSP stitching applies to the MPLS-GMPLS(non PSC)-MPLS and the
MPLS-GMPLS(PSC)-MPLS migration scenarios.
Figure 5 (c) illustrates LSP stitching in the MPLS-GMPLS-MPLS
reference network. A single e2e LSp is constructed in the data plane
from one segment in each region - the segments are stitched together
simply if all segments are packet-based, or through an adaptation
function if the middle segment is not a PSC LSP.
Brungard, et al. Expires April 25, 2005 [Page 16]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
In the control plane there are two sessions as there would be for LSP
nesting. However, only one e2e MPLS LSP can be carried by a single
transit segment if stitching is used. Note that the transit segment
may be pre-established and advertised as an FA, advertised as a
virtual FA and signaled on demand, or established on demand by the
GMPLS region border node as the result of an MPLS LSP setup request.
In the event of a change in traffic demand for the e2e LSP the
behavior depends on whether FAs are being used: - If an FA is in use,
the ingress region will attempt to use make-before-break with
resource sharing to modify the e2e LSP as required, and this may
result in the e2e LSP being moved to a distinct FA TE link. - If FAs
are not used, the change in bandwidth requirement will be signaled as
for the contiguous case with the expectation that the e2e LSP will be
modified using resource sharing. When this happens the control plane
managing the stitched segment must also act to increase the reserved
bandwidth. This operation might not be necessary if cross-technology
stitching (such as PSC to TDM) is in use.
4.2.4 Discovery of GMPLS signalling capability
It may be useful to advertise into the IGP the capability of a node
to support GMPLS signalling. This would allow every node in the
network to automatically discover the GMPLS signalling regions. [25]
provides a functional description of routing extensions in order to
advertise TE router information, including control plane capabilities
such as GMPLS signaling.
As there are several options for how the regions are managed from a
routing perspective. They could all be managed as a single area,
they could be managed as separate areas, or they could be operated as
separate ASs. In the second and third cases, it may make sense to
only advertise the border nodes that are capable of signaling
conversion since it is impossible to set up e2e LSPs through other
border nodes. In the first case, however, the full topology is
visible across the entire network and it is important that the
specific conversion capabilities of the border nodes are advertised
[25]. Note that in the case of contiguous LSPs, there is a
one-to-one relationship between LSPs in the MPLS region and LSPs in
the GMPLS region.
5. Security considerations
There are not security issues in this draft.
6. IANA Considerations
There are no IANA actions required by this draft.
Brungard, et al. Expires April 25, 2005 [Page 17]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
7. Acknowledgments
The authors are grateful to Adrian Farrel for his numerous valuable
comments.
8. References
8.1 Normative references
[1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G.
Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC
3209, December 2001.
[2] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description", RFC 3471, January 2003.
[3] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions", RFC 3473, January 2003.
[4] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering (TE)
Extensions to OSPF Version 2", RFC 3630, September 2003.
[5] Smit, H. and T. Li, "Intermediate System to Intermediate System
(IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June
2004.
[6] Mannie, E., "Generalized Multi-Protocol Label Switching
Architecture", draft-ietf-ccamp-gmpls-architecture-07 (work in
progress), May 2003.
8.2 Informative references
[7] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in
Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)",
RFC 3477, January 2003.
[8] Lang, J., "RSVP-TE Extensions in support of End-to-End
GMPLS-based Recovery",
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-01 (work in
progress), May 2004.
[9] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of
Generalized Multi-Protocol Label Switching",
draft-ietf-ccamp-gmpls-routing-09 (work in progress), October
2003.
[10] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of
Brungard, et al. Expires April 25, 2005 [Page 18]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
Generalized Multi-Protocol Label Switching",
draft-ietf-ccamp-ospf-gmpls-extensions-12 (work in progress),
October 2003.
[11] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support of
Generalized MPLS", draft-ietf-isis-gmpls-extensions-19 (work in
progress), October 2003.
[12] Lang, J., "Link Management Protocol (LMP)",
draft-ietf-ccamp-lmp-10 (work in progress), October 2003.
[13] Bryant, S. and P. Pate, "PWE3 Architecture",
draft-ietf-pwe3-arch-07 (work in progress), March 2004.
[14] Vigoureux, M., "Generalized MPLS Architecture for Multi-Region
Networks", draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04 (work in
progress), February 2004.
[15] Shiomoto, K., "Requirements for GMPLS-based multi-region and
multi-layer networks", draft-shiomoto-ccamp-gmpls-mrn-reqs-00
(work in progress), October 2004.
[16] Papadimitriou, D., "Generalized Multi-Protocol Label Switching
(GMPLS) Protocol Extensions for Multi-Region Networks (MRN)",
draft-papadimitriou-ccamp-gmpls-mrn-extensions-00 (work in
progress), October 2004.
[17] Pan, P., Swallow, G. and A. Atlas, "Fast Reroute Extensions to
RSVP-TE for LSP Tunnels",
draft-ietf-mpls-rsvp-lsp-fastreroute-07 (work in progress),
September 2004.
[18] Berger, L., "GMPLS Based Segment Recovery",
draft-ietf-ccamp-gmpls-segment-recovery-00 (work in progress),
April 2004.
[19] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08 (work in progress),
September 2002.
[20] Ayyangar, A. and J. Vasseur, "Inter domain MPLS Traffic
Engineering - RSVP-TE extensions",
draft-ayyangar-ccamp-inter-domain-rsvp-te-00 (work in
progress), July 2004.
[21] Farrel, A., "A Framework for Inter-Domain MPLS Traffic
Engineering", draft-farrel-ccamp-inter-domain-framework-01
(work in progress), July 2004.
Brungard, et al. Expires April 25, 2005 [Page 19]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
[22] Ali, Z., "Graceful Shutdown in MPLS Traffic Engineering
Networks", draft-ali-ccamp-mpls-graceful-shutdown-00 (work in
progress), June 2004.
[23] Shiomoto, K., "Multi-area multi-layer traffic engineering using
hierarchical LSPs in GMPLS networks",
draft-shiomoto-multiarea-te-01.txt (work in progress), June
2002.
[24] Le Roux, J., "Requirements for Inter-area MPLS Traffic
Engineering", draft-ietf-tewg-interarea-mpls-te-req-02.txt
(work in progress), June 2004.
[25] Vasseur, J. and J. Le Roux, "Routing extensions for discovery
of TE router information",
draft-vasseur-ccamp-te-router-info-00.txt (work in progress),
July 2004.
Authors' Addresses
Deborah Brungard
AT&T
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748
USA
Phone: +1 732 420 1573
EMail: dbrungard@att.com
Jean-Louis Le Roux
France Telecom R&D
av Pierre Marzin 22300
Lannion,
France
Phone:
EMail: jeanlouis.leroux@francetelecom.com
Brungard, et al. Expires April 25, 2005 [Page 20]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585
Japan
Phone: +81 422 59 3441
EMail: oki.eiji@lab.ntt.co.jp
Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen,
Belgium
Phone: +32 3 240 8491
EMail: dimitri.papadimitriou@alcatel.be
Daisaku Shimazaki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585
Japan
Phone: +81 422 59 4343
EMail: shimazaki.daisaku@lab.ntt.co.jp
Kohei Shiomoto
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585
Japan
Phone: +81 422 59 4402
EMail: shiomoto.kohei@lab.ntt.co.jp
Brungard, et al. Expires April 25, 2005 [Page 21]
Internet-Draft IP/MPLS - GMPLS interworking in support of IP/MPLS to GMPLS migration October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Brungard, et al. Expires April 25, 2005 [Page 22]