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