Internet Draft Network Working Group A. Fredette, E. Snyder, J. Shantigram Internet Draft (PhotonEx Corp) Expiration Date: June 2001 J. Lang, J. Drake, G. Tumuluri (Calient Networks) R. Goyal, S. Brorson, R. Krishnan (Axiowave Networks) W. L. Edwards (iLambda Networks) Y. Xue (UUNET/WorldCom) J. Yu (Zaffire, Inc) December 2000 Link Management Protocol (LMP) for WDM Transmission Systems draft-fredette-lmp-wdm-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 [Bra96]. 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 A suite of protocols is being developed in the IETF to allow networks consisting of photonic switches (PXCs), optical crossconnects (OXCs), routers, switches, DWDM transmission systems, Fredette et. al. [Page 1] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 and optical add-drop multiplexors (OADMs) to use an MPLS control plane to dynamically provision resources and to provide network survivability using protection and restoration techniques. As part of this suite, the Link Management Protocol (LMP) [LMD00] 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, [LMD00] focuses on OXC-to-OXC communications. In this document we propose extensions to LMP for use with DWDM transmission systems. 1. Introduction Future networks will consist of photonic switches (PXCs), optical crossconnects (OXCs), routers, switches, DWDM transmission systems, and optical add-drop multiplexors (OADMs) that use the MPLS control plane to dynamically provision resources and to provide network survivability using protection and restoration techniques. A pair of nodes (e.g., a PXC and a DWDM system) may be connected by thousands of fibers. Furthermore, multiple fibers and/or multiple wavelengths may be combined into a single bundled link. [LMD00] Defines the Link Management Protocol (LMP) to "maintain control channel connectivity, verify component link connectivity, and isolate link, fiber, or channel failures within the network." In it's present form, [LMD00] focuses on OXC-to-OXC communications as illustrated in Figure 1. In this document, extensions to LMP for use with DWDM transmission systems are proposed. It is assumed that the reader is familiar with LMP as defined in [LMD00]. +------+ +------+ +------+ +------+ | | ----- | | | | ----- | | | OXC1 | ----- | WDM1 | ===== | WDM2 | ----- | OXC2 | | | ----- | | | | ----- | | +------+ +------+ +------+ +------+ ^ ^ | | +----------------------LMP----------------------+ Figure 1: Current LMP Model A great deal of information about a link between two OXCs is known by the DWDM transmission system. Exposing this information to the control plane via LMP can improve network usability by further reducing required manual configuration and also greatly enhance fault detection and recovery. Fault detection is particularly an issue when the network is using all-optical photonic switches or photonic crossconnects (PXCs). Once a connection is established, PXCs have only limited visibility into the health of the connection. Even though the PXC is all-optical, long-haul DWDM transmission Fredette et. al. [Page 2] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 systems typically terminate channels electrically, then regenerates them optically which presents an opportunity to monitor the health of a channel between PXCs. The model for extending LMP to WDM transmission systems is shown in Figure 2. +------+ +------+ +------+ +------+ | | ----- | | | | ----- | | | OXC1 | ----- | WDM1 | ===== | WDM2 | ----- | OXC2 | | | ----- | | | | ----- | | +------+ +------+ +------+ +------+ ^ ^ ^ ^ ^ ^ | | | | | | | +-----LMP-----+ +-----LMP----+ | | | +----------------------LMP----------------------+ Figure 2: Extended LMP Model In this model an OXC establishes LMP sessions with neighboring transmission systems as well as with its neighboring OXCs. The OXC-OXC LMP sessions are managed essentially the same as described in [LMD00]. Although there are many similarities between OXC-OXC LMP and OXC-WDM LMP, particularly for control management and link verification, there are some significant differences as well. These differences can primarily be attributed to the nature of an OXC-WDM link, and the purpose of OXC-WDM LMP sessions. The OXC-OXC links provide the basis for routing circuits at the optical layer. The information exchanged over LMP sessions between an OXC and WDM transmission system is used to augment knowledge about the links between OXCs. The organization of link bundles must be the same for the OXC-OXC LMP session as well as for the OXC-WDM LMP sessions. Note that a side-effect of this requirement is that a link bundle can span at most one WDM system if LMP is being used. In order for the information exchanged over the OXC-WDM LMP sessions to be used by the OXC-OXC session and vice-versa, a relationship must be maintained between the sessions. For a given OXC-OXC LMP session, there are one or more related (child) OXC-WDM LMP sessions (at least one per WDM transmission system connecting the OXCs). The LMP session on the OXC is responsible for maintaining the relationship between the parent session and its children. It may be possible for the OXC to use the same CCid for OXC-OXC communications as well as OXC-WDM communications, but this needs some further thought. The OXC must also provide a session ID for the parent LMP session to the WDM system so that it can be knowledgeable about this relationship. Fredette et. al. [Page 3] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 The session ID can be created by concatenating the CCids from the two OXCs. It should be possible for the LMP sessions to come up in any order and synchronize as new sessions come up. In particular, it should be possible for the OXC-OXC session to come up without a WDM session as LMP is defined today. In case of control channel failure, one or both of the control channels may fail, and the failures may be unrelated to each other. In case of component link failure, failure of OXC-WDM link should imply failure of OXC-OXC link, and vice versa. Additional details about the extensions required for LMP are outlined in the next section. 2. LMP Extensions for WDM Transport Systems As currently defined, LMP consists of four types of functions: 1. Control Channel Management 2. Link Verification 3. Link Summarization 4. Fault Localization Extended LMP has these same basic functional categories with the addition of performance summarization/notification as follows: 1. Control Channel Management 2. Link Verification 3. Link Summarization 4. Performance Summarization 5. Fault Localization The first two functions, control channel management and link verification, are concerned with OXC-WDM links, and are nearly the same as those for OXC-OXC links. It is very important to understand the subtle distinctions between the different types of links being considered in the extended LMP. For example, in Figure 2 when OXC1 and OXC2 complete the verify process, the links being verified are the end-to-end links between the OXC's. It is these "component links" (or a bundle thereof) that are advertised in the routing protocols and used for the purposes of connection setup. The verify between OXC1 and WDM1, on the other hand verifies the shorter link between these two nodes. However, each of these shorter links is a segment of one of the larger end-to-end component links. The verify serves two functions. The first is to verify connectivity. The second is to agree upon handles by which to refer to each component link (the LinkID). So, although the OXC-WDM verify only runs over the shorter link, the LinkID is used to refer to the larger end-to-end component link. In Fredette et. al. [Page 4] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 particular, the WDM system uses the LinkID to report on the end-to-end component link in Link Summarization, Performance Summarization, and Fault Localization. Once a control channel has been established and its associated WDM-OXC links are verified, the OXC and WDM transmission system may exchange information regarding link configuration and/or performance characteristics (link/performance summarization). An OXC may also receive notifications from a WDM transmission system (performance/fault notification). It is noted again that these functions are concerned with the associated OXC-OXC links, not the OXC-WDM links themselves. In subsequent sections, specific changes are proposed to extend LMP to work with WDM transmission systems. 2.1. Control Channel Management The control channel management for OXC-WDM links is the same as for OXC-OXC links, as described in [LMD00]. It may be useful to include a "node type" or "protocol sub-type" identifier in the initial HelloConfig messages so that an OXC may differentiate between another OXC and a WDM transmission system. 2.2. Link Verification The basic test procedure used with WDM transmission systems is the same as described in [LMD00]. The VerifyTransportMechanism and possibly the VerifyID parameters are added to the protocol as described below. [LMD00] requires that "a free (unallocated) component link must be opaque (i.e., able to be terminated)". While this requirement may be reasonable for cross-connects, it is not practical for most transmission systems. When used with SONET or SDH access equipment, the Section Trace (J0) overhead is used for the purpose of link verification. For both SONET and SDH, the section trace message consists of a string of 7-bit characters (i.e., ASCII) terminated by a frame delimiter. SONET uses a 64 octet string (62 octets of data with a CR-LF frame delimiter) [SONET], while SDH uses a 16 octet string (15 octets of data with a CRC-7 frame delimiter) [SDH]. It is proposed that 15 octets or fewer be used for the Test message so that the same basic format is used for both SONET and SDH links. A VerifyTransportMechanism is added to the BeginVerify and BeginVerifyAck messages. The purpose for this new parameter is to allow nodes to negotiate a link verification method. In particular, it allows a transmission system to tell an OXC to use the section trace overhead instead of a terminated link. Additional VerifyTransportMechanism types may be added for new types of Fredette et. al. [Page 5] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 connections in the future, if necessary. The verifying node includes the VerifyTransportMechanism parameter in the BeginVerify message to indicate all supported methods (e.g., link termination, SONET Section Trace, or SDH Section Trace). In the verify protocol of the current LMP, information including the CCid is included in the the test message that allows the node being verified to uniquely identify the source of each test message. It needs to be determined whether this information can be encoded in the limited payload space available in the SDH section trace message (15 7-bit characters). An alternate solution may be for the remote node provides a VerifyID to the local node in the BeginVerifyAck Message. The Test message can then be created by concatenating the VerifyID and the LinkID. The VerifyID allows a node to differentiate test messages from different LMP peers in the absence of the CCid. 2.3. Link Summarization The LinkSummary message is extended to advertise link characteristics. The specific link characteristics to be advertised is still TBD; however, they should, in general, be those characteristics needed by the control plane for constraint-based routing and connection establishment. Additionally, the characteristics advertised in the LinkSummary message are intended to be more-or-less static characteristics as opposed to the more dynamic ones advertised in the PerformanceSummary message described below. For the purpose of discussion, the following characteristics are listed as potential candidates. In general these characteristics are advertised on a per component link basis. However, it may also be useful to advertise per fiber, per bundle, or per component link. Also some make sense for the case of transparent all-optical wavelength routing and some make sense for opaque channels that are terminated electrically at the transmission system. Potential Link Characteristics: 1. Wavelength Channel Count: Number of independent wavelengths Carried 2. Total wavelengths carried (Information is carried on a per-channel basis.): Table of all wavelengths which can be supported. For each wavelength, information should include: Fredette et. al. [Page 6] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 - Allocated or Free - Port - Section trace or ID (J0) - Timing source/quality (S1) - Wavelength - Wavelength Band (C- L- or S-Band) - Bit rate. For multiple rate cards list all possible bit rates. For transparent optical card, list "transparent" - Protocol/framing (SONET, 10GigE, OCh) - FEC if any - BER estimate (quality of the link) - Drop side interface type. - Laser output power on drop side. - Laser output power on line side. - Receiver sensitivity (dynamic range) on drop side. - Receiver sensitivity on line side. - Availability of protection, i.e. Is SONET APS possible on this wavelength? Protection type and QoS (e.g. None, SONET 1+1, SONET 1:1, Optical layer switching, pre-emptable lightpath, etc.) 3. Transparent optical span length: Distance of fiber between Tx and Rx. Used to make estimates of attenuation and dispersion until next regen. Note that this parameter applies to all wavelengths. 4. Span Loss: Span loss between Tx and Rx in dB Tx power, span attenuation, and Rx sensitivity is used in constraint-based routing on physical layer. Note that this parameter applies to all wavelengths. 5. Fiber Type: Type of the fiber used in the span (DCF or not etc.) Fiber type and span length is used to estimate dispersion penalty. Note that this parameter applies to all wavelengths. 6. Fiber characteristics: PMD, Dispersion, Loss etc. Theoretically used to estimate penalty for constraint-based routing. It is possible that the service providers have no accurate data for this field. 7. Optical amplifier data for link/span: Type and number of amplifiers Used to estimate OSNR over link. Fredette et. al. [Page 7] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 8. Performance Monitoring Capability: Whether OPM is used and if so, what is monitored and can the information be shared with other network elements. 9. OEO Regenerator Data for link/span Number and type of regenerators present in the link/span Used to estimate optical quality of link. 10. Regen and Amp Spacing/Locations How far apart are the Regens and Amps 11. Signaling Format: RZ, NRZ 12. Shared Risk Link Group Identifier: What shared risk link groups exist (manually configured on the DWDM systems by the service providers) Used for diverse path computation. 13. Channel Spacing, 14. Spectral Bandwidth of Each Channel 2.4. Performance Summarization A new type of message is added to LMP to advertise performance monitoring (PM) information that is available within the WDM transmission system. PM information is different from link characteristics in that it is more dynamic in nature. PM information should be advertised for one of several reasons: - For use in ascertaining a QoS level of a link for routing purposes - To predict likely or impending failure so that a connection can be rerouted proactively. (E.g., exceeding an uncorrected BER threshold even though the corrected BER is adequate.) - To quickly detect a failed link. This information can be used to allow the system to reroute connections proactively to avert potential failures, and so that problems can be diagnosed. As in the case of link characteristics, specific items still require further investigation. Some of the performance measures under Fredette et. al. [Page 8] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 consideration for Optical Performance Monitoring are listed below: 1. Dispersion (chromatic and polarization mode): The distortion or spreading of bits due to variations in propagation velocity of different wavelengths and polarization modes in the fiber and other network elements. 2. Optical signal-to-noise ratio (OSNR): The ratio of optical power in a primary data channel to the power in optical background noise accumulated during transmission and switching. This ratio is usually specified within some optical bandwidth of a receiver filter. The OSNR of a channel at the destination receiver will set the limit of the final detected SNR. 3. Bit-rate: The data rate of the channel in a transparent system will be necessary to make decisions on other performance metrics. 4. Q-Factor: A measure of the signal-to-noise ratio (SNR) assuming Gaussian noise statistics. 5. Wavelength registration: The determination of which wavelengths are present on a given fiber. 6. Wavelength selective component drift: The drift of a laser, filter, mux or other wavelength selective component relative to the ITU grid. 7. Optical cross talk: Two types of cross talk are of interest, in-band and out-of-band. In-band cross talk is seen as at the same wavelength as the primary channel and appears as cross talk in the electronic domain. Out-of-band cross talk appears as a different wavelength in the presence of the primary wavelength and appears as cross talk in the optical domain. 8. Optical power transients: Changes in the optical powers that are not due to normal bit Fredette et. al. [Page 9] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 transitions. May be due to optical amplifier gain transients or other transient non-linearity in the system. 9. Bit-error-rate: In a SONET environment BER can be directly measured on the channel using means to look at bits within the data stream. However, in a purely photonic network there will typically not be access to the data streams carried over the channel. However, by interpreting the other optical parameters, the system should be able to estimate the BER with relatively good accuracy, as well as guarantee bit error rate performance to the users of the channel. 10. Jitter: Random fluctuations in the location of rising and falling edges of bits relative to a local or recovered clock reference. As line speeds continue to increase, jitter will become a critical performance parameter. 11. Insertion loss: Indicates the input to output loss of a network element. When examining excessive power loss along the path of a channel the ability to measure insertion loss of individual network elements is very useful, specifically when compared against an archival database. 12. Optical power level In addition to OPM measures, the transmission systems may exchange SONET (OEO) monitoring information with the photonic switches, if such information is available. Requirements for PM in SONET are given in GR-253-CORE and some discussion of PM is also included in G.874. PM parameters shall be gathered and reported over two time intervals: 15-minute intervals and 24-hour intervals. The list given below is a subset of the parameters listed in GR-253-CORE, and is intended to be a minimal list required for making routing decisions. Naturally, one also could implement the entire suite of SONET PM parameters if one wanted to. The following parameters should be reported on a per-component link basis: 1. BER Collected via B1 error count Fredette et. al. [Page 10] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 2. SES Severely errored seconds. Collected via B1 error count. Used to collect statistics on burst errors. 3. Protection switch counts Number of protection switch events during the count interval. Provides an indication of possible link problems. If protection switch chattering is occurring, the link is bad. 4. STS pointer justifications Number of times the SONET SPE pointer needed to be justified. Provides an indication of the clocking accuracy over the optical link. 2.5. Fault Localization Fault localization consists of three major functions: 1. Fault Detection 2. Fault Notification 3. Fault Localization The actual Fault Detection mechanisms are the responsibility of the individual nodes and are not specified as part of this protocol. Fault detection mechanisms may include such things as bit error rate (BER) exceeding a threshold, loss of signal (LOS) and certain SONET-level errors. The fault notification and localization procedure is essentially the same as in the current version of LMP, however, it is executed at two levels in the extended LMP. OXCs continue to execute the OXC-to-OXC fault localization as currently specified. The main difference is that the WDM system may initiate the process (both downstream and upstream). The WDM system will also execute its own fault localization process that may allow it to determine the location of the fault much more specifically than the OXCs can. For example, the WDM transmission system may be able to pinpoint the fault to a particular amplifier along a set of fibers that can span 1000's of kilometers. 3. Security Considerations The security considerations will be the same as in [LMD00]. Fredette et. al. [Page 11] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 4. References [Bra96] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. [CBD00] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J., Edwards, W. L., "Performance Monitoring in Photonic Networks in Support of MPL(ambda)S", Internet Draft, draft-ceuppens-mpls-optical-00.txt, (work in progress), March 2000. [DBC00] 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. [KRB00] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS Traffic Engineering," Internet Draft, draft-kompella-mpls-bundle-02.txt, (work in progress), July 2000. [LMD00] Lang, J., Mitra, K., Drake, J., Kompella, K., Rekhter, Y., Berger, L., Saha, D., Basak, D., Sandick, H., "Link Management Protocol (LMP)", Internet Draft, draft-ietf-mpls-lmp-00.txt, (work in progress), September 2000. [SDH] ITU-T G.707, "Network node interface for the synchronous digital hierarchy (SDH)", 1996. [SONET] GR-253-CORE, "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria", Telcordia Technologies, Issue 3, September 2000 [T.50] ITU-T T.50, "International Reference Alphabet (IRA) (formerly International Alphabet No. 5 or IA5) Information technology 7-bit coded character set for information interchange.", 1992. Fredette et. al. [Page 12] Internet Draft draft-fredette-lmp-wdm-00.txt December 2000 5. Author's Addresses Andre Fredette Ed Snyder PhotonEx Corporation PhotonEx Corporation 8C Preston Court 8C Preston Court Bedford, MA 01730 Bedford, MA 01730 email: fredette@photonex.com email: esnyder@photonex.com Jagan Shantigram Jonathan P. Lang PhotonEx Corporation Calient Networks 8C Preston Court25 Castilian Drive Bedford, MA 01730 Goleta, CA 93117 email: jagan@photonex.com email: jplang@calient.net John Drake Gopala Tumuluri Calient Networks Calient Networks 5853 Rue Ferrari 5853 Rue Ferrari San Jose, CA 95138 San Jose, CA 95138 email: jdrake@calient.net email: krishna@calient.net Rohit Goyal Stuart Brorson Axiowave Networks Axiowave Networks 100 Nickerson Road 100 Nickerson Road Marlborough, MA 01752 Marlborough, MA 01752 email: rgoyal@axiowave.com email: sdb@axiowave.com Ram Krishnan W. L. Edwards Axiowave Networks iLambda Networks 100 Nickerson Road Aspen, CO Marlborough, MA 01752 email: texas@ilambda.com email: ram@axiowave.com Yong Xue John Yu UUNET/WorldCom Zaffire, Inc 22001 Loudoun County Parkway 2630 Orchard Parkway Ashburn, VA 20148 San Jose, CA 95134 email: yxue@uu.net email: jzyu@zaffire.com Fredette et. al. [Page 13]