CCAMP Working Group Eiji Oki
Internet Draft Daisaku Shimazaki
Expiration Date: October 2003 Kohei Shiomoto
NTT
April 2003
GMPLS and IP/MPLS Interworking Architecture
draft-oki-ccamp-gmpls-ip-interworking-00.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 GMPLS target is to seamlessly integrate IP/MPLS networks with vari-
ous transport networks such as SONET/SDH and wavelength networks. How-
ever, in the migration from IP/MPLS networks to GMPLS networks, both
kinds of networks will coexist at some point. IP/MPLS nodes that do not
support GMPLS protocols must also work with GMPLS networks. This docu-
ment addresses the GMPLS and IP/MPLS interworking architecture, and
examples both routing and signaling aspects.
Oki et al. [Page 1]
Oki et al. draft-oki-ccamp-gmpls-ip-interworknig-00.txt April 2003
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.
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/MPLS networks with various transport net-
works 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 supposed to support GMPLS protocols.
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 must also work with the GMPLS network, while
IP/MPLS nodes are not modified to deal with GMPLS protocols.
Oki et al. [Page 2]
Oki et al. draft-oki-ccamp-gmpls-ip-interworknig-00.txt April 2003
This document describes a GMPLS and IP/MPLS interworking architecture
that considers the issues of routing and signaling.
3. Problem to be solved
3.1. IP/MPLS and GMPLS coexistence network model
+-------------+ +-----------------------------+ +-------------+
| +---+ | | +---+ +---+ | | +---+ |
| ----+R1 +-+-----+--+BN1+--+ +--+BN3+--+-----+-+R3 +---- |
| +-+-+ | | +---+ | +---+ | +---+ | | +-+-+ |
| | | +--+ +--+ | | |
| | | |CN1| | | |
| | | +--+ +--+ | | |
| +-+-+ | | +---+ | +---+ | +---+ | | +-+-+ |
| ----+R2 +-+-----+--+BN2+--+ +--+BN4+--+-----+-+R4 +---- |
| +---+ | | +---+ +---+ | | +---+ |
+-------------+ +-----------------------------+ +-------------+
IP/MPLS network GMPLS network IP/MPLS network
Legend: BN: Boarder node
CN: Core 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 Border node (BN): BNs are located in the GMPLS network. They sup-
port GMPLS protocols and IP/MPLS protocols. They are connected with
IP/MPLS networks.
GMPLS core node (CN): CNs are located in the GMPLS network. They are
not connected to the IP/MPLS network. They support only GMPLS protocols.
Router or label switch router (R): Rs are located in the GMPLS network.
They support only IP/MPLS protocols, not GMPLS protocols. They have the
functions of a router, a label switch router (LSR), or both.
Figure 1 depicts the TE-links in the GMPLS network. BNs and CNs Acquire
the topology of the GMPLS network by using a 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 BN and IN are depicted,
which are conventional subnetworks, such as point-to- point, broadcast,
Oki et al. [Page 3]
Oki et al. draft-oki-ccamp-gmpls-ip-interworknig-00.txt April 2003
NBMA, and point-to-multipoint networks.
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 right 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 BN and CN 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 net-
work can reflect the TE-links expressed by the opaque LSAs in its rout-
ing table.
Note that, from a control plane point of view, R1 in the left IP/MPLS
network communicates with R4 in the right IP/MPLS 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.
3.4. Interworking architecture
One requirement is that an R in the IP/MPLS network SHOULD NOT be
affected by GMPLS protocols. Another requirement is that an R in one
IP/MPLS network SHOULD communicate with another R in a different IP/MPLS
network.
An IP/MPLS and GMPLS interworking architecture is described. The topo-
logical view of a R is shown in Figure 2. The R does not notice that
GMPLS is set among IP/MPLS networks. The R does not see any CN node. In
IP/MPLS networks, a BN node behaves as an R. If needed, a TE-link
between two BNs is defined (created), as a link between two Rs in
IP/MPLS networks, which can be either conventional subnetworks, such as
point-to-point, broadcast, NBMA, and point-to-multipoint network, or
MPLS-based TE-links. Network operators decide which TE-link SHOULD be
defined between two BNs manually or automatically.
Oki et al. [Page 4]
Oki et al. draft-oki-ccamp-gmpls-ip-interworknig-00.txt April 2003
+---------------------------------------------------------------------+
| +---+ +-------+ +-------+ +---+ |
| ----+R1 +-------+R5(BN1)+--------------+R7(BN3)+-------+R3 + |
| +-+-+ +-------+-----+ +-----+-------+ +---+ |
| | | |
| +--+--+ |
| | | |
| +-+-+ +-------+--------+ +--+------+ +-+-+ |
| ----+R2 +-------+R6(BN2)+--------------+R8(BN4)+-------+R4 + |
| +-+-+ +-------+ +-------+ +---+ |
+---------------------------------------------------------------------+
IP/MPLS network
Figure 2 Topology view of R.
For example, BN1, BN2, BN3, and BN4 behave as R5, R6, R7, and R8,
respectively, to other Rs. Four TE-links are defined between R5 and R7,
R5 and R8, R6 and R7, and R6 and R8. These TE-links are advertised as
either conventional subnetworks?? or MPLS-based TE-links.
4. Solutions
Solutions to achieve the IP/MPLS and GMPLS interworking architecture
SHOULD be addressed.
[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-09.txt (work
in progress).
Oki et al. [Page 5]
Oki et al. draft-oki-ccamp-gmpls-ip-interworknig-00.txt April 2003
5. Authors' Addresses
Eiji Oki
NTT Network Innovation Laboratories
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Email: oki.eiji@lab.ntt.co.jp
Daisaku Shimazaki
NTT Network Innovation Laboratories
Midori 3-9-11
Musashino, Tokyo 180-8585, Japan
Email: shimazaki.daisaku@lab.ntt.co.jp
Kohei Shiomoto
NTT Network Innovation Laboratories
3-9-11 Midori-cho,
Musashino-shi, Tokyo 180-8585, Japan
Email: shiomoto.kohei@lab.ntt.co.jp
Oki et al. [Page 6]