NOTE: This charter is accurate as of the 29th IETF Meeting in Seattle. It may now be out-of-date. (Consider this a "snapshot" of the working group from that meeting.) Up-to-date charters for all active working groups can be found elsewhere in this Web server.

Source Demand Routing (SDR) Charter

Chair(s)

Mailing List Information

Description of Working Group

The SDR Working Group is chartered to specify and promote the use of SDRP (Source Demand Routing Protocol) as an inter-domain routing protocol capability in conjunction with IDRP and BGP inter-domain routing protocols. The purpose of SDR is to support source-initiated selection of inter-domain 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, and configuration and usage.

The group's 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 collecting dynamic domain-level connectivity information, and 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. The group hopes to benefit from discussions with IDPR and Nimrod developers at this future stage because the issues faced are similar.

(5) The group will also investigate the addition of security options into the SDRP forwarding and packet format specifications.

Goals and Milestones

Mar 1993
Post an Internet-Draft of packet forwarding and control message format and protocol for IP.
Jun 1993
Post as an Internet-Draft the SDR MIB.
Jun 1993
Post as an Internet-Draft the SDR Usage and Configuration document. This is the highest priority after the draft specification in order to demonstrate how even static-SDR can be used to achieve concrete objectives.
Sep 1993
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.
Done
Submit as an Internet-Draft a specification for Route Setup.
Nov 1993
Post as an Internet-Draft a SDR Deployment Plan.
Dec 1993
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 1993
Post as an Internet-Draft a specification for SDR Multicast.
Mar 1994
Submit the set of SDR specifiations to the IESG for consideration as a Proposed Standard.
Mar 1994
Submit the set of SDR specifications to the IESG for consideration as a Prototype protocol.

NOTE: The Internet-Draft(s) listed below may have been deleted since they are only good for six months.

Internet-Drafts

RFCs