CCAMP Working Group Jim Jones Category: Informational Dimitri Papadimitriou Expires: May 2002 Gert Grammel Alberto Bellato Alcatel November 2001 Summary of Work Related to Optical Link Interface Standardization draft-jones-ccamp-overview-oli-related-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 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt 1. Abstract This document presents an overview of contributions made in IETF, ITU-T and T1X1.5 pertaining to the Optical Link Interface (OLI) and related interfaces. The intent is to summarize for the IETF community the different approaches and corresponding interface and protocol specification under-construction in these different standardization bodies; this in order to provide the material during CCAMP WG meetings. Since the scope of this memo is not to replace in any case these contributions, we also strongly encourage the reader to refer to these contributions for more details. Notice since OIF contributions are regulated by privacy copyright related documents arenÆt referenced in this memo. Jim Jones et al. û Information Draft û Expires May 2002 1 draft-jones-ccamp-overview-oli-related-00.txt November 2001 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 [2]. 3. Introduction Existing contributions on OLI or related interfaces general fall into 2 types: - Requirements for interface to pass information between devices to provide information for fault/failure reporting, connectivity/ adjacency discovery. Some also propose information exchange for performance monitoring and protection switching. - Proposals for protocol extensions to provide such an interface. This document organizes and summarizes existing contributions into these categories. Before the summary is given, several discussion points are presented for use during the OLI discussions. The term OLI is not universally used, and T1X1.5 and ITU-T contributions refer to similar interfaces as Optical Supervisory Interface (OSI) or Virtual Backplane Interface (VBI). In any event, the interface of interest is between a passive device (OXC, PXC or optical fabric) and an active device (an Optical Line System or I/O port). Information is passed over this interface to the passive device by the active device, which terminates in-band signals of the data plane. OLI used in combination with LMP-WDM has been proposed as the protocol of choice by IETF during the London CCAMP WG meeting. However, IETF is seeking cooperation with other bodies T1/ITU-T in order to progress in this domain. 4. Requirement Contribution 1. Reference: draft-many-oli-reqts-00.txt, June 2001 (essentially the same as T1M1.3/2000-037) ôAbstract: We analyze the requirements event communications between the active and passive devices, which in turn can be used by the optical control plane. This function is to be defined in such that it works without an upper GMPLS layer. This document includes requirements that may be address by either LMP or OLI documents.ö This reference further defines - from abstract: ôThe information that needs to be shared (between optical line systems (OLSÆs) and OLS client devices) 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.ö Jim Jones et al. û Informational Draft û Expires May 2002 2 draft-jones-ccamp-overview-oli-related-00.txt November 2001 The purpose of this document is to define the needs of active systems to communicate with passive systems. This document separates the various requirements with the following goals in mind: - For active systems to monitor and communicate the status and configuration of different lambda(s), link(s) and equipment(s), which are not visible to the passive systems and communicate the status to the relevant parties. - Reduce the error detection and immediate reporting time to passive systems (State reporting only is required.) Monitored information reported via link management should only include degraded conditions that exceed SLAs. Document calls for information on: - Link State: Signal Failed, Signal Degrade, Operational, Unequipped Available, Unequipped Unavailable, Automatic Report Control - Link Configuration: such as Link Node Identification, Link Identification, Grade of Service It also calls for faster defect reporting time (few 10Æs of msec), attention to security and a reliable protocol. +-OLI-+ +-OLI-+ | | | | | +-------------------------+ | +----+ |+----+ OLS +----+| +----+ SONET--| |--|| | +---+ +---+ | ||--| |--SONET ATM--|OXC1|--||DWDM|=|Amp|=|Amp|=|DWDM||--|OXC2|--ATM Router | |--|| 1 | +---+ +---+ | 2 ||--| |--Router | +----+ |+----+ +----+| +----+ | | | | +-------------------------+ | | | | | | | | | +-LMP-+ +---------------LMP---------------+ +-LMP-+ Figure 1. Optical Network OLI is required to provide fast failure detection and notification for PXCs, and provide information for the operation of both centralized and GMPLS-controlled optical networks. OLI is targeted at the information required for the control plane to accomplish its task. Document presents requirement outline for: - General Properties: accessibility, extensibility, simplicity, independence from control plane) - General Characteristics: reliability, security, support for multiple OLSÆs) - Functionality: Neighbor/Adjacency Discovery, Control Channel Maintenance, Connectivity Discovery, Fault Management and Link Property Information 2. Reference: T1X1.5/2001-165: Introduction of new OTM interface: OTM-LF (Line-Fabric), June 2001 Jim Jones et al. û Informational Draft û Expires May 2002 3 draft-jones-ccamp-overview-oli-related-00.txt November 2001 From abstract: ôThis document introduces the environment of the OTM- LF and compares it with existing equipment. Based on this, 10 applications requiring supervisory information being carried over this OTM-LF are defined. It is proposed to use this outline as a basis for the specification work of this new OTM-LF interface.ö This contribution: - Begins with analysis of existing equipment with a ôbackplaneö interface between I/O port cards and fabric cards, to derive OSI requirements. - Analyzes needs from data, management and control planes. - Recommends single OSI per equipment connected using LAN-type architecture. - Recommends various applications for OSI: - Connection Status - Port Management - OLS Discovery - Status monitoring of physical interface and communications over funiculus/OSI - Control and Management Plane Communication - OCh Overhead - Protection Switch Endpoint Coordination and Functional Model Emulation - Auxiliary Communication - Describes various tributary types and the resultant maintenance signals forward to the OXC on a failure. Also describes signals originated in OXC forwarded to OLS. 3. Reference: ITU Contribution - New equipment partitioning, October 2001 From abstract: Proposes a new recommendation G.vbi to support interworking over the virtual backplane interface as introduced in this contribution. - Motivation for a VBI is that integration of OLS and OXC into a single equipment is not expected in same way that SDH LT and ADM functions where merged with DXCs. Monitoring functions not duplicated in OXC and OLS. Hence standard OXC-OLS interface is required. - Associated contributions discuss VBI applications, physical aspects and performance aspects. - Discussed tradeoffs between VBI interface choices: - packet interface (e.g. Ethernet LAN) - channeled bit oriented interface to/from a central channel cross connect function - dedicated backplane overhead defined in traffic interface signals - Presented similar list of applications as T1X1.5/2001-165. 4. Reference: T1X1.5/2001-149R1 - Functions for fast light path restoration in photonic cross-connects, June 2001 Jim Jones et al. û Informational Draft û Expires May 2002 4 draft-jones-ccamp-overview-oli-related-00.txt November 2001 From abstract: ôThis contribution discusses the requirement for interface functions that permit Optical Line Systems to transfer optical signal quality and failure information to a co-located Photonic Cross-connect. +-------------------Interface------------------+ | | | | | | | +-------+ | | +---+ | | +---+ | | ---|WDM|---| |---|WDM|--- | +------+ | +---+ | | +---+ | +------+ ------| Line |--- | PXC | ---| Line |------ ------|System|--- | | ---|System|------ +------+ | +---+ | | +---+ | +------+ ---|WDM|---| |---|WDM|--- +---+ | | +---+ +-------+ Figure 2. Optical System This contribution: - Discusses functions of Automatic Discovery and Fault Notification and Trace Monitoring. - Outlines main interface requirements - Reliable transport protocol between the fabric (PXC) and the Line System (LS). - The control channel is implemented out of band (e.g. OSC, Ethernet, or other media). - OLS keeps minimum state information. The responsibility for coordination and control is at the fabric. - Control channel maintenance uses a simple keep-alive mechanism. - There is a mechanism for resynchronization if the session is disrupted for any reason. - Fault reporting must be both event-driven and available - Supports discovery using test transmitters and receivers connected to well-known ports of the fabric, and terminated by the OLS or test TXÆs and RXÆs on other PXCÆs. 5. Protocol Contribution 1. Reference: T1X1.5/2001-099, January 2001 - Detecting and correlating external path-related faults and degradations by extending LMP between OXC and DWDM From abstract: ôThe need for faster detection and restoration of faults and degradations ... calls for tighter control on the detection and reporting mechanisms. In this document we propose some such extensions that can be made to the LMP to run between the DWDM and OXC. This proposal is to extend [draft-fredette-lmp-wdm-00.txt] and to streamline the needs for such a protocol.ö Jim Jones et al. û Informational Draft û Expires May 2002 5 draft-jones-ccamp-overview-oli-related-00.txt November 2001 This contribution: - Proposal streamlines different requirements with the following goals in mind: - Monitor and communicate the status of different lambda(s), link(s) and equipment(s), which are not visible to the OXC and communicate the status to the relevant parties. - Reduce the error detection and reporting time. . Fault reporting should be both event-driven and polling- driven. . Monitored information should be periodic and event-driven (in case of degrading links or on demand). - Avoid all downstream nodes detecting the same error and sending myriad of messages to the upstream nodes. - Backward notification of the forward path status to ease the layer 3 signaling intervention (for future extension). - Presents different actions to be performed by different equipment (LDWDM, OXC, UDWDM) in response to the above-identified degradation or fault locations (to understand the protocol operations the protocol fields that need to be carried). - Suggests objectives for transport mechanisms, security, capability negotiation, monitoring requirements and fault localization/ reporting. 2. Reference: draft-fredette-lmp-wdm-02.txt, July 2001 From abstract: ôAs part of this protocol suite, the Link Management Protocol (LMP) [LMP] is defined to "maintain control channel connectivity, verify component link connectivity, and isolate link, fiber, or channel failures within the network." In it's present form, [LMP] focuses on peer communications (eg. OXC-to-OXC). In this document we propose extensions to LMP for use with OLSs. These extensions are intended to satisfy the "Optical Link Interface Requirements" described in [OLI].ö The model for extending LMP to OLSs is shown in the following figure: +------+ +------+ +------+ +------+ | | ----- | | | | ----- | | | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | | | ----- | | | | ----- | | +------+ +------+ +------+ +------+ ^ ^ ^ ^ ^ ^ | | | | | | | +-----LMP-----+ +-----LMP----+ | | | +----------------------LMP----------------------+ Figure 3. Extended LMP Model - Refers to multiple LMP sessions that may exist simultaneously on same resources (one OXC-OXC and one OXC-OLS). These sessions have Jim Jones et al. û Informational Draft û Expires May 2002 6 draft-jones-ccamp-overview-oli-related-00.txt November 2001 different purposes, must be independent and not conflict (during Verification process). - LMP consists of four types of functions: - Control Channel Management - Link Verification - Link Summarization - Fault Management (localization and notification) All four functions are supported in LMP-WDM. Additionally, a trace monitoring function is added. - An update is planned in light of revised LMP draft. 3. Reference: draft-sahay-ccamp-ntip-01.txt, July 2001. As decided during the last CCAMP WG meeting, LMP approach has received precedence over draft-sahay-ccamp-ntip-01.txt: Network Transport Interface Protocol (NTIP) for Photonic Cross Connects (PXC), July 2001. The interested reader is thus invited to read the corresponding reference for more details. 6. Security Considerations There are no security considerations in addition to the ones mentioned in the referenced documents. 7. References 1 Bradner, S., ôThe Internet Standards Process -- Revision 3ö, BCP 9, RFC 2026, October 1996. 2 Bradner, S., ôKey words for use in RFCs to Indicate Requirement Levelsö, BCP 14, RFC 2119, March 1997. 3 Brownmiller, C et al., ôdraft-many-oli-reqts-00.txtö, Interne Draft, Work in progress, June 2001. 4 Fredette A. et al., ôdraft-fredette-lmp-wdm-02.txtö, Internet Draft, Work in progress, July 2001. 5 Sahay, G. et al. ôdraft-sahay-ccamp-ntip-01.txtö, Internet Draft, Work in progress, July 2001. 9. Author's Addresses Alberto Bellato Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7215 Email: alberto.bellato@netit.alcatel.it Gert Grammel Alcatel Via Trento 30, Jim Jones et al. û Informational Draft û Expires May 2002 7 draft-jones-ccamp-overview-oli-related-00.txt November 2001 I-20059 Vimercate, Italy Phone: +39 039 686-4453 Email: gert.grammel@netit.alcatel.it Jim Jones Alcatel 3400 W. Plano Parkway, Plano, TX 75075, USA Phone: +1 972 519-2744 Email: Jim.D.Jones1@usa.alcatel.com Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be Jim Jones et al. û Informational Draft û Expires May 2002 8