xrtftr~1.htm

Current Meeting Report
Slides

Source Demand Routing (sdr)

NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.

Chair(s):

Deborah Estrin <estrin@usc.edu>

Routing Area Director(s):

Joel Halpern <jhalpern@newbridge.com>

Mailing Lists:

General Discussion:sdrp@catarina.usc.edu
To Subscribe: sdrp-request@catarina.usc.edu
Archive: ftp://catarina.usc.edu/pub/sdrp

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 explicit selection of inter- domain routes, to complement the implicit hop-hy-hop route selection provided by BGP/IDRP. The group is also chartered to specify and promote the use of a similar protocol for IPv6, referred to as the Explicit Routing Protocol (ERP).

The goal of the SDR Working Group is to release the components of SDR as ``experimental'' IETF protocols 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.

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 (a) 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) Apply the experience with SDR design and implementation to the design and implementation of ERP.

(4) Develop SDR and ERP deployment plans.

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

(6) 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. The route distribution and construction mechanisms are common to both ERP and SDRP.

(7) Investigate the use of SDRP and ERP alternate routing as a mechanism for supporting reservation traffic (e.g., based on RSVP). This will require that we address integration of SDRP/ERP and multicast routing (e.g., running PIM over SDRP/ERP), as well as the interface between SDRP/ERP and RSVP. Moreover, we will investigate the construction of SDRP/ERP routes that make use of some dynamic control information, in additional to the more traditional hop count.

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

(9) Coordinate with the IDR and IPng Working Groups.

Goals and Milestones:

Done

Post an Internet-Draft of packet forwarding and control message format and protocol for IP.

Done

Post, as an Internet-Draft, a ``white paper'' on route construction approaches and mechanisms for SDRP/ERP.

Done

Submit as an Internet-Draft a specification for Route Setup.

Done

Submit the packet forwarding and control message format Internet-Draft for publication as an RFC.

Dec 94

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.

Dec 94

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.

Jan 95

Post as an Internet-Draft a specification for SDR multicast. This is to be coordinated with IDMR's PIM.

Jan 95

Submit a ``white paper'' as an Internet-Draft on routing support for reservation-based traffic and SRRP's role. This is to be coordinated with RSVP.

Mar 95

Post as an Internet-Draft the SDR MIB. Three parts: packet forwarding and control messages MIB, the route distribution and computation MIB (including policy information).

Mar 95

Post revised Internet-Draft on route construction approaches and mechanisms for SDRP/ERP.

Jul 95

Submit the ERP specifications to the IESG for consideration as an Experimental protocol.

Oct 95

Post as an Internet-Draft the ERP MIB. Only the forwarding and control messages are different than the SDR MIB.

Dec 95

Submit the ERP specifications to the IESG for consideration as a Proposed Standard.

No Current Internet-Drafts

Request For Comments:

RFC

Status

Title

RFC1940

I

Source Demand Routing: Packet Format and Forwarding Specification (Version 1).

Current Meeting Report

The Working Group did not meet.

Slides

None Received

Done		Post an Internet-Draft of packet forwarding and control message format and protocol for IP.
Done		Post, as an Internet-Draft, a ``white paper'' on route construction approaches and mechanisms for SDRP/ERP.
Done		Submit as an Internet-Draft a specification for Route Setup.
Done		Submit the packet forwarding and control message format Internet-Draft for publication as an RFC.
Dec 94		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.
Dec 94		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.
Jan 95		Post as an Internet-Draft a specification for SDR multicast. This is to be coordinated with IDMR's PIM.
Jan 95		Submit a ``white paper'' as an Internet-Draft on routing support for reservation-based traffic and SRRP's role. This is to be coordinated with RSVP.
Mar 95		Post as an Internet-Draft the SDR MIB. Three parts: packet forwarding and control messages MIB, the route distribution and computation MIB (including policy information).
Mar 95		Post revised Internet-Draft on route construction approaches and mechanisms for SDRP/ERP.
Jul 95		Submit the ERP specifications to the IESG for consideration as an Experimental protocol.
Oct 95		Post as an Internet-Draft the ERP MIB. Only the forwarding and control messages are different than the SDR MIB.
Dec 95		Submit the ERP specifications to the IESG for consideration as a Proposed Standard.

RFC	Status	Title

RFC1940	I	Source Demand Routing: Packet Format and Forwarding Specification (Version 1).