idnits 2.17.1 draft-berger-ccamp-gmpls-alarm-spec-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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 Authors' Addresses Section. ** There are 18 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (January 2004) is 7369 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: 'RFC2205' is mentioned on line 188, but not defined == Missing Reference: 'GMPLS-ASON' is mentioned on line 544, but not defined == Missing Reference: 'BCP26' is mentioned on line 583, but not defined == Missing Reference: 'RFC2026' is mentioned on line 612, but not defined == Unused Reference: 'GMPLS-ENNI' is defined on line 664, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-disman-alarm-mib-17 == Outdated reference: A later version (-05) exists of draft-ietf-ccamp-gmpls-overlay-02 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-gmpls-rsvp-te-ason-01 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Lou Berger - Editor (Movaz Networks) 2 Internet Draft 3 Expiration Date: July 2004 5 January 2004 7 GMPLS - Communication of Alarm Information 9 draft-berger-ccamp-gmpls-alarm-spec-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. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 26 Directory, see http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes an extension to Generalized MPLS (Multi- 31 Protocol Label Switching) signaling to support communication of alarm 32 information. GMPLS signaling already supports the control of alarm 33 reporting, but not the communication of alarm information. This 34 document presents both a functional description and GMPLS-RSVP 35 specifics of such an extension. This document also proposes 36 modification of the RSVP ERROR_SPEC object. 38 Contents 40 1 Introduction .............................................. 3 41 1.1 Background ................................................ 3 42 2 Alarm Information Communication ........................... 4 43 3 GMPLS-RSVP Details ........................................ 5 44 3.1 ALARM_SPEC Objects ........................................ 5 45 3.1.1 IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs .................... 5 46 3.1.2 Procedures ................................................ 9 47 3.1.3 Error Codes and Values .................................... 10 48 3.1.4 Backwards Compatibility ................................... 10 49 3.2 Controlling Alarm Communication ........................... 10 50 3.2.1 Updated Admin Status Object ............................... 10 51 3.2.2 Procedures ................................................ 11 52 3.3 Message Formats ........................................... 11 53 3.4 Relationship to GMPLS UNI ................................. 12 54 3.5 Relationship to GMPLS E-NNI .............................. 13 55 4 Security Considerations ................................... 14 56 5 IANA Considerations ....................................... 14 57 6 Intellectual Property Considerations ...................... 15 58 7 References ................................................ 16 59 7.1 Normative References ...................................... 16 60 7.2 Informative References .................................... 16 61 8 Contributors .............................................. 17 62 9 Contact Address ........................................... 17 63 10 Full Copyright Statement .................................. 17 64 1. Introduction 66 GMPLS Signaling provides mechanisms that can be used to control the 67 reporting of alarms associated with an LSP. This support is provided 68 via Administrative Status Information [RFC3471] and the Admin_Status 69 object [RFC3473]. These mechanisms only control if alarm reporting 70 is inhibited. No provision is made for communication of alarm 71 information within GMPLS. 73 The extension described in this document defines how the alarm 74 information associated with a GMPLS label-switched path (LSP) may be 75 communicated along the path of the LSP. Communication both upstream 76 and downstream is supported. The value in communicating such alarm 77 information is that this information is then available at every node 78 along the LSP for display and diagnostic purposes. Alarm information 79 may also be useful in certain traffic protection scenarios, but such 80 uses are out of scope of this document. Alarm communication is 81 supported via a new object, new error/alarm information TLVs, and a 82 new Administrative Status Information bit. 84 The communication of alarms, as described in this document, is 85 controllable on a per LSP basis. Such communication may be useful 86 within network configurations where not all nodes support 87 communication to a user for reporting of alarms and/or communication 88 is needed to support specific applications. The support of this 89 functionality is optional. 91 The communication of alarms within GMPLS does not imply any 92 modification in behavior of processing of alarms, or for the 93 communication of alarms outside of GMPLS. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 1.1. Background 101 Problems with data plane state can often be detected by associated 102 data plane hardware components. Such data plane problems are 103 typically filtered based on elapsed time and local policy. Problems 104 that pass the filtering process are normally raised as alarms. These 105 alarms are available for display to operators. They also may be 106 collected centrally through means that are out of the scope of this 107 document. 109 Not all data plane problems cause the LSP to be immediately torn 110 down. Further, there may be a desire, particularly in optical 111 transport networks, to retain an LSP and communicate relevant alarm 112 information even when the data plane state has failed completely. 114 Although error information can be reported using PathErr, ResvErr and 115 Notify messages, these messages typically indicate a problem in 116 signaling state and can only report one problem at at a time. This 117 makes it hard to correlate all of the problems that may be associated 118 with a single LSP and to allow an operator examining the status of an 119 LSP to view a full list of current problems. This situation is 120 exacerbated by the absence of any way to communicate that a problem 121 has been resolved and a corresponding alarm cleared. 123 The extensions defined in this document allow an operator or a 124 software component to obtain a full list of current alarms associated 125 with all of the resources used to support an LSP. The extensions 126 also ensure that this list is kept up-to-date and synchronized with 127 the real alarm status in the network. Finally, the extensions make 128 the list available at every node traversed by an LSP. 130 2. Alarm Information Communication 132 A new object is introduced to carry alarm information details. The 133 details of alarm information are much like the error information 134 carried in the existing ERROR_SPEC objects. For this reason the 135 communication of alarm information uses a format that is based on the 136 communication of error information. 138 The new object introduced to carry alarm information details is 139 called an ALARM_SPEC object. This object has the same format as the 140 ERROR_SPEC object, but uses a new C-Num to avoid the semantics of 141 error processing. Also, additional TLVs are defined for the IF_ID 142 ALARM_SPEC objects to support the communication of information 143 related to a specific alarm. These TLVs may also be useful when 144 included in ERROR_SPEC objects, e.g., when the ERROR_SPEC object is 145 carried within a Notify message. 147 While the details of alarm information are like the details of 148 existing error communication, the semantics of processing differ. 149 Alarm information will typically relate to changes in data plane 150 state, without changes in control state. Alarm information will 151 always be associated with in-place LSPs. Such information will also 152 typically be most useful to operators and applications other than 153 control plane protocol processing. Finally, while error information 154 is communicated within PathErr, ResvErr and Notify messages 155 [RFC3473], alarm information will be carried within Path and Resv 156 messages. 158 Path messages are used to carry alarm information to downstream nodes 159 and Resv messages are used to carry alarm information to upstream 160 nodes. The intent of sending alarm information both upstream and 161 downstream is to provide the same visibility to alarm information at 162 any point along an LSP. The communication of multiple alarms 163 associated with an LSP is supported. In this case, multiple 164 ALARM_SPEC objects will be carried in the Path or Resv messages. 166 The addition of alarm information to Path and Resv messages is 167 controlled via a new Administrative Status Information bit. 168 Administrative Status Information is carried in the Admin_Status 169 object. 171 3. GMPLS-RSVP Details 173 This section provides the GMPLS-RSVP [RFC3473] specification for 174 communication of alarm information. The communication of alarm 175 information is optional. This section applies to nodes that support 176 communication of alarm information. 178 3.1. ALARM_SPEC Objects 180 The ALARM_SPEC objects use the same format as the ERROR_SPEC object, 181 but with class number of TBA (to be assigned by IANA in the form 182 11bbbbbb). 184 o IPv4 ALARM_SPEC object: Class = TBA, C-Type = 1 185 Definition same as IPv4 ERROR_SPEC [RFC2205]. 187 o IPv6 ALARM_SPEC object: Class = TBA, C-Type = 2 188 Definition same as IPv6 ERROR_SPEC [RFC2205]. 190 o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3 191 Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473]. 193 o IPv6 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 4 194 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473]. 196 3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs 198 The following new TLVs are defined for use with the IPv4 and IPv6 199 IF_ID ALARM_SPEC objects. They may also be used with the IPv4 and 200 IPv6 IF_ID ERROR_SPEC objects. See [RFC3471] section 9.1.1 for the 201 original definition of these values. Note the length provided below 202 is for the total TLV. All TLVs defined in this section are optional. 204 No rules apply to the relative ordering of these TLVs. These TLVs 205 MUST be listed after any interface identifying TLVs. 207 [Note: Type values are TBA (to be assigned) by IANA] 209 Type Length Description 210 ---------------------------------- 211 512 8 REFERENCE_COUNT 212 513 8 SEVERITY 213 514 8 GLOBAL_TIMESTAMP 214 515 8 LOCAL_TIMESTAMP 215 516 variable ERROR_STRING 217 The Reference Count TLV has the following format: 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type | Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Reference Count | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Reference Count: 32 bits 229 The number of times this alarm has been repeated. This field 230 MUST NOT be set to zero. 232 Only one Reference Count TLV may be included in an object. 234 The Severity TLV has the following format: 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type | Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Reserved |Impact | Severity | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Reserved: 24 bits 246 This field is reserved. It MUST be set to zero on generation 247 and MUST be ignored on receipt. 249 Impact: 4 bits 251 Indicates the impact of the alarm indicated in the TLV. The 252 following values are defined: 254 Value Definition 255 ----- --------------------- 256 0 Unspecified impact 257 1 Non-Service Affecting 258 2 Service Affecting 260 Severity: 8 bits 262 Indicates the impact of the alarm indicated in the TLV. The 263 following values are defined: 265 Value Definition 266 ----- ---------- 267 0 Reserved 268 1 Critical 269 2 Major 270 3 Minor 271 4 Warning 273 Only one Severity TLV may be included in an object. 275 The Global Timestamp TLV has the following format: 277 0 1 2 3 278 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 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Type | Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Global Timestamp | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Global Timestamp: 32 bits 287 The number of seconds since 0000 UT on 1 January 1970, 288 according to the clock on the node that originates this TLV. 290 Only one Global Timestamp TLV may be included in an object. 292 The Local Timestamp TLV has the following format: 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Type | Length | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Local Timestamp | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Local Timestamp: 32 bits 304 Number of seconds reported by the local system clock at the 305 time the associated alarm was detected on the node that 306 originates this TLV. 308 Only one Local Timestamp TLV may be included in an object. 310 The Error String TLV has the following format: 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 | Type | Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | 318 // Error String (NULL padded display string) // 319 | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Error String: 32 bits minimum (variable) 324 A string of characters, representing the type of error/alarm. 325 This string is padded to the next largest 4 byte boundary using 326 null characters. Null padding is not required when the string 327 is 32-bit aligned. The contents of error string are 328 implementation dependent. See the condition types listed in 329 Appendices of [GR833] for a list of example strings. 331 Multiple Error String TLVs may be included in an object. 333 3.1.2. Procedures 335 This section applies to nodes that support the communication of alarm 336 information. ALARM_SPEC objects are carried in Path and Resv 337 messages. Multiple ALARM_SPEC objects MAY be present. The IPv4 and 338 IPv6 formats of the ALARM_SPEC object, C-Type 1 and 2, SHOULD NOT be 339 used as they do not support the inclusion of the TLVs defined above. 341 Nodes that support the communication of alarm information, SHOULD 342 record the information contained in a received ALARM_SPECs for later 343 use. All ALARM_SPEC objects received in Path messages SHOULD be 344 passed unmodified downstream in the corresponding Path messages. All 345 ALARM_SPEC objects received in Resv messages SHOULD be passed 346 unmodified upstream in the corresponding Resv messages. ALARM_SPEC 347 objects are merged in transmitted Resv messages by including a copy 348 of all ALARM_SPEC objects received in corresponding Resv Messages. 350 To advertise local alarm information, a node generates an ALARM_SPEC 351 object for each alarm and adds it to both the Path and Resv messages 352 for the affected LSP. The IPv4 or IPv6 IF_ID ALARM_SPEC object 353 format SHOULD be used. In all cases, appropriate Error Node Address, 354 Error Code and Error Values MUST be set, see below for a discussion 355 on Error Code and Error Values. The InPlace and NotGuilty flags 356 SHOULD NOT be set. When the IPv4 or IPv6 IF_ID ALARM_SPEC object 357 format is used, TLVs SHOULD be included to identify the interface, if 358 any, the severity, the time and a brief string associated with the 359 alarm. The reference count TLV MAY also be included. ALARM_SPEC 360 objects received from other nodes are not effected by the addition of 361 local ALARM_SPEC objects, i.e., they continue to be processed as 362 described above. The choice of which alarm or alarms to advertise 363 and which to omit is a local policy matter, and may configurable by 364 the user. 366 Note, ALARM_SPEC objects SHOULD NOT be added to LSPs that are in 367 "alarm communication inhibited." ALARM_SPEC objects MAY be added to 368 LSPs that are "administratively down". These states are indicated by 369 the I and A bits of the Admin_Status object, see Section 3.2. 371 To remove local alarm information, a node simply removes the matching 372 locally generated ALARM_SPEC objects from the outgoing Path and Resv 373 messages. A node MAY modify a locally generated ALARM_SPEC object. 375 Normal refresh and trigger message processing applies to Path or Resv 376 message that contain ALARM_SPEC objects. Note that changes in 377 ALARM_SPEC objects from one message to the next may include a 378 modification in the contents of a specific ALARM_SPEC object, or a 379 change in the number of ALARM_SPEC objects present. All changes in 380 ALARM_SPEC objects SHOULD be processed as trigger messages. 382 3.1.3. Error Codes and Values 384 The Error Codes and Values used in ALARM_SPEC objects are the same as 385 those used in ERROR_SPEC objects. New Error Code values for use with 386 both ERROR_SPEC and ALARM_SPEC objects may be assigned to support 387 alarm types defined by other standards. 389 In this document we define one new Error Code. The Error Code uses 390 the value TBA (by IANA) and is referred to as "Alarms". The values 391 used in the Error Values field are the same as the values used for 392 IANAItuProbableCause in the Alarm MIB [ALARM-MIB]. 394 3.1.4. Backwards Compatibility 396 The support of ALARM_SPEC objects is optional. Non-supporting nodes 397 will pass the objects through the node unmodified, because the 398 ALARM_SPEC object has a C-Num of the form 11bbbbbb. 400 This allows alarm information to be collected and examined in a 401 network built from a collection of nodes some of which support the 402 communication of alarm information, and some of which do not. 404 3.2. Controlling Alarm Communication 406 Alarm information communication is controlled via Administrative 407 Status Information as carried in the Admin_Status object. A new bit 408 is defined, called the I bit, that indicates when alarm communication 409 is to be inhibited. The definition of this bit does not modify the 410 procedures defined in Section 7 of [RFC3473]. 412 3.2.1. Updated Admin Status Object 414 The format of the Admin_Status object is updated to include the I 415 bit: 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Length | Class-Num(196)| C-Type (1) | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 |R| Reserved |I| |T|A|D| 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Inhibit Alarm Communication (I): 1 bit 426 When set, indicates that alarm communication is disabled for 427 the LSP and that nodes SHOULD NOT add local alarm information. 429 See [RFC3471] for the definition of the remaining bits. 431 3.2.2. Procedures 433 The I bit may be set and cleared using the procedures defined in 434 Sections 7.2 and 7.3 of [RFC3473]. A node that receives (or 435 generates) an Admin_Status object with the A and I bits set (1), 436 SHOULD remove all locally generated alarm information from the 437 matching LSP's outgoing Path and Resv messages. When a node receives 438 (or generates) an Admin_Status object with the A and I bits clear 439 (0), it should add any local alarm information to the matching LSP's 440 outgoing Path and Resv messages. The processing of non-locally 441 generated ALARM_SPEC objects MUST NOT be impacted by the contents of 442 the Admin_Status object. Note, per [RFC3473], the absence of the 443 Admin_Status object is equivalent to receiving an object containing 444 values all set to zero (0). 446 When generating Notify messages for LSPs with the I bit set, the TLVs 447 described in this document MAY be added to the ERROR_SPEC object sent 448 in the the Notify message. 450 3.3. Message Formats 452 This section presents the RSVP message related formats as modified by 453 this document. The formats specified in [RFC3473] served as the 454 basis of these formats. 456 The format of a Path message is as follows: 458 ::= [ ] 459 [ [ | ] ... ] 460 [ ] 461 462 463 [ ] 464 465 [ ] 466 [ ... ] 467 [ ] 468 [ ] 469 [ ] 470 [ ... ] 471 [ ... ] 472 474 is not modified by this document. 476 The format of a Resv message is as follows: 478 ::= [ ] 479 [ [ | ] ... ] 480 [ ] 481 482 483 [ ] [ ] 484 [ ] 485 [ ] 486 [ ... ] 487 [ ... ] 488