WG ACTION: Source Demand Routing (sdr)

[Greg Vaudreuil <[e-mail]>]

The IESG has approved a new working group in the Routing Area of the
IETF.  For more information, please contact the working group chairs or 
the area director.

Greg Vaudreuil
IESG Secretary


Source Demand Routing (sdr)

Charter 
 
Chair(s):
     Deborah Estrin  <[e-mail]>
     Tony Li  <[e-mail]>
 
Routing Area Director(s) 
     Bob Hinden  <[e-mail]>
 
Mailing lists: 
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           jerico.usc.edu:~/pub/sdrp

Description of Working Group:

The SDR Working Group is chartered to specify and promote the use of
SDR (Source Demand Routing Protocol) as an interdomain routing protocol
capability in conjunction with IDRP and BGP interdomain routing
protocols.  The purpose of SDR is to support source-initiated selection
of interdomain routes, to complement the intermediate node selection
provided by BGP/IDRP.

The goal of the SDR working group is to release the components of SDR
as IETF Prototypes and to obtain operational experience with SDR in the
Internet.  Once there is enough experience with SDR the working group
will submit the SDR components to the IESG for standardization.

SDR has four components: Packet formats for protocol control messages
and encapsulation of user datagrams, Processing and forwarding of user
data and control messages, Routing information distribution/collection
and route computation, Configuration and usage.


Our strategy is to:

1. Define the format, processing and forwarding of user datagram and
control messages so that SDR can be used very early on as an efficient
means of supporting "configured" inter-domain routes.  User packets are
encapsulated along with the source route and forwarded along the
"configured" route.  Routes are static at the inter-domain level, but
are not static in terms of the intra-domain paths that packets will
take between specified points in the SDR route. The impact of
encapsulation on MTU, ICMP, performance, etc., are among the issues
that must be evaluated before deployment.

2. Develop simple schemes for a) collecting dynamic domain-level
connectivity information, and b) route construction based on this
information, so that those domains that want to can make use of a
richer, and dynamic set of SDR routes.

3. In parallel with 1 and 2, develop usage and configuration documents
and prototypes that demonstrate the utility of static-SDR and
simple-dynamic-SDR.

4. After gaining some experience with the simple schemes for
distribution, develop a second generation of information distribution
and route construction schemes.  We hope to benefit from discussions
with IDPR and NIMROD developers at this future stage because the issues
faced are similar.

5. We will also investigate the addition of security options into the
SDRP forwarding and packet format specifications.

Goals and Milestones: 
 
   Mar 93 Post an Internet Draft of packet forwarding and control message 
          format and protocol for IP.                                          

   Jun 93 Post as an Internet Draft the SDR MIB.                               

   Jun 93 Post as an Internet Draft the SDR Usage and Configuration document. 
          This is the highest priority after the draft spec in order to 
          demonstrate how even static-SDR can be used to achieve concrete 
          objectives.                                                          

   Sep 93 Post as an Internet Draft the BGP/IDRP Extensions Specification. As 
          mentioned in the Internet Draft there are a few extensions to 
          BGP/IDRP needed to support SDR. These must be detailed and 
          documented.                                                          

   Sep 93 Submit as an Internet Draft a specification for Route Setup.         

   Nov 93 Post as an Internet Draft a SDR Deployment Plan.                     

   Dec 93 Post as an Internet Draft a document describing the 
          distribution/acquisition of Information to construct richer SDR 
          routes.  The initial versions of SDR will use only configured 
          information (some of which may be derived from BGP/IDRP) as the basis
          for constructing source routes.                                      

   Dec 93 Post as an Internet Draft a specification for SDR Multicast.         

   Mar 94 Submit the set of SDR specifiations to the IESG for consideration as 
          a Proposed Standard.                                                 

   Mar 94 Submit the set of SDR specifications to the IESG for consideration as
          a Prototype protocol.                                                


Internet Drafts:

  No Current Internet drafts.

Request For Comments:

  None to date.