Internet Draft INTERNET DRAFT Larry McAdams Expires: September 2000 Cisco Systems <draft-mcadams-lightpath-attributes-00.txt> Jennifer Yates AT&T Labs - Research Lightpath attributes and related service definitions 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 This document specifies the attributes and related service definitions that may be associated with lightpaths in an optical network. The document is currently being developed within the Optical Internetworking Forum (OIF) and is being presented to the IETF for informational purposes. 1. Introduction The goal of this document is to specify lightpath attributes and their use in service definition. This draft has been created within the Optical Internetworking Forum (OIF) and submitted to the IETF as an informational draft. As such, the document uses OIF terminology, in particular, the draft refers to User to Network Interfaces (UNIs) and Network to Network Interfaces (NNIs). This terminology is not consistent with IETF terminology, and is in no way meant to imply a particular network architecture. McAdams, Yates [Page 1] draft-mcadams-lightpath-attributes-00.txt March 2000 The OIFÆs generic requirements for the Optical Internetwork [1] specify that a number of different types of clients must be supported; that rapid provisioning should be supported; that various levels of circuit protection be provided; that some form of mesh restoration be supported; and that a high level of manageability and provisioning flexibility be provided for SDH/SONET framed circuits. [1] defines the UNI as the interface between the optical network and a "client" to the optical network. It is required that the UNI be provisionable to support different types of services, protection levels, etc.; that a signaling method be provided between the client and the UNI that might be implemented in a number of ways (in-band, out-of-band, may or may not use SONET overhead bytes); that not all circuit types will support duplex in-band signaling; and that the UNI shall be specified so as to allow failure detection and localization (in or out of the Optical Network) and notification of the failure to the appropriate network management entities, and also continual verification of the integrity of the circuit. Adopting a unified protocol across both the optical network and its clients fundamentally enhances the flexibility of the control plane. Now, depending on the nature of the network and the service offered, both a client-server or overlay model (i.e. UNI) and a peer-to-peer model is possible (i.e. NNI). In some cases, the NNI may be simply viewed as an extension of the UNI. This is an issue outside the scope of this document. 2. Lightpath services The optical network is primarily offering high bandwidth connectivity in the form of lightpaths, where a lightpath is defined to be a fixed bandwidth connection between two network elements, such as IP routers or ATM switches, established via the optical network. The behaviors of the lightpaths are defined by their lightpath attributes. The definition of an atomic lightpath request needs to be discussed. In particular, whether the atomic lightpath request is for a single connection, or for multiple lightpaths, needs consideration. The simplest approach is to define the atomic lightpath request to be for a single lightpath. However, more flexibility might be achieved using a more complicated definition, in which multiple lightpaths may be simultaneously requested. 3. Lightpath operations The fundamental actions or operations related to a lightpath are: - request for a new lightpath - disconnection or teardown of an established lightpath - lightpath query (i.e. obtain current status information re: lightpath) - lightpath attribute change (i.e. change a parameter regarding an established lightpath û e.g. restoration requirements). McAdams, Yates Informational - Expires September 2000 [Page 2] draft-mcadams-lightpath-attributes-00.txt March 2000 4. Lightpath attributes A lightpath request, query, disconnect or attribute change has associated attributes. The following is a list of the attributes associated with a lightpath. It is envisioned that these attributes will be negotiated over the signaling channel between the client and the network. Many of the attributes are denoted as being required attributes, meaning that their definition is essential for the control plane operation. However, other attributes are optional. In some cases, not all of the attributes will be available, depending on the services offered and the equipment available. However, the UNI specification should not preclude any attribute. Connection-related attributes The first group of attributes are important in the connection establishment process and in ongoing capacity management and maintenance activities. Although these connection-related attributes are different and in many ways independent of the lightpath attributes used to describe the behaviors, they are included here because they are needed and the authors were not aware of their inclusion in any other relevant documents. If they are under discussion in other more appropriate documents they may be removed from this document and transferred to such related documents as appropriate. - globally unique end-to-end lightpath identifier: an identifier for the lightpath. This identifier may be assigned by either the client, or by the network. This is a required attribute in the sense that it must be known or derivable by the network. - client identifier: an identifier by which we can refer to the business entity which "owns" the lightpath. It could also identify a specific "virtual optical network" (analogous to IP VPNÆs) if the need arose. This is important for connection acceptance, billing, etc. It appears to differ from the information obtainable by end system discovery, which is focused on topological information. In some cases it may be derivable from port information. This is a required attribute in the sense that it must be known or derivable by the network. - security object: required for authentication, but could be closely related to the client identifier. The necessity and details of this needs further study. - desired availability period: the date/time when the lightpath is desired to be in service, and the earliest and latest date/time when the lightpath will be disconnected. The disconnect information is needed for capacity management; it might also be a factor in determining charges. It could be set to infinity. The inclusion of this attribute within the optical network as opposed McAdams, Yates Informational - Expires September 2000 [Page 3] draft-mcadams-lightpath-attributes-00.txt March 2000 to a higher layer management system should be further investigated. - destination address: the address of the destination to which the lightpath is to be established. It is proposed that this address be an IP address. However, it is unclear whether additional addressing schemes need to be understood by the optical network to handle non-IP aware equipment, such as ATM switches. Should the optical network understand multiple higher layer addressing schemes, or should the non-IP aware boxes (e.g. ATM switches) be assigned IP addresses by which they are referred to in the optical network? These IP addresses could be associated with the ports to which the clients are attached to the optical network. This is a required attribute. - destination port index: if individual ports are not given unique addresses, then a port index is required to identify them. The destination port index used by a lightpath may be assigned by either the client, or by the network. This is a required attribute. - destination sub-port index: when the network or end system allows multiplexing or switching at a finer granularity below the port level then the sub-port index is used to refer to specific channels below the port level. In future, more highly integrated systems there may be a need for additional levels of sub-port indexes. The destination sub-port index may be assigned by either the client or the network. This is an optional attribute. - source address: the address from which the lightpath is to be established. This is a required attribute in the sense that it must be known or derivable by the network. - source port index: similar to destination port index. The source port index may be assigned by either the client or the network. This is a required attribute in the sense that it must be known or derivable by the network. - source sub-port index: similar to destination sub-port index. The source sub-port index may be assigned by either the client or the network. This is an optional attribute. Physical attributes The next group of attributes relate to the physical and transmission characteristics of a lightpath. - framing type and use: the line protocol carried on the lightpath. Examples of such line protocols include SONET/SDH and Ethernet (GbE and 10GbE). This parameter may not be required in an optically transparent network. The proposed digital wrapper may allow some simplification of this attribute to the extent that it is used to encapsulate line protocols, but it cannot be assumed to be ubiquitous. This is a required attribute. McAdams, Yates Informational - Expires September 2000 [Page 4] draft-mcadams-lightpath-attributes-00.txt March 2000 Other attributes need to be associated with specific line protocols. For example, transparency and drop side protection attributes need to be associated with lightpaths established using SONET/SDH framing. transparency: Because of its ubiquity, SONET/SDH framing is particularly important. Three modes of operation that could be supported at the UNI are identified in [2]: Transparent: All SONET/SDH overheads would be transported unchanged. This would avoid interoperability problems with client signals using proprietary features or management techniques. Regenerator Section (SONET Section) Termination: AIS could be inserted, and a segment of a SDH MS Shared Protection Ring (SONET BLSR) could be transported. Protection would be limited to 1+1. Multiplex Section (SONET Line) and Regenerator Section Termination: The tributaries within a channelized facility could be routed separately, and the K1/K2 bytes would be available for use within the Optical Layer. M:N Linear Automatic Protection Switching could also be supported. Performance monitoring and fault handling for each of these options needs further study. This is a required attribute. drop side protection: This refers to protection between the client network element and the optical network. In the case of co- location, the choices would seem to be 0:1(unprotected), 1:N, M:N and 1+1. The non-colocated case needs further study. This is a required attribute. Similar attributes will need to be investigated / defined for other framing types. - capacity: bandwidth associated with the lightpath. For example, a lightpath used to transport SONET encoded signals may be configured to have OC-N capacity, or STS-M capacity. STS-1 granularity is suggested for SONET encoded signals, although this does not imply that a vendor has to implement such a granularity. This parameter may not be required in an optically transparent network. Asymmetric capacity might be provided by combining bi- directional and uni-directional capacity assignments; however this requires further study. This is a required attribute. - directionality: lightpaths may be either uni-directional or bi- directional. This is a required attribute. - priority and pre-emptability: this multi-level attribute determines a lightpathÆs treatment during restoration and provisioning events. This attribute would specify whether or not the resources used by a lightpath are reusable by other lightpaths in the event that there is insufficient capacity to handle a failure or the provisioning of a new lightpath with a higher priority. A simple, single level form of this attribute is required, while more McAdams, Yates Informational - Expires September 2000 [Page 5] draft-mcadams-lightpath-attributes-00.txt March 2000 elaborate multi-level forms are optional and may require further study. - protection and restoration: numerous possible definitions of protection levels exist. The simplest is to have a binary decision as to whether the lightpath is restored or not. At a finer granularity, different types of restoration can be specified. These need to be defined in terms of sub-attributes, such as: 1. restoration time, 2. what restoration capacity would be used (dedicated or shared, for example), 3. what restoration method should be used (e.g. mesh or BLSR, for example), 4. what failures are targeted (single link, single node, two links, ...), and 5. reversion strategy - does the lightpath get restored to its original route? An "optimal" available route? When? It is preferable that the definition of this attribute be functional (e.g., 100 mSec restoration time) rather than solution- specific (e.g., SONET BLSR). However, the above definition provides the ability for solution-specific restoration requirements. Maximum flexibility should be left for vendor and network operator innovation without requiring a standards change. A simple form of this attribute is required, while more elaborate forms will require further study. Routing attributes - relationships between lightpaths: various relationships may be defined between lightpaths. For example, a client may request that multiple lightpaths be diversely routed, that multiple lightpaths be routed along the same physical route, that multiple lightpaths be bundled together and treated as a single entity with a common set of attributes, or that a given lightpath be routed on the same route as an existing lightpath. Two lightpaths are diverse if they have no Shared Risk Link Groups in common (See [3] for more on Shared Risk Link Groups.) Diverse routing is frequently a requirement of sophisticated enterprise networks whose availability objectives may require that no single failure isolate a node or disconnect the network, for example. The diversity requirement for such a network is best expressed by a matrix, with element a{j,k} specifying whether lightpaths j and k must be diverse. This attribute requires further study. In particular, the definition of how multiple lightpaths may be bundled together requires further work. - specified routing: client specification for specific physical routing of a lightpath. This routing may be specified in terms of specific links or nodes which must/must not be traversed. McAdams, Yates Informational - Expires September 2000 [Page 6] draft-mcadams-lightpath-attributes-00.txt March 2000 Constraints such as the maximum delay or number of hops should also be supported. The delay is of particular importance. There are a number of ways to characterize delay. A simple metric is the total round trip delay; however it may be desirable to create a more detailed description of the temporal behavior. For example, in some cases, the differential delay between the incoming and the outgoing directions of the lightpath may be important. Finally, the change in delay caused by a protection event may also be important. In other words, it may be desirable to not only establish the temporal behavior of the primary lightpath, but also the temporal behavior of the lightpath after it has been restored, so that the delay is bounded on both the primary and restoration routes. Delay along a lightpath will be directly proportional to the route mileage of the lightpath, so it may be appropriate to formulate this constraint in mileage terms. This attribute requires further study. - client constraints: client constraints may have to be propagated across the UNI - particularly in all-optical networks without wavelength conversion available between the client and the network. In particular, information may have to be conveyed regarding the set of wavelengths accessible from the client and whether the client can re-tune its wavelengths in the face of a failure within the network. This parameter requires further investigation. 5. Summary This document specifies lightpath attributes and their use in service definition. 6. References [1] R. Bary, "Proposed Architecture Working Group Requirements Document," OIF contibution OIF2000.007. [2] J. Berthold, "Optical Internetworking Requirements for SDH Framed UNIs," OIF contribution OIF1999.161. [3] S. Chaudhuri, G. Hjßlmt²sson and J. Yates, " Control of Lightpaths in an Optical Network," IETF Internet Draft. 7. Author's addresses Larry McAdams Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134-1706, USA lmcadams@cisco.com +1 408 525 4628 McAdams, Yates Informational - Expires September 2000 [Page 7] draft-mcadams-lightpath-attributes-00.txt March 2000 Jennifer Yates AT&T Labs - Research 180 Park Avenue, Room B159 Florham Park, NJ 07932, USA jyates@research.att.com +1 973 360 7036 McAdams, Yates Informational - Expires September 2000 [Page 8]