Network Working Group A. Fredette, E. Snyder, J. Shantigram Internet Draft (PhotonEx Corp) Expiration Date: September 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) S. Dharanikota (Nayna Networks, Inc) March 2001 Link Management Protocol (LMP) for WDM Transmission Systems draft-fredette-lmp-wdm-01.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 Fredette et. al. [Page 1] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 crossconnects (OXCs), routers, switches, DWDM transmission systems, and optical add-drop multiplexors (OADMs) to use an MPLS-based control plane to dynamically provision resources and to provide network survivability using protection and restoration techniques. 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 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 GMPLS 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. [LMP] 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, [LMP] focuses on peer communications (eg. OXC-to-OXC) 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 [LMP]. +------+ +------+ +------+ +------+ | | ----- | | | | ----- | | | 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 enhancing fault detection and recovery. Fault detection is particularly an issue when the network is using all-optical photonic switches (PXC). 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 systems typically terminate Fredette et. al. [Page 2] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 channels electrically and regenerate 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 may have multiple LMP sessions corresponding to multiple peering relationships. At each level, LMP provides link management functionality (i.e., control channel management, physical connectivity verification, link property correlation) for that peering relationship. For example, the OXC-OXC LMP sessions in Figure 2 are used to build traffic-engineering (TE) links for GMPLS signaling and routing, and are managed as described in [LMP]. At the transport level, the OXC-WDM LMP session (shown in Figure 2) is used to augment knowledge about the links between the OXCs. The management of these LMP sessions is discussed in this draft. Although there are many similarities between an OXC-OXC LMP session and an OXC-WDM LMP session, 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. As previously mentioned, the OXC-OXC links provide the basis for GMPLS signaling and routing at the optical layer. The information exchanged over LMP-WDM sessions is used to augment knowledge about the links between OXCs. In order for the information exchanged over the OXC-WDM LMP sessions to be used by the OXC-OXC session, the information must be coordinated by the OXC. However, the two LMP sessions are run independently and MUST be maintained separately. One critical requirement when running an OXC-WDM LMP session is the ability of the WDM to make a data-bearing link transparent when not doing the verification procedure. This is because the same data-bearing link may be verified between OXC-WDM and between OXC-OXC. Currently, the BeginVerify procedure is used to coordinate the Test procedure (and hence the transparency/opaqueness of the data-bearing links) as Fredette et. al. [Page 3] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 described in [LMP]. To maintain independence between the sessions, it MUST be possible for the LMP sessions to come up in any order. In particular, it MUST be possible for an OXC-OXC LMP session to come up without an OXC-WDM LMP session being brought up, and vice-versa. This draft focuses on extensions required for use with opaque transmission systems. Work is ongoing in the area of completely transparent wavelength routing; however, it is premature to identify the necessary characteristics and performance information to advertise. That said, the protocol described in this document provides the necessary framework in which to advertise additional information as it is deemed appropriate. 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 Extending LMP for LMP-WDM sessions requires the addition of a performance summarization/notification function as follows: 5. Performance Summarization It is very important to understand the subtle distinctions between the different types of links being considered in the extended LMP-WDM. 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 the TE link composed of these "ports" or "component links" that are advertised in the routing protocols and used for the purposes of connection setup. The verify procedure 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 links. The verify serves two functions: to verify connectivity and exchange handles by which each port or component link is referred. Furthermore, it is up to the OXC to correlate the handles between the various LMP sessions. Once a control channel has been established and the OXC-WDM verification procedure has been completed successfully, the OXC and WDM transmission system may exchange information regarding link configuration and/or performance characteristics (link/performance summarization). An OXC may also receive notification from a WDM transmission system (performance/fault notification). Fredette et. al. [Page 4] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 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 [LMP]. The LMP Capability TLV includes a flag indicating support of an OXC-WDM LMP session as described in this draft. Furthermore, a flag has been added to the LMP Common Header to identify the transmitting node as a DWDM system. 2.2. Link Verification The Test procedure used with WDM transmission systems is the same as described in [LMP]. The VerifyTransportMechanism (included in the BeginVerify and BeginVerifyAck messages) is used to allow nodes to negotiate a link verification method and is essential for transmission systems which have access to overhead bytes rather than the payload. The VerifyId (provided by the remote node in the BeginVerifyAck message, and used in all subsequent Test messages) is used to differentiate Test messages from different LMP sessions. 2.3. Link Summarization Additional type-length values (TLVs) are defined to extend the LinkSummary message to include link characteristics. The TLVs described in the following subsections are transmitted as Data Link Sub-TLVs in the Data Link TLV (see [LMP]). The link characteristics, in general, are 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 in Section 2.4. The format of the Data Link Sub-TLVs follows the LMP TLV format given In Section 8.3 of [LMP] and shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (TLV Object) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N: 1 bit Fredette et. al. [Page 5] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 The N flag indicates if the object is negotiable parameter (N=1) Or a non-negotiable parameter (N=0). Note: none of the Data Link TLVs that are defined in LMP-WDM are negotiable and the N bit should be set to N=0. Type: 15 bits The Type field indicates the TLV type. Length: 16 bits The Length field indicates the length of the TLV object in bytes. The following Link Characteristics are advertised on a per component link (or port) basis. 2.3.1 Link Group ID A local ID assigned to a group of component links. This ID can be used to reduce the control traffic in the case of a failure by enabling the systems to send a single message for a group instead of individual messages for each member of the group. A link may be a member of multiple groups. For example, there may be a group corresponding to a particular wavelength and another group assigned to a physical fiber. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 15 bits = TBD - Length: 16 bits = 4 - Group ID: 32 bits 2.3.2 Link Descriptor The Link Descriptor TLV represents the characteristics of the link comprising the encoding type and bandwidth characteristics. This information is needed for constructing a circuit. The OXC must match the link information between incoming and outgoing interfaces for a given path. Fredette et. al. [Page 6] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 Note: This information may be a prerequisite for running the verify protocol, thus it may be redundant when verify is being used. The details for the information in this TLV are the same as those for the link descriptor sub-TLV defined in [KRB00a]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | Length = 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Encoding Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Reservable Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Reservable Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 15 bits = TBD - Length: 16 bits = 12 - Link Encoding Type: 32 bits Value Link Encoding Type ----- ------------------ 1 Standard SONET 2 Arbitrary SONET 3 Standard SDH 4 Arbitrary SDH 5 Clear 6 GigE 7 10GigE - Minimum Reservable Bandwidth: 32 bits Bytes per Second represented in IEEE floating point format. - Maximum Reservable Bandwidth: 32 bits Bytes per Second represented in IEEE floating point format. If the interface only supports a fixed rate, the minimum and maximum bandwidth fields are set to the same value. Bandwidth Values and their IEEE representation for common interfaces are provided in the following table. Signal Type (Bit-rate) Value (Bytes/Sec) (IEEE Floating point) Fredette et. al. [Page 7] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 ----------- ----------- ------------ DS0 (0.064 Mbps) 0x45FA0000 DS1 (1.544 Mbps) 0x483C7A00 E1 (2.048 Mbps) 0x487A0000 DS2 (6.312 Mbps) 0x4940A080 E2 (8.448 Mbps) 0x4980E800 Ethernet (10.00 Mbps) 0x49989680 E3 (34.368 Mbps) 0x4A831A80 DS3 (44.736 Mbps) 0x4AAAA780 STS-1 (51.84 Mbps) 0x4AC5C100 Fast Ethernet (100.00 Mbps) 0x4B3EBC20 E4 (139.264 Mbps) 0x4B84D000 OC-3/STM-1 (155.52 Mbps) 0x4B9450C0 OC-12/STM-4 (622.08 Mbps) 0x4C9450C0 GigE (1000.00 Mbps) 0x4CEE6B28 OC-48 (2488.32 Mbps) 0x4D9450C0 OC-192 (9953.28 Mbps) 0x4E9450C0 10GigE-LAN (10000.00 Mbps) 0x4E9502F9 2.3.3 Shared Risk Link Group Identifier (SRLG): SRLGs to which the link is a member. This information is manually configured on the DWDM systems by the service providers. Used for diverse path computation. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | 4 * No. of SRLGs in link | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Risk Link Group Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ............ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Risk Link Group Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 15 bits = TBD - Length: 16 bits = 4 * No. of SRLGs in link - Shared Risk Link Group Value: 32 bits List as many SRLGs as apply. 2.3.4 Wavelength The wavelength being used by the WDM system to transport the component link. Note: this is needed for a transparent system, but Fredette et. al. [Page 8] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 of questionable use for an opaque system. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Wavelength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 15 bits = TBD - Length: 16 bits = 4 - Wavelength: 32 bits Local identifier for wavelength on which the WDM system will transmit the signal from the link. 2.3.5 Bit Error Rate (BER) Estimate This TLV provides an estimate of the BER for the component link. The bit error rate (BER) is the percentage of bits that have errors relative to the total number of bits received in a transmission, usually expressed as ten to a negative power. For example, a transmission might have a BER of 10 to the minus 6, meaning that, out of 1,000,000 bits transmitted, one bit was in error. The BER is an indication of overall link quality. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | BER | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 15 bits = TBD - Length: 16 bits = 4 - Reserved: 24 bits Must be set to zero on transmit and ignored on receive. - BER: 8 bits The exponent from the BER representation described above. For Fredette et. al. [Page 9] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 example, if the BER is 10 to the minus X, the BER field is set to X. 2.3.6 Optical Protection Whether the WDM system protects the link internally. This information can be used as a measure of quality of the link. It may be advertised by routing and used by signaling as a selection criterion as described in [GMPLS]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Link Flags| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 15 bits = TBD - Length: 16 bits = 4 - Reserved: 24 bits Must be set to zero on transmit and ignored on receive. - Link Flags: 6 bits Indicates supported link protection type. These link flags are intended to be consistent with those defined in [GMPLS]. The following flags are defined: 0x20 Enhanced Indicates that a protection scheme that is more reliable than Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS-SPRING. 0x10 Dedicated 1+1 Indicates that a dedicated link layer protection scheme, i.e., 1+1 protection, should be used to support the LSP. 0x08 Dedicated 1:1 Indicates that a dedicated link layer protection scheme, i.e., 1:1 protection, should be used to support the LSP. 0x04 Shared Fredette et. al. [Page 10] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 Indicates that a shared link layer protection scheme, such as 1:N protection, should be used to support the LSP. 0x02 Unprotected Indicates that the LSP should not use any link layer protection. 0x01 Extra Traffic Indicates that the LSP should use links that are protecting other (primary) traffic. Such LSPs may be preempted when the links carrying the (primary) traffic being protected fail. 2.3.7 Span Length: Distance of fiber in WDM system. May be used as a routing metric or to estimate delay. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Span Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 15 bits = TBD - Length: 16 bits = 4 - Span Length: 32 bits Length of WDM span in meters. 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. The PM information either is available on demand, or may be advertised periodically. It should also be possible to configure the system to send PM messages upon crossing thresholds. For example, a message might be sent if the BER exceeds a pre-configured threshold. PM information is different from link characteristics in that it is more dynamic in nature and tends to be measured over a period of time. Fredette et. al. [Page 11] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 NOTE: The following messages will be added in a future version. It will be possible to request information on a TE Link, Group, or Data Link basis. It will also be possible to identify which performance information is requested. 1. Performance Summarization Request 2. Performance Summarization Advertisement 3. Performance Summarization Acknowledgement PM information should be advertised for one of the following 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. This information can be used to allow the system to reroute connections proactively to avert potential failures, and so that problems can be diagnosed. The following Performance Monitoring information may be advertised on a per component link or interface basis: 2.4.1 Line-Side Bit Error Rate (BER): This TLV provides a report of the actual BER for the component link. This is a measure of BER within the WDM system. It is measured on streams flowing from the WDM node to the peer Node. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | BER | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 15 bits = TBD - Length: 16 bits = 4 - Reserved: 24 bits Must be set to zero on transmit and ignored on receive. - BER: 8 bits The exponent from the BER representation as described in Section 2.3.5. For example, if the BER is 10 to the minus X, the BER field is set to X. Fredette et. al. [Page 12] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 2.4.2 SONET Monitoring Information 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. 2.4.2.1 BER Calculated via B1 error count 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BER-24H-1 | BER-24H-2 | BER-15M-1 | BER-15M-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 15 bits = TBD - Length: 16 bits = 4 - BER-24H-1: 8 bits BER for the previous 24 hour period. Represented as the BER exponent as described in Section 2.3.5. - BER-24H-2: 8 bits BER for the current 24 hour period. Represented as the BER exponent as described in Section 2.3.5. - BER-15M-1: 8 bits BER for the previous 15 minute period. Represented as the BER exponent as described in Section 2.3.5. - BER-15M-2: 8 bits BER for the current 15 minute period. Represented as the BER exponent as described in Section 2.3.5. Fredette et. al. [Page 13] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 2.4.2.2 SES Severely errored seconds. Collected via B1 error count. Used to collect statistics on burst errors. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SES-24H-1 | SES-24H-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SES-15M-1 | SES-15M-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 15 bits = TBD - Length: 16 bits = 8 - SES-24H-1: 16 bits SES for the previous 24 hour period. - SES-24H-2: 16 bits SES for the current 24 hour period. - SES-15M-1: 16 bits SES for the previous 15 minute period. - SES-15M-2: 16 bits SES for the current 15 minute period. 2.4.2.3 Protection switch count 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. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSC-24H-1 | PSC-24H-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSC-15M-1 | PSC-15M-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fredette et. al. [Page 14] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 - Type: 15 bits = TBD - Length: 16 bits = 8 - PSC-24H-1: 16 bits Protection switch count for the previous 24 hour period. - PSC-24H-2: 16 bits Protection switch count for the current 24 hour period. - PSC-15M-1: 16 bits Protection switch count for the previous 15 minute period. - PSC-15M-2: 16 bits Protection switch count for the current 15 minute period. 2.4.2.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. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type = TBD | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PJC-24H-1 | PJC-24H-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PJC-15M-1 | PJC-15M-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Type: 15 bits = TBD - Length: 16 bits = 8 - PJC-24H-1: 16 bits Number of times the SONET SPE pointer needed to be justified during the previous 24 hour period. - PJC-24H-2: 16 bits Number of times the SONET SPE pointer needed to be justified during the current 24 hour period. Fredette et. al. [Page 15] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 - PJC-15M-1: 16 bits Number of times the SONET SPE pointer needed to be justified during the previous 15 minute period. - PJC-15M-2: 16 bits Number of times the SONET SPE pointer needed to be justified during the current 15 minute period. 2.5. Fault Localization Fault management consists of three major functions: 1. Fault Detection 2. Fault Localization 3. Fault Notification 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 OXC-WDM 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 [LMP]. Fredette et. al. [Page 16] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 4. References [GMPLS] 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. [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. [KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF Extensions in Support of Generalized MPLS," Internet Draft, draft-kompella-ospf-extensions-00.txt, (work in progress), July 2000. [LMP] Lang, J., Mitra, K., Drake, J., Kompella, K., Rekhter, Y., Berger, L., Saha, D., Basak, D., Sandick, H., Zinin, A., "Link Management Protocol (LMP)", Internet Draft, draft-ietf-mpls-lmp-01.txt, (work in progress), November 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 17] Internet Draft draft-fredette-lmp-wdm-01.txt March 2001 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 Sudheer Dharanikota Nayna Networks, Inc. 157 Topaz Drive, Milpitas, CA 95035 email: sudheer@nayna.com Fredette et. al. [Page 18]