CCAMP Working Group Kohei Shiomoto (NTT) Internet Draft Rajiv Papneja (ISOCORE) Expiration Date: April 2004 Bijan Jabbari (ISOCORE) October 2003 Control plane architecture in GMPLS networks 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 This document addresses control plane architecutre in GMPLS enabled IP- Optical networks. Two different control plane architectures are consid- ered: symmetical and asymmetrical control plane architectures. Address- ing (router-ID, control plane address, and TE link address) and RSVP message handling are discussed for both architectures.The document also recommends normal practises for identification of TE links. Interwork between symmetrical and asymmetrical control plane is addressed. Shiomoto [Page 1] draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003 1. Author information This document is the product of the following authors collaboration. Kohei Shiomoto (NTT) NTT Network Innovation Laboratories 3-9-11 Midori, Musashino, Tokyo 180-8585, Japan Email: shiomoto.kohei@lab.ntt.co.jp Rajiv Papneja (Isocore) Isocore Corporation 8201 Greensboro Drive Suite 100, Mclean, VA 22102 Email: rpapneja@isocore.com Bijan Jabbari (Isocore) Isocore Corporation 8201 Greensboro Drive Suite 100, McLean, VA 22102 Email:bjabbari@isocore.com TBD 2. 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. 3. Introduction 3.1. Control plane separation Generalized MPLS (GMPLS) is currently being standardized in the IETF as a set of intelligent IP routing and signaling protocols that can be used to configure different switching networks: packet, layer-2, TDM, wave- length, fiber switching capabilities. Separation between control and data planes is distinctive feature for TDM, wavelength, fiber swtching networks. Control information that includes routing and singnaling packets are transported over control plane networks. Separation between control and data planes mandates a different treatment for control pack- ets as in conventional IP/MPLS protocols,there is almost no distinctions in the path taken by control and data packets in IP/MPLS networks. Shiomoto [Page 2] draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003 3.2. Impact on RSVP Two methods may be used in the symmetrical control plane as to which addresses are used for source and destination address of IP header of the Path message: (1) ingress-to-egress method and (2) hop-by-hop method. Source and destination addresses of IP header of the Path mes- sage are set to the ingress and egress nodes of LSP in the ingress-to- egress method while they are set to the the current hop and the next hop nodes, where the Path message is sent from the current to the next hop node. RSVP-TE is developed by extending RSVP developed for resource reserva- tion for Intserv model [RFC2205] and now is used to set up explicitly routed LSP (ER-LSP) in MPLS networks [RFC3209]. RSVP-TE adopts the ingress-to-egress method and uses addresses of ingress and egress of ER- LSP as the source and destination addresses of Path message with router alert option bit set. Path message may carry explicit route object (ERO) and the intermediate node inspcets the Path message and processes it to determine the appropriate next hop. Path message is routed along with the path specified in ERO. This mechanism works in IP/MPLS network because there is almost no dis- tinction as to how to forward control packet and data packet. It does not, however, work in GMPLS network because control plane network is constructed independent of data plane network topology in GMPLS network. For example, control plane network could be constructed as a native layer-two network or by using point-to-point GRE tunnels or IP-in-IP tunnels. While the ingress node and egress node are neighbors from con- trol plane perspective, they will not be neighboring nodes from the data plane perspective. The Path message cannot be inspected by intermediate nodes for data plane consequently the LSP setup, therfore fails. The ingress node is the neighbor node of the egress node in control plane perspective while the ingress node is not in the data plane perspective. After the ingress node sends the Path messaga out, the egress node receives it without allowing the intermediate nodes to inspect the Path message in data plane prespective with the result of the LSP setup fail- ure with the ingress-to-egress method. The hop-by-hop method should be used in such network. With the hop-by- hop method, the previous hop address is set to the source address of the Path messege and the next hop address is set to the destination address of the Path message. The Path message is routed along with the route along with which the LSP is to be routed in data plane network. Gener- alized Label request replaces the MPLS label request defined in the [RFC3209] in the GMPLS. It is required to carry the switching type requested by the ingress for the LSP, LSP encoding type defining the encoding type that will be used with the data associated with the LSP. It also defines the G-PID(generalized payload identifier), this value is Shiomoto [Page 3] draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003 associated with the payload type requested by the client layer of that LSP. Various implementations support different G-PID values, which causes interworking issues at the egress. A liberal policy in regards to accepting different payload values should be adopted. The G-PID range is open as defined in the [RFC-3471] allowing room for optional values. 3.3. Impcat on OSPF Since GMPLS caters to the PSC and non-PSC links there are few enhance- ments that are made to the exisiting OSPF-TE and ISIS-TE. The routing enhancements for the GMPLS is defined in the document [GMPLS-Routing] and [GMPLS-OSPF]. Once the Label switched paths have been established, document [LSP-HIER] defines how to associate TE properties with the links formed by Label Switched Paths. All the optical devices will advertise the links as either FSC, LSC, L2SC, or TDM capable and all IP routers will advertise their own links as PSC capable only. It is, therefore, important that all routing equipment are capable of qualify- ing the TE links on the switching capabilities. The OXCs will not adver- tise the link switching capability to be PSC. The CSPF algorithms on the IP routers have to be modified to incoporate the path computation across interfaces supporting various switching capabilities. Addresing and RSVP handling of symmetrical control plane is different from those of asymmetrical control plane. 3.4. Outline of this document In this document we address issues on RSVP handling in symmetrical and asymmetrical control plane and inter-work between both control plane architecture. For addressing we address router-ID, control plane address, and data plane address for both methods. For RSVP handling we address Path message routing, ERO processing, and HOP processing for both methods. For routing extensions we address the handling of non-PSC devices in the cspf computation and expected behavior of the clients. Moreover we address inter-work between both methods. 4. Control plane network architecture 4.1. Addressing Addresses are assgined to each node and link in both control and data plane in GMPLS networks. Router-ID is defined to identify the router and could be an non-IP address. Router-ID should be defined as loop- back address and be advertized by routing protocol. Loop-back address Shiomoto [Page 4] draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003 is stable address and therefore is not assigned to any of control and data plane address because any link failure causes the router-ID to become unreachable. Control plane address is assigned to each physical interface to control plane network. There is ambiguity in the implemen- tations to use the control channel address as the router-id for reacha- bility purposes. It is receommended that all the optical devices should support the notion of loopback address, which may be used as the router- id. Both numbered and unnumbered link control plane interface should be supported. Data plane address is assigned to each physical interface to data plane network and must be used as the TE-links in the GMPLS domain. Both numbered and unnumbered link data plane interface should be sup- ported. If the control channel used is a point-to-point link, it is recommended that it should be unnumbered interface. If numbered point- to-point connection for control channel is used, the endpoints of the GRE should not be used as the TE links. These control channels are advertised into routing as notmal links, which allows the routing of RSVP and other related control channels. 4.1.1. Identification of TE links in the GMPLS control plane TE links are defined as logical links which has TE properties and pro- vides information about the physical resources attached to it and can be used by the CSPF alogorithm for computing the paths for the GMPLS LSP setup. The TE links should not be confused with the addressing of the control channel and should be treated as seperate from the addressing used in the IP layer. Once the GMPLS LSPs are established the IP layer could use these LSPs as TE links [LSP-HIER]. Generally, TE links in the GMPLS layer are defined by the combination of local identifier, label and may be component links if the link type is using link bundling [lINK-BUNDLE]. The best practise to ensure seperation of the control channel addressing and TE links addressing is to assign unique address- ing to the data links (physical interfaces) connecting the routing equipment to the transport devices and use them as TE links. This sce- nario is valid only for numbered links. If the links are unnumbered then source and desitination loopback addresses with the Interface-ID is used in the ERO at the head-end of the LSP setup. TE links liveliness is an important factor that an LSR should verify before advertizing to its neighbors. This ensures that no stale entries are advertized in the TE link databases once there has been a physical link failure. Also, once the GMPLS LSP is used as a link in the IP layer, t he TE livliness ensures that the head-end and tail-end of the GMPLS LSP view the same status of the LSP. It has been observed that if restart is not sup- ported and for some reason a fiber cut happens at the ingress, and if it signals the LSP with new tunnel-ID, the transport devices and egress will maintain the state of the old LSP but the Ingress will consider it as a dead LSP. This LSP will still be operational in the IP layer and will be used to carry the traffic. Shiomoto [Page 5] draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003 4.2. Symmetrical and asymmetrical control plane In this document, we define two control plane architectures: symmetrical and asymmetrical control plane. Control plane network can be configured in the same topology as data plane topology. We call this conrol plane architecture "symmetrical" control plane. Figure 1 shows the example of symmetrical control plane. Each node consists of control plane part and data plane part. Node 1 is adjacent to node 2 in both control and data plane networks. Node 2 is adjacent to node 1 and node 3 in both control and data plane networks. Node 3 is adjacent to node 2 and node 4 in both control and data plane networks. Node 4 is adjacent to node 3 in both control and data plane networks. Control plane +---+ +---+ +---+ +---+ |C1 +-------+C2 +-------+C3 +-------+C4 | +---+ +---+ +---+ +---+ ========================================== Data plane +---+ +---+ +---+ +---+ |D1 +-------+D2 +-------+D3 +-------+D4 | +---+ +---+ +---+ +---+ Figure 1 Symmetrical control plane. Control plane network can be configured in the topolgoy different from that of the data plane network. We call this control plane architecture "asymmetrical" control plane. Figure 2 shows the example of asymmetri- cal control plane. Control plane network is constructed as a native layer-2 network. Node 1, 2, 3, and 4 are adjacent to one another in control plane network. On the other hand, node 1 is adajacent to node 2 but not to node 3 in data plane network, for instance. Node 1 is adja- cent to node 2 in data plane network. Node 2 is adjacent to node 1 and node 3 in data plane network. Node 3 is adjacent to node 2 and node 4 in data plane network. Node 4 is adjacent to node 3 in data plane net- work. Shiomoto [Page 6] draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003 Control plane +-----------+-----------+-----------+ | | | | +-+-+ +-+-+ +-+-+ +-+-+ |C1 | |C2 | |C3 | |C4 | +---+ +---+ +---+ +---+ ========================================== Data plane +---+ +---+ +---+ +---+ |D1 +-------+D2 +-------+D3 +-------+D4 | +---+ +---+ +---+ +---+ Figure 2 Asymmetrical control plane. 5. Symmetric control plane 5.1. Topology implementation Symmetric control plane is configured in either physical or logical sense. Physically symmetrical control plane is configured. In-fiber and out-of-fiber control channel can be configured. In-fiber contorl channel includes optical supervisory channel can be used for optical networks while DCC bytes can be used for SDH/SONET networks. Out-of- fiber control channel includes dedicated physical link in parallel with data plane link. Logical symmetrical control plane is configured even though physical control plane topology is different from that of data plane topology. IP-in-IP [RFC2003] and GRE [RFC2784] tunneling can be used to configure logical symmetrical control plane over physically asymmetrical control plane. 5.2. RSVP handling 5.2.1. Message routing Both ingress-to-egress method and hop-by-hop method can be used in sym- metrical control plane network. In the ingress-to-egress method, router alert option in the IP header of the Path message is set so that the intermidiate nodes inspect it. The Path message is forwarded to the egress node. Intermediate nodes inspect the Path message and the LSP is set up along with the route along with which the Path message is for- warded. Path message is routed according to the ERO object as specified in [RFC3209]. If the ERO deos not exist in the Path message, the Path message is forwarded in the same way as the normal IP packet, i.e., the Shiomoto [Page 7] draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003 forwarding table is consulted to determine the next hop. ERO consists of a combination of loose and strict subobjects. If the top subobject of ERO is loose, the next hop is determined according to the local pol- icy decision. The Path message must be routed in the same direction in the conrol plane network as the LSP is routed in the data plane network. Therefore the Path message should be routed so that the sufficient resource is available for the LSP along with the route in the data plane network. In the hop-by-hop method, the Path message is addressed to the next hop node [10.2, RFC3473]. In the hop-by-hop method, the Router Alert option should not be set. RSVP was designed to handle dynamic (non-explicit) path changes and non RSVP hops along the path and therefore the source and destination address of IP header of the Path message is set to the ingress and egress nodes of the "session". In generalized signaling, routes are usually exitly signaled hops that cannot allocate labels and cannot exist in the path of an LSP in the data plane network. 6. Asymmetric control plane 6.1. RSVP handling 6.1.1. Message routing In asymmetric control plane the Path message can take different route if we use ingress-to-egress method because the control plane topology is different from data plane topology. We should use the hop-by-hop method in asymmetrical control plane [10.2, RFC3473]. We may use the ingress- to-egress method by using ERO. The intermidiate node may insert strict subobjects in ERO in order to route the Path message along with the route with sufficient resource for the LSP. 7. Inter-work between symmetric and asymmetric control plane network Both the ingress-to-egress and hop-by-hop methods can be used in symmet- ric control plane network. Both the ingress-to-egress and hop-by-hop methods can be used in asymmetric control plane network. All combina- tion should be inter-operable. Solution for inter-operability will be developed in the future version of this draft. 8. Security considerations Security issues are not discussed in this draft. Shiomoto [Page 8] draft-shiomoto-ccamp-cplane-architecture-00.txtOctober 2003 9. Reference [RFC2003] C. Perkins, "IP Encapsulation within IP," RFC2003, October 1996. [RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specifica- tion," RFC2205, September 1997. [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic Routing Encapsulation (GRE)," RFC 2784, March 2000. [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swal- low, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC3209, December 2001. [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions," January 2003. [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with General- ized MPLS TE", [RFC Ed Queue] [draft-ietf-mpls-lsp-hierarchy-08.txt] [GMPLS-OSPF] Kompella, K., and Rekhter, Y. (Editors), "OSPF Extensions in Support of Generalized MPLS", (work in progress) [draft-ietf-ccamp- ospf-gmpls-extensions-11.txt] [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in MPLS Traffic Engineering", [RFC Ed Queue] [draft-ietf-mpls-bun- dle-04.txt] Shiomoto [Page 9]