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]