idnits 2.17.1 draft-shyam-vlsmtrp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 26, 2020) is 1550 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Bandyopadhyay 3 draft-shyam-vlsmtrp-00.txt January 26, 2020 4 Intended status: Experimental 5 Expires: July 26, 2020 7 VLSM Tree Routing Protocol 8 draft-shyam-vlsmtrp-00.txt 10 Abstract 12 This is a light weight routing protocol applicable inside a network 13 that appears in the form of a tree and distribution of address space 14 takes place with the approach of VLSM. It is based on setting default 15 route inside VLSM tree. With this approach, routing information of 16 the external world need not be passed down to the VLSM tree. Thus, 17 load inside a router gets reduced substantially. This document 18 includes IP-VPN with MPLS inside VLSM tree by extending RSVP-TE. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 26, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 1. Introduction 51 This is a light weight routing protocol of provider network that 52 appears in the form of a tree and distribution of address space takes 53 place with the approach of VLSM. It is based on setting default route 54 inside VLSM tree. Inside a VLSM tree, all the physical ports of a 55 switch are configured with their associated domain (i.e. 56 NetAddress/NetMask). Routing table will contain static routes based 57 on the entries configured on these ports. With this approach, routing 58 information of the external world need not be passed down to the VLSM 59 tree. Thus, load inside a router gets reduced substantially. In 60 order to support network management and explicit route option, root 61 of the tree maintains an image of the entire tree. A section of the 62 OSPF protocol without the SPF part is extended to get the image of 63 the tree at the root. This protocol is intended to be used in a real 64 IP environment (e.g. NAT free environment with IPv6 or any new 65 generation IP that may be emerged), but, it makes use of existing 32 66 bits address space for illustration. It expects addressing 67 architecture of real IP space to have separate address space assigned 68 for the routers; e.g. section 3.2.1 of architectural specification[1] 69 states that address space with prefix "111" will be assigned for the 70 routers. This document includes IP-VPN with MPLS inside VLSM tree by 71 extending RSVP-TE. 73 2. Setting default route inside VLSM tree 75 As it has been stated earlier, there is no need to pass down the 76 routing information of the external world inside a VLSM tree that 77 acts as a stub. Inside a VLSM tree, a node of higher prefix can be 78 divided into number of nodes with lower prefixes. Each divided node 79 can further be subdivided with nodes of further lower prefixes. This 80 process can be continued as long as it is desired or no more division 81 is further possible. 83 Following figure shows a typical arrangement of VLSM tree of a 84 service provider's network with IPv4 address space. Switch SW-A is 85 connected to the outside world and maintains global routing table. It 86 acts as the root of a VLSM tree that acts as a stub. It has been 87 assigned an address block 11.1.16.0/20 which is distributed among its 88 four children SW-B, SW-C, SW-D and SW-E with the approach of VLSM. 89 Switch SW-B further divides its address space between switches SW-F 90 and SW-G. Switch SW-F assigns an address block 11.1.16.0/24 to 91 customer network CN-A. Switch SW-G assigns address block 11.1.20.0/24 92 and 11.1.21.0/24 to two customers CN-B and CN-C; where as switch SW-E 93 assigns address block 11.1.30.0/24 to customer network CN-D. 95 Routing inside the tree takes place with the following principle. 97 Inside the tree, if a node (switch/router) that is assigned a domain 98 (NetAddr/NetMask) receives a packet which is destined to somewhere 99 outside of its domain, needs to forward the packet to its parent in 100 the hierarchy. 102 +--------------+ 103 | SW-A | 104 | 11.1.16.0/20 | 105 +-+-+------+-+-+ 106 | | | | 107 +---------------+ | | +----------------+ 108 | | | | 109 +------+-----+ +---------+--+ +-+----------+ +-----+------+ 110 | SW-B | | SW-C | | SW-D | | SW-E | 111 |11.1.16.0/21| |11.1.24.0/22| |11.1.28.0/23| |11.1.30.0/23| 112 +---+----+---+ +------------+ +------------+ +--+---------+ 113 | | | 114 | +-------+ | 115 | | +--+--+ 116 +-------+----+ +----+-------+ |CN-D | 117 | SW-F | | SW-G | +-----+ 118 |11.1.16.0/22| |11.1.20.0/22| 11.1.30.0/24 119 +--+---------+ +--+------+--+ 120 | | | 121 | | | 122 +--+--+ +--+--+ +-+---+ 123 |CN-A | |CN-B | |CN-C | 124 +-----+ +-----+ +-----+ 125 11.1.16.0/24 11.1.20.0/24 11.1.21.0/24 127 If a host in CN-A wants to send a packet to an address 11.1.21.116, 128 CE router of CN-A forwards it to SW-F. SW-F finds the destination 129 address of the packet to be outside of its domain and forwards the 130 packet to its parent SW-B. SW-B finds that a port that has been 131 configured with the matching destination address and forwards it to 132 its child SW-G. Switch SW-G sends the packet to customer network CN- 133 B. 135 If a host in CN-B wants to send a packet to 11.1.17.120, CE router of 136 CN-B forwards the packet to SW-G. SW-G finds the destination address 137 of the packet to be outside of its domain and forwards the packet to 138 its parent SW-B. SW-B finds that a port that has been configured with 139 the matching destination address and forwards the packet to its child 140 SW-F. SW-F finds the destination address to be within its domain, but 141 no port has been configured with the matching destination address and 142 generates ICMP UNREACHABLE. 144 If a host in CN-C wants to send a packet to 16.2.22.116, CE router of 145 CN-C forwards the packet to SW-G. SW-G finds the destination address 146 of the packet to be outside its domain and forwards the packet to SW- 147 B. SW-B forwards the packet to its parent SW-A. SW-A find the 148 destination address of the packet to be outside its domain and 149 consults with the global forwarding table and forwards the packet 150 through the right port. 152 3. Router address space 154 Section 2.2.7 of RFC 1812 [2] states, "a router that 155 has unnumbered point to point lines also has a special IP address, 156 called a router-id in this memo. The router-id is one of the 157 router's IP addresses (a router is required to have at least one IP 158 address). This router-id is used as if it is the IP address of all 159 unnumbered interfaces." 161 A router-id is selected based on the domain (NetAddress/NetMask) that 162 it is associated with. The prefix of the domain gets embedded with in 163 the router-id. The least significant bits of the router-id will 164 contain the prefix. For a prefix of 'n' bits in a 32 bits address 165 space there will be 32-'n' bits at the beginning of the address. 166 Based on section 3.2.1 of the architectural specification[1], it 167 starts with the prefix "1111", followed by set of '1' bits and ends 168 with a '0' bit. Therefore, to get the prefix of the domain, router-id 169 needs to be traced from the MSB towards LSB till it encounters a '0' 170 bit. The rest of the bits till the end is the prefix. So, it expects 171 prefix to be at most (32-5) i.e. 27 bits (5=first four bits as "1111" 172 followed by '0'). So, minimum length of a domain that a router can be 173 assigned is 32. With this approach, locators (i.e routers) and 174 identifiers can be routed based on the same routing table. This can 175 be defined as association between locators and identifiers. 177 4. Network management and support of explicit route option 179 Section 2 has shown how routing is achieved using static route table 180 based on the ports configured with their associated domain. Standard 181 routing protocols usually advertise networks based on which routing 182 table is constructed. There is no such need here. When a router 183 tries to establish a circuit with another, it may contact a PCE to 184 get the best possible route within a set of routes. On getting the 185 best possible path, it sets the circuit using explicit route option. 186 As there is only one path between any two nodes inside a tree, 187 setting explicit route option does not make any sense to communicate 188 between any two nodes within the same tree. It may be required to 189 communicate a node in one VLSM tree to a node in another VLSM tree. 190 To support this feature, root of a VLSM tree needs to maintain an 191 image of the entire tree. A PCE can get this image by contacting the 192 root of the tree. A network management system software also can get 193 the status of the entire tree by communicating with the root of the 194 tree. 196 This section shows how to construct the tree with the approach of 197 routing protocol. It adopts "Hello protocol" and authentication 198 mechanism of OSPF protocol leaving behind the SPF part and 199 introducing new message types relevant to VLSM tree. 201 The router at the root constructs the tree the way it appears in the 202 figure above. Every router in the tree is configured with the router- 203 id of the root i.e. the domain of the tree it belongs to. Whenever a 204 router adds a node (it may be a customer network or another router) 205 as a child, it sends an "Add Node" message. The message is sent to 206 the root. On getting an "Add Node" message, root traces the tree and 207 identifies the node with "Router ID" as specified in the message and 208 adds a node underneath. Similarly, whenever a node gets deleted, a 209 "Delete Node" message is sent to the root. On getting "Delete Node" 210 message, root deletes the entire sub-tree under that node in the 211 tree. Whenever a link goes down, a "Link Down" message is sent to the 212 root. On receiving "Link Down" message, root marks the link status as 213 not active. Whenever a link comes up, on receiving "Link Up" message, 214 root builds the subtree under the node whose link was down (if it 215 happens to be a router) and sets the status of the link as active. 216 This is to get the up-to-date status of the subtree whose link went 217 down. Root calls "GetSubtree" routine recursively to build the 218 subtree as follows: 220 void GetSubtree(struct TreeNode *node) 221 { 222 send "Get Child Nodes" message to the router designated by node. 223 for all the children under node, construct a TreeNode underneath. 224 for all the children as a router call GetSubtree(&childNode). 225 } 227 Where TreeNode may be defined as: 229 struct TreeNode{ 230 uint32 nodeId; /* RouterId, 32 bits in IPv4 */ 231 uint16 nodeType /* Customer Network (1)/Router(2) */ 232 uint16 noOfChildren; /* Number of children */ 233 struct TreeNode *parent; /* pointer to the parent */ 234 struct TreeNode *childList; /* List of child nodes */ 235 struct TreeNode *nextSibling; /* Next sibling in childList */ 236 uint16 linkStatus; /* Link status with parent UP(1)/Down(2) */ 237 } 239 Root can also call "GetSubtree" routine for all of its child to build 240 the entire tree at the time of transition from old protocol to new or 241 whenever required. 243 4.1. VLSM tree routing protocol messages 245 It maintains same message format of OSPF protocol such that existing 246 source code can be directly ported. This section describes new 247 message types along with Hello message of OSPF. Please follow section 248 A.3.1 of OSPF specification [3] for OSPF message format. 250 Every message starts with a standard 24 byte header. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Version # | Type | Packet length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Router ID | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Area ID | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Checksum | AuType | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Authentication | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Authentication | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Version # 269 The version number. This specification documents version 1 270 of the protocol. 272 Type 273 The message types are as follows. 275 Type Description 276 ________________________________ 277 1 Hello 278 2 Add Node 279 3 Delete Node 280 4 Link Down 281 5 Link Up 282 6 Get Child Nodes 283 7 Acknowledgment 285 Packet length 286 The length of the protocol packet in bytes. This length 287 includes the standard header. 289 Router ID 290 The Router ID of the packet's source. 292 Area ID 293 This is not relevant here but has been retained to make use of 294 existing OSPF source code with least modification. 296 Checksum 297 The standard IP checksum of the entire contents of the packet, 298 starting with the packet header but excluding the 64-bit 299 authentication field. This checksum is calculated as the 16-bit 300 one's complement of the one's complement sum of all the 16-bit 301 words in the packet, excepting the authentication field. If the 302 packet's length is not an integral number of 16-bit words, the 303 packet is padded with a byte of zero before checksumming. The 304 checksum is considered to be part of the packet authentication 305 procedure; for some authentication types the checksum 306 calculation is omitted. 308 AuType 309 Identifies the authentication procedure to be used for the 310 packet. Authentication is discussed in Appendix D of OSPF 311 specification [3]. 313 Authentication 314 A 64-bit field for use by the authentication scheme. See 315 Appendix D of OSPF specification for details. 317 4.1.1. The Hello packet 319 Hello packet is just same as defined in OSPF protocol. Please follow 320 Section A.3.2 of OSPF specification [3] for detail. 322 4.1.2. The Add Node packet 324 An "Add Node" packet is generated when a router adds a node as its 325 child. A node can be a customer network or a router. The message 326 gets transported to the root. The receiving router sends back an 327 "Acknowledgment" message by changing the "Type" field as 328 Acknowledgment. The "Sequence Number" and "Router ID" field gets 329 verified on receiving the acknowledgment back. On receiving an "Add 330 Node" message, root adds a new node to the tree under the node 331 designated by "Router ID". 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Version # | 2 | Packet length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Router ID | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Area ID | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Checksum | AuType | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Authentication | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Authentication | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Node Type | Sequence Number | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Node ID | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Node Type 354 Node type is Customer Network (1)/Router (2) 356 Sequence Number 357 Whenever a router generates an Add Node message it uses a Sequence 358 Number. Usually it increments the Sequence Number on completion of 359 the transaction. 361 Node ID 362 Node ID is the router ID of the domain associated with the 363 router/customer network. 365 4.1.3. The Delete Node packet 367 "Delete Node" message gets generated by a router when a child node 368 gets deleted. The message is sent to the root. On receiving "Delete 369 Node" message, root deletes the node (i.e. the entire subtree) under 370 the node designated as "Node ID". All the fields of a "Delete Node" 371 packet are same as an "Add Node" packet apart from the Type(3) field. 373 4.1.4. The Link Down packet 375 "Link Down" message gets generated once a router fails to get "Hello" 376 from any of its child and declares the link to be as inactive. The 377 message is sent to the root. On receiving "Link Down" message root 378 marks the link in the tree to be inactive. All the fields of a "Link 379 Down" packet are same as an "Add Node" packet apart from the Type(4) 380 field. 382 4.1.5. The Link Up packet 384 "Link Up" message gets generated once a router starts getting "Hello" 385 messages from a child which was marked as inactive. The message is 386 sent to the root. On receiving "Link Up" message, root calls 387 "GetSubtree" routine for the node as designated by "Node ID" (if it 388 happens to be a router). It updates changes in the subtree and marks 389 the link as active. All the fields of a "Link Up" packet are same as 390 an "Add Node" packet apart from the Type(5) field. 392 4.1.6. The Get Child Nodes packet 394 "Get Child Nodes" packet gets generated by root to get all the 395 children under a router. Contents of the router is expressed as 396 follows: 398 Router ID of the router (32 bits in IPv4) + 399 Number of children of the router (16 bits) + 400 for each child of the router { 401 Type of the child (Customer Network/Router) (16 bits) + 402 Router ID of the child (32 bits in IPv4) 403 } 405 Exchange of router information is just same as the operation of 406 "Database Description" packet of OSPF (See section A.3.3 of [3]). 407 Format of "Get Child Nodes" packet is same as "Database Description" 408 packet of OSPF with the "Type" field set as 6. 410 4.1.7. The Acknowledgment packet 412 An "Acknowledgment" packet is sent to acknowledge that an "Add 413 Node"/"Delete Node"/"Link Up"/"Link Down" message has been received 414 to the sender. All the fields of an "Acknowledgment" packet are same 415 as an "Add Node" packet apart from the Type(7) field. 417 5. IP VPN with MPLS inside VLSM tree 419 This section describes how to make IP VPN work inside VLSM tree 420 without using BGP. 422 RFC4364 [4] describes "IP VPN" with BGP/MPLS. To support VPN, PE 423 routers maintain per-site forwarding table. When a packet arrives 424 from an associated CE router, PE router consults with this forwarding 425 table to forward the packet. If the packet is supposed to be 426 forwarded to another site of VPN through the backbone, it uses two- 427 level label stack. The upper label is used to forward the packet from 428 ingress PE router to the egress PE router; where as, the inner label 429 is used for the egress PE router to identify the associated CE router 430 where the packet is supposed to be forwarded. BGP is used by the 431 Service Provider to exchange the routes of a particular VPN among the 432 PE routers that are attached to that VPN. Configuration takes place 433 on PE routers of both the sides of LSP. The simplest way to achieve 434 this is to configure these attributes manually on PE routers. In 435 order to have dynamic allocation of inner label, MPLS signaling 436 protocols (in place of BGP) need to be extended. Allocation of inner 437 label has to be done by the egress PE router. Same message that is 438 used for the assignment of upper label may be used for the assignment 439 of inner label. Inside the forwarding table, each entry contains the 440 forwarding destination address based on a set of destination 441 addresses (NetAddress/NetMask) of the IP packets received from 442 ingress CE router. While establishing inner label, ingress PE router 443 needs to send these attributes with the signaling message and the 444 egress PE router needs to validate those before assigning label. 446 5.1. Extension to RSVP-TE to support IP VPN inside VLSM tree 448 This section describes extension to RSVP-TE[5] to support dynamic 449 allocation of inner label of two-level label stack used to support 450 VPN services. 452 In order to establish LSP using RSVP-TE, ingress PE router sends Path 453 message to the egress PE router. Path message is augmented with a 454 LABEL_REQUEST object. Labels are allocated downstream and 455 distributed (propagated upstream) by means of RSVP Resv message. For 456 this purpose, the RSVP Resv message is extended with a special LABEL 457 object. In order to support VPN to establish the inner label, Path 458 message is augmented with a VPN_ATTRIBUTE label. Similarly, RSVP Resv 459 message is extended with a VPN_LABEL object. When an egress PE router 460 receives a Path message, it checks the presence of VPN_ATTRIBUTE 461 object. On finding this object, egress PE router checks the viability 462 of assignment of VPN label with the parameters from the VPN_ATTRIBUTE 463 object and the attributes that are already configured with the egress 464 PE router. If the test is positive, it assigns a VPN label and does 465 the rest of the processing of LSP label assignment and sends the RSVP 466 Resv message with the extension of VPN_LABEL object towards the 467 ingress PE router. On receiving Resv message with VPN_LABEL object, 468 ingress PE router assigns VPN label along with the rest of the 469 processing of Resv message and completes the operation. VPN_ATTRIBUTE 470 and VPN_LABEL objects are described below. 472 VPN_LABEL class=, C-Type=1 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | (inner label) | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 VPN_ATTRIBUTE class=, C-Type=1 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Global Unicast Address of Ingress CE Router | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Global Unicast Address of Egress CE Router | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Net Address of Destination IP Packet | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Net Mask of Destination IP Packet | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 The format of the Path message is as follows: 493 ::= [ ] 494 495 496 [ ] 497 498 [ ] 499 [ ] 500 [ ... ] 501 503 ::= 504 [ ] 505 [ ] 507 The format of the Resv message is as follows: 509 ::= [ ] 510 511 512 [ ] [ ] 513 [ ... ] 514 [ ] 515