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]