CURRENT_MEETING_REPORT_


Reported by Deborah Estrin/USC and Kannan Varadhan/USC

Minutes of the Source Demand Routing Working Group (SDR)

The SDR Working Group met in Seattle to discuss issues relevant to SDRP
route construction.  The following minutes are an outline of some of the
proposed techniques for route construction, and the various requirements
for making them feasible.

Deborah Estrin gave a brief report on the current status of the SDRP 2.0
packet forwarding code done at USC. This version is compliant with the
latest draft of the packet forwarding specification.  Improvements from
the previous version include:


   o General re-organization of code

   o Allow SDRP to work with packets of arbitrary size due to long
     source routes (much mbuf hacking)

   o Fragmentation

   o ICMP error messages for needing fragmentation, exceeding hop count

   o SDRP setup protocol

   o Use caching to speed forwarding/processing of SDRP packets

   o Avoiding using SDRP on packets with IP strict source route option

   o Send error messages along reverse of SDRP source route when IP
     cannot send the error

   o sdrp_config version 2.0 rewritten to give friendlier interface for
     installing filters and routes


As part of the next step, we need to decide on route construction
techniques for the short and medium term range.  In the short term
range, it has been observed that SDRP could be used to do provider
selection in the Internet today, by having the client domain initiate an
IDRP connection with a preferred backbone provider to obtain the
relevant FIB in a dynamic manner.

This requires changes to IDRP to overcome common subnetwork
restrictions.  Mechanisms are also needed to install SDRP routes learned
in this manner.  This latter technique will be required for all future
uses of SDRP.

The next extension for use in SDRP is to be able to query for RIBs for
selected destinations on demand.

This requires the following infrastructure:


   o Modifications to IDRP to permit querying for RIBs.
   o Protocols to do the RIB query.
   o Code to do the RIB query.
   o Heuristics on whom to query, as for example, a configured list of
     preferred providers.


Path Explorer is a mechanism to trigger the computation of new routes.
One can use a brute force explorer, or some form of constrained explorer
schemes.  Path Explorer was first proposed by Brijesh Kumar.

In the brute force scheme, the source requests the desired destination
to initiate a path explore.  BRs between the source and destination
propagate, but do not store, these routes.  In the process, they do
impose their transit policy criteria, but do not impose their own local
selection criteria.

The technique computes end-to-end routes, but is too expensive.

Routes are already constrained by their specified attributes.  Some
other techniques for constraining route propagation are to use source
specific preferences, hop counts, or hop counts with proxies.

To constrain route propagation, the source can specify a preference
function.  Intermediate BRs will keep a short lived cache, which they
use to compare with each viable route to decide whether or not to
propagate.

Given that the number of updates grows exponentially with the length of
the path, the source could specify a constraint hop count to limit the
update flood.

The source could use a proxy intermediate node to initiate the explore
to.  The problem with this technique is that it is hard to guess a good
proxy intermediate node accurately.  To fix this, one could use multiple
proxies.

The following is a summary of requirements for Path Explorer:

   o Protocols to initiate Path Explore and Proxy.

   o Specifications for the evaluation functions.

   o Requirements from IDRP to support propagation of routes without
     storing them internally:

      -  Do not apply selection criteria
      -  Do apply transit criteria
      -  Do not store locally (in FIB or RIBs)

   o Requirements from IDRP to support using alternate evaluation
     functions.

   o Implementations.


Path Verifier is a source routed path explorer.  It is required because
the actual forwarding behavior could be different from advertised
behavior, because network topology, or policies change and the cached
information is now stale.

We need a tool to verify the path after it has been computed and before
it is used.

Sue Hares has volunteered to work on the IDRP document changes.  A few
others have volunteered to port USC's SDRP packet forwarding code to
other architectures.


Attendees

William Barns            barns@gateway.mitre.org
Steven Berson            berson@isi.edu
Randy Bush               randy@psg.com
Deborah Estrin           estrin@usc.edu
William Gilliam          wag@cup.hp.com
Susan Hares              skh@merit.edu
Dimitry Haskin           dhaskin@wellfleet.com
Christian Huitema        Christian.Huitema@sophia.inria.fr
John Krawczyk            jkrawczy@wellfleet.com
Tony Li                  tli@cisco.com
Cheryl Madson            cmadson@wellfleet.com
J. Scott Marcus          smarcus@bbn.com
Daniel McDonald          danmcd@itd.nrl.navy.mil
Keith Mitchell           keith@pipex.net
Robert Moose             rmoose@gateway.mitre.org
Sandra Murphy            murphy@tis.com
Peder Chr.  Noergaard    pcn@tbit.dk
Erik Nordmark            nordmark@eng.sun.com
Ram Ramanathan           ramanath@bbn.com
Kwang Yao                kwang@cup.hp.com
Jessica Yu               jyy@merit.edu