idnits 2.17.1 draft-ietf-ccamp-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 seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 an Authors' Addresses Section. 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 (September 2002) is 7894 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'LMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-SIG' -- Possible downref: Non-RFC (?) normative reference: ref. 'LMP-SDH' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-RTG' -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF-TE' Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group A. Fredette, Editor 2 Internet Draft Hatteras Networks 3 Expiration Date: March 2003 J. Lang, Editor 4 Calient Networks 6 September 2002 8 Link Management Protocol (LMP) for DWDM Optical Line Systems 9 draft-ietf-ccamp-lmp-wdm-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet- Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The Link Management Protocol (LMP) is defined to manage traffic 35 engineering (TE) links. In its present form, LMP focuses on peer 36 nodes; i.e., nodes that peer in signaling and/or routing. In this 37 document we propose extensions to LMP to allow it to be used between 38 a peer node and an adjacent optical line system (OLS). These 39 extensions are intended to satisfy the "Optical Link Interface 40 Requirements" described in a companion document. 42 Changes from previous version: 44 o Editorial changes. 45 o Removed the Trace monitoring section to be put in SONET/SDH 46 technology specific draft. 47 o Moved the LMP-WDM support bit from the common header of LMP 48 messages to a new LMP-WDM_CONFIG object. 50 1. Introduction 52 Networks are being developed with routers, switches, optical 53 crossconnects (OXCs), DWDM optical line systems (OLSs), and add-drop 54 multiplexors (ADMs) that use a common control plane [e.g., 55 Generalized MPLS (GMPLS)] to dynamically provision resources and to 56 provide network survivability using protection and restoration 57 techniques. 59 The Link Management Protocol (LMP) is being developed as part of the 60 GMPLS protocol suite to manage traffic engineering (TE) links [LMP]. 61 In its present form, LMP focuses on peer nodes; i.e., nodes that peer 62 in signaling and/or routing (e.g., OXC-to-OXC, as illustrated in 63 Figure 1). In this document, extensions to LMP to allow it to be 64 used between a peer node and an adjacent optical line system (OLS) 65 are proposed. These extensions are intended to satisfy the "Optical 66 Link Interface Requirements" described in [OLI]. It is assumed that 67 the reader is familiar with LMP as defined in [LMP]. 69 +------+ +------+ +------+ +------+ 70 | | ----- | | | | ----- | | 71 | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | 72 | | ----- | | | | ----- | | 73 +------+ +------+ +------+ +------+ 74 ^ ^ 75 | | 76 +---------------------LMP---------------------+ 78 Figure 1: LMP Model 80 Consider two peer nodes (e.g., two OXCs) interconnected by a 81 wavelength-multiplexed link; i.e., a DWDM optical link (see Figure 1 82 above). Information about the configuration of this link and its 83 current state is known by the two OLSs (OLS1 and OLS2), and allowing 84 them to communicate this information to the corresponding peer nodes 85 (OXC1 and OXC2) via LMP can improve network usability by reducing 86 required manual configuration and by enhancing fault detection and 87 recovery. 89 Information about the state of LSPs using the DWDM optical link is 90 known by the peer nodes (OXC1 and OXC2), and allowing them to 91 communicate this information to the corresponding OLSs (OLS1 and 92 OLS2) is useful for alarm management and link monitoring. Alarm 93 management is important because the administrative state of an LSP, 94 known to the peer nodes (e.g., via the Admin Status object of GMPLS 95 signaling [GMPLS-SIG]) can be used to suppress spurious alarm 96 reporting from the OLSs. 98 The model for extending LMP to OLSs is shown in Figure 2. 100 +------+ +------+ +------+ +------+ 101 | | ----- | | | | ----- | | 102 | OXC1 | ----- | OLS1 | ===== | OLS2 | ----- | OXC2 | 103 | | ----- | | | | ----- | | 104 +------+ +------+ +------+ +------+ 105 ^ ^ ^ ^ ^ ^ 106 | | | | | | 107 | +-----LMP-----+ +-----LMP-----+ | 108 | | 109 +----------------------LMP-----------------------+ 111 Figure 2: Extended LMP Model 113 In this model, a peer node may have LMP sessions with adjacent OLSs 114 as well as adjacent peer nodes. In Figure 2, for example, the OXC1- 115 OXC2 LMP session can be used to build traffic-engineering (TE) links 116 for GMPLS signaling and routing, as described in [LMP]. The OXC1- 117 OLS1 and the OXC2-OLS2 LMP sessions are used to exchange information 118 about the configuration of the DWDM optical link and its current 119 state and information about the state of LSPs using that link. 121 The latter type of LMP sessions is discussed in this document. It is 122 important to note that a peer node may have LMP sessions with one or 123 more OLSs and an OLS may have LMP sessions with one or more peer 124 nodes. 126 Although there are many similarities between an LMP session between 127 two peer nodes and an LMP session between a peer node and an OLS, 128 there are some differences as well. The former type of LMP session 129 is used to provide the basis for GMPLS signaling and routing. The 130 latter type of LMP session is used to augment knowledge about the 131 links between peer nodes. 133 A peer node maintains its peer node - OLS LMP sessions and its peer 134 node - peer node LMP sessions independently. This means that it MUST 135 be possible for LMP sessions to come up in any order. In particular, 136 it MUST be possible for a peer node - peer node LMP session to come 137 up in the absence of any peer node - OLS LMP sessions and vice versa. 139 1.1. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 The reader is assumed to be familiar with the terminology in [LMP]. 147 DWDM: Dense wavelength division multiplexor 149 OLS: Optical line system 151 Opaque: 153 A device is called X-opaque if it examines or modifies the X 154 aspect of the signal while forwarding an incoming signal from 155 input to output. 157 OXC: Optical crossconnect 159 Transparent: 161 As defined in [LMP], a device is called X-transparent if it 162 forwards incoming signals from input to output without examining 163 or modifying the X aspect of the signal. For example, a Frame 164 Relay switch is network-layer transparent; an all-optical switch 165 is electrically transparent. 167 1.2. Scope of LMP-WDM Protocol 169 This document focuses on extensions required for use with opaque 170 OLSs. In particular, this document is intended for use with OLSs 171 having SONET, SDH, and Ethernet user ports. 173 At the time of this writing, work is ongoing in the area of fully 174 transparent wavelength routing; however, it is premature to identify 175 the necessary information to be exchanged between a peer node and an 176 OLS in this context. Never-the-less, the protocol described in this 177 document provides the necessary framework in which to exchange 178 whatever additional information is deemed appropriate. 180 2. LMP Extensions for Optical Line Systems 182 LMP currently consists of four main procedures, of which the first 183 two are mandatory and the last two are optional: 185 1. Control channel management 186 2. Link property correlation 187 3. Link verification 188 4. Fault management 190 All four functions are supported in LMP-WDM. 192 2.1. Control Channel Management 194 As in [LMP], we do not specify the exact implementation of the 195 control channel; it could be, for example, a separate wavelength, 196 fiber, Ethernet link, an IP tunnel routed over a separate management 197 network, a multi-hop IP network, or the overhead bytes of a data 198 link. 200 The control channel management for a peer node - OLS link is the same 201 as for a peer node - peer node link, as described in [LMP]. 203 To distinguish between a peer node - OLS LMP session from a peer node 204 - peer node LMP session, a new LMP-WDM CONFIG object is defined (C- 205 Type = TBA by IANA). The format of the CONFIG object is as follows: 207 Class = 6. 209 o C-Type = TBA, LMP-WDM_CONFIG 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |W|O| (Reserved) | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 The Reserved field should be sent as zero and ignored on receipt. 219 WDM: 1 bit 221 This bit indicates support for the LMP-WDM extensions defined 222 in this draft. 224 OLS: 1 bit 226 If set, this bit indicates that the sender is an optical line 227 system (OLS). If clear, this bit indicates that the sender is 228 a peer node. 230 The LMP-WDM extensions are designed for peer node - OLS LMP 231 sessions. The OLS bit allows a node to identify itself as an OLS or 232 a peer node. This is used to detect misconfiguration of a peer node 233 -OLS LMP session between two peer nodes or a peer node - peer node 234 LMP session between a peer node and an OLS. 236 If the node does not support the LMP-WDM extensions, it MUST reply 237 to the Config message with a ConfigNack message. 239 If a peer node that is configured to run LMP-WDM receives a Config 240 message with the OLS bit clear in LMP-WDM_CONFIG Object, it MUST 241 reply to the Config message with a ConfigNack message. 243 2.2. Link Verification 245 The Test procedure used with OLSs is the same as described in [LMP]. 246 The VerifyTransportMechanism (included in the BeginVerify and 247 BeginVerifyAck messages) is used to allow nodes to negotiate a link 248 verification method and is essential for line systems that have 249 access to overhead bytes rather than the payload. The VerifyId 250 (provided by the remote node in the BeginVerifyAck message, and used 251 in all subsequent Test messages) is used to differentiate Test 252 messages from different LMP Link Verification procedures. In 253 addition to the Test procedure described in [LMP], the trace 254 monitoring function of [LMP-SDH] may be used for link verification 255 when the OLS user ports are SONET or SDH. 257 In a combined LMP and LMP-WDM context, there is an interplay between 258 the data links being managed by peer node - peer node LMP sessions 259 and peer node - OLS LMP sessions. For example, in Figure 2, the 260 OXC1-OLS1 LMP session manages the data links between OXC1 and OLS1, 261 and the OXC2-OLS2 LMP session manages the data links between OXC2 and 262 OLS2. However, the OXC1-OXC2 LMP session manages the data links 263 between OXC1 and OXC2, which are actually a concatenation of the data 264 links between OXC1 and OLS1, the DWDM span between OLS1 and OLS2, and 265 the data links between OXC2 and OLS2, and it is these concatenated 266 links which comprise the TE links which are advertised in the GMPLS 267 TE link state database. 269 The implication of this is that when the data links between OXC1 and 270 OXC2 are being verified, using the LMP link verification procedure, 271 OLS1 and OLS2 need to make themselves transparent with respect to 272 these concatenated data links. The co-ordination of verification of 273 OXC1-OLS1 and OXC2-OLS2 data links to ensure this transparency is the 274 responsibility of the peer nodes, OXC1 and OXC2. 276 It is also necessary for these peer nodes to understand the mappings 277 between the data links of the peer node - OLS LMP session and the 278 concatenated data links of the peer node - peer node LMP session. 280 2.3. Link Summarization 282 As in [LMP], the LinkSummary message is used to synchronize the 283 Interface Ids and correlate the properties of the TE link. (Note that 284 the term "TE Link" originated from routing/signaling applications of 285 LMP, whereas this concept does not necessarily apply to an OLS. 286 However, the term is used in this document to remain consistent with 287 LMP terminology.) The LinkSummary message includes one or more 288 DATA_LINK objects. The contents of the DATA_LINK object consist of a 289 series of variable-length data items called Data Link sub-objects 290 describing the capabilities of the data links. 292 In this document, several additional Data Link sub-objects are 293 defined to describe additional link characteristics. The link 294 characteristics are, in general, those needed by the CSPF to select 295 the path for a particular LSP. These link characteristics describe 296 the specified peer node - OLS data link as well as the associated 297 DWDM span between the two OLSs. 299 The format of the Data Link sub-objects follows the format described 300 in [LMP] and is shown below for readability: 302 0 1 303 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+ 305 | Type | Length | (Sub-object contents) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+ 308 Type: 8 bits 310 The Type indicates the type of contents of the sub-object. 312 Length: 8 bits 314 The Length field contains the total length of the sub-object in 315 bytes, including the Type and Length fields. The Length MUST 316 be at least 4, and MUST be a multiple of 4. 318 The following Link Characteristics are exchanged on a per data link 319 basis. 321 2.3.1. Link Group ID 323 The main purpose of the Link Group ID is to reduce control traffic 324 during failures that affect many data links. A local ID may be 325 assigned to a group of data links. This ID can be used to reduce the 326 control traffic in the event of a failure by enabling a single 327 ChannelStatus message with the LINK GROUP CHANNEL_STATUS object (see 328 Section 2.4.1) to be used for a group of data links instead of 329 individual ChannelStatus messages for each data link. A data link 330 may be a member of multiple groups. This is achieved by including 331 multiple Link Group ID sub-objects in the LinkSummary message. 333 The Link Group ID feature allows Link Groups to be assigned based 334 upon the types of fault correlation and aggregation supported by a 335 given OLS. From a practical perspective, the Link Group ID is used 336 to map (or group) data links into "failable entities" known primarily 337 to the OLS. If one of those failable entities fails, all associated 338 data links are failed and the peer node is notified with a single 339 message. 341 For example, an OLS could create a Link Group for each laser in the 342 OLS. The data links associated with each laser would then each be 343 assigned the Link Group ID for that laser. If a laser fails, the OLS 344 would then report a single failure affecting all of the data links 345 with Link Group ID of the failed laser. The peer node that receives 346 the single failure notification then knows which data links are 347 affected. Similarly, an OLS could create a Link Group ID for a 348 fiber, to report a failure affecting all of the data links associated 349 with that fiber if a loss-of-signal (LOS) is detected for that fiber. 351 The format of the Link Group ID sub-object (Type=TBD, Length=8) is as 352 follows: 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Type | Length | (Reserved) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Link Group ID | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 The Reserved field should be sent as zero and ignored on receipt. 364 Link Group ID: 32 bits 366 Link Group ID 0xFFFFFFFF is reserved and indicates all data 367 links in a TE link. All data links are members of Link Group 368 0xFFFFFFFF by default. 370 2.3.2. Shared Risk Link Group Identifier (SRLG) 372 This identifies the SRLGs of which the data link is a member. This 373 information may be configured on an OLS by the user and used for 374 diverse path computation (see [GMPLS-RTG]). 376 The format of the SRLG sub-object (Type=TBD) is as follows: 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Type | Length | (Reserved) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | SRLG value #1 | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | SRLG value #2 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | ............ | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | SRLG value #(N-1) | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | SRLG value #N | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 The Reserved field should be sent as zero and ignored on receipt. 396 Length: 8 bits 398 The length is (N+1)*4, where N is the number of SRLG values. 400 Shared Risk Link Group Value: 32 bits 402 See [GMPLS-RTG]. List as many SRLGs as apply. 404 2.3.3. Bit Error Rate (BER) Estimate 406 This object provides an estimate of the BER for the data link. 408 The bit error rate (BER) is the proportion of bits that have errors 409 relative to the total number of bits received in a transmission, 410 usually expressed as ten to a negative power. For example, a 411 transmission might have a BER of "10 to the minus 13", meaning that, 412 out of every 10,000,000,000,000 bits transmitted, one bit may be in 413 error. The BER is an indication of overall signal quality. 415 The format of the BER Estimate sub-object (Type=TBD; Length=4) is as 416 follows: 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Type | Length | BER | (Reserved) | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 The Reserved field should be sent as zero and ignored on receipt. 426 BER: 8 bits 428 The exponent from the BER representation described above. I.e., 429 if the BER is 10 to the minus X, the BER field is set to X. 431 2.3.4. Optical Protection 433 This indicates whether the link is protected by the OLS. This 434 information can be used as a measure of link capability. It may be 435 advertised by routing and used by signaling as a selection criterion 436 as described in [GMPLS-SIG]. 438 The format of the Optical Protection sub-object (Type=TBD; Length=4) 439 is as follows: 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type | Length | (Reserved) | Link Flags| 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 The Reserved field should be sent as zero and ignored on receipt. 449 Link Flags: 6 bits 451 Encoding for Link Flags is defined in Section 7 of [GMPLS-SIG]. 453 2.3.5. Total Span Length 455 This indicates the total distance of fiber in the OLS. This may be 456 used as a routing metric or to estimate delay. 458 The format of the Total Span Length sub-object (Type=TBD, Length=8) 459 is as follows: 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Type | Length | (Reserved) | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Span Length | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 The Reserved field should be sent as zero and ignored on receipt. 471 Span Length: 32 bits 473 This value represents the total Length of the WDM span in meters 474 expressed as an unsigned (long) integer. 476 2.3.6. Administrative Group (Color) 478 The administrative group (or Color) to which the data link belongs. 480 The format of the Administrative Group sub-object (Type=TBD, 481 Length=8) is as follows: 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Type | Length | (Reserved) | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Administrative Group | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 The Reserved field should be sent as zero and ignored on receipt. 493 Administrative Group: 32 bits 495 A 32 bit value as defined in [OSPF-TE]. 497 2.4. Fault Management 499 Fault management consists of three major functions: 501 1. Fault Detection 502 2. Fault Localization 503 3. Fault Notification 505 The fault detection mechanisms are the responsibility of the 506 individual nodes and are not specified as part of this protocol. 507 Fault detection mechanisms may include a bit error rate (BER) 508 exceeding a threshold, loss of signal (LOS) and SONET/SDH-level 509 errors. It is the responsibility of the OLS to translate these 510 failures into OK, SF, or SD as described in [LMP]. 512 I.e., an OLS uses the messages defined in the LMP fault localization 513 procedures (ChannelStatus, ChannelStatusAck, ChannelStatusRequest, 514 and ChannelStatusResponse Messages) to inform the adjacent peer node 515 of failures it has detected, in order to initiate the LMP fault 516 localization procedures between peer nodes, but it does not 517 participate in those procedures. 519 The OLS may also execute its own fault localization process to allow 520 it to determine the location of the fault along the DWDM span. For 521 example, the OLS may be able to pinpoint the fault to a particular 522 amplifier in a span thousands of kilometers in length. 524 To report data link failures and recovery conditions, LMP-WDM uses 525 the ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and 526 ChannelStatusResponse Messages defined in [LMP]. 528 Each data link is identified by an Interface_ID. In addition, a Link 529 Group ID may be assigned to a group of data links (see Section 530 2.3.1). The Link Group ID may be used to reduce the control traffic 531 by providing channel status information for a group of data links. A 532 new LINK GROUP CHANNEL_STATUS object is defined below for this 533 purpose. This object may be used in place of the CHANNEL_STATUS 534 objects described in [LMP] in the ChannelStatus message. 536 2.4.1. LINK GROUP CHANNEL_STATUS Object 538 The LINK GROUP CHANNEL_STATUS object is used to indicate the status 539 of the data links belonging to a particular Link Group. The 540 correlation of data links to Group ID is made with the Link Group ID 541 sub-object of the DATA_LINK Object. 543 The format of the LINK GROUP CHANNEL_STATUS object is as follows 544 (Class = 13, C-Type =TBA by IANA): 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Link Group ID | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 |A|D| Channel Status | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | : | 554 // : // 555 | : | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Link Group ID | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 |A|D| Channel Status | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Link Group ID: 32 bits 563 Link Group ID 0xFFFFFFFF is reserved and indicates all data 564 links in a TE link. All data links are members of Link Group 565 0xFFFFFFFF by default. 567 Channel Status: 32 bits 569 The values for the Channel Status field are defined in [LMP]. 571 This Object is non-negotiable. 573 3. Security Considerations 575 This document only defines new LMP objects extending the 576 capabilities of [LMP]. This document does not introduce any new 577 security considerations. 579 4. References 581 4.1. Normative References 583 [LMP] Lang, J. P., ed., "The Link Management Protocol (LMP)," 584 (work in progress). 585 [GMPLS-SIG] Ashwood-Smith, P., Banerjee, A., et al, "Generalized 586 MPLS - Signaling Functional Description," (work in 587 progress). 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels," BCP 14, RFC 2119, March 1997. 590 [LMP-SDH] Lang, J. P., Papadimitriou, D.,"SONET/SDH Encoding for 591 Link Management Protocol (LMP) Test messages," (work in 592 progress). 593 [GMPLS-RTG] Kompella, K., Rekhter, Y. et al, "Routing Extensions in 594 Support of Generalized MPLS," (work in progress). 595 [OSPF-TE] Katz, D, Yeung, D., and Kompella, K., "Traffic 596 Engineering Extensions to OSPF Version 2," (work in 597 progress). 599 4.2. Informative References 601 [OLI] Fredette, A., Editor, "Optical Link Interface 602 Requirements", (work in progress). 604 5. Contributors 606 Osama S. Aboul-Magd, Stuart Brorson, Sudheer Dharanikota, John Drake, 607 David Drysdale, W. L. Edwards, Adrian Farrel, Andre Fredette, Rohit 608 Goyal, Hirokazu Ishimatsu, Monika Jaeger, Ram Krishnan, Jonathan P. 609 Lang, Raghu Mannam, Eric Mannie, Dimitri Papadimitriou, Jagan 610 Shantigram, Ed Snyder, George Swallow, Gopala Tumuluri, Yong Xue, 611 Lucy Yong, John Yu. 613 6. Contact Address 614 Jonathan P. Lang Andre Fredette 615 Calient Networks Hatteras Networks 616 25 Castilian Drive P.O. Box 110025 617 Goleta, CA 93117 Research Triangle Park 618 Email: jplang@calient.net NC 27709-0025 619 Afredette@HatterasNetworks.com