idnits 2.17.1 draft-irtf-routing-reqs-11.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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (February 16, 2009) is 5547 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-irtf-routing-history-06 -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Doria 3 Internet-Draft LTU 4 Intended status: Historic E. Davies 5 Expires: August 20, 2009 Folly Consulting 6 F. Kastenholz 7 February 16, 2009 9 A Set of Possible Requirements for a Future Routing Architecture 10 draft-irtf-routing-reqs-11.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 20, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 The requirements for routing architectures described in this document 50 were produced by two sub-groups under the IRTF Routing Research Group 51 in 2001, with some editorial updates up to 2006. The two sub-groups 52 worked independently, and the resulting requirements represent two 53 separate views of the problem and of what is required to fix the 54 problem. This document may usefully serve as part of the recommended 55 reading for anyone who works on routing architecture designs for the 56 Internet in the future. 58 The document is published with the support of the IRTF RRG as a 59 record of the work completed at that time, but with the understanding 60 that it does not necessarily represent either the latest technical 61 understanding or the technical consensus of the research group at the 62 date of publication. 64 Table of Contents 66 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Results from Group A . . . . . . . . . . . . . . . . . . . . . 7 68 2.1. Group A - Requirements For a Next Generation Routing 69 and Addressing Architecture . . . . . . . . . . . . . . . 7 70 2.1.1. Architecture . . . . . . . . . . . . . . . . . . . . 7 71 2.1.2. Separable Components . . . . . . . . . . . . . . . . 7 72 2.1.3. Scalable . . . . . . . . . . . . . . . . . . . . . . 8 73 2.1.4. Lots of Interconnectivity . . . . . . . . . . . . . . 11 74 2.1.5. Random Structure . . . . . . . . . . . . . . . . . . 11 75 2.1.6. Multi-homing . . . . . . . . . . . . . . . . . . . . 12 76 2.1.7. Multi-path . . . . . . . . . . . . . . . . . . . . . 12 77 2.1.8. Convergence . . . . . . . . . . . . . . . . . . . . . 13 78 2.1.9. Routing System Security . . . . . . . . . . . . . . . 15 79 2.1.10. End Host Security . . . . . . . . . . . . . . . . . . 17 80 2.1.11. Rich Policy . . . . . . . . . . . . . . . . . . . . . 17 81 2.1.12. Incremental Deployment . . . . . . . . . . . . . . . 20 82 2.1.13. Mobility . . . . . . . . . . . . . . . . . . . . . . 20 83 2.1.14. Address Portability . . . . . . . . . . . . . . . . . 21 84 2.1.15. Multi-Protocol . . . . . . . . . . . . . . . . . . . 21 85 2.1.16. Abstraction . . . . . . . . . . . . . . . . . . . . . 21 86 2.1.17. Simplicity . . . . . . . . . . . . . . . . . . . . . 22 87 2.1.18. Robustness . . . . . . . . . . . . . . . . . . . . . 22 88 2.1.19. Media Independence . . . . . . . . . . . . . . . . . 23 89 2.1.20. Stand-alone . . . . . . . . . . . . . . . . . . . . . 23 90 2.1.21. Safety of Configuration . . . . . . . . . . . . . . . 24 91 2.1.22. Renumbering . . . . . . . . . . . . . . . . . . . . . 24 92 2.1.23. Multi-prefix . . . . . . . . . . . . . . . . . . . . 24 93 2.1.24. Cooperative Anarchy . . . . . . . . . . . . . . . . . 24 94 2.1.25. Network Layer Protocols and Forwarding Model . . . . 24 95 2.1.26. Routing Algorithm . . . . . . . . . . . . . . . . . . 24 96 2.1.27. Positive Benefit . . . . . . . . . . . . . . . . . . 25 97 2.1.28. Administrative Entities and the IGP/EGP Split . . . . 25 98 2.2. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 26 99 2.2.1. Forwarding Table Optimization . . . . . . . . . . . . 26 100 2.2.2. Traffic Engineering . . . . . . . . . . . . . . . . . 26 101 2.2.3. Multicast . . . . . . . . . . . . . . . . . . . . . . 26 102 2.2.4. Quality of Service (QoS) . . . . . . . . . . . . . . 26 103 2.2.5. IP Prefix Aggregation . . . . . . . . . . . . . . . . 27 104 2.2.6. Perfect Safety . . . . . . . . . . . . . . . . . . . 27 105 2.2.7. Dynamic Load Balancing . . . . . . . . . . . . . . . 27 106 2.2.8. Renumbering of Hosts and Routers . . . . . . . . . . 28 107 2.2.9. Host Mobility . . . . . . . . . . . . . . . . . . . . 28 108 2.2.10. Backward Compatibility . . . . . . . . . . . . . . . 28 109 3. Requirements from Group B . . . . . . . . . . . . . . . . . . 29 110 3.1. Group B - Future Domain Routing Requirements . . . . . . . 29 111 3.2. Underlying Principles . . . . . . . . . . . . . . . . . . 29 112 3.2.1. Inter-domain and Intra-domain . . . . . . . . . . . . 30 113 3.2.2. Influences on a Changing Network . . . . . . . . . . 31 114 3.2.3. High Level Goals . . . . . . . . . . . . . . . . . . 32 115 3.3. High Level User Requirements . . . . . . . . . . . . . . . 36 116 3.3.1. Organisational Users . . . . . . . . . . . . . . . . 36 117 3.3.2. Individual Users . . . . . . . . . . . . . . . . . . 39 118 3.4. Mandated Constraints . . . . . . . . . . . . . . . . . . . 39 119 3.4.1. The Federated Environment . . . . . . . . . . . . . . 40 120 3.4.2. Working with Different Sorts of Networks . . . . . . 40 121 3.4.3. Delivering Resilient Service . . . . . . . . . . . . 41 122 3.4.4. When Will the New Solution Be Required? . . . . . . . 41 123 3.5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 42 124 3.6. Functional Requirements . . . . . . . . . . . . . . . . . 44 125 3.6.1. Topology . . . . . . . . . . . . . . . . . . . . . . 44 126 3.6.2. Distribution . . . . . . . . . . . . . . . . . . . . 45 127 3.6.3. Addressing . . . . . . . . . . . . . . . . . . . . . 49 128 3.6.4. Statistics Support . . . . . . . . . . . . . . . . . 51 129 3.6.5. Management Requirements . . . . . . . . . . . . . . . 51 130 3.6.6. Provability . . . . . . . . . . . . . . . . . . . . . 52 131 3.6.7. Traffic Engineering . . . . . . . . . . . . . . . . . 53 132 3.6.8. Support for Middleboxes . . . . . . . . . . . . . . . 55 133 3.7. Performance Requirements . . . . . . . . . . . . . . . . . 55 134 3.8. Backwards Compatibility (Cutover) and Maintainability . . 56 135 3.9. Security Requirements . . . . . . . . . . . . . . . . . . 56 136 3.10. Debatable Issues . . . . . . . . . . . . . . . . . . . . . 58 137 3.10.1. Network Modeling . . . . . . . . . . . . . . . . . . 58 138 3.10.2. System Modeling . . . . . . . . . . . . . . . . . . . 59 139 3.10.3. One, Two or Many Protocols . . . . . . . . . . . . . 59 140 3.10.4. Class of Protocol . . . . . . . . . . . . . . . . . . 60 141 3.10.5. Map Abstraction . . . . . . . . . . . . . . . . . . . 60 142 3.10.6. Clear Identification for All Entities . . . . . . . . 60 143 3.10.7. Robustness and Redundancy . . . . . . . . . . . . . . 61 144 3.10.8. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 61 145 3.10.9. Control Theory . . . . . . . . . . . . . . . . . . . 61 146 3.10.10. Byzantium . . . . . . . . . . . . . . . . . . . . . . 62 147 3.10.11. VPN Support . . . . . . . . . . . . . . . . . . . . . 62 148 3.10.12. End-to-End Reliability . . . . . . . . . . . . . . . 62 149 3.10.13. End-to-End Transparency . . . . . . . . . . . . . . . 62 150 4. Security Considerations . . . . . . . . . . . . . . . . . . . 64 151 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 152 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66 153 7. Informative References . . . . . . . . . . . . . . . . . . . . 68 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71 156 1. Background 158 In 2001, the IRTF Routing Research Group (IRTF RRG) chairs, Abha 159 Ahuja and Sean Doran, decided to establish a sub-group to look at 160 requirements for inter-domain routing (IDR). A group of well known 161 routing experts was assembled to develop requirements for a new 162 routing architecture. Their mandate was to approach the problem 163 starting from a blank sheet. This group was free to take any 164 approach, including a revolutionary approach, in developing 165 requirements for solving the problems they saw in inter-domain 166 routing. 168 Simultaneously, an independent effort was started in Sweden with a 169 similar goal. A team, calling itself Babylon, with participation 170 from vendors, service providers, and academia, assembled to 171 understand the history of inter-domain routing, to research the 172 problems seen by the service providers, and to develop a proposal of 173 requirements for a follow-on to the current routing architecture. 174 This group's remit required an evolutionary approach starting from 175 current routing architecture and practice. In other words the group 176 limited itself to developing an evolutionary strategy. The Babylon 177 group was later folded into the IRTF RRG as Sub-Group B to 178 distinguish it from the original RRG Sub-group A. 180 One of the questions that arose while the groups were working in 181 isolation was whether there would be many similarities between their 182 sets of requirements. That is, would the requirements that grew from 183 a blank sheet of paper resemble those that started with the 184 evolutionary approach? As can be seen from reading the two sets of 185 requirements, there were many areas of fundamental agreement but some 186 areas of disagreement. 188 There were suggestions within the RRG that the two teams should work 189 together to create a single set of requirements. Since these 190 requirements are only guidelines to future work, however, some felt 191 that doing so would risk losing content without gaining any 192 particular advantage. It is not as if any group, for example the 193 IRTF RRG or the IETF Routing Area, was expected to use these 194 requirements as written and to create an architecture that met these 195 requirements. Rather, the requirements were in practice strong 196 recommendations for a way to proceed in creating a new routing 197 architecture. In the end the decision was made to include the 198 results of both efforts, side by side, in one document. 200 This document contains the two requirement sets produced by the 201 teams. The text has received only editorial modifications; the 202 requirements themselves have been left unaltered. Whenever the 203 editors felt that conditions had changed in the few years since the 204 text was written, an editors' note has been added to the text. 206 In reading this document it is important to keep in mind that all of 207 these requirements are suggestions, which are laid out to assist 208 those interested in developing new routing architectures. It is also 209 important to remember that, while the people working on these 210 suggestions have done their best to make intelligent suggestions, 211 there are no guarantees. So a reader of this document should not 212 treat what it says as absolute, nor treat every suggestion as 213 necessary. No architecture is expected to fulfill every 214 'requirement.' Hopefully, though, future architectures will consider 215 what is offered in this document. 217 The IRTF RRG supported publication of this document as a historical 218 record of the work completed on the understanding that it does not 219 necessarily represent either the latest technical understanding or 220 the technical consensus of the research group at the time of 221 publication. The document has had substantial review by members of 222 the two teams, other members of the IRTF RRG and additional experts 223 over the years. 225 Finally, this document does not make any claims that it is possible 226 to have a practical solution that meets all the listed requirements. 228 2. Results from Group A 230 This section presents the results of the work done by Sub-Group A of 231 the IRTF-RRG during 2001- 2002. The work originally appeared under 232 the title: "Requirements For a Next Generation Routing and Addressing 233 Architecture" and was edited by Frank Kastenholz. 235 2.1. Group A - Requirements For a Next Generation Routing and 236 Addressing Architecture 238 The requirements presented in this section are not presented in any 239 particular order. 241 2.1.1. Architecture 243 The new routing and addressing protocols, data structures, and 244 algorithms need to be developed from a clear, well thought out, 245 documented, architecture. 247 The new routing and addressing system must have an architectural 248 specification which describes all of the routing and addressing 249 elements, their interactions, what functions the system performs, and 250 how it goes about performing them. The architectural specification 251 does not go into issues such as protocol and data structure design. 253 The architecture should be agnostic with regard to specific 254 algorithms and protocols. 256 Doing architecture before doing detailed protocol design is good 257 engineering practice. This allows the architecture to be reviewed 258 and commented upon, with changes made as necessary, when it is still 259 easy to do so. Also, by producing an architecture, the eventual 260 users of the protocols (the operations community) will have a better 261 understanding of how the designers of the protocols meant them to be 262 used. 264 2.1.2. Separable Components 266 The architecture must place different functions into separate 267 components. 269 Separating functions, capabilities, and so forth, into individual 270 components and making each component "stand alone" is generally 271 considered by system architects to be "A Good Thing". It allows 272 individual elements of the system to be designed and tuned to do 273 their jobs "very well". It also allows for piecemeal replacement and 274 upgrading of elements as new technologies and algorithms become 275 available. 277 The architecture must have the ability to replace or upgrade existing 278 components and to add new ones, without disrupting the remaining 279 parts of the system. Operators must be able to roll out these 280 changes and additions incrementally (i.e., no "flag days"). These 281 abilities are needed to allow the architecture to evolve as the 282 Internet changes. 284 The architecture specification shall define each of these components, 285 their jobs, and their interactions. 287 Some thoughts to consider along these lines are 289 o Making topology and addressing separate subsystems. This may 290 allow highly optimized topology management and discovery without 291 constraining the addressing structure or physical topology in 292 unacceptable ways. 294 o Separate "fault detection and healing" from basic topology. 295 From Mike O'Dell: 297 "Historically the same machinery is used for both. While 298 attractive for many reasons, the availability of exogenous 299 topology information (i.e., the intended topology) should, it 300 seems, make some tasks easier than the general case of starting 301 with zero knowledge. It certainly helps with recovery in the 302 case of constraint satisfaction. In fact, the intended 303 topology is a powerful way to state certain kinds of policy." 304 [ODell01] 306 o Making policy definition and application a separate subsystem, 307 layered over the others. 309 The architecture should also separate topology, routing, and 310 addressing from the application that uses those components. This 311 implies that applications such as policy definition, forwarding, and 312 circuit and tunnel management are separate subsystems layered on top 313 of the basic topology, routing, and addressing systems. 315 2.1.3. Scalable 317 Scaling is the primary problem facing the routing and addressing 318 architecture today. This problem must be solved and it must be 319 solved for the long term. 321 The architecture must support a large and complex network. Ideally, 322 it will serve our needs for the next 20 years. Unfortunately: 324 1. we do not know how big the Internet will grow over that time, and 326 2. the architecture developed from these requirements may change the 327 fundamental structure of the Internet and therefore its growth 328 patterns. This change makes it difficult to predict future 329 growth patterns of the Internet. 331 As a result, we can't quantify the requirement in any meaningful way. 332 Using today's architectural elements as a mechanism for describing 333 things, we believe that the network could grow to: 335 1. tens of thousands of AS's 337 Editors' Note: As of 2005, this level had already been 338 reached. 340 2. tens to hundreds of millions of prefixes, during the lifetime of 341 this architecture. 343 These sizes are given as a 'flavor' for how we expect the Internet to 344 grow. We fully believe that any new architecture may eliminate some 345 current architectural elements and introduce new ones. 347 A new routing and addressing architecture designed for a specific 348 network size would be inappropriate. First, the cost of routing 349 calculations is based only in part on the number of AS's or prefixes 350 in the network. The number and locations of the links in the network 351 are also significant factors. Second, past predictions of Internet 352 growth and topology patterns have proven to be wildly inaccurate so 353 developing an architecture to a specific size goal would at best be 354 shortsighted. 356 Editors' note: At the time of these meetings, the BGP statistics 357 kept at sites such as www.routeviews.org either did not exist or 358 had been running for only a few months. After 5 years of 359 recording public Internet data trends in AS growth, routing table 360 growth can be observed (past) with some short term prediction. As 361 each year of data collection continues the ability to observe and 362 predict trends improves. This architecture work pointed out the 363 need for such statistics to improve future routing designs. 365 Therefore we will not make the scaling requirement based on a 366 specific network size. Instead, the new routing and addressing 367 architecture should have the ability to constrain the increase in 368 load (CPU, memory space and bandwidth, and network bandwidth) on ANY 369 SINGLE ROUTER to be less than these specific functions: 371 1. The computational power and memory sizes required to execute the 372 routing protocol software and to contain the tables must grow 373 more slowly than hardware capabilities described by Moore's Law, 374 doubling every 18 months. Other observations indicate that 375 memory sizes double every 2 years or so. 377 2. Network bandwidth and latency are some key constraints on how 378 fast routing protocol updates can be disseminated (and therefore 379 how fast the routing system can adapt to changes). Raw network 380 bandwidth seems to quadruple every 3 years or so. However, it 381 seems that there are some serious physics problems in going 382 faster than 40Gbit/s (OC768); we should not expect raw network 383 link speed to grow much beyond OC768. On the other hand, for 384 economic reasons, large swathes of the core of the Internet will 385 still operate at lower speeds, possibly as slow as DS3. 387 Editors' Note: Technology is running ahead of imagination and 388 higher speeds are already common. 390 Furthermore, in some sections of the Internet even lower speed 391 links are found. Corporate access links are often T1, or slower. 392 Low-speed radio links exist. Intra-domain links may be T1 or 393 fractional-T1 (or slower). 395 Therefore, the architecture must not make assumptions about the 396 bandwidth available. 398 3. The speeds of high-speed RAMs (SRAMs, used for caches and the 399 like) are growing, though slowly. Because of their use in caches 400 and other very specific applications, these RAMs tend to be 401 small, a few megabits, and the size of these RAMs is not 402 increasing very rapidly. 404 On the other hand, the speed of "large" memories (DRAMs) is 405 increasing even slower than that for the high speed RAMs. This 406 is because the development of these RAMs is driven by the PC 407 market, where size is very important, and low speed can be made 408 up for by better caches. 410 Memory access rates should not be expected to increase 411 significantly. 413 Editors' Note: Various techniques have significantly increased 414 memory bandwidth. 800MHz is now possible, compared with less 415 than 100MHz in year 2000. This does not, however, contradict 416 the next paragraph, but rather just extends the timescales 417 somewhat. 419 The growth in resources available to any one router will eventually 420 slow down. It may even stop. Even so, the network will continue to 421 grow. The routing and addressing architecture must continue to scale 422 in even this extreme condition. We cannot continue to add more 423 computing power to routers forever. Other strategies must be 424 available. Some possible strategies are hierarchy, abstraction, and 425 aggregation of topology information. 427 2.1.4. Lots of Interconnectivity 429 The new routing and addressing architecture must be able to cope with 430 a high degree of interconnectivity in the Internet. That is, there 431 are large numbers of alternate paths and routes among the various 432 elements. Mechanisms are required to prevent this interconnectivity 433 (and continued growth in interconnectivity) from causing tables, 434 compute time, and routing protocol traffic to grow without bound. 435 The "cost" to the routing system of an increase in complexity must be 436 limited in scope; sections of the network that do not see, or do not 437 care about, the complexity ought not pay the cost of that complexity. 439 Over the past several years, the Internet has seen an increase in 440 interconnectivity. Individual end sites (companies, customers, 441 etc.), ISPs, exchange points, and so on, all are connecting to more 442 "other things". Companies multi-home to multiple ISPs, ISPs peer 443 with more ISPs, and so on. These connections are made for many 444 reasons, such as getting more bandwidth, increased reliability and 445 availability, policy, and so on. However, this increased 446 interconnectivity has a price. It leads to more scaling problems as 447 it increases the number of AS paths in the networks. 449 Any new architecture must assume that the Internet will become a 450 denser mesh. It must not assume, nor can it dictate, certain 451 patterns or limits on how various elements of the network 452 interconnect. 454 Another facet of this requirement is that there may be multiple 455 valid, loop free, paths available to a destination. See 456 Section 2.1.7 for a further discussion. 458 We wryly note that one of the original design goals of IP was to 459 support a large, heavily interconnected, network, which would be 460 highly survivable (such as in the face of a nuclear war). 462 2.1.5. Random Structure 464 The routing and addressing architecture must not place any 465 constraints on or make assumptions about the topology or 466 connectedness of the elements comprising the Internet. The routing 467 and addressing architecture must not presume any particular network 468 structure. The network does not have a "nice" structure. In the 469 past we used to believe that there was this nice "backbone/tier-1/ 470 tier-2/end-site" sort of hierarchy. This is not so. Therefore, any 471 new architecture must not presume any such structure. 473 Some have proposed that a geographic addressing scheme be used, 474 requiring exchange points to be situated within each geographic 475 'region'. There are many reasons why we believe this to be a bad 476 approach, but those arguments are irrelevant. The main issue is that 477 the routing architecture should not presume a specific network 478 structure. 480 2.1.6. Multi-homing 482 The architecture must provide multi-homing for all elements of the 483 Internet. That is, multi-homing of hosts, subnetworks, end- sites, 484 "low-level" ISPs, and backbones (i.e., lots of redundant 485 interconnections) must be supported. Among the reasons to multi-home 486 are reliability, load sharing, and performance tuning. 488 The term "multi-homing" may be interpreted in its broadest sense -- 489 one "place" has multiple connections or links to another "place". 491 The architecture must not limit the number of alternate paths to a 492 multi-homed site. 494 When multi-homing is used, it must be possible to use one, some (more 495 than one but less than all), or all of the available paths to the 496 multi-homed site. The multi-homed site must have the ability to 497 declare which path(s) are used and under what conditions (for 498 example, one path may be declared "primary" and the other "backup" 499 and to be used only when the primary fails). 501 A current problem in the Internet is that multi-homing leads to undue 502 increases in the size of the BGP routing tables. The new 503 architecture must support multi-homing without undue routing table 504 growth. 506 2.1.7. Multi-path 508 As a corollary to multi-homing, the architecture must allow for 509 multiple paths from a source to a destination to be active at the 510 same time. These paths need not have the same attributes. Policies 511 are to be used to disseminate the attributes and to classify traffic 512 for the different paths. 514 There must be a rich "language" for specifying the rules for 515 classifying the traffic and assigning classes of traffic to different 516 paths (or prohibiting it from certain paths). The rules should allow 517 traffic to be classified based upon at least the following: 519 o IPv6 FlowIDs, 521 o DSCP values, 523 o source and/or destination prefixes, or 525 o random selections at some probability. 527 A mechanism is needed that allows operators to plan and manage the 528 traffic load on the various paths. To start, this mechanism can be 529 semi-automatic or even manual. Eventually it ought to become fully 530 automatic. 532 When multi-path forwarding is used, options must be available to 533 preserve packet ordering where appropriate (such as for individual 534 TCP connections). 536 Please refer to Section 2.2.7 for a discussion of dynamic load- 537 balancing and management over multiple paths. 539 2.1.8. Convergence 541 The speed of convergence (also called the "stabilization time") is 542 the time it takes for a router's routing processes to reach a new, 543 stable, "solution" (i.e., forwarding information base) after a change 544 someplace in the network. In effect, what happens is that the output 545 of the routing calculations stabilizes -- the Nth iteration of the 546 software produces the same results as the N-1th iteration. 548 The speed of convergence is generally considered to be a function of 549 the number of subnetworks in the network and the amount of 550 connections between those networks. As either number grows, the time 551 it takes to converge increases. 553 In addition, a change can "ripple" back and forth through the system. 554 One change can go through the system, causing some other router to 555 change its advertised connectivity, causing a new change to ripple 556 through. These oscillations can take a while to work their way out 557 of the network. It is also possible that these ripples never die 558 out. In this situation the routing and addressing system is 559 unstable; it never converges. 561 Finally, it is more than likely that the routers comprising the 562 Internet never converge simply because the Internet is so large and 563 complex. Assume it takes S seconds for the routers to stabilize on a 564 solution for any one change to the network. Also assume that changes 565 occur, on average, every C seconds. Because of the size and 566 complexity of the Internet, C is now less than S. Therefore, if a 567 change, C1, occurs at time T, the routing system would stabilize at 568 time T+S, but a new change, C2, will occur at time T+C, which is 569 before T+S. The system will start processing the new change before 570 it's done with the old. 572 This is not to say that all routers are constantly processing 573 changes. The effects of changes are like ripples in a pond. They 574 spread outward from where they occur. Some routers will be 575 processing just C1, others C2, others both C1 and C2, and others 576 neither. 578 We have two separate scopes over which we can set requirements with 579 respect to convergence: 581 1. Single Change 582 In this requirement a single change of any type (link addition or 583 deletion, router failure or restart, etc.) is introduced into a 584 stabilized system. No additional changes are introduced. The 585 system must re-stabilize within some measure of bounded time. 586 This requirement is a fairly abstract one as it would be 587 impossible to test in a real network. Definition of the time 588 constraints remains an open research issue. 590 2. System-wide 591 Defining a single target for maximum convergence time for the 592 real Internet is absurd. As we mentioned earlier, the Internet 593 is large enough and diverse enough so that it is quite likely 594 that new changes are introduced somewhere before the system fully 595 digests old ones. 597 So, the first requirement here is that there must be mechanisms to 598 limit the scope of any one change's visibility and effects. The 599 number of routers that have to perform calculations in response to a 600 change is kept small, as is the settling time. 602 The second requirement is based on the following assumptions: 604 - the scope of a change's visibility and impact can be limited. 605 That is, routers within that scope know of the change and 606 recalculate their tables based on the change. Routers outside of 607 the scope don't see it at all. 609 - Within any scope, S, network changes are constantly occurring and 610 the average inter-change interval is Tc seconds. 612 - There are Rs routers within scope S. 614 - A subset of the destinations known to the routers in S, Ds, are 615 impacted by a given change. 617 - We can state that for Z% of the changes, within Y% of Tc seconds 618 after a change, C, X% of the Rs routers have their routes to Ds 619 settled to a useful answer (useful meaning that packets can get to 620 Ds, though perhaps not by the optimal path -- this allows some 621 'hunting' for the optimal solution) 623 X, Y, and Z are yet to be defined. Their definition remains a 624 research issue. 626 This requirement implies that the scopes can be kept relatively small 627 in order to minimize Rs and maximize Tc. 629 The growth rate of the convergence time must not be related to the 630 growth rate of the Internet as a whole. This implies that the 631 convergence time either 633 1. not be a function of basic network elements (such as prefixes and 634 links/paths), and/or 636 2. that the Internet be continuously divisible into chunks that 637 limit the scope and effect of a change, thereby limiting the 638 number of routers, prefixes, links, and so on, involved in the 639 new calculations. 641 2.1.9. Routing System Security 643 The security of the Internet's routing system is paramount. If the 644 routing system is compromised or attacked, the entire Internet can 645 fail. This is unacceptable. Any new architecture must be secure. 647 Architectures by themselves are not secure. It is the implementation 648 of an architecture; its protocols, algorithms, and data structures, 649 that are secure. These requirements apply primarily to the 650 implementation. The architecture must provide the elements that the 651 implementation needs to meet these security requirements. Also, the 652 architecture must not prevent these security requirements from being 653 met. 655 Security means different things to different people. In order for 656 this requirement to be useful, we must define what we mean by 657 security. We do this by identifying the attackers and threats we 658 wish to protect against. They are: 660 Masquerading 661 The system, including its protocols, must be secure against 662 intruders adopting the identity of other known, trusted, elements 663 of the routing system and then using that position of trust for 664 carrying out other attacks. Protocols must use cryptographically 665 strong authentication. 667 Denial of Service (DoS) Attacks 668 The architecture and protocols should be secure against DoS 669 attacks directed at the routers. 671 The new architecture and protocols should provide as much 672 information as it can to allow administrators to track down 673 sources of DoS and Distributed DOS (DDoS) attacks. 675 No Bad Data 676 Any new architecture and protocols must provide protection 677 against the introduction of bad, erroneous, or misleading, data 678 by attackers. Of particular importance, an attacker must not be 679 able to redirect traffic flows, with the intent of 681 o directing legitimate traffic away from a target, causing a 682 denial-of-service attack by preventing legitimate data from 683 reaching its destination, 685 o directing additional traffic (going to other destinations 686 which are 'innocent bystanders') to a target, causing the 687 target to be overloaded, or 689 o directing traffic addressed to the target to a place where the 690 attacker can copy, snoop, alter, or otherwise affect the 691 traffic. 693 Topology Hiding 694 Any new architecture and protocols must provide mechanisms to 695 allow network owners to hide the details of their internal 696 topologies, while maintaining the desired levels of service 697 connectivity and reachability. 699 Privacy 700 By "privacy" we mean privacy of the routing protocol exchanges 701 between routers. 703 When the routers are on point-to-point links, with routers at 704 each end, there may not be any need to encrypt the routing 705 protocol traffic as the possibility of a third party intercepting 706 the traffic is limited though not impossible. We do believe, 707 however, that it is important to have the ability to protect 708 routing protocol traffic in two cases: 710 1. When the routers are on a shared network, it is possible that 711 there are hosts on the network that have been compromised. 712 These hosts could surreptitiously monitor the protocol 713 traffic. 715 2. When two routers are exchanging information "at a distance" 716 (over intervening routers and, possibly, across 717 administrative domain boundaries). In this case, the 718 security of the intervening routers, links, and so on, cannot 719 be assured. Thus, the ability to encrypt this traffic is 720 important. 722 Therefore, we believe that the option to encrypt routing protocol 723 traffic is required. 725 Data Consistency 726 A router should be able to detect and recover from any data that 727 is received from other routers which is inconsistent. That is, 728 it must not be possible for data from multiple routers, none of 729 which is malicious, to "break" another router. 731 Where security mechanisms are provided, they must use methods that 732 are considered to be cryptographically secure (e.g., using 733 cryptographically strong encryption and signatures -- no clear text 734 passwords!). 736 Use of security features should not be optional (except as required 737 above). This may be "social engineering" on our part, but we believe 738 it to be necessary. If a security feature is optional, the 739 implementation of the feature must default to the "secure" setting. 741 2.1.10. End Host Security 743 The architecture must not prevent individual host-to-host 744 communications sessions from being secured (i.e., it cannot interfere 745 with things like IPsec). 747 2.1.11. Rich Policy 749 Before setting out Policy requirements, we need to define the term. 750 Like "security", "policy" means many things to many people. For our 751 purposes, policy is the set of administrative influences that alter 752 the path determination and next-hop selection procedures of the 753 routing software. 755 The main motivators for influencing path and next-hop selection seem 756 to be transit rules, business decisions, and load management. 758 The new architecture must support rich policy mechanisms. 759 Furthermore, the policy definition and dissemination mechanisms 760 should be separated from the network topology and connectivity 761 dissemination mechanisms. Policy provides input to and controls the 762 generation of the forwarding table and the abstraction, filtering, 763 aggregation, and dissemination of topology information. 765 Note that if the architecture is properly divided into subsystems 766 then at a later time, new policy subsystems that include new features 767 and capabilities could be developed and installed as needed. 769 We divide the general area of policy into two sub-categories, routing 770 information and traffic control. Routing Information Policies 771 control what routing information is disseminated or accepted, how it 772 is disseminated, and how routers determine paths and next-hops from 773 the received information. Traffic Control Policies determine how 774 traffic is classified and assigned to routes. 776 2.1.11.1. Routing Information Policies 778 There must be mechanisms to allow network administrators, operators, 779 and designers to control receipt and dissemination of routing 780 information. These controls include, but are not limited to: 782 - Selecting to which other routers routing information will be 783 transmitted. 785 - Specifying the "granularity" and type of transmitted information. 786 The length of IPv4 prefixes is an example of "granularity". 788 - Selection and filtering of topology and service information that 789 is transmitted. This gives different 'views' of internal 790 structure and topology to different peers. 792 - Selecting the level of security and authenticity for transmitted 793 information. 795 - Being able to cause the level of detail that is visible for some 796 portion of the network to reduce the farther you get from that 797 part of the network. 799 - Selecting from whom routing information will be accepted. This 800 control should be "provisional" in the sense of "accept routes 801 from "foo" only if there are no others available". 803 - Accepting or rejecting routing information based on the path the 804 information traveled (using the current system as an example, this 805 would be filtering routes based on an AS appearing anywhere in the 806 AS path). This control should be "use only if there are no other 807 paths available". 809 - Selecting the desired level of "granularity" for received routing 810 information (this would include, but is not limited to, things 811 similar in nature to the prefix-length filters widely used in the 812 current routing and addressing system). 814 - Selecting the level of security and authenticity of received 815 information in order for that information to be accepted. 817 - Determining the treatment of received routing information based on 818 attributes supplied with the information. 820 - Applying attributes to routing information that is to be 821 transmitted and then determining treatment of information (e.g., 822 sending it "here" but not "there") based on those tags. 824 - Selection and filtering of topology and service information that 825 is received. 827 2.1.11.2. Traffic Control Policies 829 The architecture should provide mechanisms that allow network 830 operators to manage and control the flow of traffic. The traffic 831 controls should include, but are not limited to: 833 - The ability to detect and eliminate congestion points in the 834 network (by re-directing traffic around those points) 836 - The ability to develop multiple paths through the network with 837 different attributes and then assign traffic to those paths based on 838 some discriminators within the packets (discriminators include, but 839 are not limited to, IP Addresses or prefixes, IPv6 flow ID, DSCP 840 values, and MPLS labels) 842 - The ability to find and use multiple, equivalent, paths through the 843 network (i.e., they would have the "same" attributes) and allocate 844 traffic across the paths. 846 - The ability to accept or refuse traffic based on some traffic 847 classification (providing, in effect, transit policies). 849 Traffic classification must at least include the source and 850 destination IP addresses (prefixes) and the DSCP value. Other fields 851 may be supported, such as 853 o Protocol and port based functions, 855 o DSCP/QoS tuple (such as ports) 857 o Per-host operations (i.e., /32s for IPv4 and /128s for IPv6), 859 o Traffic matrices (e.g., traffic from prefix X and to prefix Y). 861 2.1.12. Incremental Deployment 863 The reality of the Internet is that there can be no Internet wide cut 864 over from one architecture and protocol to another. This means that 865 any new architecture and protocol must be incrementally deployable; 866 ISPs must be able to set up small sections of the new architecture, 867 check it out, and then slowly grow the sections. Eventually, these 868 sections will "touch" and "squeeze out" the old architecture. 870 The protocols that implement the architecture must be able to 871 interoperate at "production levels" with currently existing routing 872 protocols. Furthermore, the protocol specifications must define how 873 the interoperability is done. 875 We also believe that sections of the Internet will never convert over 876 to the new architecture. Thus, it is important that the new 877 architecture and its protocols be able to interoperate with "old 878 architecture" regions of the network indefinitely. 880 The architecture's addressing system must not force existing address 881 allocations to be redone: no renumbering! 883 2.1.13. Mobility 885 There are two kinds of mobility; host mobility and network mobility. 886 Host mobility is when an individual host moves from where it was to 887 where it is. Network mobility is when an entire network (or 888 subnetwork) moves. 890 The architecture must support network level mobility. Please refer 891 to Section 2.2.9 for a discussion of Host Mobility. 893 Editor's Note: Since the time of this work, the NEMO extensions to 894 Mobile IP [RFC3963] to accommodate mobile networks have been 895 developed. 897 2.1.14. Address Portability 899 One of the big "hot items" in the current Internet political climate 900 is portability of IP addresses (both v4 and v6). The short 901 explanation is that people do not like to renumber when changing 902 connection point or provider and do not trust automated renumbering 903 tools. 905 The architecture must provide complete address portability. 907 2.1.15. Multi-Protocol 909 The Internet is expected to be "multi-protocol" for at least the next 910 several years. IPv4 and IPv6 will co-exist in many different ways 911 during a transition period. The architecture must be able to handle 912 both IPv4 and IPv6 addresses. Furthermore, protocols that supplant 913 IPv4 and IPv6 may be developed and deployed during the lifetime of 914 the architecture. The architecture must be flexible and extensible 915 enough to handle new protocols as they arise. 917 Furthermore, the architecture must not assume any given relationships 918 between a topological element's IPv4 address and its IPv6 address. 919 The architecture must not assume that all topological elements have 920 IPv4 addresses/prefixes, nor can it assume that they have IPv6 921 addresses/prefixes. 923 The architecture should allow different paths to the same destination 924 to be used for different protocols, even if all paths can carry all 925 protocols. 927 In addition to the addressing technology, the architecture need not 928 be restricted to only packet based multiplexing/demultiplexing 929 technology (such as IP); support for other multiplexing/ 930 demultiplexing technologies may be added. 932 2.1.16. Abstraction 934 The architecture must provide mechanisms for network designers and 935 operators to: 937 o Group elements together for administrative control purposes, 938 o Hide the internal structure and topology of those groupings for 939 administrative and security reasons, 941 o Limit the amount of topology information that is exported from the 942 groupings in order to control the load placed on external routers, 944 o Define rules for traffic transiting or terminating in the 945 grouping. 947 The architecture must allow the current Autonomous System structure 948 to be mapped into any new abstraction schemes. 950 Mapping mechanisms, algorithms, and techniques must be specified. 952 2.1.17. Simplicity 954 The architecture must be simple enough so that someone who is 955 extremely knowledgeable in routing and who is skilled at creating 956 straightforward and simple explanations can explain all the important 957 concepts in less than an hour. 959 This criterion has been chosen since developing an objective measure 960 of complexity for an architecture can be very difficult and is out of 961 scope for this document. 963 The requirement is that the routing architecture be kept as simple as 964 possible. This requires careful evaluation of possible features and 965 functions with a merciless weeding out of those that "might be nice" 966 but are not necessary. 968 By keeping the architecture simple, the protocols and software used 969 to implement the architecture are simpler. This simplicity in turn 970 leads to: 972 1. Faster implementation of the protocols. If there are fewer bells 973 and whistles, then there are fewer things that need to be 974 implemented. 976 2. More reliable implementations. With fewer components, there is 977 less code, reducing bug counts, and fewer interactions between 978 components that could lead to unforeseen and incorrect behavior. 980 2.1.18. Robustness 982 The architecture, and the protocols implementing it, should be 983 robust. Robustness comes in many different flavors. Some 984 considerations with regard to robustness include (but are not limited 985 to): 987 o Continued correct operation in the face of: 989 * Defective (even malicious) trusted routers. 991 * Network failures. Whenever possible, valid alternate paths are 992 to be found and used. 994 o Failures must be localized. That is, the architecture must limit 995 the "spread" of any adverse effects of a misconfiguration or 996 failure. Badness must not spread. 998 Of course, the general robustness principle of being liberal in 999 what's accepted and conservative in what's sent must also be applied. 1001 Original Editor's note: 1002 Some of the contributors to this section have argued 1003 that robustness is an aspect of Security. I have 1004 exercised editor's discretion by making it a 1005 separate section. The reason for this is that to 1006 too many people "security" means "protection from 1007 break-ins" and "authenticating and encrypting data". 1008 This requirement goes beyond those views. 1010 2.1.19. Media Independence 1012 While it is an article of faith that IP operates over a wide variety 1013 of media (such as Ethernet, X.25, ATM, and so on), IP routing must 1014 take an agnostic view toward any "routing" or "topology" services 1015 that are offered by the medium over which IP is operating. That is, 1016 the new architecture must not be designed to integrate with any 1017 media-specific topology management or routing scheme. 1019 The routing architecture must assume, and must work over, the 1020 simplest possible media. 1022 The routing and addressing architecture can certainly make use of 1023 lower-layer information and services, when and where available, and 1024 to the extent that IP routing wishes. 1026 2.1.20. Stand-alone 1028 The routing architecture and protocols must not rely on other 1029 components of the Internet (such as DNS) for their correct operation. 1030 Routing is the fundamental process by which data "finds its way 1031 around the Internet" and most, if not all, of those other components 1032 rely on routing to properly forward their data. Thus, Routing cannot 1033 rely on any Internet systems, services or capabilities that in turn 1034 rely on Routing. If it did, a dependency loop would result. 1036 2.1.21. Safety of Configuration 1038 The architecture, protocols, and standard implementation defaults 1039 must be such that a router installed "out of the box" with no 1040 configuration, etc., by the operators will not cause "bad things" to 1041 happen to the rest of the routing system (e.g., no dial-up customers 1042 advertising routes to 18/8!) 1044 2.1.22. Renumbering 1046 The routing system must allow topological entities to be renumbered. 1048 2.1.23. Multi-prefix 1050 The architecture must allow topological entities to have multiple 1051 prefixes (or the equivalent under the new architecture). 1053 2.1.24. Cooperative Anarchy 1055 As RFC1726[RFC1726] said: 1056 "A major contributor to the Internet's success is the fact that 1057 there is no single, centralized, point of control or promulgator 1058 of policy for the entire network. This allows individual 1059 constituents of the network to tailor their own networks, 1060 environments, and policies to suit their own needs. The 1061 individual constituents must cooperate only to the degree 1062 necessary to ensure that they interoperate." 1064 This decentralization, called "cooperative anarchy", is still a key 1065 feature of the Internet today. The new routing architecture must 1066 retain this feature. There can be no centralized point of control or 1067 promulgator of policy for the entire Internet. 1069 2.1.25. Network Layer Protocols and Forwarding Model 1071 For the purposes of backward compatibility, any new routing and 1072 addressing architecture and protocols must work with IPv4 and IPv6 1073 using the traditional "hop by hop" forwarding and packet-based 1074 multiplex/demultiplex models. However, the architecture need not be 1075 restricted to these models. Additional forwarding and multiplex/ 1076 demultiplex models may be added. 1078 2.1.26. Routing Algorithm 1080 The architecture should not require a particular routing algorithm 1081 family. That is to say, the architecture should be agnostic about 1082 link-state, distance-vector, or path-vector routing algorithms. 1084 2.1.27. Positive Benefit 1086 Finally, the architecture must show benefits in terms of increased 1087 stability, decreased operational costs, and increased functionality 1088 and lifetime, over the current schemes. This benefit must remain 1089 even after the inevitable costs of developing and debugging the new 1090 protocols, enduring the inevitable instabilities as things get shaken 1091 out, and so on. 1093 2.1.28. Administrative Entities and the IGP/EGP Split 1095 We explicitly recognize that the Internet consists of resources under 1096 control of multiple administrative entities. Each entity must be 1097 able to manage its own portion of the Internet as it sees fit. 1098 Moreover, the constraints that can be imposed on routing and 1099 addressing on the portion of the Internet under the control of one 1100 administration may not be feasibly extended to cover multiple 1101 administrations. Therefore, we recognize a natural and inevitable 1102 split between routing and addressing that is under a single 1103 administrative control and routing and addressing that involves 1104 multiple administrative entities. Moreover, while there may be 1105 multiple administrative authorities, the administrative authority 1106 boundaries may be complex and overlapping, rather than being a strict 1107 hierarchy. 1109 Furthermore, there may be multiple levels of administration, each 1110 with its own level of policy and control. For example, a large 1111 network might have "continental-level" administrations covering its 1112 European and Asian operations, respectively. There would also be 1113 that network's "inter-continental" administration covering the 1114 Europe-to-Asia links. Finally, there would be the "Internet" level 1115 in the administrative structure (analogous to the "exterior" concept 1116 in the current routing architecture). 1118 Thus, we believe that the administrative structure of the Internet 1119 must be extensible to many levels (more than the two provided by the 1120 current IGP/EGP split). The interior/exterior property is not 1121 absolute. The interior/exterior property of any point in the network 1122 is relative; a point on the network is interior with respect to some 1123 points on the network and exterior with respect to others. 1125 Administrative entities may not trust each other; some may be almost 1126 actively hostile toward each other. The architecture must 1127 accommodate these models. Furthermore, the architecture must not 1128 require any particular level of trust among administrative entities. 1130 2.2. Non-Requirements 1132 The following are not required or are non-goals. This should not be 1133 taken to mean that these issues must not be addressed by a new 1134 architecture. Rather, addressing these issues or not is purely an 1135 optional matter for the architects. 1137 2.2.1. Forwarding Table Optimization 1139 We believe that it is not necessary for the architecture to minimize 1140 the size of the forwarding tables (FIBs). Current memory sizes, 1141 speeds, and prices, along with processor and ASIC capabilities allow 1142 forwarding tables to be very large, O(E6), and allow fast (100M 1143 lookups/second) tables to be built with little difficulty. 1145 2.2.2. Traffic Engineering 1147 Traffic Engineering is one of those terms that has become terribly 1148 overloaded. If one asks N people what traffic engineering is, one 1149 would get something like N! disjoint answers. Therefore, we elect 1150 not to require "traffic engineering", per se. Instead, we have 1151 endeavored to determine what the ultimate intent is when operators 1152 "traffic engineer" their networks and then make those capabilities an 1153 inherent part of the system. 1155 2.2.3. Multicast 1157 The new architecture is not designed explicitly to be an inter-domain 1158 multicast routing architecture. However, given the notable lack of a 1159 viable, robust, and widely deployed inter-domain multicast routing 1160 architecture, the architecture should not hinder the development and 1161 deployment of inter-domain multicast routing without adverse effect 1162 on meeting the other requirements. 1164 We do note however that one respected network sage [Clark91] has said 1165 (roughly) 1167 "When you see a bunch of engineers standing around congratulating 1168 themselves for solving some particularly ugly problem in 1169 networking, go up to them, whisper "multicast", jump back, and 1170 watch the fun begin..." 1172 2.2.4. Quality of Service (QoS) 1174 The architecture concerns itself primarily with disseminating network 1175 topology information so that routers may select paths to destinations 1176 and build appropriate forwarding tables. Quality of Service (QoS) is 1177 not a part of this function and we make no requirements with respect 1178 to QoS. 1180 However, QoS is an area of great and evolving interest. It is 1181 reasonable to expect that in the not too distant future, 1182 sophisticated QoS facilities will be deployed in the Internet. Any 1183 new architecture and protocols should be developed with an eye toward 1184 these future evolutions. Extensibility mechanisms, allowing future 1185 QoS routing and signaling protocols to "piggy-back" on top of the 1186 basic routing system are desired. 1188 We do require the ability to assign attributes to entities and then 1189 do path generation and selection based on those attributes. Some may 1190 call this QoS. 1192 2.2.5. IP Prefix Aggregation 1194 There is no specific requirement that CIDR-style IP Prefix 1195 aggregation be done by the new architecture. Address allocation 1196 policies, societal pressure, and the random growth and structure of 1197 the Internet have all conspired to make prefix aggregation 1198 extraordinarily difficult, if not impossible. This means that large 1199 numbers of prefixes will be sloshing about in the routing system and 1200 that forwarding tables will grow quite big. This is a cost that we 1201 believe must be borne. 1203 Nothing in this non-requirement should be interpreted as saying that 1204 prefix aggregation is explicitly prohibited. CIDR-style IP Prefix 1205 aggregation might be used as a mechanism to meet other requirements, 1206 such as scaling. 1208 2.2.6. Perfect Safety 1210 Making the system impossible to mis-configure is, we believe, not 1211 required. The checking, constraints, and controls necessary to 1212 achieve this could, we believe, prevent operators from performing 1213 necessary tasks in the face of unforeseen circumstances. 1215 However, safety is always a "good thing", and any results from 1216 research in this area should certainly be taken into consideration 1217 and, where practical, incorporated into the new routing architecture. 1219 2.2.7. Dynamic Load Balancing 1221 Past history has shown that using the routing system to perform 1222 highly dynamic load balancing among multiple more-or-less-equal paths 1223 usually ends up causing all kinds of instability, etc., in the 1224 network. Thus, we do not require such a capability. 1226 However, this is an area that is ripe for additional research, and 1227 some believe that the capability will be necessary in the future. 1228 Thus, the architecture and protocols should be "malleable" enough to 1229 allow development and deployment of dynamic load balancing 1230 capabilities, should we ever figure out how to do it. 1232 2.2.8. Renumbering of Hosts and Routers 1234 We believe that the routing system is not required to "do 1235 renumbering" of hosts and routers. That's an IP issue. 1237 Of course, the routing and addressing architecture must be able to 1238 deal with renumbering when it happens. 1240 2.2.9. Host Mobility 1242 In the Internet architecture, host-mobility is handled on a per-host 1243 basis by a dedicated, Mobile-IP protocol [RFC3344]. Traffic destined 1244 for a mobile-host is explicitly forwarded by dedicated relay agents. 1245 Mobile-IP [RFC3344] adequately solves the host-mobility problem and 1246 we do not see a need for any additional requirements in this area. 1247 Of course, the new architecture must not impede or conflict with 1248 Mobile-IP. 1250 2.2.10. Backward Compatibility 1252 For the purposes of development of the architecture, we assume that 1253 there is a 'clean slate'. Unless specified in Section 2.1, there are 1254 no explicit requirements that elements, concepts, or mechanisms of 1255 the current routing architecture be carried forward into the new one. 1257 3. Requirements from Group B 1259 The following is the result of the work done by Sub-Group B of the 1260 IRTF-RRG in 2001-2002. It was originally released under the title: 1261 "Future Domain Routing Requirements" and was edited by Avri Doria and 1262 Elwyn Davies. 1264 3.1. Group B - Future Domain Routing Requirements 1266 It is generally accepted that there are major shortcomings in the 1267 inter-domain routing of the Internet today and that these may result 1268 in meltdown within an unspecified period of time. Remedying these 1269 shortcomings will require extensive research to tie down the exact 1270 failure modes that lead to these shortcomings and identify the best 1271 techniques to remedy the situation. 1273 Reviewer's Note: Even in 2001, there was a wide difference of 1274 opinion across the community regarding the shortcomings of 1275 interdomain routing. In the years between writing and 1276 publication, further analysis, changes in operational practice, 1277 alterations to the demands made on inter-domain routing, 1278 modifications made to BGP and a recognition of the difficulty of 1279 finding a replacement may have altered the views of some members 1280 of the community. 1282 Changes in the nature and quality of the services that users want 1283 from the Internet are difficult to provide within the current 1284 framework, as they impose requirements never foreseen by the original 1285 architects of the Internet routing system. 1287 The kind of radical changes that have to be accommodated are 1288 epitomized by the advent of IPv6 and the application of IP mechanisms 1289 to private commercial networks that offer specific service guarantees 1290 beyond the best-effort services of the public Internet. Major 1291 changes to the inter-domain routing system are inevitable to provide 1292 an efficient underpinning for the radically changed and increasingly 1293 commercially-based networks that rely on the IP protocol suite. 1295 3.2. Underlying Principles 1297 Although inter-domain routing is seen as the major source of 1298 problems, the interactions with intra-domain routing, and the 1299 constraints that confining changes to the inter-domain arena would 1300 impose, mean that we should consider the whole area of routing as an 1301 integrated system. This is done for two reasons: 1303 - Requirements should not presuppose the solution. A continued 1304 commitment to the current definitions and split between inter- 1305 domain and intra-domain routing would constitute such a 1306 presupposition. Therefore this part of the document uses the name 1307 Future Domain Routing (FDR). 1309 - It is necessary to understand the degree to which inter-domain and 1310 intra-domain routing are related within today's routing 1311 architecture. 1313 We are aware that using the term "domain routing" is already fraught 1314 with danger because of possible misinterpretation due to prior usage. 1315 The meaning of "domain routing" will be developed implicitly 1316 throughout the document, but a little advance explicit definition of 1317 the word 'domain' is required, as well as some explanation on the 1318 scope of 'routing'. 1320 This document uses "domain" in a very broad sense, to mean any 1321 collection of systems or domains that come under a common authority 1322 that determines the attributes defining, and the policies 1323 controlling, that collection. The use of domain in this manner is 1324 very similar to the concept of region that was put forth by John 1325 Wroclawski in his Metanet model [Wroclawski95]. The idea includes 1326 the notion that certain attributes will characterize the behavior of 1327 the systems within a domain and that there will be borders between 1328 domains. The idea of domain presented here does not presuppose that 1329 two domains will have the same behavior. Nor does it presuppose 1330 anything about the hierarchical nature of domains. Finally, it does 1331 not place restrictions on the nature of the attributes that might be 1332 used to determine membership in a domain. Since today's routing 1333 domains are an example of the concept of domains in this document, 1334 there has been no attempt to create a new term. 1336 Current practice in routing system design stresses the need to 1337 separate the concerns of the control plane and the forwarding plane 1338 in a router. This document will follow this practice, but we still 1339 use the term "routing" as a global portmanteau to cover all aspects 1340 of the system. Specifically, however, routing will be used to mean 1341 the process of discovering, interpreting, and distributing 1342 information about the logical and topological structure of the 1343 network. 1345 3.2.1. Inter-domain and Intra-domain 1347 Throughout this section the terms intra-domain and inter-domain will 1348 be used. These should be understood as relative terms. In all cases 1349 of domains, there will be a set of network systems that are within 1350 that domain; routing between these systems will be termed intra- 1351 domain. In some cases there will be routing between domains, which 1352 will be termed inter-domain. It is possible that the routing 1353 exchange between two network systems can be viewed as intra-domain 1354 from one perspective and as inter-domain from another perspective. 1356 3.2.2. Influences on a Changing Network 1358 The development of the Internet is likely to be driven by a number of 1359 changes that will affect the organization and the usage of the 1360 network, including: 1362 - Ongoing evolution of the commercial relationships between 1363 (connectivity) service providers, leading to changes in the way in 1364 which peering between providers is organized and the way in which 1365 transit traffic is routed. 1367 - Requirements for traffic engineering within and between domains 1368 including coping with multiple paths between domains. 1370 - Addition of a second IP addressing technique, in the form of IPv6. 1372 - The use of VPNs and private address space with IPv4 and IPv6. 1374 - Evolution of the end-to-end principle to deal with the expanded 1375 role of the Internet, as discussed in [Blumenthal01]: This paper 1376 discusses the possibility that the range of new requirements, 1377 especially the social and techno-political ones that are being 1378 placed on the future, may compromise the Internet's original 1379 design principles. This might cause the Internet to lose some of 1380 its key features, in particular its ability to support new and 1381 unanticipated applications. This discussion is linked to the rise 1382 of new stakeholders in the Internet, especially ISPs; new 1383 government interests; the changing motivations of the ever growing 1384 user base; and the tension between the demand for trustworthy 1385 overall operation and the inability to trust the behaviour of 1386 individual users. 1388 - Incorporation of alternative forwarding techniques such as the 1389 explicit routing (pipes) supplied by the MPLS [RFC3031] and GMPLS 1390 [RFC3471] environments. 1392 - Integration of additional constraints into route determination 1393 from interactions with other layers (e.g., Shared Risk Link Groups 1394 [I-D.many-inference-srlg]). This includes the concern that 1395 redundant routes should not fate-share, e.g., because they 1396 physically run in the same trench. 1398 - Support for alternative and multiple routing techniques that are 1399 better suited to delivering types of content organised in ways 1400 other than into IP addressed packets. 1402 Philosophically, the Internet has the mission of transferring 1403 information from one place to another. Conceptually, this 1404 information is rarely organised into conveniently sized, IP-addressed 1405 packets, and the FDR needs to consider how the information (content) 1406 to be carried is identified, named and addressed. Routing techniques 1407 can then be adapted to handle the expected types of content. 1409 3.2.3. High Level Goals 1411 This section attempts to answer two questions: 1413 - What are we trying to achieve in a new architecture? 1415 - Why should the Internet community care? 1417 There is a third question that needs to be answered as well, but that 1418 has seldom been explicitly discussed: 1420 - How will we know when we have succeeded? 1422 3.2.3.1. Providing a Routing System Matched to Domain Organization 1424 Many of today's routing problems are caused by a routing system that 1425 is not well matched to the organization and policies that it is 1426 trying to support. Our goal is to develop a routing architecture 1427 where even a domain organization that is not envisioned today can be 1428 served by a routing architecture that matches its requirements. We 1429 will know when this goal is achieved when the desired policies, 1430 rules, and organization can be mapped into the routing system in a 1431 natural, consistent, and simply understood way. 1433 3.2.3.2. Supporting a Range of Different Communication Services 1435 Today's routing protocols only support a single data forwarding 1436 service that is typically used to deliver a best-effort service in 1437 the public Internet. On the other hand, DiffServ for example, can 1438 construct a number of different bit transport services within the 1439 network. Using some of the per-domain behaviors (PDB)s that have 1440 been discussed in the IETF, it is possible to construct services such 1441 as Virtual Wire [I-D.ietf-diffserv-pdb-vw] and Assured Rate 1442 [I-D.ietf-diffserv-pdb-ar]. 1444 Providers today offer rudimentary promises about traffic handling in 1445 the network, for example delay and long-term packet loss guarantees. 1447 As time goes on, this becomes even more relevant. Communicating the 1448 service characteristics of paths in routing protocols will be 1449 necessary in the near future, and it will be necessary to be able to 1450 route packets according to their service requirements. 1452 Thus, a goal of this architecture is to allow adequate information 1453 about path service characteristics to be passed between domains and 1454 consequently, to allow the delivery of bit transport services other 1455 than the best-effort datagram connectivity service that is the 1456 current common denominator. 1458 3.2.3.3. Scalable Well Beyond Current Predictable Needs 1460 Any proposed FDR system should scale beyond the size and performance 1461 we can foresee for the next ten years. The previous IDR proposal as 1462 implemented by BGP, has, with some massaging, held up for over ten 1463 years. In that time the Internet has grown far beyond the 1464 predictions that were implied by the original requirements. 1466 Unfortunately, we will only know if we have succeeded in this goal if 1467 the FDR system survives beyond its design lifetime without serious 1468 massaging. Failure will be much easier to spot! 1470 3.2.3.4. Alternative Forwarding Mechanisms 1472 With the advent of circuit-based technologies (e.g., MPLS [RFC3031] 1473 and GMPLS [RFC3471]) managed by IP routers there are forwarding 1474 mechanisms other than the datagram service that need to be supported 1475 by the routing architecture. 1477 An explicit goal of this architecture is to add support for 1478 forwarding mechanisms other then the current hop-by-hop datagram 1479 forwarding service driven by globally unique IP addresses. 1481 3.2.3.5. Separation of Topology Map from Connectivity Service 1483 It is envisioned that an organization can support multiple services 1484 within a single network. These services can, for example, be of 1485 different quality, of different connectivity type, or of different 1486 protocols (e.g., IPv4 and IPv6). For all these services there may be 1487 common domain topology, even though the policies controlling the 1488 routing of information might differ from service to service. Thus, a 1489 goal with this architecture is to support separation between creation 1490 of a domain (or organization) topology map and service creation. 1492 3.2.3.6. Separation Between Routing and Forwarding 1494 The architecture of a router is composed of two main separable parts, 1495 control and forwarding. These components, while inter-dependent, 1496 perform functions that are largely independent of each other. 1497 Control (routing, signaling, and management) is typically done in 1498 software while forwarding typically is done with specialized ASICs or 1499 network processors. 1501 The nature of an IP-based network today is that control and data 1502 protocols share the same network and forwarding regime. This may not 1503 always be the case in future networks, and we should be careful to 1504 avoid building in this sharing as an assumption in the FDR. 1506 A goal of this architecture is to support full separation of control 1507 and forwarding, and to consider what additional concerns might be 1508 properly considered separately (e.g., adjacency management). 1510 3.2.3.7. Different Routing Paradigms in Different Areas of the Same 1511 Network 1513 A number of routing paradigms have been used or researched, in 1514 addition to the conventional shortest path by hop count paradigm that 1515 is the current mainstay of the Internet. In particular, differences 1516 in underlying transport networks may mean that other kinds of routing 1517 are more relevant, and the perceived need for traffic engineering 1518 will certainly alter the routing chosen in various domains. 1520 Explicitly, one of these routing paradigms should be the current 1521 routing paradigm, so that the new paradigms will inter-operate in a 1522 backward-compatible way with today's system. This will facilitate a 1523 migration strategy that avoids flag days. 1525 3.2.3.8. Protection Against Denial of Service and Other Security 1526 Attacks 1528 Currently, existence of a route to a destination effectively implies 1529 that anybody who can get a packet onto the network is entitled to use 1530 that route. Whilst there are limitations to this generalization, 1531 this is a clear invitation to denial of service attacks. A goal of 1532 the FDR system should be to allow traffic to be specifically linked 1533 to whole or partial routes so that a destination or link resources 1534 can be protected from unauthorized use. 1536 Editors' note: When sections like this one and the previous ones 1537 on quality differentiation were written, the idea of separating 1538 traffic for security or quality was considered an unqualified 1539 advantage. Today, however, in the midst of active discussions on 1540 Network Neutrality, it is clear that such issues have a crucial 1541 policy component that also needs to be understood. These, and 1542 other similar issues are open to further research. 1544 3.2.3.9. Provable Convergence with Verifiable Policy Interaction 1546 It has been shown both analytically by Griffin et al (see 1547 [Griffin99]) and practically (see [RFC3345]) that BGP will not 1548 converge stably or is only meta-stable (i.e., will not re-converge in 1549 the face of a single failure) when certain types of policy constraint 1550 are applied to categories of network topology. The addition of 1551 policy to the basic distance vector algorithm invalidates the proofs 1552 of convergence that could be applied to a policy free implementation. 1554 It has also been argued that global convergence may no longer be a 1555 necessary goal and that local convergence may be all that is 1556 required. 1558 A goal of the FDR should be to achieve provable convergence of the 1559 protocols used which may involve constraining the topologies and 1560 domains subject to convergence. This will also require vetting the 1561 policies imposed to ensure that they are compatible across domain 1562 boundaries and result in a consistent policy set. 1564 Editors' note: This requirement is very optimistic in that it 1565 implies that it is possible to get operators to cooperate even it 1566 is seen by them to be against their business practices. Though 1567 perhaps Utopian, this is a good goal. 1569 3.2.3.10. Robustness Despite Errors and Failures 1571 From time to time in the history of the Internet there have been 1572 occurrences where mis-configured routers have destroyed global 1573 connectivity. 1575 A goal of the FDR is to be more robust to configuration errors and 1576 failures. This should probably involve ensuring that the effects of 1577 misconfiguration and failure can be confined to some suitable 1578 locality of the failure or misconfiguration. 1580 3.2.3.11. Simplicity in Management 1582 The policy work ([rap-charter02], [snmpconf-charter02] and 1583 [policy-charter02] ) that has been done at IETF provides an 1584 architecture that standardizes and simplifies management of QoS. 1585 This kind of simplicity is needed in a Future Domain Routing 1586 architecture and its protocols. 1588 A goal of this architecture is to make configuration and management 1589 of inter-domain routing as simple as possible. 1591 Editors' Note: Snmpconf and rap are the hopes of the past. Today 1592 configuration and policy hope is focused on netconf 1593 [netconf-charter]. 1595 3.2.3.12. The Legacy of RFC1126 1597 RFC1126 outlined a set of requirements that were used to guide the 1598 development of BGP. While the network has changed in the years since 1599 1989, many of the same requirements remain. A future domain routing 1600 solution has to support, as its base requirement, the level of 1601 function that is available today. A detailed discussion of RFC1126 1602 and its requirements can be found in [I-D.irtf-routing-history]. 1603 Those requirements, while specifically spelled out in that document, 1604 are subsumed by the requirements in this document. 1606 3.3. High Level User Requirements 1608 This section considers the requirements imposed by the target 1609 audience of the FDR both in terms of organizations that might own 1610 networks that would use FDR, and the human users who will have to 1611 interact with the FDR. 1613 3.3.1. Organisational Users 1615 The organizations that own networks connected to the Internet have 1616 become much more diverse since RFC1126 [RFC1126] was published. In 1617 particular, major parts of the network are now owned by commercial 1618 service provider organizations in the business of making profits from 1619 carrying data traffic. 1621 3.3.1.1. Commercial Service providers 1623 The routing system must take into account the commercial service 1624 provider's need for secrecy and security, as well as allowing them to 1625 organize their business as flexibly as possible. 1627 Service providers will often wish to conceal the details of the 1628 network from other connected networks. So far as is possible, the 1629 routing system should not require the service providers to expose 1630 more details of the topology and capability of their networks than is 1631 strictly necessary. 1633 Many service providers will offer contracts to their customers in the 1634 form of Service Level Agreements (SLAs). The routing system must 1635 allow the providers to support these SLAs through traffic engineering 1636 and load balancing as well as multi-homing, providing the degree of 1637 resilience and robustness that is needed. 1639 Service providers can be categorized as: 1641 - Global Service Providers (GSPs) whose networks have a global 1642 reach. GSPs may, and usually will, wish to constrain traffic 1643 between their customers to run entirely on their networks. GSPs 1644 will interchange traffic at multiple peering points with other 1645 GSPs, and they will need extensive policy-based controls to 1646 control the interchange of traffic. Peering may be through the 1647 use of dedicated private lines between the partners or, 1648 increasingly, through Internet Exchange Points. 1650 - National, or regional, Service Providers (NSPs) that are similar 1651 to GSPs but typically cover one country. NSPs may operate as a 1652 federation that provides similar reach to a GSP and may wish to be 1653 able to steer traffic preferentially to other federation members 1654 to achieve global reach. 1656 - Local Internet Service Providers (ISPs) operate regionally. They 1657 will typically purchase transit capacity from NSPs or GSPs to 1658 provide global connectivity, but they may also peer with 1659 neighbouring, and sometimes distant, ISPs. 1661 The routing system should be sufficiently flexible to accommodate the 1662 continually changing business relationships of the providers and the 1663 various levels of trustworthiness that they apply to customers and 1664 partners. 1666 Service providers will need to be involved in accounting for Internet 1667 usage and monitoring the traffic. They may be involved in government 1668 action to tax the usage of the Internet, enforce social mores and 1669 intellectual property rules, or apply surveillance to the traffic to 1670 detect or prevent crime. 1672 3.3.1.2. Enterprises 1674 The leaves of the network domain graph are in many cases networks 1675 supporting a single enterprise. Such networks cover an enormous 1676 range of complexity. Some multi-national companies own networks that 1677 rival the complexity and reach of a GSP, whereas many fall into the 1678 Small Office-Home Office (SOHO) category. The routing system should 1679 allow simple and robust configuration and operation for the SOHO 1680 category, while effectively supporting the larger enterprise. 1682 Enterprises are particularly likely to lack the capability to 1683 configure and manage a complex routing system, and every effort 1684 should be made to provide simple configuration and operation for such 1685 networks. 1687 Enterprises will also need to be able to change their service 1688 provider with ease. While this is predominantly a naming and 1689 addressing issue, the routing system must be able to support seamless 1690 changeover, for example, if the changeover requires a change of 1691 address prefix, the routing system must be able to cope with a period 1692 when both sets of addresses are in use. 1694 Enterprises will wish to be able to multi-home to one or more 1695 providers as one possible means of enhancing the resilience of their 1696 network. 1698 Enterprises will also frequently need to control the trust that they 1699 place both in workers and external connections through firewalls and 1700 similar mid-boxes placed at their external connections. 1702 3.3.1.3. Domestic Networks 1704 Increasingly domestic, i.e., non-business home, networks are likely 1705 to be 'always on' and will resemble SOHO enterprises networks with no 1706 special requirements on the routing system. 1708 The routing system must also continue to support dial-up users. 1710 3.3.1.4. Internet Exchange Points 1712 Peering of service providers, academic networks, and larger 1713 enterprises is increasingly happening at specific Internet Exchange 1714 Points where many networks are linked together in a relatively small 1715 physical area. The resources of the exchange may be owned by a 1716 trusted third party or owned jointly by the connecting networks. The 1717 routing systems should support such exchange points without requiring 1718 the exchange point to either operate as a superior entity with every 1719 connected network logically inferior to it or by requiring the 1720 exchange point to be a member of one (or all) connected networks. 1721 The connecting networks have to delegate a certain amount of trust to 1722 the exchange point operator. 1724 3.3.1.5. Content Providers 1726 Content providers are at one level a special class of enterprise, but 1727 the desire to deliver content efficiently means that a content 1728 provider may provide multiple replicated origin servers or caches 1729 across a network. These may also be provided by a separate content 1730 delivery service. The routing system should facilitate delivering 1731 content from the most efficient location. 1733 3.3.2. Individual Users 1735 This section covers the most important human users of the FDR and 1736 their expected interactions with the system. 1738 3.3.2.1. All End Users 1740 The routing system must continue to deliver the current global 1741 connectivity service (i.e., any unique address to any other unique 1742 address, subject to policy constraints) that has always been the 1743 basic aim of the Internet. 1745 End user applications should be able to request, or have requested on 1746 their behalf by agents and policy mechanisms, end-to-end 1747 communication services with QoS characteristics different from the 1748 best-effort service that is the foundation of today's Internet. It 1749 should be possible to request both a single service channel and a 1750 bundle of service channels delivered as a single entity. 1752 3.3.2.2. Network Planners 1754 The routing system should allow network planners to plan and 1755 implement a network that can be proved to be stable and will meet 1756 their traffic engineering requirements. 1758 3.3.2.3. Network Operators 1760 The routing system should, so far as is possible, be simple to 1761 configure, operate and troubleshoot, behave in a predictable and 1762 stable fashion, and deliver appropriate statistics and events to 1763 allow the network to be managed and upgraded in an efficient and 1764 timely fashion. 1766 3.3.2.4. Mobile End Users 1768 The routing system must support mobile end users. It is clear that 1769 mobility is becoming a predominant mode for network access. 1771 3.4. Mandated Constraints 1773 While many of the requirements to which the protocol must respond are 1774 technical, some aren't. These mandated constraints are those that 1775 are determined by conditions of the world around us. Understanding 1776 these requirements requires an analysis of the world in which these 1777 systems will be deployed. The constraints include those that are 1778 determined by: 1780 - environmental factors, 1782 - geography, 1784 - political boundaries and considerations, and 1786 - technological factors such as the prevalence of different levels 1787 of technology in the developed world compared to those in the 1788 developing or undeveloped world. 1790 3.4.1. The Federated Environment 1792 The graph of the Internet network, with routers and other control 1793 boxes as the nodes and communication links as the edges, is today 1794 partitioned administratively into a large number of disjoint domains. 1796 A common administration may have responsibility for one or more 1797 domains that may or may not be adjacent in the graph. 1799 Commercial and policy constraints affecting the routing system will 1800 typically be exercised at the boundaries of these domains where 1801 traffic is exchanged between the domains. 1803 The perceived need for commercial confidentiality will seek to 1804 minimise the control information transferred across these boundaries, 1805 leading to requirements for aggregated information, abstracted maps 1806 of connectivity exported from domains, and mistrust of supplied 1807 information. 1809 The perceived desire for anonymity may require the use of zero- 1810 knowledge security protocols to allow users to access resources 1811 without exposing their identity. 1813 The requirements should provide the ability for groups of peering 1814 domains to be treated as a complex domain. These complex domains 1815 could have a common administrative policy. 1817 3.4.2. Working with Different Sorts of Networks 1819 The diverse Layer 2 networks over which the layer 3 routing system is 1820 implemented have typically been operated totally independently from 1821 the layer 3 network and often with their own routing mechanisms. 1822 Consideration needs to be given to the desirable degree and nature of 1823 interchange of information between the layers. In particular, the 1824 need for guaranteed robustness through diverse routing layers implies 1825 knowledge of the underlying networks. 1827 Mobile access networks may also impose extra requirements on Layer 3 1828 routing. 1830 3.4.3. Delivering Resilient Service 1832 The routing system operates at Layer 3 in the network. To achieve 1833 robustness and resilience at this layer requires that, where multiple 1834 diverse routes are employed as part of delivering the resilience, the 1835 routing system at Layer 3 needs to be assured that the Layer 2 and 1836 lower routes are really diverse. The 'diamond problem' is the 1837 simplest form of this problem - a layer 3 provider attempting to 1838 provide diversity buys layer 2 services from two separate providers 1839 who in turn buy layer 1 services from the same provider: 1841 Layer 3 service 1842 / \ 1843 / \ 1844 Layer 2 Layer 2 1845 Provider A Provider B 1846 \ / 1847 \ / 1848 Layer 1 Provider 1850 Now when the backhoe cuts the trench, the Layer 3 provider has no 1851 resilience unless he had taken special steps to verify that the 1852 trench wasn't common. The routing system should facilitate avoidance 1853 of this kind of trap. 1855 Some work is going on to understand the sort of problems that stem 1856 from this requirement, such as the work on Shared Risk Link Groups 1857 [I-D.many-inference-srlg]. Unfortunately, the full generality of the 1858 problem requires diversity be maintained over time between an 1859 arbitrarily large set of mutually distrustful providers. For some 1860 cases, it may be sufficient for diversity to be checked at 1861 provisioning or route instantiation time, but this remains a hard 1862 problem requiring research work. 1864 3.4.4. When Will the New Solution Be Required? 1866 There is a full range of opinion on this subject. An informal survey 1867 indicates that the range varies from 2 years to 6 years. And while 1868 there are those, possibly outliers, who think there is no need for a 1869 new routing architecture as well as those who think a new 1870 architecture was needed years ago, the median seems to lie at around 1871 4 years. As in all projections of the future, this is not provable 1872 at this time. 1874 Editors' note: The paragraph above was written in 2002, yet could 1875 be written without change in 2006. As with many technical 1876 predictions and schedules, the horizon has remained fixed through 1877 this interval. 1879 3.5. Assumptions 1881 In projecting the requirements for the Future Domain Routing a number 1882 of assumptions have been made. The requirements set out should be 1883 consistent with these assumptions, but there are doubtless a number 1884 of other assumptions that are not explicitly articulated here: 1886 1. The number of hosts today is somewhere in the area of 100 1887 million. With dial-in, NATs and the universal deployment of 1888 IPv6, this is likely to become up to 500 million users (see 1889 [CIDR]). In a number of years, with wireless accesses and 1890 different appliances attaching to the Internet, we are likely to 1891 see a couple of billion (10^9) 'users' on the Internet. The 1892 number of globally addressable hosts is very much dependent on 1893 how common NATs will be in the future. 1895 2. NATs, firewalls, and other middle-boxes exist, and we cannot 1896 assume that they will cease being a presence in the networks. 1898 3. The number of operators in the Internet will probably not grow 1899 very much, as there is a likelihood that operators will tend to 1900 merge. However, as Internet-connectivity expands to new 1901 countries, new operators will emerge and then merge again. 1903 4. At the beginning of 2002, there are around 12000 registered 1904 AS's. With current use of AS's (for e.g., multi-homing) the 1905 number of AS's could be expected to grow to 25000 in about 10 1906 years.[Broido02] This is down from a previously reported growth 1907 rate of 51% per year.[RFC3221]. Future growth rates are 1908 difficult to predict. 1910 Editors' Note: In the routing report table of August 2006, 1911 the total number of AS's present in the Internet Routing 1912 Table was 23000. In 4 years this is substantial progress on 1913 the prediction of 25000 AS's. Also, there are significantly 1914 more AS's registered then are visibly active, i.e., in excess 1915 of 42000 in mid-2006. It is possible, however, that many are 1916 being used internally. 1918 5. In contrast to the number of operators, the number of domains is 1919 likely to grow significantly. Today, each operator has 1920 different domains within an AS, but this also shows in SLAs and 1921 policies internal to the operator. Making this globally visible 1922 would create a number of domains 10-100 times the number of 1923 AS's, i.e., between 100,000 and 1,000,000. 1925 6. With more and more capacity at the edge of the network the IP 1926 network will expand. Today there are operators with several 1927 thousands of routers, but this is likely to be increased. Some 1928 domains will probably contain tens of thousands of routers. 1930 7. The speed of connections in the (fixed) access will technically 1931 be (almost) unconstrained. However, the cost for the links will 1932 not be negligible so that the apparent speed will be effectively 1933 bounded. Within a number of years some will have multi-gigabit 1934 speed in the access. 1936 8. At the same time, the bandwidth of wireless access still has a 1937 strict upper-bound. Within the foreseeable future each user 1938 will have only a tiny amount of resources available compared to 1939 fixed accesses (10kbps to 2Mbps for UMTS with only a few 1940 achieving the higher figure as the bandwidth is shared between 1941 the active users in a cell and only small cells can actually 1942 reach this speed, but 11Mbps or more for wireless LAN 1943 connections). There may also be requirements for effective use 1944 of bandwidth as low as 2.4 Kbps or lower, in some applications. 1946 9. Assumptions 7 and 8 taken together suggest a minimum span of 1947 bandwidth between 2.4 kbps to 10 Gbps. 1949 10. The speed in the backbone has grown rapidly, and there is no 1950 evidence that the growth will stop in the coming years. 1951 Terabit-speed is likely to be the minimum backbone speed in a 1952 couple of years. The range of bandwidths that need to be 1953 represented will require consideration on how to represent the 1954 values in the protocols. 1956 11. There have been discussions as to whether Moore's law will 1957 continue to hold for processor speed. If Moore's law does not 1958 hold, then communication circuits might play a more important 1959 role in the future. Also, optical routing is based on circuit 1960 technology, which is the main reason for taking 'circuits' into 1961 account when designing an FDR. 1963 12. However, the datagram model still remains the fundamental model 1964 for the Internet. 1966 13. The number of peering points in the network is likely to grow, 1967 as multi-homing becomes important. Also traffic will become 1968 more locally distributed, which will drive the demand for local 1969 peering. 1971 Editors' note: On the other hand peer to peer networking may 1972 shift the balance in demand for local peering. 1974 14. The FDR will achieve the same degree of ubiquity as the current 1975 Internet and IP routing. 1977 3.6. Functional Requirements 1979 This section includes a detailed discussion of new requirements for a 1980 Future Domain Routing architecture. The nth requirement carries the 1981 label "R(n)". As discussed in section 3.2.3.12 a new architecture 1982 must build upon the requirements of the past routing framework and 1983 must not reduce the functionality of the network. A discussion and 1984 analysis of the RFC1126 requirements can be found in 1985 [I-D.irtf-routing-history]. 1987 3.6.1. Topology 1989 3.6.1.1. Routers Should Be Able To Learn and To Exploit the Domain 1990 Topology 1992 R(1) Routers must be able to acquire and hold sufficient information 1993 on the underlying topology of the domain to allow the 1994 establishment of routes on that topology. 1996 R(2) Routers must have the ability to control the establishment of 1997 routes on the underlying topology. 1999 R(3) Routers must be able, where appropriate, to control Sub-IP 2000 mechanisms to support the establishment of routes. 2002 The OSI Inter-Domain Routing Protocol (IDRP)[ISO10747] allowed a 2003 collection of topologically related domains to be replaced by an 2004 aggregate domain object, in a similar way to the Nimrod[Chiappa02] 2005 domain hierarchies. This allowed a route to be more compactly 2006 represented by a single collection instead of a sequence of 2007 individual domains. 2009 R(4) Routers must, where appropriate, be able to construct 2010 abstractions of the topology that represent an aggregation of 2011 the topological features of some area of the topology. 2013 3.6.1.2. The Same Topology Information Should Support Different Path 2014 Selection Ideas 2016 The same topology information needs to provide the more flexible 2017 spectrum of path selection methods that we might expect to find in a 2018 future Internet, including distributed techniques such as hop-by-hop, 2019 shortest path, local optimization constraint-based, class of service, 2020 source address routing, and destination address routing, as well as 2021 the centralized, global optimization constraint-based 'traffic 2022 engineering' type. Allowing different path selection techniques will 2023 produce a much more predictable and comprehensible result than the 2024 'clever tricks' that are currently needed to achieve the same 2025 results. Traffic engineering functions need to be combined. 2027 R(5) Routers must be capable of supporting a small number of 2028 different path selection algorithms 2030 3.6.1.3. Separation of the Routing Information Topology from the Data 2031 transport topology. 2033 R(6) The controlling network may be logically separate from the 2034 controlled network. 2036 The two functional 'planes' may physically reside in the same nodes 2037 and share the same links, but this is not the only possibility, and 2038 other options may sometimes be necessary. An example is a pure 2039 circuit switch (that cannot see individual IP packets) combined with 2040 an external controller. Another example may be multiple links 2041 between two routers, where all the links are used for data forwarding 2042 but only one is used for carrying the routing session. 2044 3.6.2. Distribution 2046 3.6.2.1. Distribution Mechanisms 2048 R(7) Relevant changes in the state of the network, including 2049 modifications to the topology and changes in the values of 2050 dynamic capabilities, must be distributed to every entity in 2051 the network that needs them, in a reliable and trusted way, at 2052 the earliest appropriate time after the changes have occurred. 2054 R(8) Information must not be distributed outside areas where it is 2055 needed, or believed to be needed, for the operation of the 2056 routing system. 2058 R(9) Information must be distributed in such a way that it minimizes 2059 the load on the network, consistent with the required response 2060 time of the network to changes. 2062 3.6.2.2. Path Advertisement 2064 R(10) The router must be able to acquire and store additional static 2065 and dynamic information that relates to the capabilities of 2066 the topology and its component nodes and links and that can 2067 subsequently be used by path selection methods. 2069 The inter-domain routing system must be able to advertise more kinds 2070 of information than just connectivity and domain paths. 2072 R(11) The Routing System must support service specifications, e.g., 2073 the Service Level Specifications (SLSs) developed by the 2074 Differentiated Services working group [RFC3260]. 2076 Careful attention should be paid to ensuring that the distribution of 2077 additional information with path advertisements remains scalable as 2078 domains and the Internet get larger, more numerous, and more 2079 diversified. 2081 R(12) The distribution mechanism used for distributing network state 2082 information must be scalable with respect to the expected size 2083 of domains and the volume and rate of change of dynamic state 2084 that can be expected. 2086 The combination of R(9) and R(12) may result in a compromise between 2087 the responsiveness of the network to change and the overhead of 2088 distributing change notifications. Attempts to respond to very rapid 2089 changes may damage the stability of the routing system. 2091 Possible examples of additional capability information that might be 2092 carried include: 2094 - QoS information 2096 To allow an ISP to sell predictable end-to-end QoS service to any 2097 destination, the routing system should have information about the 2098 end-to-end QoS. This means that: 2100 R(13) The routing system must be able to support different paths for 2101 different services. 2103 R(14) The routing system must be able to forward traffic on the path 2104 appropriate for the service selected for the traffic, either 2105 according to an explicit marking in each packet (e.g., MPLS 2106 labels, DiffServ PHB's or DSCP values) or implicitly (e.g., 2107 the physical or logical port on which the traffic arrives). 2109 R(15) The routing system should also be able to carry information 2110 about the expected (or actually, promised) characteristics of 2111 the entire path and the price for the service. 2113 (If such information is exchanged at all between network 2114 operators today, it is through bilateral management interfaces, 2115 and not through the routing protocols.) 2116 This would allow for the operator to optimise the choice of path 2117 based on a price/performance trade-off. 2119 In addition to providing dynamic QoS information the system should 2120 be able to use static class-of-service information. 2122 - Security information 2124 Security characteristics of other domains referred to by 2125 advertisements can allow the routing entity to make routing 2126 decisions based on political concerns. The information itself is 2127 assumed to be secure so that it can be trusted. 2129 - Usage and cost information 2131 Usage and cost information can be used for billing and traffic 2132 engineering. In order to support cost-based routing policies for 2133 customers (i.e., peer ISPs), information such as "traffic on this 2134 link or path costs XXX per Gigabyte" needs to be advertised, so 2135 that the customer can choose a more or a less expensive route. 2137 - Monitored performance 2139 Performance information such as delay and drop frequency can be 2140 carried. (This may only be suitable inside a domain because of 2141 trust considerations). This should support at least the kind of 2142 delay bound contractual terms that are currently being offered by 2143 service providers. Note that these values refer to the outcome of 2144 carrying bits on the path, whereas the QoS information refers to 2145 the proposed behaviour that results in this outcome. 2147 - Multicast information 2149 R(16) The routing system must provide information needed to create 2150 multicast distribution trees. This information must be 2151 provided for one-to-many distribution trees and should be 2152 provided for many-to-many distribution trees. 2154 The actual construction of distribution trees is not necessarily 2155 done by the routing system. 2157 3.6.2.3. Stability of Routing Information 2159 R(17) The new network architecture must be stable without needing 2160 global convergence, i.e., convergence is a local property. 2162 The degree to which this is possible and the definition of "local" 2163 remain research topics. Restricting the requirement for convergence 2164 to localities will have an effect on all of the other requirements in 2165 this section. 2167 R(18) The distribution and the rate of distribution of changes must 2168 not affect the stability of the routing information. For 2169 example, commencing redistribution of a change before the 2170 previous one has settled must not cause instability. 2172 3.6.2.3.1. Avoiding Routing Oscillations 2174 R(19) The routing system must minimize oscillations in route 2175 advertisements. 2177 3.6.2.3.2. Providing Loop-free Routing and Forwarding 2179 In line with the separation of routing and forwarding concerns: 2181 R(20) The distribution of routing information must be, so far as is 2182 possible, loop-free. 2184 R(21) The forwarding information created from this routing 2185 information must seek to minimize persistent loops in the data 2186 forwarding paths. 2188 It is accepted that transient loops may occur during convergence of 2189 the protocol and that there are trade-offs between loop avoidance and 2190 global scalability. 2192 3.6.2.3.3. Detection, Notification and Repair of Failures 2194 R(22) The routing system must provide means for detecting failures 2195 of node equipment or communication links. 2197 R(23) The routing system should be able to coordinate failure 2198 indications from layer 3 mechanisms, from nodal mechanisms 2199 built into the routing system, and from lower-layer mechanisms 2200 that propagate up to Layer 3 in order to determine the root 2201 cause of the failure. This will allow the routing system to 2202 react correctly to the failure by activating appropriate 2203 mitigation and repair mechanisms if required, whilst ensuring 2204 that it does not react if lower layer repair mechanisms are 2205 able to repair or mitigate the fault. 2207 Most layer 3 routing protocols have utilized keepalives or 'hello' 2208 protocols as a means of detecting failures at Layer 3. The keepalive 2209 mechanisms are often complemented by analog mechanisms (e.g., laser 2210 light detection) and hardware mechanisms (e.g., hardware/software 2211 watchdogs) that are built into routing nodes and communication links. 2212 Great care must be taken to make best possible use of the various 2213 failure repair methods available whilst ensuring that only one repair 2214 mechanism at a time is allowed to repair any given fault. 2216 Interactions between, for example, fast reroute mechanisms at layer 3 2217 and SONET/SDH repair at Layer 1 are highly undesirable and are likely 2218 to cause problems in the network. 2220 R(24) Where a network topology and routing system contains multiple 2221 fault repair mechanisms, the responses of these systems to a 2222 detected failure should be coordinated so that the fault is 2223 repaired by the most appropriate means, and no extra repairs 2224 are initiated. 2226 R(25) Where specialized packet exchange mechanisms (e.g., layer 3 2227 keepalive or 'hello' protocol mechanisms) are used to detect 2228 failures, the routing system must allow the configuration of 2229 the rate of transmission of these keepalives. This must 2230 include the capability to turn them off altogether for links 2231 that are deliberately broken when no real user or control 2232 traffic is present (e.g., ISDN links). 2234 This will allow the operator to compromise between the speed of 2235 failure detection and the proportion of link bandwidth dedicated to 2236 failure detection. 2238 3.6.3. Addressing 2240 3.6.3.1. Support Mix of IPv4, IPv6 and Other Types of Addresses 2242 R(26) The routing system must support a mix of different kinds of 2243 addresses. 2245 This mix will include at least IPv4 and IPv6 addresses, and 2246 preferably various types of non-IP addresses too. For instance 2247 networks like SDH/SONET and WDM may prefer to use non-IP addresses. 2248 It may also be necessary to support multiple sets of 'private' (e.g., 2249 RFC1918) addresses when dealing with multiple customer VPNs. 2251 R(27) The routing system should support the use of a single topology 2252 representation to generate routing and forwarding tables for 2253 multiple address families on the same network. 2255 This capability would minimise the protocol overhead when exchanging 2256 routes. 2258 3.6.3.2. Support for Domain Renumbering/Readdressing 2259 R(28) If a domain is subject to address reassignment that would 2260 cause forwarding interruption, then the routing system should 2261 support readdressing (e.g., when a new prefix is given to an 2262 old network, and the change is known in advance) by 2263 maintaining routing during the changeover period 2264 [RFC2071],[RFC2072]. 2266 3.6.3.3. Multicast and Anycast 2268 R(29) The routing system must support multicast addressing, both 2269 within a domain and across multiple domains. 2271 R(30) The routing system should support anycast addressing within a 2272 domain. The routing system may support anycast addressing 2273 across domains. 2275 An open question is whether it is possible or useful to support 2276 anycast addressing between cooperating domains. 2278 3.6.3.4. Address Scoping 2280 R(31) The routing system must support scoping of unicast addresses, 2281 and it should support scoping of multicast and anycast address 2282 types. 2284 The unicast address scoping that is being designed for IPv6 does not 2285 seem to cause any special problems for routing. IPv6 inter-domain 2286 routing handles only IPv6 global addresses, while intra-domain 2287 routing also needs to be aware of the scope of private addresses. 2289 Editors' note: the original reference was to site-local addresses 2290 but these have been deprecated by the IETF. Link-local addresses 2291 are never routed at all. 2293 More study may be needed to identify the requirements and solutions 2294 for scoping in a more general sense and for scoping of multicast and 2295 anycast addresses. 2297 3.6.3.5. Mobility Support 2299 R(32) The routing system must support system mobility. The term 2300 "system" includes anything from an end system to an entire 2301 domain. 2303 We observe that the existing solutions based on re-numbering and/or 2304 tunneling are designed to work with the current routing, so they do 2305 not add any new requirements to future routing. But the requirement 2306 is general, and future solutions may not be restricted to the ones we 2307 have today. 2309 3.6.4. Statistics Support 2311 R(33) Both the routing and forwarding parts of the routing system 2312 must maintain statistical information about the performance of 2313 their functions. 2315 3.6.5. Management Requirements 2317 While the tools of management are outside the scope of routing, the 2318 mechanisms to support the routing architecture and protocols are 2319 within scope. 2321 R(34) Mechanisms to support Operational, Administrative and 2322 Management control of the routing architecture and protocols 2323 must be designed into the original fabric of the architecture. 2325 3.6.5.1. Simple Policy Management 2327 The basic aims of this specification are: 2329 - to require less manual configuration than today and 2331 - to satisfy the requirements for both easy handling and maximum 2332 control. That is: 2334 - All the information should be available, 2336 - but should not be visible except for when necessary. 2338 - Policies themselves should be advertised and not only the 2339 result of policy, and 2341 - policy conflict resolution must be provided. 2343 R(35) The routing system must provide management of the system by 2344 means of policies. For example, policies that can be 2345 expressed in terms of the business and services implemented on 2346 the network and reflect the operation of the network in terms 2347 of the services affected. 2349 Editors' note: This requirement is optimistic in that it 2350 implies that it is possible to get operators to 2351 cooperate even it is seen by them to be against their 2352 business practices. 2354 R(36) The distribution of policies must be amenable to scoping to 2355 protect proprietary policies that are not relevant beyond the 2356 local set of domains. 2358 3.6.5.2. Startup and Maintenance of Routers 2360 A major problem in today's networks is the need to perform initial 2361 configuration on routers from a local interface before a remote 2362 management system can take over. It is not clear that this imposes 2363 any requirements on the routing architecture beyond what is needed 2364 for a ZeroConf host. 2366 Similarly, maintenance and upgrade of routers can cause major 2367 disruptions to the network routing because the routing system and 2368 management of routers is not organized to minimize such disruption. 2369 Some improvements have been made, such as graceful restart mechanisms 2370 in protocols, but more needs to be done. 2372 R(37) The routing system and routers should provide mechanisms that 2373 minimize the disruption to the network caused by maintenance 2374 and upgrades of software and hardware. This requirement 2375 recognizes that some of the capabilities needed are outside 2376 the scope of the routing architecture (e.g., minimum impact 2377 software upgrade). 2379 3.6.6. Provability 2381 R(38) The routing system and its component protocols must be 2382 demonstrated to be locally convergent under the permitted 2383 range of parameter settings and policy options that the 2384 operator(s) can select. 2386 There are various methods for demonstration and proof that include, 2387 but are not limited to: mathematical proof, heuristic, and pattern 2388 recognition. No requirement is made on the method used for 2389 demonstrating local convergence properties. 2391 R(39) Routing protocols employed by the routing system and the 2392 overall routing system should be resistant to bad routing 2393 policy decisions made by operators. 2395 Tools are needed to check compatibility of routing policies. While 2396 these tools are not part of the routing architecture, the mechanisms 2397 to support such tools are. 2399 Routing policies are compatible if their interaction does not cause 2400 instability. A domain or group of domains in a system is defined as 2401 being convergent, either locally or globally, if and only if, after 2402 an exchange of routing information, routing tables reach a stable 2403 state that does not change until the routing policies or the topology 2404 changes again. 2406 To achieve the above-mentioned goals: 2408 R(40) The routing system must provide a mechanism to publish and 2409 communicate policies so that operational coordination and 2410 fault isolation are possible. 2412 Tools are required that verify the stability characteristics of the 2413 routing system in specified parts of the Internet. The tools should 2414 be efficient (fast) and have a broad scope of operation (check large 2415 portions of Internet). While these tools are not part of the 2416 architecture, developing them is in the interest of the architecture 2417 and should be defined as a Routing Research Group activity while 2418 research on the architecture is in progress. 2420 Tools analyzing routing policies can be applied statically or 2421 (preferably) dynamically. Dynamic solution requires tools that can 2422 be used for run time checking for oscillations that arise from policy 2423 conflicts. Research is needed to find an efficient solution to the 2424 dynamic checking of oscillations. 2426 3.6.7. Traffic Engineering 2428 The ability to do traffic engineering and to get the feedback from 2429 the network to enable traffic engineering should be included in the 2430 future domain architecture. Though traffic engineering has many 2431 definitions, it is, at base, another alternative or extension for the 2432 path selection mechanisms of the routing system. No fundamental 2433 changes to the requirements are needed, but the iterative processes 2434 involved in traffic engineering may require some additional 2435 capabilities and state in the network. 2437 Traffic engineering typically involves a combination of off-line 2438 network planning and administrative control functions in which the 2439 expected and measured traffic flows are examined, resulting in 2440 changes to static configurations and policies in the routing system. 2441 During operations, these configurations control the actual flow of 2442 traffic and affect the dynamic path selection mechanisms; the results 2443 are measured and fed back into further rounds of network planning. 2445 3.6.7.1. Support for, and Provision of, Traffic Engineering Tools 2447 At present there is an almost total lack of effective traffic 2448 engineering tools, whether in real time for network control or off- 2449 line for network planning. The routing system should encourage the 2450 provision of such tools. 2452 R(41) The routing system must generate statistical and accounting 2453 information in such a way that traffic engineering and network 2454 planning tools can be used in both real time and off-line 2455 planning and management. 2457 3.6.7.2. Support of Multiple Parallel Paths 2459 R(42) The routing system must support the controlled distribution 2460 over multiple links or paths of traffic toward the same 2461 destination. This applies to domains with two or more 2462 connections to the same neighbor domain, and to domains with 2463 connections to more than one neighbor domain. The paths need 2464 not have the same metric. 2466 R(43) The routing system must support forwarding over multiple 2467 parallel paths when available. This support should extend to 2468 cases where the offered traffic is known to exceed the 2469 available capacity of a single link, and to the cases where 2470 load is to be shared over paths for cost or resiliency 2471 reasons. 2473 R(44) Where traffic is forwarded over multiple parallel paths, the 2474 routing system must, so far as is possible, avoid reordering 2475 of packets in individual micro-flows. 2477 R(45) The routing system must have mechanisms to allow the traffic 2478 to be reallocated back onto a single path when multiple paths 2479 are not needed. 2481 3.6.7.3. Peering Support 2483 R(46) The routing system must support peer-level connectivity as 2484 well as hierarchical connections between domains. 2486 The network is becoming increasingly complex, with private peering 2487 arrangements set up between providers at every level of the hierarchy 2488 of service providers and even by certain large enterprises, in the 2489 form of dedicated extranets. 2491 R(47) The routing system must facilitate traffic engineering of peer 2492 routes so that traffic can be readily constrained to travel as 2493 the network operators desire, allowing optimal use of the 2494 available connectivity. 2496 3.6.8. Support for Middleboxes 2498 One of our assumptions is that NATs and other middle-boxes such as 2499 firewalls, web proxies and address family translators (e.g., IPv4 to 2500 IPv6) are here to stay. 2502 R(48) The routing system should work in conjunction with middle- 2503 boxes, e.g., NAT, to aid in bi-directional connectivity 2504 without compromising the additional opacity and privacy that 2505 the middle-boxes offer. 2507 This problem is closely analogous to the abstraction problem, which 2508 is already under discussion for the interchange of routing 2509 information between domains. 2511 3.7. Performance Requirements 2513 Over the past several years, the performance of the routing system 2514 has frequently been discussed. The requirements that derive from 2515 those discussions are listed below. The specific values for these 2516 performance requirements are left for further discussion. 2518 R(49) The routing system must support domains of at least N systems. 2519 A system is taken to mean either an individual router or a 2520 domain. 2522 R(50) Local convergence should occur within T units of time. 2524 R(51) The routing system must be measurably reliable. The measure 2525 of reliability remains a research question. 2527 R(52) The routing system must be locally stable to a measured 2528 degree. The degree of measurabilty remains a research issue. 2530 R(53) The routing system must be globally stable to a measured 2531 degree. The degree of measurabilty remains a research issue. 2533 R(54) The routing system should scale to an indefinitely large 2534 number of domains. 2536 There has been very little data or statistical evidence for many of 2537 the performance claims made in the past. In recent years, several 2538 efforts have been initiated to gather data and do the analyses 2539 required to make scientific assessments of performance issues and 2540 requirements. In order to complete this section of the requirements 2541 analysis, the data and analyses from these studies needs to be 2542 gathered and collated into this document. This work has been started 2543 but has yet to be completed. 2545 3.8. Backwards Compatibility (Cutover) and Maintainability 2547 This area poses a dilemma. On one hand it is an absolute requirement 2548 that: 2550 R(55) The introduction of the routing system must not require any 2551 flag days. 2553 R(56) The network currently in place must continue to run at least 2554 as well as it does now while the new network is being 2555 installed around it. 2557 However, at the same time, it is also an requirement that: 2559 R(57) The new architecture must not be limited by the restrictions 2560 that plague today's network. 2562 It has to be admitted that R(57) is not a well defined requirement, 2563 because we have not fully articulated what the restrictions might be. 2564 Some of these restrictions can be derived by reading the discussions 2565 for the positive requirements above. It would be a useful exercise 2566 to explicitly list all the restrictions and irritations that we wish 2567 to do away with. It would be further useful to determine if these 2568 restrictions can currently be removed at reasonable cost or whether 2569 we are actually condemned to live with them. 2571 Those restrictions cannot be allowed to become permanent baggage on 2572 the new architecture. If they do, the effort to create a new system 2573 will come to naught. It may, however, be necessary to live with some 2574 of them temporarily for practical reasons while providing an 2575 architecture which will eventually allow them to be removed. The 2576 last three requirements have significance not only for the transition 2577 strategy, but also for the architecture itself. They imply that it 2578 must be possible for an internet such as today's BGP-controlled 2579 network, or one of its AS's, to exist as a domain within the new FDR. 2581 3.9. Security Requirements 2583 As previously discussed, one of the major changes that has overtaken 2584 the Internet since its inception is the erosion of trust between end 2585 users making use of the net, between those users and the suppliers of 2586 services, and between the multiplicity of providers. Hence security, 2587 in all its aspects, will be much more important in the FDR. 2589 It must be possible to secure the routing communication. 2591 R(58) The communicating entities must be able to identify who sent 2592 and who received the information (authentication). 2594 R(59) The communicating entities must be able to verify that the 2595 information has not been changed on the way (integrity). 2597 Security is more important in inter-domain routing where the operator 2598 has no control over the other domains, than in intra-domain routing 2599 where all the links and the nodes are under the administration of the 2600 operator and can be expected to share a trust relationship. This 2601 property of intra-domain trust, however, should not be taken for 2602 granted: 2604 R(60) Routing communications must be secured by default, but an 2605 operator must have the option to relax this requirement within 2606 a domain where analysis indicates that other means (such as 2607 physical security) provide an acceptable alternative. 2609 R(61) The routing communication mechanism must be robust against 2610 denial-of-service attacks. 2612 R(62) It should be possible to verify that the originator of the 2613 information was authorized to generate the information. 2615 Further considerations that may impose further requirements include: 2617 - whether no one else but the intended recipient is able to access 2618 (privacy) or understand (confidentiality) the information, 2620 - whether it is possible to verify that all the information has been 2621 received and that the two parties agree on what was sent 2622 (validation and non-repudiation), 2624 - whether there is a need to separate security of routing from 2625 security of forwarding, and 2627 - whether traffic flow security is needed (i.e., whether there is 2628 value in concealing who can connect to whom, and what volumes of 2629 data are exchanged). 2631 Securing the BGP session, as done today, only secures the exchange of 2632 messages from the peering domain, not the content of the information. 2633 In other words, we can confirm that the information we got is what 2634 our neighbor really sent us, but we do not know whether this 2635 information (that originated in some remote domain) is true or not. 2637 A decision has to be made on whether to rely on chains of trust (we 2638 trust our peers who trust their peers who..), or whether we also need 2639 authentication and integrity of the information end-to-end. This 2640 information includes both routes and addresses. There has been 2641 interest in having digital signatures on originated routes as well as 2642 countersignatures by address authorities to confirm that the 2643 originator has authority to advertise the prefix. Even understanding 2644 who can confirm the authority is non-trivial, as it might be the 2645 provider who delegated the prefix (with a whole chain of authority 2646 back to ICANN) or it may be an address registry. Where a prefix 2647 delegated by a provider is being advertised through another provider 2648 as in multi-homing, both may have to be involved to confirm that the 2649 prefix may be advertised through the provider who doesn't have any 2650 interest in the prefix! 2652 R(63) The routing system must cooperate with the security policies 2653 of middle-boxes whenever possible. 2655 This is likely to involve further requirements for abstraction of 2656 information. For example, a firewall that is seeking to minimize 2657 interchange of information that could lead to a security breach. The 2658 effect of such changes on the end-to-end principle should be 2659 carefully considered as discussed in [Blumenthal01]. 2661 R(64) The routing system must be capable of complying with local 2662 legal requirements for interception of communication. 2664 3.10. Debatable Issues 2666 This section covers issues that need to be considered and resolved in 2667 deciding on a Future Domain Routing architecture. While they can't 2668 be described as requirements, they do affect the types of solution 2669 that are acceptable. The discussions included below are very open- 2670 ended. 2672 3.10.1. Network Modeling 2674 The mathematical model that underlies today's routing system uses a 2675 graph representation of the network. Hosts, routers and other 2676 processing boxes are represented by nodes and communications links by 2677 arcs. This is a topological model in that routing does not need to 2678 directly model the physical length of the links or the position of 2679 the nodes; the model can be transformed to provide a convenient 2680 picture of the network by adjusting the lengths of the arcs and the 2681 layout of the nodes. The connectivity is preserved and routing is 2682 unaffected by this transformation. 2684 The routing algorithms in traditional routing protocols utilize a 2685 small number of results from graph theory. It is only recently that 2686 additional results have been employed to support constraint-based 2687 routing for traffic engineering. 2689 The naturalness of this network model and the 'fit' of the graph 2690 theoretical methods may have tended to blind us to alternative 2691 representations and inhibited us from seeking alternative strands of 2692 theoretical thinking that might provide improved results. 2694 We should not allow this habitual behavior to stop us looking for 2695 alternative representations and algorithms; topological revolutions 2696 are possible and allowed, at least in theory. 2698 3.10.2. System Modeling 2700 The assumption that object modeling of a system is an essential first 2701 step to creating a new system is still novel in this context. 2702 Frequently the object modeling effort becomes an end in itself and 2703 does not lead to system creation. But there is a balance, and a lot 2704 that can be discovered in an ongoing effort to model a system such as 2705 the Future Domain Routing system. It is recommended that this 2706 process be included in the requirements. It should not, however, be 2707 a gating event to all other work. 2709 Some of the most important realizations will occur during the process 2710 of determining the following: 2712 - Object classification 2714 - Relationships and containment 2716 - Roles and Rules 2718 3.10.3. One, Two or Many Protocols 2720 There has been a lot of discussion of whether the FDR protocol 2721 solution should consist of one (probably new) protocol, two (intra- 2722 and inter-domain) protocols, or many protocols. While it might be 2723 best to have one protocol that handles all situations, this seems 2724 improbable. On the other hand, maintaining the 'strict' division 2725 evident in the network today between the IGP and EGP may be too 2726 restrictive an approach. Given this, and the fact that there are 2727 already many routing protocols in use, the only possible answer seems 2728 to be that the architecture should support many protocols. It 2729 remains an open issue, one for the solution, to determine if a new 2730 protocol needs to be designed in order to support the highest goals 2731 of this architecture. The expectation is that a new protocol will be 2732 needed. 2734 3.10.4. Class of Protocol 2736 If a new protocol is required to support the FDR architecture, the 2737 question remains open as to what kind of protocol this ought to be. 2738 It is our expectation that a map distribution protocol will be 2739 required to augment the current path-vector protocol and shortest 2740 path first protocols. 2742 3.10.5. Map Abstraction 2744 Assuming that a map distribution protocol, as defined in [RFC1992] is 2745 required, what are the requirements on this protocol? If every 2746 detail is advertised throughout the Internet, there will be a lot of 2747 information. Scalable solutions require abstraction. 2749 - If we summarise too much, some information will be lost on the 2750 way. 2752 - If we summarise too little, then more information than required is 2753 available, contributing to scaling limitations. 2755 - One can allow more summarisation, if there also is a mechanism to 2756 query for more details within policy limits. 2758 - The basic requirement is not that the information shall be 2759 advertised, but rather that the information shall be available to 2760 those who need it. We should not presuppose a solution where 2761 advertising is the only possible mechanism. 2763 3.10.6. Clear Identification for All Entities 2765 As in all other fields, the words used to refer to concepts and to 2766 describe operations about routing are important. Rather than 2767 describe concepts using terms that are inaccurate or rarely used in 2768 the real world of networking, it is necessary to make an effort to 2769 use the correct words. Many networking terms are used casually, and 2770 the result is a partial or incorrect understanding of the underlying 2771 concept. Entities such as nodes, interfaces, sub-networks, tunnels, 2772 and the grouping concepts such as AS's, domains, areas, and regions, 2773 need to be clearly identified and defined to avoid confusion. 2775 There is also a need to separate identifiers (what or who) from 2776 locators (where) from routes (how to reach). 2778 Editors' Note: Work was undertaken in the shim6 working group of 2779 the IETF on this sort of separation. This work needs to be taken 2780 into account in any new routing architecture. 2782 3.10.7. Robustness and Redundancy 2784 The routing association between two domains should survive even if 2785 some individual connection between two routers goes down. 2787 The "session" should operate between logical "routing entities" on 2788 each domain side, and not necessarily be bound to individual routers 2789 or addresses. Such a logical entity can be physically distributed 2790 over multiple network elements. Or it can reside in a single router, 2791 which would default to the current situation. 2793 3.10.8. Hierarchy 2795 A more flexible hierarchy with more levels and recursive groupings in 2796 both upward and downward directions allows more structured routing. 2797 The consequence is that no single level will get too big for routers 2798 to handle. 2800 On the other hand, it appears that the real world Internet is 2801 becoming less hierarchical, so that it will be increasingly difficult 2802 to use hierarchy to control scaling. 2804 Note that groupings can look different depending on which aspect we 2805 use to define them. A DiffServ area, an MPLS domain, a trusted 2806 domain, a QoS area, a multicast domain, etc., do not always coincide. 2807 But neither are they strict hierarchical subsets of each other. The 2808 basic distinction at each level is "this grouping versus everything 2809 outside". 2811 3.10.9. Control Theory 2813 Is it possible to apply a control theory framework to analyze the 2814 stability of the control system of the whole network domain, with 2815 regards to e.g., convergence speed and the frequency response, and 2816 then use the results from that analysis to set the timers and other 2817 protocol parameters? 2819 Control theory could also play a part in QoS Routing, by modifying 2820 current link state protocols with link costs dependent on load and 2821 feedback. Control theory is often used to increase the stability of 2822 dynamic systems. 2824 It might be possible to construct a new, totally dynamic routing 2825 protocol solely on a control theoretic basis, as opposed to the 2826 current protocols that are based in graph theory and static in 2827 nature. 2829 3.10.10. Byzantium 2831 Is solving the Byzantine Generals problem a requirement? This is the 2832 problem of reaching a consensus among distributed units if some of 2833 them give misleading answers. The current intra-domain routing 2834 system is, at one level, totally intolerant of misleading 2835 information. However, the effect of different sorts of misleading or 2836 incorrect information has vastly varying results, from total collapse 2837 to purely local disconnection of a single domain. This sort of 2838 behavior is not very desirable. 2840 There are, possibly, other network robustness issues that must be 2841 researched and resolved. 2843 3.10.11. VPN Support 2845 Today BGP is also used for VPNs, for example as described in RFC4364 2846 [RFC4364]. 2848 Internet routing and VPN routing have different purposes and most 2849 often exchange different information between different devices. Most 2850 Internet routers do not need to know VPN-specific information. The 2851 concepts should be clearly separated. 2853 But when it comes to the mechanisms, VPN routing can share the same 2854 protocol as ordinary Internet routing; it can use a separate instance 2855 of the same protocol or it can use a different protocol. All 2856 variants are possible and have their own merits. These requirements 2857 are silent on this issue. 2859 3.10.12. End-to-End Reliability 2861 The existing Internet architecture neither requires nor provides end- 2862 to-end reliability of control information dissemination. There is, 2863 however, already a requirement for end-to-end reliability of control 2864 information distribution, i.e., the ends of the VPN established need 2865 to have an acknowledgment of the success in setting up the VPN. 2866 While it is not necessarily the function of a routing architecture to 2867 provide end-to-end reliability for this kind of purpose, we must be 2868 clear that end-to-end reliability becomes a requirement if the 2869 network has to support such reliable control signaling. There may be 2870 other requirements that derive from requiring the FDR to support 2871 reliable control signaling. 2873 3.10.13. End-to-End Transparency 2875 The introduction of private addressing schemes, Network Address 2876 Translators, and firewalls has significantly reduced the end-to-end 2877 transparency of the network. In many cases the network is also no 2878 longer symmetric, so that communication between two addresses is 2879 possible if the communication session originates from one end but not 2880 from the other. This impedes the deployment of new peer-to-peer 2881 services and some 'push' services where the server in a client- 2882 server arrangement originates the communication session. Whether a 2883 new routing system either can or should seek to restore this 2884 transparency is an open issue. 2886 A related issue is the extent to which end user applications should 2887 seek to control the routing of communications to the rest of the 2888 network. 2890 4. Security Considerations 2892 We address security issues in the individual requirements. We do 2893 require that the architecture and protocols developed against this 2894 set of requirements be "secure". Discussion of specific security 2895 issues can be found in the following sections: 2897 o Group A: Routing System Security - Section 2.1.9 2899 o Group A: End Host Security - Section 2.1.10 2901 o Group A: Routing Information Policies - Section 2.1.11.1 2903 o Group A: Abstraction - Section 2.1.16 2905 o Group A: Robustness - Section 2.1.18 2907 o Group B: Protection against denial of service and other security 2908 attacks - Section 3.2.3.8 2910 o Group B: Commercial service providers - Section 3.3.1.1 2912 o Group B: The Federated Environment - Section 3.4.1 2914 o Group B: Path advertisement - Section 3.6.2.2 2916 o Group B: Security Requirements - Section 3.9 2918 5. IANA Considerations 2920 This document is a set of requirements from which a new routing and 2921 addressing architecture may be developed. From that architecture, a 2922 new protocol, or set of protocols, may be developed. 2924 While this note poses no new tasks for IANA, the architecture and 2925 protocols developed from this document probably will have issues to 2926 be dealt with by IANA. 2928 6. Acknowledgments 2930 This document is the combined efforts of two groups in the IRTF. 2931 Group A which was formed by the IRTF Routing Research chairs and 2932 Group B which was self formed and later was folded into the IRTF 2933 Routing Research Group. Each group has it own set of 2934 acknowledgments. 2936 Group A Acknolwedgements 2938 This originated in the IRTF Routing Research Group's sub-group on 2939 Inter-domain routing requirements. The members of the group were: 2941 Abha Ahuja Danny McPherson 2942 J. Noel Chiappa David Meyer 2943 Sean Doran Mike O'Dell 2944 JJ Garcia-Luna-Aceves Andrew Partan 2945 Susan Hares Radia Perlman 2946 Geoff Huston Yakov Rehkter 2947 Frank Kastenholz John Scudder 2948 Dave Katz Curtis Villamizar 2949 Tony Li Dave Ward 2951 We also appreciate the comments and review received from Ran 2952 Atkinson, Howard Berkowitz, Randy Bush, Avri Doria, Jeffery Haas, 2953 Dmitri Krioukov, Russ White, and Alex Zinin. Special thanks to 2954 Yakov Rehkter for contributing text and to Noel Chiappa. 2956 Group B Acknowledgements 2958 The draft is derived from work originally produced by Babylon. 2959 Babylon was a loose association of individuals from academia, 2960 service providers and vendors whose goal was to discuss issues in 2961 Internet routing with the intention of finding solutions for those 2962 problems. 2964 The individual members who contributed materially to this draft 2965 are: Anders Bergsten, Howard Berkowitz, Malin Carlzon, Lenka Carr 2966 Motyckova, Elwyn Davies, Avri Doria, Pierre Fransson, Yong Jiang, 2967 Dmitri Krioukov, Tove Madsen, Olle Pers, and Olov Schelen. 2969 Thanks also go to the members of Babylon and others who did 2970 substantial reviews of this material. Specifically we would like 2971 to acknowledge the helpful comments and suggestions of the 2972 following individuals: Loa Andersson, Tomas Ahlstrom, Erik Aman, 2973 Thomas Eriksson, Niklas Borg, Nigel Bragg, Thomas Chmara, Krister 2974 Edlund, Owe Grafford, Torbjorn Lundberg, Jeremy Mineweaser, 2975 Jasminko Mulahusic, Florian-Daniel Otel, Bernhard Stockman, Tom 2976 Worster, Roberto Zamparo. 2978 In addition, the authors are indebted to the folks who wrote all 2979 the references we have consulted in putting this paper together. 2980 This includes not only the references explicitly listed below, but 2981 also those who contributed to the mailing lists we have been 2982 participating in for years. 2984 Finally, it is the editors who are responsible for any lack of 2985 clarity, any errors, glaring omissions or misunderstandings. 2987 7. Informative References 2989 [Blumenthal01] 2990 Blumenthal, M. and D. Clark, "Rethinking the design of the 2991 Internet: The end to end arguments vs. the brave new 2992 world", May 2001, 2993 . 2995 [Broido02] 2996 Broido, A., Nemeth, E., Claffy, K., and C. Elves, 2997 "Internet Expansion, Refinement and Churn", February 2002. 2999 [CIDR] Telcordia Technologies, "CIDR Report", 3000 . 3002 [Chiappa02] 3003 Chiappa, N., "A New IP Routing and Addressing 3004 Architecture", July 1991, 3005 . 3007 [Clark91] Clark, D., "Quote reportedly from IETF Plenary 3008 discussion", 1991. 3010 [Griffin99] 3011 Griffin, T. and G. Wilfong, "An Analysis of BGP 3012 Convergence Properties", SIGCOMM , 1999. 3014 [I-D.ietf-diffserv-pdb-ar] 3015 Seddigh, N., Nandy, B., and J. Heinanen, "An Assured Rate 3016 Per-Domain Behaviour for Differentiated Services", 3017 draft-ietf-diffserv-pdb-ar-01 (work in progress), 3018 February 2001. 3020 [I-D.ietf-diffserv-pdb-vw] 3021 Jacobson, V., Nichols, K., and K. Poduri, "The 'Virtual 3022 Wire' Behavior Aggregate", draft-ietf-diffserv-pdb-vw-00 3023 (work in progress), July 2000. 3025 [I-D.irtf-routing-history] 3026 Davies, E., "Analysis of IDR requirements and History", 3027 draft-irtf-routing-history-06 (work in progress), 3028 August 2006. 3030 [I-D.many-inference-srlg] 3031 Papadimitriou, D. and others, "Inference of Shared Risk 3032 Link Groups", draft-many-inference-srlg-02 (work in 3033 progress), February 2002. 3035 [ISO10747] 3036 ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing 3037 Information among Intermediate Systems to Support 3038 Forwarding of ISO 8473 PDUs", International Standard 3039 10747 ISO/IEC JTC 1, Switzerland, 1993. 3041 [ODell01] O'Dell, M., "Private Communication", 2001. 3043 [RFC1126] Little, M., "Goals and functional requirements for inter- 3044 autonomous system routing", RFC 1126, October 1989. 3046 [RFC1726] Partridge, C. and F. Kastenholz, "Technical Criteria for 3047 Choosing IP The Next Generation (IPng)", RFC 1726, 3048 Dec 1994. 3050 [RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The 3051 Nimrod Routing Architecture", RFC 1992, August 1996. 3053 [RFC2071] Ferguson, P. and H. Berkowitz, "Network Renumbering 3054 Overview: Why would I want it and what is it anyway?", 3055 RFC 2071, January 1997. 3057 [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, 3058 January 1997. 3060 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 3061 Label Switching Architecture", RFC 3031, January 2001. 3063 [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the 3064 Internet", RFC 3221, December 2001. 3066 [RFC3260] Grossman, D., "New Terminology and Clarifications for 3067 Diffserv", RFC 3260, April 2002. 3069 [RFC3344] Perkins, C., "IP Mobility Support.", RFC 3344, 3070 August 2002. 3072 [RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, 3073 "Border Gateway Protocol (BGP) Persistent Route 3074 Oscillation Condition", RFC 3345, August 2002. 3076 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 3077 (GMPLS) Signaling Functional Description", RFC 3471, 3078 January 2003. 3080 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 3081 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 3082 RFC 3963, January 2005. 3084 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 3085 Networks (VPNs)", RFC 4364, February 2006. 3087 [Wroclawski95] 3088 Wroclowski, J., "The Metanet White Paper - Workshop on 3089 Research Directions for the Next Generation Internet", 3090 1995. 3092 [netconf-charter] 3093 Internet Engineering Task Force, "IETF Network 3094 Configuration working group", 2005, 3095 . 3097 [policy-charter02] 3098 Internet Engineering Task Force, "IETF Policy working 3099 group", 2002, . 3102 [rap-charter02] 3103 Internet Engineering Task Force, "IETF Resource Allocation 3104 Protocol working group", 2002, 3105 . 3107 [snmpconf-charter02] 3108 Internet Engineering Task Force, "IETF Configuration 3109 management with SNMP working group", 2002, . 3112 Authors' Addresses 3114 Avri Doria 3115 LTU 3116 Lulea 971 87 3117 Sweden 3119 Phone: +46 73 277 1788 3120 Email: avri@ltu.se 3122 Elwyn B. Davies 3123 Folly Consulting 3124 Soham, Cambs 3125 UK 3127 Phone: +44 7889 488 335 3128 Email: elwynd@dial.pipex.com 3130 Frank Kastenholz 3131 MA 3132 USA 3134 Email: frank@kastenholz.org