Source Demand Routing (sdr)
---------------------------
Charter
Last Modified: 04/07/1998
Current Status: Concluded Working Group
Chair(s):
Deborah Estrin <destrin@isi.edu>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
<0>
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 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.
JAN 95 Post as an Internet-Draft a specification for SDR
multicast. This is to be coordinated with IDMR's PIM.
MAR 95 Post revised Internet-Draft on route construction
approaches and mechanisms for SDRP/ERP.
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).
JUL 95 Submit the ERP specifiations 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.
Internet-Drafts:
No Current Internet-Drafts.
Request For Comments:
RFC Stat Published Title
------- -- ----------- ------------------------------------
RFC1940 I MAY 96 Source Demand Routing: Packet Format and Forwarding
Specification (Version 1).