idnits 2.17.1 draft-ietf-ccamp-gmpls-alarm-spec-02.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 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 722. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 735. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 3 instances of too long lines in the document, the longest one being 2 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 (November 2004) is 7094 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 596, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-gmpls-rsvp-te-ason-02 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger - Editor (Movaz Networks) 2 Updates: 3473 3 Category: Standards Track 4 Expiration Date: May 2005 6 November 2004 8 GMPLS - Communication of Alarm Information 10 draft-ietf-ccamp-gmpls-alarm-spec-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 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 a "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 Contents 47 1 Introduction .............................................. 3 48 1.1 Background ................................................ 3 49 2 Alarm Information Communication ........................... 4 50 3 GMPLS-RSVP Details ........................................ 5 51 3.1 ALARM_SPEC Objects ........................................ 5 52 3.1.1 IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs .................... 6 53 3.1.2 Procedures ................................................ 9 54 3.1.3 Error Codes and Values .................................... 10 55 3.1.4 Backwards Compatibility ................................... 10 56 3.2 Controlling Alarm Communication ........................... 11 57 3.2.1 Updated Admin Status Object ............................... 11 58 3.2.2 Procedures ................................................ 11 59 3.3 Message Formats ........................................... 12 60 3.4 Relationship to GMPLS UNI ................................. 13 61 3.5 Relationship to GMPLS E-NNI .............................. 14 62 4 Security Considerations ................................... 14 63 5 IANA Considerations ....................................... 15 64 6 References ................................................ 15 65 6.1 Normative References ...................................... 15 66 6.2 Informative References .................................... 16 67 7 Contributors .............................................. 17 68 8 Contact Address ........................................... 17 69 9 Full Copyright Statement .................................. 18 70 10 Intellectual Property ..................................... 18 71 1. Introduction 73 GMPLS Signaling provides mechanisms that can be used to control the 74 reporting of alarms associated with an LSP. This support is provided 75 via Administrative Status Information [RFC3471] and the Admin_Status 76 object [RFC3473]. These mechanisms only control if alarm reporting 77 is inhibited. No provision is made for communication of alarm 78 information within GMPLS. 80 The extension described in this document defines how the alarm 81 information associated with a GMPLS label-switched path (LSP) may be 82 communicated along the path of the LSP. Communication both upstream 83 and downstream is supported. The value in communicating such alarm 84 information is that this information is then available at every node 85 along the LSP for display and diagnostic purposes. Alarm information 86 may also be useful in certain traffic protection scenarios, but such 87 uses are out of scope of this document. Alarm communication is 88 supported via a new object, new error/alarm information TLVs, and a 89 new Administrative Status Information bit. 91 The communication of alarms, as described in this document, is 92 controllable on a per LSP basis. Such communication may be useful 93 within network configurations where not all nodes support 94 communication to a user for reporting of alarms and/or communication 95 is needed to support specific applications. The support of this 96 functionality is optional. 98 The communication of alarms within GMPLS does not imply any 99 modification in behavior of processing of alarms, or for the 100 communication of alarms outside of GMPLS. Additionally, the 101 extension described in this document is not intended to replace any 102 (existing) data plane fault propagation techniques. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 1.1. Background 110 Problems with data plane state can often be detected by associated 111 data plane hardware components. Such data plane problems are 112 typically filtered based on elapsed time and local policy. Problems 113 that pass the filtering process are normally raised as alarms. These 114 alarms are available for display to operators. They also may be 115 collected centrally through means that are out of the scope of this 116 document. 118 Not all data plane problems cause the LSP to be immediately torn 119 down. Further, there may be a desire, particularly in optical 120 transport networks, to retain an LSP and communicate relevant alarm 121 information even when the data plane state has failed completely. 123 Although error information can be reported using PathErr, ResvErr and 124 Notify messages, these messages typically indicate a problem in 125 signaling state and can only report one problem at at a time. This 126 makes it hard to correlate all of the problems that may be associated 127 with a single LSP and to allow an operator examining the status of an 128 LSP to view a full list of current problems. This situation is 129 exa 130 cerbated by the absence of any way to communicate that a problem 131 has been resolved and a corresponding alarm cleared. 133 The extensions defined in this document allow an operator or a 134 software component to obtain a full list of current alarms associated 135 with all of the resources used to support an LSP. The extensions 136 also ensure that this list is kept up-to-date and synchronized with 137 the real alarm status in the network. Finally, the extensions make 138 the list available at every node traversed by an LSP. 140 2. Alarm Information Communication 142 A new object is introduced to carry alarm information details. The 143 details of alarm information are much like the error information 144 carried in the existing ERROR_SPEC objects. For this reason the 145 communication of alarm information uses a format that is based on the 146 communication of error information. 148 The new object introduced to carry alarm information details is 149 called an ALARM_SPEC object. This object has the same format as the 150 ERROR_SPEC object, but uses a new C-Num to avoid the semantics of 151 error processing. Also, additional TLVs are defined for the IF_ID 152 ALARM_SPEC objects to support the communication of information 153 related to a specific alarm. These TLVs may also be useful when 154 included in ERROR_SPEC objects, e.g., when the ERROR_SPEC object is 155 carried within a Notify message. 157 While the details of alarm information are like the details of 158 existing error communication, the semantics of processing differ. 159 Alarm information will typically relate to changes in data plane 160 state, without changes in control state. Alarm information will 161 always be associated with in-place LSPs. Such information will also 162 typically be most useful to operators and applications other than 163 control plane protocol processing. Finally, while error information 164 is communicated within PathErr, ResvErr and Notify messages 165 [RFC3473], alarm information will be carried within Path and Resv 166 messages. 168 Path messages are used to carry alarm information to downstream nodes 169 and Resv messages are used to carry alarm information to upstream 170 nodes. The intent of sending alarm information both upstream and 171 downstream is to provide the same visibility to alarm information at 172 any point along an LSP. The communication of multiple alarms 173 associated with an LSP is supported. In this case, multiple 174 ALARM_SPEC objects will be carried in the Path or Resv messages. 176 The addition of alarm information to Path and Resv messages is 177 controlled via a new Administrative Status Information bit. 178 Administrative Status Information is carried in the Admin_Status 179 object. 181 3. GMPLS-RSVP Details 183 This section provides the GMPLS-RSVP [RFC3473] specification for 184 communication of alarm information. The communication of alarm 185 information is optional. This section applies to nodes that support 186 communication of alarm information. 188 3.1. ALARM_SPEC Objects 190 The ALARM_SPEC objects use the same format as the ERROR_SPEC object, 191 but with class number of TBA (to be assigned by IANA in the form 192 11bbbbbb). 194 o Class = TBA, C-Type = 1 195 Reserved. 197 o Class = TBA, C-Type = 2 198 Reserved. 200 o IPv4 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 3 201 Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473]. 203 o IPv6 IF_ID ALARM_SPEC object: Class = TBA, C-Type = 4 204 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473]. 206 3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs 208 The following new TLVs are defined for use with the IPv4 and IPv6 209 IF_ID ALARM_SPEC objects. They may also be used with the IPv4 and 210 IPv6 IF_ID ERROR_SPEC objects. See [RFC3471] section 9.1.1 for the 211 original definition of these values. Note the length provided below 212 is for the total TLV. All TLVs defined in this section are optional. 213 The defined TLVs MUST follow any interface identifying TLVs. No 214 rules apply to the relative ordering of the TLVs defined in this 215 section. 217 [Note: Type values are TBA (to be assigned) by IANA] 219 Type Length Description 220 ---------------------------------- 221 512 8 REFERENCE_COUNT 222 513 8 SEVERITY 223 514 8 GLOBAL_TIMESTAMP 224 515 8 LOCAL_TIMESTAMP 225 516 variable ERROR_STRING 227 The Reference Count TLV has the following format: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Reference Count | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Reference Count: 32 bits 239 The number of times this alarm has been repeated as determined 240 by the reporting node. This field MUST NOT be set to zero. 242 Only one Reference Count TLV may be included in an object. 244 The Severity TLV has the following format: 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Type | Length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Reserved |Impact | Severity | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Reserved: 24 bits 255 This field is reserved. It MUST be set to zero on generation, 256 MUST be ignored on receipt and MUST be forwarded unchanged and 257 unexamined by transit nodes. 259 Impact: 4 bits 261 Indicates the impact of the alarm indicated in the TLV. See 262 [M.20] for a general discussion on classification of failures. 263 The following values are defined: 265 Value Definition 266 ----- --------------------- 267 0 Unspecified impact 268 1 Non-Service Affecting (Data traffic not interrupted) 269 2 Service Affecting (Data traffic is interrupted) 271 Severity: 8 bits 273 Indicates the impact of the alarm indicated in the TLV. See 274 [RFC3877] for more information on severity. The following 275 values are defined: 277 Value Definition 278 ----- ---------- 279 0 Cleared 280 1 Indeterminate 281 2 Critical 282 3 Major 283 4 Minor 284 5 Warning 286 Only one Severity TLV may be included in an object. 288 The Global Timestamp TLV has the following format: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Global Timestamp | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Berger, et. al. 300 Global Timestamp: 32 bits 302 The number of seconds since 0000 UT on 1 January 1970, 303 according to the clock on the node that originates this TLV. 305 Only one Global Timestamp TLV may be included in an object. 307 The Local Timestamp TLV has the following format: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | Length | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Local Timestamp | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Local Timestamp: 32 bits 319 Number of seconds reported by the local system clock at the 320 time the associated alarm was detected on the node that 321 originates this TLV. 323 Only one Local Timestamp TLV may be included in an object. 325 The Error String TLV has the following format: 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Type | Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 // Error String (NULL padded display string) // 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Error String: 32 bits minimum (variable) 338 A string of characters, representing the type of error/alarm. 339 This string is padded to the next largest 4 byte boundary using 340 null characters. Null padding is not required when the string 341 is 32-bit aligned. The contents of error string are 342 implementation dependent. See the condition types listed in 343 Appendices of [GR833] for a list of example strings. Note 344 length includes padding. 346 Multiple Error String TLVs may be included in an object. 348 3.1.2. Procedures 350 This section applies to nodes that support the communication of alarm 351 information. ALARM_SPEC objects are carried in Path and Resv 352 messages. Multiple ALARM_SPEC objects MAY be present. 354 Nodes that support the communication of alarm information, SHOULD 355 record the information contained in a received ALARM_SPEC for later 356 use. All ALARM_SPEC objects received in Path messages SHOULD be 357 passed unmodified downstream in the corresponding Path messages. All 358 ALARM_SPEC objects received in Resv messages SHOULD be passed 359 unmodified upstream in the corresponding Resv messages. ALARM_SPEC 360 objects are merged in transmitted Resv messages by including a copy 361 of all ALARM_SPEC objects received in corresponding Resv Messages. 363 To advertise local alarm information, a node generates an ALARM_SPEC 364 object for each alarm and adds it to both the Path and Resv messages 365 for the effected LSP. In all cases, appropriate Error Node Address, 366 Error Code and Error Values MUST be set, see below for a discussion 367 on Error Code and Error Values. The InPlace and NotGuilty flags 368 SHOULD NOT be set. TLVs SHOULD be included to identify the 369 interface, if any, the severity, the time and a (brief) string 370 associated with the alarm. The reference count TLV MAY also be 371 included. ALARM_SPEC objects received from other nodes are not 372 effected by the addition of local ALARM_SPEC objects, i.e., they 373 continue to be processed as described above. The choice of which 374 alarm or alarms to advertise and which to omit is a local policy 375 matter, and may configurable by the user. 377 There are two ways to indicate time. A global timestamp TLV is used 378 to provide an absolute time reference for the occurrence of an alarm. 379 The local timestamp TLV is used to provide time reference for the 380 occurrence of an alarm that is relative to other information 381 advertised by the node. The global timestamp SHOULD be used on nodes 382 that maintain an absolute time reference. Both timestamp TLVs MAY be 383 used simultaneously. 385 Note, ALARM_SPEC objects SHOULD NOT be added to the state of LSPs 386 that are in "alarm communication inhibited state." ALARM_SPEC 387 objects MAY be added to the state of LSPs that are in an 388 "administratively down" state. These states are indicated by the I 389 and A bits of the Admin_Status object, see Section 3.2. 391 To remove local alarm information, a node simply removes the matching 392 locally generated ALARM_SPEC objects from the outgoing Path and Resv 393 messages. A node MAY modify a locally generated ALARM_SPEC object. 395 Normal refresh and trigger message processing applies to Path or Resv 396 messages that contain ALARM_SPEC objects. Note that changes in 397 ALARM_SPEC objects from one message to the next may include a 398 modification in the contents of a specific ALARM_SPEC object, or a 399 change in the number of ALARM_SPEC objects present. All changes in 400 ALARM_SPEC objects SHOULD be processed as trigger messages. 402 3.1.3. Error Codes and Values 404 The Error Codes and Values used in ALARM_SPEC objects are the same as 405 those used in ERROR_SPEC objects. New Error Code values for use with 406 both ERROR_SPEC and ALARM_SPEC objects may be assigned to support 407 alarm types defined by other standards. 409 In this document we define one new Error Code. The Error Code uses 410 the value TBA (by IANA) and is referred to as "Alarms". The values 411 used in the Error Values field are the same as the values used for 412 IANAItuProbableCause in the Alarm MIB [RFC3877]. Note these values 413 are managed by IANA, see http://www.iana.org. 415 3.1.4. Backwards Compatibility 417 The support of ALARM_SPEC objects is optional. Non-supporting nodes 418 will pass the objects through the node unmodified, because the 419 ALARM_SPEC object has a C-Num of the form 11bbbbbb. 421 This allows alarm information to be collected and examined in a 422 network built from a collection of nodes some of which support the 423 communication of alarm information, and some of which do not. 425 3.2. Controlling Alarm Communication 427 Alarm information communication is controlled via Administrative 428 Status Information as carried in the Admin_Status object. A new bit 429 is defined, called the I bit, that indicates when alarm communication 430 is to be inhibited. The definition of this bit does not modify the 431 procedures defined in Section 7 of [RFC3473]. 433 3.2.1. Updated Admin Status Object 435 The format of the Admin_Status object is updated to include the I 436 bit: 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Length | Class-Num(196)| C-Type (1) | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 |R| Reserved |I| |T|A|D| 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Inhibit Alarm Communication (I): 1 bit 447 When set, indicates that alarm communication is disabled for 448 the LSP and that nodes SHOULD NOT add local alarm information. 450 See [RFC3471] for the definition of the remaining bits. 452 3.2.2. Procedures 454 The I bit may be set and cleared using the procedures defined in 455 Sections 7.2 and 7.3 of [RFC3473]. A node that receives (or 456 generates) an Admin_Status object with the A or I bits set (1), 457 SHOULD remove all locally generated alarm information from the 458 matching LSP's outgoing Path and Resv messages. When a node receives 459 (or generates) an Admin_Status object with the A and I bits clear 460 (0), it SHOULD add any local alarm information to the matching LSP's 461 outgoing Path and Resv messages. 463 The processing of non-locally generated ALARM_SPEC objects MUST NOT 464 be impacted by the contents of the Admin_Status object, that is, 465 received ALARM_SPEC objects MUST be forwarded unchanged regardless of 466 the received or transmitted settings of the I and A-bits. Note, per 467 [RFC3473], the absence of the Admin_Status object is equivalent to 468 receiving an object containing values all set to zero (0). 470 I bit related processing behavior MAY be overridden locally based on 471 configuration. 473 When generating Notify messages for LSPs with the I bit set, the TLVs 474 described in this document MAY be added to the ERROR_SPEC object sent 475 in the the Notify message. 477 3.3. Message Formats 479 This section presents the RSVP message related formats as modified by 480 this document. The formats specified in [RFC3473] served as the 481 basis of these formats. The objects are listed in suggested 482 ordering. 484 The format of a Path message is as follows: 486 ::= [ ] 487 [ [ | ] ... ] 488 [ ] 489 490 491 [ ] 492 493 [ ] 494 [ ... ] 495 [ ] 496 [ ] 497 [ ] 498 [ ... ] 499 [ ... ] 500 502 is not modified by this document. 504 The format of a Resv message is as follows: 506 ::= [ ] 507 [ [ | ] ... ] 508 [ ] 509 510 511 [ ] [ ] 512 [ ] 513 [ ] 514 [ ... ] 515 [ ... ] 516