CCAMP Working Group Eiji Oki, Editor
Internet Draft (NTT)
Expiration Date: April 2004
October 2003
Migrating from IP/MPLS to GMPLS networks
draft-oki-ccamp-gmpls-ip-interworking-01.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 (2003). All Rights Reserved.
Abstract
Generalized MPLS extends MPLS to support various transport technologies.
One important GMPLS target is to seamlessly integrate IP-only-capable or
IP+MPLS-capable networks (we call them IP/MPLS networks in this docu-
ment) 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 sup-
port 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-01.txt October 2003
document addresses operational considerations on GMPLS and IP/MPLS
interworking, and provides examples on both routing and signaling
aspects. For the existing routing protocol, information on the data
plane in the GMPLS network is needed to be available to make appropriate
routing tables at IP routers in the IP/MPLS networks. Selected informa-
tion on GMPLS nodes and GMPLS TE links in the GMPLS network needs to be
advertised to the IP/MPLS net- works by emulating information 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 methods, the tunnel
method and the stitch method, are presented.
1. Summary for Sub-IP Area
1.1. Summary
See the abstract above.
1.2. Where does it fit in the Picture of the Sub-IP Work
This work fits the CCAMP box.
1.3. Why is it Targeted at this WG
This draft is targeted at the CCAMP WG because it describes an inter-
working issue between GMPLS and IP/MPLS networks
1.4. Justification of Work
The CCAMP WG should consider this document as it provides an architec-
tural framework for interworking GMPLS and IP/MPLS networks.
1.5. 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.
E. Oki et al. [Page 2]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-01.txt October 2003
2. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to sup-
port various transport 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 either when the LSPs are crossing LSP regions (see
[MPLS-HIER]) and the LSPs are setup typically between an PSC and TDM or
LSC region, or when the LSPs are crossing areas or AS boundaries. The
former method makes use of the interface switching capability descriptor
(see [GMPLS-ROUTING]) but the latter does not. GMPLS networks can make
use of both methods, while MPLS only makes use of the latter.
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 GMPLS and IP/MPLS interworking scenarios that
illustrate the issues for routing and signaling.
3. Interworking Scenarios
3.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
E. Oki et al. [Page 3]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-01.txt October 2003
Legend: G: GMPLS node
R: Router or LSR
Figure 1 Reference network for IP/MPLS and GMPLS networks
Figure 1 shows the reference network for IP/MPLS and GMPLS interworking.
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 proto-
cols and PSC switching capability on their TE links directed in the
GMPLS network (i.e. [PSC,X] TE links, where X is any switching capabil-
ity 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 net-
works. 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
topology of the GMPLS network by using the GMPLS routing protocol. The
interface switching capability of each TE link is not specified in Fig-
ure 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].
3.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
table 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
E. Oki et al. [Page 4]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-01.txt October 2003
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 recognize a GMPLS control-plane topology (expressed by a non-
opaque LSA), R1 can communicate with R4, if they are allowed to use the
GMPLS control plane.
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.
3.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
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
E. Oki et al. [Page 5]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-01.txt October 2003
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.4. Interworking Considerations
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
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.
+--------------------------------------------------------------+
E. Oki et al. [Page 6]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-01.txt October 2003
| +---+ +-----+ +------+ +---+ |
| --+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 addi-
tion 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 adver-
tised as either conventional subnetworks or MPLS-based TE links.
4. Items for Further Consideration
To achieve the IP/MPLS and GMPLS interworking architecture, the follow-
ing items SHOULD be considered.
4.1. Routing: Advertisement of abstracted GMPLS TE links and GMPLS node
Advertisement of abstracted GMPLS TE links and GMPLS border node 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.
E. Oki et al. [Page 7]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-01.txt October 2003
However, 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
interworking and does seem to generate any further requirements/consid-
erations. 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.
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",
E. Oki et al. [Page 8]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-01.txt October 2003
RFC 3209, December 2001.
[GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of
Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions-10.txt (work
in progress).
[AYYANGAR-INTER] A. Ayyangar and J.P. Vasseur, "Inter-region MPLS Traf-
fic Engineering," draft-ayyangar-inter-region-te-00.txt (work in
progress).
[GMPLS-OVERLAY] G. Swallow et al., "GMPLS RSVP Support for the Overlay
Model," draft-ietf-ccamp-gmpls-overlay-01.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,
B-2018 Antwerpen, Belgium
Phone : +32 3 240 8491
E-mail: dimitri.papadimitriou@alcatel.be
Daisaku Shimazaki
NTT
E. Oki et al. [Page 9]
E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-01.txt October 2003
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]