tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5772

Historic
Pages: 68
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

A Set of Possible Requirements for a Future Routing Architecture

Part 1 of 3, p. 1 to 24
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Research Task Force (IRTF)                             A. Doria
Request for Comments: 5772                                           LTU
Category: Historic                                             E. Davies
ISSN: 2070-1721                                         Folly Consulting
                                                           F. Kastenholz
                                                        BBN Technologies
                                                           February 2010


    A Set of Possible Requirements for a Future Routing Architecture

Abstract

   The requirements for routing architectures described in this document
   were produced by two sub-groups under the IRTF Routing Research Group
   (RRG) in 2001, with some editorial updates up to 2006.  The two sub-
   groups worked independently, and the resulting requirements represent
   two separate views of the problem and of what is required to fix the
   problem.  This document may usefully serve as part of the recommended
   reading for anyone who works on routing architecture designs for the
   Internet in the future.

   The document is published with the support of the IRTF RRG as a
   record of the work completed at that time, but with the understanding
   that it does not necessarily represent either the latest technical
   understanding or the technical consensus of the research group at the
   date of publication.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for the historical record.

   This document defines a Historic Document for the Internet community.
   This document is a product of the Internet Research Task Force
   (IRTF).  The IRTF publishes the results of Internet-related research
   and development activities.  These results might not be suitable for
   deployment.  This RFC represents the individual opinion(s) of one or
   more members of the Routing Research Group of the Internet Research
   Task Force (IRTF).  Documents approved for publication by the IRSG
   are not a candidate for any level of Internet Standard; see Section 2
   of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5772.

Page 2 
Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1. Background ......................................................4
   2. Results from Group A ............................................5
      2.1. Group A - Requirements for a Next Generation Routing and
           Addressing Architecture ....................................5
           2.1.1. Architecture ........................................6
           2.1.2. Separable Components ................................6
           2.1.3. Scalable ............................................7
           2.1.4. Lots of Interconnectivity ..........................10
           2.1.5. Random Structure ...................................10
           2.1.6. Multi-Homing .......................................11
           2.1.7. Multi-Path .........................................11
           2.1.8. Convergence ........................................12
           2.1.9. Routing System Security ............................14
           2.1.10. End Host Security .................................16
           2.1.11. Rich Policy .......................................16
           2.1.12. Incremental Deployment ............................19
           2.1.13. Mobility ..........................................19
           2.1.14. Address Portability ...............................20
           2.1.15. Multi-Protocol ....................................20
           2.1.16. Abstraction .......................................20
           2.1.17. Simplicity ........................................21
           2.1.18. Robustness ........................................21
           2.1.19. Media Independence ................................22
           2.1.20. Stand-Alone .......................................22
           2.1.21. Safety of Configuration ...........................23
           2.1.22. Renumbering .......................................23
           2.1.23. Multi-Prefix ......................................23
           2.1.24. Cooperative Anarchy ...............................23
           2.1.25. Network-Layer Protocols and Forwarding Model ......23
           2.1.26. Routing Algorithm .................................23
           2.1.27. Positive Benefit ..................................24
           2.1.28. Administrative Entities and the IGP/EGP Split .....24
      2.2. Non-Requirements ..........................................25
           2.2.1. Forwarding Table Optimization ......................25

Top      ToC       Page 3 
           2.2.2. Traffic Engineering ................................25
           2.2.3. Multicast ..........................................25
           2.2.4. Quality of Service (QoS) ...........................26
           2.2.5. IP Prefix Aggregation ..............................26
           2.2.6. Perfect Safety .....................................26
           2.2.7. Dynamic Load Balancing .............................27
           2.2.8. Renumbering of Hosts and Routers ...................27
           2.2.9. Host Mobility ......................................27
           2.2.10. Backward Compatibility ............................27
   3. Requirements from Group B ......................................27
      3.1. Group B - Future Domain Routing Requirements ..............28
      3.2. Underlying Principles .....................................28
           3.2.1. Inter-Domain and Intra-Domain ......................29
           3.2.2. Influences on a Changing Network ...................29
           3.2.3. High-Level Goals ...................................31
      3.3. High-Level User Requirements ..............................35
           3.3.1. Organizational Users ...............................35
           3.3.2. Individual Users ...................................37
      3.4. Mandated Constraints ......................................38
           3.4.1. The Federated Environment ..........................39
           3.4.2. Working with Different Sorts of Networks ...........39
           3.4.3. Delivering Resilient Service .......................39
           3.4.4. When Will the New Solution Be Required? ............40
      3.5. Assumptions ...............................................40
      3.6. Functional Requirements ...................................42
           3.6.1. Topology ...........................................43
           3.6.2. Distribution .......................................44
           3.6.3. Addressing .........................................48
           3.6.4. Statistics Support .................................50
           3.6.5. Management Requirements ............................50
           3.6.6. Provability ........................................51
           3.6.7. Traffic Engineering ................................52
           3.6.8. Support for Middleboxes ............................54
      3.7. Performance Requirements ..................................54
      3.8. Backward Compatibility (Cutover) and Maintainability ......55
      3.9. Security Requirements .....................................56
      3.10. Debatable Issues .........................................57
           3.10.1. Network Modeling ..................................58
           3.10.2. System Modeling ...................................58
           3.10.3. One, Two, or Many Protocols .......................59
           3.10.4. Class of Protocol .................................59
           3.10.5. Map Abstraction ...................................59
           3.10.6. Clear Identification for All Entities .............60
           3.10.7. Robustness and Redundancy .........................60
           3.10.8. Hierarchy .........................................60
           3.10.9. Control Theory ....................................61
           3.10.10. Byzantium ........................................61
           3.10.11. VPN Support ......................................61

Top      ToC       Page 4 
           3.10.12. End-to-End Reliability ...........................62
           3.10.13. End-to-End Transparency ..........................62
   4. Security Considerations ........................................62
   5. IANA Considerations ............................................63
   6. Acknowledgments ................................................63
   7. Informative References .........................................65

1.  Background

   In 2001, the IRTF Routing Research Group (IRTF RRG) chairs, Abha
   Ahuja and Sean Doran, decided to establish a sub-group to look at
   requirements for inter-domain routing (IDR).  A group of well-known
   routing experts was assembled to develop requirements for a new
   routing architecture.  Their mandate was to approach the problem
   starting from a blank slate.  This group was free to take any
   approach, including a revolutionary approach, in developing
   requirements for solving the problems they saw in inter-domain
   routing.

   Simultaneously, an independent effort was started in Sweden with a
   similar goal.  A team, calling itself Babylon, with participation
   from vendors, service providers, and academia assembled to understand
   the history of inter-domain routing, to research the problems seen by
   the service providers, and to develop a proposal of requirements for
   a follow-on to the current routing architecture.  This group's remit
   required an evolutionary approach starting from current routing
   architecture and practice.  In other words, the group limited itself
   to developing an evolutionary strategy.  The Babylon group was later
   folded into the IRTF RRG as Sub-Group B to distinguish it from the
   original RRG Sub-Group A.

   One of the questions that arose while the groups were working in
   isolation was whether there would be many similarities between their
   sets of requirements.  That is, would the requirements that grew from
   a blank sheet of paper resemble those that started with the
   evolutionary approach?  As can be seen from reading the two sets of
   requirements, there were many areas of fundamental agreement but some
   areas of disagreement.

   There were suggestions within the RRG that the two teams should work
   together to create a single set of requirements.  Since these
   requirements are only guidelines to future work, however, some felt
   that doing so would risk losing content without gaining any
   particular advantage.  It is not as if any group, for example, the
   IRTF RRG or the IETF Routing Area, was expected to use these
   requirements as written and to create an architecture that met these
   requirements.  Rather, the requirements were in practice strong

Top      ToC       Page 5 
   recommendations for a way to proceed in creating a new routing
   architecture.  In the end, the decision was made to include the
   results of both efforts, side by side, in one document.

   This document contains the two requirement sets produced by the
   teams.  The text has received only editorial modifications; the
   requirements themselves have been left unaltered.  Whenever the
   editors felt that conditions had changed in the few years since the
   text was written, an editors' note has been added to the text.

   In reading this document, it is important to keep in mind that all of
   these requirements are suggestions, which are laid out to assist
   those interested in developing new routing architectures.  It is also
   important to remember that, while the people working on these
   suggestions have done their best to make intelligent suggestions,
   there are no guarantees.  So a reader of this document should not
   treat what it says as absolute, nor treat every suggestion as
   necessary.  No architecture is expected to fulfill every
   "requirement".  Hopefully, though, future architectures will consider
   what is offered in this document.

   The IRTF RRG supported publication of this document as a historical
   record of the work completed on the understanding that it does not
   necessarily represent either the latest technical understanding or
   the technical consensus of the research group at the time of
   publication.  The document has had substantial review by members of
   the two teams, other members of the IRTF RRG, and additional experts
   over the years.

   Finally, this document does not make any claims that it is possible
   to have a practical solution that meets all the listed requirements.

2.  Results from Group A

   This section presents the results of the work done by Sub-Group A of
   the IRTF RRG during 2001-2002.  The work originally appeared under
   the title: "Requirements For a Next Generation Routing and Addressing
   Architecture" and was edited by Frank Kastenholz.

2.1.  Group A - Requirements for a Next Generation Routing and
      Addressing Architecture

   The requirements presented in this section are not presented in any
   particular order.

Top      ToC       Page 6 
2.1.1.  Architecture

   The new routing and addressing protocols, data structures, and
   algorithms need to be developed from a clear, well thought-out, and
   documented architecture.

   The new routing and addressing system must have an architectural
   specification that describes all of the routing and addressing
   elements, their interactions, what functions the system performs, and
   how it goes about performing them.  The architectural specification
   does not go into issues such as protocol and data structure design.

   The architecture should be agnostic with regard to specific
   algorithms and protocols.

   Doing architecture before doing detailed protocol design is good
   engineering practice.  This allows the architecture to be reviewed
   and commented upon, with changes made as necessary, when it is still
   easy to do so.  Also, by producing an architecture, the eventual
   users of the protocols (the operations community) will have a better
   understanding of how the designers of the protocols meant them to be
   used.

2.1.2.  Separable Components

   The architecture must place different functions into separate
   components.

   Separating functions, capabilities, and so forth into individual
   components and making each component "stand alone" is generally
   considered by system architects to be "A Good Thing".  It allows
   individual elements of the system to be designed and tuned to do
   their jobs "very well".  It also allows for piecemeal replacement and
   upgrading of elements as new technologies and algorithms become
   available.

   The architecture must have the ability to replace or upgrade existing
   components and to add new ones, without disrupting the remaining
   parts of the system.  Operators must be able to roll out these
   changes and additions incrementally (i.e., no "flag days").  These
   abilities are needed to allow the architecture to evolve as the
   Internet changes.

   The architecture specification shall define each of these components,
   their jobs, and their interactions.

Top      ToC       Page 7 
   Some thoughts to consider along these lines are:

   o  Making topology and addressing separate subsystems.  This may
      allow highly optimized topology management and discovery without
      constraining the addressing structure or physical topology in
      unacceptable ways.

   o  Separate "fault detection and healing" from basic topology.  From
      Mike O'Dell:

         Historically the same machinery is used for both.  While
         attractive for many reasons, the availability of exogenous
         topology information (i.e., the intended topology) should, it
         seems, make some tasks easier than the general case of starting
         with zero knowledge.  It certainly helps with recovery in the
         case of constraint satisfaction.  In fact, the intended
         topology is a powerful way to state certain kinds of policy.
         [ODell01]

   o  Making policy definition and application a separate subsystem,
      layered over the others.

   The architecture should also separate topology, routing, and
   addressing from the application that uses those components.  This
   implies that applications such as policy definition, forwarding, and
   circuit and tunnel management are separate subsystems layered on top
   of the basic topology, routing, and addressing systems.

2.1.3.  Scalable

   Scaling is the primary problem facing the routing and addressing
   architecture today.  This problem must be solved and it must be
   solved for the long term.

   The architecture must support a large and complex network.  Ideally,
   it will serve our needs for the next 20 years.  Unfortunately:

   1.  we do not know how big the Internet will grow over that time, and

   2.  the architecture developed from these requirements may change the
       fundamental structure of the Internet and therefore its growth
       patterns.  This change makes it difficult to predict future
       growth patterns of the Internet.

   As a result, we can't quantify the requirement in any meaningful way.
   Using today's architectural elements as a mechanism for describing
   things, we believe that the network could grow to:

Top      ToC       Page 8 
   1.  tens of thousands of ASs

          Editors' Note: As of 2005, this level had already been
          reached.

   2.  tens to hundreds of millions of prefixes, during the lifetime of
       this architecture.

   These sizes are given as a "flavor" for how we expect the Internet to
   grow.  We fully believe that any new architecture may eliminate some
   current architectural elements and introduce new ones.

   A new routing and addressing architecture designed for a specific
   network size would be inappropriate.  First, the cost of routing
   calculations is based only in part on the number of ASs or prefixes
   in the network.  The number and locations of the links in the network
   are also significant factors.  Second, past predictions of Internet
   growth and topology patterns have proven to be wildly inaccurate, so
   developing an architecture to a specific size goal would at best be
   shortsighted.

      Editors' Note: At the time of these meetings, the BGP statistics
      kept at sites such as www.routeviews.org either did not exist or
      had been running for only a few months.  After 5 years of
      recording public Internet data trends in AS growth, routing table
      growth can be observed (past) with some short-term prediction.  As
      each year of data collection continues, the ability to observe and
      predict trends improves.  This architecture work pointed out the
      need for such statistics to improve future routing designs.

   Therefore, we will not make the scaling requirement based on a
   specific network size.  Instead, the new routing and addressing
   architecture should have the ability to constrain the increase in
   load (CPU, memory space and bandwidth, and network bandwidth) on ANY
   SINGLE ROUTER to be less than these specific functions:

   1.  The computational power and memory sizes required to execute the
       routing protocol software and to contain the tables must grow
       more slowly than hardware capabilities described by Moore's Law,
       doubling every 18 months.  Other observations indicate that
       memory sizes double every 2 years or so.

   2.  Network bandwidth and latency are some key constraints on how
       fast routing protocol updates can be disseminated (and therefore
       how fast the routing system can adapt to changes).  Raw network
       bandwidth seems to quadruple every 3 years or so.  However, it
       seems that there are some serious physics problems in going
       faster than 40 Gbit/s (OC768); we should not expect raw network

Top      ToC       Page 9 
       link speed to grow much beyond OC768.  On the other hand, for
       economic reasons, large swathes of the core of the Internet will
       still operate at lower speeds, possibly as slow as DS3.

          Editors' Note: Technology is running ahead of imagination and
          higher speeds are already common.

       Furthermore, in some sections of the Internet, even lower speed
       links are found.  Corporate access links are often T1, or slower.
       Low-speed radio links exist.  Intra-domain links may be T1 or
       fractional-T1 (or slower).

       Therefore, the architecture must not make assumptions about the
       bandwidth available.

   3.  The speeds of high-speed RAMs (Static RAMs (SRAMs), used for
       caches and the like) are growing, though slowly.  Because of
       their use in caches and other very specific applications, these
       RAMs tend to be small, a few megabits, and the size of these RAMs
       is not increasing very rapidly.

       On the other hand, the speed of "large" memories (Dynamic RAMs
       (DRAMs)) is increasing even slower than that for the high-speed
       RAMs.  This is because the development of these RAMs is driven by
       the PC market, where size is very important, and low speed can be
       made up for by better caches.

       Memory access rates should not be expected to increase
       significantly.

          Editors' Note: Various techniques have significantly increased
          memory bandwidth. 800 MHz is now possible, compared with less
          than 100 MHz in the year 2000.  This does not, however,
          contradict the next paragraph, but rather just extends the
          timescales somewhat.

   The growth in resources available to any one router will eventually
   slow down.  It may even stop.  Even so, the network will continue to
   grow.  The routing and addressing architecture must continue to scale
   in even this extreme condition.  We cannot continue to add more
   computing power to routers forever.  Other strategies must be
   available.  Some possible strategies are hierarchy, abstraction, and
   aggregation of topology information.

Top      ToC       Page 10 
2.1.4.  Lots of Interconnectivity

   The new routing and addressing architecture must be able to cope with
   a high degree of interconnectivity in the Internet.  That is, there
   are large numbers of alternate paths and routes among the various
   elements.  Mechanisms are required to prevent this interconnectivity
   (and continued growth in interconnectivity) from causing tables,
   compute time, and routing protocol traffic to grow without bound.
   The "cost" to the routing system of an increase in complexity must be
   limited in scope; sections of the network that do not see, or do not
   care about, the complexity ought not pay the cost of that complexity.

   Over the past several years, the Internet has seen an increase in
   interconnectivity.  Individual end sites (companies, customers,
   etc.), ISPs, exchange points, and so on, all are connecting to more
   "other things".  Companies multi-home to multiple ISPs, ISPs peer
   with more ISPs, and so on.  These connections are made for many
   reasons, such as getting more bandwidth, increased reliability and
   availability, policy, and so on.  However, this increased
   interconnectivity has a price.  It leads to more scaling problems as
   it increases the number of AS paths in the networks.

   Any new architecture must assume that the Internet will become a
   denser mesh.  It must not assume, nor can it dictate, certain
   patterns or limits on how various elements of the network
   interconnect.

   Another facet of this requirement is that there may be multiple
   valid, loop-free paths available to a destination.  See Section 2.1.7
   for a further discussion.

   We wryly note that one of the original design goals of IP was to
   support a large, heavily interconnected network, which would be
   highly survivable (such as in the face of a nuclear war).

2.1.5.  Random Structure

   The routing and addressing architecture must not place any
   constraints on or make assumptions about the topology or
   connectedness of the elements comprising the Internet.  The routing
   and addressing architecture must not presume any particular network
   structure.  The network does not have a "nice" structure.  In the
   past, we used to believe that there was this nice "backbone/tier-1/
   tier-2/end-site" sort of hierarchy.  This is not so.  Therefore, any
   new architecture must not presume any such structure.

Top      ToC       Page 11 
   Some have proposed that a geographic addressing scheme be used,
   requiring exchange points to be situated within each geographic
   "region".  There are many reasons why we believe this to be a bad
   approach, but those arguments are irrelevant.  The main issue is that
   the routing architecture should not presume a specific network
   structure.

2.1.6.  Multi-Homing

   The architecture must provide multi-homing for all elements of the
   Internet.  That is, multi-homing of hosts, subnetworks, end-sites,
   "low-level" ISPs, and backbones (i.e., lots of redundant
   interconnections) must be supported.  Among the reasons to multi-home
   are reliability, load sharing, and performance tuning.

   The term "multi-homing" may be interpreted in its broadest sense --
   one "place" has multiple connections or links to another "place".

   The architecture must not limit the number of alternate paths to a
   multi-homed site.

   When multi-homing is used, it must be possible to use one, some (more
   than one but less than all), or all of the available paths to the
   multi-homed site.  The multi-homed site must have the ability to
   declare which path(s) are used and under what conditions (for
   example, one path may be declared "primary" and the other "backup"
   and to be used only when the primary fails).

   A current problem in the Internet is that multi-homing leads to undue
   increases in the size of the BGP routing tables.  The new
   architecture must support multi-homing without undue routing table
   growth.

2.1.7.  Multi-Path

   As a corollary to multi-homing, the architecture must allow for
   multiple paths from a source to a destination to be active at the
   same time.  These paths need not have the same attributes.  Policies
   are to be used to disseminate the attributes and to classify traffic
   for the different paths.

   There must be a rich "language" for specifying the rules for
   classifying the traffic and assigning classes of traffic to different
   paths (or prohibiting it from certain paths).  The rules should allow
   traffic to be classified based upon, at least, the following:

Top      ToC       Page 12 
   o  IPv6 FlowIDs,

   o  Diffserv Code Point (DSCP) values,

   o  source and/or destination prefixes, or

   o  random selections at some probability.

   A mechanism is needed that allows operators to plan and manage the
   traffic load on the various paths.  To start, this mechanism can be
   semi-automatic or even manual.  Eventually, it ought to become fully
   automatic.

   When multi-path forwarding is used, options must be available to
   preserve packet ordering where appropriate (such as for individual
   TCP connections).

   Please refer to Section 2.2.7 for a discussion of dynamic load-
   balancing and management over multiple paths.

2.1.8.  Convergence

   The speed of convergence (also called the "stabilization time") is
   the time it takes for a router's routing processes to reach a new,
   stable, "solution" (i.e., forwarding information base) after a change
   someplace in the network.  In effect, what happens is that the output
   of the routing calculations stabilizes -- the Nth iteration of the
   software produces the same results as the N-1th iteration.

   The speed of convergence is generally considered to be a function of
   the number of subnetworks in the network and the amount of
   connections between those networks.  As either number grows, the time
   it takes to converge increases.

   In addition, a change can "ripple" back and forth through the system.
   One change can go through the system, causing some other router to
   change its advertised connectivity, causing a new change to ripple
   through.  These oscillations can take a while to work their way out
   of the network.  It is also possible that these ripples never die
   out.  In this situation, the routing and addressing system is
   unstable; it never converges.

   Finally, it is more than likely that the routers comprising the
   Internet never converge simply because the Internet is so large and
   complex.  Assume it takes S seconds for the routers to stabilize on a
   solution for any one change to the network.  Also, assume that
   changes occur, on average, every C seconds.  Because of the size and
   complexity of the Internet, C is now less than S.  Therefore, if a

Top      ToC       Page 13 
   change, C1, occurs at time T, the routing system would stabilize at
   time T+S, but a new change, C2, will occur at time T+C, which is
   before T+S.  The system will start processing the new change before
   it's done with the old.

   This is not to say that all routers are constantly processing
   changes.  The effects of changes are like ripples in a pond.  They
   spread outward from where they occur.  Some routers will be
   processing just C1, others C2, others both C1 and C2, and others
   neither.

   We have two separate scopes over which we can set requirements with
   respect to convergence:

   1.  Single Change: In this requirement, a single change of any type
       (link addition or deletion, router failure or restart, etc.) is
       introduced into a stabilized system.  No additional changes are
       introduced.  The system must re-stabilize within some measure of
       bounded time.  This requirement is a fairly abstract one as it
       would be impossible to test in a real network.  Definition of the
       time constraints remains an open research issue.

   2.  System-Wide: Defining a single target for maximum convergence
       time for the real Internet is absurd.  As we mentioned earlier,
       the Internet is large enough and diverse enough so that it is
       quite likely that new changes are introduced somewhere before the
       system fully digests old ones.

   So, the first requirement here is that there must be mechanisms to
   limit the scope of any one change's visibility and effects.  The
   number of routers that have to perform calculations in response to a
   change is kept small, as is the settling time.

   The second requirement is based on the following assumptions:

   -  the scope of a change's visibility and impact can be limited.
      That is, routers within that scope know of the change and
      recalculate their tables based on the change.  Routers outside of
      the scope don't see it at all.

   -  Within any scope, S, network changes are constantly occurring and
      the average inter-change interval is Tc seconds.

   -  There are Rs routers within scope S.

   -  A subset of the destinations known to the routers in S, Ds, are
      impacted by a given change.

Top      ToC       Page 14 
   -  We can state that for Z% of the changes, within Y% of Tc seconds
      after a change, C, X% of the Rs routers have their routes to Ds
      settled to a useful answer (useful meaning that packets can get to
      Ds, though perhaps not by the optimal path -- this allows some
      "hunting" for the optimal solution).

      X, Y, and Z are yet to be defined.  Their definition remains a
      research issue.

   This requirement implies that the scopes can be kept relatively small
   in order to minimize Rs and maximize Tc.

   The growth rate of the convergence time must not be related to the
   growth rate of the Internet as a whole.  This implies that the
   convergence time either:

   1.  not be a function of basic network elements (such as prefixes and
       links/paths), and/or

   2.  that the Internet be continuously divisible into chunks that
       limit the scope and effect of a change, thereby limiting the
       number of routers, prefixes, links, and so on, involved in the
       new calculations.

2.1.9.  Routing System Security

   The security of the Internet's routing system is paramount.  If the
   routing system is compromised or attacked, the entire Internet can
   fail.  This is unacceptable.  Any new architecture must be secure.

   Architectures by themselves are not secure.  It is the implementation
   of an architecture, its protocols, algorithms, and data structures
   that are secure.  These requirements apply primarily to the
   implementation.  The architecture must provide the elements that the
   implementation needs to meet these security requirements.  Also, the
   architecture must not prevent these security requirements from being
   met.

   Security means different things to different people.  In order for
   this requirement to be useful, we must define what we mean by
   security.  We do this by identifying the attackers and threats we
   wish to protect against.  They are:

Top      ToC       Page 15 
   Masquerading
         The system, including its protocols, must be secure against
         intruders adopting the identity of other known, trusted
         elements of the routing system and then using that position of
         trust for carrying out other attacks.  Protocols must use
         cryptographically strong authentication.

   Denial-of-Service (DoS) Attacks
         The architecture and protocols should be secure against DoS
         attacks directed at the routers.

         The new architecture and protocols should provide as much
         information as it can to allow administrators to track down
         sources of DoS and Distributed DOS (DDoS) attacks.

   No Bad Data
         Any new architecture and protocols must provide protection
         against the introduction of bad, erroneous, or misleading data
         by attackers.  Of particular importance, an attacker must not
         be able to redirect traffic flows, with the intent of:

         o  directing legitimate traffic away from a target, causing a
            denial-of-service attack by preventing legitimate data from
            reaching its destination,

         o  directing additional traffic (going to other destinations
            that are "innocent bystanders") to a target, causing the
            target to be overloaded, or

         o  directing traffic addressed to the target to a place where
            the attacker can copy, snoop, alter, or otherwise affect the
            traffic.

   Topology Hiding
         Any new architecture and protocols must provide mechanisms to
         allow network owners to hide the details of their internal
         topologies, while maintaining the desired levels of service
         connectivity and reachability.

   Privacy
         By "privacy" we mean privacy of the routing protocol exchanges
         between routers.

         When the routers are on point-to-point links, with routers at
         each end, there may not be any need to encrypt the routing
         protocol traffic as the possibility of a third party

Top      ToC       Page 16 
         intercepting the traffic is limited, though not impossible.  We
         do believe, however, that it is important to have the ability
         to protect routing protocol traffic in two cases:

         1.  When the routers are on a shared network, it is possible
             that there are hosts on the network that have been
             compromised.  These hosts could surreptitiously monitor the
             protocol traffic.

         2.  When two routers are exchanging information "at a distance"
             (over intervening routers and, possibly, across
             administrative domain boundaries).  In this case, the
             security of the intervening routers, links, and so on,
             cannot be assured.  Thus, the ability to encrypt this
             traffic is important.

         Therefore, we believe that the option to encrypt routing
         protocol traffic is required.

   Data Consistency
         A router should be able to detect and recover from any data
         that is received from other routers that is inconsistent.  That
         is, it must not be possible for data from multiple routers,
         none of which is malicious, to "break" another router.

   Where security mechanisms are provided, they must use methods that
   are considered to be cryptographically secure (e.g., using
   cryptographically strong encryption and signatures -- no cleartext
   passwords!).

   Use of security features should not be optional (except as required
   above).  This may be "social engineering" on our part, but we believe
   it to be necessary.  If a security feature is optional, the
   implementation of the feature must default to the "secure" setting.

2.1.10.  End Host Security

   The architecture must not prevent individual host-to-host
   communications sessions from being secured (i.e., it cannot interfere
   with things like IPsec).

2.1.11.  Rich Policy

   Before setting out policy requirements, we need to define the term.
   Like "security", "policy" means different things to different people.
   For our purposes, "policy" is the set of administrative influences
   that alter the path determination and next-hop selection procedures
   of the routing software.

Top      ToC       Page 17 
   The main motivators for influencing path and next-hop selection seem
   to be transit rules, business decisions, and load management.

   The new architecture must support rich policy mechanisms.
   Furthermore, the policy definition and dissemination mechanisms
   should be separated from the network topology and connectivity
   dissemination mechanisms.  Policy provides input to and controls the
   generation of the forwarding table and the abstraction, filtering,
   aggregation, and dissemination of topology information.

   Note that if the architecture is properly divided into subsystems,
   then at a later time, new policy subsystems that include new features
   and capabilities could be developed and installed as needed.

   We divide the general area of policy into two sub-categories: routing
   information and traffic control.  Routing Information Policies
   control what routing information is disseminated or accepted, how it
   is disseminated, and how routers determine paths and next-hops from
   the received information.  Traffic Control Policies determine how
   traffic is classified and assigned to routes.

2.1.11.1.  Routing Information Policies

   There must be mechanisms to allow network administrators, operators,
   and designers to control receipt and dissemination of routing
   information.  These controls include, but are not limited to:

   -  Selecting to which other routers routing information will be
      transmitted.

   -  Specifying the "granularity" and type of transmitted information.
      The length of IPv4 prefixes is an example of granularity.

   -  Selection and filtering of topology and service information that
      is transmitted.  This gives different "views" of internal
      structure and topology to different peers.

   -  Selecting the level of security and authenticity for transmitted
      information.

   -  Being able to cause the level of detail that is visible for some
      portion of the network to reduce the farther you get from that
      part of the network.

   -  Selecting from whom routing information will be accepted.  This
      control should be "provisional" in the sense of "accept routes
      from "foo" only if there are no others available".

Top      ToC       Page 18 
   -  Accepting or rejecting routing information based on the path the
      information traveled (using the current system as an example, this
      would be filtering routes based on an AS appearing anywhere in the
      AS path).  This control should be "use only if there are no other
      paths available".

   -  Selecting the desired level of granularity for received routing
      information (this would include, but is not limited to, things
      similar in nature to the prefix-length filters widely used in the
      current routing and addressing system).

   -  Selecting the level of security and authenticity of received
      information in order for that information to be accepted.

   -  Determining the treatment of received routing information based on
      attributes supplied with the information.

   -  Applying attributes to routing information that is to be
      transmitted and then determining treatment of information (e.g.,
      sending it "here" but not "there") based on those tags.

   -  Selection and filtering of topology and service information that
      is received.

2.1.11.2.  Traffic Control Policies

   The architecture should provide mechanisms that allow network
   operators to manage and control the flow of traffic.  The traffic
   controls should include, but are not limited to:

   -  The ability to detect and eliminate congestion points in the
      network (by redirecting traffic around those points).

   -  The ability to develop multiple paths through the network with
      different attributes and then assign traffic to those paths based
      on some discriminators within the packets (discriminators include,
      but are not limited to, IP addresses or prefixes, IPv6 flow ID,
      DSCP values, and MPLS labels).

   -  The ability to find and use multiple, equivalent paths through the
      network (i.e., they would have the "same" attributes) and allocate
      traffic across the paths.

   -  The ability to accept or refuse traffic based on some traffic
      classification (providing, in effect, transit policies).

Top      ToC       Page 19 
      Traffic classification must at least include the source and
      destination IP addresses (prefixes) and the DSCP value.  Other
      fields may be supported, such as:

      *  Protocol and port-based functions,

      *  DSCP/QoS (Quality of Service) tuple (such as ports),

      *  Per-host operations (i.e., /32 s for IPv4 and /128 s for IPv6),
         and

      *  Traffic matrices (e.g., traffic from prefix X and to prefix Y).

2.1.12.  Incremental Deployment

   The reality of the Internet is that there can be no Internet-wide
   cutover from one architecture and protocol to another.  This means
   that any new architecture and protocol must be incrementally
   deployable; ISPs must be able to set up small sections of the new
   architecture, check it out, and then slowly grow the sections.
   Eventually, these sections will "touch" and "squeeze out" the old
   architecture.

   The protocols that implement the architecture must be able to
   interoperate at "production levels" with currently existing routing
   protocols.  Furthermore, the protocol specifications must define how
   the interoperability is done.

   We also believe that sections of the Internet will never convert over
   to the new architecture.  Thus, it is important that the new
   architecture and its protocols be able to interoperate with "old
   architecture" regions of the network indefinitely.

   The architecture's addressing system must not force existing address
   allocations to be redone: no renumbering!

2.1.13.  Mobility

   There are two kinds of mobility: host mobility and network mobility.
   Host mobility is when an individual host moves from where it was to
   where it is.  Network mobility is when an entire network (or
   subnetwork) moves.

   The architecture must support network-level mobility.  Please refer
   to Section 2.2.9 for a discussion of host mobility.

Top      ToC       Page 20 
      Editors' Note: Since the time of this work, the Network Mobility
      (NEMO) extensions to Mobile-IP [RFC3963] to accommodate mobile
      networks have been developed.

2.1.14.  Address Portability

   One of the big "hot items" in the current Internet political climate
   is portability of IP addresses (both v4 and v6).  The short
   explanation is that people do not like to renumber when changing
   connection point or provider and do not trust automated renumbering
   tools.

   The architecture must provide complete address portability.

2.1.15.  Multi-Protocol

   The Internet is expected to be "multi-protocol" for at least the next
   several years.  IPv4 and IPv6 will co-exist in many different ways
   during a transition period.  The architecture must be able to handle
   both IPv4 and IPv6 addresses.  Furthermore, protocols that supplant
   IPv4 and IPv6 may be developed and deployed during the lifetime of
   the architecture.  The architecture must be flexible and extensible
   enough to handle new protocols as they arise.

   Furthermore, the architecture must not assume any given relationships
   between a topological element's IPv4 address and its IPv6 address.
   The architecture must not assume that all topological elements have
   IPv4 addresses/prefixes, nor can it assume that they have IPv6
   addresses/prefixes.

   The architecture should allow different paths to the same destination
   to be used for different protocols, even if all paths can carry all
   protocols.

   In addition to the addressing technology, the architecture need not
   be restricted to only packet-based multiplexing/demultiplexing
   technology (such as IP); support for other multiplexing/
   demultiplexing technologies may be added.

2.1.16.  Abstraction

   The architecture must provide mechanisms for network designers and
   operators to:

   o  Group elements together for administrative control purposes,

   o  Hide the internal structure and topology of those groupings for
      administrative and security reasons,

Top      ToC       Page 21 
   o  Limit the amount of topology information that is exported from the
      groupings in order to control the load placed on external routers,

   o  Define rules for traffic transiting or terminating in the
      grouping.

   The architecture must allow the current Autonomous System structure
   to be mapped into any new abstraction schemes.

   Mapping mechanisms, algorithms, and techniques must be specified.

2.1.17.  Simplicity

   The architecture must be simple enough so that someone who is
   extremely knowledgeable in routing and who is skilled at creating
   straightforward and simple explanations can explain all the important
   concepts in less than an hour.

   This criterion has been chosen since developing an objective measure
   of complexity for an architecture can be very difficult and is out of
   scope for this document.

   The requirement is that the routing architecture be kept as simple as
   possible.  This requires careful evaluation of possible features and
   functions with a merciless weeding out of those that "might be nice"
   but are not necessary.

   By keeping the architecture simple, the protocols and software used
   to implement the architecture are simpler.  This simplicity in turn
   leads to:

   1.  Faster implementation of the protocols.  If there are fewer bells
       and whistles, then there are fewer things that need to be
       implemented.

   2.  More reliable implementations.  With fewer components, there is
       less code, reducing bug counts, and fewer interactions between
       components that could lead to unforeseen and incorrect behavior.

2.1.18.  Robustness

   The architecture, and the protocols implementing it, should be
   robust.  Robustness comes in many different flavors.  Some
   considerations with regard to robustness include (but are not limited
   to):

   o  Continued correct operation in the face of:

Top      ToC       Page 22 
      *  Defective (even malicious) trusted routers.

      *  Network failures.  Whenever possible, valid alternate paths are
         to be found and used.

   o  Failures must be localized.  That is, the architecture must limit
      the "spread" of any adverse effects of a misconfiguration or
      failure.  Badness must not spread.

   Of course, the general robustness principle of being liberal in
   what's accepted and conservative in what's sent must also be applied.

      Original Editor's Note: Some of the contributors to this section
      have argued that robustness is an aspect of security.  I have
      exercised editor's discretion by making it a separate section.
      The reason for this is that to too many people "security" means
      "protection from break-ins" and "authenticating and encrypting
      data".  This requirement goes beyond those views.

2.1.19.  Media Independence

   While it is an article of faith that IP operates over a wide variety
   of media (such as Ethernet, X.25, ATM, and so on), IP routing must
   take an agnostic view toward any "routing" or "topology" services
   that are offered by the medium over which IP is operating.  That is,
   the new architecture must not be designed to integrate with any
   media-specific topology management or routing scheme.

   The routing architecture must assume, and must work over, the
   simplest possible media.

   The routing and addressing architecture can certainly make use of
   lower-layer information and services, when and where available, and
   to the extent that IP routing wishes.

2.1.20.  Stand-Alone

   The routing architecture and protocols must not rely on other
   components of the Internet (such as DNS) for their correct operation.
   Routing is the fundamental process by which data "finds its way
   around the Internet" and most, if not all, of those other components
   rely on routing to properly forward their data.  Thus, routing cannot
   rely on any Internet systems, services, or capabilities that in turn
   rely on routing.  If it did, a dependency loop would result.

Top      ToC       Page 23 
2.1.21.  Safety of Configuration

   The architecture, protocols, and standard implementation defaults
   must be such that a router installed "out of the box" with no
   configuration, etc., by the operators will not cause "bad things" to
   happen to the rest of the routing system (e.g., no dial-up customers
   advertising routes to 18/8!).

2.1.22.  Renumbering

   The routing system must allow topological entities to be renumbered.

2.1.23.  Multi-Prefix

   The architecture must allow topological entities to have multiple
   prefixes (or the equivalent under the new architecture).

2.1.24.  Cooperative Anarchy

   As RFC 1726[RFC1726] states:

      A major contributor to the Internet's success is the fact that
      there is no single, centralized, point of control or promulgator
      of policy for the entire network.  This allows individual
      constituents of the network to tailor their own networks,
      environments, and policies to suit their own needs.  The
      individual constituents must cooperate only to the degree
      necessary to ensure that they interoperate.

   This decentralization, called "cooperative anarchy", is still a key
   feature of the Internet today.  The new routing architecture must
   retain this feature.  There can be no centralized point of control or
   promulgator of policy for the entire Internet.

2.1.25.  Network-Layer Protocols and Forwarding Model

   For the purposes of backward compatibility, any new routing and
   addressing architecture and protocols must work with IPv4 and IPv6
   using the traditional "hop-by-hop" forwarding and packet-based
   multiplex/demultiplex models.  However, the architecture need not be
   restricted to these models.  Additional forwarding and multiplex/
   demultiplex models may be added.

2.1.26.  Routing Algorithm

   The architecture should not require a particular routing algorithm
   family.  That is to say, the architecture should be agnostic about
   link-state, distance-vector, or path-vector routing algorithms.

Top      ToC       Page 24 
2.1.27.  Positive Benefit

   Finally, the architecture must show benefits in terms of increased
   stability, decreased operational costs, and increased functionality
   and lifetime, over the current schemes.  This benefit must remain
   even after the inevitable costs of developing and debugging the new
   protocols, enduring the inevitable instabilities as things get shaken
   out, and so on.

2.1.28.  Administrative Entities and the IGP/EGP Split

   We explicitly recognize that the Internet consists of resources under
   control of multiple administrative entities.  Each entity must be
   able to manage its own portion of the Internet as it sees fit.
   Moreover, the constraints that can be imposed on routing and
   addressing on the portion of the Internet under the control of one
   administration may not be feasibly extended to cover multiple
   administrations.  Therefore, we recognize a natural and inevitable
   split between routing and addressing that is under a single
   administrative control and routing and addressing that involves
   multiple administrative entities.  Moreover, while there may be
   multiple administrative authorities, the administrative authority
   boundaries may be complex and overlapping, rather than being a strict
   hierarchy.

   Furthermore, there may be multiple levels of administration, each
   with its own level of policy and control.  For example, a large
   network might have "continental-level" administrations covering its
   European and Asian operations, respectively.  There would also be
   that network's "inter-continental" administration covering the
   Europe-to-Asia links.  Finally, there would be the "Internet" level
   in the administrative structure (analogous to the "exterior" concept
   in the current routing architecture).

   Thus, we believe that the administrative structure of the Internet
   must be extensible to many levels (more than the two provided by the
   current IGP/EGP split).  The interior/exterior property is not
   absolute.  The interior/exterior property of any point in the network
   is relative; a point on the network is interior with respect to some
   points on the network and exterior with respect to others.

   Administrative entities may not trust each other; some may be almost
   actively hostile toward each other.  The architecture must
   accommodate these models.  Furthermore, the architecture must not
   require any particular level of trust among administrative entities.


Next RFC Part