minutes

[Martha Steenstrup <[e-mail]>]

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,
I encourage you to do so.  Please send all comments on the drafts
to [e-mail].

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:
- IDPR selects routes that respect the access restrictions imposed by
the transit networks and the service requirements (for example, low
delay) of the sources.
- One may reconfigure transit network policies to suit current needs,
and IDPR routes will reflect these changes.
- IDPR is robust in the presence of connectivity failures and quickly
learns new routes.
- 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 travelling 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.  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.