CURRENT_MEETING_REPORT_ Reported by Martha Steenstrup/BBN Minutes of the Inter-Domain Policy Routing Working Group (IDPR) The IDPR Working Group met for two consecutive sessions during the March 1993 IETF meeting. We discussed the status of IDPR as a standard as well as experimental work that we are currently pursuing. Two new IDPR Internet-Drafts were issued prior to the IETF meeting: 1. An updated version of the IDPR MIB, written by Woody Woodburn of Sparta. 2. A discussion of the DNS modifications to support IP address to administrative domain mappings, written by Rob Austein of Epilogue. If you have not yet obtained a copy of these new Internet-Drafts, you are encouraged to do so. Please send all comments on the drafts to idpr-wg@bbn.com. Internet Pilot Demonstration The Internet pilot demonstration of IDPR is proceeding. We will demonstrate the functioning of IDPR in the presence of policies (``acceptable use policies'') supplied by the transit networks NSFnet, NSInet, and TWBnet. No routers in any of these networks will actually run IDPR. Rather, special IDPR routers (``policy gateways'' in the IDPR terminology) will act on behalf of NSFnet, NSInet, and TWBnet to supply policy routing. These policy gateways will only handle traffic designated as IDPR traffic. IDPR traffic will be generated by a small set of hosts at BBN, SRI, UCL, and ISI; no other Internet hosts will generate IDPR traffic. Policy gateways will be located at BBN, SRI, UCL, and ISI and will act on behalf of these sites to handle IDPR traffic. Policy gateways will also be located at the FIXes and will act on behalf of NSFnet, NSInet, and TWBnet to handle IDPR traffic. There will be two SPARCstations installed at the FIXes, one SPARCstation per FIX Ethernet. Each SPARCstation will act as a set of three policy gateways, one policy gateway per participating transit network per FIX. We will show that: o IDPR selects routes that respect the access restrictions imposed by the transit networks and the service requirements (for example, low delay) of the sources. o One may reconfigure transit network policies to suit current needs, 1 and IDPR routes will reflect these changes. o IDPR is robust in the presence of connectivity failures and quickly learns new routes. o If a source attempts to setup a route that violates transit network access restrictions, the transit network refuses the route. The policy gateways handle IDPR traffic only and will not touch other traffic. Hence, this pilot demonstration will not affect regular (non-IDPR) traffic traveling over the FIXes or over any of the transit networks attached to them. Two years ago, we demonstrated this functionality in networks such as DARTnet; this will be the first demonstration of IDPR functionality in the general Internet. Two of the more ``experimental'' topics we discussed included adding the super domain functionality, described in the IDPR architecture, to the IDPR protocols and integrating resource reservation with IDPR. To handle hierarchies of domains, IDPR must have a way to represent hierarchical domain addresses and to define the distribution scope of routing information in the hierarchy. Routing information from a given domain may be visible at multiple levels within the hierarchy if the distribution scope for that domain includes multiple levels. We define the ``routing context'' as the level in the domain hierarchy at which the routing will occur. For example, suppose domain A contains domain B which in turn contains a set of domains C1,...,Cn. Furthermore, suppose we want to route among the C domains. Then the routing context is represented as A/B. Thus, when we refer to Ci after defining the routing context, it is clear that we mean Ci contained in B contained in A, rather than Ci contained in some other domain Y. Routing context must be distributed in routing information messages as well as in path setup messages, to identify the context of the information contained within the message. When integrating resource reservation and IDPR, there must exist mechanisms to generate routes that are likely to have the requested resources, to reserve resources, and to control traffic such that reservations are honored. IDPR relies on intra-domain mechanisms to that support resource reservation and traffic control across a domain, and hence there must exist an interface for communicating reservation information to the intra-domain resource reservation mechanism. IDPR domains supporting resource reservations should distribute the mean and standard deviation of the bandwidth available for reservation between relevant virtual gateway pairs, in their routing information messages. Route servers can select routes based on the mean values of available bandwidth or even on more pessimistic views such as available bandwidth equal to n standard deviations lower than the mean. 2 Generating routes with such bandwidth metrics should increase the chances of producing routes that can in fact provide the requested bandwidth. Using statistical measures of available bandwidth, a domain need not generate a routing information message for each resource reservation or release. Thus, we can contain the amount of routing information messages. However, when bandwidth available for reservation is almost exhausted, a domain should immediately generate a routing information indicating this state. This will prevent generation of new paths through this domain. Moreover, when the available bandwidth increases to a reasonable amount again, the domain should generate a routing information message to inform other domains that it has sufficient resources to accept more traffic. We have simulated such algorithms, but have not yet implemented them in an actual network. Attendees Robert Austein sra@epilogue.com David Bridgham dab@epilogue.com Al Costanzo al@akc.com Shane Dawalt sdawalt@desire.wright.edu Chip Elliott celliot@bbn.com Frank Hoffmann hoffmann@dhdibm1.bitnet Frank Kastenholz kasten@ftp.com Tony Li tli@cisco.com Charles Lynn clynn@bbn.com Glenn Mackintosh glenn@canet.ca Brad Passwaters bjp@sura.net Manoel Rodrigues manoel_rodrigues@att.com Shawn Routhier sar@epilogue.com William Simpson Bill.Simpson@um.cc.umich.edu Martha Steenstrup msteenst@bbn.com Stuart Stubblebine stubblebine@isi.edu 3