idnits 2.17.1 draft-fredette-lmp-wdm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([LMP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '...ndependently and MUST be maintained se...' RFC 2119 keyword, line 154: '...ween the sessions, it MUST be possible...' RFC 2119 keyword, line 156: '... MUST be possible for an OXC-OXC LMP...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2001) is 8433 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'CBD00' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'DBC00' is defined on line 812, but no explicit reference was found in the text == Unused Reference: 'KRB00' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'SDH' is defined on line 834, but no explicit reference was found in the text == Unused Reference: 'SONET' is defined on line 837, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-02 == Outdated reference: A later version (-04) exists of draft-ceuppens-mpls-optical-00 -- Possible downref: Normative reference to a draft: ref. 'CBD00' -- Possible downref: Non-RFC (?) normative reference: ref. 'DBC00' == Outdated reference: A later version (-05) exists of draft-kompella-mpls-bundle-02 -- Possible downref: Normative reference to a draft: ref. 'KRB00' -- No information found for draft-kompella-ospf-extensions - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'KRB00a' == Outdated reference: A later version (-02) exists of draft-ietf-mpls-lmp-01 -- Possible downref: Normative reference to a draft: ref. 'LMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDH' -- Possible downref: Non-RFC (?) normative reference: ref. 'SONET' Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Fredette, E. Snyder, J. Shantigram 2 Internet Draft (PhotonEx Corp) 3 Expiration Date: September 2001 4 J. Lang, J. Drake, G. Tumuluri 5 (Calient Networks) 7 R. Goyal, S. Brorson, R. Krishnan 8 (Axiowave Networks) 10 W. L. Edwards 11 (iLambda Networks) 13 Y. Xue 14 (UUNET/WorldCom) 16 J. Yu 17 (Zaffire, Inc) 19 S. Dharanikota 20 (Nayna Networks, Inc) 22 March 2001 24 Link Management Protocol (LMP) for WDM Transmission Systems 25 draft-fredette-lmp-wdm-01.txt 27 STATUS OF THIS MEMO: 29 This document is an Internet-Draft and is in full conformance with 30 all provisions of Section 10 of RFC2026 [Bra96]. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 Abstract 50 A suite of protocols is being developed in the IETF to allow 51 networks consisting of photonic switches (PXCs), optical 52 crossconnects (OXCs), routers, switches, DWDM transmission systems, 53 and optical add-drop multiplexors (OADMs) to use an MPLS-based 54 control plane to dynamically provision resources and to provide 55 network survivability using protection and restoration techniques. 56 As part of this protocol suite, the Link Management Protocol (LMP) 57 [LMP] is defined to "maintain control channel connectivity, verify 58 component link connectivity, and isolate link, fiber, or channel 59 failures within the network." In it's present form, [LMP] focuses 60 on peer communications (eg. OXC-to-OXC). In this document we 61 propose extensions to LMP for use with DWDM transmission systems. 63 1. Introduction 65 Future networks will consist of photonic switches (PXCs), optical 66 crossconnects (OXCs), routers, switches, DWDM transmission systems, 67 and optical add-drop multiplexors (OADMs) that use the GMPLS control 68 plane to dynamically provision resources and to provide network 69 survivability using protection and restoration techniques. A pair 70 of nodes (e.g., a PXC and a DWDM system) may be connected by 71 thousands of fibers. Furthermore, multiple fibers and/or multiple 72 wavelengths may be combined into a single bundled link. [LMP] 73 Defines the Link Management Protocol (LMP) to "maintain control 74 channel connectivity, verify component link connectivity, and 75 isolate link, fiber, or channel failures within the network." In 76 it's present form, [LMP] focuses on peer communications (eg. 77 OXC-to-OXC) as illustrated in Figure 1. In this document, 78 extensions to LMP for use with DWDM transmission systems are 79 proposed. It is assumed that the reader is familiar with LMP as 80 defined in [LMP]. 82 +------+ +------+ +------+ +------+ 83 | | ----- | | | | ----- | | 84 | OXC1 | ----- | WDM1 | ===== | WDM2 | ----- | OXC2 | 85 | | ----- | | | | ----- | | 86 +------+ +------+ +------+ +------+ 87 ^ ^ 88 | | 89 +----------------------LMP----------------------+ 91 Figure 1: Current LMP Model 93 A great deal of information about a link between two OXCs is known 94 by the DWDM transmission system. Exposing this information to the 95 control plane via LMP can improve network usability by further 96 reducing required manual configuration and also greatly enhancing 97 fault detection and recovery. Fault detection is particularly an 98 issue when the network is using all-optical photonic switches (PXC). 99 Once a connection is established, PXCs have only limited visibility 100 into the health of the connection. Even though the PXC is 101 all-optical, long-haul DWDM transmission systems typically terminate 102 channels electrically and regenerate them optically, which presents 103 an opportunity to monitor the health of a channel between PXCs. 105 The model for extending LMP to WDM transmission systems is shown in 106 Figure 2. 108 +------+ +------+ +------+ +------+ 109 | | ----- | | | | ----- | | 110 | OXC1 | ----- | WDM1 | ===== | WDM2 | ----- | OXC2 | 111 | | ----- | | | | ----- | | 112 +------+ +------+ +------+ +------+ 113 ^ ^ ^ ^ ^ ^ 114 | | | | | | 115 | +-----LMP-----+ +-----LMP----+ | 116 | | 117 +----------------------LMP----------------------+ 119 Figure 2: Extended LMP Model 121 In this model, an OXC may have multiple LMP sessions corresponding 122 to multiple peering relationships. At each level, LMP provides link 123 management functionality (i.e., control channel management, physical 124 connectivity verification, link property correlation) for that 125 peering relationship. For example, the OXC-OXC LMP sessions in 126 Figure 2 are used to build traffic-engineering (TE) links for GMPLS 127 signaling and routing, and are managed as described in [LMP]. At the 128 transport level, the OXC-WDM LMP session (shown in Figure 2) is used 129 to augment knowledge about the links between the OXCs. The 130 management of these LMP sessions is discussed in this draft. 132 Although there are many similarities between an OXC-OXC LMP session 133 and an OXC-WDM LMP session, particularly for control management and 134 link verification, there are some significant differences as well. 135 These differences can primarily be attributed to the nature of an 136 OXC-WDM link, and the purpose of OXC-WDM LMP sessions. As 137 previously mentioned, the OXC-OXC links provide the basis for GMPLS 138 signaling and routing at the optical layer. The information 139 exchanged over LMP-WDM sessions is used to augment knowledge about 140 the links between OXCs. 142 In order for the information exchanged over the OXC-WDM LMP sessions 143 to be used by the OXC-OXC session, the information must be 144 coordinated by the OXC. However, the two LMP sessions are run 145 independently and MUST be maintained separately. One critical 146 requirement when running an OXC-WDM LMP session is the ability of 147 the WDM to make a data-bearing link transparent when not doing the 148 verification procedure. This is because the same data-bearing link 149 may be verified between OXC-WDM and between OXC-OXC. Currently, the 150 BeginVerify procedure is used to coordinate the Test procedure (and 151 hence the transparency/opaqueness of the data-bearing links) as 152 described in [LMP]. 154 To maintain independence between the sessions, it MUST be possible 155 for the LMP sessions to come up in any order. In particular, it 156 MUST be possible for an OXC-OXC LMP session to come up without an 157 OXC-WDM LMP session being brought up, and vice-versa. 159 This draft focuses on extensions required for use with opaque 160 transmission systems. Work is ongoing in the area of completely 161 transparent wavelength routing; however, it is premature to identify 162 the necessary characteristics and performance information to 163 advertise. That said, the protocol described in this document 164 provides the necessary framework in which to advertise additional 165 information as it is deemed appropriate. 167 Additional details about the extensions required for LMP are 168 outlined in the next section. 170 2. LMP Extensions for WDM Transport Systems 172 As currently defined, LMP consists of four types of functions: 174 1. Control Channel Management 175 2. Link Verification 176 3. Link Summarization 177 4. Fault Localization 179 Extending LMP for LMP-WDM sessions requires the addition of a 180 performance summarization/notification function as follows: 182 5. Performance Summarization 184 It is very important to understand the subtle distinctions between 185 the different types of links being considered in the extended 186 LMP-WDM. For example, in Figure 2 when OXC1 and OXC2 complete the 187 verify process, the links being verified are the end-to-end links 188 between the OXC's. It is the TE link composed of these "ports" or 189 "component links" that are advertised in the routing protocols and 190 used for the purposes of connection setup. The verify procedure 191 between OXC1 and WDM1, on the other hand verifies the shorter link 192 between these two nodes. However, each of these shorter links is a 193 segment of one of the larger end-to-end links. The verify serves 194 two functions: to verify connectivity and exchange handles by which 195 each port or component link is referred. Furthermore, it is up to 196 the OXC to correlate the handles between the various LMP sessions. 198 Once a control channel has been established and the OXC-WDM 199 verification procedure has been completed successfully, the OXC and 200 WDM transmission system may exchange information regarding link 201 configuration and/or performance characteristics (link/performance 202 summarization). An OXC may also receive notification from a WDM 203 transmission system (performance/fault notification). 205 In subsequent sections, specific changes are proposed to extend LMP 206 to work with WDM transmission systems. 208 2.1. Control Channel Management 210 The control channel management for OXC-WDM links is the same as for 211 OXC-OXC links, as described in [LMP]. The LMP Capability TLV 212 includes a flag indicating support of an OXC-WDM LMP session as 213 described in this draft. Furthermore, a flag has been added to the 214 LMP Common Header to identify the transmitting node as a DWDM system. 216 2.2. Link Verification 218 The Test procedure used with WDM transmission systems is the same as 219 described in [LMP]. The VerifyTransportMechanism (included in the 220 BeginVerify and BeginVerifyAck messages) is used to allow nodes to 221 negotiate a link verification method and is essential for 222 transmission systems which have access to overhead bytes rather than 223 the payload. The VerifyId (provided by the remote node in the 224 BeginVerifyAck message, and used in all subsequent Test messages) is 225 used to differentiate Test messages from different LMP sessions. 227 2.3. Link Summarization 229 Additional type-length values (TLVs) are defined to extend the 230 LinkSummary message to include link characteristics. The TLVs 231 described in the following subsections are transmitted as Data Link 232 Sub-TLVs in the Data Link TLV (see [LMP]). 234 The link characteristics, in general, are those characteristics 235 needed by the control plane for constraint-based routing and 236 connection establishment. Additionally, the characteristics 237 advertised in the LinkSummary message are intended to be 238 more-or-less static characteristics as opposed to the more dynamic 239 ones advertised in the PerformanceSummary message described in 240 Section 2.4. 242 The format of the Data Link Sub-TLVs follows the LMP TLV format 243 given In Section 8.3 of [LMP] and shown below: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |N| Type | Length | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 // (TLV Object) // 252 | | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 N: 1 bit 256 The N flag indicates if the object is negotiable parameter 257 (N=1) Or a non-negotiable parameter (N=0). 259 Note: none of the Data Link TLVs that are defined in LMP-WDM 260 are negotiable and the N bit should be set to N=0. 262 Type: 15 bits 264 The Type field indicates the TLV type. 266 Length: 16 bits 268 The Length field indicates the length of the TLV object in 269 bytes. 271 The following Link Characteristics are advertised on a per component 272 link (or port) basis. 274 2.3.1 Link Group ID 276 A local ID assigned to a group of component links. This ID can be 277 used to reduce the control traffic in the case of a failure by 278 enabling the systems to send a single message for a group instead of 279 individual messages for each member of the group. A link may be a 280 member of multiple groups. For example, there may be a group 281 corresponding to a particular wavelength and another group assigned 282 to a physical fiber. 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |0| Type = TBD | Length = 4 | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Group ID | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 - Type: 15 bits = TBD 294 - Length: 16 bits = 4 296 - Group ID: 32 bits 298 2.3.2 Link Descriptor 300 The Link Descriptor TLV represents the characteristics of the link 301 comprising the encoding type and bandwidth characteristics. This 302 information is needed for constructing a circuit. The OXC must 303 match the link information between incoming and outgoing interfaces 304 for a given path. 306 Note: This information may be a prerequisite for running the verify 307 protocol, thus it may be redundant when verify is being used. 309 The details for the information in this TLV are the same as those 310 for the link descriptor sub-TLV defined in [KRB00a]. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |0| Type = TBD | Length = 12 | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Link Encoding Type | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Minimum Reservable Bandwidth | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Maximum Reservable Bandwidth | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 - Type: 15 bits = TBD 326 - Length: 16 bits = 12 328 - Link Encoding Type: 32 bits 330 Value Link Encoding Type 331 ----- ------------------ 332 1 Standard SONET 333 2 Arbitrary SONET 334 3 Standard SDH 335 4 Arbitrary SDH 336 5 Clear 337 6 GigE 338 7 10GigE 340 - Minimum Reservable Bandwidth: 32 bits 342 Bytes per Second represented in IEEE floating point format. 344 - Maximum Reservable Bandwidth: 32 bits 346 Bytes per Second represented in IEEE floating point format. 348 If the interface only supports a fixed rate, the minimum and maximum 349 bandwidth fields are set to the same value. 351 Bandwidth Values and their IEEE representation for common interfaces 352 are provided in the following table. 354 Signal Type (Bit-rate) Value (Bytes/Sec) 355 (IEEE Floating point) 357 ----------- ----------- ------------ 358 DS0 (0.064 Mbps) 0x45FA0000 359 DS1 (1.544 Mbps) 0x483C7A00 360 E1 (2.048 Mbps) 0x487A0000 361 DS2 (6.312 Mbps) 0x4940A080 362 E2 (8.448 Mbps) 0x4980E800 363 Ethernet (10.00 Mbps) 0x49989680 364 E3 (34.368 Mbps) 0x4A831A80 365 DS3 (44.736 Mbps) 0x4AAAA780 366 STS-1 (51.84 Mbps) 0x4AC5C100 367 Fast Ethernet (100.00 Mbps) 0x4B3EBC20 368 E4 (139.264 Mbps) 0x4B84D000 369 OC-3/STM-1 (155.52 Mbps) 0x4B9450C0 370 OC-12/STM-4 (622.08 Mbps) 0x4C9450C0 371 GigE (1000.00 Mbps) 0x4CEE6B28 372 OC-48 (2488.32 Mbps) 0x4D9450C0 373 OC-192 (9953.28 Mbps) 0x4E9450C0 374 10GigE-LAN (10000.00 Mbps) 0x4E9502F9 376 2.3.3 Shared Risk Link Group Identifier (SRLG): 378 SRLGs to which the link is a member. This information is manually 379 configured on the DWDM systems by the service providers. Used for 380 diverse path computation. 382 0 1 2 3 383 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 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 |0| Type = TBD | 4 * No. of SRLGs in link | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Shared Risk Link Group Value | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | ............ | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Shared Risk Link Group Value | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 - Type: 15 bits = TBD 396 - Length: 16 bits = 4 * No. of SRLGs in link 398 - Shared Risk Link Group Value: 32 bits 400 List as many SRLGs as apply. 402 2.3.4 Wavelength 404 The wavelength being used by the WDM system to transport the 405 component link. Note: this is needed for a transparent system, but 406 of questionable use for an opaque system. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 |0| Type = TBD | Length = 4 | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Wavelength | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 - Type: 15 bits = TBD 418 - Length: 16 bits = 4 420 - Wavelength: 32 bits 422 Local identifier for wavelength on which the WDM system will 423 transmit the signal from the link. 425 2.3.5 Bit Error Rate (BER) Estimate 427 This TLV provides an estimate of the BER for the component link. 429 The bit error rate (BER) is the percentage of bits that have errors 430 relative to the total number of bits received in a transmission, 431 usually expressed as ten to a negative power. For example, a 432 transmission might have a BER of 10 to the minus 6, meaning that, 433 out of 1,000,000 bits transmitted, one bit was in error. The BER is 434 an indication of overall link quality. 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 |0| Type = TBD | Length = 4 | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Reserved | BER | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 - Type: 15 bits = TBD 446 - Length: 16 bits = 4 448 - Reserved: 24 bits 450 Must be set to zero on transmit and ignored on receive. 452 - BER: 8 bits 454 The exponent from the BER representation described above. For 455 example, if the BER is 10 to the minus X, the BER field is set to 456 X. 458 2.3.6 Optical Protection 460 Whether the WDM system protects the link internally. This 461 information can be used as a measure of quality of the link. It may 462 be advertised by routing and used by signaling as a selection 463 criterion as described in [GMPLS]. 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 |0| Type = TBD | Length = 4 | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Reserved | Link Flags| 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 - Type: 15 bits = TBD 475 - Length: 16 bits = 4 477 - Reserved: 24 bits 479 Must be set to zero on transmit and ignored on receive. 481 - Link Flags: 6 bits 483 Indicates supported link protection type. These link flags are 484 intended to be consistent with those defined in [GMPLS]. 486 The following flags are defined: 488 0x20 Enhanced 490 Indicates that a protection scheme that is more reliable 491 than Dedicated 1+1 should be used, e.g., 4 fiber 492 BLSR/MS-SPRING. 494 0x10 Dedicated 1+1 496 Indicates that a dedicated link layer protection scheme, 497 i.e., 1+1 protection, should be used to support the LSP. 499 0x08 Dedicated 1:1 501 Indicates that a dedicated link layer protection scheme, 502 i.e., 1:1 protection, should be used to support the LSP. 504 0x04 Shared 505 Indicates that a shared link layer protection scheme, such 506 as 1:N protection, should be used to support the LSP. 508 0x02 Unprotected 510 Indicates that the LSP should not use any link layer 511 protection. 513 0x01 Extra Traffic 515 Indicates that the LSP should use links that are protecting 516 other (primary) traffic. Such LSPs may be preempted when 517 the links carrying the (primary) traffic being protected 518 fail. 520 2.3.7 Span Length: 522 Distance of fiber in WDM system. May be used as a routing metric or 523 to estimate delay. 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 |0| Type = TBD | Length = 4 | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Span Length | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 - Type: 15 bits = TBD 535 - Length: 16 bits = 4 537 - Span Length: 32 bits 539 Length of WDM span in meters. 541 2.4. Performance Summarization 543 A new type of message is added to LMP to advertise performance 544 monitoring (PM) information that is available within the WDM 545 transmission system. The PM information either is available on 546 demand, or may be advertised periodically. It should also be 547 possible to configure the system to send PM messages upon crossing 548 thresholds. For example, a message might be sent if the BER exceeds 549 a pre-configured threshold. PM information is different from link 550 characteristics in that it is more dynamic in nature and tends to be 551 measured over a period of time. 553 NOTE: The following messages will be added in a future version. It 554 will be possible to request information on a TE Link, Group, or Data 555 Link basis. It will also be possible to identify which performance 556 information is requested. 558 1. Performance Summarization Request 560 2. Performance Summarization Advertisement 562 3. Performance Summarization Acknowledgement 564 PM information should be advertised for one of the following reasons: 565 - For use in ascertaining a QoS level of a link for routing purposes 566 - To predict likely or impending failure so that a connection can 567 be rerouted proactively. 569 This information can be used to allow the system to reroute 570 connections proactively to avert potential failures, and so that 571 problems can be diagnosed. 573 The following Performance Monitoring information may be advertised 574 on a per component link or interface basis: 576 2.4.1 Line-Side Bit Error Rate (BER): 578 This TLV provides a report of the actual BER for the component link. 580 This is a measure of BER within the WDM system. It is measured on 581 streams flowing from the WDM node to the peer Node. 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 |0| Type = TBD | Length = 4 | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Reserved | BER | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 - Type: 15 bits = TBD 593 - Length: 16 bits = 4 595 - Reserved: 24 bits 597 Must be set to zero on transmit and ignored on receive. 599 - BER: 8 bits 601 The exponent from the BER representation as described in Section 602 2.3.5. For example, if the BER is 10 to the minus X, the BER 603 field is set to X. 605 2.4.2 SONET Monitoring Information 607 In addition to OPM measures, the transmission systems may exchange 608 SONET (OEO) monitoring information with the photonic switches, if 609 such information is available. Requirements for PM in SONET are 610 given in GR-253-CORE and some discussion of PM is also included in 611 G.874. PM parameters shall be gathered and reported over two time 612 intervals: 15-minute intervals and 24-hour intervals. The list given 613 below is a subset of the parameters listed in GR-253-CORE, and is 614 intended to be a minimal list required for making routing decisions. 615 Naturally, one also could implement the entire suite of SONET PM 616 parameters if one wanted to. 618 2.4.2.1 BER 620 Calculated via B1 error count 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 |0| Type = TBD | Length = 4 | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | BER-24H-1 | BER-24H-2 | BER-15M-1 | BER-15M-2 | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 - Type: 15 bits = TBD 632 - Length: 16 bits = 4 634 - BER-24H-1: 8 bits 636 BER for the previous 24 hour period. Represented as the BER 637 exponent as described in Section 2.3.5. 639 - BER-24H-2: 8 bits 641 BER for the current 24 hour period. Represented as the BER 642 exponent as described in Section 2.3.5. 644 - BER-15M-1: 8 bits 646 BER for the previous 15 minute period. Represented as the BER 647 exponent as described in Section 2.3.5. 649 - BER-15M-2: 8 bits 651 BER for the current 15 minute period. Represented as the BER 652 exponent as described in Section 2.3.5. 654 2.4.2.2 SES 656 Severely errored seconds. Collected via B1 error count. Used to 657 collect statistics on burst errors. 659 0 1 2 3 660 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 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 |0| Type = TBD | Length = 8 | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | SES-24H-1 | SES-24H-2 | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | SES-15M-1 | SES-15M-2 | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 - Type: 15 bits = TBD 671 - Length: 16 bits = 8 673 - SES-24H-1: 16 bits 675 SES for the previous 24 hour period. 677 - SES-24H-2: 16 bits 679 SES for the current 24 hour period. 681 - SES-15M-1: 16 bits 683 SES for the previous 15 minute period. 685 - SES-15M-2: 16 bits 687 SES for the current 15 minute period. 689 2.4.2.3 Protection switch count 691 Number of protection switch events during the count interval. 692 Provides an indication of possible link problems. If protection 693 switch chattering is occurring, the link is bad. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 |0| Type = TBD | Length = 8 | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | PSC-24H-1 | PSC-24H-2 | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | PSC-15M-1 | PSC-15M-2 | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 - Type: 15 bits = TBD 707 - Length: 16 bits = 8 709 - PSC-24H-1: 16 bits 711 Protection switch count for the previous 24 hour period. 713 - PSC-24H-2: 16 bits 715 Protection switch count for the current 24 hour period. 717 - PSC-15M-1: 16 bits 719 Protection switch count for the previous 15 minute period. 721 - PSC-15M-2: 16 bits 723 Protection switch count for the current 15 minute period. 725 2.4.2.4 STS pointer justifications 727 Number of times the SONET SPE pointer needed to be justified. 728 Provides an indication of the clocking accuracy over the optical 729 link. 731 0 1 2 3 732 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 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 |0| Type = TBD | Length = 8 | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | PJC-24H-1 | PJC-24H-2 | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | PJC-15M-1 | PJC-15M-2 | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 - Type: 15 bits = TBD 743 - Length: 16 bits = 8 745 - PJC-24H-1: 16 bits 747 Number of times the SONET SPE pointer needed to be justified 748 during the previous 24 hour period. 750 - PJC-24H-2: 16 bits 752 Number of times the SONET SPE pointer needed to be justified 753 during the current 24 hour period. 755 - PJC-15M-1: 16 bits 757 Number of times the SONET SPE pointer needed to be justified 758 during the previous 15 minute period. 760 - PJC-15M-2: 16 bits 762 Number of times the SONET SPE pointer needed to be justified 763 during the current 15 minute period. 765 2.5. Fault Localization 767 Fault management consists of three major functions: 769 1. Fault Detection 770 2. Fault Localization 771 3. Fault Notification 773 The actual Fault Detection mechanisms are the responsibility of the 774 individual nodes and are not specified as part of this protocol. 775 Fault detection mechanisms may include such things as bit error rate 776 (BER) exceeding a threshold, loss of signal (LOS) and certain 777 SONET-level errors. 779 The fault notification and localization procedure is essentially the 780 same as in the current version of LMP, however, it is executed at 781 two levels in the extended OXC-WDM LMP. 783 OXCs continue to execute the OXC-to-OXC fault localization as 784 currently specified. The main difference is that the WDM system may 785 initiate the process (both downstream and upstream). The WDM system 786 will also execute its own fault localization process that may allow 787 it to determine the location of the fault much more specifically 788 than the OXCs can. For example, the WDM transmission system may be 789 able to pinpoint the fault to a particular amplifier along a set of 790 fibers that can span 1000's of kilometers. 792 3. Security Considerations 794 The security considerations will be the same as in [LMP]. 796 4. References 798 [GMPLS] Berger, L., Ashwood-Smith, Peter, editors, "Generalized 799 MPLS - Signaling Functional Description", Internet Draft, 800 draft-ietf-mpls-generalized-signaling-02.txt, (work in 801 progress), March 2001. 803 [Bra96] Bradner, S., "The Internet Standards Process -- Revision 804 3," BCP 9, RFC 2026, October 1996. 806 [CBD00] Ceuppens, L., Blumenthal, D., Drake, J., Chrostowski, J., 807 Edwards, W. L., "Performance Monitoring in Photonic 808 Networks in Support of MPL(ambda)S", Internet Draft, 809 draft-ceuppens-mpls-optical-00.txt, (work in progress), 810 March 2000. 812 [DBC00] Drake, J., Blumenthal, D., Ceuppens, L., et al., 813 "Interworking between Photonic (Optical) Switches and 814 Transmission Systems over Optical Link Interface (OLI) 815 using Extensions to LMP", OIF Contribution oif2000.254, 816 (work in progress), November 2000. 818 [KRB00] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in 819 MPLS Traffic Engineering," Internet Draft, 820 draft-kompella-mpls-bundle-02.txt, (work in progress), 821 July 2000. 823 [KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF 824 Extensions in Support of Generalized MPLS," Internet 825 Draft, draft-kompella-ospf-extensions-00.txt, (work in 826 progress), July 2000. 828 [LMP] Lang, J., Mitra, K., Drake, J., Kompella, K., Rekhter, 829 Y., Berger, L., Saha, D., Basak, D., Sandick, H., Zinin, 830 A., "Link Management Protocol (LMP)", Internet Draft, 831 draft-ietf-mpls-lmp-01.txt, (work in progress), November 832 2000. 834 [SDH] ITU-T G.707, "Network node interface for the synchronous 835 digital hierarchy (SDH)", 1996. 837 [SONET] GR-253-CORE, "Synchronous Optical Network (SONET) 838 Transport Systems: Common Generic Criteria", Telcordia 839 Technologies, Issue 3, September 2000 841 [T.50] ITU-T T.50, "International Reference Alphabet (IRA) 842 (formerly International Alphabet No. 5 or IA5) 843 Information technology 7-bit coded character set for 844 information interchange.", 1992. 846 5. Author's Addresses 848 Andre Fredette Ed Snyder 849 PhotonEx Corporation PhotonEx Corporation 850 8C Preston Court 8C Preston Court 851 Bedford, MA 01730 Bedford, MA 01730 852 email: fredette@photonex.com email: esnyder@photonex.com 854 Jagan Shantigram Jonathan P. Lang 855 PhotonEx Corporation Calient Networks 856 8C Preston Court25 Castilian Drive 857 Bedford, MA 01730 Goleta, CA 93117 858 email: jagan@photonex.com email: jplang@calient.net 860 John Drake Gopala Tumuluri 861 Calient Networks Calient Networks 862 5853 Rue Ferrari 5853 Rue Ferrari 863 San Jose, CA 95138 San Jose, CA 95138 864 email: jdrake@calient.net email: krishna@calient.net 866 Rohit Goyal Stuart Brorson 867 Axiowave Networks Axiowave Networks 868 100 Nickerson Road 100 Nickerson Road 869 Marlborough, MA 01752 Marlborough, MA 01752 870 email: rgoyal@axiowave.com email: sdb@axiowave.com 872 Ram Krishnan W. L. Edwards 873 Axiowave Networks iLambda Networks 874 100 Nickerson Road Aspen, CO 875 Marlborough, MA 01752 email: texas@ilambda.com 876 email: ram@axiowave.com 878 Yong Xue John Yu 879 UUNET/WorldCom Zaffire, Inc 880 22001 Loudoun County Parkway 2630 Orchard Parkway 881 Ashburn, VA 20148 San Jose, CA 95134 882 email: yxue@uu.net email: jzyu@zaffire.com 884 Sudheer Dharanikota 885 Nayna Networks, Inc. 886 157 Topaz Drive, 887 Milpitas, CA 95035 888 email: sudheer@nayna.com