Internet Draft IP-Optical Working Group Darren Freeland Neil Harrison Sergio Inglima Keith James Alan McGuire Shehzad Mirza Stewart Ritchie Mel Robinson Ali Salman Peter Willis Internet Draft BT Document: draft-freeland-octrl-cons-00.txt November 2000 Considerations on the development of an Optical Control Plane 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. Abstract Work on extensions to IP control protocols for reuse in the control plane of optical transport networks has now been underway for around a year in the MPLS and IPO groups. Recent discussions have however highlighted a lack of defined requirements that should be met by candidate protocols being considered for the optical control plane. Indeed, there have been several requests for carriers to submit their requirements. This draft provides one view of some (but by no means all) of these requirements. A protocol independent approach is taken, and the authors recommend that the design of any particular facet of an optical control plane should take into account the considerations made in this document. Freeland et al 1 Considerations on the Development of an Optical Control Plane November 2000 CONTENTS 1. INTRODUCTION 2. CURRENT STANDARDS WORK 2.1 Nature of the OTN User Plane 3. TYPES OF CONNECTION 4. CARRIER OPERATING MODELS 5. OPTICAL CONTROL REQUIREMENTS 5.1 Addressing 5.2 Signalling 5.3 Routing 5.4 Other Issues 6. CONCLUSIONS 7. SECURITY CONSIDERATIONS 8. REFERENCES 9. Author's Contact Details 1. INTRODUCTION This draft gives consideration to some of the requirements that must be met by an optical control plane for various operating models. A brief summary of current standards activities with respect to optical control is also given, including a discussion on the nature of the optical layer user plane. A protocol independent approach is taken throughout the document, and the authors recommend that any particular control plane facet being considered for an optical transport network should take into account the requirements defined in this document. 2. CURRENT STANDARDS WORK A framework for IP over optical networks has been considered in the IETF [1]. Work is also underway on the extension of existing protocols developed for the MPLS traffic engineering control plane for application to the design of an optical network control plane as discussed [2]. Specifically, this work is known as MPL(ambda)S or O-MPLS and is a subset of G-MPLS or Generalised MPLS - the extension of MPLS signalling to encompass a number of possible layer 1 network technologies [3]. This implies extensions to CR-LDP and RSVP for signalling, OSPF and IS-IS for resource discovery and routing, and the use of IP addressing. It has been assumed that IP control protocols will be suitable for the control plane of layer 1 networks, given that IP traffic volumes will dominate these networks. The authors of this draft argue that this assumption has not yet been proved to be the right choice, given the nature of the optical transport network Freeland et al 2 Considerations on the Development of an Optical Control Plane November 2000 (OTN) and the requirements of carriers. Indeed there are counter marketing opinions and statistics which compel us to consider the existence of other client networks for a number of years to come. For example, some operators will use ATM to carry traffic from third generation mobile networks, and there is little, if any, slowing down of the demand for ATM and leased-line services. 2.1 Nature of the OTN user-plane User plane connections are separable entities from the control plane in the OTN. In particular, user plane and control plane traffic need not be congruently routed. This is one distinguishing feature that does not apply to traditional IP connectionless (CNLS) networks. More importantly however, the user-plane is transparent, connection-oriented (CO) and has no practical buffering. In essence, the OTN user-plane is completely agnostic regarding the type of traffic it carries (indeed this is also true of other layer 1 technologies such as SDH/SONET, which can support ATM, IP, PDH etc, encapsulated within fixed length frames). A key feature of a layer 1 user plane is its ability to accommodate large administrative bandwidth entities and have the flexibility to accommodate new client layer networks as they are introduced. These client layer networks may or may not be customer application interfacing. Given the CO and client-agnostic nature of the OTN, one cannot logically draw the conclusion that a set of control-plane protocols which were originally developed to suit a CNLS environment are the 'right choice' for the control plane of an OTN. Indeed, the only valid justification for this is the re-use of an existing set of protocols, which can save development effort. Based on this argument, one would then have to ask why other control plane protocols developed for a CO environment should not be used? We have not seen any evidence that such an analysis has been carried out. Aside from the IETF, work is underway on optical control issues in the ITU-T with the development of G.ason [4], and the OIF Carriers Group have recently produced a requirements capture for the optical UNI or User-Network Interface [5]. Both of these bodies are generally taking a protocol independent approach of requirements capture, with the goal of producing an architectural framework that any suitable control protocols should be able to meet. As such, this work is a useful foundation for work in the IETF. 3. TYPES OF CONNECTION Freeland et al 3 Considerations on the Development of an Optical Control Plane November 2000 The OTN must ultimately be able to support the following types of connections: A permanent optical channel set up by the network management system via network management protocols (requires access to a database model of the network topology. This approach has traditionally been centralised, but need not be for the OTN). A soft permanent optical channel set up by the network management system, using network generated signalling and routing protocols to establish connections (this requires a defined NNI - note that these connections cannot be set up by a user, and in particular, do not require a UNI). A switched optical channel, which can be set up by the customer on demand using signalling and routing protocols (requires naming and addressing schemes and a UNI/NNI). The OTN may support one or more of the above types of connection at any given time in its evolution. The types of connection required will initially be permanent optical channels, with a migration over time towards switched optical channels (although both may coexist). The intent is therefore to reuse features that are common to more than one type of connection - minimising the impact on existing networks and their operational procedures and support systems. 4. CARRIER OPERATING MODELS The development of a control plane will ultimately be set within the context of an operator's business model. Four main operating models can be envisaged for an optical transport network. These are: (a) ISP owning all of its own infrastructure (i.e including fibre and duct to the customer premises). (b) ISP leasing some or all of its capacity from a third party. (c) Carriers carrier providing layer 1 services. (d) Service provider offering multiple layer 1, 2 and 3 services over a common infrastructure. For some of these models the concept of a unified, single control plane may seem attractive (especially for option (a)). However, it is unlikely that just one of these models will apply to any operator, and the model that is appropriate will change depending on the application. It should also be noted that very few, if any, ISP's own all of their own infrastructure - most have to lease. Further, unless they lease they will have a very restricted market, since no operator has total global coverage 'to the duct'. Furthermore, as one considers the SME/mass-markets then peering across NNI's with other operators will be the normal mode of working, and NOT the exception. Freeland et al 4 Considerations on the Development of an Optical Control Plane November 2000 One aspect of concern when inter-working is the type of information that may be conveyed between operators. Generally this will be restricted to requests for service. This also suggests a clear distinction between types of NNI - for example an NNI between operators, and an NNI within a particular operator's administrative domain. A carrier's carrier at layer 1 only provides support for layer 1 services and its topology/resource is invisible to users of the network at higher layers. In such a network all-optical cross- connects with optical drop and insert but no access to client layers are not visible to the client. Finally, the need for an optical network to support multiple types of client layer networks introduces a number of considerations. Different types of client layer networks may have completely different control planes. If more than one client layer network is transported, it possible that each client will use a different addressing scheme. De-coupling the client layer control plane from the OTN control plane ensures that different client addressing schemes can be supported. Furthermore, this will ensure that future client layers need not be hampered by legacy technology. The development of a control plane for the optical network that is separate and distinct from any client layer(s) allows for the existence of all of these business models. The authors therefore recommend that the optical layer control plane should be independent of any particular client layer. Note that none of the above discussion places any restrictions on the particular protocols that may be used for the OTN control-plane implementation. It merely suggests separate instances of client and server layer control planes, and as such does not preclude the re- use of existing protocols. 5. OPTICAL CONTROL REQUIREMENTS A control plane consists of four main facets: - an addressing scheme; - a signalling network that provides communication between entities requesting service and entities that provision those services; - a signalling protocol for the set-up, maintenance and tear-down of trails; - a routing process to handle topology/resource usage and route calculation (this does not necessarily imply that an automated routing protocol is the right approach in all cases however). 5.1 Addressing Freeland et al 5 Considerations on the Development of an Optical Control Plane November 2000 The number of trails per second that are set up in the OTN (indeed traffic volumes in general) is likely to be at least equivalent to what carriers currently have with SONET/SDH. The optical control plane can therefore initially be expected to receive requests to set up hundreds of trails per day per domain, with the potential to scale to many more in the future. The OTN control pane should therefore be designed to support in the region of tens of thousands of connection requests per day. It follows that the OTN must have a scalable naming and addressing scheme, capable of meeting expected demand for new names and addresses over decades to come. The benefits of the above cannot be achieved unless lead times/provisioning for delivery of capacity are dramatically reduced however. It is therefore essential that such a network provides tools for capacity management, utilisation, statistics on failed call attempts, plan and build facilities, providing ordering triggers, and dealing with long term localised congestion. A large proportion of carriers will require their OTN's to be multi- client environments. This is evidenced through a number of carrier contributions to various standards forums. The reasoning is that, despite the fact traffic forecasts for the next few years do indeed show IP traffic continuing to dominate networks worldwide, non-IP traffic will not be inconsequential and therefore cannot be ignored. One of the most important issues therefore relates to the addressing scheme used in the server OTN and the various client networks. Multiple client (e.g. ATM, PSTN, IP) layer addressing schemes must be supported, therefore server OTN layer addressing should be disjoint from any client layer addressing to ensure a true multi- client server network. This does not imply that the same type of addressing cannot be used in both client and optical layer control planes - it simply means that both schemes must be disjoint from one another. This would also be in conformance to RFC 1958 [6], which mandates exactly the same principle by requiring that "the internet level protocol must be independent of the hardware medium and hardware addressing" and that "this approach allows the internet to .. decouple it's addressing mechanisms from the hardware". 5.2 Signalling The design of a signalling network and its associated interfaces are important issues for the optical control plane. The choice of channel and transmission media for the network must be appropriate to optical networks, and indeed any other layer 1 networks. If signalling is always carried along the same physical link as the actual traffic, a failure in that physical link will usually take out the control plane as well as the user plane between the Freeland et al 6 Considerations on the Development of an Optical Control Plane November 2000 particular nodes. However, the signalling network does not have to have the same physical topology as the traffic network - and indeed a separate diverse topology has both functional advantages and can be made more reliable (as a function of its own topological design and its failure behaviour). In general, the control plane network must always be more reliable than the user plane traffic network. Signalling can either be carried in a channel associated or common channel fashion. Channel associated signalling is a very simple method used for early digital transmission systems, where a limited number of signalling bits were added to the frame structure (which also contained the associated traffic channel - i.e. the user-plane and the control-plane share a common routing). This simplicity meant the technique could not be extended to signalling for advanced service features such as CLI, call waiting, etc (which are found in the PSTN/ISDN). On the other hand, it is desirable for common channel signalling to use message-based structures within a channel that is usually not congruently routed with the associated user-plane traffic. Although slightly more complex to design, common channel signalling has proven to be easier to update and modify as new service requirements emerge. Common channel signalling is therefore the universal choice for new systems. Common channel, channel associated, or a combination of both should be used where appropriate in the OTN. Interfaces within a control plane fall into two categories - client to server (known as the User-Network Interface (UNI)) and server to server (known as the Network-Network Interface (NNI)). There will be different flavours of UNI and NNI, however for the purpose of this section we will focus on the general requirements of the UNI and NNI. Common channel signalling is usually carried out-band, while channel associated signalling is not. For an optical transmission system, in-band signalling would result in a network where every signalling node would have to examine all of the data passing through it in order to find any signalling destined for it. This would be fine if every optical network element was opaque to the user plane (and this should be the case at a UNI), however there will be an increasing (over time) number of occasions where all-optical network elements (i.e. transparent to the user plane) are used within the OTN. Transparent optical nodes that cannot access in-band signalling information will therefore require an out-band data communications network (sometimes known as a dedicated optical supervisory channel). This certainly applies to nodes within the OTN (i.e. NNI's), however it will be possible to ensure that network elements at the ingress and egress points of the network are opaque to the user plane (i.e. perform optical-electronic-optical conversions, and can therefore Freeland et al 7 Considerations on the Development of an Optical Control Plane November 2000 easily access in-band signalling). Signalling for a UNI may therefore be out-band or in-band. Both UNIs and NNIs should be capable of supporting dynamic `dial up' wavelength requests. For the UNI these requests will be client initiated (for example from an IP router, ATM switch, or a client layer network within the same network element), and for the NNI these requests will be OTN initiated (for example from another carriers' optical network element). The requesting party must first specify the optical trail parameters required (e.g. protection level, bandwidth, availability). It should be noted these service level parameters require further study. The optical control interface should support CAC (Connection Admission Control). CAC should include authentication and permissibility of the user, and verification of service level parameters. It should also support billing systems as necessary, and provide a secure interface between the OTN and it's various clients. Every ingress node to the optical transport network should therefore support CAC functionality, and inform the requesting party of whether or not the circuit request has been successful. In the event of an unsuccessful attempt, the requesting party should be informed of the particular reasons why the request was rejected (i.e. network busy, fault, etc). Signalling shall be achieved using a message-based protocol rather than a bit-based protocol with framing (as in SONET/SDH), since this allows for simple extensions. The interfaces should support a number of typical signalling messages such as requests for the set-up of connections, requests for the removal of connections, accept or reject particular requests, query connection attributes, etc (though as noted above these service request parameters require further study). It is important to note that any new service requests should not affect existing user plane traffic connections. All of the signalling requirements discussed in this section should be supported by a candidate signalling protocol and should be capable of being implemented in both a point-to-point fashion for simple client-server communications, and a point to multi-point fashion in order to support multicast client-server applications. 5.3 Routing The OTN will consist of a number of administrative domains, owned by different carriers. Here we must make a distinction over NNI's between different optical entities in different administrative domains, and NNI's between optical entities within an administrative domain. It should be noted that an automatic routing protocol may not always be needed. For the purposes of this paper, we will however assume that an automatic routing protocol is to be used. Freeland et al 8 Considerations on the Development of an Optical Control Plane November 2000 As well as the basic ability of route computation (e.g. finding the 'shortest' or 'constrained shortest' path to a particular destination), dynamic routing protocols can have the additional functionality of resource discovery. This has the advantages of allowing the control plane to react dynamically to changes in network state/loading, maintain up to date routing tables, and (in certain scenarios) give a particular node full visibility of network topology and available resource within it's domain. In contrast to higher layer networks, the OTN will consist of elements that will grow to the order of a thousand or more ports (either in the wavelength domain or as physical interfaces). This implies a larger number of links between neighbouring network elements, and a greater number of adjacencies. Routing and topology discovery protocols must therefore be able to scale in order to support such network elements. In the context of the OTN, resource discovery would only be supported at NNI's within a carrier's administrative domain. Carriers will not allow another carrier or private domain visibility of either topology or resource (and certainly not resource control). Therefore topology/resource discovery is unlikely to be supported between different administrative domains. There may of course be instances where there is high degree of trust between carriers, but this would be a rare exception rather than the rule. In this situation, the two parties may choose to use a standard NNI, or a specific 'friendly' and proprietary NNI (which is outside the scope of standardisation activities). As well as not being supported at an NNI between different administrative domains, topology/resource discovery is unlikely to find favour between an optical network element and a particular client of the OTN (unless the carrier owns ALL of its clients as well). Along with the justification given in section 4.1 for disjoint addressing across client and server layers, this reinforces the requirement that the control plane for the optical layer should be independent of any particular client. 5.4 Other issues The basic and first to be standardised service for the optical control plane should be a simple bi-directional point to point connection - with a fixed grade of service and fixed bandwidth. This service is the simplest to provision and initial development should therefore focus on it. In the absence of protection/restoration mechanisms, once a connection is dropped it will only be re-established by means of a further connection attempt. This may or may not be automated. Freeland et al 9 Considerations on the Development of an Optical Control Plane November 2000 Resilience issues must also be considered. The optical control plane will be required to handle error detection/correction, and flow control mechanisms for restricting the transmission of signalling packets where appropriate (in other words, the OTN control plane will need its own OAM). Focus here should initially be restricted to the control plane, however there will be requirements to develop these mechanisms for the user plane. As discussed previously, the network for the control plane need not be co-incident with that of the user plane. Indeed this would improve resilience in the signalling network. The optical control plane should in general be as robust and reliable as possible. In the event of a signalling failure, the connection in the user plane must not be affected. The ability to change the topology of the client layer network both quickly and flexibly (i.e. client layer links = server layer trails) will bring a new dimension to traffic engineering (TE). Perhaps even obviating much of the need for TE within a client layer network. Topology distribution information must include sufficient parameters to enable traffic to be balanced across available links in the OTN (for example, percentage loading on the link). Finally, the optical control plane must be secure enough to ensure that the integrity of the OTN is not compromised, and that 'illegal' service requests are dealt with in the appropriate manner. This should be implemented by an appropriate CAC function. 6. CONCLUSIONS In this paper we have covered some general requirements for the control plane of an OTN. The following is a summarised list of protocol independent requirements that any candidate control plane for the OTN should be capable of supporting. This list is by no means exhaustive, and as well as reserving the right to add to or modify these recommendations, the authors encourage both open discussion of them and suggested additions to the list. - The OTN must allow a multi-client environment. - The OTN layer control plane should be independent of any particular client layer control plane. - A naming and addressing scheme for the OTN control plane must be scalable for decades to come. - Addressing must be disjoint across client and optical layers. - The OTN control network must be as robust and reliable as possible. - Message based signalling should be used for OTN control. - 'Modify' signalling messages must be non-traffic affecting. - Signalling failures must be non-traffic affecting. - NNI's must use out-band signalling. - UNI's may use in-band or out-band signalling. - Desirable connection parameters should be specified by the client Freeland et al 10 Considerations on the Development of an Optical Control Plane November 2000 at the UNI (e.g. protection level, availability, etc). These require further study. - Ingress optical nodes must support CAC functionality. - CAC functionality should include user authentication & permissibility, billing, security, and verification of service level parameters. - Ingress optical nodes must inform the client of whether the connection request has been successful. - Ingress optical node should inform the client of the reason(s) behind an unsuccessful connection attempt. - Point to point and point to multi-point client dial-up should be supported across a UNI. - The optical control plane should handle error detection/correction and flow control (i.e have its own OAM). - OAM focus should initially be restricted to the OTN control plane (however there will be requirements to develop OAM for the OTN user plane). - Routing & topology discovery protocols must be able to scale to support optical network elements with the order of a thousand or more ports. - Resource/topology discovery should not be supported between administrative domains. - Resource/topology discovery should not be supported at an UNI (i.e. the client should not have direct visibility/control over the OTN resources). - Resource/topology discovery may be supported at an internal NNI (i.e. within an administrative domain). - Topology distribution parameters should support TE for the optical layer. - Simple bi-directional point to point connection should be the first service to be standardised (fixed bandwidth & fixed grade of service). - Control plane requirements should be supported regardless of whether optical network elements are transparent or opaque to the user plane. 7. SECURITY CONSIDERATIONS A key security consideration has been discussed in this draft regarding routing protocols with topology/resource discovery capabilities running at the boundaries of operator's administrative domains. This would be unacceptable to the vast majority of operators. To alleviate security issues, it has therefore been recommended that resource discovery must not be supported at the boundaries of administrative domains, and additionally that separate control planes are implemented for both the client layer and OTN server layer. Future revisions of the document may consider other security issues. Freeland et al 11 Considerations on the Development of an Optical Control Plane November 2000 8. REFERENCES [1] IP over Optical Networks: A Framework, Bala Rajagopolan et al, Internet Draft, draft-many-ip-optical-framework-01.txt, Work in Progress, July 2000. [2] Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control With Optical Crossconnects, Dan Awduche et al, Internet Draft, draft-awduche-mpls-te-optical-02.txt, Work in Progress, July 2000. [3] Generalized MPLS: Signaling Functional Description, Peter Ashwood-Smith et al, Internet Draft, draft-ietf-mpls-generalized- signaling-01.txt, Work in Progress, November 2000. [4] Architecture for the Automatic Switched Optical Network (ASON), First draft of G.ason, ITU-T Study Group 13, Work in Progress, March 2000. [5] Carrier Optical Services Framework and Associated Requirements for UNI, OIF Carrier Group, T1X1.5 liason document, Work in Progress, October 2000. [6] Architectural Principles of the Internet, RFC 1958, B.Carpenter, IAB, June 1996. 9. Author's Contact Details Darren Freeland BTexaCT Email: darren.freeland@bt.com Neil Harrison BT/Ignite Email: neil.2.harrison@bt.com Sergio Inglima BTexaCT Email: sergio.inglima@bt.com Keith James BTexaCT Email: keith.a.james@bt.com Alan McGuire BTexaCT Email: alan.mcguire@bt.com Shehzad Mirza Freeland et al 12 Considerations on the Development of an Optical Control Plane November 2000 BTexaCT Email: shehzad.mirza@bt.com Stewart Ritchie BTexaCT Email: stewart.ritchie@bt.com Mel Robinson BT/Ignite Email: mel.robinson@bt.com Ali Salman BTexaCT Email: ali.salman@bt.com Peter Willis BT CTO Email: peter.j.willis@bt.com Freeland et al 13