rfc1477.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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
   ([e-mail]) and Deborah Estrin ([e-mail]).





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: [phone]
   Email: [e-mail]


















Steenstrup                                                     [Page 13]