As per Relevance of the word prototype, we have this rfc below:
Network Working Group M.
Request for Comments: 1477 BBN Systems and
July 1993
IDPR as a Proposed
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
1.
This document contains a discussion of inter-domain policy
(IDPR), including an overview of functionality and a discussion
experiments. The objective of IDPR is to construct and
routes between source and destination administrative domains,
provide user traffic with the services requested within
constraints stipulated for the domains transited
Four documents describe IDPR in detail
M. Steenstrup. An architecture for inter-domain policy routing
RFC 1478. July 1993.
M. Steenstrup. Inter-domain policy routing
specification: version 1. RFC 1479. July 1993.
H. Bowns and M. Steenstrup. Inter-domain policy
configuration and usage. Work in Progress. July 1991.
R. Woodburn. Definitions of managed objects for inter-
policy routing (version 1). Work in Progress. March 1993.
This is a product of the Inter-Domain Policy Routing Working Group
the Internet Engineering Task Force (IETF).
2. The Internet
As data communications technologies evolve and user populations grow
the demand for internetworking increases. The Internet
comprises over 7000 operational networks and over 10,000
networks. In fact, for the last several years, the number
constituent networks has approximately doubled annually. Although
do not expect the Internet to sustain this growth rate, we
prepare for the Internet of five to ten years in the future
Steenstrup [Page 1]
RFC 1477 IDPR July 1993
Internet connectivity has increased along with the number
component networks. Internetworks proliferate
interconnection of autonomous, heterogeneous networks administered
separate authorities. We use the term "administrative domain" (AD
to refer to any collection of contiguous networks, gateways, links
and hosts governed by a single administrative authority that
the intra-domain routing procedures and addressing schemes,
service restrictions for transit traffic, and defines
requirements for locally-generated traffic
In the early 1980s, the Internet was purely hierarchical, with
ARPANET as the single backbone. The current Internet possesses
semblance of a hierarchy in the collection of backbone, regional
metropolitan, and campus domains that compose it. However
technological, economical, and political incentives have prompted
introduction of inter-domain links outside of those in the
hierarchy. Hence, the Internet has the properties of
hierarchical and mesh connectivity
We expect that, over the next five years, the Internet will grow
contain O(10) backbone domains, most providing connectivity
many source and destination domains and offering a wide range
qualities of service, for a fee. Most domains will connect
or indirectly to at least one Internet backbone domain, in order
communicate with other domains. In addition, some domains
install direct links to their most favored destinations. Domains
the lower levels of the hierarchy will provide some transit service
limited to traffic between selected sources and destinations
However, the majority of Internet domains will be "stubs", that is
domains that do not provide any transit service for any other
but that connect directly to one or more transit domains
The bulk of Internet traffic will be generated by hosts in the
domains, and thus, the applications running in these hosts
determine the traffic service requirements. We expect
diversity encompassing electronic mail, desktop videoconferencing
scientific visualization, and distributed simulation, for example
Many of these applications have strict requirements on loss, delay
and throughput
In such a large and heterogeneous Internet, the routing
must be capable of ensuring that traffic is forwarded along
that offer the required services without violating domain
restrictions. We believe that IDPR meets this goal; it has
designed to accommodate an Internet comprising O(10,000)
administrative domains with diverse service offerings
requirements
Steenstrup [Page 2]
RFC 1477 IDPR July 1993
3. An Overview of
IDPR generates, establishes, and maintains "policy routes"
satisfy the service requirements of the users and respect the
restrictions of the transit domains. Policy routes are
using information about the services offered by and the
between administrative domains and information about the
requested by the users
3.1
With IDPR, each domain administrator sets "transit policies"
dictate how and by whom the resources in its domain should be used
Transit policies are usually public, and they specify
services comprising
- Access restrictions: e.g., applied to traffic to or from
domains or classes of users
- Quality: e.g., delay, throughput, or error characteristics
- Monetary cost: e.g., charge per byte, message, or session time
Each domain administrator also sets "source policies" for
originating in its domain. Source policies are usually private,
they specify requested services comprising
- Access: e.g., domains to favor or avoid in routes
- Quality: e.g., acceptable delay, throughput, and reliability
- Monetary cost: e.g., acceptable cost per byte, message, or
time
3.2
The basic IDPR functions include
- Collecting and distributing routing information, i.e.,
transit policy and connectivity information. IDPR uses link
routing information distribution, so that each source domain
obtain routing information about all other domains
- Generating and selecting policy routes based on the
information distributed and on source policy information.
gives each source domain complete control over the routes
generates
Steenstrup [Page 3]
RFC 1477 IDPR July 1993
- Setting up paths across the Internet, using the policy
generated
- Forwarding messages across and between administrative domains
the established paths. IDPR uses source-specified
forwarding, giving each source domain complete control over
paths traversed by its hosts' inter-domain traffic
- Maintaining databases of routing information, inter-domain
routes, forwarding information, and configuration information
3.3
Several different entities are responsible for performing the
functions
- "Policy gateways", the only IDPR-recognized connecting
between adjacent domains, collect and distribute
information, participate in path setup, maintain
information databases, and forward data messages along
paths
- "Path agents", resident within policy gateways, act on behalf
hosts to select policy routes, to set up and manage paths, and
maintain forwarding information databases. Any Internet host
reap the benefits of IDPR, as long as there exists a path
willing to act on its behalf and a means by which the host'
messages can reach that path agent
- Special-purpose servers maintain all other IDPR databases
follows
o Each "route server" is responsible for both its database
routing information, including domain connectivity and
policy information, and its database of policy routes. Also
each route server generates policy routes on behalf of
domain, using entries from its routing information
and using source policy information supplied
configuration or obtained directly from the path agents.
route server may reside within a policy gateway, or it
exist as an autonomous entity. Separating the route
functions from the policy gateways frees the policy
from both the memory intensive task of routing
database and route database maintenance and
computationally intensive task of route generation
o Each "mapping server" is responsible for its database
mappings that resolve Internet names and addresses
Steenstrup [Page 4]
RFC 1477 IDPR July 1993
administrative domains. The mapping server function can
easily integrated into an existing name service such as
DNS
o Each "configuration server" is responsible for its database
configured information that applies to policy gateways,
agents, and route servers in the given administrative domain
Configuration information for a given domain includes
and transit policies and mappings between local IDPR
and their addresses. The configuration server function can
easily integrated into a domain's existing network
system
3.4 Message
There are two kinds of IDPR messages
- "Data messages" containing user data generated by hosts
- "Control messages" containing IDPR protocol-related
information generated by policy gateways and route servers
Within the Internet, only policy gateways and route servers must
able to generate, recognize, and process IDPR messages.
servers and configuration servers perform necessary but
functions for IDPR, and they are not required to execute
protocols. The existence of IDPR is invisible to all other
and hosts. Using encapsulation across each domain, an IDPR
tunnels from source to destination across the Internet
domains that may employ disparate intra-domain addressing schemes
routing procedures
4.
IDPR contains mechanisms for verifying message integrity and
authenticity and for protecting against certain types of denial
service attacks. It is particularly important to keep IDPR
messages intact, because they carry control information critical
the construction and use of viable policy routes between domains
4.1 Integrity and
All IDPR messages carry a single piece of information, referred to
the IDPR documentation as the "integrity/authentication value",
may be used not only to detect message corruption but also to
the authenticity of the message's source IDPR entity. The
Assigned Numbers Authority (IANA) specifies the set of
algorithms which may be used to compute the integrity/
Steenstrup [Page 5]
RFC 1477 IDPR July 1993
values. This set may include algorithms that perform only
integrity checks such as n-bit cyclic redundancy checksums (CRCs),
well as algorithms that perform both message integrity and
authentication checks such as signed hash functions of
contents
Each domain administrator is free to select
integrity/authentication algorithm, from the set specified by
IANA, for computing the integrity/authentication values contained
its domain's messages. However, we recommend that IDPR entities
each domain be capable of executing all of the valid algorithms
that an IDPR message originating at an entity in one domain can
properly checked by an entity in another domain
IDPR control messages must carry a non-null integrity/
value. We recommend that control message integrity/authentication
based on a digital signature algorithm applied to a one-way
function, such as RSA applied to MD5, which simultaneously
message integrity and source authenticity. The digital signature
be based on either public key or private key cryptography. However
we do not require that IDPR data messages carry a non-
integrity/authentication value. In fact, we recommend that a
layer (end-to-end) procedure assume responsibility for checking
integrity and authenticity of data messages, because of the amount
computation involved
4.2
Each IDPR message carries a timestamp (expressed in seconds
since 1 January 1970 0:00 GMT) supplied by the source IDPR entity
which serves to indicate the age of the message. IDPR entities
the absolute value of a timestamp to confirm that the message
current and use the relative difference between timestamps
determine which message contains the most recent information.
IDPR entities must possess internal clocks that are synchronized
some degree, in order for the absolute value of a message
to be meaningful. The synchronization granularity required by
is on the order of minutes and can be achieved manually
Each IDPR recipient of an IDPR control message must check that
message's timestamp is in the acceptable range. A message
timestamp lies outside of the acceptable range may contain stale
corrupted information or may have been issued by a source whose
has lost synchronization with the message recipient. Such
must therefore be discarded, to prevent propagation of incorrect
control information. We do not require IDPR entities to perform
timestamp acceptability test for IDPR data messages, but
leave the choice to the individual domain administrators
Steenstrup [Page 6]
RFC 1477 IDPR July 1993
5. Size
IDPR provides policy routing among administrative domains and
been designed to accommodate an Internet containing tens of
of domains, supporting diverse source and transit policies
In order to construct policy routes, route servers require
information at the domain level only; no intra-domain details need
included in IDPR routing information. Thus, the size of the
information database maintained by a route server depends on
number of domains and transit policies and not on the number hosts
gateways, or networks in the Internet
We expect that, within a domain, a pair of IDPR entities
normally be connected such that when the primary intra-domain
fails, the intra-domain routing procedure will be able to use
alternate route. In this case, a temporary intra-domain failure
invisible at the inter-domain level. Thus, we expect that
intra-domain routing changes will be unlikely to force inter-
routing changes
Policy gateways distribute routing information when
inter-domain changes occur but may also elect to distribute
information periodically as a backup. Thus, policy gateways do
often need to generate and distribute routing information messages
and the frequency of distribution of these messages depends
weakly on intra-domain routing changes
IDPR entities rely on intra-domain routing procedures
within domains to transport inter-domain messages across domains
Hence, IDPR messages must appear well-formed according to the intra
domain routing procedures and addressing schemes in each
traversed; this requires appropriate header encapsulation of
messages at domain boundaries. Only policy gateways and
servers must be capable of handling IDPR-specific messages;
gateways and hosts simply treat the encapsulated IDPR messages
any other. Thus, for the Internet to support IDPR, only a
proportion of Internet entities require special IDPR software
With domain-level routes, many different traffic flows may use
only the same policy route but also the same path, as long
source domains, destination domains, and requested services
identical. Thus, the size of the forwarding information
maintained by a policy gateway depends on the number of domains
source policies and not on the number of hosts in the Internet
Moreover, memory associated with failed, expired, or disused
can be reclaimed for new paths, and thus forwarding information
many paths can be accommodated
Steenstrup [Page 7]
RFC 1477 IDPR July 1993
6. Interactions with Other Inter-Domain Routing
We believe that many Internet domains will benefit from
introduction of IDPR. However, the decision to support IDPR in
given domain is an individual one, left to the domain administrator
not all domains must support IDPR
Within a domain that supports IDPR, other inter-domain
procedures, such as BGP and EGP, can comfortably coexist.
inter-domain routing procedure is independent of the others.
domain administrator determines the relationship among the inter
domain routing procedures by deciding which of its traffic
should use which inter-domain routing procedures and by
this information for use by the policy gateways
Hosts in stub domains may have strict service requirements and
will benefit from the policy routing provided by IDPR. However,
stub domain itself need not support IDPR in order for its
flows to use IDPR routes. Instead, a "proxy domain" may perform
functions on behalf of the stub. The proxy domain must be
from the stub domain according to an inter-domain routing
independent of IDPR. Administrators of the stub and potential
domains mutually negotiate the relationship. Once an agreement
reached, the administrator of the stub domain should provide
proxy domain with its hosts' service requirements
IDPR policy routes must traverse a contiguous set of IDPR domains
Hence, the degree of IDPR deployment in transit domains
determine the availability of IDPR policy routes for Internet users
For a given traffic flow, if there exists no contiguous set of
domains between the source and destination, the traffic flow
on an alternate inter-domain routing procedure to provide a route
However, if there does exist a contiguous set of IDPR domains
the source and destination, the traffic flow may take advantage
policy routes provided by IDPR
7. Implementation
To date, there exist two implementations of IDPR: one an
prototype and the other an integral part of the gated UNIX process
We describe each of these implementations and our experience
them in the following sections
7.1 The
During the summer of 1990, the IDPR development group consisting
participants from USC, SAIC, and BBN began work on a UNIX-
software prototype of IDPR, designed for implementation in
Steenstrup [Page 8]
RFC 1477 IDPR July 1993
workstations. This prototype consisted of multiple user-
processes to provide the basic IDPR functions together with
modifications to speed up IDPR data message forwarding
Most, but not all, of the IDPR functionality was captured in
prototype. In the interests of producing working software as
as possible, we intentionally left out of the IDPR prototype
for source policies and for multiple policy gateways connecting
domains. This simplified configuration and route generation
compromising the basic functionality of IDPR
The IDPR prototype software was extensively instrumented to
detailed information for monitoring its behavior.
instrumentation allowed us to detect events including but not
to
- Change in policy gateway connectivity to adjacent domains
- Change in transit policies configured for a domain
- Transmission and reception of link state routing information
- Generation of policy routes, providing a description of the
route
- Transmission and reception of path control information
- Change of path state, such as path setup or teardown
With the extensive behavioral information available, we were able
track most events occurring in our test networks and hence
whether the prototype software provided the expected functionality
7.1.1 Test
In February 1991, the IDPR development group began experimenting
the completed IDPR prototype software. Each IDPR development
had its own testing environment, consisting of a set
interconnected Sun workstations, each workstation performing
functions of a policy gateway and route server
- USC used a laboratory test network consisting of SPARC1+
workstations, each pair of workstations connected by an
segment. The topology of the test network could be
configured
- SAIC used Sun3 workstations in networks at Sparta and at MITRE
These two sites were connected through Alternet using a 9.6kb
Steenstrup [Page 9]
RFC 1477 IDPR July 1993
link and through an X.25 path across the DCA EDN testbed
- BBN used SPARC1+ workstations at BBN and ISI connected over
DARTnet and TWBnet
7.1.2
The principal goal of our experiments with the IDPR
software was to provide a proof of concept. In particular, we
out to verify tha t the IDPR prototype software was able to
- Monitor connectivity across and between domains
- Update routing information when inter-domain connectivity
or when new transit policies were configured
- Distribute routing information to all domains
- Generate acceptable policy routes based on current link
routing information
- Set up and maintain paths for these policy routes
- Tear down paths that contained failed components, supported
policies, or attained their maximum age
Furthermore, we wanted to verify that the IDPR prototype
quickly detected and adapted to those events that directly
policy routes
The internetwork topology on which we based most of our
consisted of four distinct administrative domains connected in
ring. Two of the four domains served as host traffic source
destination, AD S and AD D respectively, while the two
domains provided transit service for the host traffic, AD T1 and
T2. AD S and AD D each contained a single policy gateway
connected to two other policy gateways, one in each transit domain
AD T1 and AD T2 each contained at most two policy gateways,
policy gateway connected to the other and to a policy gateway in
source or destination domain. This internetwork topology
two distinct inter-domain routes between AD S and AD D, allowing
to experiment with various component failure and transit
reconfiguration scenarios in the transit domains
For the first set of experiments, we configured transit policies
AD T1 and AD T2 that were devoid of access restrictions. We
initialized each policy gateway in our internetwork, loading in
domain-specific configurations and starting up the IDPR processes
Steenstrup [Page 10]
RFC 1477 IDPR July 1993
In our experiments, we did not use mapping servers; instead,
configured address/domain mapping tables in each policy gateway
After policy gateway initialization, we observed that each
gateway immediately determined the connectivity to policy gateways
its own domain and in the adjacent domains. The
policy gateway in each domain then generated a routing
message that was received by all other policy gateways in
internetwork
To test the route generation and path setup functionality of the
prototype software, we began a telnet session between a host in AD
and a host in AD D. We observed that the telnet traffic prompted
path agent resident in the policy gateway in AD S to request a
route from its route server. The route server then generated
policy route and returned it to the path agent. Using the
route supplied by the route server, the path agent initiated
setup, and the telnet session was established immediately
Having confirmed that the prototype software satisfactorily
the basic IDPR functions, we proceeded to test the software
changing network conditions. The first of these tests showed
the IDPR prototype software was able to deal successfully with
component failure along a path. To simulate a path
failure, we terminated the IDPR processes on a policy gateway in
transit domain, AD T1, traversed by the current path. The
gateways on either side of the failed policy gateway
detected the failure. Next, these two policy gateways,
two different domains, each issued a routing information
indicating the connectivity change and each initiated path
for its remaining path section
Once the path was torn down, the path agent agent in AD S requested
new route from its route server, to carry the existing
traffic. The route server, having received the new
information messages, proceeded to generate a policy route
the other transit domain, AD T2. Then, the path agent in AD S set
a path for the new route supplied by the route server.
the component failure and traffic rerouting, the telnet
remained intact
At this point, we restored the failed policy gateway in AD T1 to
functional state, by restarting its IDPR processes. The
policy gateway connectivity prompted the generation and
of routing information messages indicating the change in
connectivity
Steenstrup [Page 11]
RFC 1477 IDPR July 1993
Having returned the internetwork topology to its
configuration, we proceeded to test that the IDPR prototype
was able to deal successfully with transit policy reconfiguration
The current policy route carrying the telnet traffic traversed AD T2.
We then reconfigured the transit policy for AD T2 to preclude
of traffic travelling from AD S to AD D. The transit
reconfiguration prompted both the distribution of routing
advertising the new transit policy for AD T2 and the initiation
path teardown
Once the path was torn down, the path agent in AD S requested a
route from its route server, to carry the existing telnet traffic
The route server, having received the new routing
message, proceeded to generate a policy route through the
transit domain, AD T1. Then, the path agent in AD S set up a
for the new route supplied by the route server. Throughout
policy reconfiguration and rerouting, the telnet session
intact
This set of experiments, although simple, tested all of the
functionality of the IDPR prototype software and demonstrated
the prototype software could quickly and accurately adapt to
in the internetwork
7.1.3 Performance
We (USC and SAIC members of the IDPR development group) evaluated
performance of the path setup and message forwarding portions of
IDPR prototype software. For path setup, we measured the amount
processing required at the source path agent and at
policy gateways during path setup. For message forwarding,
compared the processing required at each policy gateway when
IDPR forwarding with IP encapsulation and when using only
forwarding. We also compared the processing required when
integrity/authentication value was calculated for the message
when the RSA/MD4 algorithms were employed
Our performance measurements were encouraging, but we have not
them here. We emphasize that although we tried to produce
software for the IDPR prototype, we were not able to devote
effort to optimizing this software. Hence, the
measurements for the IDPR prototype software should not be
extrapolated to other implementations of IDPR. To obtain a copy
the performance measurements for path setup and message forwarding
the IDPR prototype software, contact Robert
(woody@sparta.com) and Deborah Estrin (estrin@usc.edu).
Steenstrup [Page 12]
RFC 1477 IDPR July 1993
7.2 The Gated
In 1992, SRI joined the IDPR development group, and together SRI
SAIC, and BBN completed the task of integrating IDPR into the
UNIX process. As a result, IDPR is now available as part of gated
The gated version of IDPR contains the full functionality of
together with a simple yet versatile user interface for
configuration. As a single process, the gated version of
performs more efficiently than the multiple-process
version
The gated version of IDPR is freely available to the
community. Hence, anyone with a UNIX-based machine can
with IDPR, without investing any money or implementation effort.
making IDPR widely accessible, we can gain Internet experience
introducing IDPR into operational networks with real
constraints and transporting host traffic with real
requirements. Currently, a pilot deployment and demonstration
IDPR is under way in selected locations in the Internet
8. Security
Refer to section 4 for details on security in IDPR
9. Author's
Martha
BBN Systems and
10 Moulton
Cambridge, MA 02138
Phone: (617) 873-3192
Email: msteenst@bbn.
Steenstrup [Page 13]
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
