Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: IRTF

RFC 5772

A Set of Possible Requirements for a Future Routing Architecture

Pages: 68
Part 3 of 3 – Pages 42 to 68
First   Prev   None

Top   ToC   RFC5772 - Page 42   prevText
3.6.  Functional Requirements

   This section includes a detailed discussion of new requirements for a
   Future Domain Routing architecture.  The nth requirement carries the
   label "R(n)".  As discussed in Section, a new architecture
Top   ToC   RFC5772 - Page 43
   must build upon the requirements of the past routing framework and
   must not reduce the functionality of the network.  A discussion and
   analysis of the RFC 1126 requirements can be found in [RFC5773].

3.6.1.  Topology  Routers Should Be Able to Learn and to Exploit the Domain

   R(1)  Routers must be able to acquire and hold sufficient information
         on the underlying topology of the domain to allow the
         establishment of routes on that topology.

   R(2)  Routers must have the ability to control the establishment of
         routes on the underlying topology.

   R(3)  Routers must be able, where appropriate, to control Sub-IP
         mechanisms to support the establishment of routes.

   The OSI Inter-Domain Routing Protocol (IDRP) [ISO10747] allowed a
   collection of topologically related domains to be replaced by an
   aggregate domain object, in a similar way to the Nimrod [Chiappa02]
   domain hierarchies.  This allowed a route to be more compactly
   represented by a single collection instead of a sequence of
   individual domains.

   R(4)  Routers must, where appropriate, be able to construct
         abstractions of the topology that represent an aggregation of
         the topological features of some area of the topology.  The Same Topology Information Should Support Different Path
          Selection Ideas

   The same topology information needs to provide the more flexible
   spectrum of path selection methods that we might expect to find in a
   future Internet, including distributed techniques such as hop-by-hop,
   shortest path, local optimization constraint-based, class of service,
   source address routing, and destination address routing, as well as
   the centralized, global optimization constraint-based "traffic
   engineering" type.  Allowing different path selection techniques will
   produce a much more predictable and comprehensible result than the
   "clever tricks" that are currently needed to achieve the same
   results.  Traffic engineering functions need to be combined.

   R(5)  Routers must be capable of supporting a small number of
         different path selection algorithms.
Top   ToC   RFC5772 - Page 44  Separation of the Routing Information Topology from the Data
          Transport Topology

   R(6)  The controlling network may be logically separate from the
         controlled network.

   The two functional "planes" may physically reside in the same nodes
   and share the same links, but this is not the only possibility, and
   other options may sometimes be necessary.  An example is a pure
   circuit switch (that cannot see individual IP packets) combined with
   an external controller.  Another example may be multiple links
   between two routers, where all the links are used for data forwarding
   but only one is used for carrying the routing session.

3.6.2.  Distribution  Distribution Mechanisms

   R(7)  Relevant changes in the state of the network, including
         modifications to the topology and changes in the values of
         dynamic capabilities, must be distributed to every entity in
         the network that needs them, in a reliable and trusted way, at
         the earliest appropriate time after the changes have occurred.

   R(8)  Information must not be distributed outside areas where it is
         needed, or believed to be needed, for the operation of the
         routing system.

   R(9)  Information must be distributed in such a way that it minimizes
         the load on the network, consistent with the required response
         time of the network to changes.  Path Advertisement

   R(10)  The router must be able to acquire and store additional static
          and dynamic information that relates to the capabilities of
          the topology and its component nodes and links and that can
          subsequently be used by path selection methods.

   The inter-domain routing system must be able to advertise more kinds
   of information than just connectivity and domain paths.

   R(11)  The routing system must support service specifications, e.g.,
          the Service Level Specifications (SLSs) developed by the
          Differentiated Services working group [RFC3260].
Top   ToC   RFC5772 - Page 45
   Careful attention should be paid to ensuring that the distribution of
   additional information with path advertisements remains scalable as
   domains and the Internet get larger, more numerous, and more

   R(12)  The distribution mechanism used for distributing network state
          information must be scalable with respect to the expected size
          of domains and the volume and rate of change of dynamic state
          that can be expected.

   The combination of R(9) and R(12) may result in a compromise between
   the responsiveness of the network to change and the overhead of
   distributing change notifications.  Attempts to respond to very rapid
   changes may damage the stability of the routing system.

   Possible examples of additional capability information that might be
   carried include:

   -  QoS information

      To allow an ISP to sell predictable end-to-end QoS service to any
      destination, the routing system should have information about the
      end-to-end QoS.  This means that:

   R(13)  The routing system must be able to support different paths for
          different services.

   R(14)  The routing system must be able to forward traffic on the path
          appropriate for the service selected for the traffic, either
          according to an explicit marking in each packet (e.g., MPLS
          labels, Diffserv Per-Hop Behaviors (PHBs) or DSCP values) or
          implicitly (e.g., the physical or logical port on which the
          traffic arrives).

   R(15)  The routing system should also be able to carry information
          about the expected (or actually, promised) characteristics of
          the entire path and the price for the service.

      (If such information is exchanged at all between network operators
      today, it is through bilateral management interfaces, and not
      through the routing protocols.)

      This would allow for the operator to optimize the choice of path
      based on a price/performance trade-off.

      In addition to providing dynamic QoS information, the system
      should be able to use static class-of-service information.
Top   ToC   RFC5772 - Page 46
   -  Security information

      Security characteristics of other domains referred to by
      advertisements can allow the routing entity to make routing
      decisions based on political concerns.  The information itself is
      assumed to be secure so that it can be trusted.

   -  Usage and cost information

      Usage and cost information can be used for billing and traffic
      engineering.  In order to support cost-based routing policies for
      customers (i.e., peer ISPs), information such as "traffic on this
      link or path costs XXX per Gigabyte" needs to be advertised, so
      that the customer can choose a more or a less expensive route.

   -  Monitored performance

      Performance information such as delay and drop frequency can be
      carried.  (This may only be suitable inside a domain because of
      trust considerations.)  This should support at least the kind of
      delay-bound contractual terms that are currently being offered by
      service providers.  Note that these values refer to the outcome of
      carrying bits on the path, whereas the QoS information refers to
      the proposed behavior that results in this outcome.

   -  Multicast information

   R(16)  The routing system must provide information needed to create
          multicast distribution trees.  This information must be
          provided for one-to-many distribution trees and should be
          provided for many-to-many distribution trees.

      The actual construction of distribution trees is not necessarily
      done by the routing system.  Stability of Routing Information

   R(17)  The new network architecture must be stable without needing
          global convergence, i.e., convergence is a local property.

   The degree to which this is possible and the definition of "local"
   remain research topics.  Restricting the requirement for convergence
   to localities will have an effect on all of the other requirements in
   this section.
Top   ToC   RFC5772 - Page 47
   R(18)  The distribution and the rate of distribution of changes must
          not affect the stability of the routing information.  For
          example, commencing redistribution of a change before the
          previous one has settled must not cause instability.  Avoiding Routing Oscillations

   R(19)  The routing system must minimize oscillations in route
          advertisements.  Providing Loop-Free Routing and Forwarding

   In line with the separation of routing and forwarding concerns:

   R(20)  The distribution of routing information must be, so far as is
          possible, loop-free.

   R(21)  The forwarding information created from this routing
          information must seek to minimize persistent loops in the
          data-forwarding paths.

   It is accepted that transient loops may occur during convergence of
   the protocol and that there are trade-offs between loop avoidance and
   global scalability.  Detection, Notification, and Repair of Failures

   R(22)  The routing system must provide means for detecting failures
          of node equipment or communication links.

   R(23)  The routing system should be able to coordinate failure
          indications from Layer 3 mechanisms, from nodal mechanisms
          built into the routing system, and from lower-layer mechanisms
          that propagate up to Layer 3 in order to determine the root
          cause of the failure.  This will allow the routing system to
          react correctly to the failure by activating appropriate
          mitigation and repair mechanisms if required, while ensuring
          that it does not react if lower-layer repair mechanisms are
          able to repair or mitigate the fault.

   Most Layer 3 routing protocols have utilized keepalives or "hello"
   protocols as a means of detecting failures at Layer 3.  The keepalive
   mechanisms are often complemented by analog mechanisms (e.g., laser-
   light detection) and hardware mechanisms (e.g., hardware/software
   watchdogs) that are built into routing nodes and communication links.
   Great care must be taken to make the best possible use of the various
   failure repair methods available while ensuring that only one repair
   mechanism at a time is allowed to repair any given fault.
Top   ToC   RFC5772 - Page 48
   Interactions between, for example, fast reroute mechanisms at Layer 3
   and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/
   SDH) repair at Layer 1 are highly undesirable and are likely to cause
   problems in the network.

   R(24)  Where a network topology and routing system contains multiple
          fault repair mechanisms, the responses of these systems to a
          detected failure should be coordinated so that the fault is
          repaired by the most appropriate means, and no extra repairs
          are initiated.

   R(25)  Where specialized packet exchange mechanisms (e.g., Layer 3
          keepalive or "hello" protocol mechanisms) are used to detect
          failures, the routing system must allow the configuration of
          the rate of transmission of these keepalives.  This must
          include the capability to turn them off altogether for links
          that are deliberately broken when no real user or control
          traffic is present (e.g., ISDN links).

   This will allow the operator to compromise between the speed of
   failure detection and the proportion of link bandwidth dedicated to
   failure detection.

3.6.3.  Addressing  Support Mix of IPv4, IPv6, and Other Types of Addresses

   R(26)  The routing system must support a mix of different kinds of

   This mix will include at least IPv4 and IPv6 addresses, and
   preferably various types of non-IP addresses, too.  For instance,
   networks like SDH/SONET and Wavelength Division Multiplexing (WDM)
   may prefer to use non-IP addresses.  It may also be necessary to
   support multiple sets of "private" (e.g., RFC 1918) addresses when
   dealing with multiple customer VPNs.

   R(27)  The routing system should support the use of a single topology
          representation to generate routing and forwarding tables for
          multiple address families on the same network.

   This capability would minimize the protocol overhead when exchanging
Top   ToC   RFC5772 - Page 49  Support for Domain Renumbering/Readdressing

   R(28)  If a domain is subject to address reassignment that would
          cause forwarding interruption, then the routing system should
          support readdressing (e.g., when a new prefix is given to an
          old network, and the change is known in advance) by
          maintaining routing during the changeover period [RFC2071]
          [RFC2072].  Multicast and Anycast

   R(29)  The routing system must support multicast addressing, both
          within a domain and across multiple domains.

   R(30)  The routing system should support anycast addressing within a
          domain.  The routing system may support anycast addressing
          across domains.

   An open question is whether it is possible or useful to support
   anycast addressing between cooperating domains.  Address Scoping

   R(31)  The routing system must support scoping of unicast addresses,
          and it should support scoping of multicast and anycast address

   The unicast address scoping that is being designed for IPv6 does not
   seem to cause any special problems for routing.  IPv6 inter-domain
   routing handles only IPv6 global addresses, while intra-domain
   routing also needs to be aware of the scope of private addresses.

      Editors' Note: the original reference was to site-local addresses,
      but these have been deprecated by the IETF.  Link-local addresses
      are never routed at all.

   More study may be needed to identify the requirements and solutions
   for scoping in a more general sense and for scoping of multicast and
   anycast addresses.  Mobility Support

   R(32)  The routing system must support system mobility.  The term
          "system" includes anything from an end system to an entire
Top   ToC   RFC5772 - Page 50
   We observe that the existing solutions based on renumbering and/or
   tunneling are designed to work with the current routing, so they do
   not add any new requirements to future routing.  But the requirement
   is general, and future solutions may not be restricted to the ones we
   have today.

3.6.4.  Statistics Support

   R(33)  Both the routing and forwarding parts of the routing system
          must maintain statistical information about the performance of
          their functions.

3.6.5.  Management Requirements

   While the tools of management are outside the scope of routing, the
   mechanisms to support the routing architecture and protocols are
   within scope.

   R(34)  Mechanisms to support Operational, Administrative, and
          Management control of the routing architecture and protocols
          must be designed into the original fabric of the architecture.  Simple Policy Management

   The basic aims of this specification are:

   -  to require less manual configuration than today, and

   -  to satisfy the requirements for both easy handling and maximum
      control.  That is:

      -  All the information should be available,

      -  but should not be visible except for when necessary.

      -  Policies themselves should be advertised and not only the
         result of policy, and

      -  policy-conflict resolution must be provided.

   R(35)  The routing system must provide management of the system by
          means of policies.  For example, policies that can be
          expressed in terms of the business and services implemented on
          the network and reflect the operation of the network in terms
          of the services affected.
Top   ToC   RFC5772 - Page 51
                Editors' Note: This requirement is optimistic in that it
                implies that it is possible to get operators to
                cooperate even if it is seen by them to be against their
                business practices.

   R(36)  The distribution of policies must be amenable to scoping to
          protect proprietary policies that are not relevant beyond the
          local set of domains.  Startup and Maintenance of Routers

   A major problem in today's networks is the need to perform initial
   configuration on routers from a local interface before a remote
   management system can take over.  It is not clear that this imposes
   any requirements on the routing architecture beyond what is needed
   for a ZeroConf host.

   Similarly, maintenance and upgrade of routers can cause major
   disruptions to the network routing because the routing system and
   management of routers is not organized to minimize such disruption.
   Some improvements have been made, such as graceful restart mechanisms
   in protocols, but more needs to be done.

   R(37)  The routing system and routers should provide mechanisms that
          minimize the disruption to the network caused by maintenance
          and upgrades of software and hardware.  This requirement
          recognizes that some of the capabilities needed are outside
          the scope of the routing architecture (e.g., minimum impact
          software upgrade).

3.6.6.  Provability

   R(38)  The routing system and its component protocols must be
          demonstrated to be locally convergent under the permitted
          range of parameter settings and policy options that the
          operator(s) can select.

   There are various methods for demonstration and proof that include,
   but are not limited to: mathematical proof, heuristic, and pattern
   recognition.  No requirement is made on the method used for
   demonstrating local convergence properties.

   R(39)  Routing protocols employed by the routing system and the
          overall routing system should be resistant to bad routing
          policy decisions made by operators.
Top   ToC   RFC5772 - Page 52
   Tools are needed to check compatibility of routing policies.  While
   these tools are not part of the routing architecture, the mechanisms
   to support such tools are.

   Routing policies are compatible if their interaction does not cause
   instability.  A domain or group of domains in a system is defined as
   being convergent, either locally or globally, if and only if, after
   an exchange of routing information, routing tables reach a stable
   state that does not change until the routing policies or the topology
   changes again.

   To achieve the above-mentioned goals:

   R(40)  The routing system must provide a mechanism to publish and
          communicate policies so that operational coordination and
          fault isolation are possible.

   Tools are required that verify the stability characteristics of the
   routing system in specified parts of the Internet.  The tools should
   be efficient (fast) and have a broad scope of operation (check large
   portions of Internet).  While these tools are not part of the
   architecture, developing them is in the interest of the architecture
   and should be defined as a Routing Research Group activity while
   research on the architecture is in progress.

   Tools analyzing routing policies can be applied statically or
   (preferably) dynamically.  A dynamic solution requires tools that can
   be used for run time checking for oscillations that arise from policy
   conflicts.  Research is needed to find an efficient solution to the
   dynamic checking of oscillations.

3.6.7.  Traffic Engineering

   The ability to do traffic engineering and to get the feedback from
   the network to enable traffic engineering should be included in the
   future domain architecture.  Though traffic engineering has many
   definitions, it is, at base, another alternative or extension for the
   path selection mechanisms of the routing system.  No fundamental
   changes to the requirements are needed, but the iterative processes
   involved in traffic engineering may require some additional
   capabilities and state in the network.

   Traffic engineering typically involves a combination of off-line
   network planning and administrative control functions in which the
   expected and measured traffic flows are examined, resulting in
   changes to static configurations and policies in the routing system.
Top   ToC   RFC5772 - Page 53
   During operations, these configurations control the actual flow of
   traffic and affect the dynamic path selection mechanisms; the results
   are measured and fed back into further rounds of network planning.  Support for, and Provision of, Traffic Engineering Tools

   At present, there is an almost total lack of effective traffic
   engineering tools, whether in real time for network control or off-
   line for network planning.  The routing system should encourage the
   provision of such tools.

   R(41)  The routing system must generate statistical and accounting
          information in such a way that traffic engineering and network
          planning tools can be used in both real-time and off-line
          planning and management.  Support of Multiple Parallel Paths

   R(42)  The routing system must support the controlled distribution
          over multiple links or paths of traffic toward the same
          destination.  This applies to domains with two or more
          connections to the same neighbor domain, and to domains with
          connections to more than one neighbor domain.  The paths need
          not have the same metric.

   R(43)  The routing system must support forwarding over multiple
          parallel paths when available.  This support should extend to
          cases where the offered traffic is known to exceed the
          available capacity of a single link, and to the cases where
          load is to be shared over paths for cost or resiliency

   R(44)  Where traffic is forwarded over multiple parallel paths, the
          routing system must, so far as is possible, avoid the
          reordering of packets in individual micro-flows.

   R(45)  The routing system must have mechanisms to allow the traffic
          to be reallocated back onto a single path when multiple paths
          are not needed.  Peering Support

   R(46)  The routing system must support peer-level connectivity as
          well as hierarchical connections between domains.
Top   ToC   RFC5772 - Page 54
   The network is becoming increasingly complex, with private peering
   arrangements set up between providers at every level of the hierarchy
   of service providers and even by certain large enterprises, in the
   form of dedicated extranets.

   R(47)  The routing system must facilitate traffic engineering of peer
          routes so that traffic can be readily constrained to travel as
          the network operators desire, allowing optimal use of the
          available connectivity.

3.6.8.  Support for Middleboxes

   One of our assumptions is that NATs and other middle-boxes such as
   firewalls, web proxies, and address family translators (e.g., IPv4 to
   IPv6) are here to stay.

   R(48)  The routing system should work in conjunction with middle-
          boxes, e.g., NAT, to aid in bi-directional connectivity
          without compromising the additional opacity and privacy that
          the middle-boxes offer.

   This problem is closely analogous to the abstraction problem, which
   is already under discussion for the interchange of routing
   information between domains.

3.7.  Performance Requirements

   Over the past several years, the performance of the routing system
   has frequently been discussed.  The requirements that derive from
   those discussions are listed below.  The specific values for these
   performance requirements are left for further discussion.

   R(49)  The routing system must support domains of at least N systems.
          A system is taken to mean either an individual router or a

   R(50)  Local convergence should occur within T units of time.

   R(51)  The routing system must be measurably reliable.  The measure
          of reliability remains a research question.

   R(52)  The routing system must be locally stable to a measured
          degree.  The degree of measurability remains a research issue.

   R(53)  The routing system must be globally stable to a measured
          degree.  The degree of measurability remains a research issue.
Top   ToC   RFC5772 - Page 55
   R(54)  The routing system should scale to an indefinitely large
          number of domains.

   There has been very little data or statistical evidence for many of
   the performance claims made in the past.  In recent years, several
   efforts have been initiated to gather data and do the analyses
   required to make scientific assessments of performance issues and
   requirements.  In order to complete this section of the requirements
   analysis, the data and analyses from these studies needs to be
   gathered and collated into this document.  This work has been started
   but has yet to be completed.

      Editors' Note: This work was never completed due to corporate

3.8.  Backward Compatibility (Cutover) and Maintainability

   This area poses a dilemma.  On one hand, it is an absolute
   requirement that:

   R(55)  The introduction of the routing system must not require any
          flag days.

   R(56)  The network currently in place must continue to run at least
          as well as it does now while the new network is being
          installed around it.

   However, at the same time, it is also an requirement that:

   R(57)  The new architecture must not be limited by the restrictions
          that plague today's network.

   It has to be admitted that R(57) is not a well-defined requirement,
   because we have not fully articulated what the restrictions might be.
   Some of these restrictions can be derived by reading the discussions
   for the positive requirements above.  It would be a useful exercise
   to explicitly list all the restrictions and irritations with which we
   wish to do away.  Further, it would be useful to determine if these
   restrictions can currently be removed at a reasonable cost or whether
   we are actually condemned to live with them.

   Those restrictions cannot be allowed to become permanent baggage on
   the new architecture.  If they do, the effort to create a new system
   will come to naught.  It may, however, be necessary to live with some
   of them temporarily for practical reasons while providing an
   architecture that will eventually allow them to be removed.  The last
   three requirements have significance not only for the transition
Top   ToC   RFC5772 - Page 56
   strategy but also for the architecture itself.  They imply that it
   must be possible for an internet such as today's BGP-controlled
   network, or one of its ASs, to exist as a domain within the new FDR.

3.9.  Security Requirements

   As previously discussed, one of the major changes that has overtaken
   the Internet since its inception is the erosion of trust between end
   users making use of the net, between those users and the suppliers of
   services, and between the multiplicity of providers.  Hence,
   security, in all its aspects, will be much more important in the FDR.

   It must be possible to secure the routing communication.

   R(58)  The communicating entities must be able to identify who sent
          and who received the information (authentication).

   R(59)  The communicating entities must be able to verify that the
          information has not been changed on the way (integrity).

   Security is more important in inter-domain routing where the operator
   has no control over the other domains, than in intra-domain routing
   where all the links and the nodes are under the administration of the
   operator and can be expected to share a trust relationship.  This
   property of intra-domain trust, however, should not be taken for

   R(60)  Routing communications must be secured by default, but an
          operator must have the option to relax this requirement within
          a domain where analysis indicates that other means (such as
          physical security) provide an acceptable alternative.

   R(61)  The routing communication mechanism must be robust against
          denial-of-service attacks.

   R(62)  It should be possible to verify that the originator of the
          information was authorized to generate the information.

   Further considerations that may impose further requirements include:

   -  whether no one else but the intended recipient is able to access
      (privacy) or understand (confidentiality) the information,

   -  whether it is possible to verify that all the information has been
      received and that the two parties agree on what was sent
      (validation and non-repudiation),
Top   ToC   RFC5772 - Page 57
   -  whether there is a need to separate security of routing from
      security of forwarding, and

   -  whether traffic flow security is needed (i.e., whether there is
      value in concealing who can connect to whom, and what volumes of
      data are exchanged).

   Securing the BGP session, as done today, only secures the exchange of
   messages from the peering domain, not the content of the information.
   In other words, we can confirm that the information we got is what
   our neighbor really sent us, but we do not know whether or not this
   information (that originated in some remote domain) is true.

   A decision has to be made on whether to rely on chains of trust (we
   trust our peers who trust their peers who..), or whether we also need
   authentication and integrity of the information end-to-end.  This
   information includes both routes and addresses.  There has been
   interest in having digital signatures on originated routes as well as
   countersignatures by address authorities to confirm that the
   originator has authority to advertise the prefix.  Even understanding
   who can confirm the authority is non-trivial, as it might be the
   provider who delegated the prefix (with a whole chain of authority
   back to ICANN) or it may be an address registry.  Where a prefix
   delegated by a provider is being advertised through another provider
   as in multi-homing, both may have to be involved to confirm that the
   prefix may be advertised through the provider who doesn't have any
   interest in the prefix!

   R(63)  The routing system must cooperate with the security policies
          of middle-boxes whenever possible.

   This is likely to involve further requirements for abstraction of
   information.  For example, a firewall that is seeking to minimize
   interchange of information that could lead to a security breach.  The
   effect of such changes on the end-to-end principle should be
   carefully considered as discussed in [Blumenthal01].

   R(64)  The routing system must be capable of complying with local
          legal requirements for interception of communication.

3.10.  Debatable Issues

   This section covers issues that need to be considered and resolved in
   deciding on a Future Domain Routing architecture.  While they can't
   be described as requirements, they do affect the types of solution
   that are acceptable.  The discussions included below are very open-
Top   ToC   RFC5772 - Page 58
3.10.1.  Network Modeling

   The mathematical model that underlies today's routing system uses a
   graph representation of the network.  Hosts, routers, and other
   processing boxes are represented by nodes and communications links by
   arcs.  This is a topological model in that routing does not need to
   directly model the physical length of the links or the position of
   the nodes; the model can be transformed to provide a convenient
   picture of the network by adjusting the lengths of the arcs and the
   layout of the nodes.  The connectivity is preserved and routing is
   unaffected by this transformation.

   The routing algorithms in traditional routing protocols utilize a
   small number of results from graph theory.  It is only recently that
   additional results have been employed to support constraint-based
   routing for traffic engineering.

   The naturalness of this network model and the "fit" of the graph
   theoretical methods may have tended to blind us to alternative
   representations and inhibited us from seeking alternative strands of
   theoretical thinking that might provide improved results.

   We should not allow this habitual behavior to stop us from looking
   for alternative representations and algorithms; topological
   revolutions are possible and allowed, at least in theory.

3.10.2.  System Modeling

   The assumption that object modeling of a system is an essential first
   step to creating a new system is still novel in this context.
   Frequently, the object modeling effort becomes an end in itself and
   does not lead to system creation.  But there is a balance, and a lot
   that can be discovered in an ongoing effort to model a system such as
   the Future Domain Routing system.  It is recommended that this
   process be included in the requirements.  It should not, however, be
   a gating event to all other work.

   Some of the most important realizations will occur during the process
   of determining the following:

   -  Object classification

   -  Relationships and containment

   -  Roles and Rules
Top   ToC   RFC5772 - Page 59
3.10.3.  One, Two, or Many Protocols

   There has been a lot of discussion of whether the FDR protocol
   solution should consist of one (probably new) protocol, two (intra-
   and inter-domain) protocols, or many protocols.  While it might be
   best to have one protocol that handles all situations, this seems
   improbable.  On the other hand, maintaining the "strict" division
   evident in the network today between the IGP and EGP may be too
   restrictive an approach.  Given this, and the fact that there are
   already many routing protocols in use, the only possible answer seems
   to be that the architecture should support many protocols.  It
   remains an open issue, one for the solution, to determine if a new
   protocol needs to be designed in order to support the highest goals
   of this architecture.  The expectation is that a new protocol will be

3.10.4.  Class of Protocol

   If a new protocol is required to support the FDR architecture, the
   question remains open as to what kind of protocol this ought to be.
   It is our expectation that a map distribution protocol will be
   required to augment the current path-vector protocol and shortest
   path first protocols.

3.10.5.  Map Abstraction

   Assuming that a map distribution protocol, as defined in [RFC1992] is
   required, what are the requirements on this protocol?  If every
   detail is advertised throughout the Internet, there will be a lot of
   information.  Scalable solutions require abstraction.

   -  If we summarize too much, some information will be lost on the

   -  If we summarize too little, then more information than required is
      available, contributing to scaling limitations.

   -  One can allow more summarization, if there also is a mechanism to
      query for more details within policy limits.

   -  The basic requirement is not that the information shall be
      advertised, but rather that the information shall be available to
      those who need it.  We should not presuppose a solution where
      advertising is the only possible mechanism.
Top   ToC   RFC5772 - Page 60
3.10.6.  Clear Identification for All Entities

   As in all other fields, the words used to refer to concepts and to
   describe operations about routing are important.  Rather than
   describe concepts using terms that are inaccurate or rarely used in
   the real world of networking, it is necessary to make an effort to
   use the correct words.  Many networking terms are used casually, and
   the result is a partial or incorrect understanding of the underlying
   concept.  Entities such as nodes, interfaces, subnetworks, tunnels,
   and the grouping concepts such as ASs, domains, areas, and regions,
   need to be clearly identified and defined to avoid confusion.

   There is also a need to separate identifiers (what or who) from
   locators (where) from routes (how to reach).

      Editors' Note: Work was undertaken in the shim6 working group of
      the IETF on this sort of separation.  This work needs to be taken
      into account in any new routing architecture.

3.10.7.  Robustness and Redundancy

   The routing association between two domains should survive even if
   some individual connection between two routers goes down.

   The "session" should operate between logical "routing entities" on
   each domain side, and not necessarily be bound to individual routers
   or addresses.  Such a logical entity can be physically distributed
   over multiple network elements.  Or, it can reside in a single
   router, which would default to the current situation.

3.10.8.  Hierarchy

   A more flexible hierarchy with more levels and recursive groupings in
   both upward and downward directions allows more structured routing.
   The consequence is that no single level will get too big for routers
   to handle.

   On the other hand, it appears that the real-world Internet is
   becoming less hierarchical, so that it will be increasingly difficult
   to use hierarchy to control scaling.

   Note that groupings can look different depending on which aspect we
   use to define them.  A Diffserv area, an MPLS domain, a trusted
   domain, a QoS area, a multicast domain, etc., do not always coincide;
   nor are they strict hierarchical subsets of each other.  The basic
   distinction at each level is "this grouping versus everything
Top   ToC   RFC5772 - Page 61
3.10.9.  Control Theory

   Is it possible to apply a control theory framework to analyze the
   stability of the control system of the whole network domain, with
   regard to, e.g., convergence speed and the frequency response, and
   then use the results from that analysis to set the timers and other
   protocol parameters?

   Control theory could also play a part in QoS routing, by modifying
   current link-state protocols with link costs dependent on load and
   feedback.  Control theory is often used to increase the stability of
   dynamic systems.

   It might be possible to construct a new, totally dynamic routing
   protocol solely on a control theoretic basis, as opposed to the
   current protocols that are based in graph theory and static in

3.10.10.  Byzantium

   Is solving the Byzantine Generals problem a requirement?  This is the
   problem of reaching a consensus among distributed units if some of
   them give misleading answers.  The current intra-domain routing
   system is, at one level, totally intolerant of misleading
   information.  However, the effect of different sorts of misleading or
   incorrect information has vastly varying results, from total collapse
   to purely local disconnection of a single domain.  This sort of
   behavior is not very desirable.

   There are, possibly, other network robustness issues that must be
   researched and resolved.

3.10.11.  VPN Support

   Today, BGP is also used for VPNs, for example, as described in RFC
   4364 [RFC4364].

   Internet routing and VPN routing have different purposes and most
   often exchange different information between different devices.  Most
   Internet routers do not need to know VPN-specific information.  The
   concepts should be clearly separated.

   But when it comes to the mechanisms, VPN routing can share the same
   protocol as ordinary Internet routing; it can use a separate instance
   of the same protocol or it can use a different protocol.  All
   variants are possible and have their own merits.  These requirements
   are silent on this issue.
Top   ToC   RFC5772 - Page 62
3.10.12.  End-to-End Reliability

   The existing Internet architecture neither requires nor provides end-
   to-end reliability of control information dissemination.  There is,
   however, already a requirement for end-to-end reliability of control
   information distribution, i.e., the ends of the VPN established need
   to have an acknowledgment of the success in setting up the VPN.
   While it is not necessarily the function of a routing architecture to
   provide end-to-end reliability for this kind of purpose, we must be
   clear that end-to-end reliability becomes a requirement if the
   network has to support such reliable control signaling.  There may be
   other requirements that derive from requiring the FDR to support
   reliable control signaling.

3.10.13.  End-to-End Transparency

   The introduction of private addressing schemes, Network Address
   Translators, and firewalls has significantly reduced the end-to-end
   transparency of the network.  In many cases, the network is also no
   longer symmetric, so that communication between two addresses is
   possible if the communication session originates from one end but not
   from the other.  This impedes the deployment of new peer-to-peer
   services and some "push" services where the server in a client-
   server arrangement originates the communication session.  Whether a
   new routing system either can or should seek to restore this
   transparency is an open issue.

   A related issue is the extent to which end-user applications should
   seek to control the routing of communications to the rest of the

4.  Security Considerations

   We address security issues in the individual requirements.  We do
   require that the architecture and protocols developed against this
   set of requirements be "secure".  Discussion of specific security
   issues can be found in the following sections:

   o  Group A: Routing System Security - Section 2.1.9

   o  Group A: End Host Security - Section 2.1.10

   o  Group A: Routing Information Policies - Section

   o  Group A: Abstraction - Section 2.1.16

   o  Group A: Robustness - Section 2.1.18
Top   ToC   RFC5772 - Page 63
   o  Group B: Protection against Denial-of-Service and Other Security
      Attacks - Section

   o  Group B: Commercial Service Providers - Section

   o  Group B: The Federated Environment - Section 3.4.1

   o  Group B: Path Advertisement - Section

   o  Group B: Security Requirements - Section 3.9

5.  IANA Considerations

   This document is a set of requirements from which a new routing and
   addressing architecture may be developed.  From that architecture, a
   new protocol, or set of protocols, may be developed.

   While this note poses no new tasks for IANA, the architecture and
   protocols developed from this document probably will have issues to
   be dealt with by IANA.

6.  Acknowledgments

   This document is the combined effort of two groups in the IRTF.
   Group A, which was formed by the IRTF Routing Research chairs, and
   Group B, which was self-formed and later was folded into the IRTF
   Routing Research Group.  Each group has it own set of

   Group A Acknowledgments

      This originated in the IRTF Routing Research Group's sub-group on
      Inter-domain routing requirements.  The members of the group were:

           Abha Ahuja                      Danny McPherson
           J. Noel Chiappa                 David Meyer
           Sean Doran                      Mike O'Dell
           JJ Garcia-Luna-Aceves           Andrew Partan
           Susan Hares                     Radia Perlman
           Geoff Huston                    Yakov Rehkter
           Frank Kastenholz                John Scudder
           Dave Katz                       Curtis Villamizar
           Tony Li                         Dave Ward

      We also appreciate the comments and review received from Ran
      Atkinson, Howard Berkowitz, Randy Bush, Avri Doria, Jeffery Haas,
      Dmitri Krioukov, Russ White, and Alex Zinin.  Special thanks to
      Yakov Rehkter for contributing text and to Noel Chiappa.
Top   ToC   RFC5772 - Page 64
   Group B Acknowledgments

      The document is derived from work originally produced by Babylon.
      Babylon was a loose association of individuals from academia,
      service providers, and vendors whose goal was to discuss issues in
      Internet routing with the intention of finding solutions for those

      The individual members who contributed materially to this document
      are: Anders Bergsten, Howard Berkowitz, Malin Carlzon, Lenka Carr
      Motyckova, Elwyn Davies, Avri Doria, Pierre Fransson, Yong Jiang,
      Dmitri Krioukov, Tove Madsen, Olle Pers, and Olov Schelen.

      Thanks also go to the members of Babylon and others who did
      substantial reviews of this material.  Specifically, we would like
      to acknowledge the helpful comments and suggestions of the
      following individuals: Loa Andersson, Tomas Ahlstrom, Erik Aman,
      Thomas Eriksson, Niklas Borg, Nigel Bragg, Thomas Chmara, Krister
      Edlund, Owe Grafford, Torbjorn Lundberg, Jeremy Mineweaser,
      Jasminko Mulahusic, Florian-Daniel Otel, Bernhard Stockman, Tom
      Worster, and Roberto Zamparo.

      In addition, the authors are indebted to the folks who wrote all
      the references we have consulted in putting this paper together.
      This includes not only the references explicitly listed below, but
      also those who contributed to the mailing lists we have been
      participating in for years.

      The editors thank Lixia Zhang, as IRSG document shepherd, for her
      help and her perseverance, without which this document would never
      have been published.

      Finally, it is the editors who are responsible for any lack of
      clarity, any errors, glaring omissions or misunderstandings.
Top   ToC   RFC5772 - Page 65
7.  Informative References

              Blumenthal, M. and D. Clark, "Rethinking the design of the
              Internet: The end to end arguments vs. the brave new
              world", May 2001,

              Broido, A., Nemeth, E., Claffy, K., and C. Elves,
              "Internet Expansion, Refinement and Churn", February 2002.

   [CIDR]     Telcordia Technologies, "CIDR Report",

              Chiappa, N., "A New IP Routing and Addressing
              Architecture", July 1991,

   [Clark91]  Clark, D., "Quote reportedly from IETF Plenary
              discussion", 1991.

              Seddigh, N., Nandy, B., and J. Heinanen, "An Assured Rate
              Per-Domain Behaviour for Differentiated Services", Work
              in Progress, July 2001.

              Jacobson, V., Nichols, K., and K. Poduri, "The 'Virtual
              Wire' Per-Domain Behavior", Work in Progress, July 2000.

              Griffin, T. and G. Wilfong, "An Analysis of BGP
              Convergence Properties", SIGCOMM 1999.

              ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing
              Information among Intermediate Systems to Support
              Forwarding of ISO 8473 PDUs", International Standard
              10747 ISO/IEC JTC 1, Switzerland, 1993.

              Papadimitriou, D., Poppe, F., J. Jones, J., S.
              Venkatachalam, S., S. Dharanikota, S., Jain, R., Hartani,
              R., and D. Griffith, "Inference of Shared Risk Link
              Groups", Work in Progress, November 2001.
Top   ToC   RFC5772 - Page 66
   [ODell01]  O'Dell, M., "Private Communication", 2001.

   [RFC1126]  Little, M., "Goals and functional requirements for inter-
              autonomous system routing", RFC 1126, October 1989.

   [RFC1726]  Partridge, C. and F. Kastenholz, "Technical Criteria for
              Choosing IP The Next Generation (IPng)", RFC 1726,
              Dec 1994.

   [RFC1992]  Castineyra, I., Chiappa, N., and M. Steenstrup, "The
              Nimrod Routing Architecture", RFC 1992, August 1996.

   [RFC2071]  Ferguson, P. and H. Berkowitz, "Network Renumbering
              Overview: Why would I want it and what is it anyway?",
              RFC 2071, January 1997.

   [RFC2072]  Berkowitz, H., "Router Renumbering Guide", RFC 2072,
              January 1997.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3221]  Huston, G., "Commentary on Inter-Domain Routing in the
              Internet", RFC 3221, December 2001.

   [RFC3260]  Grossman, D., "New Terminology and Clarifications for
              Diffserv", RFC 3260, April 2002.

   [RFC3344]  Perkins, C., "IP Mobility Support.", RFC 3344,
              August 2002.

   [RFC3345]  McPherson, D., Gill, V., Walton, D., and A. Retana,
              "Border Gateway Protocol (BGP) Persistent Route
              Oscillation Condition", RFC 3345, August 2002.

   [RFC3471]  Berger, L., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Functional Description", RFC 3471,
              January 2003.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC5773]  Davies, E. and A. Doria, "Analysis of Inter-Domain Routing
              Requirements and History", RFC 5773, February 2010.
Top   ToC   RFC5772 - Page 67
              Wroclowski, J., "The Metanet White Paper - Workshop on
              Research Directions for the Next Generation Internet",

              Internet Engineering Task Force, "IETF Network
              Configuration working group", 2005,

              Internet Engineering Task Force, "IETF Policy working
              group", 2002, <

              Internet Engineering Task Force, "IETF Resource Allocation
              Protocol working group", 2002,

              Internet Engineering Task Force, "IETF Configuration
              management with SNMP working group", 2002, <http://
Top   ToC   RFC5772 - Page 68
Authors' Addresses

   Avri Doria
   Lulea  971 87

   Phone: +46 73 277 1788

   Elwyn B. Davies
   Folly Consulting
   Soham, Cambs

   Phone: +44 7889 488 335

   Frank Kastenholz
   BBN Technologies
   10 Moulton St.
   Cambridge, MA  02183

   Phone: +1 617 873 8047