As per Relevance of the word subscribe, we have this rfc below:
Network Working Group Y.
Request for Comments: 1787 T.J. Watson Research Center, IBM Corp
Category: Informational April 1995
Routing in a Multi-provider
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document was prepared by the author on behalf of the
Architecture Board (IAB). It is offered by the IAB to
discussion
Over the past few years the Internet has undergone
changes. Among them is the emergence of multiple Network
Providers, where resources that provide Internet-wide IP
(routers, links) are controlled by different organizations.
document presents some of the issues related to network layer
in a multi-provider Internet, and specifically to the
routing
1. Network Service Providers vs Network Service
Within the current routing paradigm the service offered by a
at the network layer (IP) is the set of destinations (hosts) that
be reached through the provider. Once a subscriber establishes
connectivity to a provider, the subscriber can in principle reach
the destinations reachable through the provider. Since the value
the Internet-wide connectivity service offered by a
increases with the number of destinations reachable through
provider, providers are motivated to interconnect with each other
In principle a provider need not offer the same service (in terms
the set of destinations) to all of its subscribers -- for some of
subscribers the provider may restrict the services to a subset of
destinations reachable through the provider. In fact, for
types of subscribers constrained connectivity could be seen as
of the service offered by a provider
In a multi-provider environment individual providers may be driven
diverse and sometimes even conflicting goals and objectives. Some
the providers exist to provide connectivity to only a specific
Rekhter [Page 1]
RFC 1787 Routing in a multi-provider Internet April 1995
of Network Service Subscribers. Other providers place no
on the subscribers that can subscribe to them, as long as
subscribers pay the fee charged by the providers. Some of
providers place certain constraints on the reselling of
connectivity services by organizations (e.g., other providers
attached to the providers. Some of the providers may be operated
companies that are subject to specific regulations (e.g.,
monopoly), while other providers are completely unregulated.
scope of geographical coverage among providers varies from a
region (e.g., county, town) to a country-wide, international, or
intercontinental
There is no centralized control over all the providers in
Internet. The providers do not always coordinate their efforts
each other, and quite often are in competition with each other
Despite all the diversity among the providers, the Internet-wide
connectivity is realized via Internet-wide distributed routing,
involves multiple providers, and thus implies certain degree
cooperation and coordination. Therefore, there is a need to
the providers' goals and objectives against the public interest
Internet-wide connectivity and subscribers' choices. Further work
needed to understand how to reach the balance
2. Routing
Conceptually routing requirements can be classified into
following three categories: source preferences,
preferences, and constraints on transit traffic. Source
allow an originator of a packet to exert control over the path to
destination. Destination preferences allow a destination to
control over the path from a source to the destination.
on transit traffic allow a provider to control the traffic that
traverse through the resources (routers, links) controlled by
provider
From a conceptual point of view the requirements over the degree
control for source and destination preferences may vary from
able to just provide connectivity (regardless of the path), to
able to select immediate providers, to more complex scenarios,
at the other extreme a subscriber may want to have complete
over the path selection
From a conceptual point of view the requirements over the degree
control for transit traffic may vary from control based only on
direct physical connectivity (controlling the set of
directly connected to the provider), to being able to
traffic to a particular set of sources or destinations, or
Rekhter [Page 2]
RFC 1787 Routing in a multi-provider Internet April 1995
combination of particular sources and destinations, or even take
account the paths to/from these sources and/or destinations
In view of a potentially wide variety of routing requirements,
need to get a better understanding on the relative
importance of various routing requirements. In practice
usually don't formulate their routing requirements in a vacuum.
example, since the primary role of a provider is to provide
to a set of subscribers, the provider usually formulates its
requirements based on the set of the routing requirements of
subscribers the provider is expected to serve
Support for various routing requirements should take into account
overhead and the scope of the overhead associated with
requirements. A situation where an organization can
impose routing information overhead on other organization (e.g.,
requiring the other organization to maintain an additional
information) should be viewed as undesirable. The cost of
a particular routing requirement should not be borne by
that do not benefit from supporting that requirement. Ideally
routing system should allow to shift the overhead associated with
particular routing requirement towards the entity that instigates
requirement (for example, there is a need to carefully balance
overhead associated with maintaining a state needed for multi-
header compression vs carrying explicit forwarding information on
per packet basis). Organizations with simple routing
shouldn't bear the same routing information overhead as
with complex routing requirements
A situation where the overhead associated with supporting
particular routing requirement has to be carried by every
(e.g., router, host) within an organization that would like to
the requirement could be viewed as undesirable. An
should be able to instantiate its routing requirements in a more
less central fashion, for example by utilizing just some of
routers
Even if the scope of the routing information overhead is
local, there is a need to perform a careful analysis of the
between the potential benefits and the cost associated
supporting various routing requirements
3.
The technique of encapsulation allows for the creation of a "virtual
IP overlay over an existing IP infrastructure. This has
implications for the Internet routing system
Rekhter [Page 3]
RFC 1787 Routing in a multi-provider Internet April 1995
In the presence of encapsulation, a provider may no longer be able
constrain its transit traffic to a particular set of ultimate
and/or destinations, as a packet may be encapsulated by some
along the path, with the original source and/or destination
being "hidden" (via encapsulation) at the Network layer. Likewise
encapsulation may affect source and destination preferences, as
source (or a destination) may either (a) be unaware of
encapsulation, or (b) have little or no control over the
segment of a path
Further work is needed to understand the implications of the
capabilities created via encapsulation on the semantics of
requirements, as well as the interaction among the
requirements by the entities that form the overlay and the
that form the underlying infrastructure
4. Price Structure and its Impact on
Routing among providers, as well as between providers and
may be influenced by the price structure employed by the providers
as well as the usage pattern of the subscribers. A provider can
routing as a mechanism that allows the provider to exert control
who can use the provider's services. A subscriber can view routing
a mechanism that allows the subscriber to exert control over
price it pays for the Internet connectivity
The need to exert control has to be carefully balanced against
cost of the routing mechanisms needed to provide such control. In
competitive market one could question the viability of a
whose incremental cost would be greater than the saving recovered
the mechanism -- competitive pressure or alternate mechanisms
likely to push providers and subscribers towards choosing
cheapest mechanism
5.
One of the key requirements imposed on the Internet routing is
ability to scale. In addition to conventional metrics for
(e.g., memory, CPU, bandwidth), we need to take into
scalability with respect to the human resources required to
the system. The need for deployment of CIDR already showed that
routing scheme that scales linearly with respect to the number
connected networks, or even to the number of connected
is unacceptable today, and is likely to be unacceptable in the
term. It is not clear whether routing that scales linearly with
number of providers is going to be acceptable in the long term
Rekhter [Page 4]
RFC 1787 Routing in a multi-provider Internet April 1995
Scaling implies that the Internet routing system needs to
powerful mechanisms to provide routing
aggregation/abstraction
In the absence of Internet-wide coordination and in the presence
competition among the providers, the aggregation/
mechanisms should minimize preconditions as well as limit the
of required inter-provider coordination. Ideally the routing
should allow a provider to control the amount of its local
needed to deal with the routing overhead based on considerations
are purely local to the provider
One of the side effects of the routing
aggregation/abstraction is that some of the routing information
going to be lost. This may impact route optimality and even
ability to find an existing route. The need for routing
aggregation/abstraction also implies certain homogeneity of
information to be aggregated/abstracted. This needs to be counter
balanced against the potential diversity of routing requirements
As a way to deal with the routing information loss due
aggregation/abstraction, we need to explore mechanisms that
routing that is based on the on-demand acquisition of subsets
unaggregated information
The overhead associated with supporting specific routing
has a direct impact on the overall scalability of the
routing system. We need to get a better understanding of how
routing requirements impact scalability. When the impact
significant, and the requirements have practical importance we
to develop mechanisms that allow the impact to be reduced
6. Hierarchical
Classless Inter-Domain Routing (CIDR) (RFC1518, RFC1519) that is
today for scalable Internet-wide routing is based on the technique
hierarchical routing. Essential to this technique is the
that Network layer addresses assigned to individual entities (e.g.,
hosts, routers) reflect the position of these entities within
network topology -- addresses are said to be "
significant". With CIDR addresses assigned to most of the
sites are expected to reflect providers the sites are connected to --
CIDR uses "provider-based" addresses
One of the fundamental consequences of using hierarchical routing
that in order to preserve topological significance of
addresses, changes in the network topology may need to be
by the corresponding changes in the addresses. Presence of
Rekhter [Page 5]
RFC 1787 Routing in a multi-provider Internet April 1995
providers serving the same geographical area implies that
subscriber should be able to switch from one provider to another
Since such a switch implies changes in the Internet topology,
follows that to retain topological significance of the (provider
based) addresses within the subscriber, the subscriber has to
the addresses of all of its entities -- the process known
"renumbering". There are already tools to facilitate this process --
Dynamic Host Configuration Protocol (DHCP). However, DHCP is not
widely deployed. Further work is needed to improve these tools,
them widely deployed, and to integrate them with Domain Name
(DNS).
Multi-level hierarchical routing allows for recapturing
routing information (routing entropy) due to the mismatch
addresses and topology at a particular level in the routing
at some higher level in the hierarchy (e.g., at an exchange
among providers). This enables the routing system to contain
scope of entities impacted by the mismatch. Containing the scope
entities could be an important factor to facilitate
renumbering. Further work is needed to develop
deployment strategies to put these capabilities in place
It is important to emphasize that the requirement to
topologically significant addresses doesn't need to be
indiscriminately to all the organizations connected to the
-- hierarchical routing requires that most, but not all addresses
topologically significant. For a large organization it could
sufficient if the set of destinations within the organization can
represented within the Internet routing system as a small number
address prefixes, even if these address prefixes are independent
the providers that the organization uses to connect to the
("provider-independent" addresses). The volume of routing
that a large organization would inject into the Internet
system would be comparable to the (aggregated) routing
associated with a large number of small organizations
Existence of multiple providers allows a subscriber to
simultaneously connected to more than one provider (multi-
subscribers). CIDR offers several alternatives for handling
cases. We need to gain more operational experience as well as
understand tradeoffs associated with the proposed alternatives
An alternative to CIDR address assignment is to assign
based purely on the geographical location. However,
assignment that reflects geographical location of an entity
that either (a) the Internet topology needs to be made
congruent to the geography, or (b) addresses aren't going to
topologically significant. In the former case we need to
Rekhter [Page 6]
RFC 1787 Routing in a multi-provider Internet April 1995
the driving forces that would make the topology congruent to
geography. In the latter case techniques other than
routing need to be developed
7. Routing Information
While ensuring Internet-wide coordination may be more and
difficult, as the Internet continues to grow, stability
consistency of the Internet-wide routing could significantly
if the information about routing requirements of
organizations could be shared across organizational boundaries.
information could be used in a wide variety of situations
from troubleshooting to detecting and eliminating conflicting
requirements. The scale of the Internet implies that the
should be distributed. Work is currently underway to
depositories of this information (Routing Registries), as well as
develop tools that analyze, as well as utilize this information
8.
In this section we enumerate some of the issues that the IAB
should be brought to the attention of the Internet community
The following two tasks require the most immediate attention
- further work is needed to develop technologies that
- further work is needed to investigate feasibility of
information aggregation above the direct (immediate)
The following tasks are viewed as medium term
- further work is needed to get a better understanding on
relative practical importance of various routing
- further work is needed to understand of how various
requirements impact scalability of the routing
- further work is needed to investigate alternatives
hierarchical
Finally, the following tasks are viewed as long term
- further work is needed to understand and utilize the benefits
routing information
Rekhter [Page 7]
RFC 1787 Routing in a multi-provider Internet April 1995
- further work is needed to understand the implications of
overlays created via
- further work is needed to understand how different
structures influence routing
- further work is needed to understand how to balance
providers' goals and objectives against the public interest
Internet-wide connectivity and subscribers' choices
9.
This document presents some of the issues related to routing in
multi-provider Internet. There are no doubt routing-related
that are not covered in this document. For instance, such areas
multicast routing, or routing in the presence of mobile hosts,
routing in the presence of a large shared media (e.g., ATM) aren'
discussed here. Further work is needed to understand the
of a multi-provider Internet on these areas
The impact of multi-provider Internet goes well beyond just routing
and percolates into such areas as network management
troubleshooting, and others. Further work is needed to assess
implications of multi-provider environment on these areas, as well
to understand the interaction among all these areas from a system
wide perspective
10.
Many thanks to all the IAB members, and especially to
Carpenter, Robert Elz, Christian Huitema, Paul Mockapetris, and
Zhang for their contributions to this document
Security
Security issues are not discussed in this memo
Editor's
Yakov
T.J. Watson Research Center IBM
P.O. Box 704, Office H3-D40
Yorktown Heights, NY 10598
Phone: +1 914 784 7361
EMail: yakov@watson.ibm.
Rekhter [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
