idnits 2.17.1 draft-shyam-real-ip-framework-60.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 == Line 1147 has weird spacing: '...lent to the a...' -- The document date (July 03, 2019) is 1752 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 ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC6177' on line 1794 -- Looks like a reference, but probably isn't: 'RFC4692' on line 1799 == Unused Reference: '20' is defined on line 1988, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1993, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1996, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1999, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 2002, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 2005, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4893 (ref. '4') (Obsoleted by RFC 6793) ** Obsolete normative reference: RFC 5395 (ref. '12') (Obsoleted by RFC 6195) -- Obsolete informational reference (is this intentional?): RFC 1771 (ref. '22') (Obsoleted by RFC 4271) -- Obsolete informational reference (is this intentional?): RFC 1883 (ref. '23') (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '24') (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT S. Bandyopadhyay 3 draft-shyam-real-ip-framework-60.txt July 03, 2019 4 Intended status: Experimental 5 Expires: January 03, 2019 7 An Architectural Framework of the Internet for the Real IP World 8 draft-shyam-real-ip-framework-60.txt 10 Abstract 12 This document tries to propose an architectural framework of the 13 internet in the real IP world. It describes how a three-tier mesh 14 structured hierarchy can be established in a large address space 15 based on fragmenting it into some regions and some sub regions inside 16 each of them. It shows how to make a transition from private IP to 17 real IP without making significant changes with the existing network. 18 It introduces VLSM tree routing protocol. It introduces another 19 protocol for host identification with provider independent address. 20 With the useful works done through IPv6, it provides all necessary 21 inputs based on which a specification of IP with 64 bit address space 22 may be emerged. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 03, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. 53 Table of Contents 54 1. Introduction.....................................................3 55 2. Background.......................................................3 56 3. A Three tier mesh structured hierarchical network................5 57 3.1. Route propagation...........................................6 58 3.2. Determination of prefix lengths.............................8 59 3.2.1. A pseudo optimal distribution of prefixes in 60 a 64 bit architecture................................9 61 3.2.2. Whether to go for a two tier or three tier hierarchy 62 ....................................................11 63 3.3. Issues related to Satellite communications.................12 64 4. VLSM tree routing protocol......................................12 65 4.1. Setting default route inside VLSM tree.....................12 66 4.2. Router address space.......................................14 67 4.3. Network management and support of explicit route option....15 68 4.3.1. VLSM tree routing protocol messages.................16 69 4.3.1.1. The Hello packet...........................18 70 4.3.1.2. The Add Node packet........................18 71 4.3.1.3. The Delete Node packet.....................19 72 4.3.1.4. The Link Down packet.......................19 73 4.3.1.5. The Link Up packet.........................19 74 4.3.1.6. The Get Child Nodes packet.................19 75 4.3.1.7. The Acknowledgment packet..................19 76 4.4. IP VPN with MPLS inside VLSM tree..........................20 77 4.4.1. Extension to RSVP-TE to support IP VPN inside VLSM 78 tree................................................20 79 5. Provider Independent addressing, name services and multihoming..22 80 5.1. PI address Resolution......................................24 81 5.1.1. Record Format.......................................27 82 5.1.2. Messages............................................29 83 5.1.3. Master file and data file...........................31 84 5.1.4. Zone maintenance and transfers......................32 85 6. Issues related to IP mobility...................................33 86 6.1. Changes expected with the specifications related 87 to IP mobility.............................................35 88 7. Refinements over existing IPv6 specification....................36 89 8. Distributed processing and Multicasting.........................39 90 9. Transition to real IP from private IP...........................39 91 10. IANA Consideration.............................................40 92 11. Security Consideration.........................................40 93 12. Acknowledgments................................................40 94 13. Normative References...........................................41 95 14. Informative References.........................................42 96 15. Author's Address...............................................42 98 1. Introduction 100 Transition from IPv4 to IPv6 is in the process. Work has been done to 101 upgrade individual nodes (workstations) from IPv4 to IPv6. Also, 102 there are established documents to make routers/switches to work to 103 support IPv4 as well as IPv6 packets simultaneously in order to make 104 the transition possible [1]. CIDR[2] based hierarchical architecture 105 in the existing 32-bit system is supposed to be continued in IPv6 too 106 with a large address space. There are documents/concerns over BGP 107 table entries to become too large in the existing system [3]. There 108 are proposals to upgrade Autonomous System number to 32-bit from 109 16-bit to support the demand at the same time [4]. The challenge 110 relies on how to make the transition smooth from IPv4 to a real IP 111 world with least changes possible. 113 The term "real IP environment" is referred to an environment where 114 hosts in a customer network will possess globally unique IP addresses 115 and communicate with the rest of the world without the help of 116 NAT[5]. This document reflects changes required with the BSD 4.4 117 source code where ever applicable. 119 2. Background 121 Existing system is in work with Autonomous System (AS) and inter-AS 122 layer with the approach of CIDR. In order to meet the need within the 123 32-bit address space, Autonomous Systems of various sizes maintain 124 CIDR based hierarchical architecture. With the help of NAT [5], a 125 stub network can maintain an user ID space as large as a class A 126 network and can meet its useful need to communicate with the rest of 127 the world with very few real IP addresses. With the combination of 128 CIDR and NAT applied in the entire space, most of the part of 32-bit 129 address space gets effectively used as network ID. 131 With traditional CIDR based hierarchy, a node of higher prefix can be 132 divided into number of nodes with lower prefixes. Each divided node 133 can further be subdivided with nodes of further lower prefixes. This 134 process can be continued till no further division is possible. The 135 point worth noting is at each point the designer of the network has 136 to preconceive the future expansion of the network with the concept 137 in the mind that the resource can not be exhausted at any point of 138 time. This phenomenon leads the designer to allocate resources much 139 higher than whatever is needed which leads to a space of unused 140 address space. The problem gets aggravated once resource gets 141 exhausted by any chance. e.g. a node of prefix /16 can be divided 142 with a number of nodes of prefixes /24. If any one of the nodes /24 143 gets exhausted, resources of other nodes of prefixes /24 can not be 144 used even if they are available. 146 In IPv4 environment, there is a desperate attempt of the service 147 providers to provide internet services with the help of NAT. e.g. a 148 large educational institute meets its current requirement with 4 real 149 IP addresses; one for its mail server, one for its web server, one 150 for its ftp server and another one for its proxy server to provide 151 web based services to all of its users. In general, these services 152 are used by an organization of any size(it may be 400 or even 40000). 153 In the current scenario, the CIDR based tree has been built using 154 these components together. When private IP will be replaced with real 155 IP, each customer network will require IP addresses based on its size 156 and requirement. 158 Transitioning from private IP to real IP basically requires the 159 following components: 161 o A solution for site multihoming with provider assigned 162 address space 163 o A strategy to replace private IP to real IP 164 o A solution to uniquely identify a host in a real IP environment 165 o A solution to make individual nodes and routers/switches to work 166 with IPv4 and next generation IP simultaneously. 168 Solution for site multihoming has been provided in a separate 169 document [8]. Section 9 shows how to make a transition from private 170 IP space to real IP space with provider assigned addresses with CIDR 171 based approach itself without reorganization of the existing provider 172 network. Section 5 provides a solution for identifying a host 173 uniquely with a number in a real IP environment. RFC 4213 [1] has 174 already described the transition mechanism from IPv4 to IPv6 for 175 individual nodes and routers. 177 Transitioning to real IP will eliminate the extra routing entries 178 associated with multihomed sites and thus will reduce the size of the 179 BGP table substantially. Assignment of addresses requires an 180 architectural framework. It may continue with the existing CIDR based 181 architecture (provided transitioning to real IP will be good enough 182 to handle all routing related issues for ever) or may come out with a 183 different approach. Mesh structured hierarchy will reduce the growth 184 of routing entries in a CIDR based environment as well as convenient 185 for distribution of network resources in a suitable manner in the 186 long run. 188 This document also tries to resolve and enhance several issues that 189 were carried on as part of deployment of IPv6. It shows that a 64 bit 190 address space is good enough for all practical purposes. With the 191 useful works done through IPv6, it provides all necessary inputs 192 based on which a specification of IP with 64 bit address space may be 193 emerged. 195 3. A Three-tier mesh structured hierarchical network 197 As Autonomous Systems of various sizes are supported, Autonomous 198 Systems and the nodes inside the Autonomous Systems can be viewed as 199 graphically lying on the same plane within the address apace. If 200 network can be viewed as lying on different planes, routing issues 201 can be made simpler. If network is designed with a fixed length of 202 prefix for the Autonomous System everywhere, routing information for 203 the rest will get confined with the other part of the network prefix. 204 Which means the maximum size of AS gets assigned to all irrespective 205 of their actual sizes. This can be made possible with the advantage 206 of using a large address space and dividing it into number of regions 207 of fixed sizes inside it. Thus entire network can be viewed as a 208 network of inter-AS layer nodes. Each node in the inter-AS layer can 209 act either only as a router in the inter-AS layer or as a router in 210 the inter-AS layer with an Autonomous System attached to it with a 211 single point of attachment or as an Autonomous System with multiple 212 Autonomous System border routers (ASBR) appearing like a mesh. Thus 213 two tier mesh structured hierarchy gets established between AS layer 214 and inter-AS layer with each AS having a fixed length of prefix. 216 Based on the definition of Autonomous System, it is a small area 217 within the entire network that maintains its own independent identity 218 that communicates with the rest of the world through some specific 219 border routers. In the similar manner, if a larger area (say region 220 or state) can be considered as network of Autonomous Systems, that 221 can maintain its own identity by communicating with the rest of the 222 world through some border routers (say, state border router), mesh 223 structured hierarchy can be established within the inter-AS layer. 224 The inter-AS layer will be split into inter-AS-top and inter-AS- 225 bottom. To maintain this hierarchy, each node of inter-AS-top needs 226 to have multiple regional or state border routers (say, SBR) through 227 which each one will communicate with the rest of the world in the 228 similar manner an Autonomous System maintains ASBR. Thus, entire 229 network will appear as a network of nodes of inter-AS-top layer. To 230 maintain hierarchy, each node of the inter-AS-top needs to have a 231 fixed length of prefix. i.e. each node of the inter-AS top will be 232 assigned a maximum (fixed) number of nodes of Autonomous Systems. 234 Thus, with three-tier mesh structured hierarchy in the network layer, 235 network ID can be viewed as A.B.C. If pA, pB and pC be the prefix 236 lengths of inter-AS-top, inter-AS-bottom and AS layers respectively, 237 there will be 2^pA nodes at the topmost layer, 2^pB at the inter-AS- 238 bottom layer and 2^pC nodes at the AS layer. Thus the entire space 239 gets divided into a fixed number of regions and each region gets 240 divided into fixed number of sub regions. This division is supposed 241 to be made based on geography, population density and their demands 242 and related factors. 244 Let nMaxInterASTopNodes be the possible maximum number of nodes 245 assigned at the top most layer and nMaxInterASBottomNodes be that at 246 the inter-AS-bottom layer and nMaxASNodes at the AS layer. Where 247 nMaxInterASTopNodes <= 2^pA and nMaxInterASBottomNodes <= 2^pB and 248 nMaxASNodes <= 2^pC. 250 3.1. Route propagation 252 With hierarchy established, routing information that gets established 253 inside a node of inter-AS-top, does not need to be propagated to 254 another node of inter-AS-top. Entire routing information of inter-AS- 255 top layer needs to be propagated to inter-AS-bottom layer. So, each 256 router of inter-AS layer will have two tables of information, one for 257 the inter-AS-top and another for the inter-AS-bottom of the inter-AS- 258 top node that it belongs to. BGP (with little modification) will work 259 very well with a trick applied at the SBRs. Each SBR will not 260 propagate the routing information of inter-AS-bottom layer of its 261 domain to another SBR of neighboring domain. i.e. SBR of one top 262 layer node will propagate routing information only of inter-AS-top 263 layer to SBR of another top layer node. Inside a node of inter-AS- 264 top, routing information of inter-AS-top and inter-AS-bottom need to 265 be propagated from one ASBR to another neighboring ASBR. Inside a top 266 layer node A, routing information of another top layer node B will 267 have two parts; one for the list of SBRs through which a packet will 268 traverse from top layer node A to B and another for the list of ASBRs 269 through which the packet will traverse from one AS to another inside 270 A. In terms of BGP, AS_PATH attribute will be split into two parts; 271 one for the information of the top layer and another for the bottom 272 layer. Within the same node A routing information of one AS to 273 another AS will not have any top layer information. i.e. the top 274 layer information will be set to as NULL. 276 Similarly, each node of the AS layer will have three tables of 277 routing entries. One for the inter-AS-top, one for the inter-AS- 278 bottom and another for the routing information inside the Autonomous 279 System itself. 281 Introduction of hierarchy at the inter-AS layer reduces the size of 282 the routing table substantially. With the availability of hardware 283 resources if flat address space is maintained at each layer, problems 284 related to CIDR can be avoided. With flat address space, no 285 hierarchical relationship needs to be established between any two 286 nodes in the same layer. So, all the nodes inside each layer can be 287 used till they get exhausted. With flat address space (i.e. without 288 prefix reduction), BGP tables will have maximum nMaxInterASTopNodes + 289 nMaxInterASBottomNodes entries. 291 IGP like OSPF has got provision to divide AS into smaller areas. OSPF 292 hides the topology of an area from the rest of the Autonomous System. 293 This information hiding enables a significant reduction in routing 294 traffic. With the support of subnetting, OSPF attaches an IP address 295 mask to indicate a range of IP addresses being described by that 296 particular route. With this approach it reduces the size of the 297 routing traffic instead of describing all the nodes inside it, but 298 introduces another level of hierarchy. If subnetting concept can be 299 avoided from the AS layer(with the additional overhead of computation 300 inside the SPF tree), each area can be configured from a free pool of 301 addresses based on its requirement dynamically. So, an AS can be 302 divided into number of areas of heterogeneous sizes with the nodes 303 from a free pool of address space. 305 Similarly, the concept of area can be introduced in the inter-AS- 306 bottom layer the way it works in OSPF. The area border routers in the 307 inter-AS-bottom layer have to behave exactly in the similar manner 308 the way an ABR behaves in OSPF. i.e. an area border router will hide 309 the topology inside an area to the rest of the world and will 310 distribute the collected information inside the area to the rest. It 311 will distribute the collected routing information from outside to the 312 nodes inside as well. In order to implement this, protocol running in 313 the inter-AS layer (say BGP) will have to introduce a 'cost' factor. 314 This cost factor can be interpreted as the cost of propagation of a 315 packet from one AS to another. The protocols running inside AS layer 316 (RIP/OSPF, etc) will have to the supply the cost information for a 317 packet to travel from one ASBR to another. All the protocols must 318 behave in unison for supplying this information. The cost factor is 319 needed for a remote node while sending a packet to a node inside an 320 area while more than one area border routers are equidistant from 321 that remote node. Thus inter-AS-bottom layer (i.e. one inter-AS-top 322 level node) can be divided into number of areas of heterogeneous 323 sizes with nodes of AS from a free pool of address space. BGP adopts 324 a technique called route aggregation. Along with route aggregation it 325 reduces routing information within a message. In the similar manner, 326 introduction of area inside inter-AS-bottom layer will not only 327 reduce the complexity of the protocol, but will reduce the size of a 328 BGP packet substantially. 330 With this architecture, each node(router) inside an AS is represented 331 as A.B.C. Each node may or may not be attached with a network which 332 acts as a leaf node (i.e. a network will not act as a transit). In 333 order to make use of user-id space properly and to support customer 334 networks of heterogeneous sizes, the user-ID space needs to be 335 divided as subnet-ID and user-ID. Profoundly, a VLSM (variable length 336 subnet mask) type of approach (in the form of a tree) has to be 337 adopted at each node of an AS. So, each node of the AS layer will act 338 as the root of a tree whose leaves are independent small customer 339 networks which will act as stub. As the routing information of inter- 340 AS layer as well as AS layer need not be passed inside any node of 341 the VLSM tree, each router inside the tree should maintain default 342 route for any address outside of its network/domain. With this 343 approach, load on each router of the service providers will become 344 negligible. Protocols that supports VLSM with MPLS/VPN has to be 345 implemented inside the tree. Inside the VLSM tree, all the physical 346 ports of a switch have to be configured with the subnet mask. A light 347 weight routing protocol can be developed on top of static routing 348 table by setting default route inside VLSM tree. 350 The fundamental assumptions based on which this architecture lies can 351 be summarized as follows: 353 i) Entire network can be viewed as a network of regions or states 354 where each region or state can have its own identity by communicating 355 with the rest of the world through some state border routers. Each 356 region or state is a network of Autonomous Systems. Each region as 357 well as each Autonomous System inside them will have a fixed 358 (maximum) length of prefix. 360 ii) Availability of hardware resources is such that flat address 361 space can be maintained at the inter-AS layer. 363 Introduction of mesh-structured hierarchy will have several 364 advantages: 366 o Load at each router will get reduced substantially. 367 o Concept of CIDR style approach and complexity related to 368 prefix reduction can be easily avoided. 369 o Mesh structured hierarchy will make traffic evenly distributed. 370 o Physical cable connection can be optimized. 371 o Administrative issues will become easier. 373 3.2. Determination of prefix lengths 375 With this architecture, IP address can be described as A.B.C.D where 376 the D part represents the user id. Each router in the inter-AS layer 377 will have two tables of information, one for the inter-AS-top and 378 another for the inter-AS-bottom of the inter-AS-top node that it 379 belongs to. Whereas, each node of the AS layer will have three tables 380 of routing entries; one for the inter-AS-top, one for the inter-AS- 381 bottom and another for the routing information inside the Autonomous 382 System itself. In the worst case. a node inside an AS needs to 383 maintain nMaxInterASTopNodes + nMaxInterASBottomNodes + nMaxASNodes 384 entries in its routing table. 386 The dynamic nature of allocating an area from a free pool of address 387 space is more frequent at the AS layer than at the inter-AS-bottom 388 layer. As OSPF supports all the features needed, it can be considered 389 as default choice in the AS layer. Existing implementation of OSPF 390 (Version 2) supports subnetting, by which an entire area can be 391 represented as a combination of network address and subnet mask. With 392 this approach, entire routing table gets reduced substantially. With 393 the removal of subnetting, all the nodes inside an area will have an 394 entry inside the routing table (OSPF Version 1). So the deterministic 395 factor is what is the maximum number of nodes inside an AS OSPF can 396 support once subnetting support gets removed. So the prefix length of 397 AS layer will be determined by this factor of OSPF. 399 With the introduction of hierarchy in the inter-AS layer, number of 400 entries in the BGP routing table will get reduced substantially. Even 401 if pA and pB both are selected as 16, number of routing entries come 402 within the admissible range of existing BGP protocol. But, it is the 403 responsibility of IANA to come out with a scheme how 404 nMaxInterASTopNodes and nMaxInterASBottomNodes are to be selected. 405 Each top level node will have nMaxInterASBottomNodes nodes. It will 406 be a waste of address space if each country gets assigned a top level 407 nodes (e.g. china has got a population of 1,306,313,800 people where 408 as Vatican City has got only 920 according to a census of 2006). So a 409 moderate value of nMaxInterASBottomNodes is desirable, with which 410 larger countries will have a number of top level nodes. e.g. each 411 state of USA can be assigned a top level node. With the introduction 412 of area in the inter-AS-bottom layer, each top level node can be 413 divided into number of areas of heterogeneous sizes. So, a group of 414 neighboring countries with less population can share the address 415 space of a top level node. Similarly, user-id space has to be decided 416 based on the largest area VLSM tree should be spanned through. All 417 these issues are completely geo political and have to be decided by 418 IANA. 420 3.2.1. A pseudo optimal distribution of prefixes in a 64 bit 421 architecture 423 In order to have optimal use of cable connections, length of the VLSM 424 tree is expected to be as short as possible. Also any single 425 organization may prefer to have its user id space to be under the 426 same network id. So, a 16 bit user-id may become insufficient for 427 places like large university campus, where as 32 bit will become too 428 large. Hence, 24 bit user-id will be a moderate one which is the 429 class A address space in IPv4 (also used as the space for private 430 IP). As published in 1998 [6], OSPF can support an area with 1600 431 routers and 30K external LSAs. So, 11 bits are needed to support this 432 space. With the assumption that OSPF can support much more address 433 space with the advancement of hardware technology as well as to keep 434 the space open for future expansions, 12 bits are assigned for the AS 435 layer. 16 bits are assigned for the inter-AS-bottom layer. So, if on 436 the average, 16 bit equivalent space gets used within the user-id 437 space (i.e. one out of 256) and 8 bit equivalent nodes gets used 438 inside an AS (16% of 1600), for a top level node (with 16 bit 439 equivalent AS nodes), it will generate 2^40 IP addresses, which will 440 give 8629 IP addresses per person in Japan (with a population of 441 127417200; Japan is at the 10th position from the top in the 442 population list of the world). So, even if all the countries with 443 population less than or equal to Japan are assigned a top level node 444 and all the provinces/states of countries with larger population are 445 assigned a top level node each, total number of nodes will come well 446 under 1024. If a number of neighboring countries with lesser 447 population shares a top level node, total number of top level nodes 448 will come down further. This suggests that 62 bit equivalent 449 (10(pA)+16(pB)+12(pC)+24(user-id)) space will be good enough for 450 unicast addresses. This distribution expects OSPF to support 65K 451 (64K+1K) external LSAs. 453 Distribution of address space will be finalized based on the 454 consultation with IANA. Primarily, they may appear to be as follows: 456 64 bit address space may be divided into two 63 bits blocks: 458 i. Global unicast addresses with the most significant bit set to 0. 459 This space is equally divided between provider assigned (PA) address 460 space and provider independent (PI) address space. 462 a) Provider assigned address space with prefix 00. 464 b) Provider independent (PI) address space with prefix 01. Provider 465 independent address space will be used for the customers who would 466 like to retain their number even after changing their providers. As 467 routing will be based on PA addresses, each PI address will be 468 associated to at least one PA address. Most significant part of PI 469 addressing is, it is independent of the architectural framework of 470 the provider network; even if the architectural framework changes, 471 same format of PI addressing can be maintained. Once implemented, PI 472 address of a node will be the number that will be generally used by 473 the common people. Section 5 describes issues related to PI 474 addressing in detail. 476 ii. Address space with the MSB set to 1 will be distributed within 477 the rest. Each of them will have a fixed prefix. This distribution 478 will be based on the requirements and the work that have already been 479 done in connection to IPv6: 481 a) Address space for multicasting with a prefix set to 1001. 483 b) Address space for link-local address: Link local addresses will 484 have a prefix 1010. 486 c) Router address space: Prefix 1111 will be used by routers inside 487 VLSM trees and 1110 will be used by backbone routers connecting them. 489 d) Address space for private IP: Each customer network can maintain 490 private address space to communicate within its users. This space 491 will be distributed within all the customer sites of a corporate that 492 can maintain VPN services. A 32 bit address space should be good 493 enough for private IP. Private address space will have a 32 bit 494 prefix with leading 4 bits are set to 1100 and the rest are set to 1. 496 Rest of the address space has been kept for future use. 498 3.2.2. Whether to go for a two-tier or three-tier hierarchy 500 Establishment of hierarchy in the inter-AS layer reduces the size of 501 BGP entries to a great extent, but leads to an improper use of 502 address space due to geo-political reason. If hierarchy in the inter- 503 AS space gets removed, entire 26 bit (10+16) space will be available 504 for a single layer and use of inter-AS space will be true to its 505 sense, but will increase external LSA (and/or number of entries in 506 the BGP table) dramatically. So, it depends on to what extent OSPF 507 can support external LSAs. BGP expects the packet length to be 508 limited to 4096 bytes. BGP manages to make it work with this 509 limitation with the concept of prefix reduction in the CIDR based 510 environment. As the number of inter-AS nodes increases, BGP has to 511 change this limit in order to make it work in flat address space. The 512 alternate will be to divide the inter-AS space into number of areas 513 as defined in section 2.1. The area border routers will advertise the 514 aggregated information to the rest of the world. BGP may have to 515 incorporate both the options at the same time. As the number of nodes 516 in the inter-AS layer increases, in order to reduce the number of 517 entries in the routing table, inter-AS space has to be split into two 518 separate planes. So, two-tier hierarchy can be considered as an 519 interim state to go for three-tier hierarchy. If it so happen that 520 current available data is good enough to support the present need, it 521 will be worth to look for to what extent it can support in the 522 future. Assignment of inter-AS nodes in two-tier hierarchy should be 523 based on the geographical distribution as if it is part of three-tier 524 hierarchy. Otherwise, introduction of three-tier hierarchy in the 525 future will become another difficult task to go through. Based on the 526 report of year 2011, BGP supports ~400,000 entries in the routing 527 table. With this growing trend, BGP may have to change the limit of 528 packet length even in a CIDR based environment. With the introduction 529 of two-tier hierarchy, number of entries in the routing table will 530 come down drastically and with the three-tier approach, it will come 531 down further. 533 3.3. Issues related to Satellite communications 535 Establishment of hierarchy in the inter-AS layer expects the only way 536 any two autonomous systems in two different top level nodes 537 communicate is through their SBRs. If two autonomous systems inside 538 the same top level node communicate through satellite, it will be 539 considered as a direct link between them. Whenever autonomous system 540 'ASa' of top level node 'A' communicates with autonomous system 'ASb' 541 of top level node 'B' through satellite, they have to go through 542 their state border routers. i.e. satellite port inside 'A' that 543 communicates with a satellite port inside 'B' will be considered as 544 state border router. If multiple such ports exists inside node 'A', 545 all of them will be equidistant from any port inside 'B'. Which 546 expects any satellite port inside 'B' to have prior knowledge of list 547 of autonomous systems that will be under the purview of any port 548 inside 'A'. So, all the satellite ports of 'A' have to exchange such 549 group of information with all the satellite ports of 'B' and vice 550 versa. These group of autonomous systems can be considered as a 551 cluster of autonomous systems inside an area of a top level node. If 552 number of such ports is small, some heuristics can be applied while 553 assigning AS numbers in order to reduce the processing time during 554 the circuit establishment phase. It will become difficult to 555 maintain such heuristics once the number of such ports becomes large. 556 So, in case of satellite communication, the advantage of establishing 557 hierarchy inside inter-AS layer diminishes as the number of satellite 558 ports increases. If any private corporate maintains its own satellite 559 channel to communicate between its offices at distant locations, all 560 of these offices are going to be considered as under the user-id 561 space of its network. Service providers that provide satellite 562 services to the end-site customers, can operate in the usual manner 563 as they will provide connection to customer networks which will act 564 as stub. 566 4. VLSM tree routing protocol 568 This section describes a light weight routing protocol applicable 569 inside VLSM tree. It is based on setting default route inside VLSM 570 tree. Inside a VLSM tree, all the physical ports of a switch have to 571 be configured with their associated domain (i.e. NetAddress/NetMask). 572 Routing table will contain static routes based on the entries 573 configured on these ports. 575 4.1 Setting default route inside VLSM tree 577 Section 3.1 describes that there is no need to pass down the routing 578 information of the external world inside VLSM tree that acts as a 579 stub. Inside a VLSM tree, a node of higher prefix can be divided into 580 number of nodes with lower prefixes. Each divided node can further be 581 subdivided with nodes of further lower prefixes. This process can be 582 continued as long as it is desired or no more division is further 583 possible. 585 Following figure shows a typical arrangement of VLSM tree of a 586 service provider's network with IPv4 address space. Switch SW-A is 587 connected to the outside world and maintains global routing table. It 588 acts as the root of a VLSM tree that acts as a stub. It has been 589 assigned an address block 11.1.16.0/20 which is distributed among its 590 four children SW-B, SW-C, SW-D and SW-E with the approach of VLSM. 591 Switch SW-B further divides its address space between switches SW-F 592 and SW-G. Switch SW-F assigns an address block 11.1.16.0/24 to 593 customer network CN-A. Switch SW-G assigns address block 11.1.20.0/24 594 and 11.1.21.0/24 to two customers CN-B and CN-C; where as switch SW-E 595 assigns address block 11.1.30.0/24 to customer network CN-D. 597 Routing inside the tree takes place with the following principle. 599 Inside the tree, if a node (switch/router) that is assigned a domain 600 (NetAddr/NetMask) receives a packet which is destined to somewhere 601 outside of its domain, needs to forward the packet to its parent in 602 the hierarchy. 604 +--------------+ 605 | SW-A | 606 | 11.1.16.0/20 | 607 +-+-+------+-+-+ 608 | | | | 609 +---------------+ | | +----------------+ 610 | | | | 611 +------+-----+ +---------+--+ +-+----------+ +-----+------+ 612 | SW-B | | SW-C | | SW-D | | SW-E | 613 |11.1.16.0/21| |11.1.24.0/22| |11.1.28.0/23| |11.1.30.0/23| 614 +---+----+---+ +------------+ +------------+ +--+---------+ 615 | | | 616 | +-------+ | 617 | | +--+--+ 618 +-------+----+ +----+-------+ |CN-D | 619 | SW-F | | SW-G | +-----+ 620 |11.1.16.0/22| |11.1.20.0/22| 11.1.30.0/24 621 +--+---------+ +--+------+--+ 622 | | | 623 | | | 624 +--+--+ +--+--+ +-+---+ 625 |CN-A | |CN-B | |CN-C | 626 +-----+ +-----+ +-----+ 627 11.1.16.0/24 11.1.20.0/24 11.1.21.0/24 628 If a host in CN-A wants to send a packet to an address 11.1.21.116, 629 CE router of CN-A forwards it to SW-F. SW-F finds the destination 630 address of the packet to be outside of its domain and forwards the 631 packet to its parent SW-B. SW-B finds that a port that has been 632 configured with the matching destination address and forwards it to 633 its child SW-G. Switch SW-G sends the packet to customer network CN- 634 B. 636 If a host in CN-B wants to send a packet to 11.1.17.120, CE router of 637 CN-B forwards the packet to SW-G. SW-G finds the destination address 638 of the packet to be outside of its domain and forwards the packet to 639 its parent SW-B. SW-B finds that a port that has been configured with 640 the matching destination address and forwards the packet to its child 641 SW-F. SW-F finds the destination address to be within its domain, but 642 no port has been configured with the matching destination address and 643 generates ICMP UNREACHABLE. 645 If a host in CN-C wants to send a packet to 16.2.22.116, CE router of 646 CN-C forwards the packet to SW-G. SW-G finds the destination address 647 of the packet to be outside its domain and forwards the packet to SW- 648 B. SW-B forwards the packet to its parent SW-A. SW-A find the 649 destination address of the packet to be outside its domain and 650 consults with the global forwarding table and forwards the packet 651 through the right port. 653 4.2. Router address space 655 Section 2.2.7 of RFC 1812 states, "a router that 656 has unnumbered point to point lines also has a special IP address, 657 called a router-id in this memo. The router-id is one of the 658 router's IP addresses (a router is required to have at least one IP 659 address). This router-id is used as if it is the IP address of all 660 unnumbered interfaces." 662 A router-id is selected based on the domain (NetAddress/NetMask) that 663 it is associated with. The prefix of the domain gets embedded with in 664 the router-id. The least significant bits of the router-id will 665 contain the prefix. For a prefix of 'n' bits in a 32 bits address 666 space there will be 32-'n' bits at the beginning of the address. It 667 starts with the prefix "1111" (see section 3.2.1), followed by set of 668 '1' bits and ends with a '0' bit. Therefore, to get the prefix of the 669 domain, router-id needs to be traced from the MSB towards LSB till it 670 encounters a '0' bit. The rest of the bits till the end is the 671 prefix. So, it expects prefix to be at most (32-5) i.e. 27 bits 672 (5=first three bits as "1111" followed by '0'). So, minimum length of 673 a domain that a router can be assigned is 32. With this approach, 674 locators (i.e routers) and identifiers can be routed based on the 675 same routing table. This can be defined as association between 676 locators and identifiers. 678 4.3. Network management and support of explicit route option 680 Section 4.1. has shown how routing is achieved using static route 681 table based on the ports configured with their associated domain. 682 Standard routing protocols usually advertise networks based on which 683 routing table is constructed. There is no such need here. When a 684 router tries to establish a circuit with another, it may contact a 685 PCE to get the best possible route within a set of routes. On 686 getting the best possible path, it sets the circuit using explicit 687 route option. As there is only one path between any two nodes inside 688 a tree, setting explicit route option does not make any sense to 689 communicate between any two nodes within the same tree. It may be 690 required to communicate a node in one VLSM tree to a node in another 691 VLSM tree. To support this feature, root of a VLSM tree needs to 692 maintain an image of the entire tree. A PCE can get this image by 693 contacting the root of the tree. A network management system software 694 also can get the status of the entire tree by communicating with the 695 root of the tree. 697 It is possible to construct this tree with the approach of network 698 management by means of pooling and generation of trap on network 699 failure. This section shows how it is done with the approach of 700 routing protocol. It adopts "Hello protocol" and authentication 701 mechanism of OSPF protocol leaving behind the SPF part and 702 introducing new message types relevant to VLSM tree. 704 The router at the root constructs the tree the way it appears in the 705 figure above. Every router in the tree is configured with the router- 706 id of the root i.e. the domain of the tree it belongs to. Whenever a 707 router adds a node (it may be a customer network or another router) 708 as a child, it sends an "Add Node" message. The message is sent to 709 the root. On getting an "Add Node" message, root traces the tree and 710 identifies the node with "Router ID" as specified in the message and 711 adds a node underneath. Similarly, whenever a node gets deleted, a 712 "Delete Node" message is sent to the root. On getting "Delete Node" 713 message, root deletes the entire sub-tree under that node in the 714 tree. Whenever a link goes down, a "Link Down" message is sent to the 715 root. On receiving "Link Down" message, root marks the link status as 716 not active. Whenever a link comes up, on receiving "Link Up" message, 717 root builds the subtree under the node whose link was down (if it 718 happens to be a router) and sets the status of the link as active. 719 This is to get the up-to-date status of the subtree whose link went 720 down. Root calls "GetSubtree" routine recursively to build the 721 subtree as follows: 723 void GetSubtree(struct TreeNode *node) 724 { 725 send "Get Child Nodes" message to the router designated by node. 726 for all the children under node, construct a TreeNode underneath. 727 for all the children as a router call GetSubtree(&childNode). 728 } 730 Where TreeNode may be defined as: 732 struct TreeNode{ 733 uint32 nodeId; /* RouterId, 32 bits in IPv4 */ 734 uint16 nodeType /* Customer Network (1)/Router(2) */ 735 uint16 noOfChildren; /* Number of children */ 736 struct TreeNode *parent; /* pointer to the parent */ 737 struct TreeNode *childList; /* List of child nodes */ 738 struct TreeNode *nextSibling; /* Next sibling in childList */ 739 uint16 linkStatus; /* Link status with parent UP(1)/Down(2) */ 740 } 742 Root can also call "GetSubtree" routine for all of its child to build 743 the entire tree at the time of transition from old protocol to new or 744 whenever required. 746 4.3.1. VLSM tree routing protocol messages 748 It maintains same message format of OSPF protocol such that existing 749 source code can be directly ported. This section describes new 750 message types along with Hello message of OSPF. Please follow section 751 A.3.1 of OSPF specification [19] for OSPF message format. 753 Every message starts with a standard 24 byte header. 755 0 1 2 3 756 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Version # | Type | Packet length | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Router ID | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Area ID | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Checksum | AuType | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Authentication | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Authentication | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 Version # 772 The version number. This specification documents version 1 773 of the protocol. 775 Type 776 The message types are as follows. 778 Type Description 779 ________________________________ 780 1 Hello 781 2 Add Node 782 3 Delete Node 783 4 Link Down 784 5 Link Up 785 6 Get Child Nodes 786 7 Acknowledgment 788 Packet length 789 The length of the protocol packet in bytes. This length 790 includes the standard header. 792 Router ID 793 The Router ID of the packet's source. 795 Area ID 796 This is not relevant here but has been retained to make use of 797 existing OSPF source code with least modification. 799 Checksum 800 The standard IP checksum of the entire contents of the packet, 801 starting with the packet header but excluding the 64-bit 802 authentication field. This checksum is calculated as the 16-bit 803 one's complement of the one's complement sum of all the 16-bit 804 words in the packet, excepting the authentication field. If the 805 packet's length is not an integral number of 16-bit words, the 806 packet is padded with a byte of zero before checksumming. The 807 checksum is considered to be part of the packet authentication 808 procedure; for some authentication types the checksum 809 calculation is omitted. 811 AuType 812 Identifies the authentication procedure to be used for the 813 packet. Authentication is discussed in Appendix D of OSPF 814 specification [19]. 816 Authentication 817 A 64-bit field for use by the authentication scheme. See 818 Appendix D of OSPF specification for details. 820 4.3.1.1. The Hello packet 822 Hello packet is just same as defined in OSPF protocol. Please follow 823 Section A.3.2 of OSPF specification [19] for detail. 825 4.3.1.2. The Add Node packet 827 An "Add Node" packet is generated when a router adds a node as its 828 child. A node can be a customer network or a router. The message 829 gets transported to the root. The receiving router sends back an 830 "Acknowledgment" message by changing the "Type" field as 831 Acknowledgment. The "Sequence Number" and "Router ID" field gets 832 verified on receiving the acknowledgment back. On receiving an "Add 833 Node" message, root adds a new node to the tree under the node 834 designated by "Router ID". 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Version # | 2 | Packet length | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Router ID | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Area ID | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Checksum | AuType | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Authentication | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Authentication | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Node Type | Sequence Number | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Node ID | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 Node Type 857 Node type is Customer Network (1)/Router (2) 859 Sequence Number 860 Whenever a router generates an Add Node message it uses a Sequence 861 Number. Usually it increments the Sequence Number on completion of 862 the transaction. 864 Node ID 865 Node ID is the router ID of the domain associated with the 866 router/customer network. 868 4.3.1.3. The Delete Node packet 870 "Delete Node" message gets generated by a router when a child node 871 gets deleted. The message is sent to the root. On receiving "Delete 872 Node" message, root deletes the node (i.e. the entire subtree) under 873 the node designated as "Node ID". All the fields of a "Delete Node" 874 packet are same as an "Add Node" packet apart from the Type(3) field. 876 4.3.1.4. The Link Down packet 878 "Link Down" message gets generated once a router fails to get "Hello" 879 from any of its child and declares the link to be as inactive. The 880 message is sent to the root. On receiving "Link Down" message root 881 marks the link in the tree to be inactive. All the fields of a "Link 882 Down" packet are same as an "Add Node" packet apart from the Type(4) 883 field. 885 4.3.1.5. The Link Up packet 887 "Link Up" message gets generated once a router starts getting "Hello" 888 messages from a child which was marked as inactive. The message is 889 sent to the root. On receiving "Link Up" message, root calls 890 "GetSubtree" routine for the node as designated by "Node ID" (if it 891 happens to be a router). It updates changes in the subtree and marks 892 the link as active. All the fields of a "Link Up" packet are same as 893 an "Add Node" packet apart from the Type(5) field. 895 4.3.1.6. The Get Child Nodes packet 897 "Get Child Nodes" packet gets generated by root to get all the 898 children under a router. Contents of the router is expressed as 899 follows: 901 Router ID of the router (32 bits in IPv4) + 902 Number of children of the router (16 bits) + 903 for each child of the router { 904 Type of the child (Customer Network/Router) (16 bits) + 905 Router ID of the child (32 bits in IPv4) 906 } 908 Exchange of router information is just same as the operation of 909 "Database Description" packet of OSPF (See section A.3.3 of [19]). 910 Format of "Get Child Nodes" packet is same as "Database Description" 911 packet of OSPF with the "Type" field set as 6. 913 4.3.1.7. The Acknowledgment packet 915 An "Acknowledgment" packet is sent to acknowledge that an "Add 916 Node"/"Delete Node"/"Link Up"/"Link Down" message has been received 917 to the sender. All the fields of an "Acknowledgment" packet are same 918 as an "Add Node" packet apart from the Type(7) field. 920 4.4. IP VPN with MPLS inside VLSM tree 922 This section describes how to make IP VPN work inside VLSM tree 923 without using BGP. 925 RFC4364 [7] describes "IP VPN" with BGP/MPLS. To support VPN, PE 926 routers maintain per-site forwarding table. When a packet arrives 927 from an associated CE router, PE router consults with this forwarding 928 table to forward the packet. If the packet is supposed to be 929 forwarded to another site of VPN through the backbone, it uses two- 930 level label stack. The upper label is used to forward the packet from 931 ingress PE router to the egress PE router; where as, the inner label 932 is used for the egress PE router to identify the associated CE router 933 where the packet is supposed to be forwarded. BGP is used by the 934 Service Provider to exchange the routes of a particular VPN among the 935 PE routers that are attached to that VPN. Configuration takes place 936 on PE routers of both the sides of LSP. The simplest way to achieve 937 this is to configure these attributes manually on PE routers. In 938 order to have dynamic allocation of inner label, MPLS signaling 939 protocols (in place of BGP) need to be extended. Allocation of inner 940 label has to be done by the egress PE router. Same message that is 941 used for the assignment of upper label may be used for the assignment 942 of inner label. Inside the forwarding table, each entry contains the 943 forwarding destination address based on a set of destination 944 addresses (NetAddress/NetMask) of the IP packets received from 945 ingress CE router. While establishing inner label, ingress PE router 946 needs to send these attributes with the signaling message and the 947 egress PE router needs to validate those before assigning label. 949 4.4.1. Extension to RSVP-TE to support IP VPN inside VLSM tree 951 This section describes extension to RSVP-TE[17] to support dynamic 952 allocation of inner label of two-level label stack used to support 953 VPN services. 955 In order to establish LSP using RSVP-TE, ingress PE router sends Path 956 message to the egress PE router. Path message is augmented with a 957 LABEL_REQUEST object. Labels are allocated downstream and 958 distributed (propagated upstream) by means of RSVP Resv message. For 959 this purpose, the RSVP Resv message is extended with a special LABEL 960 object. In order to support VPN to establish the inner label, Path 961 message is augmented with a VPN_ATTRIBUTE label. Similarly, RSVP Resv 962 message is extended with a VPN_LABEL object. When an egress PE router 963 receives a Path message, it checks the presence of VPN_ATTRIBUTE 964 object. On finding this object, egress PE router checks the viability 965 of assignment of VPN label with the parameters from the VPN_ATTRIBUTE 966 object and the attributes that are already configured with the egress 967 PE router. If the test is positive, it assigns a VPN label and does 968 the rest of the processing of LSP label assignment and sends the RSVP 969 Resv message with the extension of VPN_LABEL object towards the 970 ingress PE router. On receiving Resv message with VPN_LABEL object, 971 ingress PE router assigns VPN label along with the rest of the 972 processing of Resv message and completes the operation. VPN_ATTRIBUTE 973 and VPN_LABEL objects are described below. 975 VPN_LABEL class=, C-Type=1 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | (inner label) | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 VPN_ATTRIBUTE class=, C-Type=1 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Global Unicast Address of Ingress CE Router | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Global Unicast Address of Egress CE Router | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Net Address of Destination IP Packet | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Net Mask of Destination IP Packet | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 The format of the Path message is as follows: 997 ::= [ ] 998 999 1000 [ ] 1001 1002 [ ] 1003 [ ] 1004 [ ... ] 1005 1007 ::= 1008 [ ] 1009 [ ] 1011 The format of the Resv message is as follows: 1013 ::= [ ] 1014 1015 1016 [ ] [ ] 1017 [ ... ] 1018 [ ] 1019