CCAMP Working Group Eiji Oki Internet Draft Daisaku Shimazaki Expiration Date: September 2003 Kohei Shiomoto NTT March 2003 GMPLS and IP/MPLS Interworking Architecture 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 Gneneralized MPLS extends MPLS to support various transport technolo- gies. The final goal of GMPLS is to achieve seemless integration of IP/MPLS networks with various tranport networks such as SONET/SDH and wavelength networks. However, in the migration process from IP/MPLS networks to GMPLS networks, both kinds of networks coexist. IP/MPLS nodes that do not support GMPLS protocols also need to work with GMPMLS networks. This document describes GMPLS and IP/MPLS interworking archi- tecture, which icludes both routing and signaling aspects. Oki et al. [Page 1] Oki et al. draft-oki-ccamp-gmpls-ip-interworknig-00.txt June 2002 1. Summnary 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 proposes a interwork- ing architecture 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 between 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 Gneneralized MPLS extends MPLS to support various transport technolo- gies. One of GMPLS targests is to achieve seemless integration of IP/MPLS networks with various tranport networks such as SONET/SDH and wavelength networks. However, in the migration process from IP/MPLS networks to GMPLS networks, both networks coexist. IP/MPLS nodes that do not support GMPLS protocols also need to work with a GMPMLS network. This document describes GMPLS and IP/MPLS interworking architecture, which icludes both routing and signaling aspects. Oki et al. [Page 2] Oki et al. draft-oki-ccamp-gmpls-ip-interworknig-00.txt June 2002 3. +-------------+ +-----------------------------+ +-------------+ | +---+ | | +---+ +---+ | | +---+ | | ----+IN +-+-----+--+BN +--+ +--+BN +--+-----+-+IN +---- | | +-+-+ | | +---+ | +---+ | +---+ | | +-+-+ | | | | +--+ +--+ | | | | | | |CN | | | | | | | +--+ +--+ | | | | +-+-+ | | +---+ | +---+ | +---+ | | +-+-+ | | ----+IN +-+-----+--+BN +--+ +--+BN +--+-----+-+IN +---- | | +---+ | | +---+ +---+ | | +---+ | +-------------+ +-----------------------------+ +-------------+ IP/MPLS network GMPLS network IP/MPLS network Legend: CN: Core node BN: Boarder node IN: IP/MPLS node Figure 1 Reference network that consists of IP/MPLS and GMPLS networks Figure 1 shows a reference network, where IP/MPLS networks and a GMPLS network coexits. Nodes that appears in Figure 1 are defined as follows. GMPLS core node (CN): A CN is located in a GMPLS network. It is not con- nected with a IP/MPLS network. It supports GMPLS protocls. Border node (BN): A BN is located in a GMPLS network. It supports both GMPLS protocols and IP/MPLS protocols. It is connected with IP/MPLS net- works. IP/MPLS node (IN): An IN is located in an IP/MPLS network. It supports only IP/MPLS protocols, but does not support GMPLS protocols. An IN has functions of an IP router, a Label switch Router (LSR), or both. In the GMPLS network, TE-links are dipicted in Figure 1. BN and CN have topology information of the GMPLS network by using routing protocol. An intereface switching capaplity connected to each TE-link is not speci- fied in Figure 1. Links between BN and IN are dipicted, which are normal links between IP routers. The CN topology view is shown as Figure 2. A CN has the topology infor- mation of the GMPLS network. A CN MAY have the topology information of the IP/MPLS netowrks, as shown in Figure 1. +-----------------------------+ | +---+ +---+ | | |BN +--+ +--+BN | | Oki et al. [Page 3] Oki et al. draft-oki-ccamp-gmpls-ip-interworknig-00.txt June 2002 | +---+ | +---+ | +---+ | | +--+ +--+ | | |CN | | | +--+ +--+ | | +---+ | +---+ | +---+ | | |BN +--+ +--+BN | | | +---+ +---+ | +-----------------------------+ GMPLS network Figure 2 CN topology view. The IN topology view is shown as Figure 3. An IN does not notice that GMPLS exits among IP/MPLS networks. An IN does not see CN node. A BN node behaves like an IN for IP/MPLS networks. A TE-link between two BNs is defined, if needed, is created, as a link between two INs for IP/MPLS networks. Network operators decide BN pair defines its TE-link manually or automatically. +---------------------------------------------------------------------+ | +---+ +---+ +---+ +---+ | | ----+IN +----------+IN +---------------+IN +----------+IN +---- | | +-+-+ +---+-----+ +------+-+-+ +---+ | | | | | | +--+--+ | | | | | | +-+-+ +---+--------+ +---+---+ +-+-+ | | ----+IN +----------+IN +---------------+IN +----------+IN +---- | | +---+ +---+ +---+ +---+ | +---------------------------------------------------------------------+ IP/MPLS network Figure 3 IN topology view. 4. Addressing 5. Routing aspects LSA type 1 LSA type 10 6. Signaling aspects PSC LSC Oki et al. [Page 4] Oki et al. draft-oki-ccamp-gmpls-ip-interworknig-00.txt June 2002 7. References [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. 8. 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 5]