CCAMP Working Group D. Brungard (ATT)
Internet Draft J.L. Le Roux (FT)
Expiration Date: August 2005 E. Oki (NTT)
D. Papadimitriou (Alcatel)
D. Shimazaki (NTT)
K. Shiomoto (NTT)
February 2005
IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migration
draft-oki-ccamp-gmpls-ip-interworking-05.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.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document addresses the migration from Multi-Protocol 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
D.Brungard et al. - Expires August 2005 [Page 1]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
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 Segment Stitching . . . . . . . . . . . . . . . . . . 10
4.2 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1 LSP nesting . . . . . . . . . . . . . . . . . . . . . 13
4.2.2 Contiguous LSPs . . . . . . . . . . . . . . . . . . . 13
4.2.3 LSP stitching . . . . . . . . . . . . . . . . . . . . 14
4.2.4 Discovery of GMPLS signaling capability . . . . . . . 14
5. Security considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1 Normative references . . . . . . . . . . . . . . . . . . . 15
8.2 Informative references . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . 20
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
D.Brungard et al. - Expires August 2005 [Page 2]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
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 infrastructure. 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 capabilities 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
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
D.Brungard et al. - Expires August 2005 [Page 3]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
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).
................. .............................. ..................
: 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
D.Brungard et al. - Expires August 2005 [Page 4]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
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 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
D.Brungard et al. - Expires August 2005 [Page 5]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
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 controlled
infrastructure is used to bridge the disconnected GMPLS networks.
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.
................. ..............................
: 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
D.Brungard et al. - Expires August 2005 [Page 6]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
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 across 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
capabilities. 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
D.Brungard et al. - Expires August 2005 [Page 7]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
GMPLS RSVP-TE signaling ([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.
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 object used for administration 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
D.Brungard et al. - Expires August 2005 [Page 8]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
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 signaling mechanisms
required in order to bridge the difference between MPLS and GMPLS
protocols.
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.
D.Brungard et al. - Expires August 2005 [Page 9]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
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 [24] and [21]).
4.1.2 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.2.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 utilized 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.2.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
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
D.Brungard et al. - Expires August 2005 [Page 10]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
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
|<-------------------------------------------------------->|
|<-------------------------------------------------------->|
|<-------------------------------------------------------->|
session for FA/LSP tunnel
|<--------------------------->|
e2e LSP _____________________________
<------------ | FA/LSP tunnel | ----------->
<------------ | | ----------->
<------------ | | ----------->
|_____________________________|
D.Brungard et al. - Expires August 2005 [Page 11]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
(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
Fig.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. A (transit) 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]).
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. Virtual FAs are defined in [MRN-REQ].
Note that the transit FA-LSP may be pre-established and advertised
as an FA, or advertised as a virtual FA and signaled on demand, or
triggered on demand by the GMPLS region border node as the result of
an MPLS LSP setup request and then advertised as an FA.
D.Brungard et al. - Expires August 2005 [Page 12]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
In the event of a change in traffic demand for the e2e LSP, if a
transit FA-LSP 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.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 to give sufficient information to enable an operational path
to be computed, or to enable that suitable crankback mechanisms are
used. Another option is to make all border nodes capable of this
conversion so that there are no issue.
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.
D.Brungard et al. - Expires August 2005 [Page 13]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
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 signaling capability
It may be useful to advertise into the IGP the capability of a node
to support GMPLS signaling. This would allow every node in the
network to automatically discover the GMPLS signaling regions. [25]
provides GMPLS routing (IS-IS and OSPF) extensions for the
advertisement of TE node capabilities, including control plane
capabilities such as GMPLS signaling.
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
D.Brungard et al. - Expires August 2005 [Page 14]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
There are no IANA actions required by this draft.
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", RFC 3945, October 2004.
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-02 (work in progress), October 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
Generalized Multi-Protocol Label Switching", Internet-Draft,
D.Brungard et al. - Expires August 2005 [Page 15]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
draft-ietf-ccamp-ospf-gmpls-extensions-12, October 2003.
[11] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support of
Generalized MPLS", Internet-Draft, draft-ietf-isis-gmpls-
extensions-19, October 2003.
[12] Lang, J., "Link Management Protocol (LMP)", Internet-Draft
draft-ietf-ccamp-lmp-10, October 2003.
[13] Bryant, S. and P. Pate, "PWE3 Architecture", Internet-Draft,
draft-ietf-pwe3-arch-07, March 2004.
[15] Shiomoto, K., "Requirements for GMPLS-based multi-region
networks", draft-shiomoto-ccamp-gmpls-mrn-reqs-01 (work in
progress), February 2005.
[16] Papadimitriou, D., "Generalized Multi-Protocol Label Switching
(GMPLS) Protocol Extensions for Multi-Region Networks (MRN)",
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01 (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-01 (work in progress), October 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-ietf-ccamp-inter-
domain-rsvp-te-02 (work in progress), January 2005.
[21] Farrel, A., "A Framework for Inter-Domain MPLS Traffic
Engineering", draft-ietf-ccamp-inter-domain-framework-01 (work
in progress), July 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
D.Brungard et al. - Expires August 2005 [Page 16]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
Engineering", draft-ietf-tewg-interarea-mpls-te-req-02.txt
(work in progress), June 2004.
[25] Vasseur, J.P., Le Roux, J.L., "Routing extensions for discovery
of Traffic Engineering Node Capabilities", draft-vasseur-
ccamp-te-node-cap-00.txt (work in progress), February 2005.
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: +33 2 96 05 30 20
Email: jeanlouis.leroux@francetelecom.com
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
D.Brungard et al. - Expires August 2005 [Page 17]
draft-oki-ccamp-gmpls-ip-interworking-05.txt February 2005
Phone: +81 422 59 4402
Email: shiomoto.kohei@lab.ntt.co.jp
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 (2005). 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.
D.Brungard et al. - Expires August 2005 [Page 18]