idnits 2.17.1 draft-irtf-routing-reqs-groupb-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 38 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 39 longer pages, the longest (page 38) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 213: '...ed. These terms SHOULD NOT be underst...' RFC 2119 keyword, line 214: '... inter-domain. Rather these SHOULD be...' RFC 2119 keyword, line 800: '...rk and must, and MUST not reduce the f...' RFC 2119 keyword, line 808: '... R(1) Routers MUST be able to acqui...' RFC 2119 keyword, line 812: '... R(2) Routers MUST have the ability...' (69 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1300 has weird spacing: '... to the cases...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This section includes a detailed discussion of new requirements for a future domain routing architecture. As discussed in section 2.3.12 a new architecture must build upon the requirements of the past routing framework and must, and MUST not reduce the functionality of the network. A discussion and analysis of the RFC1126 requirements can be found in [41]. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '10' on line 1766 looks like a reference -- Missing reference section? '24' on line 1829 looks like a reference -- Missing reference section? '25' on line 1832 looks like a reference -- Missing reference section? '31' on line 1858 looks like a reference -- Missing reference section? '18' on line 1797 looks like a reference -- Missing reference section? '19' on line 1804 looks like a reference -- Missing reference section? '12' on line 1774 looks like a reference -- Missing reference section? '20' on line 1810 looks like a reference -- Missing reference section? '26' on line 1837 looks like a reference -- Missing reference section? '27' on line 1841 looks like a reference -- Missing reference section? '28' on line 1846 looks like a reference -- Missing reference section? '41' on line 1905 looks like a reference -- Missing reference section? '4' on line 1742 looks like a reference -- Missing reference section? '30' on line 1853 looks like a reference -- Missing reference section? '43' on line 1915 looks like a reference -- Missing reference section? '13' on line 1777 looks like a reference -- Missing reference section? '36' on line 1883 looks like a reference -- Missing reference section? '9' on line 1763 looks like a reference -- Missing reference section? '42' on line 1908 looks like a reference -- Missing reference section? '39' on line 1898 looks like a reference -- Missing reference section? '40' on line 1902 looks like a reference -- Missing reference section? '32' on line 1862 looks like a reference -- Missing reference section? '16' on line 1790 looks like a reference -- Missing reference section? '1' on line 1732 looks like a reference -- Missing reference section? '2' on line 1735 looks like a reference -- Missing reference section? '3' on line 1739 looks like a reference -- Missing reference section? '5' on line 1746 looks like a reference -- Missing reference section? '6' on line 1751 looks like a reference -- Missing reference section? '7' on line 1756 looks like a reference -- Missing reference section? '8' on line 1759 looks like a reference -- Missing reference section? '11' on line 1770 looks like a reference -- Missing reference section? '14' on line 1780 looks like a reference -- Missing reference section? '15' on line 1785 looks like a reference -- Missing reference section? '17' on line 1793 looks like a reference -- Missing reference section? '21' on line 1815 looks like a reference -- Missing reference section? '22' on line 1818 looks like a reference -- Missing reference section? '23' on line 1823 looks like a reference -- Missing reference section? 'BGMP' on line 1823 looks like a reference -- Missing reference section? '29' on line 1850 looks like a reference -- Missing reference section? '33' on line 1868 looks like a reference -- Missing reference section? '34' on line 1872 looks like a reference -- Missing reference section? '35' on line 1879 looks like a reference -- Missing reference section? '37' on line 1889 looks like a reference -- Missing reference section? '38' on line 1893 looks like a reference -- Missing reference section? 'History' on line 1905 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 47 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IRTF Routing Research Avri Doria (co-editor) 3 Internet Draft Lulea University of Technology 4 Elwyn Davies (co-editor) 5 Nortel Networks 7 Document: draft-irtf-routing-reqs-groupb-00.txt February, 2002 9 Future Domain Routing Requirements 10 Group B contribution 11 13 Status of this Memo 15 This document is an Internet Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a "working 25 draft" or "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 Discussion and suggestions for improvement are requested. This 34 document will expire before August, 2002. Distribution of this draft 35 is unlimited. 37 Copyright Notice 38 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 Abstract 41 This draft is the product of Group B, which is one of, at least, two 42 subgroups in the IRTF-Routing Research Group working on requirements 43 for routing solutions for the future. This document sets out a set 44 of requirements that we believe are important for the future routing 45 architecture and future routing protocols. It should be noted that 46 the IRTF-Routing Research group does not endorse this set of 47 requirements or any other set of requirements as the one and only set 48 of requirements. 50 Group B 1 51 Acknowledgements 53 The draft is derived from draft-davies-fdr-reqs-01.txt that was 54 produced by Babylon. Babylon is a loose association of individuals 55 from academia, service providers and vendors whose goal is to discuss 56 issues in Internet routing with the intention of finding solutions 57 for those problems. 59 The individual members who contributed materially to this draft are: 60 Anders Bergsten, Howard Berkowitz, Malin Carlzon, Lenka Carr 61 Motyckova, Elwyn Davies, Avri Doria, Pierre Fransson, Yong Jiang, 62 Dmitri Krioukov, Tove Madsen, Olle Pers, and Olov Schelen. 64 Thanks also go to the members of Babylon and others who did 65 substantial reviews of this material. Specifically we would like to 66 acknowledge the helpful comments and suggestions of the following 67 individuals: Loa Andersson, Tomas Ahlstr�m, Erik �man, Thomas 68 Eriksson, Niklas Borg, Nigel Bragg, Thomas Chmara, Krister Edlund, 69 Owe Grafford, Torbj�rn Lundberg, Jasminko Mulahusic, Florian-Daniel 70 Otel, Bernhard Stockman, Tom Worster, Roberto Zamparo. 72 In addition, the authors are indebted to the folks who wrote all the 73 references we have consulted in putting this paper together. This 74 includes not only the references explicitly listed below, but also 75 those who contributed to the mailing lists we have been participating 76 in for years. 78 Finally, it is the editors who are responsible for any lack of 79 clarity, any errors, glaring omissions or misunderstandings. 81 Changes from Draft-davies-fdr-reqs-01.txt 83 - The historical background has been separated into another I-D for 84 which we plan to seek Informational RFC status. 86 - The actual requirements (where they are fully crystallized) have 87 been individually numbered and isolated from surrounding 88 discussion material. 90 Group B Expires: September 2002 2 91 Contents 93 1. Introduction....................................................4 94 2. Underlying principles...........................................4 95 2.2 Influences on a changing network...........................5 96 2.3 High level goals...........................................6 97 3. High level user requirements....................................9 98 3.1 Organisational users......................................10 99 3.2 Individual users..........................................12 100 4. Mandated constraints...........................................13 101 4.1 The federated environment.................................13 102 4.2 Working with different sorts of networks..................13 103 4.3 Delivering diversity......................................14 104 4.4 When will the new solution be required?...................14 105 5. Assumptions....................................................15 106 6. Functional requirements........................................16 107 6.1 Topology..................................................16 108 6.2 Distribution..............................................17 109 6.3 Addressing................................................21 110 6.4 Statistics support........................................23 111 6.5 Management requirements...................................23 112 6.6 Provability...............................................24 113 6.7 Traffic engineering.......................................25 114 6.8 Support for mid-boxes.....................................26 115 7. Performance requirements.......................................27 116 8. Backwards compatibility (cutover) and maintainability..........27 117 9. Security requirements..........................................28 118 10. Debatable issues..............................................30 119 10.1 Network modeling.......................................30 120 10.2 System modeling........................................30 121 10.3 One, two or many protocols.............................31 122 10.4 Class of protocol to use...............................31 123 10.5 Map abstraction........................................31 124 10.6 Clear identification for all entities..................32 125 10.7 Robustness and redundancy:.............................32 126 10.8 Hierarchy..............................................32 127 10.9 Will new control mechanisms be needed?.................33 128 10.10 Byzantium..............................................33 129 10.11 VPN support............................................33 130 10.12 End to end reliability.................................33 131 10.13 End to end transparency................................34 132 11. Bibliography..................................................34 133 12. Author's Addresses............................................38 135 Group B Expires: September 2002 3 136 1. Introduction 138 It is generally accepted that there are major shortcomings in the 139 inter-domain routing of the Internet today and that these may result 140 in meltdown within an unspecified period of time. Remedying these 141 shortcomings will require extensive research to tie down the exact 142 failure modes that lead to these shortcomings and identify the best 143 techniques to remedy the situation. 145 Various developments in the nature and quality of the services that 146 users want from the Internet are difficult to provide within the 147 current framework as they impose requirements never foreseen by the 148 original architects of the Internet routing system. 150 The potential advent of IPv6 and the application of IP mechanisms to 151 private commercial networks offering specific service guarantees as 152 an improvement over the best efforts services of the Public Internet 153 epitomize the kind of radical changes which have to be accommodated: 154 Major changes to the inter-domain routing system are inevitable if it 155 is to provide an efficient underpinning for the radically changed and 156 increasingly, commercially-based networks which rely on the IP 157 protocol suite. 159 2. Underlying principles 161 Although inter-domain routing is seen as the major source of 162 problems, the interactions with intra-domain routing and the 163 constraints that confining changes to the inter-domain arena would 164 impose, means that we should consider the whole area of routing as an 165 integrated system. This is done for 2 reasons: 167 - Requirements should not presuppose the solution. A continued 168 commitment to the current definitions and split between inter- 169 domain and intra-domain routing would constitute such a 170 presupposition. Therefore the name Future Domain Routing(FDR) is 171 being used in this document, 173 - As an acknowledgement of how intertwined inter-domain and intra- 174 domain routing are within today's routing architecture. 176 We are aware that using the term Domain Routing is already fraught 177 with danger because of possible misinterpretation due to prior usage. 178 The meaning of Domain Routing will be developed implicitly throughout 179 the document, but a little advance explicit definition of the word 180 'domain' is required, as well as some expansion on the scope of 181 'routing'. 183 This document uses domain in a very broad sense to mean any 184 collection of systems or domains that come under a common authority 185 that determines the attributes defining, and the policies 186 controlling, that collection. The use of domain in this context is 187 very similar to the concept of Region that was put forth by John 189 Group B Expires: September 2002 4 190 Wroclawski in his Metanet model [10]. The idea includes the notion 191 that within a domain certain system attributes will characterize the 192 behavior of the systems in the domain and that there will be borders 193 between domains. The idea of domain presented does not inherently 194 presuppose that the identifying behaviors between two domains are to 195 be the same. Nor does it presuppose anything about the hierarchical 196 nature of domains. Finally it does not place restrictions on the 197 nature of the attributes that might be used to determine membership 198 in a domain. Since today's routing domains are a subset of all 199 domains as conceived of in this document, there has been no attempt 200 to create a new term. 202 Current practice stresses the need to separate the concerns of the 203 control plane in a router and the forwarding plane: This document 204 will follow this practice, but we still use the term 'routing' as a 205 global portmanteau to cover all aspects of the system. Specifically 206 however routing will be used to mean the process of discovering, 207 interpreting and distributing information about the logical and 208 topological structure of the network. 210 2.1.1 Inter-domain and intra-domain 212 Throughout this document the terms intra-domain and inter-domain will 213 be used. These terms SHOULD NOT be understood to imply that there is 214 one intra-domain and one inter-domain. Rather these SHOULD be 215 understood as relative terms. In all case of domains there will be a 216 set of network systems that are within that domain and routing 217 between these systems will be termed intra-domain. In some cases 218 there will be routing between domains, which will be termed inter- 219 domain. It is possible that the same routing activities can be 220 viewed as intra-domain from one perspective and inter-domain from 221 another perspective. 223 2.2 Influences on a changing network 225 The development of the Internet is likely to be driven by a number of 226 changes that will affect the organization and the usage of the 227 network, including: 228 - Ongoing evolution of the commercial relationships between 229 (connectivity) service providers, leading to changes in the way in 230 which peering between providers is organised and the way in which 231 transit traffic is routed 232 - Requirements for traffic engineering within and between domains 233 including coping with multiple paths between domains 234 - Potential addition of a second IP addressing technique through 235 IPv6. 236 - The use of VPNs and private address space with IPv4, and possibly 237 IPv6 238 - Evolution of the end-to-end principle to deal with the expanded 239 role of the Internet as discussed in [32]]. This paper discusses 240 the possibility that the range of new requirements, especially the 241 social and techno-political ones, which are being placed on the 243 Group B Expires: September 2002 5 244 future Internet, may compromise the Internet's original design 245 principles. This might cause the Internet to lose some of its key 246 features, in particular its ability to support new and 247 unanticipated applications. The discussion is linked to the rise 248 of new stakeholders in the Internet, especially ISPs; new 249 government interests; the changing motivations of the ever growing 250 user base; and the tension between the demand for trustworthy 251 overall operation and the inability to trust the behaviour of 252 individual users. 253 - Incorporation of alternative forwarding techniques such as the 254 explicit routing (pipes) supplied by the MPLS [24] and GMPLS 255 environments [25]. 256 - Integrating additional constraints into route determination from 257 interactions with other layers (e.g. Shared Risk Link Groups [31]) 258 - Support for alternative and multiple routing techniques that are 259 better suited to delivering types of content organised other than 260 into IP addressed packets. 262 Philosophically, the Internet has the mission of transferring 263 information from one place to another. Conceptually, this 264 information is rarely organised into conveniently sized, IP-addressed 265 packets and the FDR needs to consider how the information (content) 266 to be carried is identified, named and addressed. Routing techniques 267 can then be adapted to handle the expected types of content. 269 2.3 High level goals 271 This section attempts to answer two questions: 272 - What are we trying to achieve in a new architecture? 273 - Why should the Internet community care? 275 There is a third question that needs to be answered as well, but 276 which, for the present, is mostly not explicitly discussed: 277 - How will we know when we have succeeded? 279 2.3.1 Providing a routing system matched to domain organization 281 Many of today's routing problems are caused by a routing system that 282 is not well matched to the organization and policies which it is 283 trying to support. It is our goal to develop a routing architecture 284 where even domain organization that is not envisioned today can be 285 served by a routing architecture that matches its requirements. 287 We will know when this goal is achieved when the desired policies, 288 rules and organization can be mapped into the routing system in a 289 natural, consistent and simply understood way. 291 2.3.2 Supporting a range of different communication services 293 Today's routing protocols only support a single data forwarding 294 service that is typically used to deliver a best efforts service in 295 the Public Internet. On the other hand, with, for example, DiffServ 297 Group B Expires: September 2002 6 298 it is possible to construct a number of different bit transport 299 services within the network. Using some of the per-domain behaviors 300 (PDB)s that have been discussed in the IETF, it should be possible to 301 construct services such as Virtual Wire [18] and Assured Rate [19]. 303 Providers today offer rudimentary promises about how traffic will be 304 handled in the network, for example delay and long-term packet loss 305 guarantees, and this will probably be even more relevant in the 306 future. Communicating the service characteristics of paths in routing 307 protocols will be necessary in the near future, and it will be 308 necessary to be able to route packets according to their service 309 requirements. 311 Thus, a goal of this architecture is to allow for adequate 312 information about path service characteristics passed between domains 313 and consequently allow the delivery of bit transport services other 314 than the best-effort datagram connectivity service that is the 315 current common denominator. 317 2.3.3 Scaleable well beyond current predictable needs 319 Any proposed new FDR system should scale beyond the size and 320 performance we can foresee for the next ten years. The previous IDR 321 proposal has, with some massaging, held up for somewhat over ten 322 years in which time the Internet has grown far beyond the predictions 323 that were made in the requirements that were placed on it originally. 325 Unfortunately, we will only know if we have succeeded in this goal if 326 the FDR system survives beyond its design lifetime without serious 327 massaging. Failure will be much easier to spot! 329 2.3.4 Supporting alternative forwarding mechanisms 331 With the advent of circuit based technologies (e.g., MPLS [24] used 332 for RSVP-TE or CR-LDP for traffic engineering, GMPLS [25]) managed by 333 IP routers there are forwarding mechanisms other than the datagram 334 service that need to be supported by the routing architecture. 336 An explicit goal of this architecture is to add support for 337 forwarding mechanisms other then the current hop-by-hop datagram 338 forwarding service driven by globally unique IP addresses. 340 2.3.5 Supporting separation of topology map and connectivity service 342 It is envisioned that an organization can support multiple services 343 on top of a single network. These services can, for example, be of 344 different quality, of different type of connectivity, or different 345 protocols (e.g. IPv4 and IPv6). For all these services there may be 346 common domain topology, even though the policies controlling the 347 routing of information might differ from service to service. 349 Group B Expires: September 2002 7 350 Thus, a goal with this architecture is to support separation between 351 creation of a domain (or organization) topology map and service 352 creation. 354 2.3.6 Achieving separation between routing and forwarding 356 The architecture of a router is composed of two main separable parts; 357 control and forwarding. These components, while inter-dependent, 358 perform functions that are largely independent of each other. 359 Control (routing, signaling, and management) is typically done in 360 software while forwarding typically is done with specialized ASICs or 361 network processors. 363 The nature of an IP based network today is that control and data 364 protocols share the same network and forwarding regime. This may not 365 always be the case in future networks and we should be careful to 366 avoid building this sharing in as an assumption in the FDR. 368 A goal of this architecture is to support full separation of control 369 and forwarding, and to consider what additional concerns might be 370 properly considered separately (e.g. adjacency management). 372 2.3.7 Providing for use of different routing paradigms in different 373 areas of the same network 375 A number of different routing paradigms have been used or researched 376 in addition to conventional shortest path hop-by-hop paradigm that is 377 the current mainstay of the Internet. In particular, differences in 378 underlying transport networks may mean that other kinds of routing 379 are more relevant, and the perceived need for traffic engineering 380 will certainly alter the routing chosen in various domains. 382 Explicitly, one of these routing paradigms should be the current 383 routing paradigm, so that the new paradigms will inter-operate in a 384 backwards-compatible way with today's system. This will facilitate a 385 migration strategy that avoids flag days. 387 2.3.8 Preventing denial of service and other security attacks 389 Currently, existence of a route to a destination effectively implies 390 that anybody who can get a packet onto the network is entitled to use 391 that route. Whilst there are limitations to this generalization, 392 this is a clear invitation to denial of service attacks. A goal of 393 the FDR system should be to allow traffic to be specifically linked 394 to whole or partial routes so that a destination or link resources 395 can be protected from unauthorized use. 397 2.3.9 Providing provable convergence with verifiable policy interaction 399 It has been shown both analytically by Griffin et al (see [12]) and 400 practically (see [20]) that BGP will not converge stably or is only 402 Group B Expires: September 2002 8 403 meta-stable (i.e. will not reconverge in the face of a single 404 failure) when certain types of policy constraint are applied to 405 categories of network topology. The addition of policy to the basic 406 distance vector algorithm invalidates the proofs that could be 407 applied to a policy free implementation. 409 It has also been argued that global convergence may no longer be a 410 necessary goal and that local convergence may be all that is 411 required. 413 A goal of the FDR should be to achieve provable convergence of the 414 protocols used which may involve constraining the topologies and 415 domains subject to convergence. This will also require vetting the 416 policies imposed to ensure that they are compatible across domain 417 boundaries and result in a consistent policy set. 419 2.3.10 Providing robustness despite errors and failures 421 From time to time in the history of the Internet there have been 422 occurrences where people misconfiguring routers have destroyed global 423 connectivity. This should never be possible. 425 A goal of the FDR is to be robust to configuration errors and 426 failures. This should probably involve ensuring that the effects of 427 misconfiguration and failure can be confined to some suitable 428 locality of the failure or misconfiguration. 430 2.3.11 Simplicity in management 432 With the policy work ([26], [27] and [28]) that has been done at IETF 433 there exists an architecture that standardizes and simplifies 434 management of QoS. This kind of simplicity is needed in a future 435 domain routing architecture and its protocols. 437 A goal of this architecture is to make configuration and management 438 of inter-domain routing as simple as possible. 440 2.3.12 The legacy of RFC1126 442 RFC1126 outlined a set of requirements that were used to guide the 443 development of BGP. While the network is definitely different then it 444 was in 1989, many of the same requirements remain. A future domain 445 routing has to support as its base requirement, the level of function 446 that is available today. A detailed discussion of RFC1126 and it 447 requirements can be found in [41]. Those requirements, while 448 specifically spelled out in that document are to be subsumed by the 449 requirements in this document. 451 3. High level user requirements 453 Group B Expires: September 2002 9 454 This section considers the requirements imposed by the target 455 audience of the FDR both in terms of organizations that might own 456 networks, which would use FDR, and the human users who will have to 457 interact with the FDR. 459 3.1 Organisational users 461 The organizations that own networks connected to the Internet have 462 become much more diverse since RFC1126 [4] was published. In 463 particular a major part of the network are now owned by commercial 464 service provider organizations in the business of making profits from 465 carrying data traffic. 467 3.1.1 Commercial service providers 469 The routing system must take into account the commercial service 470 provider's for commercial secrecy and security, as well as allowing 471 them to organize their business as flexibly as possible. 473 Service providers will often wish to conceal the details of the 474 network from other connected networks. So far as is possible, the 475 routing system should not require the service providers to expose 476 more details of the topology and capability of their networks than is 477 strictly necessary. 479 Many service providers will also offer contracts to their customers 480 in the form of Service Level Agreements (SLAs) and the routing system 481 must allow the providers to support these SLAs through traffic 482 engineering and load balancing, as well as multihoming, allowing them 483 to achieve the degree of resilience and robustness that they need. 485 Service providers can be categorized as 487 - Global Service Providers (GSPs) with networks that have a global 488 reach. Such providers may, and usually will, wish to constrain 489 traffic between their customers to run entirely on their 490 networks. Such providers will interchange traffic at multiple 491 peering points with other GSPs and need extensive policy-based 492 controls to control the interchange of traffic. Peering may be 493 through the use of dedicated private lines between the partners 494 or increasingly through Internet Exchange Points. 495 - National Service Providers (NSPs) that are similar to GSPs but 496 typically cover one country. Such organizations may operate as 497 a federation that provides similar reach to a GSP and may wish 498 to be able to steer traffic preferentially to other federation 499 members to achieve global reach. 500 - Local Internet Service Providers (ISPs) operate regionally and 501 will typically purchase transit capacity from NSPs or GSPs to 502 provide global connectivity, but may also peer with neighbouring 503 ISPs. 505 Group B Expires: September 2002 10 506 The routing system should be sufficiently flexible to accommodate the 507 continually changing business relationships of the providers, and the 508 various levels of trustworthiness that they apply to customers and 509 partners. 511 Service providers will need to be involved in accounting for Internet 512 usage, monitoring the traffic, and may be involved in government 513 action to tax the usage of the Internet, enforce social mores and 514 intellectual property rules or apply surveillance to the traffic to 515 detect or prevent crime. 517 3.1.2 Enterprises 519 The leaves of the network domain graph are in many cases networks 520 supporting a single enterprise. Such networks cover an enormous 521 range of complexity with some multi-national companies owning 522 networks that rival the complexity and reach of a GSP whereas many 523 fall into the Small Office-Home Office (SOHO) category. The routing 524 system should allow simple and robust configuration and operation for 525 the SOHO category, whilst effectively supporting the larger 526 enterprise. 528 Enterprises are particularly likely to lack the capability to 529 configure and manage a complex routing system and every effort should 530 be made to provide simple configuration and operation for such 531 networks. 533 Enterprises will also need to be able to change their service 534 provider with ease. Whilst this is predominantly a naming and 535 addressing issue, the routing system must be able to support seamless 536 changeover, for example, by coping with a changeover period when both 537 sets of addresses are in use. 539 Enterprises will wish to be able to multihome to one or more 540 providers as one possible means of enhancing the resilience of their 541 network. 543 Enterprises will also frequently need to control the trust that they 544 place both in workers and external connections through firewalls and 545 similar mid-boxes placed at their external connections. 547 3.1.3 Domestic networks 549 Increasingly domestic, i.e. non business home, networks are likely to 550 be 'always on' and will resemble SOHO enterprises networks with no 551 special requirements of the routing system. 553 The routing system must support dial-up users. 555 3.1.4 Internet exchange points 557 Group B Expires: September 2002 11 558 Peering of service providers, academic networks and larger 559 enterprises is increasingly happening at specific Internet Exchange 560 Points where many networks are linked together in a relatively small 561 physical area. The resources of the exchange may be owned by a 562 trusted third party or owned jointly by the connecting networks. The 563 routing systems should support such exchange points without requiring 564 the exchange point to either operate as a superior entity with every 565 connected network logically inferior to it or requiring the exchange 566 point to be a member of one (or all) connected networks. The 567 connecting networks have to delegate a certain amount of trust to the 568 exchange point operator. 570 3.1.5 Content providers 572 Content providers are at one level a special class of enterprise, but 573 the desire to deliver content efficiently means that a content 574 provider may provide multiple replicated origin servers or caches 575 across a network. These may also be provided by a separate content 576 delivery service. The routing system should facilitate delivering 577 content from the most efficient location. 579 3.2 Individual users 581 This section covers the most important human users of the FDR and 582 their expected interactions with the system. 584 3.2.1 All end users 586 The routing system must continue to deliver the current global 587 connectivity service (i.e. any address to any other address, subject 588 to policy constraints) that has always been the basic aim of the 589 Internet. 591 End user applications should be able to request, or have requested on 592 their behalf by agents and policy mechanisms, end-to-end 593 communication services with different QoS characteristics as compared 594 with the best efforts service that is the foundation of today's 595 Internet. It should be possible to request both a single service 596 channel and a bundle of service channels delivered as a single 597 entity. 599 3.2.2 Network planners 601 The routing system should allow them to plan and implement a network 602 that can be proved to be stable and will meet their traffic 603 engineering requirements. 605 3.2.3 Network operators 607 The routing system should, so far as is possible, be simple to 608 configure operate and troubleshoot, behave in a predictable, stable 609 fashion and deliver appropriate statistics and events to allow the 611 Group B Expires: September 2002 12 612 network to be managed and upgraded in an efficient and timely 613 fashion. 615 3.2.4 Mobile end users 617 The routing system must support mobile end users. It is clear that 618 mobility is becoming a predominant mode for network access. 620 4. Mandated constraints 622 While many of the requirement to which the protocol must respond are 623 technical, some aren't. These mandated constraints are those that 624 are determined by conditions of the world around us. Understanding 625 these requirements requires and analysis of the world in which these 626 systems will be deployed. The constraints include those that are 627 determined by: 628 - Environmental factors. 629 - Geography 630 - Political boundaries and considerations 631 - Technological factors such as the prevalence of different 632 levels of technology in the developed world as opposed to in 633 the developing or undeveloped world. 635 4.1 The federated environment 637 The graph of the Internet network with routers and other control 638 boxes at the nodes and communication links along the edges is today 639 partitioned administratively into a large number of disjoint domains. 641 A common administration may have responsibility for one or more 642 domains that may or may not be adjacent in the graph. 644 Commercial and policy constraints affecting the routing system will 645 typically be exercised at the boundaries of these domains where 646 traffic is exchanged between the domains. 648 The perceived need for commercial confidentiality will seek to 649 minimise the control information transferred across these boundaries, 650 leading to requirements for aggregated information, abstracted maps 651 of connectivity exported from domains and mistrust of supplied 652 information. 654 The perceived desire for anonymity may require the use of zero- 655 knowledge security protocols to allow users to access resources 656 without exposing their identity. 658 The requirements should provide the ability for groups of peering 659 domains to be treated as a complex domain. These complex domains 660 could have a common administrative policy. 662 4.2 Working with different sorts of networks 664 Group B Expires: September 2002 13 665 The diverse Layer 2 networks over which the layer 3 routing system is 666 implemented have typically been operated totally independently from 667 the layer 3 network. Consideration needs to be given to the degree 668 and nature of interchange of information between the layers that is 669 desirable. In particular, the need for robustness through diverse 670 routing implies knowledge of the underlying networks to be able to 671 guarantee the robustness. 673 Mobile access networks may also impose extra requirements on Layer 3 674 routing. 676 4.3 Delivering diversity 678 The routing system is operating at Layer 3 in the network. To 679 achieve robustness and resilience at this layer requires that where 680 multiple diverse routes are employed as part of delivering the 681 resilience, the routing system at Layer 3 needs to be assured that 682 the Layer 2 and lower routes are really diverse. The 'diamond 683 problem' is the simplest form of this problem - a layer 3 provider 684 attempting to provide diversity buys layer 2 services from two 685 separate providers who in turn buy wayleaves from the same provider: 687 Layer 3 service 688 / \ 689 / \ 690 Layer 2 Layer 2 691 Provider A Provider B 692 \ / 693 \ / 694 Trench provider 696 Now when the backhoe cuts the trench, the Layer 3 provider has no 697 resilience unless he had taken special steps to verify that the 698 trench wasn't common. The routing system should facilitate avoidance 699 of this kind of trap. 701 Some work is going on to understand the sort of problems that stem 702 from this requirement, such as the work on Shared Risk Link Groups 703 [31]. Unfortunately, the full generality of the problem requires 704 diversity be maintained over time between an arbitrarily large set of 705 mutually distrustful providers. For some cases, it may be sufficient 706 for diversity to be checked at provisioning or route instantiation 707 time, but this remains a hard problem requiring research work. 709 4.4 When will the new solution be required? 711 There is a full range of opinion on this subject. An informal survey 712 indicates that the range varies from 2 years to 6 years. And while 713 there are those, possibly outliers, who think there is no need for a 714 new routing architecture as well as those who think a new 715 architecture was needed years ago, the median seems to lie at around 717 Group B Expires: September 2002 14 718 4 years. As in all projections of the future this is largely not 719 provable at this time. 721 5. Assumptions 723 In projecting the requirements for the Future Domain Routing a number 724 of assumptions have been made. The requirements set out should be 725 consistent with these assumptions, but there are doubtless a number 726 of other assumptions that are not explicitly articulated here: 728 1. The number of hosts today is somewhere in the area of 100 Million. 729 With dial in and NATs this is likely to turn into up to 500 730 Million users (see [30]). In a number of years, with wireless 731 accesses and different appliances attaching to the Internet, we 732 are likely to see a couple of Billion (10^9) 'users' on the 733 Internet. The number of globally addressable hosts is very much 734 dependent on how common NATs will be in the future. 735 2. NATs, firewalls and other mid-boxes exist and we cannot assume 736 that they will cease being a presence in the networks. 737 3. The number of operators in the Internet will probably not grow 738 very much, as there is a likelihood that operators will tend to 739 merge. However, as Internet-connectivity expands to new countries, 740 new operators will emerge and then merge again. 741 4. As of the beginning of 2002, there are around 12000 registered 742 AS's. With current use of AS's (for e.g., multi-homing) the 743 number of AS's could be expected to grow to 25000 in about 10 744 years.[43] This is down from a previously reported growth rate of 745 51% per year.[13]. Future growth rates are difficult to predict. 746 5. In contrast to the number of operators, the number of domains is 747 likely to grow significantly. Today, each operator has different 748 domains within an AS, but this also shows in SLAs and policies 749 internal to the operator. Making this globally visible would 750 create a number of domains 10-100 times the number of ASs, i.e., 751 between 100,000 and 1,000,000. 752 6. With more and more capacity at the edge of the network the IP 753 network will expand. Today there are operators with several 754 thousands of routers, but this is likely to be increased. A domain 755 will probably contain tens of thousands of routers. 756 7. The speed of connections in the (fixed) access will technically be 757 (almost) unconstrained. However, the cost for the links will not 758 be negligible so that the apparent speed will be effectively 759 bounded. Within a number of years some will have multi-gigabit 760 speed in the access. 761 8. At the same time, the bandwidth of wireless access still has a 762 strict upper-bound. Within the foreseeable future each user will 763 only have a tiny amount of resources available compared to fixed 764 accesses (10kbps to 2Mbps for UMTS with only a few achieving the 765 higher figure as the bandwidth is shared between the active users 766 in a cell and only small cells can actually reach this speed, but 767 11Mbps or more for wireless LAN connections). There may also be 768 requirements for effective use of bandwidth as low as 2.4 Kbps or 769 lower, in some applications. 771 Group B Expires: September 2002 15 772 9. Assumptions 7 and 8 taken together suggest a minimum span of 773 bandwidth between 2.4 kbps to 10 Gbps. 774 10. The speed in the backbone has grown rapidly, and there is no 775 evidence that the growth will stop in the coming years. Terabit- 776 speed is likely to be the minimum backbone speed in a couple of 777 years. The range of bandwidths that need to be represented will 778 require consideration on how to represent the values in the 779 protocols. 780 11. There have been discussions as to whether Moore's law will 781 continue to hold for processor speed. If Moore's law does not 782 hold, then communication circuits might play a more important role 783 in the future. Also, optical routing is based on circuit 784 technology, which is the main reason for taking �circuits� into 785 account when designing an FDR. 786 12. However, the datagram model still remains the fundamental model 787 for the Internet. 788 13. The number of peering points in the network is likely to grow, as 789 multi-homing becomes important. Also traffic will become more 790 locally distributed, which will drive the demand for local 791 peering. 792 14. The FDR will achieve the same degree of ubiquity as the current 793 Internet and IP routing. 795 6. Functional requirements 797 This section includes a detailed discussion of new requirements for a 798 future domain routing architecture. As discussed in section 2.3.12 a 799 new architecture must build upon the requirements of the past routing 800 framework and must, and MUST not reduce the functionality of the 801 network. A discussion and analysis of the RFC1126 requirements can 802 be found in [41]. 804 6.1 Topology 806 6.1.1 Routers should be able to know and exploit the domain topology 808 R(1) Routers MUST be able to acquire and hold sufficient 809 information on the underlying topology of the domain to 810 allow the establishment of routes on that topology. 812 R(2) Routers MUST have the ability to control the 813 establishment of routes on the underlying topology. 815 R(3) Routers MUST be able, where appropriate, to control Sub- 816 IP mechanisms to support the establishment of routes. 818 The OSI Inter-Domain Routing Protocol (IDRP) [36] utilized a 819 capability which allowed a collection of topologically related 820 domains to be replaced by a domain collection object in a similar way 821 to the Nimrod[9] domain hierarchies, allowing a route to be more 823 Group B Expires: September 2002 16 824 compactly represented by a single collection in place of a sequence 825 of individual domains. 827 R(4) Routers MUST, where appropriate, be able to construct 828 abstractions of the topology that represent an 829 aggregation of the topological features of some area of 830 the topology. 832 6.1.2 The same topology information should support different path 833 selection ideas: 835 The same topology information needs to provide a more flexible 836 spectrum of path selection methods that we might expect to find in a 837 future Internet, including, amongst others, both distributed 838 techniques such as hop-by-hop, shortest path, local optimization 839 constraint-based, class of service, source address routing, and 840 destination address routing as well as the centralized, global 841 optimization constraint-based 'traffic engineering' type (Open 842 constraints should be allowed). Allowing different path selection 843 techniques to be used will produce a much more predictable and 844 comprehensible result than the 'clever tricks' that are currently 845 needed to achieve the same results. Traffic engineering functions 846 need to be combined. 848 R(5) Routers MUST be capable of supporting a small number of 849 different path selection algorithms 851 6.1.3 Separation of the routing information topology from the data 852 transport topology. 854 R(6) The controlling network MAY be logically separate from 855 the controlled network. 857 Physically, the two functional 'planes' can reside in the same nodes 858 and share the same links, but this is not the only possibility. Other 859 options can also be feasible, and may sometimes be necessary. An 860 example is a pure circuit switch (that cannot see individual IP 861 packets), combined with an external controller. Another example may 862 be where there are multiple links between two routers, and all the 863 links are used for data forwarding, but only one is used for carrying 864 the routing session. 866 6.2 Distribution 868 6.2.1 Distribution mechanisms 870 R(7) Relevant changes in the state of the network, including 871 modifications to the topology and changes in the values 872 of dynamic capabilities, MUST be distributed to every 873 entity in the network that needs them in a reliable, and 875 Group B Expires: September 2002 17 876 trusted way at the earliest appropriate time after the 877 change has occurred. 879 R(8) Information MUST NOT be distributed outside areas where 880 it is needed or believed to be needed for the operation 881 of the routing system. 883 R(9) Information MUST be distributed in such a way that it 884 minimizes the load on the network consistent with the 885 required response time of the network to changes. 887 6.2.2 Path advertisement 889 R(10) The router MUST be able to acquire and store additional 890 static and dynamic information relating to the 891 capabilities of the topology and its component nodes and 892 links, which can subsequently be used by path selection 893 methods. 895 The inter-domain routing system must be able to advertise more kinds 896 of information than just connectivity and domain path. 898 R(11) The Routing System MUST support service specifications, 899 e.g. the Service Level Specifications (SLSs) developed by 900 the Differentiated Services working group. [42] 902 Careful attention should be paid to ensuring that the distribution of 903 additional information with path advertisements remains scalable as 904 domains and the Internet get larger, more numerous and more 905 diversified. 907 R(12) The distribution mechanism used for distributing network 908 state information MUST be scalable with respect to the 909 expected size of domains and the volume and rate of 910 change of dynamic state that can be expected. 912 The combination of R(3) and R(3) may result in a compromise between 913 the responsiveness of the network to change and the overhead of 914 distributing change notifications. Also attempts to respond to very 915 rapid changes may damage the stability of the routing system. 917 Possible examples of additional capability information that might be 918 carried include: 920 - QoS information 922 To allow an ISP to sell predictable end-to-end QoS service to any 923 destination, the routing system should have information about the 924 end-to-end QoS. This means that: 926 Group B Expires: September 2002 18 927 R(13) The routing system MUST be able to support different 928 paths for different services. 930 R(14) The routing system MUST be able to forward traffic on the 931 path appropriate for the service selected for the traffic 932 either according to an explicit marking in each packet of 933 the traffic (e.g. MPLS labels, DiffServ PDB's or 934 TOS-values) or implicitly (e.g. the physical or logical 935 port on which the traffic arrives). 937 R(15) The routing system SHOULD also be able to carry 938 information about the expected (or actually, promised) 939 characteristics of the entire path and the price for the 940 service. 942 (If such information is exchanged at all between network operators 943 today, it is through bilateral management interfaces, and not through 944 the routing protocols.) 946 This would allow for the operator to optimise the choice of path 947 based on a price/performance trade-off. 949 In addition to providing dynamic QoS information the system should be 950 able to use static class-of-service information. 952 - security information 954 Security characteristics of other domains (in the path or in the map) 955 can allow the routing entity to choose routing decision based on some 956 political reasons. The information itself is assumed to be so secure 957 that you can trust it. 959 - usage and cost information 961 This can be used for billing and traffic engineering purpose. In 962 order to support cost based routing policies for customers (i.e. peer 963 ISPs), information such as "traffic on this link or path costs XXX 964 per Gigabyte" needs to be advertised, so that the customer can choose 965 a cheap or an expensive route from an economic perspective. 967 - monitored performance 969 Some performance information such as delay and drop frequency can be 970 carried. (This is may only be suitable inside a domain because of 971 trust considerations). This should support at least the kind of 972 delay bound contractual terms that are currently being offered by 973 service providers. Note that these values refer to the outcome of 974 carrying bits on the path, whereas the QOS information refers to the 975 proposed behaviour that results in this outcome. 977 Group B Expires: September 2002 19 978 - Multicast information 980 R(16) The routing system must provide necessary information 981 needed to create multicast distribution trees. This 982 information MUST be provided for one-to-many distribution 983 trees and SHOULD be provided for many-to-many 984 distribution trees. 986 The actual construction of distribution trees is not necessarily done 987 by the routing system. 989 6.2.3 Stability of routing information 991 R(17) The new network architecture MUST be stable without 992 needing global convergence, i.e. convergence is a local 993 property. 995 The degree to which this is possible and the definition of local 996 remains a research topic. Restricting the requirement for convergence 997 to localities will have an effect on all of the other requirements in 998 this section. 1000 R(18) The distribution, and the rate of distribution of changes 1001 MUST NOT affect the stability of the routing information, 1002 e.g. by commencing redistribution of a change before the 1003 previous one had settled. 1005 6.2.3.1 Avoiding routing oscillations 1007 R(19) The routing system MUST minimize oscillations in route 1008 advertisements. 1010 6.2.3.2 Providing loop free routing and forwarding 1012 In line with the separation of concerns of routing and forwarding: 1014 R(20) The distribution of routing information MUST be, so far 1015 as is possible, loop-free. 1017 R(21) The forwarding information created from this routing 1018 information MUST seek to minimize persistent loops in the 1019 data forwarding paths. 1021 It is accepted that transient loops may occur during convergence of 1022 the protocol and that there are trade-offs between loop avoidance and 1023 global scalability. 1025 6.2.3.3 Detection, notification and repair of failures 1027 R(22) The routing system MUST provide means for detecting 1028 failures of both node equipment and communication links. 1030 Group B Expires: September 2002 20 1031 R(23) The routing system SHOULD be able to coordinate responses 1032 to failure detection indications from layer 3 mechanisms 1033 and nodal mechanisms built into the routing system and 1034 from lower layer mechanisms that are propagated up to 1035 Layer 3 in order to determine the root cause of the 1036 failure. This will allow the routing system to react 1037 correctly to the failure by activating appropriate 1038 mitigation and repair mechanisms if required, whilst 1039 ensuring that it does not react if lower layer repair 1040 mechanisms are able to repair or mitigate the fault. 1042 Most layer 3 routing protocols have utilized keepalives or 'hello' 1043 protocols as a means of detecting failures at Layer 3. The keepalive 1044 mechanisms are often complemented by analog (e.g. laser light 1045 detection) and hardware mechanisms (e.g. hardware/software watchdogs) 1046 that are built into routing nodes and communication links. Great 1047 care must be taken to make best possible use of the various failure 1048 repair methods available whilst ensuring that only one repair 1049 mechanism at a time is allowed to repair any given fault: 1050 Interactions between (say) fast reroute mechanisms at layer 3 and 1051 SONET/SDH repair at Layer 1 are highly undesirable and are likely to 1052 cause problems in the network. 1054 R(24) Where a network topology and routing system contains 1055 multiple fault repair mechanisms, the responses of these 1056 systems to a detected failure SHOULD be coordinated so 1057 that the fault is repaired by the most appropriate means, 1058 and no extra repairs are initiated. 1060 R(25) Where specialized packet exchange mechanisms (e.g. layer 1061 3 keepalive or 'hello' protocol mechanisms) are used to 1062 detect failures, the routing system MUST make provision 1063 to allow the rate of transmission of these keepalives to 1064 be configured, including the capability to turn them off 1065 altogether where links are deliberately broken when no 1066 real user or control traffic is present (e.g. ISDN 1067 links). 1069 This will allow the operator to compromise between the speed of failure 1070 detection and the proportion of link bandwidth dedicated to failure 1071 detection. 1073 6.3 Addressing 1075 6.3.1 Support mix of IPv4, IPv6 and other types of addresses 1077 R(26) The routing system MUST support a mix of different kinds 1078 of addresses. 1080 This mix will include at least IPv4 and IPv6 addresses, and 1081 preferably various types of non-IP addresses too. For instance 1082 networks like SDH/SONET and WDM may prefer to use non-IP addresses. 1084 Group B Expires: September 2002 21 1085 It may also be necessary to support multiple sets of 'private' (e.g. 1086 RFC1918) addresses when dealing with multiple customer VPNs. 1088 R(27) The routing system SHOULD support the capability to use a 1089 single topology representation to generate routing and 1090 forwarding tables for multiple address families on the 1091 same network. 1093 This capability would minimise the protocol overhead when exchanging 1094 routes. 1096 6.3.2 Support for domain renumbering/readdressing 1098 R(28) If a domain is subject to address reassignment that would 1099 cause forwarding interruption then the routing system 1100 SHOULD support readdressing (e.g. when a new prefix is 1101 given to an old network, and the change is known in 1102 advance) by maintaining routing during the changeover 1103 period [39], [40]. 1105 6.3.3 Multicast and anycast 1107 R(29) The routing system MUST support multicast addressing, 1108 both within a domain and across multiple domains. 1110 R(30) The routing system SHOULD support anycast addressing 1111 within a domain. The routing system MAY support anycast 1112 addressing across domains. 1114 It is still an open question as to whether it is possible or useful 1115 to support anycast addressing between cooperating domains. 1117 6.3.4 Address scoping 1119 R(31) The routing system MUST support scoping of unicast 1120 addresses, and SHOULD support scopingof multicast and 1121 anycast address types. 1123 For unicast address scoping, as is being designed for IPv6, does not 1124 seem to cause any special problems with respect to routing. IPv6 1125 Inter-domain routing handles only IPv6 global addresses, while intra- 1126 domain routing also needs to be aware of site-local addresses. Link- 1127 local addresses are never routed at all. 1129 For scoping in a more general sense, and for scoping of multicast and 1130 anycast addresses, more study may be needed to identify the 1131 requirements solutions. 1133 6.3.5 Mobility support 1135 Group B Expires: September 2002 22 1136 R(32) The routing system MUST support system mobility (and 1137 movability, and portability, whatever the differences may 1138 be). The term system includes anything from an end system 1139 to an entire domain. 1141 We observe that the existing solutions based on re-numbering and/or 1142 tunneling are designed to work with the current routing, so they do 1143 not add any new requirements to future routing. But the requirement 1144 is general, and future solutions may not be restricted to the ones we 1145 have today. 1147 6.4 Statistics support 1149 R(33) Both the routing and forwarding parts of the routing 1150 system MUST maintain statistical information about the 1151 performance of their functions. 1153 6.5 Management requirements 1155 While the tools of management are outside the scope of routing, the 1156 mechanisms to support the routing architecture and protocols are 1157 within scope: 1159 R(34) Mechanisms to support Operational, Administrative and 1160 Management control of the routing architecture and 1161 protocols MUST be designed into the original fabric of 1162 the architecture. 1164 6.5.1 Simple policy management 1166 The basic aims of this specification are: 1167 - to require less manual configuration than today 1168 - to satisfy both the requirements for easy handling, and maximum 1169 control, i.e. 1170 - All the information should be available 1171 - But should not be visible except for when desired. 1172 - Policies themselves should be advertised and not only the 1173 result of policy, and 1174 - Provide Policy conflict Resolution 1176 R(35) The routing system MUST provide for management of the 1177 system by means of policies; e.g. that can be expressed 1178 in terms of the business and services implemented on the 1179 network and reflect the operation of the network in terms 1180 of the services affected. 1182 R(36) The distribution of policies MUST be amenable to scoping, 1183 to protect proprietary policies that are not of relevance 1184 beyond the local set of domains from distribution. 1186 Group B Expires: September 2002 23 1187 6.5.2 Startup and Maintenance of Routers 1189 A major problem in today's networks is the need to perform initial 1190 configuration on routers from a local interface before a remote 1191 management system can take over. It is not clear that this imposes 1192 any requirements on the routing architecture beyond what is need for 1193 a ZeroConf host. 1195 Similarly, maintenance and upgrade of routers can cause major 1196 disruptions to the network routing because the routing system and 1197 management of routers is not organized to minimize such disruption. 1198 Some improvements have been made, such as graceful restart mechanisms 1199 in protocols, but more needs to be done. 1201 R(37) The routing system and routers SHOULD provide mechanisms 1202 that will minimize the disruption to the network caused 1203 by maintenance and upgrades of software and hardware. It 1204 is recognized that some of the capabilities needed are 1205 outside the scope of the routing architecture (e.g. 1206 minimum impact software upgrade) but the routing system 1207 SHOULD provide the necessary support for such 1208 capabilities. 1210 6.6 Provability 1212 R(38) The routing system and its component protocols MUST be 1213 provably locally convergent under the permitted range of 1214 parameter settings and policy options that the 1215 operator(s) can select. 1217 There are various methods for proof that include, but are not limited 1218 to: mathematical, heuristic, and pattern recognition. No requirement 1219 is made on the method used for proving local convergence properties. 1221 R(39) Routing protocols employed by the routing system and the 1222 overall routing system SHOULD be resistant to bad routing 1223 policy decisions made by operators. 1225 Tools are needed to check compatibility of routing policies. While 1226 these tools are not part of the routing architecture, the mechanisms 1227 to support such tools are. 1229 Routing policies are compatible if their interaction does not cause 1230 divergence. A domain or group of domains in a system is defined as 1231 being convergent if and only if, after an exchange of routing 1232 information, routing tables reach a stable state that does not change 1233 until routing policies or topology changes. 1235 To achieve the above-mentioned goals: 1237 Group B Expires: September 2002 24 1238 R(40) The routing system MUST provide a mechanism to publish 1239 and communicate policies so that operational coordination 1240 and fault isolation is possible. 1242 Tools are required that verify the stability characteristics of the 1243 routing system in specified parts of Internet. The tools should be 1244 efficient (fast) and have a broad scope of operation (check large 1245 portions of Internet). While these tools are not part of the 1246 architecture, developing them is in the interest of the architecture 1247 and should be defined as a Routing Research Group activity while 1248 research on the architecture is in progress. 1250 Tools analyzing routing policies can be applied statically or 1251 (preferably) dynamically. Dynamic solution requires tools that can be 1252 used for run time checking for a source of oscillations that arise 1253 from policy conflicts. Research is needed to prove that there is an 1254 efficient solution to the dynamic checking of oscillations. 1256 6.7 Traffic engineering 1258 The ability to do traffic engineering and get the feedback from the 1259 network that enables traffic engineering are capabilities that should 1260 be included in the future domain architecture. Traffic engineering 1261 is, at base, another alternative or extension for the path selection 1262 mechanisms of the routing system: No fundamental changes to the 1263 requirements are needed but the iterative processes involved in 1264 traffic engineering may require some additional capabilities and 1265 state in the network. 1266 Traffic engineering typically involves a combination of off-line 1267 network planning and administrative control functions in which the 1268 expected and measured traffic flows are examined resulting in changes 1269 to static configurations and policies in the routing system. During 1270 operations under these configurations control the actual flow of 1271 traffic and affect the dynamic path selection mechanisms: The 1272 results are measured and fed back into further rounds of network 1273 planning. 1275 6.7.1 Support for and provision of traffic engineering tools 1277 At present there is an almost total lack of effective traffic 1278 engineering tools, whether on-line at all times for network control 1279 or off-line for network planning. The routing system should 1280 encourage the provision of such tools. 1282 R(41) The routing system MUST generate statistical and 1283 accounting information in such a way that traffic 1284 engineering and network planning tools can be used both 1285 in real time and for off-line planning and management. 1287 Group B Expires: September 2002 25 1288 6.7.2 Support of multiple parallel paths 1290 R(42) The routing system MUST support the controlled 1291 distribution, over multiple links or paths, of traffic 1292 towards the same destination. This applies to domains 1293 with two or more connections to the same neighbor domain, 1294 and to domains with connections to more than one neighbor 1295 domain. The paths need not have the same metric. 1297 R(43) The routing system MUST support forwarding over multiple 1298 parallel paths when available. This support SHOULD extend 1299 to cases where the offered traffic is known to exceed the 1300 available capacity of a single link, and to the cases 1301 where load is to be shared over paths for cost or 1302 resiliency reasons. 1304 R(44) Where traffic is forwarded over multiple parallel paths, 1305 the routing system MUST, so far as is possible, avoid 1306 reordering of packets in individual micro-flows. 1308 R(45) The routing system MUST have mechanisms to allow the 1309 traffic to be reallocated back on to a single path when 1310 the multiple paths are not needed. 1312 6.7.3 Peering support 1314 R(46) The routing system MUST support peer-level connectivity 1315 as well as hierarchical connections between domains. 1317 The network is becoming increasingly complex with private peering 1318 arrangements set up between providers at every level of the hierarchy 1319 of service providers and even by certain large enterprises, in the 1320 form of dedicated extranets. 1322 R(47) The routing system MUST facilitate traffic engineering of 1323 these peer routes so that traffic can be readily 1324 constrained to travel as the network operators desire and 1325 they can consequentially make optimal use of the 1326 available connectivity. 1328 6.8 Support for mid-boxes 1330 One of our assumptions is that NATs and other Mid-boxes such as 1331 firewalls, web proxies and address family (e.g. IPv4 to IPv6) 1332 translators are here to stay. 1334 R(48) The routing system SHOULD work in conjunction with mid- 1335 boxes, e.g. NAT, to aid in bi-directional connectivity 1336 without compromising the additional opacity and privacy 1337 that the mid-boxes offer. 1339 Group B Expires: September 2002 26 1340 This problem is closely analogous to the abstraction problem, which 1341 is already under discussion for the interchange of routing 1342 information between domains. 1344 7. Performance requirements 1346 Over the past several years, the performance of the routing system 1347 has frequently been discussed. The requirements that derive from 1348 those discussions are listed below. Currently the required values 1349 for these performance requirements are left for further discussion. 1351 R(49) The routing system MUST support domains of at least X 1352 systems. A system is taken to mean either an individual 1353 router or a domain. 1355 R(50) Local convergence SHOULD occur within X units of time. 1357 R(51) The routing system MUST be 99.99x?% available. 1359 R(52) The routing system MUST be reliable as measured by TBD. 1361 R(53) The routing system MUST be locally stable as measured by 1362 TBD. 1364 R(54) The routing system MUST be globally stable as measured by 1365 TBD. 1367 R(55) The routing system SHOULD scale to an indefinitely large 1368 number of domains. 1370 In many cases there has been very little data or statistical evidence 1371 for many of the performance claims being made. In recent years 1372 several efforts have been initiated to gather data and do the 1373 analyses required to make scientific assessments of the performance 1374 issues and requirements. In order to complete this section of the 1375 requirements analysis, the data and analyses from these studies needs 1376 to be gathered and collated into this document. This work has been 1377 started but has yet to be completed. 1379 8. Backwards compatibility (cutover) and maintainability 1381 This area poses a dilemma. On one hand it is an absolute requirement 1382 that: 1384 R(56) The introduction of the routing system MUST NOT require 1385 any flag days 1387 Group B Expires: September 2002 27 1388 R(57) The network currently in place MUST continue to run at 1389 least as well as it does now while the new network is 1390 being brought in around it. 1392 However, at the same time, it is also an absolute requirement that: 1394 R(58) The new architecture MUST NOT be limited by the 1395 restrictions that plague today's network. [It has to be 1396 admitted that this is not a well defined requirement, 1397 because we have not fully articulated what the 1398 restrictions might be. Some of these restrictions can be 1399 derived by reading the discussions for the positive 1400 requirements above: It would be a useful exercise to 1401 explicitly list all the restrictions and irritations that 1402 we wish to do away with. It would be further useful to 1403 determine if these restrictions can currently be removed 1404 at reasonable cost or whether we are actually condemned 1405 to live with them.] 1407 Those restrictions cannot be allowed to become permanent baggage on 1408 the new architecture. If they do, the effort to create a new system 1409 will come to naught. It may, however, be necessary to live with some 1410 of them temporarily for practical reasons whilst providing an 1411 architecture which will eventually allow them to be removed. 1413 These three requirements have significance not only for the 1414 transition strategy, but for the architecture itself implying that it 1415 must be possible for an internet such as today's BGP controlled 1416 network, or one of its ASs, to exist as a domain within the new FDR. 1418 9. Security requirements 1420 As previously discussed, one of the major changes to have overtaken 1421 the Internet since its inception, is the erosion of trust between end 1422 users making use of the net, between those users and the suppliers of 1423 services, and between the multiplicity of providers. Hence security, 1424 in all its aspects, will be much more important in the FDR. 1426 It must be possible to secure the routing communication: 1428 R(59) The communicating entities MUST be able to identify who 1429 sent and who received the information (authentication) 1431 R(60) The communicating entities MUST be able to verify that 1432 the information has not been changed on the way 1433 (integrity). 1435 Security is more important in inter-domain routing where the operator 1436 has no control to the other domains, then in intra-domain routing 1437 since all the links and the nodes are under the administration of the 1438 operator and can be expected to share a trust relationship. This 1440 Group B Expires: September 2002 28 1441 property of intra-domain trust, however, should not be taken for 1442 granted: 1444 R(61) Routing communications MUST be secured by default, but an 1445 operator MUST have the option to relax this requirement 1446 within a domain where analysis indicates that other means 1447 (such as physical security) provide an acceptable 1448 alternative. 1450 R(62) The routing communication mechanism MUST be robust 1451 against denial-of-service attacks. 1453 Further considerations that may impose requirements include: 1454 - Whether no one else but the intended recipient must be able to 1455 access (privacy) or understand (confidentiality) the information. 1456 - Whether it is possible to verify that all the information has been 1457 received (non-repudiation). 1458 - Whether there is a need to separate security of routing from 1459 security of forwarding. 1460 - Whether traffic flow security is needed (i.e. whether there is 1461 value in concealing who can connect to whom, and what volumes of 1462 data are exchanged). 1464 Securing the BGP session, as done today, only secures the exchange of 1465 messages from the peering domain, not the content of the information. 1466 In other words, we can confirm that the information we got is what 1467 our neighbor really sent us, but we do not know if this information 1468 (that originated in some remote domain) is true or not. 1470 A decision has to be made on whether to rely on chains of trust (we 1471 trust our peers who trust their peers who..), or whether we also need 1472 authentication and integrity of the information end-to-end. This 1473 information includes both routes and addresses. There has been 1474 interest in having digital signatures both on originated routes, but 1475 also countersignatures by address authorities to confirm that the 1476 originator has authority to advertise the prefix. Even understanding 1477 who can confirm the authority is non-trivial as it might be the 1478 provider who delegated the prefix (with a whole chain of authority 1479 back to ICANN) or it may be straight to an address registry. Where a 1480 prefix delegated by a provider is being advertised though another 1481 provider as in multi-homing, both may have to be involved to confirm 1482 that the prefix may be advertised through the provider who doesn't 1483 have any interest in the prefix! 1485 R(63) The routing system MUST cooperate with the security 1486 policies of mid-boxes whenever possible. 1488 This is likely to involve further requirements for abstraction of 1489 information, as, for example, the firewall is seeking to minimize 1490 interchange of information that could lead to a security breach. The 1492 Group B Expires: September 2002 29 1493 effect of such changes on the end-to-end principle should be 1494 carefully considered as discussed in [32]. 1496 R(64) The routing system MUST be capable of complying with 1497 local legal requirement for interception of 1498 communication. 1500 10.Debatable issues 1502 This section covers issues that need to be considered and resolved in 1503 deciding on a future domain routing architecture. While they can't 1504 be described as requirements, they do affect the types of solution 1505 that are acceptable. The discussions included below are very open- 1506 ended. 1508 10.1Network modeling 1510 The mathematical model that underlies today's routing system uses a 1511 graph representation of the network. Hosts, routers and other 1512 processing boxes are represented by nodes and communications links by 1513 arcs. The model is a topological model in that routing does not need 1514 to directly model the physical length of the links or the position of 1515 the nodes: The model can be transformed to provide a convenient 1516 picture of the network by adjusting the lengths of the arcs and the 1517 layout of the nodes. The connectivity is preserved and routing is 1518 unaffected by the transformation. 1520 The routing algorithms in traditional routing protocols utilize a 1521 small number of results from graph theory. It is only recently that 1522 additional results have been employed to support constraint based 1523 routing for traffic engineering. 1525 The naturalness of this network model and the 'fit' of the graph 1526 theoretical methods may have tended to blind us to alternative 1527 representations and inhibited us from seeking out alternative strands 1528 of theoretical thinking that might provide improved results. 1530 We should not allow this habitual behavior to stop us looking for 1531 alternative representations and algorithms: Topological revolutions 1532 are possible and allowed, at least in theory. 1534 10.2System modeling 1536 The assumption that object modeling of a system is an essential first 1537 step to creating a new system is still novel in this context. 1538 Frequently the effort to object model becomes an end in itself and 1539 does not lead to system creation. But there is a balance and a lot 1540 that can be discovered in an ongoing effort to model a system such as 1541 the future domain routing system. 1543 Group B Expires: September 2002 30 1544 It is recommended that this process be included in the requirements. 1545 It should not, however be a gating event to all other work. 1547 Some of the most important realizations will occur during the process 1548 of determining the following: 1549 - Object classification 1550 - Relationships and containment 1551 - Roles and Rules 1553 10.3 One, two or many protocols 1555 There has been a lot of discussion of whether the FDR protocol 1556 solution should consist of one (probably new) protocol, two (intra 1557 and inter domain) protocols or many protocols. While in the best of 1558 all possible worlds, it might be best to have one protocol that 1559 handles all situations, this seems improbable in this less then best 1560 of all possible worlds. On the other hand, maintaining the 'strict' 1561 division evident in the network today between the IGP and EGP has 1562 been effectively argued elsewhere as being too restrictive an 1563 approach. Given this, and the fact that there are already many 1564 routing protocols in use, the only possible answer seems to be that 1565 the architecture SHOULD support many protocols. It remains an open 1566 issue, one for the solution, to determine if a new protocol needs to 1567 be designed in order to support the highest goals of this 1568 architecture. The expectation is that, yes, a new protocol will need 1569 to be designed. 1571 10.4Class of protocol to use 1573 If a new protocol is required to support the FDR architecture, the 1574 question remains open as to what kind of protocol this ought to be. 1575 It is our expectation that a map distribution protocol will be 1576 required to augment the current path-vector protocol and shortest 1577 path first protocols. 1579 10.5Map abstraction 1581 Assuming that a map distribution protocol is required, what are the 1582 requirements on this protocol? If every detail is advertised 1583 throughout the Internet, there will be a lot of information. 1584 Scalable solutions require abstraction. 1586 - If we summarise too much, some information will be lost on the 1587 way. 1589 - If we summarise too little, then more information then required is 1590 available contributing to scaling limitations. 1592 - One can allow more summarisation, if there also is a mechanism to 1593 query for more details within policy limits. 1595 Group B Expires: September 2002 31 1596 - The basic requirement is not that the information shall be 1597 advertised, but rather that the information shall be available to 1598 those who need it. Of course we should not presuppose a solution 1599 where advertising is the only possible mechanism. 1601 10.6Clear identification for all entities 1603 As in all other fields, the words used to refer to concepts and to 1604 describe operations about routing are important. Rather than describe 1605 concepts using terms that are inaccurate or rarely used in the real 1606 world of networking, it is necessary to make an effort to use the 1607 correct words. Many networking terms are used casually, and the 1608 result is a partial or incorrect understanding of the underlying 1609 concept. Entities such as nodes, interfaces, sub-networks, tunnels, 1610 and the grouping concepts such as ASs, domains, areas, and regions, 1611 need to be clearly identified and defined to avoid mixing from each 1612 other. 1614 There is also a need to separate identifiers (what or who) from 1615 locators (where) from routes (how to reach). 1617 10.7Robustness and redundancy: 1619 The routing association between two domains should survive even if 1620 some individual connection between two routers goes down. 1622 The "session" should operate between logical "routing entities" on 1623 each domain side, and not necessarily be bound to individual routers 1624 or addresses. Such a logical entity can be physically distributed 1625 over multiple network elements. Or it can reside in a single router, 1626 which would default to the current situation. 1628 10.8Hierarchy 1630 A more flexible hierarchy with more levels and recursive groupings in 1631 both upward and downward directions allows more structured routing. 1632 The consequence is that no single level will get too big for routers 1633 to handle. 1635 On the other hand, it appears that the real world Internet is 1636 becoming less hierarchical, so that it will be increasingly difficult 1637 to use hierarchy for scaling control. 1639 Note that groupings can look different depending on which aspect we 1640 use to define them. A DiffServ area, a MPLS domain, a trusted domain, 1641 a QoS area, a multicast domain, etc, do not always coincide. And 1642 neither are they strict hierarchical subsets of each other. The basic 1643 distinction at each level is "this grouping versus everything 1644 outside". 1646 Group B Expires: September 2002 32 1647 10.9Will new control mechanisms be needed? 1649 Is it possible to apply a control theory framework, and analyze the 1650 stability of the control system of the whole network domain, for e.g. 1651 convergence speed and the frequency response, and then use the 1652 results from that analysis to set the timers and other protocol 1653 parameters. 1655 Control theory could also play a part is QoS Routing, by modifying 1656 current link state protocols with link costs dependent on load. 1657 Control theory is used to increase the stability of such systems. 1659 At best, it might be possible to construct a new totally dynamical 1660 routing protocol solely on a control theoretic basis as opposed to 1661 the current protocols which are based in graph theory and static in 1662 nature. 1664 10.10 Byzantium 1666 Is solution to the Byzantine Generals problem a requirement? This is 1667 the problem of reaching a consensus among distributed units if some 1668 of them give misleading answers. The current intra-domain routing 1669 system is, at one level, totally intolerant of misleading 1670 information, but the effect of different sorts of misleading or 1671 incorrect information has vastly varying results, from total collapse 1672 through to purely local disconnection of a single domain. This sort 1673 of behavior is not very desirable. 1675 What are some of the other network robustness issues that must be 1676 resolved? 1678 10.11 VPN support 1680 Today BGP is also used for VPN and other stuff for example as 1681 described in RFC2547 [16]. 1683 Internet routing and VPN routing have different purposes, and most 1684 often exchange different information between different devices. Most 1685 Internet routers do not need to know any VPN specific information. 1686 The concepts should be clearly separated. 1688 But when it comes to the mechanisms, VPN routing can share the same 1689 protocol as ordinary Internet routing, it can use a separate instance 1690 of the same protocol, or it can use a different protocol. All 1691 variants are possible and have their own merits. These requirements 1692 currently are silent on this issue. 1694 10.12 End to end reliability 1696 Group B Expires: September 2002 33 1697 The existing Internet architecture neither requires or provides end- 1698 to-end reliability of control information dissemination. For 1699 example, in distributing VPN information there is, however, a 1700 requirement for end to end reliability of control information, i.e. 1701 the ends of the VPN established need to have a acknowledgement of the 1702 success in setting up the VPN. While it is not necessarily the 1703 function of a routing architecture to provide end-to-end reliability 1704 for this kind of purpose, we must be clear that end-to-end 1705 reliability becomes a requirement if the network has to support such 1706 reliable control signaling. There may be other requirements that 1707 derive from requiring the FDR to support reliable control signaling. 1709 10.13 End to end transparency 1711 The introduction of private addressing schemes, Network Address 1712 Translators and firewalls has significantly reduced the end-to-end 1713 transparency of the network. In many cases the network is also no 1714 longer symmetric, so that communication between two addresses is 1715 possible if the communication session originates from one end but not 1716 from the other. This impedes the deployment of new peer-to-peer 1717 services, and some 'push' services where the server in a client- 1718 server arrangement originates the communication session. Whether a 1719 new routing system either can or should seek to restore this 1720 transparency is an open issue. 1722 A related issue is the extent to which end user applications should 1723 seek to control the routing of communications in the rest of the 1724 network. 1726 11.Bibliography 1728 The following were consulted in the writing of this document. Not 1729 all are specifically referred to in the document, but all helped in 1730 forming this work. These references are not intended as normative. 1732 [1] Clark, D., "Policy Routing in Internet 1733 Protocols", RFC 1102, May 1989. 1735 [2] Estrin, D., "Requirements for Policy Based 1736 Routing in the Research Internet", RFC 1125, 1737 November 1989. 1739 [3] Steenstrup, M,. "An Architecture for Inter-Domain 1740 Policy Routing", RFC 1478, June 1993 1742 [4] Little, M., "Goals and Functional Requirements 1743 for Inter-Autonomous System Routing", RFC 1126, 1744 July 1989. 1746 [5] Perlman, R., "Interconnections Second Edition", 1747 1999, Addison Wesley Longman, Inc. 1749 Group B Expires: September 2002 34 1751 [6] Perlman, R., "Network Layer Protocols with 1752 Byzantine Robust-ness", Ph.D. Thesis, Department 1753 of Electrical Engineering and Computer Science, 1754 MIT, August 1988. 1756 [7] Castineyra, I., Chiappa, N., Steenstrup, M., "the 1757 Nimrod Routing Architecture", RFC1992, Aug 1996 1759 [8] Chiappa, N., "IPng Technical Requirements of the 1760 Nimrod Routing and Addressing Architecture", RFC 1761 1753, Dec 1994 1763 [9] Chiappa, N., "A New IP Routing and Addressing 1764 Architecture" 1766 [10] Wroclowski, J., The Metanet White Paper - 1767 Workshop on Research Directions for the Next 1768 Generation Internet, 1995 1770 [11] Labovitz, C., Ahuja, A., Farnam J., Bose, A., 1771 Experimental Measurement of Delayed Convergence, 1772 NANOG 1774 [12] Griffin, T.G., Wilfong, G., An Analysis of BGP 1775 Convergence Properties, SIGCOMM 1999 1777 [13] Huston, G., Commentary on Inter-Domain Routing 1778 in the Internet,RFC 3221, Dec 2001 1780 [14] Alaettinoglu, C., Jacobson, V. and Yu, H, , 1781 Towards Milli-Second IGP Convergence, Internet 1782 Draft - draft-alaettinoglu-isis-convergence-00, 1783 Nov 2000 Work in Progress 1785 [15] Sandick, H., Squire, M., Cain, B., Duncan, I., 1786 Haberman, B., Fast LIveness Protocol (FLIP), 1787 Internet Draft - draft-sandiick-flip-00, 1788 Feb 2000, Work in Progress 1790 [16] Rosen, E. and Rekhter, Y., BGP/MPLS VPNs, 1791 RFC2547, March 1999 1793 [17] Clark, D., Chapin, L., Cerf, V., Braden, R., 1794 Hobby, R., "towards the Future Internet 1795 Architecture", RFC1287, December 1991 1797 [18] Jacobson, V., Nichols, K. and Poduri, K., The 1798 'Virtual Wire' Behavior Aggregate, Internet Draft 1799 - draft-ietf-diffserv-pdb-vw-00, July 2000, Work 1800 in Progress 1802 Group B Expires: September 2002 35 1804 [19] Seddigh, N., Nandy, B., and Heinanen, J., 1805 An Assured Rate Per-Domain Behaviour for 1806 Differentiated Services, Internet Draft - 1807 draft-ietf-diffserv-pdb-ar-00, Feb 2001, Work in 1808 Progress 1810 [20] McPherson, D., Gill, V., Walton, D. and Retana, 1811 A., "BGP Persistent Route Oscillation Condition", 1812 Internet Draft - draft-mcpherson-bgp-route- 1813 oscillation-00, Dec 2000, Work in Progress 1815 [21] Hain, T, "Architectural Implications of NAT", RFC 1816 2993, November 2000 1818 [22] McPherson, D. and Przygienda, T., OSPF Transient 1819 Blackhole Avoidance, Internet Draft - draft- 1820 mcpherson-ospf-transient-00, July 2000 Work In 1821 Progress 1823 [23] [BGMP] Thaler, D., Estrin, D. and Meyer, D. 1824 (editors), Border Gateway Multicast Protocol 1825 (BGMP): Protocol Specification, Internet Draft - 1826 draft-ietf-bgmp-spec-02, Nov 2000 Work in 1827 progress 1829 [24] Rosen, E. Et al., Multiprotocol Label Switching 1830 Architecture, RFC 3031 1832 [25] Ashwood-Smith, P. Et al., Generalized MPLS - 1833 Signaling Functional Description, Internet Draft 1834 - draft-ietf-mpls-generalized-signaling-01.txt, 1835 Work in progress 1837 [26] IETF Resource Allocation Protocol working group, 1838 http://www.ietf.org/html.charters/rap- 1839 charter.html 1841 [27] IETF Configuration management with SNMP working 1842 group, 1843 http://www.ietf.org/html.charters/snmpconf- 1844 charter.html 1846 [28] IETF Policy working group, 1847 http://www.ietf.org/html.charters/policy- 1848 charter.html 1850 [29] Yu J., "Scalable Routing Design Principles", RFC 1851 2791 1853 [30] Telcordia Technologies Netsizer web site 1854 http://www.netsizer.com/ 1856 Group B Expires: September 2002 36 1858 [31] Inference of Shared Risk Link Groups, 1859 draft-many-inference-srlg-00.txt, 1860 Work in progress 1862 [32] Blumenthal, Marjory S. and Clark, David D., 1863 Rethinking the design of the Internet: 1864 The end to end arguments vs. the brave new world, 1865 May 2001, 1866 http://ana-www.lcs.mit.edu/anaweb/papers.html 1868 [33] Lang et al, Link Management Protocol, 1869 draft-lang-mpls-lmp-02.txt, 1870 Work in progress 1872 [34] Xu, Z., Dai, S. and Garcia-Luna-Aceves, J.J., 1873 A More Efficient Distance Vector Routing 1874 Algorithm, Proc. IEEE MILCOM 97, Monterey, 1875 California, November 2-5, 1997, 1876 http://www.cse.ucsc.edu/research/ccrg/ 1877 publications/zhengyu.milcom97.pdf 1879 [35] Bradner, S. and Mankin, A., "The Recommendation 1880 for the IP Next Generation Protocol", RFC 1752, 1881 January 1995. 1883 [36] ISO/IEC, "Protocol for Exchange of Inter-Domain 1884 Routeing Information among Intermediate 1885 Systems to support Forwarding of ISO 8473 PDUs", 1886 International Standard 10747, 1887 ISO/IEC JTC 1,Switzerland 1993 1889 [37] Bates, T., Rekhter, Y., Chandra, R. and Katz, D, 1890 "Multiprotocol Extensions to BGP-4", 1891 RFC2858, June 2000 1893 [38] Berkowitz, H. and Krioukov, D, "To Be Multihomed: 1894 Requirements and Definitions", 1895 draft-berkowitz-multirqmt-02.txt, 1896 Work in progress. 1898 [39] Ferguson, P. and Berkowitz, H. "Network 1899 Renumbering Overview: Why would I want it and 1900 what is it anyway?", RFC2071, January 1997 1902 [40] Berkowitz, H., "Router Renumbering Guide", 1903 RFC2072, January 1997 1905 [41] [History] Doria (ed), draft-groupb-irtf-rr- 1906 history-00.txt, work in progress 1908 [42] Grossman, Dan, "New Terminology and 1909 Clarifications for Diffserv", draft-ietf- 1911 Group B Expires: September 2002 37 1912 diffserv-new-terms-08.txt, January 2002, Work in 1913 progress. 1915 [43] Broido, A., Nemeth, e., kc, and elves., Internet 1916 Expansion, Refinement and Churn, Presentation at 1917 Nanog, Feb 2002 1919 12.Author's Addresses 1921 Elwyn Davies 1922 Nortel Networks 1923 London Road 1924 Harlow, Essex CM17 9NA 1925 UK 1926 Phone: +44-1279-405498 1927 Email: elwynd@nortelnetworks.com 1929 Avri Doria 1930 Div. of Computer Communications 1931 Lulea University of Technology 1932 S-971 87 Lulea 1933 Sweden 1934 Phone: (+46) 920 46 3030 1935 Email: avri@sm.luth.se 1937 Howard Berkowitz 1938 Gett Communications 1939 5012 25th Street South 1940 Arlington, VA 22206 1941 USA 1942 Phone +1 703 998 5819 1943 Email: hcb@gettcomm.com 1945 Dmitri Krioukov 1946 Nortel Networks 1947 2325 Dulles Corner Boulevard 1948 th 1949 11 Floor 1950 Herndon 1951 VA 20171, USA 1952 Phone: +1 571 331 1104 1953 Email: dima@krioukov.net 1955 Malin Carlzon 1956 Royal Institute of Technology 1957 Network Operating Centre 1958 KTHNOC 1959 SE-100 44 Stockholm 1960 Sweden 1961 Phone: +46 70 269 6519 1962 Email: malin@sunet.se 1964 Group B Expires: September 2002 38 1965 Anders Bergsten 1966 Telia Research AB 1967 Aurorum 6 1968 S-977 75 Lulea 1969 Sweden 1970 Phone: +46 920 754 50 1971 Email: anders.p.bergsten@telia.se 1973 Olle Pers 1974 Telia Research AB 1975 S- 123 86 Farsta 1976 Sweden 1977 Phone: +46 8 713 8182 1978 Email: olle.k.pers@telia.se 1980 Yong Jiang 1981 Telia Research AB 1982 S- 123 86 Farsta 1983 Sweden 1984 Phone: +46 8 713 8125 1985 Email: yong.b.jiang@telia.se 1987 Lenka Carr Motyckova 1988 Div. of Computer Communications 1989 Lulea University of Technology 1990 S-971 87 Lulea 1991 Sweden 1992 Phone: +46 920 91769 1993 Email: lenka@sm.luth.se 1995 Pierre Fransson 1996 Div. of Computer Communications 1997 Lulea University of Technology 1998 S-971 87 Lulea 1999 Sweden 2000 Phone: +46 70 646 0384 2001 Email: pierre@cdt.luth.se 2003 Olov Schelen 2004 Div. of Computer Communications 2005 Lulea University of Technology 2006 S-971 87 Lulea 2007 Sweden 2008 Phone: +46 70 536 2030 2009 Email: Olov.Schelen@cdt.luth.se 2011 Group B Expires: September 2002 39 2012 Tove Madsen 2013 Utfors Bredband AB 2014 R�sundav�gen 12 2015 P.O. Box 525 2016 SE-169 29 Solna 2017 Sweden 2018 Phone: +46 8 5270 5040 2019 Email: tove.madsen@utfors.se 2021 Group B Expires: September 2002 40