IRTF Routing Research Avri Doria (co-editor) Internet Draft Lulea University of Technology Elwyn Davies (co-editor) Nortel Networks Document: draft-irtf-routing-reqs-groupb-00.txt February, 2002 Future Domain Routing Requirements Group B contribution Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Discussion and suggestions for improvement are requested. This document will expire before August, 2002. Distribution of this draft is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This draft is the product of Group B, which is one of, at least, two subgroups in the IRTF-Routing Research Group working on requirements for routing solutions for the future. This document sets out a set of requirements that we believe are important for the future routing architecture and future routing protocols. It should be noted that the IRTF-Routing Research group does not endorse this set of requirements or any other set of requirements as the one and only set of requirements. Group B 1 INTERNET DRAFT FDR Requirements February, 2002 Acknowledgements The draft is derived from draft-davies-fdr-reqs-01.txt that was produced by Babylon. Babylon is a loose association of individuals from academia, service providers and vendors whose goal is to discuss issues in Internet routing with the intention of finding solutions for those problems. The individual members who contributed materially to this draft are: Anders Bergsten, Howard Berkowitz, Malin Carlzon, Lenka Carr Motyckova, Elwyn Davies, Avri Doria, Pierre Fransson, Yong Jiang, Dmitri Krioukov, Tove Madsen, Olle Pers, and Olov Schelen. Thanks also go to the members of Babylon and others who did substantial reviews of this material. Specifically we would like to acknowledge the helpful comments and suggestions of the following individuals: Loa Andersson, Tomas Ahlstr÷m, Erik Êman, Thomas Eriksson, Niklas Borg, Nigel Bragg, Thomas Chmara, Krister Edlund, Owe Grafford, Torbj÷rn Lundberg, Jasminko Mulahusic, Florian-Daniel Otel, Bernhard Stockman, Tom Worster, Roberto Zamparo. In addition, the authors are indebted to the folks who wrote all the references we have consulted in putting this paper together. This includes not only the references explicitly listed below, but also those who contributed to the mailing lists we have been participating in for years. Finally, it is the editors who are responsible for any lack of clarity, any errors, glaring omissions or misunderstandings. Changes from Draft-davies-fdr-reqs-01.txt - The historical background has been separated into another I-D for which we plan to seek Informational RFC status. - The actual requirements (where they are fully crystallized) have been individually numbered and isolated from surrounding discussion material. Group B Expires: September 2002 2 INTERNET DRAFT FDR Requirements February, 2002 Contents 1. Introduction....................................................4 2. Underlying principles...........................................4 2.2 Influences on a changing network...........................5 2.3 High level goals...........................................6 3. High level user requirements....................................9 3.1 Organisational users......................................10 3.2 Individual users..........................................12 4. Mandated constraints...........................................13 4.1 The federated environment.................................13 4.2 Working with different sorts of networks..................13 4.3 Delivering diversity......................................14 4.4 When will the new solution be required?...................14 5. Assumptions....................................................15 6. Functional requirements........................................16 6.1 Topology..................................................16 6.2 Distribution..............................................17 6.3 Addressing................................................21 6.4 Statistics support........................................23 6.5 Management requirements...................................23 6.6 Provability...............................................24 6.7 Traffic engineering.......................................25 6.8 Support for mid-boxes.....................................26 7. Performance requirements.......................................27 8. Backwards compatibility (cutover) and maintainability..........27 9. Security requirements..........................................28 10. Debatable issues..............................................30 10.1 Network modeling.......................................30 10.2 System modeling........................................30 10.3 One, two or many protocols.............................31 10.4 Class of protocol to use...............................31 10.5 Map abstraction........................................31 10.6 Clear identification for all entities..................32 10.7 Robustness and redundancy:.............................32 10.8 Hierarchy..............................................32 10.9 Will new control mechanisms be needed?.................33 10.10 Byzantium..............................................33 10.11 VPN support............................................33 10.12 End to end reliability.................................33 10.13 End to end transparency................................34 11. Bibliography..................................................34 12. Author's Addresses............................................38 Group B Expires: September 2002 3 INTERNET DRAFT FDR Requirements February, 2002 1. Introduction It is generally accepted that there are major shortcomings in the inter-domain routing of the Internet today and that these may result in meltdown within an unspecified period of time. Remedying these shortcomings will require extensive research to tie down the exact failure modes that lead to these shortcomings and identify the best techniques to remedy the situation. Various developments in the nature and quality of the services that users want from the Internet are difficult to provide within the current framework as they impose requirements never foreseen by the original architects of the Internet routing system. The potential advent of IPv6 and the application of IP mechanisms to private commercial networks offering specific service guarantees as an improvement over the best efforts services of the Public Internet epitomize the kind of radical changes which have to be accommodated: Major changes to the inter-domain routing system are inevitable if it is to provide an efficient underpinning for the radically changed and increasingly, commercially-based networks which rely on the IP protocol suite. 2. Underlying principles Although inter-domain routing is seen as the major source of problems, the interactions with intra-domain routing and the constraints that confining changes to the inter-domain arena would impose, means that we should consider the whole area of routing as an integrated system. This is done for 2 reasons: - Requirements should not presuppose the solution. A continued commitment to the current definitions and split between inter- domain and intra-domain routing would constitute such a presupposition. Therefore the name Future Domain Routing(FDR) is being used in this document, - As an acknowledgement of how intertwined inter-domain and intra- domain routing are within today's routing architecture. We are aware that using the term Domain Routing is already fraught with danger because of possible misinterpretation due to prior usage. The meaning of Domain Routing will be developed implicitly throughout the document, but a little advance explicit definition of the word 'domain' is required, as well as some expansion on the scope of 'routing'. This document uses domain in a very broad sense to mean any collection of systems or domains that come under a common authority that determines the attributes defining, and the policies controlling, that collection. The use of domain in this context is very similar to the concept of Region that was put forth by John Group B Expires: September 2002 4 INTERNET DRAFT FDR Requirements February, 2002 Wroclawski in his Metanet model [10]. The idea includes the notion that within a domain certain system attributes will characterize the behavior of the systems in the domain and that there will be borders between domains. The idea of domain presented does not inherently presuppose that the identifying behaviors between two domains are to be the same. Nor does it presuppose anything about the hierarchical nature of domains. Finally it does not place restrictions on the nature of the attributes that might be used to determine membership in a domain. Since today's routing domains are a subset of all domains as conceived of in this document, there has been no attempt to create a new term. Current practice stresses the need to separate the concerns of the control plane in a router and the forwarding plane: This document will follow this practice, but we still use the term 'routing' as a global portmanteau to cover all aspects of the system. Specifically however routing will be used to mean the process of discovering, interpreting and distributing information about the logical and topological structure of the network. 2.1.1 Inter-domain and intra-domain Throughout this document the terms intra-domain and inter-domain will be used. These terms SHOULD NOT be understood to imply that there is one intra-domain and one inter-domain. Rather these SHOULD be understood as relative terms. In all case of domains there will be a set of network systems that are within that domain and routing between these systems will be termed intra-domain. In some cases there will be routing between domains, which will be termed inter- domain. It is possible that the same routing activities can be viewed as intra-domain from one perspective and inter-domain from another perspective. 2.2 Influences on a changing network The development of the Internet is likely to be driven by a number of changes that will affect the organization and the usage of the network, including: - Ongoing evolution of the commercial relationships between (connectivity) service providers, leading to changes in the way in which peering between providers is organised and the way in which transit traffic is routed - Requirements for traffic engineering within and between domains including coping with multiple paths between domains - Potential addition of a second IP addressing technique through IPv6. - The use of VPNs and private address space with IPv4, and possibly IPv6 - Evolution of the end-to-end principle to deal with the expanded role of the Internet as discussed in [32]]. This paper discusses the possibility that the range of new requirements, especially the social and techno-political ones, which are being placed on the Group B Expires: September 2002 5 INTERNET DRAFT FDR Requirements February, 2002 future Internet, may compromise the Internet's original design principles. This might cause the Internet to lose some of its key features, in particular its ability to support new and unanticipated applications. The discussion is linked to the rise of new stakeholders in the Internet, especially ISPs; new government interests; the changing motivations of the ever growing user base; and the tension between the demand for trustworthy overall operation and the inability to trust the behaviour of individual users. - Incorporation of alternative forwarding techniques such as the explicit routing (pipes) supplied by the MPLS [24] and GMPLS environments [25]. - Integrating additional constraints into route determination from interactions with other layers (e.g. Shared Risk Link Groups [31]) - Support for alternative and multiple routing techniques that are better suited to delivering types of content organised other than into IP addressed packets. Philosophically, the Internet has the mission of transferring information from one place to another. Conceptually, this information is rarely organised into conveniently sized, IP-addressed packets and the FDR needs to consider how the information (content) to be carried is identified, named and addressed. Routing techniques can then be adapted to handle the expected types of content. 2.3 High level goals This section attempts to answer two questions: - What are we trying to achieve in a new architecture? - Why should the Internet community care? There is a third question that needs to be answered as well, but which, for the present, is mostly not explicitly discussed: - How will we know when we have succeeded? 2.3.1 Providing a routing system matched to domain organization Many of today's routing problems are caused by a routing system that is not well matched to the organization and policies which it is trying to support. It is our goal to develop a routing architecture where even domain organization that is not envisioned today can be served by a routing architecture that matches its requirements. We will know when this goal is achieved when the desired policies, rules and organization can be mapped into the routing system in a natural, consistent and simply understood way. 2.3.2 Supporting a range of different communication services Today's routing protocols only support a single data forwarding service that is typically used to deliver a best efforts service in the Public Internet. On the other hand, with, for example, DiffServ Group B Expires: September 2002 6 INTERNET DRAFT FDR Requirements February, 2002 it is possible to construct a number of different bit transport services within the network. Using some of the per-domain behaviors (PDB)s that have been discussed in the IETF, it should be possible to construct services such as Virtual Wire [18] and Assured Rate [19]. Providers today offer rudimentary promises about how traffic will be handled in the network, for example delay and long-term packet loss guarantees, and this will probably be even more relevant in the future. Communicating the service characteristics of paths in routing protocols will be necessary in the near future, and it will be necessary to be able to route packets according to their service requirements. Thus, a goal of this architecture is to allow for adequate information about path service characteristics passed between domains and consequently allow the delivery of bit transport services other than the best-effort datagram connectivity service that is the current common denominator. 2.3.3 Scaleable well beyond current predictable needs Any proposed new FDR system should scale beyond the size and performance we can foresee for the next ten years. The previous IDR proposal has, with some massaging, held up for somewhat over ten years in which time the Internet has grown far beyond the predictions that were made in the requirements that were placed on it originally. Unfortunately, we will only know if we have succeeded in this goal if the FDR system survives beyond its design lifetime without serious massaging. Failure will be much easier to spot! 2.3.4 Supporting alternative forwarding mechanisms With the advent of circuit based technologies (e.g., MPLS [24] used for RSVP-TE or CR-LDP for traffic engineering, GMPLS [25]) managed by IP routers there are forwarding mechanisms other than the datagram service that need to be supported by the routing architecture. An explicit goal of this architecture is to add support for forwarding mechanisms other then the current hop-by-hop datagram forwarding service driven by globally unique IP addresses. 2.3.5 Supporting separation of topology map and connectivity service It is envisioned that an organization can support multiple services on top of a single network. These services can, for example, be of different quality, of different type of connectivity, or different protocols (e.g. IPv4 and IPv6). For all these services there may be common domain topology, even though the policies controlling the routing of information might differ from service to service. Group B Expires: September 2002 7 INTERNET DRAFT FDR Requirements February, 2002 Thus, a goal with this architecture is to support separation between creation of a domain (or organization) topology map and service creation. 2.3.6 Achieving separation between routing and forwarding The architecture of a router is composed of two main separable parts; control and forwarding. These components, while inter-dependent, perform functions that are largely independent of each other. Control (routing, signaling, and management) is typically done in software while forwarding typically is done with specialized ASICs or network processors. The nature of an IP based network today is that control and data protocols share the same network and forwarding regime. This may not always be the case in future networks and we should be careful to avoid building this sharing in as an assumption in the FDR. A goal of this architecture is to support full separation of control and forwarding, and to consider what additional concerns might be properly considered separately (e.g. adjacency management). 2.3.7 Providing for use of different routing paradigms in different areas of the same network A number of different routing paradigms have been used or researched in addition to conventional shortest path hop-by-hop paradigm that is the current mainstay of the Internet. In particular, differences in underlying transport networks may mean that other kinds of routing are more relevant, and the perceived need for traffic engineering will certainly alter the routing chosen in various domains. Explicitly, one of these routing paradigms should be the current routing paradigm, so that the new paradigms will inter-operate in a backwards-compatible way with today's system. This will facilitate a migration strategy that avoids flag days. 2.3.8 Preventing denial of service and other security attacks Currently, existence of a route to a destination effectively implies that anybody who can get a packet onto the network is entitled to use that route. Whilst there are limitations to this generalization, this is a clear invitation to denial of service attacks. A goal of the FDR system should be to allow traffic to be specifically linked to whole or partial routes so that a destination or link resources can be protected from unauthorized use. 2.3.9 Providing provable convergence with verifiable policy interaction It has been shown both analytically by Griffin et al (see [12]) and practically (see [20]) that BGP will not converge stably or is only Group B Expires: September 2002 8 INTERNET DRAFT FDR Requirements February, 2002 meta-stable (i.e. will not reconverge in the face of a single failure) when certain types of policy constraint are applied to categories of network topology. The addition of policy to the basic distance vector algorithm invalidates the proofs that could be applied to a policy free implementation. It has also been argued that global convergence may no longer be a necessary goal and that local convergence may be all that is required. A goal of the FDR should be to achieve provable convergence of the protocols used which may involve constraining the topologies and domains subject to convergence. This will also require vetting the policies imposed to ensure that they are compatible across domain boundaries and result in a consistent policy set. 2.3.10 Providing robustness despite errors and failures From time to time in the history of the Internet there have been occurrences where people misconfiguring routers have destroyed global connectivity. This should never be possible. A goal of the FDR is to be robust to configuration errors and failures. This should probably involve ensuring that the effects of misconfiguration and failure can be confined to some suitable locality of the failure or misconfiguration. 2.3.11 Simplicity in management With the policy work ([26], [27] and [28]) that has been done at IETF there exists an architecture that standardizes and simplifies management of QoS. This kind of simplicity is needed in a future domain routing architecture and its protocols. A goal of this architecture is to make configuration and management of inter-domain routing as simple as possible. 2.3.12 The legacy of RFC1126 RFC1126 outlined a set of requirements that were used to guide the development of BGP. While the network is definitely different then it was in 1989, many of the same requirements remain. A future domain routing has to support as its base requirement, the level of function that is available today. A detailed discussion of RFC1126 and it requirements can be found in [41]. Those requirements, while specifically spelled out in that document are to be subsumed by the requirements in this document. 3. High level user requirements Group B Expires: September 2002 9 INTERNET DRAFT FDR Requirements February, 2002 This section considers the requirements imposed by the target audience of the FDR both in terms of organizations that might own networks, which would use FDR, and the human users who will have to interact with the FDR. 3.1 Organisational users The organizations that own networks connected to the Internet have become much more diverse since RFC1126 [4] was published. In particular a major part of the network are now owned by commercial service provider organizations in the business of making profits from carrying data traffic. 3.1.1 Commercial service providers The routing system must take into account the commercial service provider's for commercial secrecy and security, as well as allowing them to organize their business as flexibly as possible. Service providers will often wish to conceal the details of the network from other connected networks. So far as is possible, the routing system should not require the service providers to expose more details of the topology and capability of their networks than is strictly necessary. Many service providers will also offer contracts to their customers in the form of Service Level Agreements (SLAs) and the routing system must allow the providers to support these SLAs through traffic engineering and load balancing, as well as multihoming, allowing them to achieve the degree of resilience and robustness that they need. Service providers can be categorized as - Global Service Providers (GSPs) with networks that have a global reach. Such providers may, and usually will, wish to constrain traffic between their customers to run entirely on their networks. Such providers will interchange traffic at multiple peering points with other GSPs and need extensive policy-based controls to control the interchange of traffic. Peering may be through the use of dedicated private lines between the partners or increasingly through Internet Exchange Points. - National Service Providers (NSPs) that are similar to GSPs but typically cover one country. Such organizations may operate as a federation that provides similar reach to a GSP and may wish to be able to steer traffic preferentially to other federation members to achieve global reach. - Local Internet Service Providers (ISPs) operate regionally and will typically purchase transit capacity from NSPs or GSPs to provide global connectivity, but may also peer with neighbouring ISPs. Group B Expires: September 2002 10 INTERNET DRAFT FDR Requirements February, 2002 The routing system should be sufficiently flexible to accommodate the continually changing business relationships of the providers, and the various levels of trustworthiness that they apply to customers and partners. Service providers will need to be involved in accounting for Internet usage, monitoring the traffic, and may be involved in government action to tax the usage of the Internet, enforce social mores and intellectual property rules or apply surveillance to the traffic to detect or prevent crime. 3.1.2 Enterprises The leaves of the network domain graph are in many cases networks supporting a single enterprise. Such networks cover an enormous range of complexity with some multi-national companies owning networks that rival the complexity and reach of a GSP whereas many fall into the Small Office-Home Office (SOHO) category. The routing system should allow simple and robust configuration and operation for the SOHO category, whilst effectively supporting the larger enterprise. Enterprises are particularly likely to lack the capability to configure and manage a complex routing system and every effort should be made to provide simple configuration and operation for such networks. Enterprises will also need to be able to change their service provider with ease. Whilst this is predominantly a naming and addressing issue, the routing system must be able to support seamless changeover, for example, by coping with a changeover period when both sets of addresses are in use. Enterprises will wish to be able to multihome to one or more providers as one possible means of enhancing the resilience of their network. Enterprises will also frequently need to control the trust that they place both in workers and external connections through firewalls and similar mid-boxes placed at their external connections. 3.1.3 Domestic networks Increasingly domestic, i.e. non business home, networks are likely to be 'always on' and will resemble SOHO enterprises networks with no special requirements of the routing system. The routing system must support dial-up users. 3.1.4 Internet exchange points Group B Expires: September 2002 11 INTERNET DRAFT FDR Requirements February, 2002 Peering of service providers, academic networks and larger enterprises is increasingly happening at specific Internet Exchange Points where many networks are linked together in a relatively small physical area. The resources of the exchange may be owned by a trusted third party or owned jointly by the connecting networks. The routing systems should support such exchange points without requiring the exchange point to either operate as a superior entity with every connected network logically inferior to it or requiring the exchange point to be a member of one (or all) connected networks. The connecting networks have to delegate a certain amount of trust to the exchange point operator. 3.1.5 Content providers Content providers are at one level a special class of enterprise, but the desire to deliver content efficiently means that a content provider may provide multiple replicated origin servers or caches across a network. These may also be provided by a separate content delivery service. The routing system should facilitate delivering content from the most efficient location. 3.2 Individual users This section covers the most important human users of the FDR and their expected interactions with the system. 3.2.1 All end users The routing system must continue to deliver the current global connectivity service (i.e. any address to any other address, subject to policy constraints) that has always been the basic aim of the Internet. End user applications should be able to request, or have requested on their behalf by agents and policy mechanisms, end-to-end communication services with different QoS characteristics as compared with the best efforts service that is the foundation of today's Internet. It should be possible to request both a single service channel and a bundle of service channels delivered as a single entity. 3.2.2 Network planners The routing system should allow them to plan and implement a network that can be proved to be stable and will meet their traffic engineering requirements. 3.2.3 Network operators The routing system should, so far as is possible, be simple to configure operate and troubleshoot, behave in a predictable, stable fashion and deliver appropriate statistics and events to allow the Group B Expires: September 2002 12 INTERNET DRAFT FDR Requirements February, 2002 network to be managed and upgraded in an efficient and timely fashion. 3.2.4 Mobile end users The routing system must support mobile end users. It is clear that mobility is becoming a predominant mode for network access. 4. Mandated constraints While many of the requirement to which the protocol must respond are technical, some aren't. These mandated constraints are those that are determined by conditions of the world around us. Understanding these requirements requires and analysis of the world in which these systems will be deployed. The constraints include those that are determined by: - Environmental factors. - Geography - Political boundaries and considerations - Technological factors such as the prevalence of different levels of technology in the developed world as opposed to in the developing or undeveloped world. 4.1 The federated environment The graph of the Internet network with routers and other control boxes at the nodes and communication links along the edges is today partitioned administratively into a large number of disjoint domains. A common administration may have responsibility for one or more domains that may or may not be adjacent in the graph. Commercial and policy constraints affecting the routing system will typically be exercised at the boundaries of these domains where traffic is exchanged between the domains. The perceived need for commercial confidentiality will seek to minimise the control information transferred across these boundaries, leading to requirements for aggregated information, abstracted maps of connectivity exported from domains and mistrust of supplied information. The perceived desire for anonymity may require the use of zero- knowledge security protocols to allow users to access resources without exposing their identity. The requirements should provide the ability for groups of peering domains to be treated as a complex domain. These complex domains could have a common administrative policy. 4.2 Working with different sorts of networks Group B Expires: September 2002 13 INTERNET DRAFT FDR Requirements February, 2002 The diverse Layer 2 networks over which the layer 3 routing system is implemented have typically been operated totally independently from the layer 3 network. Consideration needs to be given to the degree and nature of interchange of information between the layers that is desirable. In particular, the need for robustness through diverse routing implies knowledge of the underlying networks to be able to guarantee the robustness. Mobile access networks may also impose extra requirements on Layer 3 routing. 4.3 Delivering diversity The routing system is operating at Layer 3 in the network. To achieve robustness and resilience at this layer requires that where multiple diverse routes are employed as part of delivering the resilience, the routing system at Layer 3 needs to be assured that the Layer 2 and lower routes are really diverse. The 'diamond problem' is the simplest form of this problem - a layer 3 provider attempting to provide diversity buys layer 2 services from two separate providers who in turn buy wayleaves from the same provider: Layer 3 service / \ / \ Layer 2 Layer 2 Provider A Provider B \ / \ / Trench provider Now when the backhoe cuts the trench, the Layer 3 provider has no resilience unless he had taken special steps to verify that the trench wasn't common. The routing system should facilitate avoidance of this kind of trap. Some work is going on to understand the sort of problems that stem from this requirement, such as the work on Shared Risk Link Groups [31]. Unfortunately, the full generality of the problem requires diversity be maintained over time between an arbitrarily large set of mutually distrustful providers. For some cases, it may be sufficient for diversity to be checked at provisioning or route instantiation time, but this remains a hard problem requiring research work. 4.4 When will the new solution be required? There is a full range of opinion on this subject. An informal survey indicates that the range varies from 2 years to 6 years. And while there are those, possibly outliers, who think there is no need for a new routing architecture as well as those who think a new architecture was needed years ago, the median seems to lie at around Group B Expires: September 2002 14 INTERNET DRAFT FDR Requirements February, 2002 4 years. As in all projections of the future this is largely not provable at this time. 5. Assumptions In projecting the requirements for the Future Domain Routing a number of assumptions have been made. The requirements set out should be consistent with these assumptions, but there are doubtless a number of other assumptions that are not explicitly articulated here: 1. The number of hosts today is somewhere in the area of 100 Million. With dial in and NATs this is likely to turn into up to 500 Million users (see [30]). In a number of years, with wireless accesses and different appliances attaching to the Internet, we are likely to see a couple of Billion (10^9) 'users' on the Internet. The number of globally addressable hosts is very much dependent on how common NATs will be in the future. 2. NATs, firewalls and other mid-boxes exist and we cannot assume that they will cease being a presence in the networks. 3. The number of operators in the Internet will probably not grow very much, as there is a likelihood that operators will tend to merge. However, as Internet-connectivity expands to new countries, new operators will emerge and then merge again. 4. As of the beginning of 2002, there are around 12000 registered AS's. With current use of AS's (for e.g., multi-homing) the number of AS's could be expected to grow to 25000 in about 10 years.[43] This is down from a previously reported growth rate of 51% per year.[13]. Future growth rates are difficult to predict. 5. In contrast to the number of operators, the number of domains is likely to grow significantly. Today, each operator has different domains within an AS, but this also shows in SLAs and policies internal to the operator. Making this globally visible would create a number of domains 10-100 times the number of ASs, i.e., between 100,000 and 1,000,000. 6. With more and more capacity at the edge of the network the IP network will expand. Today there are operators with several thousands of routers, but this is likely to be increased. A domain will probably contain tens of thousands of routers. 7. The speed of connections in the (fixed) access will technically be (almost) unconstrained. However, the cost for the links will not be negligible so that the apparent speed will be effectively bounded. Within a number of years some will have multi-gigabit speed in the access. 8. At the same time, the bandwidth of wireless access still has a strict upper-bound. Within the foreseeable future each user will only have a tiny amount of resources available compared to fixed accesses (10kbps to 2Mbps for UMTS with only a few achieving the higher figure as the bandwidth is shared between the active users in a cell and only small cells can actually reach this speed, but 11Mbps or more for wireless LAN connections). There may also be requirements for effective use of bandwidth as low as 2.4 Kbps or lower, in some applications. Group B Expires: September 2002 15 INTERNET DRAFT FDR Requirements February, 2002 9. Assumptions 7 and 8 taken together suggest a minimum span of bandwidth between 2.4 kbps to 10 Gbps. 10. The speed in the backbone has grown rapidly, and there is no evidence that the growth will stop in the coming years. Terabit- speed is likely to be the minimum backbone speed in a couple of years. The range of bandwidths that need to be represented will require consideration on how to represent the values in the protocols. 11. There have been discussions as to whether Moore's law will continue to hold for processor speed. If Moore's law does not hold, then communication circuits might play a more important role in the future. Also, optical routing is based on circuit technology, which is the main reason for taking ³circuits³ into account when designing an FDR. 12. However, the datagram model still remains the fundamental model for the Internet. 13. The number of peering points in the network is likely to grow, as multi-homing becomes important. Also traffic will become more locally distributed, which will drive the demand for local peering. 14. The FDR will achieve the same degree of ubiquity as the current Internet and IP routing. 6. Functional requirements 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]. 6.1 Topology 6.1.1 Routers should be able to know and exploit the domain topology R(1) Routers MUST be able to acquire and hold sufficient information on the underlying topology of the domain to allow the establishment of routes on that topology. R(2) Routers MUST have the ability to control the establishment of routes on the underlying topology. R(3) Routers MUST be able, where appropriate, to control Sub- IP mechanisms to support the establishment of routes. The OSI Inter-Domain Routing Protocol (IDRP) [36] utilized a capability which allowed a collection of topologically related domains to be replaced by a domain collection object in a similar way to the Nimrod[9] domain hierarchies, allowing a route to be more Group B Expires: September 2002 16 INTERNET DRAFT FDR Requirements February, 2002 compactly represented by a single collection in place of a sequence of individual domains. R(4) Routers MUST, where appropriate, be able to construct abstractions of the topology that represent an aggregation of the topological features of some area of the topology. 6.1.2 The same topology information should support different path selection ideas: The same topology information needs to provide a more flexible spectrum of path selection methods that we might expect to find in a future Internet, including, amongst others, both distributed techniques such as hop-by-hop, shortest path, local optimization constraint-based, class of service, source address routing, and destination address routing as well as the centralized, global optimization constraint-based 'traffic engineering' type (Open constraints should be allowed). Allowing different path selection techniques to be used will produce a much more predictable and comprehensible result than the 'clever tricks' that are currently needed to achieve the same results. Traffic engineering functions need to be combined. R(5) Routers MUST be capable of supporting a small number of different path selection algorithms 6.1.3 Separation of the routing information topology from the data transport topology. R(6) The controlling network MAY be logically separate from the controlled network. Physically, the two functional 'planes' can reside in the same nodes and share the same links, but this is not the only possibility. Other options can also be feasible, and may sometimes be necessary. An example is a pure circuit switch (that cannot see individual IP packets), combined with an external controller. Another example may be where there are multiple links between two routers, and all the links are used for data forwarding, but only one is used for carrying the routing session. 6.2 Distribution 6.2.1 Distribution mechanisms R(7) Relevant changes in the state of the network, including modifications to the topology and changes in the values of dynamic capabilities, MUST be distributed to every entity in the network that needs them in a reliable, and Group B Expires: September 2002 17 INTERNET DRAFT FDR Requirements February, 2002 trusted way at the earliest appropriate time after the change has occurred. R(8) Information MUST NOT be distributed outside areas where it is needed or believed to be needed for the operation of the routing system. R(9) Information MUST be distributed in such a way that it minimizes the load on the network consistent with the required response time of the network to changes. 6.2.2 Path advertisement R(10) The router MUST be able to acquire and store additional static and dynamic information relating to the capabilities of the topology and its component nodes and links, which can subsequently be used by path selection methods. The inter-domain routing system must be able to advertise more kinds of information than just connectivity and domain path. R(11) The Routing System MUST support service specifications, e.g. the Service Level Specifications (SLSs) developed by the Differentiated Services working group. [42] Careful attention should be paid to ensuring that the distribution of additional information with path advertisements remains scalable as domains and the Internet get larger, more numerous and more diversified. R(12) The distribution mechanism used for distributing network state information MUST be scalable with respect to the expected size of domains and the volume and rate of change of dynamic state that can be expected. The combination of R(3) and R(3) may result in a compromise between the responsiveness of the network to change and the overhead of distributing change notifications. Also attempts to respond to very rapid changes may damage the stability of the routing system. Possible examples of additional capability information that might be carried include: - QoS information To allow an ISP to sell predictable end-to-end QoS service to any destination, the routing system should have information about the end-to-end QoS. This means that: Group B Expires: September 2002 18 INTERNET DRAFT FDR Requirements February, 2002 R(13) The routing system MUST be able to support different paths for different services. R(14) The routing system MUST be able to forward traffic on the path appropriate for the service selected for the traffic either according to an explicit marking in each packet of the traffic (e.g. MPLS labels, DiffServ PDB's or TOS-values) or implicitly (e.g. the physical or logical port on which the traffic arrives). R(15) The routing system SHOULD also be able to carry information about the expected (or actually, promised) characteristics of the entire path and the price for the service. (If such information is exchanged at all between network operators today, it is through bilateral management interfaces, and not through the routing protocols.) This would allow for the operator to optimise the choice of path based on a price/performance trade-off. In addition to providing dynamic QoS information the system should be able to use static class-of-service information. - security information Security characteristics of other domains (in the path or in the map) can allow the routing entity to choose routing decision based on some political reasons. The information itself is assumed to be so secure that you can trust it. - usage and cost information This can be used for billing and traffic engineering purpose. In order to support cost based routing policies for customers (i.e. peer ISPs), information such as "traffic on this link or path costs XXX per Gigabyte" needs to be advertised, so that the customer can choose a cheap or an expensive route from an economic perspective. - monitored performance Some performance information such as delay and drop frequency can be carried. (This is may only be suitable inside a domain because of trust considerations). This should support at least the kind of delay bound contractual terms that are currently being offered by service providers. Note that these values refer to the outcome of carrying bits on the path, whereas the QOS information refers to the proposed behaviour that results in this outcome. Group B Expires: September 2002 19 INTERNET DRAFT FDR Requirements February, 2002 - Multicast information R(16) The routing system must provide necessary information needed to create multicast distribution trees. This information MUST be provided for one-to-many distribution trees and SHOULD be provided for many-to-many distribution trees. The actual construction of distribution trees is not necessarily done by the routing system. 6.2.3 Stability of routing information R(17) The new network architecture MUST be stable without needing global convergence, i.e. convergence is a local property. The degree to which this is possible and the definition of local remains a research topic. Restricting the requirement for convergence to localities will have an effect on all of the other requirements in this section. R(18) The distribution, and the rate of distribution of changes MUST NOT affect the stability of the routing information, e.g. by commencing redistribution of a change before the previous one had settled. 6.2.3.1 Avoiding routing oscillations R(19) The routing system MUST minimize oscillations in route advertisements. 6.2.3.2 Providing loop free routing and forwarding In line with the separation of concerns of routing and forwarding: R(20) The distribution of routing information MUST be, so far as is possible, loop-free. R(21) The forwarding information created from this routing information MUST seek to minimize persistent loops in the data forwarding paths. It is accepted that transient loops may occur during convergence of the protocol and that there are trade-offs between loop avoidance and global scalability. 6.2.3.3 Detection, notification and repair of failures R(22) The routing system MUST provide means for detecting failures of both node equipment and communication links. Group B Expires: September 2002 20 INTERNET DRAFT FDR Requirements February, 2002 R(23) The routing system SHOULD be able to coordinate responses to failure detection indications from layer 3 mechanisms and nodal mechanisms built into the routing system and from lower layer mechanisms that are propagated up to Layer 3 in order to determine the root cause of the failure. This will allow the routing system to react correctly to the failure by activating appropriate mitigation and repair mechanisms if required, whilst ensuring that it does not react if lower layer repair mechanisms are able to repair or mitigate the fault. Most layer 3 routing protocols have utilized keepalives or 'hello' protocols as a means of detecting failures at Layer 3. The keepalive mechanisms are often complemented by analog (e.g. laser light detection) and hardware mechanisms (e.g. hardware/software watchdogs) that are built into routing nodes and communication links. Great care must be taken to make best possible use of the various failure repair methods available whilst ensuring that only one repair mechanism at a time is allowed to repair any given fault: Interactions between (say) fast reroute mechanisms at layer 3 and SONET/SDH repair at Layer 1 are highly undesirable and are likely to cause problems in the network. R(24) Where a network topology and routing system contains multiple fault repair mechanisms, the responses of these systems to a detected failure SHOULD be coordinated so that the fault is repaired by the most appropriate means, and no extra repairs are initiated. R(25) Where specialized packet exchange mechanisms (e.g. layer 3 keepalive or 'hello' protocol mechanisms) are used to detect failures, the routing system MUST make provision to allow the rate of transmission of these keepalives to be configured, including the capability to turn them off altogether where links are deliberately broken when no real user or control traffic is present (e.g. ISDN links). This will allow the operator to compromise between the speed of failure detection and the proportion of link bandwidth dedicated to failure detection. 6.3 Addressing 6.3.1 Support mix of IPv4, IPv6 and other types of addresses R(26) The routing system MUST support a mix of different kinds of addresses. This mix will include at least IPv4 and IPv6 addresses, and preferably various types of non-IP addresses too. For instance networks like SDH/SONET and WDM may prefer to use non-IP addresses. Group B Expires: September 2002 21 INTERNET DRAFT FDR Requirements February, 2002 It may also be necessary to support multiple sets of 'private' (e.g. RFC1918) addresses when dealing with multiple customer VPNs. R(27) The routing system SHOULD support the capability to use a single topology representation to generate routing and forwarding tables for multiple address families on the same network. This capability would minimise the protocol overhead when exchanging routes. 6.3.2 Support for domain renumbering/readdressing R(28) If a domain is subject to address reassignment that would cause forwarding interruption then the routing system SHOULD support readdressing (e.g. when a new prefix is given to an old network, and the change is known in advance) by maintaining routing during the changeover period [39], [40]. 6.3.3 Multicast and anycast R(29) The routing system MUST support multicast addressing, both within a domain and across multiple domains. R(30) The routing system SHOULD support anycast addressing within a domain. The routing system MAY support anycast addressing across domains. It is still an open question as to whether it is possible or useful to support anycast addressing between cooperating domains. 6.3.4 Address scoping R(31) The routing system MUST support scoping of unicast addresses, and SHOULD support scopingof multicast and anycast address types. For unicast address scoping, as is being designed for IPv6, does not seem to cause any special problems with respect to routing. IPv6 Inter-domain routing handles only IPv6 global addresses, while intra- domain routing also needs to be aware of site-local addresses. Link- local addresses are never routed at all. For scoping in a more general sense, and for scoping of multicast and anycast addresses, more study may be needed to identify the requirements solutions. 6.3.5 Mobility support Group B Expires: September 2002 22 INTERNET DRAFT FDR Requirements February, 2002 R(32) The routing system MUST support system mobility (and movability, and portability, whatever the differences may be). The term system includes anything from an end system to an entire domain. We observe that the existing solutions based on re-numbering and/or tunneling are designed to work with the current routing, so they do not add any new requirements to future routing. But the requirement is general, and future solutions may not be restricted to the ones we have today. 6.4 Statistics support R(33) Both the routing and forwarding parts of the routing system MUST maintain statistical information about the performance of their functions. 6.5 Management requirements While the tools of management are outside the scope of routing, the mechanisms to support the routing architecture and protocols are within scope: R(34) Mechanisms to support Operational, Administrative and Management control of the routing architecture and protocols MUST be designed into the original fabric of the architecture. 6.5.1 Simple policy management The basic aims of this specification are: - to require less manual configuration than today - to satisfy both the requirements for easy handling, and maximum control, i.e. - All the information should be available - But should not be visible except for when desired. - Policies themselves should be advertised and not only the result of policy, and - Provide Policy conflict Resolution R(35) The routing system MUST provide for management of the system by means of policies; e.g. that can be expressed in terms of the business and services implemented on the network and reflect the operation of the network in terms of the services affected. R(36) The distribution of policies MUST be amenable to scoping, to protect proprietary policies that are not of relevance beyond the local set of domains from distribution. Group B Expires: September 2002 23 INTERNET DRAFT FDR Requirements February, 2002 6.5.2 Startup and Maintenance of Routers A major problem in today's networks is the need to perform initial configuration on routers from a local interface before a remote management system can take over. It is not clear that this imposes any requirements on the routing architecture beyond what is need for a ZeroConf host. Similarly, maintenance and upgrade of routers can cause major disruptions to the network routing because the routing system and management of routers is not organized to minimize such disruption. Some improvements have been made, such as graceful restart mechanisms in protocols, but more needs to be done. R(37) The routing system and routers SHOULD provide mechanisms that will minimize the disruption to the network caused by maintenance and upgrades of software and hardware. It is recognized that some of the capabilities needed are outside the scope of the routing architecture (e.g. minimum impact software upgrade) but the routing system SHOULD provide the necessary support for such capabilities. 6.6 Provability R(38) The routing system and its component protocols MUST be provably locally convergent under the permitted range of parameter settings and policy options that the operator(s) can select. There are various methods for proof that include, but are not limited to: mathematical, heuristic, and pattern recognition. No requirement is made on the method used for proving local convergence properties. R(39) Routing protocols employed by the routing system and the overall routing system SHOULD be resistant to bad routing policy decisions made by operators. Tools are needed to check compatibility of routing policies. While these tools are not part of the routing architecture, the mechanisms to support such tools are. Routing policies are compatible if their interaction does not cause divergence. A domain or group of domains in a system is defined as being convergent if and only if, after an exchange of routing information, routing tables reach a stable state that does not change until routing policies or topology changes. To achieve the above-mentioned goals: Group B Expires: September 2002 24 INTERNET DRAFT FDR Requirements February, 2002 R(40) The routing system MUST provide a mechanism to publish and communicate policies so that operational coordination and fault isolation is possible. Tools are required that verify the stability characteristics of the routing system in specified parts of Internet. The tools should be efficient (fast) and have a broad scope of operation (check large portions of Internet). While these tools are not part of the architecture, developing them is in the interest of the architecture and should be defined as a Routing Research Group activity while research on the architecture is in progress. Tools analyzing routing policies can be applied statically or (preferably) dynamically. Dynamic solution requires tools that can be used for run time checking for a source of oscillations that arise from policy conflicts. Research is needed to prove that there is an efficient solution to the dynamic checking of oscillations. 6.7 Traffic engineering The ability to do traffic engineering and get the feedback from the network that enables traffic engineering are capabilities that should be included in the future domain architecture. Traffic engineering is, at base, another alternative or extension for the path selection mechanisms of the routing system: No fundamental changes to the requirements are needed but the iterative processes involved in traffic engineering may require some additional capabilities and state in the network. Traffic engineering typically involves a combination of off-line network planning and administrative control functions in which the expected and measured traffic flows are examined resulting in changes to static configurations and policies in the routing system. During operations under these configurations control the actual flow of traffic and affect the dynamic path selection mechanisms: The results are measured and fed back into further rounds of network planning. 6.7.1 Support for and provision of traffic engineering tools At present there is an almost total lack of effective traffic engineering tools, whether on-line at all times for network control or off-line for network planning. The routing system should encourage the provision of such tools. R(41) The routing system MUST generate statistical and accounting information in such a way that traffic engineering and network planning tools can be used both in real time and for off-line planning and management. Group B Expires: September 2002 25 INTERNET DRAFT FDR Requirements February, 2002 6.7.2 Support of multiple parallel paths R(42) The routing system MUST support the controlled distribution, over multiple links or paths, of traffic towards the same destination. This applies to domains with two or more connections to the same neighbor domain, and to domains with connections to more than one neighbor domain. The paths need not have the same metric. R(43) The routing system MUST support forwarding over multiple parallel paths when available. This support SHOULD extend to cases where the offered traffic is known to exceed the available capacity of a single link, and to the cases where load is to be shared over paths for cost or resiliency reasons. R(44) Where traffic is forwarded over multiple parallel paths, the routing system MUST, so far as is possible, avoid reordering of packets in individual micro-flows. R(45) The routing system MUST have mechanisms to allow the traffic to be reallocated back on to a single path when the multiple paths are not needed. 6.7.3 Peering support R(46) The routing system MUST support peer-level connectivity as well as hierarchical connections between domains. The network is becoming increasingly complex with private peering arrangements set up between providers at every level of the hierarchy of service providers and even by certain large enterprises, in the form of dedicated extranets. R(47) The routing system MUST facilitate traffic engineering of these peer routes so that traffic can be readily constrained to travel as the network operators desire and they can consequentially make optimal use of the available connectivity. 6.8 Support for mid-boxes One of our assumptions is that NATs and other Mid-boxes such as firewalls, web proxies and address family (e.g. IPv4 to IPv6) translators are here to stay. R(48) The routing system SHOULD work in conjunction with mid- boxes, e.g. NAT, to aid in bi-directional connectivity without compromising the additional opacity and privacy that the mid-boxes offer. Group B Expires: September 2002 26 INTERNET DRAFT FDR Requirements February, 2002 This problem is closely analogous to the abstraction problem, which is already under discussion for the interchange of routing information between domains. 7. Performance requirements Over the past several years, the performance of the routing system has frequently been discussed. The requirements that derive from those discussions are listed below. Currently the required values for these performance requirements are left for further discussion. R(49) The routing system MUST support domains of at least X systems. A system is taken to mean either an individual router or a domain. R(50) Local convergence SHOULD occur within X units of time. R(51) The routing system MUST be 99.99x?% available. R(52) The routing system MUST be reliable as measured by TBD. R(53) The routing system MUST be locally stable as measured by TBD. R(54) The routing system MUST be globally stable as measured by TBD. R(55) The routing system SHOULD scale to an indefinitely large number of domains. In many cases there has been very little data or statistical evidence for many of the performance claims being made. In recent years several efforts have been initiated to gather data and do the analyses required to make scientific assessments of the performance issues and requirements. In order to complete this section of the requirements analysis, the data and analyses from these studies needs to be gathered and collated into this document. This work has been started but has yet to be completed. 8. Backwards compatibility (cutover) and maintainability This area poses a dilemma. On one hand it is an absolute requirement that: R(56) The introduction of the routing system MUST NOT require any flag days Group B Expires: September 2002 27 INTERNET DRAFT FDR Requirements February, 2002 R(57) The network currently in place MUST continue to run at least as well as it does now while the new network is being brought in around it. However, at the same time, it is also an absolute requirement that: R(58) The new architecture MUST NOT be limited by the restrictions that plague today's network. [It has to be admitted that this is not a well defined requirement, because we have not fully articulated what the restrictions might be. Some of these restrictions can be derived by reading the discussions for the positive requirements above: It would be a useful exercise to explicitly list all the restrictions and irritations that we wish to do away with. It would be further useful to determine if these restrictions can currently be removed at reasonable cost or whether we are actually condemned to live with them.] Those restrictions cannot be allowed to become permanent baggage on the new architecture. If they do, the effort to create a new system will come to naught. It may, however, be necessary to live with some of them temporarily for practical reasons whilst providing an architecture which will eventually allow them to be removed. These three requirements have significance not only for the transition strategy, but for the architecture itself implying that it must be possible for an internet such as today's BGP controlled network, or one of its ASs, to exist as a domain within the new FDR. 9. Security requirements As previously discussed, one of the major changes to have overtaken the Internet since its inception, is the erosion of trust between end users making use of the net, between those users and the suppliers of services, and between the multiplicity of providers. Hence security, in all its aspects, will be much more important in the FDR. It must be possible to secure the routing communication: R(59) The communicating entities MUST be able to identify who sent and who received the information (authentication) R(60) The communicating entities MUST be able to verify that the information has not been changed on the way (integrity). Security is more important in inter-domain routing where the operator has no control to the other domains, then in intra-domain routing since all the links and the nodes are under the administration of the operator and can be expected to share a trust relationship. This Group B Expires: September 2002 28 INTERNET DRAFT FDR Requirements February, 2002 property of intra-domain trust, however, should not be taken for granted: R(61) Routing communications MUST be secured by default, but an operator MUST have the option to relax this requirement within a domain where analysis indicates that other means (such as physical security) provide an acceptable alternative. R(62) The routing communication mechanism MUST be robust against denial-of-service attacks. Further considerations that may impose requirements include: - Whether no one else but the intended recipient must be able to access (privacy) or understand (confidentiality) the information. - Whether it is possible to verify that all the information has been received (non-repudiation). - Whether there is a need to separate security of routing from security of forwarding. - Whether traffic flow security is needed (i.e. whether there is value in concealing who can connect to whom, and what volumes of data are exchanged). Securing the BGP session, as done today, only secures the exchange of messages from the peering domain, not the content of the information. In other words, we can confirm that the information we got is what our neighbor really sent us, but we do not know if this information (that originated in some remote domain) is true or not. A decision has to be made on whether to rely on chains of trust (we trust our peers who trust their peers who..), or whether we also need authentication and integrity of the information end-to-end. This information includes both routes and addresses. There has been interest in having digital signatures both on originated routes, but also countersignatures by address authorities to confirm that the originator has authority to advertise the prefix. Even understanding who can confirm the authority is non-trivial as it might be the provider who delegated the prefix (with a whole chain of authority back to ICANN) or it may be straight to an address registry. Where a prefix delegated by a provider is being advertised though another provider as in multi-homing, both may have to be involved to confirm that the prefix may be advertised through the provider who doesn't have any interest in the prefix! R(63) The routing system MUST cooperate with the security policies of mid-boxes whenever possible. This is likely to involve further requirements for abstraction of information, as, for example, the firewall is seeking to minimize interchange of information that could lead to a security breach. The Group B Expires: September 2002 29 INTERNET DRAFT FDR Requirements February, 2002 effect of such changes on the end-to-end principle should be carefully considered as discussed in [32]. R(64) The routing system MUST be capable of complying with local legal requirement for interception of communication. 10.Debatable issues This section covers issues that need to be considered and resolved in deciding on a future domain routing architecture. While they can't be described as requirements, they do affect the types of solution that are acceptable. The discussions included below are very open- ended. 10.1Network modeling The mathematical model that underlies today's routing system uses a graph representation of the network. Hosts, routers and other processing boxes are represented by nodes and communications links by arcs. The model is a topological model in that routing does not need to directly model the physical length of the links or the position of the nodes: The model can be transformed to provide a convenient picture of the network by adjusting the lengths of the arcs and the layout of the nodes. The connectivity is preserved and routing is unaffected by the transformation. The routing algorithms in traditional routing protocols utilize a small number of results from graph theory. It is only recently that additional results have been employed to support constraint based routing for traffic engineering. The naturalness of this network model and the 'fit' of the graph theoretical methods may have tended to blind us to alternative representations and inhibited us from seeking out alternative strands of theoretical thinking that might provide improved results. We should not allow this habitual behavior to stop us looking for alternative representations and algorithms: Topological revolutions are possible and allowed, at least in theory. 10.2System modeling The assumption that object modeling of a system is an essential first step to creating a new system is still novel in this context. Frequently the effort to object model becomes an end in itself and does not lead to system creation. But there is a balance and a lot that can be discovered in an ongoing effort to model a system such as the future domain routing system. Group B Expires: September 2002 30 INTERNET DRAFT FDR Requirements February, 2002 It is recommended that this process be included in the requirements. It should not, however be a gating event to all other work. Some of the most important realizations will occur during the process of determining the following: - Object classification - Relationships and containment - Roles and Rules 10.3 One, two or many protocols There has been a lot of discussion of whether the FDR protocol solution should consist of one (probably new) protocol, two (intra and inter domain) protocols or many protocols. While in the best of all possible worlds, it might be best to have one protocol that handles all situations, this seems improbable in this less then best of all possible worlds. On the other hand, maintaining the 'strict' division evident in the network today between the IGP and EGP has been effectively argued elsewhere as being too restrictive an approach. Given this, and the fact that there are already many routing protocols in use, the only possible answer seems to be that the architecture SHOULD support many protocols. It remains an open issue, one for the solution, to determine if a new protocol needs to be designed in order to support the highest goals of this architecture. The expectation is that, yes, a new protocol will need to be designed. 10.4Class of protocol to use If a new protocol is required to support the FDR architecture, the question remains open as to what kind of protocol this ought to be. It is our expectation that a map distribution protocol will be required to augment the current path-vector protocol and shortest path first protocols. 10.5Map abstraction Assuming that a map distribution protocol is required, what are the requirements on this protocol? If every detail is advertised throughout the Internet, there will be a lot of information. Scalable solutions require abstraction. - If we summarise too much, some information will be lost on the way. - If we summarise too little, then more information then required is available contributing to scaling limitations. - One can allow more summarisation, if there also is a mechanism to query for more details within policy limits. Group B Expires: September 2002 31 INTERNET DRAFT FDR Requirements February, 2002 - The basic requirement is not that the information shall be advertised, but rather that the information shall be available to those who need it. Of course we should not presuppose a solution where advertising is the only possible mechanism. 10.6Clear identification for all entities As in all other fields, the words used to refer to concepts and to describe operations about routing are important. Rather than describe concepts using terms that are inaccurate or rarely used in the real world of networking, it is necessary to make an effort to use the correct words. Many networking terms are used casually, and the result is a partial or incorrect understanding of the underlying concept. Entities such as nodes, interfaces, sub-networks, tunnels, and the grouping concepts such as ASs, domains, areas, and regions, need to be clearly identified and defined to avoid mixing from each other. There is also a need to separate identifiers (what or who) from locators (where) from routes (how to reach). 10.7Robustness and redundancy: The routing association between two domains should survive even if some individual connection between two routers goes down. The "session" should operate between logical "routing entities" on each domain side, and not necessarily be bound to individual routers or addresses. Such a logical entity can be physically distributed over multiple network elements. Or it can reside in a single router, which would default to the current situation. 10.8Hierarchy A more flexible hierarchy with more levels and recursive groupings in both upward and downward directions allows more structured routing. The consequence is that no single level will get too big for routers to handle. On the other hand, it appears that the real world Internet is becoming less hierarchical, so that it will be increasingly difficult to use hierarchy for scaling control. Note that groupings can look different depending on which aspect we use to define them. A DiffServ area, a MPLS domain, a trusted domain, a QoS area, a multicast domain, etc, do not always coincide. And neither are they strict hierarchical subsets of each other. The basic distinction at each level is "this grouping versus everything outside". Group B Expires: September 2002 32 INTERNET DRAFT FDR Requirements February, 2002 10.9Will new control mechanisms be needed? Is it possible to apply a control theory framework, and analyze the stability of the control system of the whole network domain, for e.g. convergence speed and the frequency response, and then use the results from that analysis to set the timers and other protocol parameters. Control theory could also play a part is QoS Routing, by modifying current link state protocols with link costs dependent on load. Control theory is used to increase the stability of such systems. At best, it might be possible to construct a new totally dynamical routing protocol solely on a control theoretic basis as opposed to the current protocols which are based in graph theory and static in nature. 10.10 Byzantium Is solution to the Byzantine Generals problem a requirement? This is the problem of reaching a consensus among distributed units if some of them give misleading answers. The current intra-domain routing system is, at one level, totally intolerant of misleading information, but the effect of different sorts of misleading or incorrect information has vastly varying results, from total collapse through to purely local disconnection of a single domain. This sort of behavior is not very desirable. What are some of the other network robustness issues that must be resolved? 10.11 VPN support Today BGP is also used for VPN and other stuff for example as described in RFC2547 [16]. Internet routing and VPN routing have different purposes, and most often exchange different information between different devices. Most Internet routers do not need to know any VPN specific information. The concepts should be clearly separated. But when it comes to the mechanisms, VPN routing can share the same protocol as ordinary Internet routing, it can use a separate instance of the same protocol, or it can use a different protocol. All variants are possible and have their own merits. These requirements currently are silent on this issue. 10.12 End to end reliability Group B Expires: September 2002 33 INTERNET DRAFT FDR Requirements February, 2002 The existing Internet architecture neither requires or provides end- to-end reliability of control information dissemination. For example, in distributing VPN information there is, however, a requirement for end to end reliability of control information, i.e. the ends of the VPN established need to have a acknowledgement of the success in setting up the VPN. While it is not necessarily the function of a routing architecture to provide end-to-end reliability for this kind of purpose, we must be clear that end-to-end reliability becomes a requirement if the network has to support such reliable control signaling. There may be other requirements that derive from requiring the FDR to support reliable control signaling. 10.13 End to end transparency The introduction of private addressing schemes, Network Address Translators and firewalls has significantly reduced the end-to-end transparency of the network. In many cases the network is also no longer symmetric, so that communication between two addresses is possible if the communication session originates from one end but not from the other. This impedes the deployment of new peer-to-peer services, and some 'push' services where the server in a client- server arrangement originates the communication session. Whether a new routing system either can or should seek to restore this transparency is an open issue. A related issue is the extent to which end user applications should seek to control the routing of communications in the rest of the network. 11.Bibliography The following were consulted in the writing of this document. Not all are specifically referred to in the document, but all helped in forming this work. These references are not intended as normative. [1] Clark, D., "Policy Routing in Internet Protocols", RFC 1102, May 1989. [2] Estrin, D., "Requirements for Policy Based Routing in the Research Internet", RFC 1125, November 1989. [3] Steenstrup, M,. "An Architecture for Inter-Domain Policy Routing", RFC 1478, June 1993 [4] Little, M., "Goals and Functional Requirements for Inter-Autonomous System Routing", RFC 1126, July 1989. [5] Perlman, R., "Interconnections Second Edition", 1999, Addison Wesley Longman, Inc. Group B Expires: September 2002 34 INTERNET DRAFT FDR Requirements February, 2002 [6] Perlman, R., "Network Layer Protocols with Byzantine Robust-ness", Ph.D. Thesis, Department of Electrical Engineering and Computer Science, MIT, August 1988. [7] Castineyra, I., Chiappa, N., Steenstrup, M., "the Nimrod Routing Architecture", RFC1992, Aug 1996 [8] Chiappa, N., "IPng Technical Requirements of the Nimrod Routing and Addressing Architecture", RFC 1753, Dec 1994 [9] Chiappa, N., "A New IP Routing and Addressing Architecture" [10] Wroclowski, J., The Metanet White Paper - Workshop on Research Directions for the Next Generation Internet, 1995 [11] Labovitz, C., Ahuja, A., Farnam J., Bose, A., Experimental Measurement of Delayed Convergence, NANOG [12] Griffin, T.G., Wilfong, G., An Analysis of BGP Convergence Properties, SIGCOMM 1999 [13] Huston, G., Commentary on Inter-Domain Routing in the Internet,RFC 3221, Dec 2001 [14] Alaettinoglu, C., Jacobson, V. and Yu, H, , Towards Milli-Second IGP Convergence, Internet Draft - draft-alaettinoglu-isis-convergence-00, Nov 2000 Work in Progress [15] Sandick, H., Squire, M., Cain, B., Duncan, I., Haberman, B., Fast LIveness Protocol (FLIP), Internet Draft - draft-sandiick-flip-00, Feb 2000, Work in Progress [16] Rosen, E. and Rekhter, Y., BGP/MPLS VPNs, RFC2547, March 1999 [17] Clark, D., Chapin, L., Cerf, V., Braden, R., Hobby, R., "towards the Future Internet Architecture", RFC1287, December 1991 [18] Jacobson, V., Nichols, K. and Poduri, K., The 'Virtual Wire' Behavior Aggregate, Internet Draft - draft-ietf-diffserv-pdb-vw-00, July 2000, Work in Progress Group B Expires: September 2002 35 INTERNET DRAFT FDR Requirements February, 2002 [19] Seddigh, N., Nandy, B., and Heinanen, J., An Assured Rate Per-Domain Behaviour for Differentiated Services, Internet Draft - draft-ietf-diffserv-pdb-ar-00, Feb 2001, Work in Progress [20] McPherson, D., Gill, V., Walton, D. and Retana, A., "BGP Persistent Route Oscillation Condition", Internet Draft - draft-mcpherson-bgp-route- oscillation-00, Dec 2000, Work in Progress [21] Hain, T, "Architectural Implications of NAT", RFC 2993, November 2000 [22] McPherson, D. and Przygienda, T., OSPF Transient Blackhole Avoidance, Internet Draft - draft- mcpherson-ospf-transient-00, July 2000 Work In Progress [23] [BGMP] Thaler, D., Estrin, D. and Meyer, D. (editors), Border Gateway Multicast Protocol (BGMP): Protocol Specification, Internet Draft - draft-ietf-bgmp-spec-02, Nov 2000 Work in progress [24] Rosen, E. Et al., Multiprotocol Label Switching Architecture, RFC 3031 [25] Ashwood-Smith, P. Et al., Generalized MPLS - Signaling Functional Description, Internet Draft - draft-ietf-mpls-generalized-signaling-01.txt, Work in progress [26] IETF Resource Allocation Protocol working group, http://www.ietf.org/html.charters/rap- charter.html [27] IETF Configuration management with SNMP working group, http://www.ietf.org/html.charters/snmpconf- charter.html [28] IETF Policy working group, http://www.ietf.org/html.charters/policy- charter.html [29] Yu J., "Scalable Routing Design Principles", RFC 2791 [30] Telcordia Technologies Netsizer web site http://www.netsizer.com/ Group B Expires: September 2002 36 INTERNET DRAFT FDR Requirements February, 2002 [31] Inference of Shared Risk Link Groups, draft-many-inference-srlg-00.txt, Work in progress [32] Blumenthal, Marjory S. and Clark, David D., Rethinking the design of the Internet: The end to end arguments vs. the brave new world, May 2001, http://ana-www.lcs.mit.edu/anaweb/papers.html [33] Lang et al, Link Management Protocol, draft-lang-mpls-lmp-02.txt, Work in progress [34] Xu, Z., Dai, S. and Garcia-Luna-Aceves, J.J., A More Efficient Distance Vector Routing Algorithm, Proc. IEEE MILCOM 97, Monterey, California, November 2-5, 1997, http://www.cse.ucsc.edu/research/ccrg/ publications/zhengyu.milcom97.pdf [35] Bradner, S. and Mankin, A., "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995. [36] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing Information among Intermediate Systems to support Forwarding of ISO 8473 PDUs", International Standard 10747, ISO/IEC JTC 1,Switzerland 1993 [37] Bates, T., Rekhter, Y., Chandra, R. and Katz, D, "Multiprotocol Extensions to BGP-4", RFC2858, June 2000 [38] Berkowitz, H. and Krioukov, D, "To Be Multihomed: Requirements and Definitions", draft-berkowitz-multirqmt-02.txt, Work in progress. [39] Ferguson, P. and Berkowitz, H. "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC2071, January 1997 [40] Berkowitz, H., "Router Renumbering Guide", RFC2072, January 1997 [41] [History] Doria (ed), draft-groupb-irtf-rr- history-00.txt, work in progress [42] Grossman, Dan, "New Terminology and Clarifications for Diffserv", draft-ietf- Group B Expires: September 2002 37 INTERNET DRAFT FDR Requirements February, 2002 diffserv-new-terms-08.txt, January 2002, Work in progress. [43] Broido, A., Nemeth, e., kc, and elves., Internet Expansion, Refinement and Churn, Presentation at Nanog, Feb 2002 12.Author's Addresses Elwyn Davies Nortel Networks London Road Harlow, Essex CM17 9NA UK Phone: +44-1279-405498 Email: elwynd@nortelnetworks.com Avri Doria Div. of Computer Communications Lulea University of Technology S-971 87 Lulea Sweden Phone: (+46) 920 46 3030 Email: avri@sm.luth.se Howard Berkowitz Gett Communications 5012 25th Street South Arlington, VA 22206 USA Phone +1 703 998 5819 Email: hcb@gettcomm.com Dmitri Krioukov Nortel Networks 2325 Dulles Corner Boulevard th 11 Floor Herndon VA 20171, USA Phone: +1 571 331 1104 Email: dima@krioukov.net Malin Carlzon Royal Institute of Technology Network Operating Centre KTHNOC SE-100 44 Stockholm Sweden Phone: +46 70 269 6519 Email: malin@sunet.se Group B Expires: September 2002 38 INTERNET DRAFT FDR Requirements February, 2002 Anders Bergsten Telia Research AB Aurorum 6 S-977 75 Lulea Sweden Phone: +46 920 754 50 Email: anders.p.bergsten@telia.se Olle Pers Telia Research AB S- 123 86 Farsta Sweden Phone: +46 8 713 8182 Email: olle.k.pers@telia.se Yong Jiang Telia Research AB S- 123 86 Farsta Sweden Phone: +46 8 713 8125 Email: yong.b.jiang@telia.se Lenka Carr Motyckova Div. of Computer Communications Lulea University of Technology S-971 87 Lulea Sweden Phone: +46 920 91769 Email: lenka@sm.luth.se Pierre Fransson Div. of Computer Communications Lulea University of Technology S-971 87 Lulea Sweden Phone: +46 70 646 0384 Email: pierre@cdt.luth.se Olov Schelen Div. of Computer Communications Lulea University of Technology S-971 87 Lulea Sweden Phone: +46 70 536 2030 Email: Olov.Schelen@cdt.luth.se Group B Expires: September 2002 39 INTERNET DRAFT FDR Requirements February, 2002 Tove Madsen Utfors Bredband AB R…sundav„gen 12 P.O. Box 525 SE-169 29 Solna Sweden Phone: +46 8 5270 5040 Email: tove.madsen@utfors.se Group B Expires: September 2002 40