RFC relevance of destination

As per Relevance of the word destination, we have this rfc below:

Network Working Group D.
Request for Comments: 1940
Category: Informational T.
Y.
cisco
K.
D.

May 1996

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

Status of this

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

1.

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

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

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

Estrin, et al Informational [Page 1]

RFC 1940 SDRv1 May 1996

2. Model of

An Internet can be viewed as a collection of routing
interconnected by means of common subnetworks, and Border
(BRs) attached to these subnetworks. A routing domain itself may
composed of further subnetworks, routers interconnecting
subnetworks, and hosts. This document assumes that there is
type of routing present within the routing domain, but it does
assume that this intra-domain routing is coordinated or
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
a common subnetwork, form an inter-domain connection. By definition
packets that traverse multiple domains must traverse BRs of
domains. Note that a single physical router may act as multiple
for the purposes of this model

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

Each domain has a globally unique identifier, called a
Identifier (DI). All the BRs within a domain need to know the
assigned to the domain. Management of the DI space is outside
scope of this document. This document assumes that Autonomous
(AS) numbers are used as DIs. A domain path (or simply path)
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
network address and domain paths. The network addresses
represented by NLRI (Network Layer Reachability Information)
described in [3].

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

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

Estrin, et al Informational [Page 2]

RFC 1940 SDRv1 May 1996

2.1 SDRP

A component in an SDRP route is either a DI (AS number) or an
address. Thus, an SDRP route is defined as a sequence of
and routers, syntactically expressed as a sequence of DIs and
addresses. Thus an SDRP route is a collection of source
hops

Each component of the SDRP route is called a "hop." The
traverses each component of the SDRP route exactly once. When
router corresponding to one of the components of the SDRP
receives the packet from a router corresponding to the
component of the SDRP route, the router will process the
according to the SDRP forwarding rules in this packet. The
component of the SDRP route that this router will forward
packet to, is called the "next hop," with respect to this
and component of the SDRP route

An SDRP hop can either be a "strict" source routed hop, or
"loose" source routed hop. A strict source route hop is one
which, if the next hop specified is a DI, refers to an
adjacent domain, and the packet will be forwarded directly to
route within the domain; if the next hop specified is an
address, refers to an immediately adjacent router on a
subnetwork. Any other kind of a source route hop is a
source route hop

A route is a "strict source route" if the current hop
executed is processed as a strict source route hop. Likewise,
route is a "loose source route" if the current hop being
is processed as a loose source route hop

It is assumed that each BR participates in the intra-
routing protocol(s) (IGPs) of the domain to which the BR belongs
Thus, a BR may forward a packet to any other BR in its own
using intra-domain routing procedures. Forwarding a
between two BRs that form an inter-domain connection
neither intra-domain nor the inter-domain routing procedures (
inter-domain connection is a common Layer 2 subnetwork).

It is also assumed that all routers participate in the intra
domain routing protocol(s) (IGPs) of the domain to which
belong

While SDRP does not require that all domains have a common
layer protocol, all the BRs in the domains along a given
route are required to support a common network layer.
document specifies SDRP operations when that common network

Estrin, et al Informational [Page 3]

RFC 1940 SDRv1 May 1996

protocol is IP ([5]).

While this document requires all the BRs to support IP,
document does not preclude a BR from additionally supporting
network layer protocols as well (e.g., CLNP, IPX, AppleTalk).
a BR supports multiple network layers, then for the purposes
this model, the BR must maintain multiple Forwarding
Bases (FIBs), one per network layer

2.2 SDRP

Forwarding an IP packet along an SDRP route is accomplished
encapsulating the entire packet in an SDRP packet. An SDRP
consists of the SDRP header followed by the SDRP data. The
header carries the SDRP route constructed by the domain
originated the SDRP packet. The SDRP data carries the
packet that the source domain decided to forward via SDRP

An SDRP packet is carried across domains as the data portion of
IP packet with protocol number 42.

This document refers to the IP header of a packet that carries
SDRP packet as the delivery IP header (or just the
header). This document refers to the packet carried as SDRP
s the payload packet, and the IP header of the payload packet
the payload header

Thus, an SDRP Packet can be represented as follows

+-------------------+--------------+-------------------
| Delivery header | SDRP header | SDRP
| (IP header) | | (Payload packet
+-------------------+--------------+--------------------

Each SDRP route may have an MTU associated with it. An MTU of
SDRP route is defined as the maximum length of the payload
that can be carried without fragmentation of an SDRP packet.
means that the SDRP MTU as seen by the transport layer
applications above the transport layer is the actual link MTU
the length of the Delivery and SDRP headers. Procedures for
discovery are specified in Section 9.

2.3 D-

It is assumed that a BR participates in either BGP or IDRP. A
participating in SDRP augments its FIBs with a D-FIB that
routes to domains. A route to a domain is a triplet Hop, NLRI>, where DI depicts a destination domain, Next-

Estrin, et al Informational [Page 4]

RFC 1940 SDRv1 May 1996

depicts the IP address of the next-hop BR, and NLRI depicts
set of reachable destinations within the destination domain. D
FIBs are constructed based on the information obtained from
BGP, IDRP, or configuration information

An SDRP packet is forwarded across multiple domains by
the forwarding databases (both FIBs and D-FIBs) maintained by
BRs

The operational status of SDRP routes is monitored via
(Error Reporting) and active (Route Probing) mechanisms. The
Reporting mechanism provides the originator of the SDRP route
a failure notification. The Probing mechanism provides
originator of the SDRP route with confirmation of a route'
feasibility

3. SDRP Packet

The total length of an SDRP packet (header plus data) can
determined from the information carried in the delivery IP header
The length of the payload packet can be determined from the
length of an SDRP packet and the length of its SDRP Header

The following describes the format of an SDRP packet

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |D|S|P| | Hop Count |SourceProtoType| Payload Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Route Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | Notification |SrcRouteLength | NextHopPtr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Route ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version and Flags (1 octet

The SDRP version number and control flags are coded in the
octet. Bit 0 is the most significant bit, bit 7 is the
significant bit

Estrin, et al Informational [Page 5]

RFC 1940 SDRv1 May 1996

Version (bits 0 through 2)

The first three bits contain the Version field
the version number of the protocol. The value of this
is set to 1.

Flags (bits 3 through 7)

Data packet/Control packet (bit 3)

If the bit is set to 1, then the packet carries data

Otherwise, the packet carries control information

Loose/Strict Source Route (bit 4)

The Loose/Strict Source Route indicator is used
making a forwarding decision (see Section 5.2). If
bit is set to 1, it indicates that the next hop is
Strict Source Route Hop. If this bit is set to 0,
indicates that the next hop is a Loose Source Route

Probe Indicator (bit 5)

The Probe Indicator is used by the originator of
route to request verification of the route's
(see Sections 4 and 7.1). If this bit is set to 1,
indicates that the originator is probing the route.
bit should always be set to 0 for control packets

Hop Count (1 octet

The Hop Count field carries the maximum number of routers
SDRP data packet may traverse. It is decremented by 1 as
SDRP data packet traverses a router which forwards the
using SDRP forwarding. Once the Hop Count field reaches
value of 0, the router should discard the data packet
generate a control packet (see Section 5.2.6). A router
receives a packet with a Hop Count value of 0 should
the data packet, and generate a control packet (see
5.2.6).

Source Route Protocol Type (1 octet

The Source Route Protocol Type fields indicates the type
information that appears in the source route. The value 1
this field indicates that the contents of the source route
as described in this document and indicates an Explicit

Estrin, et al Informational [Page 6]

RFC 1940 SDRv1 May 1996

Route. The value 2 in this field indicates a Route Setup.
syntax of the source route for this value is identical to
value of 1, but also has additional semantics which are
in other documents

Payload Protocol Type (1 octet

The Payload Protocol Type field indicates the protocol type
the payload. If the payload is an IP datagram, then this
should contain the value 1.

Note that this Payload Protocol Type is not the same as the
protocol type[5,7].

Source Route Identifier (4 octets

The BR that originates the SDRP packet should insert a 32
value in this field which will serve as an identifier for
source route. This value needs to be unique only in
context of the originating BR

Target Router (4 octets

This field is meaningful only in control packets

The Target Router field contains one of the IP addresses of
router that originated the SDRP packet that triggered
control packet to be returned

Prefix (4 octets

The Prefix field contains an IP address prefix. Only
number of bits specified in the Prefix Length are significant
The Prefix field is used to prevent routing loops when
BGP or IDRP to route to the next AS in a loose source
(see Section 4).

Prefix Length (1 octet

The Prefix Length field indicates the length in bits of the
address prefix. A length of zero indicates a prefix
matches all IP addresses

Notification Code (1 octet

This field is only meaningful in control packets.
data packets, this field is transmitted as zero,
should be ignored on receipt

Estrin, et al Informational [Page 7]

RFC 1940 SDRv1 May 1996

This document defines the following values for
Notification Code

1 - No Route

2 - Strict Source Route

3 - Transit Policy

4 - Hop Count

5 - Probe

6 - Unimplemented SDRP

7 - Unimplemented Source Route Protocol

8 - Setup Request

Source Route Length (1 octet

The Source Route Length field indicates the length in 32
words of the domain level source route carried in the
Header

Next Hop Pointer (1 octet

The Next Hop Pointer field indicates the offset of the high
order byte of the next hop along the route that the packet
to be forwarded. This offset is relative to the start of
Source Route field; so if the value of the Next Hop
field equals the value of the Source Route Length field,
the entire source route has been completely traversed.
other source routes are said to be incompletely traversed

Source Route (variable

The components of the source route are syntactically
addresses

An IP address from network 128.0.0.0 is used to encode a
hop that is a domain. The least significant two octets
the DI, which is an Internet Autonomous System number

Estrin, et al Informational [Page 8]

RFC 1940 SDRv1 May 1996

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 128 . 0 | D. I. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

An IP address from the network 127.0.0.0 is used to
characteristics of the source route. The least
three octets are used as a Source Route Change field

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 127 | Source Route Change |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source Route Change (3 octets

Loose/Strict Source Route Change (bit 1)

The Loose/Strict Source Route Change bit reflects a
value of the Loose/Strict Source Route bit in the
header. The value of the Loose/Strict Source
Change bit is copied into the Loose/Strict Source
bit in the SDRP header when a Source Route Change
is encountered in processing an SDRP packet

The rest of the Source Route Change field is transmitted
zero, and should be ignored on receipt

Payload (variable

The Payload field carries the datagram originated by the end
system within the domain that constructed the SDRP packet.
Payload field forms the data portion of the SDRP packet. In
control packet this field may be empty or may carry the
header of the packet that triggered the control message (
5.2.5). Note that there is no padding between the Source
and the Payload, and that the Payload may start at
arbitrary octet boundary

Estrin, et al Informational [Page 9]

RFC 1940 SDRv1 May 1996

4. Originating SDRP Data

This document assumes that a router that originates SDRP packets
preconfigured with a set of SDRP routes. Procedures for
these routes are outside the scope of this document. SDRP
forwarding may be deployed initially without additional
protocol support

An application on a source host generates packets that must
delivered to a given destination. The packet traverses the
by following normal hop-by-hop routing information. An
router in the path between the source host and the destination
may decide to forward some of these packets via SDRP

When this router receives an IP datagram, the router uses
information in the datagram and the local criteria to
whether the datagram should be forwarded along a particular
route. Associated with each set of criteria is a set of one or
SDRP routes that should be used to route matching packets. The
nature of the criteria is a local matter. The only restrictions
document places on the applicability of SDRP routes is that an
datagram that contains a strict source route should not be
along an SDRP route, that SDRP encapsulation should never be
to an SDRP packet, and that if SDRP is used with inter-domain routes
the destination domain must also run SDRP

If the router decides to forward a datagram along a particular
route, the router constructs the SDRP packet by placing the
datagram into the Payload field of the SDRP packet and
the SDRP header based on the selected SDRP route. The Next
pointer is set to 0 (the first entry in the Source Route field of
SDRP packet). The value of the Time To Live field in the
header should be copied into the Hop Count field of the SDRP header

Even if we assume that interior routing is loop free, it is possible
either due to the state of inter-domain routing or due to other
routers, that a domain level source route that does not
with the intended destination domain may lead a packet into a
loop. Originating SDRP routers that wish to insure that this
not occur should include a final domain level hop of
destination's domain, i.e. specify the SDRP route as
instead of , if the destination host is in domain DI3.
means for determining the DI of the destination domain is outside
the scope of this document

Similarly, when using SDRP for interior routing, it is possible
the source route does not coincide with IGP routing. In this case
one means of preventing a loop is to specify the last hop router's

Estrin, et al Informational [Page 10]

RFC 1940 SDRv1 May 1996

address as the last address within the source route.
encapsulating router can do this by specifying the source route
reach destination host IP3 as instead of .

The source address field in the delivery header should contain an
address of the router. The value of the Don't Fragment flag of
delivery header is copied from the Don't Fragment flag of the
header. The value of the Type Of Service field in the
header is copied from the Type Of Service field in the
header. If the payload header contains an IP security option,
option is replicated as an option in the delivery header. All
IP options in the payload header must be ignored

If the SDRP route that is used is learned from IDRP, then the
corresponding to this route is copied into the TOS field in
delivery header

The resulting SDRP packet is then forwarded as described in
5.2.2.

If the encapsulating router decides to forward a datagram along
particular SDRP route that has an MTU smaller than the length of
datagram, then if the payload header has the Don't Fragment flag
to 1, the router should generate an ICMP Destination
message with a code meaning "fragmentation needed and DF set"
accordance with [6]. The ICMP message must be sent to the
source host. The router should then discard the original datagram

If a router has learned an MTU for a particular SDRP route,
via ICMP messages or via configuration information, and it
that an SDRP packet must be fragmented before transmission, then
first calculates the the effective MTU seen by the payload packet
If the effective MTU is greater than or equal to 512 bytes,
router SHOULD first fragment the payload packet using normal
fragmentation. SDRP packets are then constructed for each fragment
as describe above. Otherwise, the router should first form the
packet, and then fragment it

A router may use locally originated SDRP packets to verify
feasibility of its SDRP routes. To do this the router sets the
of the Probe Indicator field in the SDRP packet to 1. Receipt of
SDRP control packet by the originating router with the "
Completed" Notification Code (see Section 7.1) indicates
of the SDRP route. Persistent lack of SDRP control packets with
"Probe Completed" Notification Code should be used as an
that the associated SDRP route is not feasible

Estrin, et al Informational [Page 11]

RFC 1940 SDRv1 May 1996

5. Processing SDRP

We say that a router receives an SDRP packet if the
address field in the delivery header of the packet arriving at
router contains one of the IP addresses of the router

When a router receives an SDRP packet, the router extracts the
Route Protocol field from the SDRP header

5.1 Supporting Transit

A router may be able to verify that a packet that it is given
forward does not violate any of the transit policies that may exist
of the domain to which the router belongs. Specific
mechanisms are a matter that is local to the router and are
the scope of this document

The restriction on the verification mechanisms is that they may
into account only the contents of the SDRP header, the
header, and transport protocol header of the payload packet

With SDRP a domain may enforce its transit policies by
filters based on the information present in the IP Header.
example a router may initially carefully filter all SDRP traffic
all possible sources. A filter that allows certain SDRP traffic
selected sources to pass through the router could then be
dynamically to pass similar types of traffic. Thus, by
appropriate filtering information, a transit domain can
support transit policies. Other mechanisms for supporting
policy and implementation techniques are not precluded by
document

If the router detects that the SDRP packet violates a domain'
transit policy it sends back an SDRP control packet to
encapsulating router and discards the violating packet

SDRP control packets are not subject to transit policies

If a router does not discard an SDRP packet due to a transit
violation, then the router attempts to forward it as specified
Section 5.2.

5.2 Forwarding SDRP

Procedures for forwarding of an SDRP packet depend

a) whether the router has the routing information needed
forward the packet

Estrin, et al Informational [Page 12]

RFC 1940 SDRv1 May 1996

b) whether the SDRP route has been completely traversed
c) whether the SDRP route is strict or loose,
d) whether the packet is a data or control packet

When forwarding an SDRP packet (either data or control) a
should not modify the following fields in the delivery header

a) Source
b) Don't Fragment

If the Source Route Protocol Type of a packet indicates a Route
and the router does not or cannot support setup, the router MAY
the encapsulating router a control packet with a Notification Code
Setup Request Rejected. It MAY then modify the data packet so
the Source Route Protocol Type is Explicit Source Route and the
Indicator bit is 0, then forwards the packet as described below.
router MAY send notification of a failed setup request
periodically. Alternately, a router MAY silently drop the
Setup packet

5.2.1 Forwarding algorithm pseudo-

The following pseudo-code gives an overview of the SDRP
algorithm. Please consult the text below for more details

Let LOCAL_DI be the DI of the domain of the local system,
NEXT_HOP be the next hop in the source route if the source route
not been completely traversed, let NEXT_DI be the DI portion
NEXT_HOP if NEXT_HOP is from network 128.0.0.0, and let NEXT_
be the IP address of the next router if the packet is to be
using SDRP. We say that NEXT_DI is adjacent if the local domain
adjacent to the domain that has NEXT_DI as its DI, and we say
NEXT_ROUTER is adjacent if it represents an IP address of a
that shares a link with the current router. Normal IP
refers to forwarding that can be accomplished using FIBs
via BGP, IDRP or one or more IGPs

The pseudo code requires sending control messages in a number
places. All such control messages must be sent to the
router, which is indicated in the source address of the
header. Note too that all intermediate SDRP routers that process
SDRP packet must ensure that the source address of the
header is left untouched, since this source address is the address
the encapsulating router to which any control messages must be sent

Estrin, et al Informational [Page 13]

RFC 1940 SDRv1 May 1996

if the packet is a control packet
if the Target Router equals an address assigned to
local router
remove the delivery
process information carried in the control

end
if the packet can be forwarded using normal IP forwarding
set Next Hop Pointer to Source Route
forward the packet using normal IP

end
end

if the version field is not 1
if the packet is a data packet
generate a control packet with "Unimplemented SDRP version
end
discard the

end

if the source route protocol type is not 1
if the packet is a data packet
generate a control packet with "Unimplemented source
protocol type
end
discard the

end

if the Hop Count field is greater than 0
decrement the Hop Count
end
if the Hop Count field is 0
if the packet is a data packet
generate a control packet with "Hop Count Exceeded
end
discard the

end

if the packet is a data packet
if the packet violates transit policy
generate a control packet with "Transit Policy Violation

Estrin, et al Informational [Page 14]

RFC 1940 SDRv1 May 1996

discard the data

end
end

set mode to
set advanced to
if Next Hop Ptr does not equal Source Route Length
set NEXT_HOP to the next hop in the source
while mode equals NONE
if NEXT_HOP is from network 127.0.0.0
set the Loose/Strict Source Route bit equal
the Loose/Strict Source Route Change
else if NEXT_HOP is from network 128.0.0.0
set NEXT_DI to the least significant two octets of NEXT_
if NEXT_DI is not equal to LOCAL_DI
set mode to
end
else if NEXT_HOP does not equal an address assigned to
local router
set mode to
end
if mode equals NONE
set advanced to
increment the Next Hop Pointer
if Next Hop Pointer equals Source Route Length
set mode to

set NEXT_HOP to the next hop in the source
end
end
end
end

if mode equals DOMAIN
set route to
if the source route is loose
if not advanced
find the route, if any, based on Prefix and Prefix
if the route is an aggregate formed at the local router
set route to
end
end
if route equals NONE
select a BGP or IDRP route, if any, with a path that
NEXT_DI and is not an aggregate formed at the local
if route equals NONE

Estrin, et al Informational [Page 15]

RFC 1940 SDRv1 May 1996

if the packet is a data packet
generate a control packet with "No Route Available
end
discard the

end
copy the NLRI from the route to the Prefix and Prefix
end
if the route is an IDRP route
set appropriate TOS in delivery
end
set NEXT_ROUTER from the

set NEXT_ROUTER from the routing information for NEXT_
using the D-
if route equals NONE
if the packet is a data packet
generate a control packet with "No Route Available
end
discard the

end
if NEXT_DI is not adjacent
if the packet is a data packet
generate a control packet with "Strict Source Route Failed
end
discard the

end
end
end
end

if mode equals LOCAL
set NEXT_ROUTER equal to NEXT_
if the source route is strict and NEXT_ROUTER is
adjacent
if the packet is a data packet
generate a control packet with "Strict Source Route Failed
end
discard the

end
end

if mode equals LOCAL or mode equals DOMAIN
set the destination address of the delivery header

Estrin, et al Informational [Page 16]

RFC 1940 SDRv1 May 1996

to NEXT_
checksum the delivery
route packet to NEXT_ROUTER using normal IP

end

if the packet is a control packet
discard the
end
remove the delivery header and the SDRP
if there is no normal IP route to the payload destination
generate a control packet with "No Route Available
discard the data

end
forward the payload using normal IP
if the probe bit is set
generate a control packet with "Probe Completed
end

5.2.2 Handling an SDRP control packet

An SDRP control packet is indicated by 0 in the Data packet/
packet bit in the Flags field in the SDRP Header

If the Target Router field of the received SDRP packet contains an
address that is assigned to the router that received this
packet, then the router should use the information carried in
Notification Code field, the Source Route Identifier field and
information carried in the Payload field to update the status of
SDRP routes. Details of such procedures are described in Section 7.

Otherwise, the router checks whether it can forward the packet to
router specified in the Target Router field by using the
information present in its local FIB. If forwarding is possible
the local system sets the destination address of the delivery
to the address specified in the Target Router field, and hands
packet off for normal IP forwarding. If normal IP forwarding
impossible then the packet may be forwarded in the same manner as
SDRP data packet (described below) but with the following exceptions

- Control packets are not subject to transit policies
- In no case should a control packet be generated in response
an error caused by a control packet
- If the source route is completely traversed and the packet
cannot be forwarded via normal IP routing, the packet should
silently dropped

Estrin, et al Informational [Page 17]

RFC 1940 SDRv1 May 1996

5.2.3 Handling an SDRP data packet

An SDRP data packet is indicated by a one in the Data packet/
packet bit in the Flags field in the SDRP Header

An SDRP data packet is forwarded by sending the packet along
source route in the SDRP Header. When the source route is
traversed and the packet has reached the destination domain,
payload may be removed from the data packet and forwarded normally
Further details are described below

5.2.4 Checking the SDRP version

An SDRP packet that has a version number other than 1 should
discarded. If the SDRP packet was a data packet, then a
packet with the Notification Code "Unimplemented SDRP version"
be generated as specified in section 6.

5.2.5 Checking the Source Route Protocol

This document describes Source Route Protocol Type 1. An SDRP
may support multiple Source Route Protocol Types; however an
router is NOT required to support all defined Source Route Types
Any packet that has a Source Route Protocol Type which is
supported should be discarded. If the SDRP packet was a data packet
then a control packet with the Notification Code "
Source Route Protocol Type" should be generated as specified
section 6.

5.2.6 Decrementing and checking Hop

If an SDRP packet is to be forwarded and the Hop Count field is non
zero, the Hop Count field should be decremented. If the
value is zero and the packet was a data packet, then a control
with the Notification Code "Hop Count Exceeded" should be
and sent to the encapsulating router as specified in section 6,
the packet should be discarded. If the resulting value is zero
the packet was a control packet, the packet should be discarded.
payload of the control packet should carry the payload
followed by 64 bits of the payload data of the data packet

5.2.7 Upholding transit

It is not a goal of SDRP to create a security routing system
Therefore, we need to qualify our use of the term "upholding
policy". It is assumed that transit policies have the nature of
"gentleperson's agreement", and are upheld by all the participants
In other words, it is assumed that there will be no

Estrin, et al Informational [Page 18]

RFC 1940 SDRv1 May 1996

attempts to violate transit policies and that parties will rely
auditing and post facto detection of violations. When a
architecture is developed for IP or other network protocols then
may be applied to increase the assurance of transit
enforcement. These issues are beyond the scope of this document

A router may examine any data packet to verify if it complies
local transit policies, as described in section 5.1. If
verification fails, the router generates a control packet. If
verification referred to only the contents of the SDRP header,
the payload field of the control packet should be empty. If
verification referred to both the contents of the SDRP header and
payload header, then the payload field of the control packet
carry the payload header. If the verification referred to
transport protocol header, then the payload field of the
packet should carry the payload header and the transport header

The Notification Code field of the SDRP header in the control
is set to Transit Policy Violation. The procedures for
the rest of the SDRP Header of the control packet are specified
Section 6.

5.2.8 Partially traversed source

If a router receives an SDRP packet with a partially traversed
route, it extracts the next hop of the source route from the
Route field. The router locates the high-order byte of
appropriate hop by using the Next Hop Pointer field as a 32 bit
offset relative to the start of the Source Route field. The next
is always four octets long. The following procedure is used
interpret the next hop

Syntactically, each element in the source route appears as an
address. There are three encodings for the next hop

a) The next hop is an address in network 127.0.0.0. In this case
the Loose/Strict Source Route field is set equal to the Loose/
Source Route Change bit. Then the Next Hop Pointer is incremented
the next hop is read from the Source Route field, and these
cases are examined again

b) The next hop is an address in network 128.0.0.0. In this case
the DI of the next domain is extracted from the least significant
octets of the next hop. If the extracted DI is the same as the DI
the local domain, then the Next Hop Pointer is incremented, the
hop is read from the Source Route field, and these three cases
examined again. Otherwise, if the extracted DI is different from
DI of the local domain, the next hop is the extracted DI, and

Estrin, et al Informational [Page 19]

RFC 1940 SDRv1 May 1996

forwarding process may proceed

c) The next hop is any other IP address. If the next hop is equal
any IP address assigned to the local router, the Next Hop Pointer
incremented, the next hop is read from the Source Route field,
these three cases examined again. Otherwise, the next hop is the
address of the next router in the source route and the
process may proceed

The above procedure for interpreting the next hop in the source
finishes when the next hop is either a router other than the
router or an encoded DI that is not the local DI or a
source route

If upon termination of this procedure the source route is
traversed, see section 5.2.9.

5.2.8.1 Finding a route to the next

If the next hop is not a DI, then the destination address in
delivery header is replaced by the next hop address and the
packet can then be forwarded using normal IP forwarding. Otherwise
a DI was extracted from the next hop in the source route, and
following procedure is used to find a route to the next domain

Given the DI of the next domain, the router next consults its D-FIB
If no entry exists in the D-FIB for the next domain, then the
should be discarded. If the packet was a data packet, a
message with Notification Code "No Route Available" should
generated as specified in Section 6. No other actions are necessary

If there is a D-FIB entry, the router next examines the SDRP
to determine if the packet specified a strict source route. If so
and the next domain is not adjacent to the local domain, then
control packet with the Notification Code "Strict Source
Failed" should be generated, as specified in section 6, and
original packet should be discarded. No other actions are necessary

If source route is loose, then BGP or IDRP information must be
to insure that there is no loop in reaching the next hop. If
Next Hop Pointer was incremented when determining the next hop,
the router must select a BGP or IDRP route with a path that
the extracted DI, and the NLRI for this route is copied into
Prefix Length and Prefix fields

Otherwise, the Next Hop Pointer was not incremented, and the
should use the information carried in the Prefix and Prefix Length
an index into its BGP or IDRP routing table. If it finds a

Estrin, et al Informational [Page 20]

RFC 1940 SDRv1 May 1996

route then it must select the corresponding D-FIB entry. If
route was formed locally by aggregation, then the router must
its D-FIB and select any route with a path that includes
extracted DI. The NLRI for this route should be copied into
Prefix Length and Prefix fields

In either case, the D-FIB entry includes the IP address of the
SDRP-speaking router to which the SDRP packet should be routed.
destination address in the delivery header is replaced by
address. The resulting packet can then be forwarded using normal
forwarding

5.2.8.2 Last Hop

A small optimization can be performed if there is only a single DI
IP address in the source route that has not been traversed

In this case, if the next hop in the SDRP route is a DI, that DI
adjacent to the router processing this packet, the route has a
to the destination address in the payload header in its FIB, and
FIB route passes through the adjacent domain, then the source
may be considered completely traversed and processing may proceed
in section 5.2.9.

If the next hop in the SDRP route is an IP address, that IP
is adjacent to the router processing this packet, the router has
route to the destination address in the payload header in its FIB
and this FIB route passes through the adjacent IP address, then
source route may be considered completely traversed and
may proceed as in section 5.2.9.

Since the last hop optimization may only be done if the last hop
directly adjacent, and reachable, it is irrelevant whether the
route specifies that this is a strict source route or a loose
route hop

5.2.9 Completely Traversed source

If the SDRP packet received by a router with a completely-
source route is a control packet and if the Target Router
carries an IP address assigned to the router, then the packet
be processed as specified in Section 7. Otherwise, if the
packet is a control packet, and the packet cannot be forwarded
either SDRP or normal IP forwarding, the packet should be
dropped

The Hop Count field has already been decremented when processing
SDRP header. The Hop Count field should now be copied from the

Estrin, et al Informational [Page 21]

RFC 1940 SDRv1 May 1996

header into the IP TTL field in the payload header. The
payload packet is then forwarded using normal IP forwarding.
there is no FIB entry for the destination, then the packet should
discarded and a control message with Notification Code "No
Available" should be generated as specified in Section 6. If
packet can be forwarded and if the Probe Indication bit is set to
in the SDRP header, then a control message with Notification
"Probe Completed" should be generated as specified in section 6. If
control packet is generated, then it must be sent to
encapsulating router. The payload of the control packet should
the first 64 bits of the SDRP header and the payload header

6. Originating SDRP control

A router sends a control packet in response to either
conditions, or to successful completion of a probe request (
via Probe Indication in the Flags field).

The Data Packet/Control Packet field is set to indicate
Packet. The following fields are copied from the SDRP header of
Data packet that caused the generation of the Control packet

- Loose/Strict Source
- Source Route Protocol
- Source Route
- Source Route Length
- Payload Protocol

A Control packet should not carry a Probe Indication field

A router should never originate a Control packet as the result of
error caused by a control packet

The Target Router is copied from the source IP address of
delivery header of the SDRP Data packet. This causes the
packet to be returned to the encapsulating router

The router generating a control packet checks its FIB for a route
the destination depicted by the Target Router field. If such a
is present, then the value of the Destination Address field in
delivery header is set to the Target Router, the Source Address
in the delivery header is set to the IP address of one of
interfaces attached to the local system, and the packet is
via normal IP forwarding

If the FIB does not have a route to the destination depicted by
Target Router field, the local system constructs the Source
field of the Control packet by reversing the SDRP route carried

Estrin, et al Informational [Page 22]

RFC 1940 SDRv1 May 1996

the Source Route field of the Data packet, sets the value of the
Hop Pointer to the value of the Source Route Length field minus
value of the Next Hop Pointer field of the SDRP data packet
caused generation of the Control Packet. All Loose/Strict
Route change bits in the new source route should be set to 0 (
source route).

The contents of the Payload field depends on the reason
generating a control packet

The resulting packet is then handled via SDRP Forwarding
described in Section 5.2.

7. Processing control

A router participating in SDRP may receive control information in
forms, SDRP control packets from other routers and ICMP messages
routers that do not participate in SDRP, but are involved
forwarding SDRP packets

7.1 Processing SDRP control

Most control packets carry information about some SDRP routes used
the router. To correlate information carried in the SDRP
packet with the SDRP routes used by the router, the router
information carried in the SDRP header of the control packet,
optionally in the SDRP payload of the control packet (if present).

In general, receipt of any SDRP control packet that carries one
the following Notification

- No Route

- Strict Source Route

- Unimplemented SDRP

- Unimplemented Source Route Probe

indicates that the corresponding SDRP route is presently
feasible, and thus should not be used for packet forwarding.
router must mark the affected routes as not feasible, and may
alternate routes if available

The router may at some later point attempt to use an SDRP route
was marked as infeasible. The criteria used for retrying routes
outside the scope of this document and a subject of further study
It need not be standardizes and can be a matter of local control

Estrin, et al Informational [Page 23]

RFC 1940 SDRv1 May 1996

Receipt of an SDRP control packet that carries "Probe Completed
Notification code indicates that the corresponding SDRP route
feasible

Receipt of an SDRP control packet that carries the "Transit
Violation" Notification Code shall be interpreted as follows

- If the control packet carries no payload data then
corresponding SDRP route violates transit policy regardless
the content of the payload packet carried along that route
- If the control packet carries only the payload header,
the corresponding SDRP route violates transit policy due
the content of the payload header
- If the control packet carries the payload header and
transport header, then the corresponding SDRP route
transit policy for the particular combination of payload
transport header contents

If a router receives an SDRP control packet that carries "Hop
Exceeded" Notification Code, the router should use the information
the payload of the Control packet to construct an ICMP Time
Message with code "time to live exceeded in transit" and send
message to the host indicated by the source address in the
Header

7.2 Processing ICMP

To correlate information carried in the ICMP messages with the
routes used by the router, the router uses the portion of the
datagram returned by ICMP. This must contain the Source
Identifier of the SDRP route used by the router

ICMP Destination Unreachable messages with a code
"fragmentation needed and DF set" should be used for SDRP
discovery as described in Section 9.

All other ICMP Unreachable messages indicate that the
route is not feasible

8. Constructing D-FIBs

A BR constructs its D-FIB as a result of participating in either
or IDRP. A BR must advertise a route to destinations within
domain to all of its external peers (BRs in adjacent domains),
BGP or IDRP. In BGP and IDRP, a BR must advertise a route
destinations within its domain to all of its external peers (BRs
adjacent domains).

Estrin, et al Informational [Page 24]

RFC 1940 SDRv1 May 1996

If a BR receives a route to an adjacent domain from a BR in
domain and selects that route as part of its BGP or IDRP
Process, then it must propagate this route (via BGP or IDRP) to
other BRs within its domain. A BR may also propagate such a route
it depicts an autonomous system other than the adjacent domain

Since AS numbers are encoded as network numbers in network 128.0.0.0,
it is possible to also advertise a route to a domain in BGP or IDRP

9. SDRP MTU

To participate in Path MTU Discovery ([6]) a router may
information about the maximum length of the payload packet that
be carried without fragmentation along a particular SDRP route

SDRP provides two complimentary techniques to support MTU Discovery

The first one is passive and is based on the receipt of the
Destination Unreachable messages (as described in Section 7.2).
combining information provided in the ICMP message with
information about the SDRP route the local system can determine
length of a payload packet that would require fragmentation

The second one is active and employs the Probe Indicator bit. If
SDRP data packet that carries the Probe Indicator bit in the
header and Don't Fragment flag in the delivery header triggers
last router on the SDRP route to return an SDRP Control packet (
the Notification Code "Probe Completed"), then the
carried in the payload header of the control packet can be used
determine the length of the payload packet that went through the
route without fragmentation

10.

The authors would like to thank Scott Bradner (Harvard University),
Noel Chiappa (Consultant), Joel Halpern (Newbridge Networks),
Christian Huitema (INRIA), and Curtis Villamizar (ANS) for
comments on various aspects of this document

Security

Security issues are not discussed in this memo

Estrin, et al Informational [Page 25]

RFC 1940 SDRv1 May 1996

Authors'

Deborah
USC/Information Sciences
4676 Admiralty
Marina Del Rey, Ca 90292-6695.

Phone: +1 310 822 1511 x 253
EMail: estrin@isi.

Tony
cisco Systems, Inc
1525 O'Brien
Menlo Park, CA 94025

Phone: +1 415 526 8186
EMail: tli@cisco.

Yakov
Cisco
170 West Tasman
San Jose, CA,

Phone: +1 914 528 0090
Fax: +1 408 526-4952
EMail: yakov@cisco.

Kannan
USC/Information Sciences
4676 Admiralty
Marina Del Rey, Ca 90292-6695.

Phone: +1 310 822 1511 x 402
EMail: kannan@isi.

Daniel
USC/Information Sciences
4676 Admiralty
Marina Del Rey, Ca 90292-6695.

Phone: +1 310 822 1511 x 352
EMail: daniel@isi.

Estrin, et al Informational [Page 26]

RFC 1940 SDRv1 May 1996

[1] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
(BGP-3), RFC 1267, October 1991.

[2] Rekhter, Y., and P. Gross, "Application of the Border
Protocol in the Internet", RFC 1268, October 1991.

[3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1654, July 1994.

[4] Hares, S., "IDRP for IP", IDR Working Group, 1994.
Work in Progress

[5] Postel, J., "Internet Protocol - DARPA Internet
Protocol Specification", STD 5, RFC 791, September 1981.

[6] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.

[7] Reynolds, J., and J. Postel, "ASSIGNED NUMBERS", STD 2,
RFC 1700, October 1994.

Estrin, et al Informational [Page 27]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX