Network Working Group Osama Aboul-Magd (Nortel Networks) Internet Draft Curtis Brownmiller (WorldCom) Expiration Date: December 2001 Sudheer Dharanikota (Nayna Networks) Naganand Doraswamy (PhotonEx Corp.) John Drake (Calient Networks) Georgios Ellinas (Tellium) Rohit Goyal (Axiowave Networks) Riad Hartani (Caspian Networks) Bilel Jamoussi (Nortel Networks) John Labourdette (Tellium) Jonathan Lang (Calient Networks) Eric Mannie (Ebone (GTS)) Babu Narayanan (Nortel Networks) Dimitri Papadimitriou (Alcatel IPO-NSG) Bala Rajagopalan (Tellium) Rajiv Ramaswami (Nortel Networks) Vasant Sahay (Nortel Networks) Ed Snyder (PhotonEx Corp.) Yong Xue (UUNET/WorldCom) Editor: Andre Fredette (PhotonEx Corp.) June 2001 TITLE: Optical Link Interface Requirements draft-many-oli-reqts-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [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. [Page 1] Internet Draft draft-many-oli-reqts-00.txt June 2001 ABSTRACT The emergence of transparent optical switches, together with a movement towards more dynamic, multi-vendor networks, has introduced a need for information sharing between optical line systems and client devices. The information that needs to be shared includes link status and link properties. We call this interface the Optical Link Interface (OLI). In this document, we provide high-level requirements for the OLI. CONTENTS ABSTRACT...........................................................2 CONTENTS...........................................................2 SUMMARY FOR SUB-IP RELATED INTERNET DRAFTS.........................3 1. Introduction and Overview.......................................5 2. Fault Detection and Notification for PXCs.......................7 3. Discovery of Link Properties....................................7 4. Requirements for the Optical Link Interface.....................8 4.1. OLI General Principles........................................8 4.2. General OLI Characteristics...................................9 4.3. OLI Functionality.............................................9 4.3.1. Neighbor Discovery..........................................9 4.3.2. Control Channel Maintenance................................10 4.3.3. OLI Synchronization........................................10 4.3.4. Connectivity Discovery.....................................10 4.3.5. Fault Management...........................................10 4.3.5.1. Fault Notification.......................................11 4.3.5.2. Trace Monitoring.........................................11 4.3.5.3. Alarm Suppression........................................12 4.3.6. Link Property Information..................................12 5. References.....................................................14 6. Author Contact Information.....................................15 [Page 2] Internet Draft draft-many-oli-reqts-00.txt June 2001 SUMMARY FOR SUB-IP RELATED INTERNET DRAFTS (Section Requested by Bert and Scott) The emergence of transparent optical switches, together with a movement towards more dynamic, multi-vendor networks, has introduced a need for information sharing between optical line systems and client devices. The information that needs to be shared includes link status and link properties. We call this interface the Optical Link Interface (OLI). In this document, we provide high-level requirements for the OLI. This work is motivated by two main issues. The first is the need to enhance the fault detection and recovery support for photonic switches (PXCs), and the second is to enhance the discovery of link characteristics for optical networks in general. These issues are discussed separately in this document. We then provide more specific requirements for an interface between the optical line system (OLS) and OLS client proposed to solve these issues called the Optical Link Interface (OLI). NOTE: This document was requested by the CCAMP co-chairs based on discussions regarding the below mentioned drafts at the last two IETF meetings. RELATED DOCUMENTS http://www.ietf.org/internet-drafts/draft-fredette-lmp-wdm-01.txt http://www.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mpls-lmp-02.txt WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK A protocol that would satisfy the OLI requirements would fit in the Control part of the sub-ip work. WHY IS IT TARGETED AT THIS WG An OLI would enhance the ability of circuit switches and routers using MPLS-based control protocols to dynamically discover link properties and to learn about link status. The link properties can be useful during signalling of paths, and the link status information is essential for fault detection and recovery. Furthermore, the OLI is independent of any signalling protocol, so it can be used by both distributed control system, such as GMPLS, and centralized management systems. Therefore, an OLI would support the following CCAMP objectives: [Page 3] Internet Draft draft-many-oli-reqts-00.txt June 2001 . Define signalling protocols and measurement protocols such that they support multiple physical path and tunnel technologies (e.g. O-O and O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE) using input from technology-specific working groups such as MPLS, IPO, etc. . Define signalling and measurement protocols that are independent of each other. This allows applications other than the signalling protocol to use the measurement protocol; it also allows the signalling protocol to use knowledge obtained by means other than the measurement protocol. . Abstract link and path properties needed for link and path protection. Define signalling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi- layer path protection and restoration functions are achievable using the defined signalling and measurement protocols, either separately or in combination. . Define how the properties of network resources gathered by the measurement protocol can be distributed in existing routing protocols, such as OSPF and IS-IS. JUSTIFICATION draft-fredette-lmp-wdm-01.txt (lmp-wdm) and draft-sahay-ccamp-ntip- 00.txt (ntip) are both protocol proposals to satisfy the OLI requirements. lmp-wdm has been discussed in the past two ccamp sessions and ntip was discussed in the last one. There has been a great deal of interest in this work by both network operators and vendors. Given the competing proposals and some general questions about the specific requirements that the proposals were intended to solve, the CCAMP co-chairs asked the authors of lmp-wdm and ntip (and other interested people) to work together on a set of requirements. This document describes those requirements. [Page 4] Internet Draft draft-many-oli-reqts-00.txt June 2001 1. Introduction and Overview Optical networks being deployed today consist of the following three basic types of devices: service delivery platforms (e.g., routers, ATM switches, and SONET/SDH devices), optical switches (OXCs), and Optical Line Systems (OLSs), as shown in Figure 1. +-OLI-+ +-OLI-+ | | | | | +-------------------------+ | +----+ |+----+ OLS +----+| +----+ SONET--| |--|| | +---+ +---+ | ||--| |--SONET ATM--|OXC1|--||DWDM|=|Amp|=|Amp|=|DWDM||--|OXC2|--ATM Routerûû| |--|| 1 | +---+ +---+ | 2 ||--| |--Router | +----+ |+----+ +----+| +----+ | | | | +-------------------------+ | | | | | | | | | +-LMP-+ +---------------LMP---------------+ +-LMP-+ Figure 1: Optical Network Before continuing, a few definitions are provided to describe salient information about the above network. . Opaque Device: A device that terminates a connection electrically. An opaque device is sometimes called an O-E-O device because it receives an optical signal, converts it to an electrical signal, then regenerates a new optical signal. It is also usually must be aware of the type of traffic and bandwidth being carried and has a specific physical interface for that type of traffic and bandwidth. An example is a SONET or SDH device. . Transparent Optical Device: A device that transmits/propagates an optical signal without terminating it. These devices are sometimes referred to as O- O-O devices, because they receive an optical signal, switch it optically, then transmit the same optical signal without ever converting it to an electrical signal. An example is a MEMS- based photonic switch in which both the interfaces and switching fabric are transparent. Transparent devices, in theory, can operate independent of traffic type and bandwidth. . Optical Cross Connect (OXC): A cross connect that switches optical connections. The term OXC is used as a generic term that may apply to both opaque and transparent devices. Whenever the material applies to both opaque and transparent devices, we use the term OXC, as opposed to the more specific PXC term defined below. [Page 5] Internet Draft draft-many-oli-reqts-00.txt June 2001 . Photonic Cross Connect (PXC): A transparent OXC. An example is a MEMS-based photonic switch in which both the interfaces and switching fabric are transparent. Whenever the material in this document applies specifically to transparent devices, we used the term PXC, as opposed to the more generic term OXC defined above. . Optical Line System (OLS): An optical line system is used to transmit data over long distances. There are various classes including long-haul, ultra-long haul, metro, however, we do not differentiate between the classes in this document. Most OLSs being deployed today use wave division multiplexing (WDM), or dense division multiplexing (DWDM) techniques to multiplex many channels over a single pair of fibers. Therefore, the OLS is also commonly referred to as a DWDM transmission system. An OLS typically contains multiple types of nodes including DWDM and Optical Amplifier (OA) nodes. Although an OLS contains multiple nodes, they work as a single system, and for the purposes of this document, we treat the OLS as a single system. Note that an OLS may be either opaque or transparent, however, in this document we only address opaque OLSs. . OLS Client: Any device that attaches to an OLS for the purpose of using its data transmission services. An OLS client may be either opaque or transparent. In Figure 1, the OXC is shown as an OLS client with the service delivery platforms connected to the OXC; however, the service delivery platforms may also be direct OLS clients. Whenever the material in this document applies to any OLS client, we use this most general term. . Link: The term link refers to a circuit or logical connection between two peer OLS clients. The OLS transmits the data on a link between the two peer OLS clients. A link may be uni- directional or bi-directional. . Port: Place where an OLS client attaches to an OLS. A link requires that both OLS clients are attached to corresponding ports on the OLS. This work is motivated by two main issues. The first is the need to enhance the fault detection and recovery support for PXCs, and the second is to enhance the discovery of link characteristics for optical networks in general. These issues are discussed separately below. We then provide more specific requirements for an interface between the OLS and OLS client proposed to solve these issues called the Optical Link Interface (OLI). [Page 6] Internet Draft draft-many-oli-reqts-00.txt June 2001 DISCLAIMER: The name ôOLIö, introduced in [OIF2000.254], has been chosen due to the lack of a better name at this time. Not all of the co-authors agree on the name OLI. 2. Fault Detection and Notification for PXCs Standard SONET/SDH equipment provides extensive fault detection, reporting and handling capabilities. These SONET/SDH standards can be employed by opaque devices using SONET/SDH overhead messaging; however, as networks transition to the use of more transparent optical networking devices, such as PXCs, access to the SONET/SDH overhead may not exist in every node. Once a connection is established, PXCs have only limited visibility into the health of the connection. Even though the PXC is all-optical, an opaque OLS terminates channels electrically and regenerate them optically, which presents an opportunity to monitor the health of a channel between PXCs. The elements of an OLS also typically communicate over an internal control channel. This can provide a system wide view of OLS client-to-client link health. In a sense, the OLI allows the OLSs to become the ôeyes and the earsö of the PXC. The typical OLS located between a pair of PXCs monitors for degradation and faults along the entire fiber path. Expensive electronic circuitry monitors such degradations at the SONET/SDH and wavelength level at various points along the fiber path. Repeaters and Amplifiers detect fiber cuts and pass along the information to other equipment along the path. SONET/SDH-level failures can be detected as well. To use the SONET/SDH-level fault reporting methods, all devices require the expensive electronic circuitry. A PXC can avoid the use of SONET/SDH circuitry to provide a more cost effective solution. In this perspective, an OLI between the OLS and PXC can provide the same fault information to a non-SONET/SDH client, while reducing the cost of that client, and, therefore overall network cost. 3. Discovery of Link Properties The establishment of connections in an optical network may be accomplished either through a centralized management system or a distributed control system, such as GMPLS. A great deal of information about a link between two clients is known by the OLS. Exposing this information to the control plane can improve network usability by further reducing required manual configuration and also greatly enhancing fault detection and recovery. [Page 7] Internet Draft draft-many-oli-reqts-00.txt June 2001 The configuration and management of todayÆs transport networks are largely driven by significant human intervention, which increases the time to turn up revenue generating services and is prone to errors and inefficiencies. Even where management systems provide automation for some provisioning and management tasks, the management systems are still largely proprietary and cumbersome. Furthermore, optical networks are more commonly being deployed with equipment from multiple vendors which further burdens the user with multiple management systems. A standard interface between the OLS and its clients can simplify the users job by allowing some provisioning functions to be accomplished by just the client management application. The Generalized Multi-protocol Label Switching (GMPLS) body of work [GMPLS-ARCH] is being specified in the IETF to provide a standard automated and distributed IP control plane for optical networks. The use of GMPLS will enable the dynamic provisioning of resources and provide network survivability using protection and restoration techniques. The main intent of GMPLS is to make optical networks more manageable, scalable and efficient, while maintaining or improving on their current high availability characteristics. GMPLS protocols define standard control interfaces between service delivery platforms and OXCs to exchange routing [GMPLS-OSPF, GMPLS- ISIS] and signaling [GMPLS-SIG, GMPLS-RSVP, GMPLS-LDP] information, and perform link management functions [LMP]. An interface with the OLS can allow GMPLS devices to automatically learn information about the links, and therefore, will reduce required manual configuration. 4. Requirements for the Optical Link Interface In this section we define more specific requirements for an Optical Link Interface (OLI) between the OLS and its clients. As described above, the OLI is required to provide fast failure detection and notification for PXCs, as well as to provide much-needed information for the operation of both centralized and GMPLS-controlled optical networks. 4.1. OLI General Principles . In optical networks there will be a management plane and a control plane. The fundamental purpose of the control plane is to accurately and rapidly create, maintain, and delete connections within the optical network; while the purpose of the management plane is to provide operators with capabilities such as root cause analysis, service definition, and SLA verification. The OLI is targeted at the information that is required for the control plane to accomplish its task. [Page 8] Internet Draft draft-many-oli-reqts-00.txt June 2001 . The OLI should be a simple protocol mechanism for reporting the health and properties of OLSs based on a well-defined set of parameters. . The OLI-defined parameters should be accessible via query by both the control and the management plane of the network regardless of the architecture used (i.e., distributed or centralized). . The OLI should be extensible so that we can start with a set of most-needed parameters initially, and be able to extend later by adding new parameter types and new parameters within a type. In particular, the initial focus is on opaque OLSs. However, the OLS should be extensible for use with all optical networks containing PXCs and transparent OLSs. . The initial focus of the OLI is on SONET and SDH equipment. However, the OLI must be extensible to support other types of equipment such as Ethernet and G.709. . All the intelligence such as data collection, analysis, triggering, routing decisions, etc. should reside in the network control and management plane functions. What and how the OLI-parameters are used is totally up to the control and management plane design. In effect, this will allow OLI to be decoupled from any particular control plane protocol such as GMPLS. . In general, care must be taken to make the OLI implementable on existing OLS hardware, while still being flexible enough to allow enhanced operations with future generations of OLS hardware. This desire may make it necessary to specify some optional OLI features. 4.2. General OLI Characteristics . The OLI must be reliable. . The OLI must provide security measures. . The OLI must not assume a one-to-one relationship between OLS and client. I.e., an OLS client will most likely be attached to multiple different OLSs, and a single OLS may have multiple different clients at a single location. 4.3. OLI Functionality 4.3.1. Neighbor Discovery [Page 9] Internet Draft draft-many-oli-reqts-00.txt June 2001 . It should be possible for adjacent nodes to use the OLI with as little configuration as possible. . The OLI should support discovery and negotiation of optional features. 4.3.2. Control Channel Maintenance . The OLI must support the use of out-of-band communications for all messages (except for the specific in-band signals for connectivity discovery described in Section 4.3.4). . The OLI must provide a mechanism to maintain the OLI session/control channel between neighboring nodes. For example, a simple hello or keep-alive protocol could be used. If a session fails it should be reestablished and the information should be resynchronized as described in Section 4.3.3. 4.3.3. OLI Synchronization . The OLI must specify a process for the OLS and OLS client to resynchronize if the session is disrupted for any reason (such as a reboot or temporary loss of control channel connectivity). . The resynchronization process should be defined such that the OLS does not need to remember the instructions issued by the OLS client. The client should re-issue the instructions/commands to OLS during the resynchronization. 4.3.4. Connectivity Discovery . The OLI must provide a protocol including in-band signals for auto discovery of optical connectivity. . The OLI must support control over link transparency. Link transparency control is used by OLS clients to control whether the OLS terminates the in-band messages, or allows them to pass through so that the OLS client can discover its peer at a higher layer. 4.3.5. Fault Management . Fault reporting must be both event-driven and available on request (e.g., polling). . The defect notification must be fast enough to support switch times in the range of a few 10Æs of milliseconds. [Page 10] Internet Draft draft-many-oli-reqts-00.txt June 2001 Note: The OLS does not participate in end-to-end fault isolation. It is the role of the control plane to determine whether switching is done on the section or path level and to make the protection switching decisions. . The OLI should support the aggregation of fault reporting. For example, the failure of a single fiber could cause the failure of 100Æs to 1000Æs of ports simultaneously. If possible, it would be better to send a single message to report all failures. 4.3.5.1. Fault Notification At a minimum, the following fault granularity must be provided: . Signal Okay (OK): Port is operational. . Signal Fail (SF): A hard signal failure including (but not limited to) loss of signal (LOS), loss of frame (LOF), Line AIS, or a BER (BIP-8 measure through B1/B2) exceeding a specified value. . Signal Degrade (SD): A soft failure caused by a BER exceeding a preselected threshold. The specific BER used to define the threshold is may be configured, but is typically in the range of 10-5 to 10-9. . It should be possible to negotiate a line behavior for the above failures. For example, it may be more advantageous to a PXC for the OLS to turn off its laser than to insert AIS-L when a failure is detected. . It is expected that the thresholds necessary (e.g., BER) for detecting the above failures are provisioned at the OLS. It may also be useful to support the negotiation of some of these thresholds. 4.3.5.2. Trace Monitoring Trace monitoring is an important feature, especially for PXCs. The trace monitoring features described in this section, allow the PXC to do basic trace monitoring on circuits by using the capabilities on the attached OLSs . It must be possible for an OLS Client to request the OLS to monitor a link for a specific pattern in the overhead. An [Page 11] Internet Draft draft-many-oli-reqts-00.txt June 2001 example of this overhead is the SONET Section Trace message transmitted in the J0 byte. If the actual trace message does not match the expected trace message, the OLS must report the mismatch condition. . It must be possible for an OLS client to request the value of the current trace message on a given port. . It should be possible for an OLS client to request the OLS to insert a trace message. It is optional for an OLS to provide this service. 4.3.5.3. Alarm Suppression . It must be possible to enable a port in an unequipped state on an OLS, but suppress alarms. This allows the OXC to have a port/wavelength ready, but not necessarily operational. 4.3.6. Link Property Information The link property advertisement provides information known to transport systems that would otherwise need to be configured at the OLS client. Link properties, in general, constitute the information needed by the control plane for constraint-based routing and connection establishment. Additionally, the information advertised in the Link Property advertisement is intended to be more-or-less static, as opposed to the more dynamic information available in the Performance Information Advertisement described in the next section. The OLI should provide a mechanism for advertising the following information: . Link Descriptor . Signal Type: The overhead termination type (e.g., STM-16 or OC-48). . Bandwidth Encoding: Bandwidth supported on the link. . Shared Risk Link Group Identifier (SRLG): SRLGs to which the link is a member. This information may be manually configured on the OLS by the service providers. It may also be derived based on information known to the OLS (e.g., all circuits sharing a single fiber). The SRLG can be used for diverse path computation. See [GMPLS-OSPF] or [GMPLS-ISIS] for more details on SRLGs. [Page 12] Internet Draft draft-many-oli-reqts-00.txt June 2001 . Span Length: Distance of fiber in the OLS. May be used as a routing metric or to estimate delay. This value may either be estimated by the OLS, or provisioned at the OLS. . Administrative Group (Color). [Page 13] Internet Draft draft-many-oli-reqts-00.txt June 2001 5. References [GMPLS-ARCH] E. Mannie, Editor, ôGeneralized Multi-Protocol Label Switching (GMPLS) Architectureö, Internet Draft, draft-many-gmpls-architecture-00.txt, (work in progress), February 2001. [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J., Bernstein, G., Fedyk, D., Mannie, E., Saha, D., and Sharma, V., ôIS-IS Extensions in Support of Generalized MPLSö, Internet Draft, draft-ietf-isis- gmpls-extensions-02.txt, (work in progress), February 2001. [GMPLS-LDP] Ashwood-Smith, P. et al, ôGeneralized MPLS Signaling - CR-LDP Extensionsö, Internet Draft, draft-ietf-mpls- generalized-cr-ldp-01.txt, (work in progress), February 2001. [GMPLS-OSPF] Kompella, K., et. al, ôOSPF Extensions in Support of Generalized MPLSö, Internet Draft, draft-kompella- ospf-gmpls-extensions-01.txt, (work in progress), February 2001. [GMPLS-SIG] Berger, L., Ashwood-Smith, Peter, editors, ôGeneralized MPLS - Signaling Functional Descriptionö, Internet Draft, draft-ietf-mpls-generalized-signaling- 02.txt, (work in progress), March 2001. [LMP] Lang, J., et. al, ôLink Management Protocol (LMP)ö, Internet Draft, draft-ietf-mpls-lmp-02.txt, (work in progress), March 2001. [LMP-WDM] A. Fredette, et al., ôLink Management Protocol (LMP) for WDM Transmission Systems,ö Internet Draft, draft- fredette-lmp-wdm-01.txt, (work in progress), March 2001. [NTIP] V. Sahay et al., ôNetwork Transport Interface Protocol (NTIP) for Photonic Cross Connects (PXC),ö Internet Draft, draft-sahay-ccamp-ntip-00.txt, (work in progress), February 2001. [OIF2000.254] Drake, J., Blumenthal, D., Ceuppens, L., et al., ôInterworking between Photonic (Optical) Switches and Transmission Systems over Optical Link Interface (OLI) using Extensions to LMPö, OIF Contribution oif2000.254, (work in progress), November 2000. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. [Page 14] Internet Draft draft-many-oli-reqts-00.txt June 2001 6. Author Contact Information Osama Aboul-Magd John Labourdette Nortel Networks Tellium osama@nortelnetworks.com jlabourdette@tellium.com Curtis Brownmiller Jonathan Lang WorldCom Calient Networks Curtis.Brownmiller@wcom.com jplang@calient.net Sudheer Dharanikota Eric Mannie Nayna Networks Ebone (GTS) sudheer@nayna.com Eric.Mannie@ebone.com John Drake Babu Narayanan Calient Networks Nortel Networks jdrake@calient.net bon@nortelnetworks.com Naganand Doraswamy Dimitri Papadimitriou PhotonEx Corp. Alcatel IPO-NSG naganand@photonex.com dimitri.papadimitriou@alcatel.be Georgios Ellinas Bala Rajagopalan Tellium Tellium gellinas@tellium.com BRaja@tellium.com Andre Fredette Rajiv Ramaswami PhotonEx Corp. Nortel Networks fredette@photonex.com rajiv@nortelnetworks.com Rohit Goyal Vasant Sahay Axiowave Networks Nortel Networks rgoyal@axiowave.com vasants@nortelnetworks.com Riad Hartani Ed Snyder Caspian Networks PhotonEx Corp. rhartani@caspiannetworks.com esnyder@photonex.com Bilel Jamoussi Yong Xue Nortel Networks UUNET/WorldCom jamoussi@nortelnetworks.com yxue@UU.NET [Page 15]