Network Working Group A. Doria
Internet-Draft ETRI
Expires: May 31, 2004 E. Davies
Nortel Networks
F. Kastenholz
Juniper Networks
December 1, 2003
Requirements for Inter Domain Routing
draft-irtf-routing-reqs-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 31, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
These requirements for routing architectures are the product of two
sub-groups with the IRTF Routing Research Group. They represent two
individual and separate views of the problem and of what is required
to fix the problem. While speaking of requirements, the document is
actually a recommendation to anyone who would create a routing
architecture for the Internet in the coming years.
Doria, et al. Expires May 31, 2004 [Page 1]
Internet-Draft IRTF IDR Requirements December 2003
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Results from Group A . . . . . . . . . . . . . . . . . . . 6
2.1 Group A - Requirements For a Next Generation Routing
and Addressing Architecture . . . . . . . . . . . . . . . 6
2.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Separable Components . . . . . . . . . . . . . . . . . . . 6
2.1.3 Scalable . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4 Lots of Interconnectivity . . . . . . . . . . . . . . . . 9
2.1.5 Random Structure . . . . . . . . . . . . . . . . . . . . . 10
2.1.6 Multi-homing . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 19
2.1.15 Multi-Protocol . . . . . . . . . . . . . . . . . . . . . . 19
2.1.16 Abstraction . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.17 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.18 Robustness . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.19 Media Independence . . . . . . . . . . . . . . . . . . . . 21
2.1.20 Stand-alone . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.21 Safety of Configuration . . . . . . . . . . . . . . . . . 22
2.1.22 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.23 Multi-prefix . . . . . . . . . . . . . . . . . . . . . . . 22
2.1.24 Cooperative Anarchy . . . . . . . . . . . . . . . . . . . 22
2.1.25 Network Layer Protocols and Forwarding Model . . . . . . . 23
2.1.26 Routing Algorithm . . . . . . . . . . . . . . . . . . . . 23
2.1.27 Positive Benefit . . . . . . . . . . . . . . . . . . . . . 23
2.1.28 Administrative Entities and the IGP/EGP Split . . . . . . 23
2.2 Non-Requirements . . . . . . . . . . . . . . . . . . . . . 24
2.2.1 Forwarding Table Optimization . . . . . . . . . . . . . . 24
2.2.2 Traffic Engineering . . . . . . . . . . . . . . . . . . . 24
2.2.3 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.4 QOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.5 IP Prefix Aggregation . . . . . . . . . . . . . . . . . . 25
2.2.6 Perfect Safety . . . . . . . . . . . . . . . . . . . . . . 25
2.2.7 Dynamic Load Balancing . . . . . . . . . . . . . . . . . . 26
2.2.8 Renumbering of hosts and routers . . . . . . . . . . . . . 26
2.2.9 Host Mobility . . . . . . . . . . . . . . . . . . . . . . 26
2.2.10 Clean Slate . . . . . . . . . . . . . . . . . . . . . . . 26
3. Requirements from Group B . . . . . . . . . . . . . . . . 27
3.1 Group B - Future Domain Routing Requirements . . . . . . . 27
3.2 Underlying principles . . . . . . . . . . . . . . . . . . 27
Doria, et al. Expires May 31, 2004 [Page 2]
Internet-Draft IRTF IDR Requirements December 2003
3.2.1 Inter-domain and intra-domain . . . . . . . . . . . . . . 28
3.2.2 Influences on a changing network . . . . . . . . . . . . . 28
3.2.3 High level goals . . . . . . . . . . . . . . . . . . . . . 30
3.3 High level user requirements . . . . . . . . . . . . . . . 33
3.3.1 Organisational users . . . . . . . . . . . . . . . . . . . 33
3.3.2 Individual users . . . . . . . . . . . . . . . . . . . . . 36
3.4 Mandated constraints . . . . . . . . . . . . . . . . . . . 37
3.4.1 The federated environment . . . . . . . . . . . . . . . . 37
3.4.2 Working with different sorts of networks . . . . . . . . . 38
3.4.3 Delivering Diversity . . . . . . . . . . . . . . . . . . . 38
3.4.4 When will the new solution be required? . . . . . . . . . 39
3.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Functional requirements . . . . . . . . . . . . . . . . . 41
3.6.1 Topology . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.6.2 Distribution . . . . . . . . . . . . . . . . . . . . . . . 42
3.6.3 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 46
3.6.4 Statistics support . . . . . . . . . . . . . . . . . . . . 48
3.6.5 Management requirements . . . . . . . . . . . . . . . . . 48
3.6.6 Provability . . . . . . . . . . . . . . . . . . . . . . . 49
3.6.7 Traffic engineering . . . . . . . . . . . . . . . . . . . 50
3.6.8 Support for middleboxes . . . . . . . . . . . . . . . . . 52
3.7 Performance requirements . . . . . . . . . . . . . . . . . 52
3.8 Backwards compatibility (cutover) and maintainability . . 53
3.9 Security requirements . . . . . . . . . . . . . . . . . . 54
3.10 Debatable issues . . . . . . . . . . . . . . . . . . . . . 55
3.10.1 Network modeling . . . . . . . . . . . . . . . . . . . . . 55
3.10.2 System modeling . . . . . . . . . . . . . . . . . . . . . 56
3.10.3 One, two or many protocols . . . . . . . . . . . . . . . . 56
3.10.4 Class of protocol to use . . . . . . . . . . . . . . . . . 57
3.10.5 Map abstraction . . . . . . . . . . . . . . . . . . . . . 57
3.10.6 Clear identification for all entities . . . . . . . . . . 57
3.10.7 Robustness and redundancy: . . . . . . . . . . . . . . . . 58
3.10.8 Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 58
3.10.9 Will new control mechanisms be needed? . . . . . . . . . . 58
3.10.10 Byzantium . . . . . . . . . . . . . . . . . . . . . . . . 59
3.10.11 VPN support . . . . . . . . . . . . . . . . . . . . . . . 59
3.10.12 End to end reliability . . . . . . . . . . . . . . . . . . 59
3.10.13 End to end transparency . . . . . . . . . . . . . . . . . 60
4. Security Considerations . . . . . . . . . . . . . . . . . 61
5. IANA Considerations . . . . . . . . . . . . . . . . . . . 62
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 63
Informative References . . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 68
Intellectual Property and Copyright Statements . . . . . . 69
Doria, et al. Expires May 31, 2004 [Page 3]
Internet-Draft IRTF IDR Requirements December 2003
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. A group of well known routing
experts was assembled and given the task of developing requirements
for a new routing architecture. Their mandate was to approach the
problem from the blank sheet perspective. 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.
Around the same time, an independent effort was started in Sweden
with a similar goal. In this case a team, calling itself Babylon,
representing vendors, service providers and academia assembled to
understand the history of inter domain routing, to do research on the
problems seen by the service providers and to develop, from that
study, a proposal of requirements for a follow-on to the current
routing architecture. This group's approach required starting not
from a blank page but from current routing architecture and practice.
In other words the group limited itself to developing an evolutionary
strategy. Later, the Babylon group was folded into the IRTF RRG and
was established as Sub-Group B within the RRG.
One of the questions that arose while the groups were working in
isolation was whether there would be many similarities between the
set 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, and
some areas of disagreement.
There were suggestions within the RRG that the two teams should work
together to bring the requirements sets together into one set of
requirements. Since these requirements are only guidelines to future
work, however, it was felt by some that doing so would lose 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
take these requirements as written and go create an architecture that
met these requirements. Rather, the requirements, were really strong
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 both of the requirements sets produced by the
teams. They have only been modified slightly, all editorial, from the
final versions submitted as individual internet drafts. The
requirements have been left unaltered.
Doria, et al. Expires May 31, 2004 [Page 4]
Internet-Draft IRTF IDR Requirements December 2003
In reading this document it is important to keep in mind that all of
these requirements are in fact just suggestions. As an informational
document, these suggestions are laid out to assist those interested
in working on 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 is no guarantee. So,
one last, or rather first, suggestion to anyone reading this
document, do not treat what it says as absolute, and do not 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.
Finally this document does not make any claims with respect to
whether it is possible to have a practical solution that meets all
the requirements listed in this document.
Doria, et al. Expires May 31, 2004 [Page 5]
Internet-Draft IRTF IDR Requirements December 2003
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
order.
2.1.1 Architecture
The new routing and addressing protocols, data structures, and
algorithms MUST be developed from a clear, well thought out,
documented, architecture.
The new routing and addressing system must have an architectural
specification which 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.
Doria, et al. Expires May 31, 2004 [Page 6]
Internet-Draft IRTF IDR Requirements December 2003
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.
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.
o Making policy definition and application a separate subsystem,
layered overtop of 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 overtop
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
Doria, et al. Expires May 31, 2004 [Page 7]
Internet-Draft IRTF IDR Requirements December 2003
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
1. Tens of thousands of AS's and
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 to a specific
network size would be inappropriate. First, the cost of routing
calculations is based only in part on the number of AS's or prefixes
in the network. The number and locations of the links in the network
is also a significant factor. 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.
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 be less
than the growth in hardware capabilities described by Moore's
Law, which has hardware capabilities doubling every 18 months or
so. 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 40gbits (OC768). We should not expect raw network
link speed to grow much beyond OC768. In addition, for economic
reasons, large swathes of the core of the Internet will still
Doria, et al. Expires May 31, 2004 [Page 8]
Internet-Draft IRTF IDR Requirements December 2003
operate at lower speeds, possibly as slow as DS3.
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 (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 (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.
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.
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 up to more
"other things". Company's multi-home to multiple ISPs, ISPs peer
with more ISPs, and so on. These connections are made for many
Doria, et al. Expires May 31, 2004 [Page 9]
Internet-Draft IRTF IDR Requirements December 2003
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
"meshier". 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. When there are
multiple valid, loop free, paths available, all such paths MUST be
available for forwarding traffic.
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 make any constraints
on or 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.
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, multihoming 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 "multihoming" 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
Doria, et al. Expires May 31, 2004 [Page 10]
Internet-Draft IRTF IDR Requirements December 2003
multi-homed site.
When multi-homing, 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 multihoming leads to undue
increases in the size of the BGP routing tables. The new
architecture MUST support multi-homing without causing 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 use in specifying the rules for
classifying the traffic and assigning classes of traffic to different
paths (or prohibiting it from certain paths). The rules for
classification should allow traffic to be classified based on
o IPv6 FlowIDs
o DSCP values
o Source and/or Destination prefixes
o Random selections at some probability
o ...
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).
Past experience with dynamic load-balancing and management over
multiple paths has been bad. Typically, traffic would oscillate,
Doria, et al. Expires May 31, 2004 [Page 11]
Internet-Draft IRTF IDR Requirements December 2003
first all traffic would go over one path, then it would all be
'migrated' to a different path, and then back again. Significant
research is needed in this area.
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 come up with 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
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
Doria, et al. Expires May 31, 2004 [Page 12]
Internet-Draft IRTF IDR Requirements December 2003
deletion, router failure or restart, etc.) is introduced into a
stabilized system. No additional changes are introduced. The
system must restabilize 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.
- 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, thought perhaps not by the optimal path -- this allows some
'hunting' for the optimal solution)
X, Y, 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
Doria, et al. Expires May 31, 2004 [Page 13]
Internet-Draft IRTF IDR Requirements December 2003
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:
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.
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 DDOS attacks.
No Bad Data
Any new architecture and protocols must provide protection
against the introduction of bad, bogus, or misleading, data by
Doria, et al. Expires May 31, 2004 [Page 14]
Internet-Draft IRTF IDR Requirements December 2003
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
which 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, yet maintaining the desired levels of service
connectivity and reachability.
Privacy
By "privacy" we mean privacy of the routing protocol exchanges
between routers. In the past this has not been considered
important for routing protocols.
When the routers are on point-to-point links, with routers at
each end, there is no need to encrypt the routing protocol
traffic; there is no possibility of a third party intercepting
the traffic, and if one of the two routers are compromised then
it doesn't matter. This is not sufficient. We believe 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, administrative
domains). 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.
Doria, et al. Expires May 31, 2004 [Page 15]
Internet-Draft IRTF IDR Requirements December 2003
Data Consistency
A router should be able to detect and recover from any data that
is received from other routers which 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 clear text
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 many things to many people. For our
purposes, we define policy as
Policy is the set of administrative influences that alter the path
determination and next-hop selection procedures of the routing
software.
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
Doria, et al. Expires May 31, 2004 [Page 16]
Internet-Draft IRTF IDR Requirements December 2003
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 others 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".
- 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 "provisional" in the sense of
"accept routes that traverse "foo" only if there are no others
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.
Doria, et al. Expires May 31, 2004 [Page 17]
Internet-Draft IRTF IDR Requirements December 2003
- 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 re-directing 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, DSCP values, and MPLS
labels) .
- The ability to 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).
Traffic classification must at least include the source and
destination IP addresses (prefixes) and the DSCP value. Other fields
may be supported, such as
o Protocol and port based functions,
o DSCP/QOS tuple (such as ports)
o Per-host operations (i.e. /32s for IPv4 and /128s for IPv6),
o Traffic matrices (e.g., traffic from prefix X and to prefix Y).
Doria, et al. Expires May 31, 2004 [Page 18]
Internet-Draft IRTF IDR Requirements December 2003
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.
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 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
Doria, et al. Expires May 31, 2004 [Page 19]
Internet-Draft IRTF IDR Requirements December 2003
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 to 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,
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 Radia Perlman can
explain all the important concepts in less than an hour.
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".
Doria, et al. Expires May 31, 2004 [Page 20]
Internet-Draft IRTF IDR Requirements December 2003
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 Defective (even malicious) trusted routers.
o 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.
Doria, et al. Expires May 31, 2004 [Page 21]
Internet-Draft IRTF IDR Requirements December 2003
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.
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 (no dialup 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 RFC1726[44] said:
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
Doria, et al. Expires May 31, 2004 [Page 22]
Internet-Draft IRTF IDR Requirements December 2003
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 with
regard to using link-state, distance-vector, or path-vector routing
algorithms.
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
Doria, et al. Expires May 31, 2004 [Page 23]
Internet-Draft IRTF IDR Requirements December 2003
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.
2.2 Non-Requirements
The following are not required or are non-goals. This should not be
taken to mean that these issues must not be addressed by a new
architecture. Rather, addressing these issues or not is purely a
matter for the architects.
2.2.1 Forwarding Table Optimization
We believe that it is not necessary for the architecture to minimize
the size of the forwarding tables (FIBS). Current memory sizes,
speeds, and prices, along with processor and ASIC capabilities allow
forwarding tables to be very large, O(E6), and fast (100M lookups/
second) tables to be built with little difficulty.
2.2.2 Traffic Engineering
Traffic Engineering is one of those terms that has become terribly
overloaded. If you ask N people what traffic engineering is, you get
something like N! disjoint answers. Therefore, we elect not to
require "traffic engineering", per se. Instead, we have endeavored
to determine what the ultimate intent is when operators "traffic
engineer" their networks and then make those capabilities an inherent
part of the system.
2.2.3 Multicast
The new architecture is not designed explicitly to be an inter-domain
multicast routing architecture. However, given the notable lack of a
viable, robust, and widely deployed inter- domain multicast routing
architecture, the architecture should not hinder the development and
deployment of inter-domain multicast routing without adverse effect
Doria, et al. Expires May 31, 2004 [Page 24]
Internet-Draft IRTF IDR Requirements December 2003
on meeting the other requirements.
We do note however that one respected network sage has said (roughly)
When you see a bunch of engineers standing around congratulating
themselves for solving some particularly ugly problem in
networking, go up to them, whisper "multicast", jump back, and
watch the fun begin...
2.2.4 QOS
The Architecture concerns itself primarily with disseminating network
topology information so that routers may select paths to destinations
and build appropriate forwarding tables. QOS is not a part of this
function and we make no requirements with respect to QOS.
However, QOS is an area of great and evolving interest. It is
reasonable to expect that in the not too distant future,
sophisticated QOS facilities will be deployed in the Internet. Any
new architecture and protocols should be developed with an eye toward
these future evolutions. Extensibility mechanisms, allowing future
QOS routing and signaling protocols to "piggy- back" on top of the
basic routing system are desired.
We do require the ability to assign attributes to entities and then
do path generation and selection based on those attributes. Some may
call this QOS.
2.2.5 IP Prefix Aggregation
There is no specific requirement that CIDR-style IP Prefix
aggregation be done by the new architecture. Address allocation
policies, societal pressure, and the random growth and structure of
the Internet have all conspired to make prefix aggregation
extraordinarily difficult, if not impossible. This means that large
numbers of prefixes will be sloshing about in the routing system and
that forwarding tables will grow quite big. This is a cost that we
believe must be borne.
Nothing in this non-requirement should be interpreted as saying that
prefix aggregation is explicitly prohibited. CIDR-style IP Prefix
aggregation might be used as a mechanism to meet other requirements,
such as scaling.
2.2.6 Perfect Safety
Making the system impossible to misconfigure is, we believe, not
Doria, et al. Expires May 31, 2004 [Page 25]
Internet-Draft IRTF IDR Requirements December 2003
required. The checking, constraints, and controls necessary to
achieve this could, we believe, prevent operators from performing
necessary tasks in the face of unforeseen circumstances.
However, safety is always a "good thing", and any results from
research in this area should certainly be taken into consideration
and, where practical, incorporated into the new routing architecture.
2.2.7 Dynamic Load Balancing
Past history has shown that using the routing system to perform
highly dynamic load balancing among multiple more-or-less-equal paths
usually ends up causing all kinds of instability, etc, in the
network. Thus, we do not require such a capability.
However, this is an area that is ripe for additional research, and
some believe that the capability will be necessary in the future.
Thus, the architecture and protocols should be "malleable" enough to
allow development and deployment of dynamic load balancing
capabilities, should we ever figure out how to do it.
2.2.8 Renumbering of hosts and routers
We believe that the routing system is not required to "do
renumbering" of hosts and routers. That's an IP issue.
Of course, the routing and addressing architecture must be able to
deal with renumbering when it happens.
2.2.9 Host Mobility
In the Internet Architecture, host-mobility is handled on a per-host
basis by a dedicated, Mobile-IP protocol [45]. Traffic destined for
a mobile-host is explicitly forwarded by dedicated relay agents.
Mobile-IP [45] adequately solves the host- mobility problem and we do
not see a need for any additional requirements in this area. Of
course, the new architecture MUST NOT impede or conflict with
Mobile-IP.
2.2.10 Clean Slate
For the purposes of development of the architecture, we assume that
there is a 'clean slate'. Unless specified in Section 2.1, we have
no explicit requirements that elements, concepts or mechanisms of the
current routing architecture are carried forward into the new one.
Doria, et al. Expires May 31, 2004 [Page 26]
Internet-Draft IRTF IDR Requirements December 2003
3. Requirements from Group B
The following is the result of the work done by Sub-Group B of the
IRTF-RRG in 2001-2002. It was originally released under the title:
"Future Domain Routing Requirements" and was edited by Avri Doria and
Elwyn Davies.
3.1 Group B - Future Domain Routing Requirements
It is generally accepted that there are major shortcomings in the
inter-domain routing of the Internet today and that these may result
in meltdown within an unspecified period of time. Remedying these
shortcomings will require extensive research to tie down the exact
failure modes that lead to these shortcomings and identify the best
techniques to remedy the situation.
Various developments in the nature and quality of the services that
users want from the Internet are difficult to provide within the
current framework as they impose requirements never foreseen by the
original architects of the Internet routing system.
The advent of IPv6 and the application of IP mechanisms to private
commercial networks offering specific service guarantees as an
improvement over the best efforts services of the Public Internet
epitomize the kind of radical changes which have to be accommodated:
Major changes to the inter-domain routing system are inevitable if it
is to provide an efficient underpinning for the radically changed and
increasingly, commercially-based networks which rely on the IP
protocol suite.
3.2 Underlying principles
Although inter-domain routing is seen as the major source of
problems, the interactions with intra-domain routing and the
constraints that confining changes to the inter-domain arena would
impose, means that we should consider the whole area of routing as an
integrated system. This is done for 2 reasons:
- Requirements should not presuppose the solution. A continued
commitment to the current definitions and split between inter-
domain and intra-domain routing would constitute such a
presupposition. Therefore the name Future Domain Routing(FDR) is
being used in this document,
- As an acknowledgment of how intertwined inter-domain and intra-
domain routing are within today's routing architecture.
Doria, et al. Expires May 31, 2004 [Page 27]
Internet-Draft IRTF IDR Requirements December 2003
We are aware that using the term Domain Routing is already fraught
with danger because of possible misinterpretation due to prior usage.
The meaning of Domain Routing will be developed implicitly throughout
the document, but a little advance explicit definition of the word
'domain' is required, as well as some expansion on the scope of
'routing'.
This document uses domain in a very broad sense to mean any
collection of systems or domains that come under a common authority
that determines the attributes defining, and the policies
controlling, that collection. The use of domain in this context is
very similar to the concept of Region that was put forth by John
Wroclawski in his Metanet model [10]. The idea includes the notion
that within a domain certain system attributes will characterize the
behavior of the systems in the domain and that there will be borders
between domains. The idea of domain presented does not inherently
presuppose that the identifying behaviors between two domains are to
be the same. Nor does it presuppose anything about the hierarchical
nature of domains. Finally it does not place restrictions on the
nature of the attributes that might be used to determine membership
in a domain. Since today's routing domains are a subset of all
domains as conceived of in this document, there has been no attempt
to create a new term.
Current practice stresses the need to separate the concerns of the
control plane in a router and the forwarding plane: This document
will follow this practice, but we still use the term 'routing' as a
global portmanteau to cover all aspects of the system. Specifically
however routing will be used to mean the process of discovering,
interpreting and distributing information about the logical and
topological structure of the network.
3.2.1 Inter-domain and intra-domain
Throughout this document the terms intra-domain and inter-domain will
be used. These terms SHOULD NOT be understood to imply that there is
one intra-domain and one inter-domain. Rather these SHOULD be
understood as relative terms. In all case of domains there will be a
set of network systems that are within that domain and routing
between these systems will be termed intra-domain. In some cases
there will be routing between domains, which will be termed inter-
domain. It is possible that the same routing activities can be
viewed as intra-domain from one perspective and inter-domain from
another perspective.
3.2.2 Influences on a changing network
The development of the Internet is likely to be driven by a number of
Doria, et al. Expires May 31, 2004 [Page 28]
Internet-Draft IRTF IDR Requirements December 2003
changes that will affect the organization and the usage of the
network, including:
- Ongoing evolution of the commercial relationships between
(connectivity) service providers, leading to changes in the way in
which peering between providers is organized and the way in which
transit traffic is routed
- Requirements for traffic engineering within and between domains
including coping with multiple paths between domains
- Potential addition of a second IP addressing technique through
IPv6.
- The use of VPNs and private address space with IPv4, and possibly
IPv6
- Evolution of the end-to-end principle to deal with the expanded
role of the Internet as discussed in [32]. This paper discusses
the possibility that the range of new requirements, especially the
social and techno-political ones, which are being placed on the
future Internet, may compromise the Internet's original design
principles. This might cause the Internet to lose some of its key
features, in particular its ability to support new and
unanticipated applications. The discussion is linked to the rise
of new stakeholders in the Internet, especially ISPs; new
government interests; the changing motivations of the ever growing
user base; and the tension between the demand for trustworthy
overall operation and the inability to trust the behaviour of
individual users.
- Incorporation of alternative forwarding techniques such as the
explicit routing (pipes) supplied by the MPLS [24] and GMPLS
environments [25].
- Integrating additional constraints into route determination from
interactions with other layers (e.g. Shared Risk Link Groups [31])
- Support for alternative and multiple routing techniques that are
better suited to delivering types of content organised other than
into IP addressed packets.
Philosophically, the Internet has the mission of transferring
information from one place to another. Conceptually, this
information is rarely organised into conveniently sized, IP-addressed
packets and the FDR needs to consider how the information (content)
to be carried is identified, named and addressed. Routing techniques
can then be adapted to handle the expected types of content.
Doria, et al. Expires May 31, 2004 [Page 29]
Internet-Draft IRTF IDR Requirements December 2003
3.2.3 High level goals
This section attempts to answer two questions:
- What are we trying to achieve in a new architecture?
- Why should the Internet community care?
There is a third question that needs to be answered as well, but
which, for the present, is mostly not explicitly discussed:
- How will we know when we have succeeded?
3.2.3.1 Providing a routing system matched to domain organization
Many of today's routing problems are caused by a routing system that
is not well matched to the organization and policies which it is
trying to support. It is our goal to develop a routing architecture
where even domain organization that is not envisioned today can be
served by a routing architecture that matches its requirements.
We will know when this goal is achieved when the desired policies,
rules and organization can be mapped into the routing system in a
natural, consistent and simply understood way.
3.2.3.2 Supporting a range of different communication services
Today's routing protocols only support a single data forwarding
service that is typically used to deliver a best efforts service in
the Public Internet. On the other hand, with, for example, DiffServ
it is possible to construct a number of different bit transport
services within the network. Using some of the per-domain behaviors
(PDB)s that have been discussed in the IETF, it should be possible to
construct services such as Virtual Wire [18] and Assured Rate [19].
Providers today offer rudimentary promises about how traffic will be
handled in the network, for example delay and long-term packet loss
guarantees, and this will probably be even more relevant in the
future. Communicating the service characteristics of paths in routing
protocols will be necessary in the near future, and it will be
necessary to be able to route packets according to their service
requirements.
Thus, a goal of this architecture is to allow for adequate
information about path service characteristics passed between domains
and consequently allow the delivery of bit transport services other
than the best-effort datagram connectivity service that is the
Doria, et al. Expires May 31, 2004 [Page 30]
Internet-Draft IRTF IDR Requirements December 2003
current common denominator.
3.2.3.3 Scaleable well beyond current predictable needs
Any proposed new FDR system should scale beyond the size and
performance we can foresee for the next ten years. The previous IDR
proposal has, with some massaging, held up for somewhat over ten
years in which time the Internet has grown far beyond the predictions
that were made in the requirements that were placed on it originally.
Unfortunately, we will only know if we have succeeded in this goal if
the FDR system survives beyond its design lifetime without serious
massaging. Failure will be much easier to spot!
3.2.3.4 Supporting alternative forwarding mechanisms
With the advent of circuit based technologies (e.g., MPLS [24] used
for RSVP-TE or CR-LDP for traffic engineering, GMPLS [25]) managed by
IP routers there are forwarding mechanisms other than the datagram
service that need to be supported by the routing architecture.
An explicit goal of this architecture is to add support for
forwarding mechanisms other then the current hop-by-hop datagram
forwarding service driven by globally unique IP addresses.
3.2.3.5 Supporting separation of topology map and connectivity service
It is envisioned that an organization can support multiple services
on top of a single network. These services can, for example, be of
different quality, of different type of connectivity, or different
protocols (e.g. IPv4 and IPv6). For all these services there may be
common domain topology, even though the policies controlling the
routing of information might differ from service to service. Thus, a
goal with this architecture is to support separation between creation
of a domain (or organization) topology map and service creation.
3.2.3.6 Achieving separation between routing and forwarding
The architecture of a router is composed of two main separable parts;
control and forwarding. These components, while inter-dependent,
perform functions that are largely independent of each other. Control
(routing, signaling, and management) is typically done in software
while forwarding typically is done with specialized ASICs or network
processors.
The nature of an IP based network today is that control and data
protocols share the same network and forwarding regime. This may not
always be the case in future networks and we should be careful to
Doria, et al. Expires May 31, 2004 [Page 31]
Internet-Draft IRTF IDR Requirements December 2003
avoid building this sharing in as an assumption in the FDR.
A goal of this architecture is to support full separation of control
and forwarding, and to consider what additional concerns might be
properly considered separately (e.g. adjacency management).
3.2.3.7 Providing for use of different routing paradigms in different
areas of the same network
A number of different routing paradigms have been used or researched
in addition to conventional shortest path hop-by-hop paradigm that is
the current mainstay of the Internet. In particular, differences in
underlying transport networks may mean that other kinds of routing
are more relevant, and the perceived need for traffic engineering
will certainly alter the routing chosen in various domains.
Explicitly, one of these routing paradigms should be the current
routing paradigm, so that the new paradigms will inter-operate in a
backward-compatible way with today's system. This will facilitate a
migration strategy that avoids flag days.
3.2.3.8 Preventing denial of service and other security attacks
Currently, existence of a route to a destination effectively implies
that anybody who can get a packet onto the network is entitled to use
that route. Whilst there are limitations to this generalization,
this is a clear invitation to denial of service attacks. A goal of
the FDR system should be to allow traffic to be specifically linked
to whole or partial routes so that a destination or link resources
can be protected from unauthorized use.
3.2.3.9 Providing provable convergence with verifiable policy
interaction
It has been shown both analytically by Griffin et al (see [12]) and
practically (see [20]) that BGP will not converge stably or is only
meta-stable (i.e. will not reconverge in the face of a single
failure) when certain types of policy constraint are applied to
categories of network topology. The addition of policy to the basic
distance vector algorithm invalidates the proofs that could be
applied to a policy free implementation.
It has also been argued that global convergence may no longer be a
necessary goal and that local convergence may be all that is
required.
A goal of the FDR should be to achieve provable convergence of the
protocols used which may involve constraining the topologies and
Doria, et al. Expires May 31, 2004 [Page 32]
Internet-Draft IRTF IDR Requirements December 2003
domains subject to convergence. This will also require vetting the
policies imposed to ensure that they are compatible across domain
boundaries and result in a consistent policy set.
3.2.3.10 Providing robustness despite errors and failures
From time to time in the history of the Internet there have been
occurrences where people misconfiguring routers have destroyed global
connectivity. This should never be possible.
A goal of the FDR is to be robust to configuration errors and
failures. This should probably involve ensuring that the effects of
misconfiguration and failure can be confined to some suitable
locality of the failure or misconfiguration.
3.2.3.11 Simplicity in management
With the policy work ([26], [27] and [28]) that has been done at IETF
there exists an architecture that standardizes and simplifies
management of QoS. This kind of simplicity is needed in a future
domain routing architecture and its protocols.
A goal of this architecture is to make configuration and management
of inter-domain routing as simple as possible.
3.2.3.12 The legacy of RFC1126
RFC1126 outlined a set of requirements that were used to guide the
development of BGP. While the network is definitely different then it
was in 1989, many of the same requirements remain. A future domain
routing has to support as its base requirement, the level of function
that is available today. A detailed discussion of RFC1126 and its
requirements can be found in [41]. Those requirements, while
specifically spelled out in that document are to be subsumed by the
requirements in this document.
3.3 High level user requirements
This section considers the requirements imposed by the target
audience of the FDR both in terms of organizations that might own
networks, which would use FDR, and the human users who will have to
interact with the FDR.
3.3.1 Organisational users
The organizations that own networks connected to the Internet have
become much more diverse since RFC1126 [4] was published. In
particular a major part of the network are now owned by commercial
Doria, et al. Expires May 31, 2004 [Page 33]
Internet-Draft IRTF IDR Requirements December 2003
service provider organizations in the business of making profits from
carrying data traffic.
3.3.1.1 Commercial service providers
The routing system must take into account the commercial service
provider's need for commercial secrecy and security, as well as
allowing them to organize their business as flexibly as possible.
Service providers will often wish to conceal the details of the
network from other connected networks. So far as is possible, the
routing system should not require the service providers to expose
more details of the topology and capability of their networks than is
strictly necessary.
Many service providers will also offer contracts to their customers
in the form of Service Level Agreements (SLAs) and the routing system
must allow the providers to support these SLAs through traffic
engineering and load balancing, as well as multihoming, allowing them
to achieve the degree of resilience and robustness that they need.
Service providers can be categorized as
- Global Service Providers (GSPs) with networks that have a global
reach. Such providers may, and usually will, wish to constrain
traffic between their customers to run entirely on their networks.
Such providers will interchange traffic at multiple peering points
with other GSPs and need extensive policy-based controls to
control the interchange of traffic. Peering may be through the
use of dedicated private lines between the partners or
increasingly through Internet Exchange Points.
- National Service Providers (NSPs) that are similar to GSPs but
typically cover one country. Such organizations may operate as a
federation that provides similar reach to a GSP and may wish to be
able to steer traffic preferentially to other federation members
to achieve global reach.
- Local Internet Service Providers (ISPs) operate regionally and
will typically purchase transit capacity from NSPs or GSPs to
provide global connectivity, but may also peer with neighbouring
ISPs.
The routing system should be sufficiently flexible to accommodate the
continually changing business relationships of the providers, and the
various levels of trustworthiness that they apply to customers and
partners.
Doria, et al. Expires May 31, 2004 [Page 34]
Internet-Draft IRTF IDR Requirements December 2003
Service providers will need to be involved in accounting for Internet
usage, monitoring the traffic, and may be involved in government
action to tax the usage of the Internet, enforce social mores and
intellectual property rules or apply surveillance to the traffic to
detect or prevent crime.
3.3.1.2 Enterprises
The leaves of the network domain graph are in many cases networks
supporting a single enterprise. Such networks cover an enormous
range of complexity with some multi-national companies owning
networks that rival the complexity and reach of a GSP whereas many
fall into the Small Office-Home Office (SOHO) category. The routing
system should allow simple and robust configuration and operation for
the SOHO category, whilst effectively supporting the larger
enterprise.
Enterprises are particularly likely to lack the capability to
configure and manage a complex routing system and every effort should
be made to provide simple configuration and operation for such
networks.
Enterprises will also need to be able to change their service
provider with ease. Whilst this is predominantly a naming and
addressing issue, the routing system must be able to support seamless
changeover, for example, by coping with a changeover period when both
sets of addresses are in use.
Enterprises will wish to be able to multihome to one or more
providers as one possible means of enhancing the resilience of their
network.
Enterprises will also frequently need to control the trust that they
place both in workers and external connections through firewalls and
similar mid-boxes placed at their external connections.
3.3.1.3 Domestic networks
Increasingly domestic, i.e. non business home, networks are likely to
be 'always on' and will resemble SOHO enterprises networks with no
special requirements of the routing system.
The routing system must support dial-up users.
3.3.1.4 Internet exchange points
Peering of service providers, academic networks and larger
enterprises is increasingly happening at specific Internet Exchange
Doria, et al. Expires May 31, 2004 [Page 35]
Internet-Draft IRTF IDR Requirements December 2003
Points where many networks are linked together in a relatively small
physical area. The resources of the exchange may be owned by a
trusted third party or owned jointly by the connecting networks. The
routing systems should support such exchange points without requiring
the exchange point to either operate as a superior entity with every
connected network logically inferior to it or requiring the exchange
point to be a member of one (or all) connected networks. The
connecting networks have to delegate a certain amount of trust to the
exchange point operator.
3.3.1.5 Content providers
Content providers are at one level a special class of enterprise, but
the desire to deliver content efficiently means that a content
provider may provide multiple replicated origin servers or caches
across a network. These may also be provided by a separate content
delivery service. The routing system should facilitate delivering
content from the most efficient location.
3.3.2 Individual users
This section covers the most important human users of the FDR and
their expected interactions with the system.
3.3.2.1 All end users
The routing system must continue to deliver the current global
connectivity service (i.e. any address to any other address, subject
to policy constraints) that has always been the basic aim of the
Internet.
End user applications should be able to request, or have requested on
their behalf by agents and policy mechanisms, end-to-end
communication services with different QoS characteristics as compared
with the best efforts service that is the foundation of today's
Internet. It should be possible to request both a single service
channel and a bundle of service channels delivered as a single
entity.
3.3.2.2 Network planners
The routing system should allow them to plan and implement a network
that can be proved to be stable and will meet their traffic
engineering requirements.
3.3.2.3 Network operators
The routing system should, so far as is possible, be simple to
Doria, et al. Expires May 31, 2004 [Page 36]
Internet-Draft IRTF IDR Requirements December 2003
configure operate and troubleshoot, behave in a predictable, stable
fashion and deliver appropriate statistics and events to allow the
network to be managed and upgraded in an efficient and timely
fashion.
3.3.2.4 Mobile end users
The routing system must support mobile end users. It is clear that
mobility is becoming a predominant mode for network access.
3.4 Mandated constraints
While many of the requirement to which the protocol must respond are
technical, some aren't. These mandated constraints are those that
are determined by conditions of the world around us. Understanding
these requirements requires and analysis of the world in which these
systems will be deployed. The constraints include those that are
determined by:
- Environmental factors.
- Geography
- Political boundaries and considerations
- Technological factors such as the prevalence of different levels
of technology in the developed world as opposed to in the
developing or undeveloped world.
3.4.1 The federated environment
The graph of the Internet network with routers and other control
boxes at the nodes and communication links along the edges is today
partitioned administratively into a large number of disjoint domains.
A common administration may have responsibility for one or more
domains that may or may not be adjacent in the graph.
Commercial and policy constraints affecting the routing system will
typically be exercised at the boundaries of these domains where
traffic is exchanged between the domains.
The perceived need for commercial confidentiality will seek to
minimise the control information transferred across these boundaries,
leading to requirements for aggregated information, abstracted maps
of connectivity exported from domains and mistrust of supplied
information.
Doria, et al. Expires May 31, 2004 [Page 37]
Internet-Draft IRTF IDR Requirements December 2003
The perceived desire for anonymity may require the use of zero-
knowledge security protocols to allow users to access resources
without exposing their identity.
The requirements should provide the ability for groups of peering
domains to be treated as a complex domain. These complex domains
could have a common administrative policy.
3.4.2 Working with different sorts of networks
The diverse Layer 2 networks over which the layer 3 routing system is
implemented have typically been operated totally independently from
the layer 3 network. Consideration needs to be given to the degree
and nature of interchange of information between the layers that is
desirable. In particular, the need for robustness through diverse
routing implies knowledge of the underlying networks to be able to
guarantee the robustness.
Mobile access networks may also impose extra requirements on Layer 3
routing.
3.4.3 Delivering Diversity
The routing system is operating at Layer 3 in the network. To
achieve robustness and resilience at this layer requires that where
multiple diverse routes are employed as part of delivering the
resilience, the routing system at Layer 3 needs to be assured that
the Layer 2 and lower routes are really diverse. The 'diamond
problem' is the simplest form of this problem - a layer 3 provider
attempting to provide diversity buys layer 2 services from two
separate providers who in turn buy wayleaves from the same provider:
Layer 3 service
/ \
/ \
Layer 2 Layer 2
Provider A Provider B
\ /
\ /
Trench provider
Now when the backhoe cuts the trench, the Layer 3 provider has no
resilience unless he had taken special steps to verify that the
trench wasn't common. The routing system should facilitate avoidance
of this kind of trap.
Some work is going on to understand the sort of problems that stem
from this requirement, such as the work on Shared Risk Link Groups
Doria, et al. Expires May 31, 2004 [Page 38]
Internet-Draft IRTF IDR Requirements December 2003
[31]. Unfortunately, the full generality of the problem requires
diversity be maintained over time between an arbitrarily large set of
mutually distrustful providers. For some cases, it may be sufficient
for diversity to be checked at provisioning or route instantiation
time, but this remains a hard problem requiring research work.
3.4.4 When will the new solution be required?
There is a full range of opinion on this subject. An informal survey
indicates that the range varies from 2 years to 6 years. And while
there are those, possibly outliers, who think there is no need for a
new routing architecture as well as those who think a new
architecture was needed years ago, the median seems to lie at around
4 years. As in all projections of the future this is largely not
provable at this time.
3.5 Assumptions
In projecting the requirements for the Future Domain Routing a number
of assumptions have been made. The requirements set out should be
consistent with these assumptions, but there are doubtless a number
of other assumptions that are not explicitly articulated here:
1. The number of hosts today is somewhere in the area of 100
Million. With dial in and NATs this is likely to turn into up to
500 Million users (see [30]). In a number of years, with
wireless accesses and different appliances attaching to the
Internet, we are likely to see a couple of Billion (10^9)
'users' on the Internet. The number of globally addressable
hosts is very much dependent on how common NATs will be in the
future.
2. NATs, firewalls and other middleboxes exist and we cannot assume
that they will cease being a presence in the networks.
3. The number of operators in the Internet will probably not grow
very much, as there is a likelihood that operators will tend to
merge. However, as Internet-connectivity expands to new
countries, new operators will emerge and then merge again.
4. As of the beginning of 2002, there are around 12000 registered
AS's. With current use of AS's (for e.g., multi-homing) the
number of AS's could be expected to grow to 25000 in about 10
years.[43] This is down from a previously reported growth rate
of 51% per year.[13]. Future growth rates are difficult to
predict.
5. In contrast to the number of operators, the number of domains is
Doria, et al. Expires May 31, 2004 [Page 39]
Internet-Draft IRTF IDR Requirements December 2003
likely to grow significantly. Today, each operator has different
domains within an AS, but this also shows in SLAs and policies
internal to the operator. Making this globally visible would
create a number of domains 10-100 times the number of AS's,
i.e., between 100,000 and 1,000,000.
6. With more and more capacity at the edge of the network the IP
network will expand. Today there are operators with several
thousands of routers, but this is likely to be increased. A
domain will probably contain tens of thousands of routers.
7. The speed of connections in the (fixed) access will technically
be (almost) unconstrained. However, the cost for the links will
not be negligible so that the apparent speed will be effectively
bounded. Within a number of years some will have multi-gigabit
speed in the access.
8. At the same time, the bandwidth of wireless access still has a
strict upper-bound. Within the foreseeable future each user will
only have a tiny amount of resources available compared to fixed
accesses (10kbps to 2Mbps for UMTS with only a few achieving the
higher figure as the bandwidth is shared between the active
users in a cell and only small cells can actually reach this
speed, but 11Mbps or more for wireless LAN connections). There
may also be requirements for effective use of bandwidth as low
as 2.4 Kbps or lower, in some applications.
9. Assumptions 7 and 8 taken together suggest a minimum span of
bandwidth between 2.4 kbps to 10 Gbps.
10. The speed in the backbone has grown rapidly, and there is no
evidence that the growth will stop in the coming years. Terabit-
speed is likely to be the minimum backbone speed in a couple of
years. The range of bandwidths that need to be represented will
require consideration on how to represent the values in the
protocols.
11. There have been discussions as to whether Moore's law will
continue to hold for processor speed. If Moore's law does not
hold, then communication circuits might play a more important
role in the future. Also, optical routing is based on circuit
technology, which is the main reason for taking 'circuits' into
account when designing an FDR.
12. However, the datagram model still remains the fundamental model
for the Internet.
13. The number of peering points in the network is likely to grow,
Doria, et al. Expires May 31, 2004 [Page 40]
Internet-Draft IRTF IDR Requirements December 2003
as multi-homing becomes important. Also traffic will become more
locally distributed, which will drive the demand for local
peering.
14. The FDR will achieve the same degree of ubiquity as the current
Internet and IP routing.
3.6 Functional requirements
This section includes a detailed discussion of new requirements for a
future domain routing architecture. As discussed in section 3.2.3.12
a new architecture must build upon the requirements of the past
routing framework and must, and MUST not reduce the functionality of
the network. A discussion and analysis of the RFC1126 requirements
can be found in [41].
3.6.1 Topology
3.6.1.1 Routers should be able to know and exploit the domain topology
R(1) Routers MUST be able to acquire and hold sufficient information
on the underlying topology of the domain to allow the
establishment of routes on that topology.
R(2) Routers MUST have the ability to control the establishment of
routes on the underlying topology.
R(3) Routers MUST be able, where appropriate, to control Sub-IP
mechanisms to support the establishment of routes.
The OSI Inter-Domain Routing Protocol (IDRP)[36] utilized a
capability which allowed a collection of topologically related
domains to be replaced by a domain collection object in a similar way
to the Nimrod[9] domain hierarchies, allowing a route to be more
compactly represented by a single collection in place of a sequence
of individual domains.
R(4) Routers MUST, where appropriate, be able to construct
abstractions of the topology that represent an aggregation of
the topological features of some area of the topology.
3.6.1.2 The same topology information should support different path
selection ideas
The same topology information needs to provide a more flexible
spectrum of path selection methods that we might expect to find in a
Doria, et al. Expires May 31, 2004 [Page 41]
Internet-Draft IRTF IDR Requirements December 2003
future Internet, including, amongst others, both distributed
techniques such as hop-by-hop, shortest path, local optimization
constraint-based, class of service, source address routing, and
destination address routing as well as the centralized, global
optimization constraint-based 'traffic engineering' type (Open
constraints should be allowed). Allowing different path selection
techniques to be used will produce a much more predictable and
comprehensible result than the 'clever tricks' that are currently
needed to achieve the same results. Traffic engineering functions
need to be combined.
R(5) Routers MUST be capable of supporting a small number of
different path selection algorithms
3.6.1.3 Separation of the routing information topology from the data
transport topology.
R(6) The controlling network MAY be logically separate from the
controlled network.
Physically, the two functional 'planes' can reside in the same nodes
and share the same links, but this is not the only possibility. Other
options can also be feasible, and may sometimes be necessary. An
example is a pure circuit switch (that cannot see individual IP
packets), combined with an external controller. Another example may
be where there are multiple links between two routers, and all the
links are used for data forwarding, but only one is used for carrying
the routing session.
3.6.2 Distribution
3.6.2.1 Distribution mechanisms
R(7) Relevant changes in the state of the network, including
modifications to the topology and changes in the values of
dynamic capabilities, MUST be distributed to every entity in
the network that needs them in a reliable, and trusted way at
the earliest appropriate time after the change has occurred.
R(8) Information MUST NOT be distributed outside areas where it is
needed or believed to be needed for the operation of the
routing system.
R(9) Information MUST be distributed in such a way that it minimizes
the load on the network consistent with the required response
time of the network to changes.
Doria, et al. Expires May 31, 2004 [Page 42]
Internet-Draft IRTF IDR Requirements December 2003
3.6.2.2 Path advertisement
R(10) The router MUST be able to acquire and store additional static
and dynamic information relating to the capabilities of the
topology and its component nodes and links, which can
subsequently be used by path selection methods.
The inter-domain routing system must be able to advertise more kinds
of information than just connectivity and domain path.
R(11) The Routing System MUST support service specifications, e.g.
the Service Level Specifications (SLSs) developed by the
Differentiated Services working group. [42]
Careful attention should be paid to ensuring that the distribution of
additional information with path advertisements remains scalable as
domains and the Internet get larger, more numerous and more
diversified.
R(12) The distribution mechanism used for distributing network state
information MUST be scalable with respect to the expected size
of domains and the volume and rate of change of dynamic state
that can be expected.
The combination of R(9) and R(12) may result in a compromise between
the responsiveness of the network to change and the overhead of
distributing change notifications. Also attempts to respond to very
rapid changes may damage the stability of the routing system.
Possible examples of additional capability information that might be
carried include:
- QoS information
To allow an ISP to sell predictable end-to-end QoS service to any
destination, the routing system should have information about the
end-to-end QoS. This means that:
R(13) The routing system MUST be able to support different paths for
different services.
R(14) The routing system MUST be able to forward traffic on the path
appropriate for the service selected for the traffic either
according to an explicit marking in each packet of the traffic
(e.g. MPLS labels, DiffServ PHB's or DSCP values) or implicitly
(e.g. the physical or logical port on which the traffic
arrives).
Doria, et al. Expires May 31, 2004 [Page 43]
Internet-Draft IRTF IDR Requirements December 2003
R(15) The routing system SHOULD also be able to carry information
about the expected (or actually, promised) characteristics of
the entire path and the price for the service.
(If such information is exchanged at all between network
operators today, it is through bilateral management interfaces,
and not through the routing protocols.)
This would allow for the operator to optimise the choice of path
based on a price/performance trade-off.
In addition to providing dynamic QoS information the system should
be able to use static class-of-service information.
- security information
Security characteristics of other domains (in the path or in the
map) can allow the routing entity to choose routing decision based
on some political reasons. The information itself is assumed to be
so secure that you can trust it.
- usage and cost information
This can be used for billing and traffic engineering purpose. In
order to support cost based routing policies for customers (i.e.
peer ISPs), information such as "traffic on this link or path
costs XXX per Gigabyte" needs to be advertised, so that the
customer can choose a cheap or an expensive route from an economic
perspective.
- monitored performance
Some performance information such as delay and drop frequency can
be carried. (This is may only be suitable inside a domain because
of trust considerations). This should support at least the kind
of delay bound contractual terms that are currently being offered
by service providers. Note that these values refer to the outcome
of carrying bits on the path, whereas the QOS information refers
to the proposed behaviour that results in this outcome.
- Multicast information
R(16) The routing system must provide necessary information needed to
create multicast distribution trees. This information MUST be
provided for one-to-many distribution trees and SHOULD be
provided for many-to-many distribution trees.
Doria, et al. Expires May 31, 2004 [Page 44]
Internet-Draft IRTF IDR Requirements December 2003
The actual construction of distribution trees is not necessarily
done by the routing system.
3.6.2.3 Stability of routing information
R(17) The new network architecture MUST be stable without needing
global convergence, i.e. convergence is a local property.
The degree to which this is possible and the definition of local
remains a research topic. Restricting the requirement for convergence
to localities will have an effect on all of the other requirements in
this section.
R(18) The distribution, and the rate of distribution of changes MUST
NOT affect the stability of the routing information, e.g. by
commencing redistribution of a change before the previous one
had settled.
3.6.2.3.1 Avoiding routing oscillations
R(19) The routing system MUST minimize oscillations in route
advertisements.
3.6.2.3.2 Providing loop free routing and forwarding
In line with the separation of concerns of routing and forwarding:
R(20) The distribution of routing information MUST be, so far as is
possible, loop-free.
R(21) The forwarding information created from this routing
information MUST seek to minimize persistent loops in the data
forwarding paths.
It is accepted that transient loops may occur during convergence of
the protocol and that there are trade-offs between loop avoidance and
global scalability.
3.6.2.3.3 Detection, notification and repair of failures
R(22) The routing system MUST provide means for detecting failures of
both node equipment and communication links.
Doria, et al. Expires May 31, 2004 [Page 45]
Internet-Draft IRTF IDR Requirements December 2003
R(23) The routing system SHOULD be able to coordinate responses to
failure detection indications from layer 3 mechanisms and nodal
mechanisms built into the routing system and from lower layer
mechanisms that are propagated up to Layer 3 in order to
determine the root cause of the failure. This will allow the
routing system to react correctly to the failure by activating
appropriate mitigation and repair mechanisms if required,
whilst ensuring that it does not react if lower layer repair
mechanisms are able to repair or mitigate the fault.
Most layer 3 routing protocols have utilized keepalives or 'hello'
protocols as a means of detecting failures at Layer 3. The keepalive
mechanisms are often complemented by analog (e.g. laser light
detection) and hardware mechanisms (e.g. hardware/software watchdogs)
that are built into routing nodes and communication links. Great
care must be taken to make best possible use of the various failure
repair methods available whilst ensuring that only one repair
mechanism at a time is allowed to repair any given fault:
Interactions between (say) fast reroute mechanisms at layer 3 and
SONET/SDH repair at Layer 1 are highly undesirable and are likely to
cause problems in the network.
R(24) Where a network topology and routing system contains multiple
fault repair mechanisms, the responses of these systems to a
detected failure SHOULD be coordinated so that the fault is
repaired by the most appropriate means, and no extra repairs
are initiated.
R(25) Where specialized packet exchange mechanisms (e.g. layer 3
keepalive or 'hello' protocol mechanisms) are used to detect
failures, the routing system MUST make provision to allow the
rate of transmission of these keepalives to be configured,
including the capability to turn them off altogether where
links are deliberately broken when no real user or control
traffic is present (e.g. ISDN links).
This will allow the operator to compromise between the speed of
failure detection and the proportion of link bandwidth dedicated to
failure detection.
3.6.3 Addressing
3.6.3.1 Support mix of IPv4, IPv6 and other types of addresses
R(26) The routing system MUST support a mix of different kinds of
addresses.
This mix will include at least IPv4 and IPv6 addresses, and
Doria, et al. Expires May 31, 2004 [Page 46]
Internet-Draft IRTF IDR Requirements December 2003
preferably various types of non-IP addresses too. For instance
networks like SDH/SONET and WDM may prefer to use non-IP addresses.
It may also be necessary to support multiple sets of 'private' (e.g.
RFC1918) addresses when dealing with multiple customer VPNs.
R(27) The routing system SHOULD support the capability to use a
single topology representation to generate routing and
forwarding tables for multiple address families on the same
network.
This capability would minimise the protocol overhead when exchanging
routes.
3.6.3.2 Support for domain renumbering/readdressing
R(28) If a domain is subject to address reassignment that would cause
forwarding interruption then the routing system SHOULD support
readdressing (e.g. when a new prefix is given to an old
network, and the change is known in advance) by maintaining
routing during the changeover period [39], [40].
3.6.3.3 Multicast and anycast
R(29) The routing system MUST support multicast addressing, both
within a domain and across multiple domains.
R(30) The routing system SHOULD support anycast addressing within a
domain. The routing system MAY support anycast addressing
across domains.
It is still an open question as to whether it is possible or useful
to support anycast addressing between cooperating domains.
3.6.3.4 Address scoping
R(31) The routing system MUST support scoping of unicast addresses,
and SHOULD support scoping of multicast and anycast address
types.
For unicast address scoping, as is being designed for IPv6, does not
seem to cause any special problems with respect to routing. IPv6
Inter-domain routing handles only IPv6 global addresses, while intra-
domain routing also needs to be aware of the scope of private
addresses (editor's note: original reference was to site-local
addresses but these are being deprecated by the IETF). Link-local
addresses are never routed at all.
Doria, et al. Expires May 31, 2004 [Page 47]
Internet-Draft IRTF IDR Requirements December 2003
For scoping in a more general sense, and for scoping of multicast and
anycast addresses, more study may be needed to identify the
requirements solutions.
3.6.3.5 Mobility support
R(32) The routing system MUST support system mobility (and
movability, and portability, whatever the differences may be).
The term system includes anything from an end system to an
entire domain.
We observe that the existing solutions based on re-numbering and/or
tunneling are designed to work with the current routing, so they do
not add any new requirements to future routing. But the requirement
is general, and future solutions may not be restricted to the ones we
have today.
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.
3.6.5.1 Simple policy management
The basic aims of this specification are:
- to require less manual configuration than today
- to satisfy both the requirements for easy handling, and maximum
control, i.e.
- All the information should be available
Doria, et al. Expires May 31, 2004 [Page 48]
Internet-Draft IRTF IDR Requirements December 2003
- But should not be visible except for when desired.
- Policies themselves should be advertised and not only the
result of policy, and
- Provide Policy conflict Resolution
R(35) The routing system MUST provide for management of the system by
means of policies; e.g. that can be expressed in terms of the
business and services implemented on the network and reflect
the operation of the network in terms of the services affected.
R(36) The distribution of policies MUST be amenable to scoping, to
protect proprietary policies that are not of relevance beyond
the local set of domains from distribution.
3.6.5.2 Startup and Maintenance of Routers
A major problem in today's networks is the need to perform initial
configuration on routers from a local interface before a remote
management system can take over. It is not clear that this imposes
any requirements on the routing architecture beyond what is need for
a ZeroConf host.
Similarly, maintenance and upgrade of routers can cause major
disruptions to the network routing because the routing system and
management of routers is not organized to minimize such disruption.
Some improvements have been made, such as graceful restart mechanisms
in protocols, but more needs to be done.
R(37) The routing system and routers SHOULD provide mechanisms that
will minimize the disruption to the network caused by
maintenance and upgrades of software and hardware. It is
recognized that some of the capabilities needed are outside the
scope of the routing architecture (e.g. minimum impact software
upgrade) but the routing system SHOULD provide the necessary
support for such capabilities.
3.6.6 Provability
R(38) The routing system and its component protocols MUST be provably
locally convergent under the permitted range of parameter
settings and policy options that the operator(s) can select.
There are various methods for proof that include, but are not limited
to: mathematical, heuristic, and pattern recognition. No requirement
Doria, et al. Expires May 31, 2004 [Page 49]
Internet-Draft IRTF IDR Requirements December 2003
is made on the method used for proving local convergence properties.
R(39) Routing protocols employed by the routing system and the
overall routing system SHOULD be resistant to bad routing
policy decisions made by operators.
Tools are needed to check compatibility of routing policies. While
these tools are not part of the routing architecture, the mechanisms
to support such tools are.
Routing policies are compatible if their interaction does not cause
divergence. A domain or group of domains in a system is defined as
being convergent if and only if, after an exchange of routing
information, routing tables reach a stable state that does not change
until routing policies or topology changes.
To achieve the above-mentioned goals:
R(40) The routing system MUST provide a mechanism to publish and
communicate policies so that operational coordination and fault
isolation is possible.
Tools are required that verify the stability characteristics of the
routing system in specified parts of Internet. The tools should be
efficient (fast) and have a broad scope of operation (check large
portions of Internet). While these tools are not part of the
architecture, developing them is in the interest of the architecture
and should be defined as a Routing Research Group activity while
research on the architecture is in progress.
Tools analyzing routing policies can be applied statically or
(preferably) dynamically. Dynamic solution requires tools that can be
used for run time checking for a source of oscillations that arise
from policy conflicts. Research is needed to prove that there is an
efficient solution to the dynamic checking of oscillations.
3.6.7 Traffic engineering
The ability to do traffic engineering and get the feedback from the
network that enables traffic engineering are capabilities that should
be included in the future domain architecture. Traffic engineering
is, at base, another alternative or extension for the path selection
mechanisms of the routing system: No fundamental changes to the
requirements are needed but the iterative processes involved in
traffic engineering may require some additional capabilities and
state in the network.
Traffic engineering typically involves a combination of off-line
Doria, et al. Expires May 31, 2004 [Page 50]
Internet-Draft IRTF IDR Requirements December 2003
network planning and administrative control functions in which the
expected and measured traffic flows are examined resulting in changes
to static configurations and policies in the routing system. During
operations under these configurations control the actual flow of
traffic and affect the dynamic path selection mechanisms: The
results are measured and fed back into further rounds of network
planning.
3.6.7.1 Support for and provision of traffic engineering tools
At present there is an almost total lack of effective traffic
engineering tools, whether on-line at all times for network control
or off-line for network planning. The routing system should
encourage the provision of such tools.
R(41) The routing system MUST generate statistical and accounting
information in such a way that traffic engineering and network
planning tools can be used both in real time and for off-line
planning and management.
3.6.7.2 Support of multiple parallel paths
R(42) The routing system MUST support the controlled distribution,
over multiple links or paths, of traffic 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 reasons.
R(44) Where traffic is forwarded over multiple parallel paths, the
routing system MUST, so far as is possible, avoid reordering of
packets in individual micro-flows.
R(45) The routing system MUST have mechanisms to allow the traffic to
be reallocated back on to a single path when the multiple paths
are not needed.
R(46) The routing system MUST support peer-level connectivity as well
as hierarchical connections between domains.
The network is becoming increasingly complex with private peering
Doria, et al. Expires May 31, 2004 [Page 51]
Internet-Draft IRTF IDR Requirements December 2003
arrangements set up between providers at every level of the hierarchy
of service providers and even by certain large enterprises, in the
form of dedicated extranets.
R(47) The routing system MUST facilitate traffic engineering of these
peer routes so that traffic can be readily constrained to
travel as the network operators desire and they can
consequentially make optimal use of the available connectivity.
3.6.8 Support for middleboxes
One of our assumptions is that NATs and other middleboxes such as
firewalls, web proxies and address family (e.g. IPv4 to IPv6)
translators are here to stay.
R(48) The routing system SHOULD work in conjunction with middleboxes,
e.g. NAT, to aid in bi-directional connectivity without
compromising the additional opacity and privacy that the
middleboxes 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. Currently the required values
for these performance requirements are left for further discussion.
R(49) The routing system MUST support domains of at least X systems.
A system is taken to mean either an individual router or a
domain.
R(50) Local convergence SHOULD occur within X units of time.
R(51) The routing system MUST be 99.99x?% available.
R(52) The routing system MUST be measurably reliable. The measure of
reliabilty remains a research question.
R(53) The routing system MUST be locally stable to a measured degree.
The degree of measurabilty remains a research issue.
Doria, et al. Expires May 31, 2004 [Page 52]
Internet-Draft IRTF IDR Requirements December 2003
R(54) The routing system MUST be globally stable to a measured
degree. The degree of measurabilty remains a research issue.
R(55) The routing system SHOULD scale to an indefinitely large number
of domains.
In many cases there has been very little data or statistical evidence
for many of the performance claims being made. In recent years
several efforts have been initiated to gather data and do the
analyses required to make scientific assessments of the performance
issues and requirements. In order to complete this section of the
requirements analysis, the data and analyses from these studies needs
to be gathered and collated into this document. This work has been
started but has yet to be completed.
3.8 Backwards compatibility (cutover) and maintainability
This area poses a dilemma. On one hand it is an absolute requirement
that:
R(56) The introduction of the routing system MUST NOT require any
flag days
R(57) The network currently in place MUST continue to run at least as
well as it does now while the new network is being brought in
around it.
However, at the same time, it is also an absolute requirement that:
R(58) The new architecture MUST NOT be limited by the restrictions
that plague today's network. [It has to be admitted that this
is not a well defined requirement, because we have not fully
articulated what the restrictions might be. Some of these
restrictions can be derived by reading the discussions for the
positive requirements above: It would be a useful exercise to
explicitly list all the restrictions and irritations that we
wish to do away with. It would be further useful to determine
if these restrictions can currently be removed at reasonable
cost or whether we are actually condemned to live with them.]
Those restrictions cannot be allowed to become permanent baggage on
the new architecture. If they do, the effort to create a new system
will come to naught. It may, however, be necessary to live with some
of them temporarily for practical reasons whilst providing an
architecture which will eventually allow them to be removed.
These three requirements have significance not only for the
transition strategy, but for the architecture itself implying that it
Doria, et al. Expires May 31, 2004 [Page 53]
Internet-Draft IRTF IDR Requirements December 2003
must be possible for an internet such as today's BGP controlled
network, or one of its AS's, to exist as a domain within the new FDR.
3.9 Security requirements
As previously discussed, one of the major changes to have overtaken
the Internet since its inception, is the erosion of trust between end
users making use of the net, between those users and the suppliers of
services, and between the multiplicity of providers. Hence security,
in all its aspects, will be much more important in the FDR.
It must be possible to secure the routing communication:
R(59) The communicating entities MUST be able to identify who sent
and who received the information (authentication)
R(60) The communicating entities MUST be able to verify that the
information has not been changed on the way (integrity).
Security is more important in inter-domain routing where the operator
has no control to the other domains, then in intra-domain routing
since all the links and the nodes are under the administration of the
operator and can be expected to share a trust relationship. This
property of intra-domain trust, however, should not be taken for
granted:
R(61) Routing communications MUST be secured by default, but an
operator MUST have the option to relax this requirement within
a domain where analysis indicates that other means (such as
physical security) provide an acceptable alternative.
R(62) The routing communication mechanism MUST be robust against
denial-of-service attacks.
Further considerations that may impose requirements include:
- Whether no one else but the intended recipient must be able to
access (privacy) or understand (confidentiality) the information.
- Whether it is possible to verify that all the information has been
received (non-repudiation).
- Whether there is a need to separate security of routing from
security of forwarding.
- Whether traffic flow security is needed (i.e. whether there is
value in concealing who can connect to whom, and what volumes of
data are exchanged).
Doria, et al. Expires May 31, 2004 [Page 54]
Internet-Draft IRTF IDR Requirements December 2003
Securing the BGP session, as done today, only secures the exchange of
messages from the peering domain, not the content of the information.
In other words, we can confirm that the information we got is what
our neighbor really sent us, but we do not know if this information
(that originated in some remote domain) is true or not.
A decision has to be made on whether to rely on chains of trust (we
trust our peers who trust their peers who..), or whether we also need
authentication and integrity of the information end-to-end. This
information includes both routes and addresses. There has been
interest in having digital signatures 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 though another provider
as in multi-homing, both may have to be involved to confirm that the
prefix may be advertised through the provider who doesn't have any
interest in the prefix!
R(63) The routing system MUST cooperate with the security policies of
middleboxes whenever possible.
This is likely to involve further requirements for abstraction of
information, as, for example, the firewall is seeking to minimize
interchange of information that could lead to a security breach. The
effect of such changes on the end-to-end principle should be
carefully considered as discussed in [32].
R(64) The routing system MUST be capable of complying with local
legal requirement for interception of communication.
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-
ended.
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. The model is a topological model in that routing does not need
Doria, et al. Expires May 31, 2004 [Page 55]
Internet-Draft IRTF IDR Requirements December 2003
to directly model the physical length of the links or the position of
the nodes: The model can be transformed to provide a convenient
picture of the network by adjusting the lengths of the arcs and the
layout of the nodes. The connectivity is preserved and routing is
unaffected by the transformation.
The routing algorithms in traditional routing protocols utilize a
small number of results from graph theory. It is only recently that
additional results have been employed to support constraint based
routing for traffic engineering.
The naturalness of this network model and the 'fit' of the graph
theoretical methods may have tended to blind us to alternative
representations and inhibited us from seeking out alternative strands
of theoretical thinking that might provide improved results.
We should not allow this habitual behavior to stop us looking for
alternative representations and algorithms: Topological revolutions
are possible and allowed, at least in theory.
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 effort to object model becomes an end in itself and
does not lead to system creation. But there is a balance and a lot
that can be discovered in an ongoing effort to model a system such as
the future domain routing system. 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
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 in the best of
all possible worlds, it might be best to have one protocol that
handles all situations, this seems improbable in this less then best
Doria, et al. Expires May 31, 2004 [Page 56]
Internet-Draft IRTF IDR Requirements December 2003
of all possible worlds. On the other hand, maintaining the 'strict'
division evident in the network today between the IGP and EGP has
been effectively argued elsewhere as being too restrictive an
approach. Given this, and the fact that there are already many
routing protocols in use, the only possible answer seems to be that
the architecture SHOULD support many protocols. It remains an open
issue, one for the solution, to determine if a new protocol needs to
be designed in order to support the highest goals of this
architecture. The expectation is that, yes, a new protocol will need
to be designed.
3.10.4 Class of protocol to use
If a new protocol is required to support the FDR architecture, the
question remains open as to what kind of protocol this ought to be.
It is our expectation that a map distribution protocol will be
required to augment the current path-vector protocol and shortest
path first protocols.
3.10.5 Map abstraction
Assuming that a map distribution protocol is required, what are the
requirements on this protocol? If every detail is advertised
throughout the Internet, there will be a lot of information. Scalable
solutions require abstraction.
- If we summarise too much, some information will be lost on the
way.
- If we summarise too little, then more information then required is
available contributing to scaling limitations.
- One can allow more summarisation, if there also is a mechanism to
query for more details within policy limits.
- The basic requirement is not that the information shall be
advertised, but rather that the information shall be available to
those who need it. Of course we should not presuppose a solution
where advertising is the only possible mechanism.
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
Doria, et al. Expires May 31, 2004 [Page 57]
Internet-Draft IRTF IDR Requirements December 2003
result is a partial or incorrect understanding of the underlying
concept. Entities such as nodes, interfaces, sub-networks, tunnels,
and the grouping concepts such as AS's, 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).
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 for scaling control.
Note that groupings can look different depending on which aspect we
use to define them. A DiffServ area, a MPLS domain, a trusted domain,
a QoS area, a multicast domain, etc, do not always coincide. And
neither are they strict hierarchical subsets of each other. The basic
distinction at each level is "this grouping versus everything
outside".
3.10.9 Will new control mechanisms be needed?
Is it possible to apply a control theory framework, and analyze the
stability of the control system of the whole network domain, for e.g.
convergence speed and the frequency response, and then use the
results from that analysis to set the timers and other protocol
parameters?
Control theory could also play a part is QoS Routing, by modifying
current link state protocols with link costs dependent on load.
Control theory is used to increase the stability of such systems.
Doria, et al. Expires May 31, 2004 [Page 58]
Internet-Draft IRTF IDR Requirements December 2003
It might be possible to construct a new, totally dynamic routing
protocol solely on a control theoretic basis as opposed to the
current protocols which are based in graph theory and static in
nature.
3.10.10 Byzantium
Is solution to the Byzantine Generals problem a requirement? This is
the problem of reaching a consensus among distributed units if some
of them give misleading answers. The current intra-domain routing
system is, at one level, totally intolerant of misleading
information, but the effect of different sorts of misleading or
incorrect information has vastly varying results; from total collapse
through to purely local disconnection of a single domain. This sort
of behavior is not very desirable.
What are some of the other network robustness issues that must be
resolved?
3.10.11 VPN support
Today BGP is also used for VPN as well as other tasks, for example as
described in RFC2547 [16].
Internet routing and VPN routing have different purposes, and most
often exchange different information between different devices. Most
Internet routers do not need to know 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.
3.10.12 End to end reliability
The existing Internet architecture neither requires nor provides end-
to-end reliability of control information dissemination. For
example, in distributing VPN information there is, however, a
requirement for end to end reliability of control information, i.e.
the ends of the VPN established need to have a 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.
Doria, et al. Expires May 31, 2004 [Page 59]
Internet-Draft IRTF IDR Requirements December 2003
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
network.
Doria, et al. Expires May 31, 2004 [Page 60]
Internet-Draft IRTF IDR Requirements December 2003
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".
Doria, et al. Expires May 31, 2004 [Page 61]
Internet-Draft IRTF IDR Requirements December 2003
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.
Doria, et al. Expires May 31, 2004 [Page 62]
Internet-Draft IRTF IDR Requirements December 2003
6. Acknowledgments
This document is the combined efforts 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
acknowledgments.
Group A Acknolwedgements
This originated in the IRTF Routing Research Group's sub-group on
Inter-domain routing requirements. The members of the group are:
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.
Group B Acknowledgements
The draft 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
problems.
The individual members who contributed materially to this draft
are: Anders Bergsten, Howard Berkowitz, Malin Carlzon, Lenka Carr
Motyckova, Elwyn Davies, Avri Doria, Pierre Fransson, Yong Jiang,
Dmitri Krioukov, Tove Madsen, Olle Pers, and Olov Schelen.
Thanks also go to the members of Babylon and others who did
substantial reviews of this material. Specifically we would like
to acknowledge the helpful comments and suggestions of the
following individuals: Loa Andersson, Tomas Ahlstrom, Erik Aman,
Thomas Eriksson, Niklas Borg, Nigel Bragg, Thomas Chmara, Krister
Edlund, Owe Grafford, Torbjorn Lundberg, Jasminko Mulahusic,
Florian-Daniel Otel, Bernhard Stockman, Tom Worster, Roberto
Doria, et al. Expires May 31, 2004 [Page 63]
Internet-Draft IRTF IDR Requirements December 2003
Zamparo.
In addition, the authors are indebted to the folks who wrote all
the references we have consulted in putting this paper together.
This includes not only the references explicitly listed below, but
also those who contributed to the mailing lists we have been
participating in for years.
Finally, it is the editors who are responsible for any lack of
clarity, any errors, glaring omissions or misunderstandings.
Doria, et al. Expires May 31, 2004 [Page 64]
Internet-Draft IRTF IDR Requirements December 2003
Informative References
[1] Clark, D., "Policy Routing in Internet Protocols", RFC 1102,
May 1989.
[2] Estrin, D., "Requirements for Policy Based Routing in the
Research Internet", RFC 1125, Nov 1989.
[3] Steenstrup, M., "An Architecture for Inter-Domain Policy
Routing", RFC 1478, Jun 1993.
[4] Little, M., "Goals and Functional Requirements for
Inter-Autonomous System Routing", RFC 1126, Jul 1989.
[5] Perlman, R., "Interconnections Second Edition", Addison Wesley
Longman Inc., 1999.
[6] Perlman, R., "Network Layer Protocols with Byzantine
Robust-ness", Ph.D Thesis, Department of Electrical Engineering
and Computer Science, MIT, Aug 1988.
[7] Castineyra, I., Chiappa, N. and M. Steenstrup, "The Nimrod
Routing Architecture", RFC 1992, Aug 1996.
[8] Chiappa, N., "IPng Technical Requirements of the Nimrod Routing
and Addressing Architecture", RFC 1753, Dec 1994.
[9] Chiappa, N., "A New IP Routing and Addressing Architecture", ,
Jul 1991, <http://ana-3.lcs.mit.edu/~jnc/nimrod/overview.txt>.
[10] Wroclowski, J., "The Metanet White Paper - Workshop on Research
Directions for the Next Generation Internet", , 1995.
[11] Labovitz, C., Ahuja, A., Farnam, J. and A. Bose, "Experimental
Measurement of Delayed Convergence", Apricot , Mar 2000,
<http://www.apnic.net/meetings/amm2000/present/Abha_Ahuja.ppt>.
[12] Griffin, T. and G. Wilfong, "An Analysis of BGP Convergence
Properties", SIGCOMM , 1999.
[13] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, Dec 2001.
[14] Alaettinoglu, C., Jacobson, V. and H. Yu, "",
draft-alaettinoglu-isis-convergence-00 (work in progress), Nov
2000.
[15] Sandick, H., Squire, M., Cain, B., Duncan, I. and B. Haberman,
Doria, et al. Expires May 31, 2004 [Page 65]
Internet-Draft IRTF IDR Requirements December 2003
"Fast LIveness Protocol (FLIP)", draft-sandiick-flip-00 (work
in progress), Feb 2000.
[16] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, Mar 1999.
[17] Clark, D., Chapin, L., Cerf, V., Braden, R. and R. Hobby,
"Towards the Future Internet Architecture", RFC 1287, Dec 1991.
[18] Jacobson, V., Nichols, K. and K. Poduri, "The 'Virtual Wire'
Behavior Aggregate", draft-ietf-diffserv-pdb-vw-00 (work in
progress), Jul 2000.
[19] Seddigh, N., Nandy, B. and J. Heinanen, "An Assured Rate
Per-Domain Behaviour for Differentiated Services",
draft-ietf-diffserv-pdb-ar-00 (work in progress), Feb 2001.
[20] McPherson, D., Gill, V., Walton, D. and A. Retana, "BGP
Persistent Route Oscillation Condition",
draft-mcpherson-bgp-route-oscillation-00 (work in progress),
Dec 2000.
[21] Hain, T., "Architectural Implications of NAT", RFC 2993, Nov
2000.
[22] McPherson, D. and T. Przygienda, "OSPF Transient Blackhole
Avoidance", draft-mcpherson-ospf-transient-00 (work in
progress), Jul 2000.
[23] Thaler, D., Estrin, D. and D. Meyer, "Border Gateway Multicast
Protocol (BGMP): Protocol Specification",
draft-ietf-bgmp-spec-02 (work in progress), Nov 2000.
[24] Rosen, E., "Multiprotocol Label Switching Architecture", RFC
3031, Jan 2001.
[25] Ashwood-Smith, P., "Generalized MPLS - Signaling Functional
Description", draft-ietf-mpls-generalized-signaling-01 (work in
progress), Nov 2000.
[26] "IETF Resource Allocation Protocol working group", , 2002,
<http://www.ietf.org/html.charters/rap-charter.html>.
[27] "IETF Configuration management with SNMP working group", ,
2002, <http://www.ietf.org/html.charters/
snmpconf-charter.html>.
[28] "IETF Policy working group", , 2002, <http://www.ietf.org/
html.charters/policy-charter.html>.
Doria, et al. Expires May 31, 2004 [Page 66]
Internet-Draft IRTF IDR Requirements December 2003
[29] Yu, J., "Scalable Routing Design Principles", RFC 2791, Jul
2000.
[30] "Telcordia Technologies Netsizer web site", , 2002, <http://
www.telcordia.com/research/netsizer/>.
[31] "Inference of Shared Risk Link Groups",
draft-many-inference-srlg-00 (work in progress), Feb 2001.
[32] Blumenthal, M. and D. Clark, "Rethinking the design of the
Internet: The end to end arguments vs. the brave new world", ,
May 2001, <http://ana-www.lcs.mit.edu/anaweb/papers.html>.
[33] Lang, J., "Link Management Protocol", draft-lang-mpls-lmp-02
(work in progress), Jul 2000.
[34] Xu, Z., Dai, S. and J. Garcia-Luna-Aceves, "A More Efficient
Distance Vector Routing Algorithm", Proc IEEE MILCOM 97,
Monterey, California, Nov 1997, <http://www.cse.ucsc.edu/
research/ccrg/publications/zhengyu.milcom97.pdf>.
[35] Bradner, S. and A. Mankin, "The Recommendation for the IP Next
Generation Protocol", RFC 1752, Jan 1995.
[36] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing
Information among Intermediate Systems to support Forwarding of
ISO 8473 PDUs", International Standard 10747 ISO/IEC JTC 1,
Switzerland, 1993.
[37] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol
Extensions to BGP-4", RFC 2858, Jun 2000.
[38] Berkowitz, H. and D. Krioukov, "To Be Multihomed: Requirements
and Definitions", draft-berkowitz-multirqmt-02 (work in
progress), Oct 1999.
[39] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview:
Why would I want it and what is it anyway?", RFC 2071, Jan
1997.
[40] Berkowitz, H., "Router Renumbering Guide", RFC 2072, Jan 1997.
[41] Doria, A., "Analysis of IDR requirements and History",
draft-irtf-routing-history-00 (work in progress), December
2003.
[42] Grossman, D., "New Terminology and Clarifications for
Diffserv", draft-ietf-diffserv-new-terms-08 (work in progress),
Doria, et al. Expires May 31, 2004 [Page 67]
Internet-Draft IRTF IDR Requirements December 2003
Jan 2002.
[43] Broido, A., Nemeth, E., Claffy, K. and C. Elves, "Internet
Expansion, Refinement and Churn", Presentation at Nanog , Feb
2002.
[44] Partridge, C. and F. Kastenholz, "Technical Criteria for
Choosing IP The Next Generation (IPng)", RFC 1726, Dec 1994.
[45] Perkins, C., "IP Mobility Support.", RFC 2002, Oct 1996.
Authors' Addresses
Avri Doria
ETRI
161 Gajeong-dong
Yuseong-gu
Daejeon, RI 305-350
Korea
Phone: +82 16 9608 5024
EMail: avri@acm.org
Elwyn B. Davies
Nortel Networks
Harlow Laboratories
London Road
Harlow, Essex CM17 9NA
UK
Phone: +44 1279 405 498
Fax: +44 1279 405 514
EMail: elwynd@nortelnetworks.com
Frank Kastenholz
Juniper Networks
10 Technology Park
Westford, MA 01886
USA
Phone: +1 978 589 0286
EMail: fkastenholz@juniper.net
URI:
Doria, et al. Expires May 31, 2004 [Page 68]
Internet-Draft IRTF IDR Requirements December 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Doria, et al. Expires May 31, 2004 [Page 69]
Internet-Draft IRTF IDR Requirements December 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Doria, et al. Expires May 31, 2004 [Page 70]
