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

Document Type RFC - Informational (May 1996; No errata)
Authors Deborah Estrin  , Tony Li  , Yakov Rekhter  , Kannan Varadhan  , Daniel Zappala 
Last updated 2013-03-02
Stream Internent Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1940 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          D. Estrin
Request for Comments: 1940                                           USC
Category: Informational                                            T. Li
                                                              Y. Rekhter
                                                           cisco Systems
                                                             K. Varadhan
                                                              D. Zappala
                                                                May 1996

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

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

1.  Overview

   The purpose of SDRP is to support source-initiated selection of
   routes to complement the route selection provided by existing routing
   protocols for both inter-domain and intra-domain routes. This
   document refers to such source-initiated routes as "SDRP routes".
   This document describes the packet format and forwarding procedure
   for SDRP.  It also describes procedures for ascertaining feasibility
   of SDRP routes.  Other components not described here are routing
   information distribution and route computation.  This portion of the
   protocol may initially be used with manually configured routes. The
   same packet format and processing will be usable with dynamic route
   information distribution and computation methods under development.

   The packet forwarding protocol specified here makes minimal
   assumptions about the distribution and acquisition of routing
   information needed to construct the SDRP routes.  These minimal
   assumptions are believed to be sufficient for the existing Internet.
   Future components of the SDRP protocol will extend capabilities in
   this area and others in a largely backward-compatible manner.

   This version of the packet forwarding protocol sends all packets with
   the complete SDRP route in the SDRP header. Future versions will
   address route setup and other enhancements and optimizations.

Estrin, et al                Informational                      [Page 1]
RFC 1940                         SDRv1                          May 1996

2.  Model of operations

   An Internet can be viewed as a collection of routing domains
   interconnected by means of common subnetworks, and Border Routers
   (BRs) attached to these subnetworks.  A routing domain itself may be
   composed of further subnetworks, routers interconnecting these
   subnetworks, and hosts.  This document assumes that there is some
   type of routing present within the routing domain, but it does not
   assume that this intra-domain routing is coordinated or even

   For the purposes of this discussion, a BR belongs to only one domain.
   A pair of BRs, each belonging to a different domain, but attached to
   a common subnetwork, form an inter-domain connection. By definition,
   packets that traverse multiple domains must traverse BRs of these
   domains.  Note that a single physical router may act as multiple BRs
   for the purposes of this model.

   A pair of domains is said to be adjacent if there is at least one
   pair of BRs, one in each domain, that form an inter-domain

   Each domain has a globally unique identifier, called a Domain
   Identifier (DI). All the BRs within a domain need to know the DI
   assigned to the domain.  Management of the DI space is outside the
   scope of this document.  This document assumes that Autonomous System
   (AS) numbers are used as DIs.  A domain path (or simply path) refers
   to a list of DIs such as might be taken from a BGP AS path [1, 2, 3]
   or an IDRP RD path [4].  We refer to a route as the combination of a
   network address and domain paths. The network addresses are
   represented by NLRI (Network Layer Reachability Information) as
   described in [3].

   This document assumes that the routing domains are congruent to the
   autonomous systems. Thus, within the content of this document, the
   terms autonomous system and routing domain can be used

   An application residing at a source host inside a domain,
   communicates with a destination host at another domain.  An
   intermediate router in the path from the source host to the
   destination host may decide to forward the packet using SDRP.  It can
   do this by encapsulating the entire IP packet from the source host in
   an SDRP packet.  The router that does this encapsulation is called
   the "encapsulating router."

Estrin, et al                Informational                      [Page 2]
RFC 1940                         SDRv1                          May 1996
Show full document text