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