idnits 2.17.1 draft-ietf-ccamp-gmpls-alarm-spec-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 837. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 843. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The abstract seems to indicate that this document updates RFC3473, but the header doesn't have an 'Updates:' line to match this. 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 (September 2006) is 6426 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 450, but not defined == Missing Reference: 'RFC-ccamp-gmpls-alarm-spec' is mentioned on line 707, but not defined == Missing Reference: 'RFC4124' is mentioned on line 719, but not defined Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger - Editor (LabN) 2 Updates: 3473 3 Category: Standards Track 4 Expiration Date: March 2007 6 September 2006 8 GMPLS - Communication of Alarm Information 10 draft-ietf-ccamp-gmpls-alarm-spec-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This document describes an extension to Generalized MPLS (Multi- 38 Protocol Label Switching) signaling to support communication of alarm 39 information. GMPLS signaling already supports the control of alarm 40 reporting, but not the communication of alarm information. This 41 document presents both a functional description and GMPLS-RSVP 42 specifics of such an extension. This document also proposes 43 modification of the RSVP ERROR_SPEC object. 45 This document updates RFC 3473 "Generalized Multi-Protocol Label 46 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 47 Engineering (RSVP-TE) Extensions" through the addition of new, 48 optional protocol elements. It does not change, and is fully backward 49 compatible with the procedures specified in RFC 3473. 51 Contents 53 1 Introduction ............................................. 3 54 1.1 Background ............................................... 3 55 2 Alarm Information Communication .......................... 4 56 3 GMPLS-RSVP Details ....................................... 5 57 3.1 ALARM_SPEC Objects ....................................... 5 58 3.1.1 IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs ................... 6 59 3.1.2 Procedures ............................................... 9 60 3.1.3 Error Codes and Values .................................. 10 61 3.1.4 Backwards Compatibility ................................. 11 62 3.2 Controlling Alarm Communication ......................... 11 63 3.2.1 Updated Admin Status Object ............................. 11 64 3.2.2 Procedures .............................................. 11 65 3.3 Message Formats ......................................... 12 66 3.4 Relationship to GMPLS UNI ............................... 13 67 3.5 Relationship to GMPLS E-NNI ............................. 14 68 4 Acknowledgements ........................................ 14 69 5 Security Considerations ................................. 14 70 6 IANA Considerations ..................................... 15 71 6.1 New RSVP Object ......................................... 15 72 6.2 New Interface ID Types .................................. 16 73 6.3 New Registry for Admin-Status Object Bit Fields ......... 16 74 6.4 New RSVP Error Code ..................................... 16 75 7 References .............................................. 17 76 7.1 Normative References .................................... 17 77 7.2 Informative References .................................. 17 78 8 Contributors ............................................ 18 79 9 Contact Address ......................................... 18 80 10 Full Copyright Statement ................................ 18 81 11 Intellectual Property ................................... 19 83 1. Introduction 85 GMPLS Signaling provides mechanisms that can be used to control the 86 reporting of alarms associated with an LSP. This support is provided 87 via Administrative Status Information [RFC3471] and the Admin_Status 88 object [RFC3473]. These mechanisms only control if alarm reporting 89 is inhibited. No provision is made for communication of alarm 90 information within GMPLS. 92 The extension described in this document defines how the alarm 93 information associated with a GMPLS label-switched path (LSP) may be 94 communicated along the path of the LSP. Communication both upstream 95 and downstream is supported. The value in communicating such alarm 96 information is that this information is then available at every node 97 along the LSP for display and diagnostic purposes. Alarm information 98 may also be useful in certain traffic protection scenarios, but such 99 uses are out of scope of this document. Alarm communication is 100 supported via a new object, new error/alarm information TLVs, and a 101 new Administrative Status Information bit. 103 The communication of alarms, as described in this document, is 104 controllable on a per LSP basis. Such communication may be useful 105 within network configurations where not all nodes support 106 communication to a user for reporting of alarms and/or communication 107 is needed to support specific applications. The support of this 108 functionality is optional. 110 The communication of alarms within GMPLS does not imply any 111 modification in behavior of processing of alarms, or for the 112 communication of alarms outside of GMPLS. Additionally, the 113 extension described in this document is not intended to replace any 114 (existing) data plane fault propagation techniques. 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 1.1. Background 122 Problems with data plane state can often be detected by associated 123 data plane hardware components. Such data plane problems are 124 typically filtered based on elapsed time and local policy. Problems 125 that pass the filtering process are normally raised as alarms. These 126 alarms are available for display to operators. They also may be 127 collected centrally through means that are out of the scope of this 128 document. 130 Not all data plane problems cause the LSP to be immediately torn 131 down. Further, there may be a desire, particularly in optical 132 transport networks, to retain an LSP and communicate relevant alarm 133 information even when the data plane state has failed completely. 135 Although error information can be reported using PathErr, ResvErr and 136 Notify messages, these messages typically indicate a problem in 137 signaling state and can only report one problem at at a time. This 138 makes it hard to correlate all of the problems that may be associated 139 with a single LSP and to allow an operator examining the status of an 140 LSP to view a full list of current problems. This situation is 141 exacerbated by the absence of any way to communicate that a problem 142 has been resolved and a corresponding alarm cleared. 144 The extensions defined in this document allow an operator or a 145 software component to obtain a full list of current alarms associated 146 with all of the resources used to support an LSP. The extensions 147 also ensure that this list is kept up-to-date and synchronized with 148 the real alarm status in the network. Finally, the extensions make 149 the list available at every node traversed by an LSP. 151 2. Alarm Information Communication 153 A new object is introduced to carry alarm information details. The 154 details of alarm information are much like the error information 155 carried in the existing ERROR_SPEC objects. For this reason the 156 communication of alarm information uses a format that is based on the 157 communication of error information. 159 The new object introduced to carry alarm information details is 160 called an ALARM_SPEC object. This object has the same format as the 161 ERROR_SPEC object, but uses a new C-Num to avoid the semantics of 162 error processing. Also, additional TLVs are defined for the IF_ID 163 ALARM_SPEC objects to support the communication of information 164 related to a specific alarm. These TLVs may also be useful when 165 included in ERROR_SPEC objects, e.g., when the ERROR_SPEC object is 166 carried within a Notify message. 168 While the details of alarm information are like the details of 169 existing error communication, the semantics of processing differ. 170 Alarm information will typically relate to changes in data plane 171 state, without changes in control state. Alarm information will 172 always be associated with in-place LSPs. Such information will also 173 typically be most useful to operators and applications other than 174 control plane protocol processing. Finally, while error information 175 is communicated within PathErr, ResvErr and Notify messages 177 [RFC3473], alarm information will be carried within Path and Resv 178 messages. 180 Path messages are used to carry alarm information to downstream nodes 181 and Resv messages are used to carry alarm information to upstream 182 nodes. The intent of sending alarm information both upstream and 183 downstream is to provide the same visibility to alarm information at 184 any point along an LSP. The communication of multiple alarms 185 associated with an LSP is supported. In this case, multiple 186 ALARM_SPEC objects will be carried in the Path or Resv messages. 188 The addition of alarm information to Path and Resv messages is 189 controlled via a new Administrative Status Information bit. 190 Administrative Status Information is carried in the Admin_Status 191 object. 193 3. GMPLS-RSVP Details 195 This section provides the GMPLS-RSVP [RFC3473] specification for 196 communication of alarm information. The communication of alarm 197 information is OPTIONAL. This section applies to nodes that support 198 communication of alarm information. 200 3.1. ALARM_SPEC Objects 202 The ALARM_SPEC objects use the same format as the ERROR_SPEC object, 203 but with class number of TBA (to be assigned by IANA in the form 204 11bbbbbb, per Section 3.1.4). 206 o Class = TBA, C-Type = 1 207 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined 208 for use with ALARM_SPEC.) 210 o Class = TBA, C-Type = 2 211 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined 212 for use with ALARM_SPEC.) 214 o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3 215 Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473]. 217 o IPv6 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 4 218 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473]. 220 3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs 222 The following new TLVs are defined for use with the IPv4 and IPv6 223 IF_ID ALARM_SPEC objects. They may also be used with the IPv4 and 224 IPv6 IF_ID ERROR_SPEC objects. See [RFC3471] section 9.1.1 for the 225 original definition of these values. Note the length provided below 226 is for the total TLV. All TLVs defined in this section are OPTIONAL. 227 The defined TLVs MUST follow any interface identifying TLVs. No 228 rules apply to the relative ordering of the TLVs defined in this 229 section. 231 [Note: Type values are TBA (to be assigned) by IANA] 233 Type Length Description 234 ---------------------------------- 235 512 8 REFERENCE_COUNT 236 513 8 SEVERITY 237 514 8 GLOBAL_TIMESTAMP 238 515 8 LOCAL_TIMESTAMP 239 516 variable ERROR_STRING 241 The Reference Count TLV has the following format: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Type | Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Reference Count | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Reference Count: 32 bits 253 The number of times this alarm has been repeated as determined 254 a TLV is sent and a received TLV with this field set to zero 255 MUST be ignored. 257 Only one Reference Count TLV may be included in an object. 259 The Severity TLV has the following format: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Reserved |Impact | Severity | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Reserved: 20 bits 270 This field is reserved. It MUST be set to zero on generation, 271 MUST be ignored on receipt and MUST be forwarded unchanged and 272 unexamined by transit nodes. 274 Impact: 4 bits 276 Indicates the impact of the alarm indicated in the TLV. See 277 [M.20] for a general discussion on classification of failures. 278 The following values are defined in this document. The details 279 of the semantics may be found in [M.20]. 281 Value Definition 282 ----- --------------------- 283 0 Unspecified impact 284 1 Non-Service Affecting (Data traffic not interrupted) 285 2 Service Affecting (Data traffic is interrupted) 287 Severity: 8 bits 289 Indicates the impact of the alarm indicated in the TLV. See 290 [RFC3877] and [M.3100] for more information on severity. The 291 The following values are defined in this document. The details 292 of the semantics may be found in [RFC3877] and [M.3100]. 294 Value Definition 295 ----- ---------- 296 0 Cleared 297 1 Indeterminate 298 2 Critical 299 3 Major 300 4 Minor 301 5 Warning 303 Only one Severity TLV may be included in an object. 305 The Global Timestamp TLV has the following format: 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Type | Length | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Global Timestamp | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Global Timestamp: 32 bits 316 A positive integer where all 32 bits are valid that indicates 317 the number of seconds since 0000 UT on 1 January 1970 according 318 to the clock on the node that originates this TLV. This time 319 MAY include leap seconds if they are used by the local clock. 321 Only one Global Timestamp TLV may be included in an object. 323 The Local Timestamp TLV has the following format: 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type | Length | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Local Timestamp | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Local Timestamp: 32 bits 335 Number of seconds reported by the local system clock at the 336 time the associated alarm was detected on the node that 337 originates this TLV. This number is expected to be meaningful 338 in the context of the originating node. For example, it may 339 indicate the number of seconds since the node rebooted or may 340 be a local representation of an unsynchronized real-time clock. 342 Only one Local Timestamp TLV may be included in an object. 344 The Error String TLV has the following format: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Type | Length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | 352 // Error String (NULL padded display string) // 353 | | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Error String: 32 bits minimum (variable) 357 A string of characters in US-ASCII, representing the type of 358 error/alarm. This string is padded to the next largest 4 byte 359 boundary using null characters. Null padding is not required 360 when the string is 32-bit aligned. The contents of error 361 string are implementation dependent. See the condition types 362 listed in Appendices of [GR833] for a list of example strings. 363 Note length includes padding. 365 Multiple Error String TLVs may be included in an object. 367 3.1.2. Procedures 369 This section applies to nodes that support the communication of alarm 370 information. ALARM_SPEC objects are carried in Path and Resv 371 messages. Multiple ALARM_SPEC objects MAY be present. 373 Nodes that support the extensions defined in this document SHOULD 374 store any alarm information from received ALARM_SPEC objects for 375 future use. All ALARM_SPEC objects received in Path messages SHOULD 376 be passed unmodified downstream in the corresponding Path messages. 377 All ALARM_SPEC objects received in Resv messages SHOULD be passed 378 unmodified upstream in the corresponding Resv messages. ALARM_SPEC 379 objects are merged in transmitted Resv messages by including a copy 380 of all ALARM_SPEC objects received in corresponding Resv Messages. 382 To advertise local alarm information, a node generates an ALARM_SPEC 383 object for each alarm and adds it to both the Path and Resv messages 384 for the effected LSP. In all cases, appropriate Error Node Address, 385 Error Code and Error Values MUST be set, see below for a discussion 386 on Error Code and Error Values. As the InPlace and NotGuilty flags 387 only have meaning in ERROR_SPEC objects, they SHOULD NOT be set. 388 TLVs SHOULD be included in the ALARM_SPEC object to identify the 389 interface, if any, associated with the alarm - the TLVs defined in 390 [RFC3471] for identifying interfaces in the IF_ID ERROR_SPEC object 391 [RFC3473] SHOULD be used for this purpose, but note that TLVs type 4 392 and 5 (component interfaces) are deprecated by [RFC4201] and SHOULD 393 NOT be used. TLVs SHOULD also be included to indicate the severity 394 (Severity TLV), the time (Global Timestamp and/or Local Timestamp 395 TLVs), and a (brief) string (Error String TLV) associated with the 396 alarm. The reference count TLV MAY also be included to indicate the 397 number of times an alarm has been repeated at the reporting node. 398 ALARM_SPEC objects received from other nodes are not effected by the 399 addition of local ALARM_SPEC objects, i.e., they continue to be 400 processed as described above. The choice of which alarm or alarms to 401 advertise and which to omit is a local policy matter, and may 402 configurable by the user. 404 There are two ways to indicate time. A global timestamp TLV is used 405 to provide an absolute time reference for the occurrence of an alarm. 406 The local timestamp TLV is used to provide time reference for the 407 occurrence of an alarm that is relative to other information 408 advertised by the node. The global timestamp SHOULD be used on nodes 409 that maintain an absolute time reference. Both timestamp TLVs MAY be 410 used simultaneously. 412 Note, ALARM_SPEC objects SHOULD NOT be added to the Path and Resv 413 states of LSPs that are in "alarm communication inhibited state." 414 ALARM_SPEC objects MAY be added to the state of LSPs that are in an 415 "administratively down" state. These states are indicated by the I 416 and A bits of the Admin_Status object, see Section 3.2. 418 To remove local alarm information, a node simply removes the matching 419 locally generated ALARM_SPEC objects from the outgoing Path and Resv 420 messages. A node MAY modify a locally generated ALARM_SPEC object. 422 Normal refresh and trigger message processing applies to Path or Resv 423 messages that contain ALARM_SPEC objects. Note that changes in 424 ALARM_SPEC objects from one message to the next may include a 425 modification in the contents of a specific ALARM_SPEC object, or a 426 change in the number of ALARM_SPEC objects present. All changes in 427 ALARM_SPEC objects SHOULD be processed as trigger messages. 429 Failure to follow the above directives, in particular the ones 430 labeled "SHOULD" and "SHOULD NOT", may result in the alarm 431 information not being properly or fully communicated. 433 3.1.3. Error Codes and Values 435 The Error Codes and Values used in ALARM_SPEC objects are the same as 436 those used in ERROR_SPEC objects. New Error Code values for use with 437 both ERROR_SPEC and ALARM_SPEC objects may be assigned to support 438 alarm types defined by other standards. 440 In this document we define one new Error Code. The Error Code uses 441 the value TBA (by IANA) and is referred to as "Alarms". The values 442 used in the Error Values field when the Error Code is "Alarms" are 443 the same as the values defined in the IANAItuProbableCause Textual 444 Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. Note 445 these values are managed by IANA, see http://www.iana.org. 447 3.1.4. Backwards Compatibility 449 The support of ALARM_SPEC objects is OPTIONAL. Non-supporting nodes 450 will (according to the rules defined in [RFC2205]) pass the objects 451 through the node unmodified, because the ALARM_SPEC object has a 452 C-Num of the form 11bbbbbb. 454 This allows alarm information to be collected and examined in a 455 network built from a collection of nodes some of which support the 456 communication of alarm information, and some of which do not. 458 3.2. Controlling Alarm Communication 460 Alarm information communication is controlled via Administrative 461 Status Information as carried in the Admin_Status object. A new bit 462 is defined, called the I bit, that indicates when alarm communication 463 is to be inhibited. The definition of this bit does not modify the 464 procedures defined in Section 7 of [RFC3473]. 466 3.2.1. Updated Admin Status Object 468 The format of the Admin_Status object is updated to include the I 469 bit: 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Length | Class-Num(196)| C-Type (1) | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 |R| Reserved |I| |T|A|D| 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Inhibit Alarm Communication (I): 1 bit 480 When set, indicates that alarm communication is disabled for 481 the LSP and that nodes SHOULD NOT add local alarm information. 483 See section 7.1 of [RFC3473] for the definition of the remaining 484 bits. 486 3.2.2. Procedures 488 The I bit may be set and cleared using the procedures defined in 489 Sections 7.2 and 7.3 of [RFC3473]. A node that receives (or 490 generates) an Admin_Status object with the A or I bits set (1), 491 SHOULD remove all locally generated alarm information from the 492 matching LSP's outgoing Path and Resv messages. When a node receives 493 (or generates) an Admin_Status object with the A and I bits clear (0) 494 and there is local alarm information present, it SHOULD add the local 495 alarm information to the matching LSP's outgoing Path and Resv 496 messages. 498 The processing of non-locally generated ALARM_SPEC objects MUST NOT 499 be impacted by the contents of the Admin_Status object, that is, 500 received ALARM_SPEC objects MUST be forwarded unchanged regardless of 501 the received or transmitted settings of the I and A-bits. Note, per 502 [RFC3473], the absence of the Admin_Status object is equivalent to 503 receiving an object containing values all set to zero (0). 505 I bit related processing behavior MAY be overridden locally based on 506 configuration. 508 When generating Notify messages for LSPs with the I bit set, the TLVs 509 described in this document MAY be added to the ERROR_SPEC object sent 510 in the the Notify message. 512 3.3. Message Formats 514 This section presents the RSVP message related formats as modified by 515 this document. The formats specified in [RFC3473] served as the 516 basis of these formats. The objects are listed in suggested 517 ordering. 519 The format of a Path message is as follows: 521 ::= [ ] 522 [ [ | ] ... ] 523 [ ] 524 525 526 [ ] 527 528 [ ] 529 [ ... ] 530 [ ] 531 [ ] 532 [ ] 533 [ ... ] 534 [ ... ] 535 537 is not modified by this document. 539 The format of a Resv message is as follows: 541 ::= [ ] 542 [ [ | ] ... ] 543 [ ] 544 545 546 [ ] [ ] 547 [ ] 548 [ ] 549 [ ... ] 550 [ ... ] 551