Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5772

A Set of Possible Requirements for a Future Routing Architecture

Pages: 68
Historic
Part 2 of 3 – Pages 25 to 42
First   Prev   Next

Top   ToC   RFC5772 - Page 25   prevText

2.2. Non-Requirements

The following are not required or are non-goals. This should not be taken to mean that these issues must not be addressed by a new architecture. Rather, addressing these issues or not is purely an optional matter for the architects.

2.2.1. Forwarding Table Optimization

We believe that it is not necessary for the architecture to minimize the size of the forwarding tables (FIBs). Current memory sizes, speeds, and prices, along with processor and Application-specific Integrated Circuit (ASIC) capabilities allow forwarding tables to be very large, O(E6), and allow fast (100 M lookups/second) tables to be built with little difficulty.

2.2.2. Traffic Engineering

"Traffic engineering" is one of those terms that has become terribly overloaded. If one asks N people what traffic engineering is, one would get something like N! disjoint answers. Therefore, we elect not to require "traffic engineering", per se. Instead, we have endeavored to determine what the ultimate intent is when operators "traffic engineer" their networks and then make those capabilities an inherent part of the system.

2.2.3. Multicast

The new architecture is not designed explicitly to be an inter-domain multicast routing architecture. However, given the notable lack of a viable, robust, and widely deployed inter-domain multicast routing architecture, the architecture should not hinder the development and deployment of inter-domain multicast routing without an adverse effect on meeting the other requirements. We do note however that one respected network sage [Clark91] has said (roughly): When you see a bunch of engineers standing around congratulating themselves for solving some particularly ugly problem in networking, go up to them, whisper "multicast", jump back, and watch the fun begin...
Top   ToC   RFC5772 - Page 26

2.2.4. Quality of Service (QoS)

The architecture concerns itself primarily with disseminating network topology information so that routers may select paths to destinations and build appropriate forwarding tables. Quality of Service (QoS) is not a part of this function and we make no requirements with respect to QoS. However, QoS is an area of great and evolving interest. It is reasonable to expect that in the not too distant future, sophisticated QoS facilities will be deployed in the Internet. Any new architecture and protocols should be developed with an eye toward these future evolutions. Extensibility mechanisms, allowing future QoS routing and signaling protocols to "piggy-back" on top of the basic routing system are desired. We do require the ability to assign attributes to entities and then do path generation and selection based on those attributes. Some may call this QoS.

2.2.5. IP Prefix Aggregation

There is no specific requirement that CIDR-style (Classless Inter- Domain Routing) IP prefix aggregation be done by the new architecture. Address allocation policies, societal pressure, and the random growth and structure of the Internet have all conspired to make prefix aggregation extraordinarily difficult, if not impossible. This means that large numbers of prefixes will be sloshing about in the routing system and that forwarding tables will grow quite big. This is a cost that we believe must be borne. Nothing in this non-requirement should be interpreted as saying that prefix aggregation is explicitly prohibited. CIDR-style IP prefix aggregation might be used as a mechanism to meet other requirements, such as scaling.

2.2.6. Perfect Safety

Making the system impossible to misconfigure is, we believe, not required. The checking, constraints, and controls necessary to achieve this could, we believe, prevent operators from performing necessary tasks in the face of unforeseen circumstances. However, safety is always a "good thing", and any results from research in this area should certainly be taken into consideration and, where practical, incorporated into the new routing architecture.
Top   ToC   RFC5772 - Page 27

2.2.7. Dynamic Load Balancing

History has shown that using the routing system to perform highly dynamic load balancing among multiple more-or-less-equal paths usually ends up causing all kinds of instability, etc., in the network. Thus, we do not require such a capability. However, this is an area that is ripe for additional research, and some believe that the capability will be necessary in the future. Thus, the architecture and protocols should be "malleable" enough to allow development and deployment of dynamic load-balancing capabilities, should we ever figure out how to do it.

2.2.8. Renumbering of Hosts and Routers

We believe that the routing system is not required to "do renumbering" of hosts and routers. That's an IP issue. Of course, the routing and addressing architecture must be able to deal with renumbering when it happens.

2.2.9. Host Mobility

In the Internet architecture, host mobility is handled on a per-host basis by a dedicated, Mobile-IP protocol [RFC3344]. Traffic destined for a mobile-host is explicitly forwarded by dedicated relay agents. Mobile-IP [RFC3344] adequately solves the host-mobility problem and we do not see a need for any additional requirements in this area. Of course, the new architecture must not impede or conflict with Mobile-IP.

2.2.10. Backward Compatibility

For the purposes of development of the architecture, we assume that there is a "clean slate". Unless specified in Section 2.1, there are no explicit requirements that elements, concepts, or mechanisms of the current routing architecture be carried forward into the new one.

3. Requirements from Group B

The following is the result of the work done by Sub-Group B of the IRTF RRG in 2001-2002. It was originally released under the title: "Future Domain Routing Requirements" and was edited by Avri Doria and Elwyn Davies.
Top   ToC   RFC5772 - Page 28

3.1. Group B - Future Domain Routing Requirements

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. Reviewer's Note: Even in 2001, there was a wide difference of opinion across the community regarding the shortcomings of inter- domain routing. In the years between writing and publication, further analysis, changes in operational practice, alterations to the demands made on inter-domain routing, modifications made to BGP, and a recognition of the difficulty of finding a replacement may have altered the views of some members of the community. Changes 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 kind of radical changes that have to be accommodated are epitomized by the advent of IPv6 and the application of IP mechanisms to private commercial networks that offer specific service guarantees beyond the best-effort services of the public Internet. Major changes to the inter-domain routing system are inevitable to provide an efficient underpinning for the radically changed and increasingly commercially-based networks that rely on the IP protocol suite.

3.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, mean that we should consider the whole area of routing as an integrated system. This is done for two 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, this part of the document uses the name Future Domain Routing (FDR). - It is necessary to understand the degree to which inter-domain and intra-domain routing are related within today's routing architecture.
Top   ToC   RFC5772 - Page 29
   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 explanation 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 manner is
   very similar to the concept of region that was put forth by John
   Wroclawski in his Metanet model [Wroclawski95].  The idea includes
   the notion that certain attributes will characterize the behavior of
   the systems within a domain and that there will be borders between
   domains.  The idea of domain presented here does not presuppose that
   two domains will have the same behavior.  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 an example of the concept of domains in this document,
   there has been no attempt to create a new term.

   Current practice in routing-system design stresses the need to
   separate the concerns of the control plane and the forwarding plane
   in a router.  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.

3.2.1. Inter-Domain and Intra-Domain

Throughout this section, the terms "intra-domain" and "inter-domain" will be used. These should be understood as relative terms. In all cases of domains, there will be a set of network systems that are within that domain; 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 routing exchange between two network systems can be viewed as intra-domain from one perspective and as inter-domain from another perspective.

3.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:
Top   ToC   RFC5772 - Page 30
   -  Ongoing evolution of the commercial relationships between
      (connectivity) service providers, leading to changes in the way in
      which peering between providers is organized and the way in which
      transit traffic is routed.

   -  Requirements for traffic engineering within and between domains
      including coping with multiple paths between domains.

   -  Addition of a second IP addressing technique, in the form of IPv6.

   -  The use of VPNs and private address space with IPv4 and IPv6.

   -  Evolution of the end-to-end principle to deal with the expanded
      role of the Internet, as discussed in [Blumenthal01]: this paper
      discusses the possibility that the range of new requirements,
      especially the social and techno-political ones that are being
      placed on the future, 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.  This 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 behavior of
      individual users.

   -  Incorporation of alternative forwarding techniques such as the
      explicit routing (pipes) supplied by the MPLS [RFC3031] and GMPLS
      [RFC3471] environments.

   -  Integration of additional constraints into route determination
      from interactions with other layers (e.g., Shared Risk Link Groups
      [InferenceSRLG]).  This includes the concern that redundant routes
      should not fate-share, e.g., because they physically run in the
      same trench.

   -  Support for alternative and multiple routing techniques that are
      better suited to delivering types of content organized in ways
      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 organized 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.
Top   ToC   RFC5772 - Page 31

3.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 that has seldom been explicitly discussed: - How will we know when we have succeeded?
3.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 that it is trying to support. Our goal is to develop a routing architecture where even a 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 easily understood way.
3.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-effort service in the public Internet. On the other hand, Diffserv for example, can 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 is possible to construct services such as Virtual Wire [DiffservVW] and Assured Rate [DiffservAR]. Providers today offer rudimentary promises about traffic handling in the network, for example, delay and long-term packet loss guarantees. As time goes on, this becomes even more relevant. 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 adequate information about path service characteristics to be passed between domains and consequently, to allow the delivery of bit transport services other than the best-effort datagram connectivity service that is the current common denominator.
Top   ToC   RFC5772 - Page 32
3.2.3.3. Scalable Well Beyond Current Predictable Needs
Any proposed FDR system should scale beyond the size and performance we can foresee for the next ten years. The previous IDR proposal as implemented by BGP, has, with some massaging, held up for over ten years. In that time the Internet has grown far beyond the predictions that were implied by the original requirements. 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!
3.2.3.4. Alternative Forwarding Mechanisms
With the advent of circuit-based technologies (e.g., MPLS [RFC3031] and GMPLS [RFC3471]) 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.
3.2.3.5. Separation of Topology Map from Connectivity Service
It is envisioned that an organization can support multiple services within a single network. These services can, for example, be of different quality, of different connectivity type, or of 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. Thus, a goal with this architecture is to support separation between creation of a domain (or organization) topology map and service creation.
3.2.3.6. 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 in this sharing as an assumption in the FDR.
Top   ToC   RFC5772 - Page 33
   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).

3.2.3.7. Different Routing Paradigms in Different Areas of the Same Network
A number of routing paradigms have been used or researched, in addition to the conventional shortest-path-by-hop-count 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 backward-compatible way with today's system. This will facilitate a migration strategy that avoids flag days.
3.2.3.8. Protection against 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. While 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. Editors' Note: When sections like this one and the previous ones on quality differentiation were written, the idea of separating traffic for security or quality was considered an unqualified advantage. Today, however, in the midst of active discussions on Network Neutrality, it is clear that such issues have a crucial policy component that also needs to be understood. These, and other similar issues, are open to further research.
3.2.3.9. Provable Convergence with Verifiable Policy Interaction
It has been shown both analytically, by Griffin, et al. (see [Griffin99]), and practically (see [RFC3345]) that BGP will not converge stably or is only meta-stable (i.e., will not re-converge 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 of convergence that could be applied to a policy-free implementation.
Top   ToC   RFC5772 - Page 34
   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 that 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.

      Editors' Note: This requirement is very optimistic in that it
      implies that it is possible to get operators to cooperate even it
      is seen by them to be against their business practices.  Though
      perhaps Utopian, this is a good goal.

3.2.3.10. Robustness Despite Errors and Failures
From time to time in the history of the Internet, there have been occurrences where misconfigured routers have destroyed global connectivity. A goal of the FDR is to be more 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.
3.2.3.11. Simplicity in Management
The policy work ([rap-charter02], [snmpconf-charter02], and [policy-charter02]) that has been done at IETF provides 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. Editors' Note: Snmpconf and rap are the hopes of the past. Today, configuration and policy hope is focused on netconf [netconf-charter].
3.2.3.12. The Legacy of RFC 1126
RFC 1126 outlined a set of requirements that were used to guide the development of BGP. While the network has changed in the years since 1989, many of the same requirements remain. A future domain routing solution has to support, as its base requirement, the level of function that is available today. A detailed discussion of RFC 1126
Top   ToC   RFC5772 - Page 35
   and its requirements can be found in [RFC5773].  Those requirements,
   while specifically spelled out in that document, are subsumed by the
   requirements in this document.

3.3. High-Level User Requirements

This section considers the requirements imposed by the target audience of the FDR both in terms of organizations that might own networks that would use FDR, and the human users who will have to interact with the FDR.

3.3.1. Organizational Users

The organizations that own networks connected to the Internet have become much more diverse since RFC 1126 [RFC1126] was published. In particular, major parts of the network are now owned by commercial service provider organizations in the business of making profits from carrying data traffic.
3.3.1.1. Commercial Service Providers
The routing system must take into account the commercial service provider's need for 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 offer contracts to their customers in the form of Service Level Agreements (SLAs). The routing system must allow the providers to support these SLAs through traffic engineering and load balancing as well as multi-homing, providing the degree of resilience and robustness that is needed. Service providers can be categorized as: - Global Service Providers (GSPs) whose networks have a global reach. GSPs may, and usually will, wish to constrain traffic between their customers to run entirely on their networks. GSPs will interchange traffic at multiple peering points with other GSPs, and they will 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.
Top   ToC   RFC5772 - Page 36
   -  National, or regional, Service Providers (NSPs) that are similar
      to GSPs but typically cover one country.  NSPs 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.  They
      will typically purchase transit capacity from NSPs or GSPs to
      provide global connectivity, but they may also peer with
      neighboring, and sometimes distant, ISPs.

   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 and monitoring the traffic.  They 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.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. Some multi-national companies own 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, while 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. While this is predominantly a naming and addressing issue, the routing system must be able to support seamless changeover; for example, if the changeover requires a change of address prefix, the routing system must be able to cope with a period when both sets of addresses are in use. Enterprises will wish to be able to multi-home to one or more providers as one possible means of enhancing the resilience of their network.
Top   ToC   RFC5772 - Page 37
   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.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 on the routing system. The routing system must also continue to support dial-up users.
3.3.1.4. Internet Exchange Points
Peering of service providers, academic networks, and larger enterprises is happening increasingly 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 by 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.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.3.2. Individual Users

This section covers the most important human users of the FDR and their expected interactions with the system.
3.3.2.1. All End Users
The routing system must continue to deliver the current global connectivity service (i.e., any unique address to any other unique address, subject to policy constraints) that has always been the basic aim of the Internet.
Top   ToC   RFC5772 - Page 38
   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 QoS characteristics different from the
   best-effort 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.3.2.2. Network Planners
The routing system should allow network planners to plan and implement a network that can be proved to be stable and will meet their traffic engineering requirements.
3.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 and stable fashion, and deliver appropriate statistics and events to allow the network to be managed and upgraded in an efficient and timely fashion.
3.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.

3.4. Mandated Constraints

While many of the requirements 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 an 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, and - technological factors such as the prevalence of different levels of technology in the developed world compared to those in the developing or undeveloped world.
Top   ToC   RFC5772 - Page 39

3.4.1. The Federated Environment

The graph of the Internet network, with routers and other control boxes as the nodes and communication links as 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 minimize 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.

3.4.2. Working with Different Sorts of Networks

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 and often with their own routing mechanisms. Consideration needs to be given to the desirable degree and nature of interchange of information between the layers. In particular, the need for guaranteed robustness through diverse routing layers implies knowledge of the underlying networks. Mobile access networks may also impose extra requirements on Layer 3 routing.

3.4.3. Delivering Resilient Service

The routing system operates 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
Top   ToC   RFC5772 - Page 40
   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 Layer 1 services from the same provider:

                             Layer 3 service
                              /           \
                             /             \
                         Layer 2         Layer 2
                       Provider A      Provider B
                             \             /
                              \           /
                             Layer 1 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
   [InferenceSRLG].  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.

3.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 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 4 years. As in all projections of the future, this is not provable at this time. Editors' Note: The paragraph above was written in 2002, yet could be written without change in 2006. As with many technical predictions and schedules, the horizon has remained fixed through this interval.

3.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:
Top   ToC   RFC5772 - Page 41
   1.   The number of hosts today is somewhere in the area of 100
        million.  With dial-in, NATs, and the universal deployment of
        IPv6, this is likely to become up to 500 million users (see
        [CIDR]).  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 middle-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.   At the beginning of 2002, there are around 12000 registered ASs.
        With current use of ASs (e.g., multi-homing) the number of ASs
        could be expected to grow to 25000 in about 10 years [Broido02].
        This is down from a previously reported growth rate of 51% per
        year [RFC3221].  Future growth rates are difficult to predict.

           Editors' Note: In the routing report table of August 2006,
           the total number of ASs present in the Internet Routing Table
           was 23000.  In 4 years, this is substantial progress on the
           prediction of 25000 ASs.  Also, there are significantly more
           ASs registered than are visibly active, i.e., in excess of
           42000 in mid-2006.  It is possible, however, that many are
           being used internally.

   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.  Some
        domains 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.
Top   ToC   RFC5772 - Page 42
   8.   At the same time, the bandwidth of wireless access still has a
        strict upper-bound.  Within the foreseeable future each user
        will have only a tiny amount of resources available compared to
        fixed accesses (10 kbps to 2 Mbps for a Universal Mobile
        Telecommunications System (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 11 Mbps 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.

   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.

           Editors' Note: On the other hand, peer-to-peer networking may
           shift the balance in demand for local peering.

   14.  The FDR will achieve the same degree of ubiquity as the current
        Internet and IP routing.



(page 42 continued on part 3)

Next Section