Source Demand Routing: Packet Format and Forwarding Specification (Version 1)
RFC 1940
Network Working Group D. Estrin
Request for Comments: 1940 USC
Category: Informational T. Li
Y. Rekhter
cisco Systems
K. Varadhan
D. Zappala
USC
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
consistent.
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
connection.
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
interchangeably.
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