idnits 2.17.1 draft-ietf-ccamp-gmpls-alarm-spec-04.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 767. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 778. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 791. ** 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 (August 2006) is 6463 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: 'BCP26' is mentioned on line 634, 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: February 2007 6 August 2006 8 GMPLS - Communication of Alarm Information 10 draft-ietf-ccamp-gmpls-alarm-spec-04.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 Security Considerations ................................... 14 69 5 IANA Considerations ....................................... 15 70 6 References ................................................ 16 71 6.1 Normative References ...................................... 16 72 6.2 Informative References .................................... 16 73 7 Contributors .............................................. 17 74 8 Contact Address ........................................... 17 75 9 Full Copyright Statement .................................. 18 76 10 Intellectual Property ..................................... 18 77 1. Introduction 79 GMPLS Signaling provides mechanisms that can be used to control the 80 reporting of alarms associated with an LSP. This support is provided 81 via Administrative Status Information [RFC3471] and the Admin_Status 82 object [RFC3473]. These mechanisms only control if alarm reporting 83 is inhibited. No provision is made for communication of alarm 84 information within GMPLS. 86 The extension described in this document defines how the alarm 87 information associated with a GMPLS label-switched path (LSP) may be 88 communicated along the path of the LSP. Communication both upstream 89 and downstream is supported. The value in communicating such alarm 90 information is that this information is then available at every node 91 along the LSP for display and diagnostic purposes. Alarm information 92 may also be useful in certain traffic protection scenarios, but such 93 uses are out of scope of this document. Alarm communication is 94 supported via a new object, new error/alarm information TLVs, and a 95 new Administrative Status Information bit. 97 The communication of alarms, as described in this document, is 98 controllable on a per LSP basis. Such communication may be useful 99 within network configurations where not all nodes support 100 communication to a user for reporting of alarms and/or communication 101 is needed to support specific applications. The support of this 102 functionality is optional. 104 The communication of alarms within GMPLS does not imply any 105 modification in behavior of processing of alarms, or for the 106 communication of alarms outside of GMPLS. Additionally, the 107 extension described in this document is not intended to replace any 108 (existing) data plane fault propagation techniques. 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 1.1. Background 116 Problems with data plane state can often be detected by associated 117 data plane hardware components. Such data plane problems are 118 typically filtered based on elapsed time and local policy. Problems 119 that pass the filtering process are normally raised as alarms. These 120 alarms are available for display to operators. They also may be 121 collected centrally through means that are out of the scope of this 122 document. 124 Not all data plane problems cause the LSP to be immediately torn 125 down. Further, there may be a desire, particularly in optical 126 transport networks, to retain an LSP and communicate relevant alarm 127 information even when the data plane state has failed completely. 129 Although error information can be reported using PathErr, ResvErr and 130 Notify messages, these messages typically indicate a problem in 131 signaling state and can only report one problem at at a time. This 132 makes it hard to correlate all of the problems that may be associated 133 with a single LSP and to allow an operator examining the status of an 134 LSP to view a full list of current problems. This situation is 135 exacerbated by the absence of any way to communicate that a problem 136 has been resolved and a corresponding alarm cleared. 138 The extensions defined in this document allow an operator or a 139 software component to obtain a full list of current alarms associated 140 with all of the resources used to support an LSP. The extensions 141 also ensure that this list is kept up-to-date and synchronized with 142 the real alarm status in the network. Finally, the extensions make 143 the list available at every node traversed by an LSP. 145 2. Alarm Information Communication 147 A new object is introduced to carry alarm information details. The 148 details of alarm information are much like the error information 149 carried in the existing ERROR_SPEC objects. For this reason the 150 communication of alarm information uses a format that is based on the 151 communication of error information. 153 The new object introduced to carry alarm information details is 154 called an ALARM_SPEC object. This object has the same format as the 155 ERROR_SPEC object, but uses a new C-Num to avoid the semantics of 156 error processing. Also, additional TLVs are defined for the IF_ID 157 ALARM_SPEC objects to support the communication of information 158 related to a specific alarm. These TLVs may also be useful when 159 included in ERROR_SPEC objects, e.g., when the ERROR_SPEC object is 160 carried within a Notify message. 162 While the details of alarm information are like the details of 163 existing error communication, the semantics of processing differ. 164 Alarm information will typically relate to changes in data plane 165 state, without changes in control state. Alarm information will 166 always be associated with in-place LSPs. Such information will also 167 typically be most useful to operators and applications other than 168 control plane protocol processing. Finally, while error information 169 is communicated within PathErr, ResvErr and Notify messages 170 [RFC3473], alarm information will be carried within Path and Resv 171 messages. 173 Path messages are used to carry alarm information to downstream nodes 174 and Resv messages are used to carry alarm information to upstream 175 nodes. The intent of sending alarm information both upstream and 176 downstream is to provide the same visibility to alarm information at 177 any point along an LSP. The communication of multiple alarms 178 associated with an LSP is supported. In this case, multiple 179 ALARM_SPEC objects will be carried in the Path or Resv messages. 181 The addition of alarm information to Path and Resv messages is 182 controlled via a new Administrative Status Information bit. 183 Administrative Status Information is carried in the Admin_Status 184 object. 186 3. GMPLS-RSVP Details 188 This section provides the GMPLS-RSVP [RFC3473] specification for 189 communication of alarm information. The communication of alarm 190 information is optional. This section applies to nodes that support 191 communication of alarm information. 193 3.1. ALARM_SPEC Objects 195 The ALARM_SPEC objects use the same format as the ERROR_SPEC object, 196 but with class number of TBA (to be assigned by IANA in the form 197 11bbbbbb, per Section 3.1.4). 199 o Class = TBA, C-Type = 1 200 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined 201 for use with ALARM_SPEC.) 203 o Class = TBA, C-Type = 2 204 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined 205 for use with ALARM_SPEC.) 207 o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3 208 Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473]. 210 o IPv6 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 4 211 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473]. 213 3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs 215 The following new TLVs are defined for use with the IPv4 and IPv6 216 IF_ID ALARM_SPEC objects. They may also be used with the IPv4 and 217 IPv6 IF_ID ERROR_SPEC objects. See [RFC3471] section 9.1.1 for the 218 original definition of these values. Note the length provided below 219 is for the total TLV. All TLVs defined in this section are optional. 220 The defined TLVs MUST follow any interface identifying TLVs. No 221 rules apply to the relative ordering of the TLVs defined in this 222 section. 224 [Note: Type values are TBA (to be assigned) by IANA] 226 Type Length Description 227 ---------------------------------- 228 512 8 REFERENCE_COUNT 229 513 8 SEVERITY 230 514 8 GLOBAL_TIMESTAMP 231 515 8 LOCAL_TIMESTAMP 232 516 variable ERROR_STRING 234 The Reference Count 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 | Reference Count | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Reference Count: 32 bits 246 The number of times this alarm has been repeated as determined 247 by the reporting node. This field MUST NOT be set to zero. 249 Only one Reference Count TLV may be included in an object. 251 The Severity TLV has the following format: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type | Length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Reserved |Impact | Severity | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Reserved: 24 bits 262 This field is reserved. It MUST be set to zero on generation, 263 MUST be ignored on receipt and MUST be forwarded unchanged and 264 unexamined by transit nodes. 266 Impact: 4 bits 268 Indicates the impact of the alarm indicated in the TLV. See 269 [M.20] for a general discussion on classification of failures. 270 The following values are defined: 272 Value Definition 273 ----- --------------------- 274 0 Unspecified impact 275 1 Non-Service Affecting (Data traffic not interrupted) 276 2 Service Affecting (Data traffic is interrupted) 278 Severity: 8 bits 280 Indicates the impact of the alarm indicated in the TLV. See 281 [RFC3877] and [M.3100] for more information on severity. The 282 following values are defined: 284 Value Definition 285 ----- ---------- 286 0 Cleared 287 1 Indeterminate 288 2 Critical 289 3 Major 290 4 Minor 291 5 Warning 293 Only one Severity TLV may be included in an object. 295 The Global Timestamp TLV has the following format: 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type | Length | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Global Timestamp | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Global Timestamp: 32 bits 306 The number of seconds since 0000 UT on 1 January 1970, 307 according to the clock on the node that originates this TLV. 309 Only one Global Timestamp TLV may be included in an object. 311 The Local Timestamp TLV has the following format: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type | Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Local Timestamp | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Local Timestamp: 32 bits 323 Number of seconds reported by the local system clock at the 324 time the associated alarm was detected on the node that 325 originates this TLV. This number is expected to be meaningful 326 in the context of the originating node. For example, it may 327 indicate the number of seconds since the node rebooted or may 328 be a local representation of an unsynchronized real-time clock. 330 Only one Local Timestamp TLV may be included in an object. 332 The Error String TLV has the following format: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 // Error String (NULL padded display string) // 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Error String: 32 bits minimum (variable) 345 A string of characters in US-ASCII, representing the type of 346 error/alarm. This string is padded to the next largest 4 byte 347 boundary using null characters. Null padding is not required 348 when the string is 32-bit aligned. The contents of error 349 string are implementation dependent. See the condition types 350 listed in Appendices of [GR833] for a list of example strings. 351 Note length includes padding. 353 Multiple Error String TLVs may be included in an object. 355 3.1.2. Procedures 357 This section applies to nodes that support the communication of alarm 358 information. ALARM_SPEC objects are carried in Path and Resv 359 messages. Multiple ALARM_SPEC objects MAY be present. 361 Nodes that support the communication of alarm information, SHOULD 362 record the information contained in a received ALARM_SPEC for later 363 use. All ALARM_SPEC objects received in Path messages SHOULD be 364 passed unmodified downstream in the corresponding Path messages. All 365 ALARM_SPEC objects received in Resv messages SHOULD be passed 366 unmodified upstream in the corresponding Resv messages. ALARM_SPEC 367 objects are merged in transmitted Resv messages by including a copy 368 of all ALARM_SPEC objects received in corresponding Resv Messages. 370 To advertise local alarm information, a node generates an ALARM_SPEC 371 object for each alarm and adds it to both the Path and Resv messages 372 for the effected LSP. In all cases, appropriate Error Node Address, 373 Error Code and Error Values MUST be set, see below for a discussion 374 on Error Code and Error Values. As the InPlace and NotGuilty flags 375 only have meaning in ERROR_SPEC objects, they SHOULD NOT be set. 376 TLVs SHOULD be included in the ALARM_SPEC object to identify the 377 interface, if any, associated with the alarm - the TLVs defined in 378 [RFC3471] for identifying interfaces in the IF_ID ERROR_SPEC object 379 [RFC3473] SHOULD be used for this purpose, but note that TLVs type 4 380 and 5 (component interfaces) are deprecated by [RFC4201] and SHOULD 381 NOT be used. TLVs SHOULD also be included to indicate the severity 382 (Severity TLV), the time (Global Timestamp and/or Local Timestamp 383 TLVs), and a (brief) string (Error String TLV) associated with the 384 alarm. The reference count TLV MAY also be included to indicate the 385 number of times an alarm has been repeated at the reporting node. 386 ALARM_SPEC objects received from other nodes are not effected by the 387 addition of local ALARM_SPEC objects, i.e., they continue to be 388 processed as described above. The choice of which alarm or alarms to 389 advertise and which to omit is a local policy matter, and may 390 configurable by the user. 392 There are two ways to indicate time. A global timestamp TLV is used 393 to provide an absolute time reference for the occurrence of an alarm. 394 The local timestamp TLV is used to provide time reference for the 395 occurrence of an alarm that is relative to other information 396 advertised by the node. The global timestamp SHOULD be used on nodes 397 that maintain an absolute time reference. Both timestamp TLVs MAY be 398 used simultaneously. 400 Note, ALARM_SPEC objects SHOULD NOT be added to the Path and Resv 401 states of LSPs that are in "alarm communication inhibited state." 402 ALARM_SPEC objects MAY be added to the state of LSPs that are in an 403 "administratively down" state. These states are indicated by the I 404 and A bits of the Admin_Status object, see Section 3.2. 406 To remove local alarm information, a node simply removes the matching 407 locally generated ALARM_SPEC objects from the outgoing Path and Resv 408 messages. A node MAY modify a locally generated ALARM_SPEC object. 410 Normal refresh and trigger message processing applies to Path or Resv 411 messages that contain ALARM_SPEC objects. Note that changes in 412 ALARM_SPEC objects from one message to the next may include a 413 modification in the contents of a specific ALARM_SPEC object, or a 414 change in the number of ALARM_SPEC objects present. All changes in 415 ALARM_SPEC objects SHOULD be processed as trigger messages. 417 Failure to follow the above directives, in particular the ones 418 labeled "SHOULD" and "SHOULD NOT", may result in the alarm 419 information not being properly or fully communicated. 421 3.1.3. Error Codes and Values 423 The Error Codes and Values used in ALARM_SPEC objects are the same as 424 those used in ERROR_SPEC objects. New Error Code values for use with 425 both ERROR_SPEC and ALARM_SPEC objects may be assigned to support 426 alarm types defined by other standards. 428 In this document we define one new Error Code. The Error Code uses 429 the value TBA (by IANA) and is referred to as "Alarms". The values 430 used in the Error Values field are the same as the values used for 431 IANAItuProbableCause in the Alarm MIB [RFC3877]. Note these values 432 are managed by IANA, see http://www.iana.org. 434 3.1.4. Backwards Compatibility 436 The support of ALARM_SPEC objects is optional. Non-supporting nodes 437 will pass the objects through the node unmodified, because the 438 ALARM_SPEC object has a C-Num of the form 11bbbbbb. 440 This allows alarm information to be collected and examined in a 441 network built from a collection of nodes some of which support the 442 communication of alarm information, and some of which do not. 444 3.2. Controlling Alarm Communication 446 Alarm information communication is controlled via Administrative 447 Status Information as carried in the Admin_Status object. A new bit 448 is defined, called the I bit, that indicates when alarm communication 449 is to be inhibited. The definition of this bit does not modify the 450 procedures defined in Section 7 of [RFC3473]. 452 3.2.1. Updated Admin Status Object 454 The format of the Admin_Status object is updated to include the I 455 bit: 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Length | Class-Num(196)| C-Type (1) | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 |R| Reserved |I| |T|A|D| 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Inhibit Alarm Communication (I): 1 bit 466 When set, indicates that alarm communication is disabled for 467 the LSP and that nodes SHOULD NOT add local alarm information. 469 See section 7.1 of [RFC3473] for the definition of the remaining 470 bits. 472 3.2.2. Procedures 474 The I bit may be set and cleared using the procedures defined in 475 Sections 7.2 and 7.3 of [RFC3473]. A node that receives (or 476 generates) an Admin_Status object with the A or I bits set (1), 477 SHOULD remove all locally generated alarm information from the 478 matching LSP's outgoing Path and Resv messages. When a node receives 479 (or generates) an Admin_Status object with the A and I bits clear (0) 480 and there is local alarm information present, it SHOULD add the local 481 alarm information to the matching LSP's outgoing Path and Resv 482 messages. 484 The processing of non-locally generated ALARM_SPEC objects MUST NOT 485 be impacted by the contents of the Admin_Status object, that is, 486 received ALARM_SPEC objects MUST be forwarded unchanged regardless of 487 the received or transmitted settings of the I and A-bits. Note, per 488 [RFC3473], the absence of the Admin_Status object is equivalent to 489 receiving an object containing values all set to zero (0). 491 I bit related processing behavior MAY be overridden locally based on 492 configuration. 494 When generating Notify messages for LSPs with the I bit set, the TLVs 495 described in this document MAY be added to the ERROR_SPEC object sent 496 in the the Notify message. 498 3.3. Message Formats 500 This section presents the RSVP message related formats as modified by 501 this document. The formats specified in [RFC3473] served as the 502 basis of these formats. The objects are listed in suggested 503 ordering. 505 The format of a Path message is as follows: 507 ::= [ ] 508 [ [ | ] ... ] 509 [ ] 510 511 512 [ ] 513 514 [ ] 515 [ ... ] 516 [ ] 517 [ ] 518 [ ] 519 [ ... ] 520 [ ... ] 521 523 is not modified by this document. 525 The format of a Resv message is as follows: 527 ::= [ ] 528 [ [ | ] ... ] 529 [ ] 530 531 532 [ ] [ ] 533 [ ] 534 [ ] 535 [ ... ] 536 [ ... ] 537