idnits 2.17.1 draft-ietf-ccamp-gmpls-alarm-spec-06.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 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 849. ** 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 document seems to lack an Authors' Addresses Section. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- 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 6423 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: 'RFC-ccamp-gmpls-alarm-spec' is mentioned on line 722, but not defined Summary: 5 errors (**), 0 flaws (~~), 2 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-06.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 .................................... 11 61 3.1.4 Backwards Compatibility ................................... 11 62 3.2 Controlling Alarm Communication ........................... 11 63 3.2.1 Updated Admin Status Object ............................... 12 64 3.2.2 Procedures ................................................ 12 65 3.3 Message Formats ........................................... 13 66 3.4 Relationship to GMPLS UNI ................................. 14 67 3.5 Relationship to GMPLS E-NNI .............................. 14 68 4 Acknowledgments ........................................... 15 69 5 Security Considerations ................................... 15 70 6 IANA Considerations ....................................... 16 71 6.1 New RSVP Object ........................................... 16 72 6.2 New Interface ID Types .................................... 16 73 6.3 New Registry for Admin-Status Object Bit Fields ........... 17 74 6.4 New RSVP Error Code ....................................... 17 75 7 References ................................................ 18 76 7.1 Normative References ...................................... 18 77 7.2 Informative References .................................... 18 78 8 Contributors .............................................. 19 79 9 Contact Address ........................................... 19 80 10 Full Copyright Statement .................................. 20 81 11 Intellectual Property ..................................... 20 82 1. Introduction 84 GMPLS Signaling provides mechanisms that can be used to control the 85 reporting of alarms associated with an LSP. This support is provided 86 via Administrative Status Information [RFC3471] and the Admin_Status 87 object [RFC3473]. These mechanisms only control if alarm reporting 88 is inhibited. No provision is made for communication of alarm 89 information within GMPLS. 91 The extension described in this document defines how the alarm 92 information associated with a GMPLS label-switched path (LSP) may be 93 communicated along the path of the LSP. Communication both upstream 94 and downstream is supported. The value in communicating such alarm 95 information is that this information is then available at every node 96 along the LSP for display and diagnostic purposes. Alarm information 97 may also be useful in certain traffic protection scenarios, but such 98 uses are out of scope of this document. Alarm communication is 99 supported via a new object, new error/alarm information TLVs, and a 100 new Administrative Status Information bit. 102 The communication of alarms, as described in this document, is 103 controllable on a per LSP basis. Such communication may be useful 104 within network configurations where not all nodes support 105 communication to a user for reporting of alarms and/or communication 106 is needed to support specific applications. The support of this 107 functionality is optional. 109 The communication of alarms within GMPLS does not imply any 110 modification in behavior of processing of alarms, or for the 111 communication of alarms outside of GMPLS. Additionally, the 112 extension described in this document is not intended to replace any 113 (existing) data plane fault propagation techniques. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 1.1. Background 121 Problems with data plane state can often be detected by associated 122 data plane hardware components. Such data plane problems are 123 typically filtered based on elapsed time and local policy. Problems 124 that pass the filtering process are normally raised as alarms. These 125 alarms are available for display to operators. They also may be 126 collected centrally through means that are out of the scope of this 127 document. 129 Not all data plane problems cause the LSP to be immediately torn 130 down. Further, there may be a desire, particularly in optical 131 transport networks, to retain an LSP and communicate relevant alarm 132 information even when the data plane state has failed completely. 134 Although error information can be reported using PathErr, ResvErr and 135 Notify messages, these messages typically indicate a problem in 136 signaling state and can only report one problem at at a time. This 137 makes it hard to correlate all of the problems that may be associated 138 with a single LSP and to allow an operator examining the status of an 139 LSP to view a full list of current problems. This situation is 140 exacerbated by the absence of any way to communicate that a problem 141 has been resolved and a corresponding alarm cleared. 143 The extensions defined in this document allow an operator or a 144 software component to obtain a full list of current alarms associated 145 with all of the resources used to support an LSP. The extensions 146 also ensure that this list is kept up-to-date and synchronized with 147 the real alarm status in the network. Finally, the extensions make 148 the list available at every node traversed by an LSP. 150 2. Alarm Information Communication 152 A new object is introduced to carry alarm information details. The 153 details of alarm information are much like the error information 154 carried in the existing ERROR_SPEC objects. For this reason the 155 communication of alarm information uses a format that is based on the 156 communication of error information. 158 The new object introduced to carry alarm information details is 159 called an ALARM_SPEC object. This object has the same format as the 160 ERROR_SPEC object, but uses a new C-Num to avoid the semantics of 161 error processing. Also, additional TLVs are defined for the IF_ID 162 ALARM_SPEC objects to support the communication of information 163 related to a specific alarm. These TLVs may also be useful when 164 included in ERROR_SPEC objects, e.g., when the ERROR_SPEC object is 165 carried within a Notify message. 167 While the details of alarm information are like the details of 168 existing error communication, the semantics of processing differ. 169 Alarm information will typically relate to changes in data plane 170 state, without changes in control state. Alarm information will 171 always be associated with in-place LSPs. Such information will also 172 typically be most useful to operators and applications other than 173 control plane protocol processing. Finally, while error information 174 is communicated within PathErr, ResvErr and Notify messages 175 [RFC3473], alarm information will be carried within Path and Resv 176 messages. 178 Path messages are used to carry alarm information to downstream nodes 179 and Resv messages are used to carry alarm information to upstream 180 nodes. The intent of sending alarm information both upstream and 181 downstream is to provide the same visibility to alarm information at 182 any point along an LSP. The communication of multiple alarms 183 associated with an LSP is supported. In this case, multiple 184 ALARM_SPEC objects will be carried in the Path or Resv messages. 186 The addition of alarm information to Path and Resv messages is 187 controlled via a new Administrative Status Information bit. 188 Administrative Status Information is carried in the Admin_Status 189 object. 191 3. GMPLS-RSVP Details 193 This section provides the GMPLS-RSVP [RFC3473] specification for 194 communication of alarm information. The communication of alarm 195 information is OPTIONAL. This section applies to nodes that support 196 communication of alarm information. 198 3.1. ALARM_SPEC Objects 200 The ALARM_SPEC objects use the same format as the ERROR_SPEC object, 201 but with class number of TBA (to be assigned by IANA in the form 202 11bbbbbb, per Section 3.1.4). 204 o Class = TBA, C-Type = 1 205 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined 206 for use with ALARM_SPEC.) 208 o Class = TBA, C-Type = 2 209 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined 210 for use with ALARM_SPEC.) 212 o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3 213 Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473]. 215 o IPv6 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 4 216 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473]. 218 3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs 220 The following new TLVs are defined for use with the IPv4 and IPv6 221 IF_ID ALARM_SPEC objects. They may also be used with the IPv4 and 222 IPv6 IF_ID ERROR_SPEC objects. See [RFC3471] section 9.1.1 for the 223 original definition of these values. Note the length provided below 224 is for the total TLV. All TLVs defined in this section are OPTIONAL. 225 The defined TLVs MUST follow any interface identifying TLVs. No 226 rules apply to the relative ordering of the TLVs defined in this 227 section. 229 [Note: Type values are TBA (to be assigned) by IANA] 231 Type Length Description 232 ---------------------------------- 233 512 8 REFERENCE_COUNT 234 513 8 SEVERITY 235 514 8 GLOBAL_TIMESTAMP 236 515 8 LOCAL_TIMESTAMP 237 516 variable ERROR_STRING 239 The Reference Count TLV has the following format: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type | Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Reference Count | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Reference Count: 32 bits 251 The number of times this alarm has been repeated as determined 252 by the reporting node. This field MUST NOT be set to zero and 253 TLVs received with this field set to zero MUST be ignored. 255 Only one Reference Count TLV may be included in an object. 257 The Severity TLV has the following format: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type | Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Reserved |Impact | Severity | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Reserved: 20 bits 269 This field is reserved. It MUST be set to zero on generation, 270 MUST be ignored on receipt and MUST be forwarded unchanged and 271 unexamined by transit nodes. 273 Impact: 4 bits 275 Indicates the impact of the alarm indicated in the TLV. See 276 [M.20] for a general discussion on classification of failures. 277 The following values are defined in this document. The details 278 of the semantics may be found in [M.20]. 280 Value Definition 281 ----- --------------------- 282 0 Unspecified impact 283 1 Non-Service Affecting (Data traffic not interrupted) 284 2 Service Affecting (Data traffic is interrupted) 286 Severity: 8 bits 288 Indicates the impact of the alarm indicated in the TLV. See 289 [RFC3877] and [M.3100] for more information on severity. The 290 following values are defined in this document. The details of 291 the semantics may be found in [RFC3877] and [M.3100]: 293 Value Definition 294 ----- ---------- 295 0 Cleared 296 1 Indeterminate 297 2 Critical 298 3 Major 299 4 Minor 300 5 Warning 302 Only one Severity TLV may be included in an object. 304 The Global Timestamp TLV has the following format: 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Type | Length | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Global Timestamp | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Global Timestamp: 32 bits 316 An unsigned fixed-point integer that indicates the number of 317 seconds since 00:00:00 UT on 1 January 1970 according to the 318 clock on the node that originates this TLV. This time MAY 319 include leap seconds if they are used by the local clock and 320 SHOULD contain the same time value as used by the node when the 321 alarm is reported through other systems (such as within the 322 Management Plane) if global time is used in those reports. 324 Only one Global Timestamp TLV may be included in an object. 326 The Local Timestamp TLV has the following format: 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Local Timestamp | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Local Timestamp: 32 bits 338 Number of seconds reported by the local system clock at the 339 time the associated alarm was detected on the node that 340 originates this TLV. This number is expected to be meaningful 341 in the context of the originating node. For example, it may 342 indicate the number of seconds since the node rebooted or may 343 be a local representation of an unsynchronized real-time clock. 345 Only one Local Timestamp TLV may be included in an object. 347 The Error String TLV has the following format: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type | Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | | 355 // Error String (NULL padded display string) // 356 | | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 Error String: 32 bits minimum (variable) 361 A string of characters in US-ASCII, representing the type of 362 error/alarm. This string is padded to the next largest 4 byte 363 boundary using null characters. Null padding is not required 364 when the string is 32-bit aligned. The contents of error 365 string are implementation dependent. See the condition types 366 listed in Appendices of [GR833] for a list of example strings. 367 Note length includes padding. 369 Multiple Error String TLVs may be included in an object. 371 3.1.2. Procedures 373 This section applies to nodes that support the communication of alarm 374 information. ALARM_SPEC objects are carried in Path and Resv 375 messages. Multiple ALARM_SPEC objects MAY be present. 377 Nodes that support the extensions defined in this document SHOULD 378 store any alarm information from received ALARM_SPEC objects for 379 future use. All ALARM_SPEC objects received in Path messages SHOULD 380 be passed unmodified downstream in the corresponding Path messages. 381 All ALARM_SPEC objects received in Resv messages SHOULD be passed 382 unmodified upstream in the corresponding Resv messages. ALARM_SPEC 383 objects are merged in transmitted Resv messages by including a copy 384 of all ALARM_SPEC objects received in corresponding Resv Messages. 386 To advertise local alarm information, a node generates an ALARM_SPEC 387 object for each alarm and adds it to both the Path and Resv messages 388 for the effected LSP. In all cases, appropriate Error Node Address, 389 Error Code and Error Values MUST be set, see below for a discussion 390 on Error Code and Error Values. As the InPlace and NotGuilty flags 391 only have meaning in ERROR_SPEC objects, they SHOULD NOT be set. 392 TLVs SHOULD be included in the ALARM_SPEC object to identify the 393 interface, if any, associated with the alarm - the TLVs defined in 394 [RFC3471] for identifying interfaces in the IF_ID ERROR_SPEC object 395 [RFC3473] SHOULD be used for this purpose, but note that TLVs type 4 396 and 5 (component interfaces) are deprecated by [RFC4201] and SHOULD 397 NOT be used. TLVs SHOULD also be included to indicate the severity 398 (Severity TLV), the time (Global Timestamp and/or Local Timestamp 399 TLVs), and a (brief) string (Error String TLV) associated with the 400 alarm. The reference count TLV MAY also be included to indicate the 401 number of times an alarm has been repeated at the reporting node. 402 ALARM_SPEC objects received from other nodes are not effected by the 403 addition of local ALARM_SPEC objects, i.e., they continue to be 404 processed as described above. The choice of which alarm or alarms to 405 advertise and which to omit is a local policy matter, and may 406 configurable by the user. 408 There are two ways to indicate time. A global timestamp TLV is used 409 to provide an absolute time reference for the occurrence of an alarm. 410 The local timestamp TLV is used to provide time reference for the 411 occurrence of an alarm that is relative to other information 412 advertised by the node. The global timestamp SHOULD be used on nodes 413 that maintain an absolute time reference. Both timestamp TLVs MAY be 414 used simultaneously. 416 Note, ALARM_SPEC objects SHOULD NOT be added to the Path and Resv 417 states of LSPs that are in "alarm communication inhibited state." 418 ALARM_SPEC objects MAY be added to the state of LSPs that are in an 419 "administratively down" state. These states are indicated by the I 420 and A bits of the Admin_Status object, see Section 3.2. 422 To remove local alarm information, a node simply removes the matching 423 locally generated ALARM_SPEC objects from the outgoing Path and Resv 424 messages. A node MAY modify a locally generated ALARM_SPEC object. 426 Normal refresh and trigger message processing applies to Path or Resv 427 messages that contain ALARM_SPEC objects. Note that changes in 428 ALARM_SPEC objects from one message to the next may include a 429 modification in the contents of a specific ALARM_SPEC object, or a 430 change in the number of ALARM_SPEC objects present. All changes in 431 ALARM_SPEC objects SHOULD be processed as trigger messages. 433 Failure to follow the above directives, in particular the ones 434 labeled "SHOULD" and "SHOULD NOT", may result in the alarm 435 information not being properly or fully communicated. 437 3.1.3. Error Codes and Values 439 The Error Codes and Values used in ALARM_SPEC objects are the same as 440 those used in ERROR_SPEC objects. New Error Code values for use with 441 both ERROR_SPEC and ALARM_SPEC objects may be assigned to support 442 alarm types defined by other standards. 444 In this document we define one new Error Code. The Error Code uses 445 the value TBA (by IANA) and is referred to as "Alarms". The values 446 used in the Error Values field when the Error Code is "Alarms" are 447 the same as the values defined in the IANAItuProbableCause Textual 448 Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. Note 449 these values are managed by IANA, see http://www.iana.org. 451 3.1.4. Backwards Compatibility 453 The support of ALARM_SPEC objects is OPTIONAL. Non-supporting nodes 454 will (according to the rules defined in [RFC2205]) pass the objects 455 through the node unmodified, because the ALARM_SPEC object has a C- 456 Num of the form 11bbbbbb. 458 This allows alarm information to be collected and examined in a 459 network built from a collection of nodes some of which support the 460 communication of alarm information, and some of which do not. 462 3.2. Controlling Alarm Communication 464 Alarm information communication is controlled via Administrative 465 Status Information as carried in the Admin_Status object. A new bit 466 is defined, called the I bit, that indicates when alarm communication 467 is to be inhibited. The definition of this bit does not modify the 468 procedures defined in Section 7 of [RFC3473]. 470 3.2.1. Updated Admin Status Object 472 The format of the Admin_Status object is updated to include the I 473 bit: 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Length | Class-Num(196)| C-Type (1) | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 |R| Reserved |I| |T|A|D| 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Inhibit Alarm Communication (I): 1 bit 484 When set, indicates that alarm communication is disabled for 485 the LSP and that nodes SHOULD NOT add local alarm information. 487 See section 7.1 of [RFC3473] for the definition of the remaining 488 bits. 490 3.2.2. Procedures 492 The I bit may be set and cleared using the procedures defined in 493 Sections 7.2 and 7.3 of [RFC3473]. A node that receives (or 494 generates) an Admin_Status object with the A or I bits set (1), 495 SHOULD remove all locally generated alarm information from the 496 matching LSP's outgoing Path and Resv messages. When a node receives 497 (or generates) an Admin_Status object with the A and I bits clear (0) 498 and there is local alarm information present, it SHOULD add the local 499 alarm information to the matching LSP's outgoing Path and Resv 500 messages. 502 The processing of non-locally generated ALARM_SPEC objects MUST NOT 503 be impacted by the contents of the Admin_Status object, that is, 504 received ALARM_SPEC objects MUST be forwarded unchanged regardless of 505 the received or transmitted settings of the I and A-bits. Note, per 506 [RFC3473], the absence of the Admin_Status object is equivalent to 507 receiving an object containing values all set to zero (0). 509 I bit related processing behavior MAY be overridden locally based on 510 configuration. 512 When generating Notify messages for LSPs with the I bit set, the TLVs 513 described in this document MAY be added to the ERROR_SPEC object sent 514 in the the Notify message. 516 3.3. Message Formats 518 This section presents the RSVP message related formats as modified by 519 this document. The formats specified in [RFC3473] served as the 520 basis of these formats. The objects are listed in suggested 521 ordering. 523 The format of a Path message is as follows: 525 ::= [ ] 526 [ [ | ] ... ] 527 [ ] 528 529 530 [ ] 531 532 [ ] 533 [ ... ] 534 [ ] 535 [ ] 536 [ ] 537 [ ... ] 538 [ ... ] 539 541 is not modified by this document. 543 The format of a Resv message is as follows: 545 ::= [ ] 546 [ [ | ] ... ] 547 [ ] 548 549 550 [ ] [ ] 551 [ ] 552 [ ] 553 [ ... ] 554 [ ... ] 555