CCAMP Working Group Kohei Shiomoto (NTT) Internet Draft Rajiv Papneja (ISOCORE) Expiration Date: June 2004 Bijan Jabbari (ISOCORE) February 2004 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 describes practice for designing control plane in GMPLS enabled IP-Optical networks. Two different control plane architectures are considered: symmetrical and asymmetrical control plane architec- tures. Addressing (router-ID, control plane address, and TE link address) and RSVP message handling are discussed for both architectures. The document also recommends best practices for identification of TE links. Interworking between symmetrical and asymmetrical control planes is also finally discussed. Shiomoto [Page 1] draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004 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 Richard Rabbat Fujitsu America Limited Vijay Pandayan Sycamore Network 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 Shiomoto [Page 2] draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004 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 a distinctive feature for TDM, wavelength, fiber switch- ing networks. Control information that includes routing and signaling packets are transported over control plane networks. Separation between control and data planes mandates a different treatment for control pack- ets than in conventional IP/MPLS protocols where there is almost no dis- tinction in the path taken by control and data packets in IP/MPLS net- works. 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 the IP header of the Path message: (1) ingress-to-egress method and (2) hop-by-hop method. Source and destination addresses of the IP header of the Path message are set to the ingress and egress nodes of LSP in the ingress- to-egress method. They are set to the current hop and the next hop nodes, when the IP header addresses are set using the hop-by-hop node. RSVP-TE adopts the ingress-to-egress method with the router alert option bit set. The Path message may carry explicit route object (ERO). Inter- mediate nodes inspect the Path message and process it to determine the appropriate next hop. The Path message is routed along the path speci- fied in the ERO. This mechanism works in IP/MPLS network because there is almost no dis- tinction as to how to forward control and data packets. It does not, however, work in GMPLS network because the control plane network is con- structed independently of the data plane network topology and thus may be different. For example, the control plane network could be con- structed as a native layer-2 network or by using point-to-point GRE tun- nels or IP-in-IP tunnels. While the ingress and egress nodes are neigh- bors from the control plane perspective, they may not be neighboring nodes from the data plane perspective. The Path message cannot be inspected by intermediate nodes, the LSP setup therefore fails. The ingress node is the neighbor of the egress node from the control plane perspective while the it is not from the data plane perspective. After the ingress node sends the Path message out, the egress node receives it Shiomoto [Page 3] draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004 without allowing the intermediate nodes to inspect the Path message resulting in the failure of the LSP setup when using 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 message and the next hop address is set to the destination address of the Path message. The Path message is routed along the route that the LSP is to be routed on in the data plane network. A Generalized Label request replaces the MPLS label request defined in the [RFC3209]. It is required to carry the switching type requested by the ingress of 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 (Gen- eralized Payload IDentifier): this value is 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 val- ues should be adopted. 3.3. Impact on OSPF Since GMPLS caters to PSC and non-PSC links, a few enhancements have been made to the existing OSPF-TE and ISIS-TE protocols. The routing enhancements for GMPLS are defined in [GMPLS-Routing] and [GMPLS-OSPF]. Once the Label Switched Paths have been established, [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, impor- tant that all routing equipment be capable of qualifying the TE linksf switching capabilities. For example, OXCs will not advertise the link switching capability to be PSC. The CSPF algorithms on the IP routers have to be modified to allow for path computation across interfaces sup- porting various switching capabilities. Addressing and RSVP handling of a symmetrical control plane are different from those of an asymmetrical control plane. 3.4. Outline of this document In this document we address issues on RSVP handling in symmetrical and asymmetrical control planes and inter-work between both control planes. With respect to addressing, we look at router-ID, control plane address, Shiomoto [Page 4] draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004 and data plane address for both methods. With respect to RSVP handling, we address Path message routing, ERO processing, and HOP processing. With respect to routing extensions, we address the handling of non-PSC devices in the CSPF computation and expected behavior of the clients. Lastly, we address inter-working between both methods. 4. Control plane network architecture 4.1. Addressing Addresses are assigned to each node and link in both control and data plane in GMPLS networks. A Router-ID is defined to identify the router and could be a non-IP address. Router-ID should be defined as loopback address and be advertised by the routing protocol. The loop-back address is a stable address and therefore is not assigned to any control or data plane address because any link failure causes the router-ID to become unreachable. A control plane address is assigned to each physi- cal interface to the control plane network. There is an ambiguity in the implementations that manifests itself in the use of the control channel address as the router-id for reachability purposes. It is rec- ommended that all the optical devices should support the notion of a loopback address, which may be used as the router-id. Both numbered and unnumbered link control plane interface should be supported. A data plane address is assigned to each physical interface to the data plane network and must be used as the address of the TE-links in the GMPLS domain. Both numbered and unnumbered link data plane interface should be supported. If the control channel used is a point-to-point link, it is recommended that it should be an unnumbered interface. If a 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 by the routing protocol as normal 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 that have TE properties and pro- vide information about the physical resources attached to them; they can be used by the CSPF algorithm for computing the paths. The TE links should not be confused with the addressing of the control channel and should be treated as separate from the addressing used in the IP layer. Once the 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 possibly component links if the link type uses link bundling [lINK-BUNDLE]. The best practice to Shiomoto [Page 5] draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004 ensure separation of the control channel addressing and TE links addressing is to assign unique addresses to the data links (physical interfaces) connecting the routing equipment to the transport devices and use them as TE links. This scenario is valid only for numbered links. If the links are unnumbered then source and destination loopback addresses with the Interface-ID are used in the ERO at the head-end of the LSP. TE linksf liveliness is an important factor that an LSR should verify before advertising to its neighbors. This ensures that no stale entries are advertised in the TE link databases once there has been a physical link failure. Also, once the LSP is used as a link in the IP layer, the TE liveliness ensures that the head-end and tail-end of the GMPLS LSP have the same view of the status of the LSP. It has been observed that if restart is not supported and a fiber cut happens at the ingress that 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 to be a dead LSP. This LSP will still be operational at the IP layer and will be used to carry the traffic. 4.2. Symmetrical and asymmetrical control plane We define two control plane architectures: symmetrical and asymmetrical control plane. A control plane network can be configured with the same topology as the data planefs. We call this control plane architecture "symmetrical" control plane. Figure 1 shows the example of symmetrical control plane. Each node consists of a 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, etc. A control plane network topology can be different from that of the data plane network. We call this control plane architecture "asymmetrical" control plane. Figure 2 shows the example of asymmetrical control plane. Control plane network is constructed as a native layer-2 net- work. Node 1 is adjacent to node 3 in control plane but not in data plane. Shiomoto [Page 6] draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004 Control plane +---+ +---+ +---+ +---+ |C1 +-------+C2 +-------+C3 +-------+C4 | +---+ +---+ +---+ +---+ ========================================== Data plane +---+ +---+ +---+ +---+ |D1 +-------+D2 +-------+D3 +-------+D4 | +---+ +---+ +---+ +---+ Figure 1 Symmetrical control plane. 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 A symmetric control plane is configured in either the physical or logi- cal sense. In-fiber and out-of-fiber control channel can be configured. An in-fiber control channel that 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 a dedicated physical link in parallel with the data plane link. A logically symmet- rical control plane can be configured even though the physical control plane topology is different from that of the data plane. IP-in-IP [RFC2003] and GRE [RFC2784] tunneling can be used to configure logically Shiomoto [Page 7] draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004 symmetrical control plane over a 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 a symmetrical control plane network. In the ingress-to-egress method, the router alert option in the IP header of the Path message is set so that the intermediate 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 the route on which the Path message is forwarded. The Path message is routed according to the ERO object as specified in [RFC3209]. If the ERO does not exist in the Path message, the Path message is for- warded in the same way as the normal IP packet, i.e., the forwarding ta- ble is consulted to determine the next hop. An ERO consists of a combi- nation of loose and strict subobjects. If the top subobject of ERO is loose, the next hop is determined according to the local policy deci- sion. The Path message must be routed in the same direction in the con- trol plane network as the LSP is routed in the data plane network. Therefore the Path message should be routed so that sufficient resources are available for the LSP. 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 explicitly 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 planes, the Path message can take a different route if we use ingress-to-egress method. We should use the hop-by-hop method in asymmetrical control plane [10.2, RFC3473]. We may use the ingress-to-egress method when using EROs. The intermediate node may insert strict subobjects in the ERO in order to route the Path message Shiomoto [Page 8] draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004 along 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. 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- Shiomoto [Page 9] draft-shiomoto-ccamp-cplane-architecture-01.txtFebruary 2004 bundle-04.txt] Shiomoto [Page 10]