idnits 2.17.1 draft-fredette-lmp-wdm-02.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 seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 instances of lines with non-ascii characters in the document. == 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], [OLI]), 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 269: '...ndependently and MUST be maintained se...' RFC 2119 keyword, line 278: '...ween the sessions, it MUST be possible...' RFC 2119 keyword, line 280: '... MUST be possible for an OXC-OXC LMP...' RFC 2119 keyword, line 343: '... node, it MUST reply to the Config M...' RFC 2119 keyword, line 386: '...able and the N bit MUST be set to N=0....' (18 more instances...) 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 (July 2001) is 8292 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) == Missing Reference: 'RFC2026' is mentioned on line 36, but not defined == Unused Reference: 'Bra96' is defined on line 1208, but no explicit reference was found in the text == Unused Reference: 'DBC00' is defined on line 1211, but no explicit reference was found in the text == Unused Reference: 'KRB00' is defined on line 1217, but no explicit reference was found in the text == Unused Reference: 'SDH' is defined on line 1237, but no explicit reference was found in the text == Unused Reference: 'SONET' is defined on line 1240, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-02 -- 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' -- Unexpected draft version: The latest known version of draft-ietf-mpls-lmp is -02, but you're referring to -03. (However, the state information for draft-kompella-ospf-extensions is not up-to-date. The last update was unsuccessful) -- Possible downref: Normative reference to a draft: ref. 'LMP' -- Possible downref: Normative reference to a draft: ref. 'OLI' -- Possible downref: Non-RFC (?) normative reference: ref. 'SDH' -- Possible downref: Non-RFC (?) normative reference: ref. 'SONET' Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Brorson (Axiowave Networks) 3 Internet Draft S. Dharanikota (Nayna Networks, Inc) 4 Expiration Date: January 2001 J. Drake (Calient Networks) 5 David Drysdale (Data Connection) 6 W. L. Edwards (iLambda Networks) 7 Adrian Farrel (Movaz Networks) 8 R. Goyal (Axiowave Networks) 9 Monika Jaeger (T-systems) 10 R. Krishnan (Axiowave Networks) 11 Raghu Mannam (Hitachi Telecom) 12 Eric Mannie (Ebone (GTS)) 13 Dimitri Papadimitriou (Alcatel IPO-NSG) 14 J. Shantigram (PhotonEx Corp.) 15 E. Snyder (PhotonEx Corp.) 16 George Swallow (Cisco Systems) 17 G. Tumuluri (Calient Networks) 18 Y. Xue (UUNET/WorldCom) 19 Lucy Yong (Williams Communications) 20 J. Yu (Zaffire, Inc) 22 Editors: 23 Andre Fredette (PhotonEx Corp.) 24 Jonathan Lang (Calient Networks) 26 July 2001 28 Link Management Protocol (LMP) for DWDM Optical Line Systems 30 draft-fredette-lmp-wdm-02.txt 32 Status of this Memo 34 This document is an Internet-Draft and is in full conformance with 35 all provisions of Section 10 of RFC2026 [RFC2026]. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six 43 months and may be updated, replaced, or obsoleted by other documents 44 at any time. It is inappropriate to use Internet- Drafts as 45 reference material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 ABSTRACT 54 A suite of protocols is being developed in the IETF to allow 55 networks consisting of photonic switches (PXCs), optical 56 crossconnects (OXCs), routers, switches, DWDM optical line systems 57 (OLSs), and optical add-drop multiplexors (OADMs) to use an MPLS- 58 based control plane to dynamically provision resources and to 59 provide network survivability using protection and restoration 60 techniques. As part of this protocol suite, the Link Management 61 Protocol (LMP) [LMP] is defined to "maintain control channel 62 connectivity, verify component link connectivity, and isolate link, 63 fiber, or channel failures within the network." In it's present 64 form, [LMP] focuses on peer communications (eg. OXC-to-OXC). In 65 this document we propose extensions to LMP for use with OLSs. These 66 extensions are intended to satisfy the "Optical Link Interface 67 Requirements" described in [OLI]. 69 CONTENTS 70 1. Introduction.......................................................5 71 2. LMP Extensions for Optical Line Systems............................7 72 2.1. Control Channel Management.......................................8 73 2.2. Link Verification................................................8 74 2.3. Link Summarization...............................................8 75 2.3.1. Link Group ID..................................................9 76 2.3.2. Link Descriptor...............................................10 77 2.3.3. Shared Risk Link Group Identifier (SRLG):.....................11 78 2.3.4. Bit Error Rate (BER) Estimate.................................11 79 2.3.5. Optical Protection............................................12 80 2.3.6. Span Length:..................................................13 81 2.3.7. Administrative Group (Color)..................................13 82 2.4. Fault Management................................................14 83 2.4.1. ChannelStatus Message (MsgType = TBD).........................14 84 2.4.1.1. Channel Status TLV..........................................15 85 2.4.1.2. Group Status TLV............................................16 86 2.4.1.3. Message ID TLV..............................................17 87 2.4.2. ChannelStatusAck Message (MsgType = TBD)......................17 88 2.4.3. ChannelStatusReq Message (MsgType = TBD)......................18 89 2.4.3.1. Channel Entity TLV..........................................19 90 2.5. Trace Monitoring................................................19 91 2.5.1. TraceMonitor Message (MsgType = TBD)..........................19 92 2.5.1.1. Trace TLV...................................................20 93 2.5.2. TraceMonitorAck Message (MsgType = TBD).......................21 94 2.5.3. TraceMonitorNack Message (MsgType = TBD)......................22 95 2.5.4. TraceMismatch Message (MsgType = TBD).........................22 96 2.5.5. TraceMismatchAck Message (MsgType = TBD)......................23 97 2.5.6. TraceReq Message (MsgType = TBD)..............................24 98 2.5.7. TraceReport Message (MsgType = TBD)...........................24 99 3. Security Considerations...........................................25 100 4. Work Items........................................................25 101 5. References........................................................26 102 6. Author's Addresses................................................27 103 SUMMARY FOR SUB-IP RELATED INTERNET DRAFTS 104 (Section Requested by Bert and Scott) 106 SUMMARY 108 This work is motivated by two main issues. The first is the need to 109 enhance the fault detection and recovery support for photonic 110 switches (PXCs), and the second is to enhance the discovery of link 111 characteristics for optical networks in general. 113 GMPLS is being developed to allow networks consisting of photonic 114 switches (PXCs), optical crossconnects (OXCs), routers, switches and 115 optical line systems (OLS) (or DWDM systems) to use an MPLS-based 116 control plane to dynamically provision resources and to provide 117 network survivability using protection and restoration techniques. 118 As part of this protocol suite, the Link Management Protocol (LMP) 119 [LMP] is defined to "maintain control channel connectivity, verify 120 component link connectivity, and isolate link, fiber, or channel 121 failures within the network." In it's present form, [LMP] focuses 122 on peer communications (e.g., OXC-to-OXC). In this document we 123 propose extensions to LMP for use with optical line systems. These 124 extensions allow the OLS to inform attached devices, such as routers 125 or PXCs, of (1) link properties needed for routing/signalling and 126 (2) link failures that can be used to drive failure recovery 127 protocols. 129 RELATED DOCUMENTS 131 http://www.ietf.org/internet-drafts/draft-ietf-mpls-lmp-02.txt 132 http://www.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt 134 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 136 lmp-wdm fits in the Control part of the sub-ip work. 138 WHY IS IT TARGETED AT THIS WG 140 lmp-wdm enhances the ability of circuit switches and routers using 141 MPLS-based control protocols to dynamically discover link properties 142 and to learn about link status. The link properties can be useful 143 during signalling of paths, and the link status information is 144 essential for fault detection and recovery. Furthermore, lmp-wdm is 145 independent of any signalling protocol, so it can be used by both 146 distributed control system, such as GMPLS, and centralized 147 management systems. 149 Therefore, lmp-wdm supports the following CCAMP objectives: 151 . Define signalling protocols and measurement protocols such that 152 they support multiple physical path and tunnel technologies 153 (e.g., O-O and O-E-O optical switches, ATM and Frame Relay 154 switches, MPLS, GRE) using input from technology-specific 155 working groups such as MPLS, IPO, etc. 157 . Define signalling and measurement protocols that are 158 independent of each other. This allows applications other than 159 the signalling protocol to use the measurement protocol; it 160 also allows the signalling protocol to use knowledge obtained 161 by means other than the measurement protocol. 163 . Abstract link and path properties needed for link and path 164 protection. Define signalling mechanisms for path protection, 165 diverse routing and fast path restoration. Ensure that multi- 166 layer path protection and restoration functions are achievable 167 using the defined signalling and measurement protocols, either 168 separately or in combination. 170 . Define how the properties of network resources gathered by the 171 measurement protocol can be distributed in existing routing 172 protocols, such as OSPF and IS-IS. 174 JUSTIFICATION 176 draft-fredette-lmp-wdm-00.txt (lmp-wdm) is a protocol proposal 177 intended to satisfy the optical link interface (OLI) requirements 178 (draft-many-oli-reqts-00.txt - described separately). The 179 requirements document has achieved consensus in the CCAMP working 180 group. lmp-wdm has been discussed in the past two ccamp sessions 181 and a competing proposal, draft-sahay-ccamp-ntip-00.txt (ntip), was 182 discussed in the last one. There has been a great deal of interest 183 in this work by both network operators and vendors. 185 1. Introduction 187 Future networks will consist of photonic switches (PXCs), optical 188 crossconnects (OXCs), routers, switches, DWDM optical line systems 189 (OLSs), and optical add-drop multiplexors (OADMs) that use the GMPLS 190 control plane to dynamically provision resources and to provide 191 network survivability using protection and restoration techniques. 192 A pair of nodes (e.g., a PXC and an OLS) may be connected by 193 thousands of fibers. Furthermore, multiple fibers and/or multiple 194 wavelengths may be combined into a single bundled link. [LMP] 195 Defines the Link Management Protocol (LMP) to "maintain control 196 channel connectivity, verify component link connectivity, and 197 isolate link, fiber, or channel failures within the network." In 198 it's present form, [LMP] focuses on peer communications (eg. OXC- 199 to-OXC) as illustrated in Figure 1. In this document, extensions to 200 LMP for use with OLSs are proposed. These extensions are intended 201 to satisfy the "Optical Link Interface Requirements" described in 202 [OLI]. It is assumed that the reader is familiar with LMP as 203 defined in [LMP]. 205 +------+ +------+ +------+ +------+ 206 | | ----- | | | | ----- | | 207 | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | 208 | | ----- | | | | ----- | | 209 +------+ +------+ +------+ +------+ 210 ^ ^ 211 | | 212 +----------------------LMP----------------------+ 214 Figure 1: Current LMP Model 216 A great deal of information about a link between two OXCs is known 217 by the OLS. Exposing this information to the control plane via LMP 218 can improve network usability by further reducing required manual 219 configuration and also greatly enhancing fault detection and 220 recovery. Fault detection is particularly an issue when the network 221 is using all-optical photonic switches (PXC). Once a connection is 222 established, PXCs have only limited visibility into the health of 223 the connection. Even though the PXC is all-optical, long-haul OLSs 224 typically terminate channels electrically and regenerate them 225 optically, which presents an opportunity to monitor the health of a 226 channel between PXCs. LMP-WDM can then be used by the OLS to 227 provide this information to the PXC using LMP-WDM. The model for 228 extending LMP to OLSs is shown in Figure 2. 230 +------+ +------+ +------+ +------+ 231 | | ----- | | | | ----- | | 232 | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | 233 | | ----- | | | | ----- | | 234 +------+ +------+ +------+ +------+ 235 ^ ^ ^ ^ ^ ^ 236 | | | | | | 237 | +-----LMP-----+ +-----LMP----+ | 238 | | 239 +----------------------LMP----------------------+ 241 Figure 2: Extended LMP Model 243 In this model, an OXC may have multiple LMP sessions corresponding 244 to multiple peering relationships. At each level, LMP provides link 245 management functionality (i.e., control channel management, physical 246 connectivity verification, link property correlation) for that 247 peering relationship. For example, the OXC-OXC LMP sessions in 248 Figure 2 are used to build traffic-engineering (TE) links for GMPLS 249 signaling and routing, and are managed as described in [LMP]. At the 250 transport level, the OXC-OLS LMP session (shown in Figure 2) is used 251 to augment knowledge about the links between the OXCs. The 252 management of these LMP sessions is discussed in this draft. It is 253 important to note the an OXC may peer with one or more OLSs and an 254 OLS may peer with one or more OXCs. 256 Although there are many similarities between an OXC-OXC LMP session 257 and an OXC-OLS LMP session, particularly for control management and 258 link verification, there are some differences as well. These 259 differences can primarily be attributed to the nature of an OXC-OLS 260 link, and the purpose of OXC-OLS LMP sessions. As previously 261 mentioned, the OXC-OXC links provide the basis for GMPLS signaling 262 and routing at the optical layer. The information exchanged over 263 LMP-WDM sessions is used to augment knowledge about the links 264 between OXCs. 266 In order for the information exchanged over the OXC-OLS LMP sessions 267 to be used by the OXC-OXC session, the information must be 268 coordinated by the OXC. However, the two LMP sessions are run 269 independently and MUST be maintained separately. One critical 270 requirement when running an OXC-OLS LMP session is the ability of 271 the OLS to make a data link transparent when not doing the 272 verification procedure. This is because the same data link may be 273 verified between OXC-OLS and between OXC-OXC. Currently, the 274 BeginVerify procedure is used to coordinate the Test procedure (and 275 hence the transparency/opaqueness of the data links) as described in 276 [LMP]. 278 To maintain independence between the sessions, it MUST be possible 279 for the LMP sessions to come up in any order. In particular, it 280 MUST be possible for an OXC-OXC LMP session to come up without an 281 OXC-OLS LMP session being brought up, and vice-versa. 283 This draft focuses on extensions required for use with opaque 284 transmission systems. Work is ongoing in the area of completely 285 transparent wavelength routing; however, it is premature to identify 286 the necessary characteristics to advertise. That said, the protocol 287 described in this document provides the necessary framework in which 288 to advertise additional information as it is deemed appropriate. 290 Additional details about the extensions required for LMP are 291 outlined in the next section. 293 2. LMP Extensions for Optical Line Systems 295 As currently defined, LMP consists of four types of functions: 297 1. Control Channel Management 298 2. Link Verification 299 3. Link Summarization 300 4. Fault Management 302 All four functions are supported in LMP-WDM. Additionally, a trace 303 monitoring function is added. 305 In this document we follow the convention of [LMP] and use the term 306 "data link" to refer to either "component links" or "ports". 308 It is very important to understand the subtle distinctions between 309 the different types of links being considered in the extended LMP- 310 WDM. For example, in Figure 2 when OXC1 and OXC2 complete the 311 verify process, the links being verified are the end-to-end links 312 between the OXC's. It is the TE link composed of these "data links" 313 that are advertised in the routing protocols and used for the 314 purposes of connection setup. The verify procedure between OXC1 and 315 OLS1, on the other hand verifies the shorter link between these two 316 nodes. However, each of these shorter links is a segment of one of 317 the larger end-to-end links. The verify serves two functions: to 318 verify connectivity and exchange handles by which each data link is 319 referred. Furthermore, it is up to the OXC to correlate the handles 320 between the various LMP sessions. 322 Once a control channel has been established and the OXC-OLS 323 verification procedure has been completed successfully, the OXC and 324 OLS may exchange information regarding link configuration (link 325 summarization). An OXC may also receive notification regarding the 326 operational status from an OLS (ChannelStatus). 328 In subsequent sections, specific changes are proposed to extend LMP 329 to work with OLSs. 331 2.1. Control Channel Management 333 As in [LMP], we do not specify the exact implementation of the 334 control channel; it could be, for example, a separate wavelength or 335 fiber, an Ethernet link, an IP tunnel through a separate management 336 network, or the overhead bytes of a data link. 338 The control channel management for OXC-OLS links is the same as for 339 OXC-OXC links, as described in [LMP]. A flag in the LMP Common 340 Header is used identify the transmitting node as an OLS. This 341 informs the receiving node that the LMP-WDM extensions will be used 342 for the session. If the LMP-WDM extensions are not supported by the 343 node, it MUST reply to the Config Message with a ConfigNack Message. 345 2.2. Link Verification 347 The Test procedure used with OLSs is the same as described in [LMP]. 348 The VerifyTransportMechanism (included in the BeginVerify and 349 BeginVerifyAck messages) is used to allow nodes to negotiate a link 350 verification method and is essential for transmission systems which 351 have access to overhead bytes rather than the payload. The VerifyId 352 (provided by the remote node in the BeginVerifyAck message, and used 353 in all subsequent Test messages) is used to differentiate Test 354 messages from different LMP sessions. 356 2.3. Link Summarization 358 As in [LMP], the LinkSummary message is used to synchronize the 359 Interface Ids and correlate the properties of the TE link. 360 Additional type-length values (TLVs) are defined to extend the 361 LinkSummary message to include link characteristics. The TLVs 362 described in the following subsections are transmitted as Data Link 363 Sub-TLVs in the Data Link TLV (see [LMP]). The link 364 characteristics, in general, are those characteristics needed by the 365 control plane for constraint-based routing and connection 366 establishment. 368 The format of the Data Link Sub-TLVs follows the LMP TLV format 369 described in [LMP]. The TLV format is shown below for readability: 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |N| Type | Length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | | 377 // (TLV Object) // 378 | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 N: 1 bit 382 The N flag indicates if the object is a negotiable parameter 383 (N=1) or a non-negotiable parameter (N=0). 385 Note: none of the Data Link TLVs that are defined in LMP-WDM 386 are negotiable and the N bit MUST be set to N=0. 388 Type: 15 bits 390 The Type field indicates the TLV type. 392 Length: 16 bits 394 The Length field indicates the length of the TLV object in 395 bytes. 397 The following Link Characteristics are advertised on a per data link 398 basis. 400 2.3.1. Link Group ID 402 A local ID assigned to a group of data links. This ID can be used 403 to reduce the control traffic in the case of a failure by enabling 404 the systems to send a single message for a group instead of 405 individual messages for each member of the group. A link may be a 406 member of multiple groups. This is achieved by presenting multiple 407 Link Group ID TLVs in the LinkSummary message. 409 The Link Group ID feature allows Link Groups to be assigned based 410 upon the types of fault correlation and aggregation supported by a 411 given OLS. 413 For example, an OLS could create a Link Group for each laser in the 414 OLS. This group could then be associated with user ports during 415 discovery/initialization time. Multiple user ports might even be 416 associated with a single group (depending on the kind of 417 multiplexing supported in the system). If a laser fails, the OLS 418 can report a failure for the group. In the OXC this translates into 419 the failure of the associated link or links. Another group could be 420 assigned for a fiber to report all ports down that are associated 421 with that fiber if LOS is detected at the fiber level. Depending on 422 the physical OLS implementation, it may make sense to allocate other 423 groups, such as all ports on a particular circuit pack. With this 424 method, the OXC only needs to know about the externally visible 425 ports. The OLS can associate the ports with logical groups and the 426 OXC doesn't need to know anything about the physical OLS 427 implementation or how ports are multiplexed electrically or 428 optically within the system. 430 The format of the Link Group ID TLV is as follows: 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 |0| Type = TBD | Length = 4 | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Group ID | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Type: 15 bits = TBD 442 Length: 16 bits = 4 444 Group ID: 32 bits 446 Group ID 0xFFFFFFFF is reserved and indicates all data links in a 447 TE link. All data links are members of Link Group 0xFFFFFFFF by 448 default. 450 2.3.2. Link Descriptor 452 The Link Descriptor TLV represents the characteristics of the link 453 comprising the encoding type and bandwidth characteristics. This 454 information is needed for constructing a circuit. The OXC must 455 match the link information between incoming and outgoing interfaces 456 for a given path. 458 Note: This information may be a prerequisite for running the verify 459 protocol, thus it may be redundant when verify is being used. 461 The encoding for the information in this TLV are the same as those 462 for the link descriptor sub-TLV defined in [KRB00a]. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 |0| Type = TBD | Length = 12 | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Link Encoding Type | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Minimum Reservable Bandwidth | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Maximum Reservable Bandwidth | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 Type: 15 bits = TBD 478 Length: 16 bits = 12 479 Link Encoding Type: 32 bits 481 See [KRB00a] for encoding. 483 Minimum Reservable Bandwidth: 32 bits 485 See [KRB00a] for encoding. 487 Maximum Reservable Bandwidth: 32 bits 489 See [KRB00a] for encoding. 491 2.3.3. Shared Risk Link Group Identifier (SRLG): 493 SRLGs of which the link is a member. This information is manually 494 configured on an OLS by the user. Used for diverse path computation. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 |0| Type = TBD | 4 * No. of SRLGs in link | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Shared Risk Link Group Value | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | ............ | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Shared Risk Link Group Value | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Type: 15 bits = TBD 510 Length: 16 bits = 4 * No. of SRLGs in link 512 Shared Risk Link Group Value: 32 bits 514 List as many SRLGs as apply. 516 2.3.4. Bit Error Rate (BER) Estimate 518 This TLV provides an estimate of the BER for the data link. 520 The bit error rate (BER) is the proportion of bits that have errors 521 relative to the total number of bits received in a transmission, 522 usually expressed as ten to a negative power. For example, a 523 transmission might have a BER of "10 to the minus 13", meaning that, 524 out of every 10,000,000,000,000 bits transmitted, one bit may be in 525 error. The BER is an indication of overall signal quality. 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 |0| Type = TBD | Length = 4 | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Reserved | BER | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Type: 15 bits = TBD 537 Length: 16 bits = 4 539 Reserved: 24 bits 541 Must be set to zero on transmit and ignored on receive. 543 BER: 8 bits 545 The exponent from the BER representation described above. For 546 example, if the BER is 10 to the minus X, the BER field is set to 547 X. 549 2.3.5. Optical Protection 551 Whether the OLS protects the link internally. This information can 552 be used as a measure of quality of the link. It may be advertised 553 by routing and used by signaling as a selection criterion as 554 described in [GMPLS]. 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 |0| Type = TBD | Length = 4 | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Reserved | Link Flags| 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Type: 15 bits = TBD 566 Length: 16 bits = 4 568 Reserved: 24 bits 570 Must be set to zero on transmit and ignored on receive. 572 Link Flags: 6 bits 573 Encoding for Link Flags can be found in [GMPLS]. 575 2.3.6. Span Length: 577 Distance of fiber in OLS. May be used as a routing metric or to 578 estimate delay. 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 |0| Type = TBD | Length = 4 | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Span Length | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Type: 15 bits = TBD 590 Length: 16 bits = 4 592 Span Length: 32 bits 594 Length of WDM span in meters expressed as an unsigned integer. 596 2.3.7. Administrative Group (Color) 598 The administrative group (or Color) to which the data link belongs. 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 |0| Type = TBD | Length = 4 | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Administrative Group | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Type: 15 bits = TBD 610 Length: 16 bits = 4 612 Administrative Group: 32 bits 614 A 32 bit value. 616 2.4. Fault Management 618 Fault management consists of three major functions: 620 1. Fault Detection 621 2. Fault Localization 622 3. Fault Notification 624 The actual Fault Detection mechanisms are the responsibility of the 625 individual nodes and are not specified as part of this protocol. 626 Fault detection mechanisms may include such things as bit error rate 627 (BER) exceeding a threshold, loss of signal (LOS) and certain SONET- 628 level errors. 630 The fault notification and localization procedure is essentially the 631 same as in the current version of LMP, however, it is executed at 632 two levels in the extended OXC-OLS LMP. 634 OXCs continue to execute the OXC-to-OXC fault localization as 635 currently specified. The main difference is that the OLS may 636 initiate the process (both downstream and upstream). It is 637 important to note that the OLS does not participate in end-to-end 638 fault localization as described in [LMP]. 640 The OLS may also execute its own fault localization process that may 641 allow it to determine the location of the fault much more 642 specifically than the OXCs can. For example, the OLS may be able to 643 pinpoint the fault to a particular amplifier along a set of fibers 644 that can span 1000's of kilometers. 646 To report individual link failure and recovery conditions, LMP-WDM 647 uses a new message called the ChannelStatus Message. The 648 ChannelStatus Message is described below. 650 2.4.1. ChannelStatus Message (MsgType = TBD) 652 The ChannelStatus message is sent over the control channel and is 653 used to report the operational status of a data link. While 654 channels are active, a ChannelStatus Message MUST be sent every time 655 that the status of a channel changes. A channel status message MUST 656 also be sent if a ChannelStatusReq Message is received. 658 Different acknowledgement rules are used depending on why the 659 ChannelStatus message is being sent. If an unsolicited 660 ChannelStatus message is sent due to a change in status of a data 661 link, the receiving node MUST acknowledge the ChannelStatus message 662 with a ChannelStatusAck. However, if the ChannelStatus message is 663 being sent in response to a ChannelStatusReq message, the 664 ChannelStatus message serves as the acknowledgement for the 665 ChannelStatusReq message. Therefore, the following acknowledgement 666 rules are used: 668 1. If a ChannelStatus message is sent in response to a 669 ChannelStatusReq message, the ChannelStatus message MUST 670 include the Message ID TLV. 672 2. A neighboring node that receives a ChannelStatus message that 673 does not include the Message ID TLV message MUST respond with a 674 ChannelStatusAck message. 676 The format of the ChannelStatus message is as follows: 678 ::= 680 The format of the ChannelStatus object is as follows: 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | MessageId | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | | 688 // (Status TLVs) // 689 | | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 MessageId: 32 bits 694 When combined with the Local TE Link Id in the common header of 695 the received packet, the MessageId field uniquely identifies a 696 message. This value is incremented and only decreases when the 697 value wraps. This is used for message acknowledgement in the 698 ChannelStatusAck message. 700 The ChannelStatus message MUST include at least one Status TLV. To 701 specify a status for the whole TE Link, use the group status TLV and 702 link group ID 0xFFFFFFFF. 704 2.4.1.1. Channel Status TLV 706 0 1 2 3 707 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 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 |0| TBD | Length | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Local Interface Id | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Condition | (Reserved) | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 The Channel Status TLV is non-negotiable. 718 Length: 16 bits 720 The Length is in bytes (see LMP TLV format). 722 Local Interface Id: 32 bits 724 This is the local Interface Id (either Port Id or Component 725 Interface Id) of the data link that has failed. This is within 726 the scope of the TE Link Id. 728 Condition: 8 bits 730 Status Condition: 732 Value Condition Description 733 ----- --------- ----------- 734 1 Signal Okay Data link is operational. 735 (OK) 736 2 Signal Degrade A soft failure caused by a BER 737 (SD) exceeding a preselected threshold. The 738 specific BER used to define the 739 threshold is may be configured, but is 740 typically in the range of 10-5 to 10-9. 741 3 Signal Fail A hard signal failure including (but 742 (SF) not limited to) loss of signal (LOS), 743 loss of frame (LOF), Line AIS, or a BER 744 (BIP-8 measure through B1/B2) exceeding 745 a specified value. 747 2.4.1.2. Group Status TLV 749 0 1 2 3 750 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 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 |0| TBD | Length | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Link Group Id | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Condition | (Reserved) | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 The Group Status TLV is non-negotiable. 761 Length: 16 bits 763 The Length is in bytes (see LMP TLV format). 765 Link Group Id: 32 bits 767 This is the Link Group ID. 769 Condition: 8 bits 771 The same conditions described in Section 2.4.1.1 are used. 773 2.4.1.3. Message ID TLV 775 The Message ID TLV MUST be included in the ChannelStatus message if 776 it is being sent in response to a ChannelStatusReq message. 778 0 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 |0| TBD | Length | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | MessageId | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Remote TE Link Id | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 MessageId: 32 bits 790 This is copied from the ChannelStatusReq message being 791 acknowledged. 793 Remote TE Link Id: 32 bits 795 This is copied from the Common Header of the ChannelStatusReq 796 message being acknowledged. 798 2.4.2. ChannelStatusAck Message (MsgType = TBD) 800 The ChannelStatusAck message is sent in response to a ChannelStatus 801 message that does not include the Message ID TLV. 803 The ChannelStatusAck message is used to indicate that all of the 804 status TLVs in the ChannelStatus message have been receive without 805 error. 807 The format is as follows: 808 ::= 810 The ChannelStatusAck object has the following format: 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | MessageId | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Remote TE Link Id | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 MessageId: 32 bits 822 This is copied from the ChannelStatus message being 823 acknowledged. 825 Remote TE Link Id: 32 bits 827 This is copied from the Common Header of the ChannelStatus 828 message being acknowledged. 830 2.4.3. ChannelStatusReq Message (MsgType = TBD) 832 The ChannelStatusReq message is sent over the control channel and is 833 used to request the status of one or more data link(s). 835 A neighboring node that receives a ChannelStatusReq message MUST 836 respond with a ChannelStatus message. The format is as follows: 838 ::= 840 The format of the ChannelStatusReq object is as follows: 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | MessageId | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | | 848 // (Channel Entity TLVs) // 849 | | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 MessageId: 32 bits 854 When combined with the Local TE Link Id in the common header of 855 the received packet, the MessageId field uniquely identifies a 856 message. This value is incremented and only decreases when the 857 value wraps. This is used for message acknowledgement in the 858 ChannelStatusReqAck message. 860 A ChannelStatusReq Message MAY include zero or more Channel Entity 861 TLVs. If no Entity TLVs are included, the receiving node MUST report 862 on all data links within the TE link. 864 2.4.3.1. Channel Entity TLV 866 0 1 2 3 867 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 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 |0| TBD | Length | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Local Interface Id | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 The Channel Entity TLV is non-negotiable. 876 Length: 16 bits 878 The Length is in bytes (see LMP TLV format). 880 Local Interface Id: 32 bits 882 This is the local Interface Id (either Port Id or Component 883 Interface Id) of the data link for which status is requested. 884 This is within the scope of the TE Link Id. 886 2.5. Trace Monitoring 888 The trace monitoring features described in this section allow a PXC 889 to do basic trace monitoring on circuits by using the capabilities 890 on an attached OLS. 892 . An OLS Client may request the OLS to monitor a link for a 893 specific pattern in the overhead using the TraceMonitorReq 894 Message. An example of this overhead is the SONET Section 895 Trace message transmitted in the J0 byte. If the actual trace 896 message does not match the expected trace message, the OLS MUST 897 report the mismatch condition. 899 . An OLS client may request the value of the current trace 900 message on a given data link using the TraceReq Message. 902 2.5.1. TraceMonitor Message (MsgType = TBD) 904 The TraceMonitor message is sent over the control channel and is 905 used to request an OLS to monitor one or more data links for a 906 specific trace value. An OLS MUST respond to a TraceMonitor message 907 with either a TraceMonitorAck or TraceMonitorNack Message. 909 ::= 911 The format of the TraceMonitor object is as follows: 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | MessageId | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | | 919 // (Trace TLVs) // 920 | | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 MessageId: 32 bits 925 When combined with the Local TE Link Id in the common header of 926 the received packet, the MessageId field uniquely identifies a 927 message. This value is incremented and only decreases when the 928 value wraps. This is used for message acknowledgement in the 929 TraceMonitorAck or TraceMonitorNack message. 931 The TraceMonitor message MUST include at least one Trace TLV. 933 2.5.1.1. Trace TLV 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 |0| TBD | Length | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Local Interface Id | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Trace Type | Trace Length | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | | 945 // Trace Message // 946 | | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 The Trace TLV is non-negotiable. 951 Length: 16 bits 953 The Length is in bytes (see LMP TLV format). 955 Local Interface Id: 32 bits 956 This is the local Interface Id (either Port Id or Component 957 Interface Id) of the data link for which the trace monitoring 958 is requested. This is within the scope of the TE Link Id. 960 Trace Type: 16 bits 962 The type of the trace message: 964 1 � SONET Section Trace (J0 Byte) 965 2 � SONET Path Trace (J1 Byte) 966 3 � SDH Section Trace (J0 Byte) 967 4 � SDH Path Trace (J1 Byte) 969 Other types TBD. 971 Trace Length: 16 bits 973 The Length in bytes of the trace message provided. 975 Trace Message: 977 Expected message. The valid length and value combinatios are 978 determined by the specific technology (e.g., SONET or SDH) and 979 are beyond the scope of this document. The message MUST be 980 padded with zeros to a 32-bit boundary, if necessary. 982 2.5.2. TraceMonitorAck Message (MsgType = TBD) 984 The TraceMonitorAck message is used to indicate that all of the 985 Trace TLVs in the TraceMonitor message have been received and 986 processed correctly. 988 The format is as follows: 989 ::= 991 The TraceMonitorAck object has the following format: 993 0 1 2 3 994 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 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | MessageId | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Remote TE Link Id | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 MessageId: 32 bits 1003 This is copied from the TraceMonitor message being 1004 acknowledged. 1006 Remote TE Link Id: 32 bits 1007 This is copied from the Common Header of the TraceMonitor 1008 message being acknowledged. 1010 2.5.3. TraceMonitorNack Message (MsgType = TBD) 1012 The TraceMonitorNack message is used to indicate that one or more of 1013 the Trace TLVs in the TraceMonitor message was not processed 1014 correctly. This could be because the trace monitoring requested is 1015 not supported or there was an error in one of the values. 1017 The format is as follows: 1018 ::= 1020 The TraceMonitorNack object has the following format: 1022 0 1 2 3 1023 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 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | MessageId | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Remote TE Link Id | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | | 1030 // (Rejected Trace TLVs) // 1031 | | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 MessageId: 32 bits 1036 This is copied from the TraceMonitor message being 1037 acknowledged. 1039 Remote TE Link Id: 32 bits 1041 This is copied from the Common Header of the TraceMonitor 1042 message being acknowledged. 1044 Rejected Trace TLVs: 32 bits 1046 Trace TLVs that were not accepted. Copied from TraceMonitor 1047 message. If none are included, it means that all Trace TLVs 1048 are rejected. 1050 2.5.4. TraceMismatch Message (MsgType = TBD) 1052 The TraceMismatch message is sent over the control channel and is 1053 used to report a trace mismatch on a data link for which trace 1054 monitoring was requested. 1056 A neighboring node that receives a TraceMismatch message MUST 1057 respond with a TraceMismatchAck message. The format is as follows: 1059 ::= 1061 The format of the TraceMismatch object is as follows: 1063 0 1 2 3 1064 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 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | MessageId | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 | | 1069 // Local Interface Ids // 1070 | | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 MessageId: 32 bits 1075 When combined with the Local TE Link Id in the common header of 1076 the received packet, the MessageId field uniquely identifies a 1077 message. This value is incremented and only decreases when the 1078 value wraps. This is used for message acknowledgement in the 1079 TraceMismatchAck message. 1081 Local Interface Id: 32 bits per Id 1083 This is the local Interface Id (either Port Id or Component 1084 Interface Id) of the data link that has a trace mismatch. This 1085 is within the scope of the TE Link Id. Multiple Local 1086 Interface Ids may be reported in the same message. 1088 2.5.5. TraceMismatchAck Message (MsgType = TBD) 1090 The TraceMismatchAck message is used to acknowledge receipt of a 1091 TraceMismatch message. 1093 The format is as follows: 1094 ::= 1096 The TraceMismatchAck object has the following format: 1098 0 1 2 3 1099 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 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | MessageId | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Remote TE Link Id | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 MessageId: 32 bits 1107 This is copied from the TraceMismatch message being 1108 acknowledged. 1110 Remote TE Link Id: 32 bits 1112 This is copied from the Common Header of the TraceMismatch 1113 message being acknowledged. 1115 2.5.6. TraceReq Message (MsgType = TBD) 1117 The TraceReq message is sent over the control channel and is used to 1118 request the current trace value of indicated data links. 1120 A node that receives a TraceReq message MUST respond with a 1121 TraceReport message. The format is as follows: 1123 ::= 1125 The format of the TraceReq object is as follows: 1127 0 1 2 3 1128 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 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | MessageId | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | | 1133 // (Channel Entity TLVs) // 1134 | | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 MessageId: 32 bits 1139 When combined with the Local TE Link Id in the common header of 1140 the received packet, the MessageId field uniquely identifies a 1141 message. This value is incremented and only decreases when the 1142 value wraps. This is used for message acknowledgement in the 1143 TraceReport message. 1145 A TraceReq Message may include zero or more Channel Entity TLVs (as 1146 described in Section 2.4.3). If no Channel Entity TLVs are 1147 included, the receiving node MUST report on all data links within 1148 the TE link. 1150 2.5.7. TraceReport Message (MsgType = TBD) 1152 The TraceReport message is sent over the control channel after 1153 receiving a TraceReq message. 1155 ::= 1157 The format of the TraceReport object is as follows: 1159 0 1 2 3 1160 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 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | MessageId | 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1164 | | 1165 // (Trace TLVs) // 1166 | | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 MessageId: 32 bits 1171 This is copied from the TraceReq message being acknowledged. 1173 The TraceReport message MUST include a Trace TLV (as described in 1174 Section 2.5.1) for each link requested. 1176 3. Security Considerations 1178 LMP-WDM introduces no new security issues over [LMP]. As in [LMP], 1179 LMP-WDM exchanges may be authenticated using the Cryptographic 1180 authentication option. MD5 is currently the only message digest 1181 algorithm specified. 1183 4. Work Items 1185 The following work items have been identified. They will be 1186 addressed in a future version of this draft: 1188 1. Error messages may be needed in response to some of the defined 1189 messages. 1191 2. More discussion on Trace Monitoring procedures is needed. 1193 3. Provide description of procedures and interactions for running 1194 LMP and LMP-WDM on the same link. Include description of how 1195 control over link transparency works during the Verify 1196 procedure. 1198 4. Determine whether some functions are optional and, if so, 1199 provide a capability negotiation mechanism. 1201 5. References 1203 [GMPLS] Berger, L., Ashwood-Smith, Peter, editors, 1204 "Generalized MPLS - Signaling Functional Description", 1205 Internet Draft, draft-ietf-mpls-generalized-signaling- 1206 02.txt, (work in progress), March 2001. 1208 [Bra96] Bradner, S., "The Internet Standards Process -- 1209 Revision 3," BCP 9, RFC 2026, October 1996. 1211 [DBC00] Drake, J., Blumenthal, D., Ceuppens, L., et al., 1212 "Interworking between Photonic (Optical) Switches and 1213 Transmission Systems over Optical Link Interface (OLI) 1214 using Extensions to LMP", OIF Contribution 1215 oif2000.254, (work in progress), November 2000. 1217 [KRB00] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling 1218 in MPLS Traffic Engineering," Internet Draft, draft- 1219 kompella-mpls-bundle-02.txt, (work in progress), July 1220 2000. 1222 [KRB00a] Kompella, K., Rekhter, Y., Banerjee, A., et al, "OSPF 1223 Extensions in Support of Generalized MPLS," Internet 1224 Draft, draft-kompella-ospf-extensions-00.txt, (work in 1225 progress), July 2000. 1227 [LMP] Lang, J., Mitra, K., Drake, J., Kompella, K., Rekhter, 1228 Y., Berger, L., Saha, D., Basak, D., Sandick, H., 1229 Zinin, A., "Link Management Protocol (LMP)", Internet 1230 Draft, draft-ietf-mpls-lmp-03.txt, (work in progress), 1231 July 2001. 1233 [OLI] Fredette, A., Editor, "Optical Link Interface 1234 Requirements", Internet Draft, draft-many-oli-reqts- 1235 00.txt, (work in progress), June 2001. 1237 [SDH] ITU-T G.707, "Network node interface for the 1238 synchronous digital hierarchy (SDH)", 1996. 1240 [SONET] GR-253-CORE, "Synchronous Optical Network (SONET) 1241 Transport Systems: Common Generic Criteria", Telcordia 1242 Technologies, Issue 3, September 2000 1244 [T.50] ITU-T T.50, "International Reference Alphabet (IRA) 1245 (formerly International Alphabet No. 5 or IA5) 1246 Information technology 7-bit coded character set for 1247 information interchange.", 1992. 1249 6. Author's Addresses 1251 Stuart Brorson Monika Jaeger 1252 Axiowave Networks T-systems 1253 100 Nickerson Road Monika.Jaeger@t-systems.de 1254 Marlborough, MA 01752 1255 email: sdb@axiowave.com Ram Krishnan 1256 Axiowave Networks 1257 Sudheer Dharanikota 100 Nickerson Road 1258 Nayna Networks, Inc. Marlborough, MA 01752 1259 157 Topaz Drive, email: ram@axiowave.com 1260 Milpitas, CA 95035 1261 email: sudheer@nayna.com Jonathan P. Lang 1262 Calient Networks 1263 John Drake Court25 Castilian Drive 1264 Calient Networks Goleta, CA 93117 1265 5853 Rue Ferrari email: jplang@calient.net 1266 San Jose, CA 95138 1267 email: jdrake@calient.net Raghu Mannam 1268 Hitachi Telecom (USA), Inc. 1269 David Drysdale rmannam@hitel.com 1270 Data Connection Ltd 1271 dmd@dataconnection.com Eric Mannie 1272 Ebone (GTS) 1273 W. L. Edwards Terhulpsesteenweg 6A 1274 iLambda Networks 1560 Hoeilaart 1275 Aspen, CO Belgium 1276 email: texas@ilambda.com Email: eric.mannie@gts.com 1278 Adrian Farrel (Movaz Networks) Dimitri Papadimitriou 1279 Movaz Networks, Inc. Alcatel IPO NSG-NA 1280 7926 Jones Branch Drive, Francis Wellesplein 1, 1281 Suite 615 B-2018 Antwerpen, Belgium 1282 McLean, VA 22102 email: dimitri.Papadimitriou 1283 email: afarrel@movaz.com @alcatel.be 1285 Andre Fredette Jagan Shantigram 1286 PhotonEx Corporation PhotonEx Corporation 1287 8C Preston Court 8C Preston 1288 Bedford, MA 01730 Bedford, MA 01730 1289 email: fredette@photonex.com email: jagan@photonex.com 1291 Rohit Goyal Ed Snyder 1292 Axiowave Networks PhotonEx Corporation 1293 100 Nickerson Road 8C Preston Court 1294 Marlborough, MA 01752 Bedford, MA 01730 1295 email: rgoyal@axiowave.com email: esnyder@photonex.com 1296 George Swallow Lucy Yong 1297 Cisco Systems, Inc. Williams Communications 1298 250 Apollo Drive 2 East First Street 1299 Chelmsford, MA 01824 Tulsa, OK 74172 1300 Email: swallow@cisco.com lucy.yong@wilcom.com 1302 Gopala Tumuluri John Yu 1303 Calient Networks Zaffire, Inc 1304 5853 Rue Ferrari 2630 Orchard Parkway 1305 San Jose, CA 95138 San Jose, CA 95134 1306 email: krishna@calient.net email: jzyu@zaffire.com 1308 Yong Xue 1309 UUNET/WorldCom 1310 22001 Loudoun County Parkway 1311 Ashburn, VA 20148 1312 email: yxue@uu.net