CCAMP Working Group Eiji Oki, Editor Internet Draft (NTT) Expiration Date: August 2004 February 2004 Migrating from IP/MPLS to GMPLS networks draft-oki-ccamp-gmpls-ip-interworking-02.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 (2004). All Rights Reserved. Abstract Generalized MPLS (GMPLS) extends MPLS to support various transport tech- nologies. One important GMPLS target is to seamlessly integrate 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 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 support 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-02.txt February 2004 document addresses operational considerations on migrating from IP/MPLS to GMPLS networks and provides examples on both routing and signaling aspects. Routing information on the data plane (controlled by GMPLS) needs to be available at IP routers belonging to the IP/MPLS networks. Selected information on GMPLS nodes and GMPLS TE links in the GMPLS net- work needs to be advertised to the IP/MPLS networks by emulating infor- mation 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 meth- ods, the tunnel method and the stitch method, are presented. 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. 1. Introduction Generalized Multi-Protocol Label Switching (GMPLS) extends MPLS to sup- port various switching 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 when the LSPs are crossing LSP regions (see [MPLS- HIER]) and the LSPs are setup typically between a PSC and a TDM or LSC region by making use of the interface switching capability descriptor (see [GMPLS-ROUTING]) assigned to each TE link. 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 the migration scenarios from IP/MPLS networks to GMPLS networks that illustrate the issues for routing and signaling. E. Oki et al. [Page 2] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004 2. Migration Scenarios 2.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 Legend: G: GMPLS node R: Router or LSR Figure 1 Reference network for the migrating from IP/MPLS to GMPLS networks. Figure 1 shows the reference network for the migration from IP/MPLS to GMPLS networks. 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 protocols and PSC switching capability on their TE links directed in the GMPLS network (i.e. [PSC,X] TE links, where X is any switching capability 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 networks. 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 E. Oki et al. [Page 3] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004 topology of the GMPLS network by using the GMPLS routing protocol. The interface switching capability of each TE link is not specified in Figure 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]. 2.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 topology 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 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 exchange the routing information via a GMPLS control-plane, R1 can communicate with R4. However, traffic from the left IP/MPLS network to the right IP/MPLS network can occupy the GMPLS control-plane network resources. This SHOULD be avoided. 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. 2.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 E. Oki et al. [Page 4] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004 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 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. Migration requirements 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 E. Oki et al. [Page 5] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004 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. +--------------------------------------------------------------+ | +---+ +-----+ +------+ +---+ | | --+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 addition 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 advertised as either conventional subnetworks or MPLS-based TE links. E. Oki et al. [Page 6] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004 4. Items for Further Consideration To achieve the migration from IP/MPLS and GMPLS networks, the following items SHOULD be considered. 4.1. Routing: Advertisement of abstracted GMPLS TE links and router address Advertisement of a abstracted GMPLS TE link and router addresses 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. How- ever, 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 E. Oki et al. [Page 7] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004 interworking and does not seem to generate any further requirements/con- siderations. 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. 4.4. Recovery capability interworking Recovery mechanisms in MPLS networks are described in [MPLS-RECOV- ERY][FAST-REROUTE] and those in GMPLS networks are described in [GMPLS- RECOVERY]. Both mechanisms SHOULD work consistently without affecting each mechanism. In GMPLS networks, a concept of the shared risk link group (SRLG) is introduced. SRLG-disjoint routes are determined using the SRLG informa- tion advertised by the GMPLS OSPF extensions [GMPLS-OSPF]. However, when a GMPLS TE link in a GMPLS network is abstracted to a link for IP/MPLS networks, SRLG information is omitted. This means that IP/MPLS nodes do not completely determine SRLG-disjoint routes from IP/MPLS net- works' point of view when a GMPLS TE link is abstracted. 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", RFC 3209, December 2001. [GMPLS-OSPF] K. Kompella and Y. Rekhter, "OSPF Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions-12.txt (work in progress). E. Oki et al. [Page 8] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004 [AYYANGAR-INTER] A. Ayyangar and J.P. Vasseur, "Inter-region MPLS Traf- fic Engineering," draft-ayyangar-inter-region-te-01.txt (work in progress). [GMPLS-OVERLAY] G. Swallow et al., "GMPLS RSVP Support for the Overlay Model," draft-ietf-ccamp-gmpls-overlay-02.txt (work in progress). [GMPLS-RECOVERY] CCAMP P&R Design Team, "Analysis of Generalized Multi- Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)," draft-ietf-ccamp-gmpls-recovery-analy- sis-02.txt (work in Progress). [MPLS-RECOVERY] V. Sharma, et al. "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery," RFC 3469. [FAST-REROUTE] Ping Pan et. at., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels," draft-ietf-mpls-rsvp-lsp-fastreroute-03.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, E. Oki et al. [Page 9] E. Oki et al. draft-oki-ccamp-gmpls-ip-interworking-02.txt February 2004 B-2018 Antwerpen, Belgium Phone : +32 3 240 8491 E-mail: dimitri.papadimitriou@alcatel.be Daisaku Shimazaki NTT 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]