CCAMP Working Group Eiji Oki, Editor
Internet Draft (NTT)
Expiration Date: August 2004
February 2004
Migrating from IP/MPLS to GMPLS networks
draft-oki-ccamp-gmpls-ip-interworking-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 (2004). All Rights Reserved.
Abstract
Generalized MPLS (GMPLS) extends MPLS to support various transport tech-
nologies. One important GMPLS target is to seamlessly integrate IP-
only-capable or IP+MPLS-capable networks (we call them IP/MPLS networks
in this document) with various transport networks such as SONET/SDH and
wavelength switched networks. IP/MPLS networks (supporting only packet
LSPs) migration to GMPLS networks (supporting both packet and non-packet
LSPs) will coexist at some point in time. Such IP/MPLS nodes that do not
support GMPLS protocols must also operate with GMPLS networks. IP/MPLS
nodes that do not support the processing non-packet LSP specifics of
GMPLS protocols must also operate with such GMPLS networks. This
E. Oki et al. [Page 1]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004
document addresses operational considerations on migrating from IP/MPLS
to GMPLS networks and provides examples on both routing and signaling
aspects. Routing information on the data plane (controlled by GMPLS)
needs to be available at IP routers belonging to the IP/MPLS networks.
Selected information on GMPLS nodes and GMPLS TE links in the GMPLS net-
work needs to be advertised to the IP/MPLS networks by emulating infor-
mation that can be understood by IP routers. These advertised nodes and
links need to appear as IP router entries and behave as conventional IP
subnetworks. From the signaling aspects, a comparison between two meth-
ods, the tunnel method and the stitch method, are presented.
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.
1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to sup-
port various switching technologies. GMPLS enables us to achieve the
seam- less integration of IP-only-capable or IP+MPLS-capable networks
(we call them IP/MPLS networks in this document) with various transport
networks such as SONET/SDH and wavelength networks. GMPLS introduces new
concepts of interface switching capability such as forwarding adjacency
label switch path (FA-LSP), and generalized labels. All nodes in GMPLS
networks are assumed to support GMPLS protocols.
FA-LSPs are defined when the LSPs are crossing LSP regions (see [MPLS-
HIER]) and the LSPs are setup typically between a PSC and a TDM or LSC
region by making use of the interface switching capability descriptor
(see [GMPLS-ROUTING]) assigned to each TE link.
However, in the migration process from IP/MPLS networks to GMPLS net-
works, both will coexist at some point in time. IP/MPLS nodes that do
not support GMPLS protocols such as RSVP-TE [RFC3473] and OSPF-TE exten-
sions [GMPLS-OSPF] must also operate with the GMPLS network, while
IP/MPLS nodes are not modified to deal with GMPLS protocols.
This document describes the migration scenarios from IP/MPLS networks to
GMPLS networks that illustrate the issues for routing and signaling.
E. Oki et al. [Page 2]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004
2. Migration Scenarios
2.1. IP/MPLS and GMPLS coexistence network model
+---------+ +-------------------------+ +---------+
| +---+ | | +---+ +---+ +---+ + | +---+ |
| --+R1 +-+-----+--+G1 +---+G3 +---+G5 +--+-----+-+R3 +-- |
| +-+-+ | | +---+ +---+ +---+ | | +-+-+ |
| | | | | | | | |
| | | +---+---+ | | | |
| | | | | | | | |
| | | | +---+ | | | |
| | | | | | | | |
| +-+-+ | | +---+ +---+ +---+ | | +---+ |
| --+R2 +-+-----+--+G2 +---+G4 +---+G6 +--+-----+-+R4 +-- |
| +---+ | | +---+ +---+ +---+ | | +---+ |
+---------+ +-------------------------+ +---------+
IP/MPLS network GMPLS network IP/MPLS network
Legend: G: GMPLS node
R: Router or LSR
Figure 1 Reference network for the migrating from IP/MPLS to GMPLS networks.
Figure 1 shows the reference network for the migration from IP/MPLS to GMPLS
networks. Nodes that appears in Figure 1 are defined as follows.
GMPLS node (G): Gs are located in the GMPLS network. They support
GMPLS protocols. Gs are categorized into border nodes and core
nodes. A G that is connected with IP/MPLS networks, is referred to
a border node, which are G1, G2, G5, and G6.
The GMPLS border nodes support IP/MPLS
protocols and PSC switching capability on their TE links directed
in the GMPLS network (i.e. [PSC,X] TE links, where X is any switching
capability supported by the GMPLS network). A G that is not connected to the
IP/MPLS networks, is referred to a core node, which are G3 and G4.
Router or label switch router (R): Rs are located in the IP/MPLS
networks. They support only IP/MPLS protocols, not GMPLS protocols.
They have the functions of an IPv4/v6
router (i.e. without label switching on some or all their interfaces
in particular those directed toward the GMPLS network), a label switch
router (LSR), or both. Note that some Rs in an IP/MPLS network are connected to a GMPLS
network such as R1, R2, R3, and R4 as depicted in Figure 1, and
some Rs in an IP/MPLS network are not directly connected to a GMPLS network
while they are connected to other Rs in the same IP/MPLS network
although they are not depicted.
Figure 1 depicts the TE links in the GMPLS network. Gs acquire the
E. Oki et al. [Page 3]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004
topology of the GMPLS network by using the GMPLS routing protocol. The
interface switching capability of each TE link is not specified in
Figure 1. TE links with several kinds of interface switching
capabilities can exist in the GMPLS network. Links between a GMPLS
border node and R are depicted, which are conventional
subnetworks, such as point-to- point, broadcast, NBMA, and
point-to-multipoint networks. Models where the R routers
are GMPLS capable while the network that hosts them are purely IP/MPLS
based constitute a particular case of [GMPLS-OVERLAY].
2.2. Routing aspects
Consider that R1 in the left IP/MPLS network communicates with R4 in the
right IP/MPLS network via the data plane of the GMPLS network in Figure
1. R1 needs to have the routing information to R4. However, since R1
does not support GMPLS protocols, R1 is not able to create the routing
topology for the representative R1-R4 IP/MPLS network by using the data
plane of the GMPLS network. Routing information in terms of data plane
for the GMPLS and IP/MPLS networks MUST be exchanged. Although Gs can
advertise opaque LSAs to inform other nodes of the TE links in the GMPLS
network via the existing OSPF extensions [GMPLS-OSPF], no R in the
IP/MPLS network can reflect the TE link expressed by the opaque LSA in
its TE LSDB such that these links appear as being packet switching capa-
ble.
Note that if R1 in the left IP/MPLS network and R4 in the right IP/MPLS
network exchange the routing information via a GMPLS control-plane, R1
can communicate with R4. However, traffic from the left IP/MPLS network
to the right IP/MPLS network can occupy the GMPLS control-plane network
resources. This SHOULD be avoided.
Additionally, a GMPLS core node (e.g. G3) can not create the routing ta-
ble for the IP/MPLS network for routing LSPs originating in the GMPLS
network crossing into the IP/MPLS network. Routing information of the
IP/MPLS network needs to be advertised to the GMPLS network.
2.3. Signaling aspects
Consider that R1 in the left IP/MPLS network tries to set up a label
switched path (LSP) to R4 in the right IP/MPLS network in Figure 1.
Since R1 does not support the GMPLS protocols, R1 uses, for example, the
MPLS- based RSVP-TE signaling protocol to set up the LSP [RFC3209]. The
GMPLS network MUST deal with the MPLS-based signaling protocol without
impacting the IP/MPLS networks that support only the IP/MPLS protocols.
Here, the signaling protocol of RSVP-TE for establishing an MPLS LSP via
E. Oki et al. [Page 4]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004
a GMPLS network is considered when IP/MPLS nodes have a network topology
containing part of an GMPLS internal network. There are two methods --
the tunnel method and the stitch method [AYYANGAR-INTER] -- for process-
ing RSVP-TE control packets such as Path and Resv Messages from IP/MPLS
nodes at GMPLS border nodes.
A GMPLS network and IP/MPLS networks MAY be located within a single OSPF
routing area, or a GMPLS network MAY correspond to a single routing area
or multiple routing areas. In this case, GMPLS border nodes correspond
to Area Boarder Nodes. A GMPLS network MAY correspond to a single AS or
multiple ASs.
In the tunnel method, GMPLS border nodes treat the incoming MPLS LSP
request as a GMPLS PSC LSP request. This node then looks toward any of
its existing established PSC FA-LSPs to tunnel this request. Control
packets, such as MPLS LSP Path message are then forwarded using one of
the methods described in [MPLS-HIER]. Moreover, MPLS control packets,
such as MPLS Path messages, MAY be forwarded into a PSC LSP that inter-
connects the control plane of the GMPLS border nodes.
In the stitch method, a GMPLS border node translates MPLS RSVP control
packets into GMPLS RSVP control packets and connects the two LSPs: an
MPLS LSP and a GMPLS PSC LSP. Control packets translated from MPLS to
GMPLS are forwarded to the GMPLS control plane. Whereas, in the tunnel
method, the MPLS messages used to control the MPLS LSP are forwarded
through the GMPLS network using an established PSC LSP.
In the IP/MPLS network, RSVP-TE is used for not only LSP establishment
but also for continuity (or health) checks of established LSPs by making
use of RSVP refresh messages. In the stitch method, executing MPLS LSP
continuity checks regularly implies translation and forwarding of the
resulting GMPLS RSVP-TE packets between GMPLS border nodes. The tunnel
method is more advantageous for continuity checks of MPLS LSPs. This is
because GMPLS border nodes do not need to translate these RSVP-TE pack-
ets in order to forward them to the other end (via an established PSC
LSP). In this case, only trigger messages need to be translated.
3. Migration requirements
One requirement is that the IP/MPLS network operations on packet LSPs
SHOULD NOT be impacted by GMPLS network operations on PSC and non-PSC
LSPs. Another requirement is that a router in an IP/MPLS network (say
Ri) SHOULD be able to communicate with any another router in an IP/MPLS
network (say Rj, i =/= j). This MAY be accomplished through the use of
an intermediate node Rk such that i =/= k and j =/= k.
The topological view from the IP/MPLS network is shown in Figure 2. TE
E. Oki et al. [Page 5]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004
links from the GMPLS network are selected to be advertised to the
IP/MPLS networks. Rs in IP/MPLS networks do not notice that GMPLS LSPs
are established between the inter-connected IP/MPLS networks. For
instance, R1 does not see G3. Within the IP/MPLS network(s), the adver-
tised GMPLS nodes (say G's) behave as any other IP-only-capable node or
MPLS-capable node (say R's). Note that If needed, a TE link between two
advertised G's is created and advertised as any other link between two
R's of the IP/MPLS network(s). The interface switching capabilities at
the both ends of the TE link (defined between G's) MUST be packet
switching capable (PSC).
Note: R4 may want to setup a packet LSP to G4 (see Figure 1.) and vice-
versa. In this case, G4 must host TE links whose interface switching
capability includes PSC. It MAY be thus required that the PSC TE link
related information advertised by G4 is translated by other GMPLS border
nodes in order to allow R3 (or other border Rs) performing this opera-
tion in order to allow R4.
Network operators will decide which TE link SHOULD be defined between
two Gs, manually or automatically.
+--------------------------------------------------------------+
| +---+ +-----+ +------+ +---+ |
| --+R1 +--------+R5(G1)+--------------+R8(G5)+--------+R3 +-- |
| +-+-+ +-----+ +------+ +---+ |
| | | | |
| +-----+---------------+ | |
| | | | |
| | +----+ +----------+ |
| | | | |
| +-+-+ +------+ +------+ +------+ +---+ |
| --+R2 +--------+R6(G2)+---+R7(G4)+---+R9(G6)+--------+R4 +-- |
| +---+ +------+ +------+ +------+ +---+ |
+--------------------------------------------------------------+
IP/MPLS network
Figure 2 Topology view of R.
The advertised G's are G1, G2, G4, G5, and G6, and behave as R5, R6,
R7, R8, and R9, respectively. The advertised TE links are defined
(in addition to the R1-R5, R2-R6, R3-R8 and R4-R9 TE links) between
R5-R6, R5-R7, R5-R8, R6-R7, R6-R8, R7-R8 and R7-R9. These TE links are
advertised as either conventional subnetworks or MPLS-based TE links.
E. Oki et al. [Page 6]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004
4. Items for Further Consideration
To achieve the migration from IP/MPLS and GMPLS networks, the following
items SHOULD be considered.
4.1. Routing: Advertisement of abstracted GMPLS TE links and router
address
Advertisement of a abstracted GMPLS TE link and router addresses to the
IP/MPLS networks SHOULD be addressed in such a way that an IP/MPLS net-
work can be aware of their existence. This dissemination mechanism
should be defined such that the IP/MPLS network is not confronted with
internal GMPLS TE information which it can not process (e.g. internal
GMPLS TE links).
Additionally, a GMPLS core node requires advertisement of the corre-
sponding IP/MPLS network to allow routing for LSPs originated within the
GMPLS network.
4.2. Control Plane-Data Plane Separation: IP data-plane packet trans-
mission in GMPLS networks
An IP router MAY receive link states updates from a GMPLS control plane
network and insert this information in its TE link state database. How-
ever, it is not desirable that IP data-plane packets are transmitted
through the GMPLS control plane. This transmission SHOULD be avoided.
Avoiding inserting IP/MPLS data plane packets into the GMPLS control
plane SHOULD be detailed (using as starting point section 2.2 of [GMPLS-
ROUTING]), in particular when an IGP adjacency is defined between the
GMPLS and IP/MPLS networks. On the other hand, it is expected that the
control plane of GMPLS border nodes shall be capable to process incoming
requests (i.e. that triggers the establishment of an LSP through the
GMPLS network). But discriminate these control packets from those that
require only tunnelling (via the GMPLS control plane or data plane LSP)
to reach the other GMPLS border nodes. In brief, not only the IP/MPLS
data plane packets shall not be forwarded throughout the GMPLS control
plane but the latter shall also be functionally transparent to IP/MPLS
control plane packets, in particular if it does not support any PSC
capability.
4.3. Signaling: Tunnelling and Stitching
Two signaling methods are currently defined: automated LSP stitching
(using LSP segments) and LSP tunnelling (using FA-LSP). The LSP tun-
nelling method is currently available to achieve IP/MPLS and GMPLS
E. Oki et al. [Page 7]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004
interworking and does not seem to generate any further requirements/con-
siderations. The stitching method is detailed in the MPLS context (see
[AYYANGAR-INTER]) and SHOULD be analyzed to determine if some specific
issues needs to be addressed in the IP/MPLS - GMPLS interworking con-
text.
4.4. Recovery capability interworking
Recovery mechanisms in MPLS networks are described in [MPLS-RECOV-
ERY][FAST-REROUTE] and those in GMPLS networks are described in [GMPLS-
RECOVERY]. Both mechanisms SHOULD work consistently without affecting
each mechanism.
In GMPLS networks, a concept of the shared risk link group (SRLG) is
introduced. SRLG-disjoint routes are determined using the SRLG informa-
tion advertised by the GMPLS OSPF extensions [GMPLS-OSPF]. However,
when a GMPLS TE link in a GMPLS network is abstracted to a link for
IP/MPLS networks, SRLG information is omitted. This means that IP/MPLS
nodes do not completely determine SRLG-disjoint routes from IP/MPLS net-
works' point of view when a GMPLS TE link is abstracted.
5. References
[MPLS-HIER] K. Kompella et al., "LSP Hierarchy with Generalized MPLS
TE," draft-ietf-mpls-lsp-hierarchy-08.txt (work in progress).
[GMPLS-ROUTING] K. Kompella and Y. Rekhter, "Routing Extensions in Sup-
port of Generalized Multi-Protocol Label Switching," draft-ietf-ccamp-
gmpls-routing-09.txt, Octorber 2003 (work in progress).
[RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP Tun-
nels", RFC 3209, December 2001.
[RFC3471] L. Berger et al., "Generalized MPLS - Signaling Functional
Description", RFC 3471, January 2003.
[RFC3473] L. Berger et al., "Generalized MPLS Signaling - RSVP-TE Exten-
sions", RFC 3473, January 2003.
[RFC3209] Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of
Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions-12.txt (work
in progress).
E. Oki et al. [Page 8]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004
[AYYANGAR-INTER] A. Ayyangar and J.P. Vasseur, "Inter-region MPLS Traf-
fic Engineering," draft-ayyangar-inter-region-te-01.txt (work in
progress).
[GMPLS-OVERLAY] G. Swallow et al., "GMPLS RSVP Support for the Overlay
Model," draft-ietf-ccamp-gmpls-overlay-02.txt (work in progress).
[GMPLS-RECOVERY] CCAMP P&R Design Team, "Analysis of Generalized Multi-
Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including
Protection and Restoration)," draft-ietf-ccamp-gmpls-recovery-analy-
sis-02.txt (work in Progress).
[MPLS-RECOVERY] V. Sharma, et al. "Framework for Multi-Protocol Label
Switching (MPLS)-based Recovery," RFC 3469.
[FAST-REROUTE] Ping Pan et. at., "Fast Reroute Extensions to RSVP-TE for
LSP Tunnels," draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt (work in
progress).
6. Author's Address
Eiji Oki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp
7. Contributors
Deborah Brungard
AT&T
Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA
Phone: +1 732 420 1573
E-mail: dbrungard@att.com
Jean-Louis Le Roux
France Telecom R&D
av Pierre Marzin
22300 Lannion
France
Email: jeanlouis.leroux@francetelecom.com
Dimitri Papadimitriou
Alcatel
Francis Wellensplein 1,
E. Oki et al. [Page 9]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004
B-2018 Antwerpen, Belgium
Phone : +32 3 240 8491
E-mail: dimitri.papadimitriou@alcatel.be
Daisaku Shimazaki
NTT
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Email: shimazaki.daisaku@lab.ntt.co.jp
Kohei Shiomoto
NTT
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
Email: shiomoto.kohei@lab.ntt.co.jp
E. Oki et al. [Page 10]