RFC 1940
Source Demand Routing: Packet Format and Forwarding Specification (Version 1)
Part 1 of 6 🎀
Source Demand Routing: Packet Format and Forwarding Specification (Version 1) 🎀
okay bestie, let's get into it. this is RFC 1940, a May 1996 doc from the Network Working Group (Request for Comments: 1940) 💖. Its category is Informational, so it's giving "here's info for the community," not "this is a standard" ✨. The authors are D. Estrin (USC), T. Li (cisco Systems), Y. Rekhter (cisco Systems), K. Varadhan (USC), and D. Zappala (USC) 👑. The title block doesn't list anything it obsoletes or updates.
Status of this Memo ✨
This memo gives information to the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🫶
1. Overview 🌸
so the whole point of SDRP is letting a source pick its own routes 🧭 It's meant to work alongside the route selection that existing routing protocols already do, for both inter-domain and intra-domain routes. This doc calls those source-picked paths "SDRP routes" 💅 It covers the packet format, the forwarding procedure, and how to check whether an SDRP route is actually feasible. What it doesn't cover is routing information distribution and route computation. For now this part can be used with manually configured routes, and the same packet format and processing will still work once dynamic route info distribution and computation methods are ready 🔥
The forwarding protocol here makes minimal assumptions about how the routing info needed to build SDRP routes gets distributed and acquired. Those minimal assumptions are believed to be enough for the existing Internet 🌈 Future parts of SDRP will expand what it can do in this area and others, and they're designed to be largely backward-compatible 🫶
This version sends every packet with the complete SDRP route sitting in the SDRP header. Future versions will handle route setup and other enhancements and optimizations ⭐
2. Model of operations 🧩
picture the Internet as a bunch of routing domains hooked together by shared subnetworks, with Border Routers (BRs) attached to those subnetworks 🍓 A routing domain can have its own subnetworks, routers connecting them, and hosts. This doc assumes there's some kind of routing inside each domain, but it doesn't assume that intra-domain routing is coordinated or even consistent 🙈
For this discussion, a BR belongs to only one domain 💜 When two BRs from different domains are attached to a common subnetwork, they form an inter-domain connection. By definition, packets that cross multiple domains have to go through the BRs of those domains. One physical router can act as multiple BRs for this model 🧚
Two domains are called adjacent if at least one pair of BRs, one in each domain, forms an inter-domain connection 🦋
Every domain gets a globally unique identifier called a Domain Identifier (DI) 💖 All the BRs in a domain need to know the DI assigned to that domain. How the DI space is managed is out of scope for this doc. This doc assumes Autonomous System (AS) numbers get used as DIs ✨ A domain path (or just "path") is a list of DIs, like the ones you'd get from a BGP AS path [1, 2, 3] or an IDRP RD path [4]. A route is the combo of a network address and domain paths 🎀 The network addresses are represented by NLRI (Network Layer Reachability Information), as described in [3] 💅
This doc assumes routing domains are congruent to autonomous systems, so within this doc, "autonomous system" and "routing domain" can be used interchangeably 👑
An application on a source host inside one domain talks to a destination host in another domain 🌈 An intermediate router on the path from source to destination may decide to forward the packet using SDRP. To do that, it encapsulates the entire IP packet from the source host inside an SDRP packet 🫶 The router that does this encapsulation is called the "encapsulating router" 🔥
2.1 SDRP routes 🛤️
a component of an SDRP route is either a DI (AS number) or an IP address 💅 So an SDRP route is a sequence of domains and routers, written out as a sequence of DIs and IP addresses. Basically, an SDRP route is a collection of source routed hops 🧭
Each component of the SDRP route is called a "hop" ✨ The packet goes through each component exactly once 💖 When a router that corresponds to one component gets the packet from the router that corresponds to the previous component, it processes the packet according to the SDRP forwarding rules inside that packet. The next component that router forwards to is called the "next hop," relative to that router and that component of the route 🦋
An SDRP hop can be either a "strict" source routed hop or a "loose" source routed hop 🌸 A strict source route hop works like this: if the next hop is a DI, it refers to an immediately adjacent domain, and the packet gets forwarded directly to a route within that domain. If the next hop is an IP address, it refers to an immediately adjacent router on a common subnetwork. Any other kind of source route hop is a loose source route hop 🍓
A route is a "strict source route" if the current hop being executed is processed as a strict source route hop. Likewise, a route is a "loose source route" if the current hop being executed is processed as a loose source route hop 💜
Each BR takes part in the intra-domain routing protocol(s) (IGPs) of the domain it belongs to 🧠 So a BR can forward a packet to any other BR in its own domain using intra-domain routing procedures. Forwarding a packet between two BRs that form an inter-domain connection needs neither intra-domain nor inter-domain routing procedures, because an inter-domain connection is a common Layer 2 subnetwork 🧚
All routers also take part in the intra-domain routing protocol(s) (IGPs) of the domain they belong to 🌈
SDRP doesn't require every domain to have a common network layer protocol. But all the BRs in the domains along a given SDRP route are required to support a common network layer ✨ This doc specifies SDRP operations for the case where that common network layer protocol is IP ([5]) 🎀
This doc requires all BRs to support IP, but it doesn't stop a BR from also supporting other network layer protocols (for example CLNP, IPX, or AppleTalk) 🫶 If a BR supports multiple network layers, then for this model the BR must maintain multiple Forwarding Information Bases (FIBs), one per network layer 🔥
2.2 SDRP encapsulation 📦
Forwarding an IP packet along an SDRP route is done by encapsulating the entire packet inside an SDRP packet 💅 An SDRP packet is the SDRP header followed by the SDRP data. The SDRP header carries the SDRP route built by the domain that originated the SDRP packet. The SDRP data carries the original packet that the source domain decided to forward via SDRP 👑
An SDRP packet gets carried across domains as the data portion of an IP packet with protocol number 42 🌈
This doc refers to the IP header of a packet that carries an SDRP packet as the delivery IP header (or just the "delivery header") 🦋 It calls the packet carried as SDRP data the payload packet, and the IP header of that payload packet is the payload header 🍓
So an SDRP packet looks like this 👇
+-------------------+--------------+-------------------
| Delivery header | SDRP header | SDRP data
| (IP header) | | (Payload packet)
+-------------------+--------------+--------------------Each SDRP route may have an MTU associated with it. The MTU of an SDRP route is defined as the maximum length of the payload packet that can be carried without fragmenting the SDRP packet 💖 That means the SDRP MTU, as seen by the transport layer and by applications above it, is the actual link MTU minus the lengths of the Delivery and SDRP headers 🧚 MTU discovery procedures are specified in Section 9 ⭐
2.3 D-FIB 🗺️
It's assumed that a BR takes part in either BGP or IDRP. A BR participating in SDRP augments its FIBs with a D-FIB, which contains routes to domains 💜 A route to a domain is a triplet <DI, Next-Hop, NLRI>, where DI is the destination domain, Next-Hop is the IP address of the next-hop BR, and NLRI is the set of reachable destinations within the destination domain ✨ D-FIBs are built from information obtained from BGP, IDRP, or configuration information 🎀
An SDRP packet is forwarded across multiple domains by using the forwarding databases (both FIBs and D-FIBs) that the BRs maintain 🫶
The operational status of SDRP routes is monitored through passive (Error Reporting) and active (Route Probing) mechanisms 🔥 The Error Reporting mechanism gives the originator of the SDRP route a failure notification 💅 The Probing mechanism gives the originator of the SDRP route confirmation that a route is feasible 🌸
3. SDRP Packet format ✨
okay bestie, first things first: the total length of an SDRP packet (header plus data) can be figured out from the info in the delivery IP header 🧚 and the payload length is just the total SDRP length minus the length of the SDRP Header. easy peasy 💅
here's the layout of an SDRP packet, and it's giving main character 🎀
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 live in the very first octet. bit 0 is the most significant bit and bit 7 is the least significant one 🤓
Version (bits 0 through 2)
the first three bits hold the Version field, which is the version number of the protocol. its value 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, it carries control information. 📦
- Loose/Strict Source Route (bit 4): this indicator gets used when making a forwarding decision (see Section 5.2). if this bit is set to 1, the next hop is a Strict Source Route Hop. if it's set to 0, the next hop is a Loose Source Route. 🧭
- Probe Indicator (bit 5): the originator of the route uses this to request verification of the route's feasibility (see Sections 4 and 7.1). if this bit is set to 1, the originator is probing the route. this bit should always be set to 0 for control packets. 🔍
Hop Count (1 octet) ⏳
the Hop Count field carries the maximum number of routers an SDRP data packet may traverse. it gets decremented by 1 each time an SDRP data packet crosses a router that forwards it using SDRP forwarding. once the Hop Count field hits 0, the router should discard the data packet and generate a control packet (see Section 5.2.6). a router that receives a packet with a Hop Count value of 0 should discard the data packet and generate a control packet (see Section 5.2.6). no more laps for you 🙅♀️💀
Source Route Protocol Type (1 octet) 🌸
this field tells you what kind of info shows up in the source route. a value of 1 means the contents of the source route are as described in this document, and it's an Explicit Source Route. a value of 2 means a Route Setup. the syntax for 2 is identical to 1, but it also has extra semantics that are defined in other documents 📚
Payload Protocol Type (1 octet) 🍓
this one says what protocol type the payload is. if the payload is an IP datagram, this field should contain the value 1 ✨
Note that this Payload Protocol Type is not the same as the IP protocol type[5,7]. don't mix them up, bestie 🙈
Source Route Identifier (4 octets) 🔑
the BR that originates the SDRP packet should insert a 32 bit value in this field. it serves as an identifier for the source route. this value only needs to be unique in the context of the originating BR, so no need to stress about global uniqueness 🫶
Target Router (4 octets) 🎯
this field is meaningful only in control packets.
the Target Router field contains one of the IP addresses of the router that originated the SDRP packet that triggered the control packet to be returned. it's like a little reply address 💌
Prefix (4 octets) 🌐
the Prefix field contains an IP address prefix, and only the number of bits specified in the Prefix Length are significant. the Prefix field is used to prevent routing loops when using BGP or IDRP to route to the next AS in a loose source route (see Section 4). loop prevention is literally its whole personality 🔁
Prefix Length (1 octet) 📏
the Prefix Length field tells you the length in bits of the IP address prefix. a length of zero means a prefix that matches all IP addresses 🌈
Notification Code (1 octet) 🚨
this field only means something in control packets. in data packets, it's transmitted as zero and should be ignored on receipt. 🙃
this document defines the following values for the Notification Code:
1- No Route Available2- Strict Source Route Failed3- Transit Policy Violation4- Hop Count Exceeded5- Probe Completed6- Unimplemented SDRP version7- Unimplemented Source Route Protocol Type8- Setup Request Rejected
Source Route Length (1 octet) 📐
the Source Route Length field indicates the length in 32 bit words of the domain level source route carried in the SDRP 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 the packet has to be forwarded on. this offset is relative to the start of the Source Route field. so if the value of the Next Hop Pointer field equals the value of the Source Route Length field, then the entire source route has been completely traversed. all other source routes are said to be incompletely traversed. 🏁
Source Route (variable) 🗺️
the components of the source route are syntactically IP addresses. 🤯
an IP address from network 128.0.0.0 is used to encode a next hop that is a domain. the least significant two octets contain the DI, which is an Internet Autonomous System number 👑
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 encode characteristics of the source route. the least significant 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): this bit reflects a new value of the Loose/Strict Source Route bit in the SDRP header. the value of the Loose/Strict Source Route Change bit gets copied into the Loose/Strict Source Route bit in the SDRP header when a Source Route Change field is encountered in processing an SDRP packet. 🔄
the rest of the Source Route Change field is transmitted as 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. the Payload field forms the data portion of the SDRP packet. in a control packet this field may be empty, or it may carry the payload header of the packet that triggered the control message (see 5.2.5). 💖
note that there is no padding between the Source Route and the Payload, and the Payload may start at any arbitrary octet boundary. no padding, no drama 🙌✨
4. Originating SDRP Data packets ✨
okay bestie, listen up 🎀 this doc assumes that a router which originates SDRP packets is already preconfigured with a set of SDRP routes 🗺️. How those routes get built is totally outside the scope of this document. SDRP packet forwarding can be deployed first without any extra routing protocol support, so it's low-key easy to start with 💅.
So here's the vibe. An application on a source host makes packets that need to reach a given destination. They travel across the Internet by following normal hop-by-hop routing information 🦋. An intermediate router on the path between the source host and the destination host may decide to forward some of these packets via SDRP ✨.
When this router gets an IP datagram, it uses the info in the datagram and its local criteria to figure out whether the datagram should be forwarded along a particular SDRP route. Every set of criteria comes with one or more SDRP routes that should be used for the packets that match 🌸. What the criteria actually are is a local matter, so the router gets to decide 🙈. The only restrictions this document puts on the applicability of SDRP routes are these: an IP datagram that contains a strict source route should not be forwarded along an SDRP route, SDRP encapsulation should never be applied to an SDRP packet, and 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 SDRP route, it builds the SDRP packet by putting the original datagram into the Payload field and constructing the SDRP header based on the selected route 🎁. The Next Hop pointer is set to 0, which is the first entry in the Source Route field of the SDRP packet. The value of the Time To Live field in the payload header should be copied into the Hop Count field of the SDRP header ⏳.
Now the loop drama 🌀 Even if we assume interior routing is loop free, it's possible, either because of the state of inter-domain routing or because of other SDRP routers, that a domain-level source route which doesn't end at the intended destination domain can lead a packet into a routing loop. Originating SDRP routers that want to make sure this doesn't happen should include a final domain-level hop of the destination's domain. So instead of <DI1, DI2>, you specify the SDRP route as <DI1, DI2, DI3> if the destination host is in domain DI3 💖. How you figure out the DI of the destination domain is outside the scope of this document.
Similarly, when SDRP is used for interior routing, the source route might not line up with IGP routing 😬. In that case, one way to prevent a loop is to specify the last hop router's IP address as the last address within the source route. The encapsulating router can do this by specifying the source route to reach destination host IP3 as <IP1, IP2, IP3> instead of <IP1, IP2> 🧚.
The delivery header is where the aesthetic really comes together 🧁 The source address field in the delivery header should contain an IP address of the router. The Don't Fragment flag in the delivery header is copied from the Don't Fragment flag in the payload header. The Type Of Service field in the delivery header is copied from the Type Of Service field in the payload header. If the payload header contains an IP security option, that option is replicated as an option in the delivery header. All other IP options in the payload header must be ignored 🚫.
If the SDRP route that's used was learned from IDRP, then the TOS corresponding to that route is copied into the TOS field in the delivery header 🍓.
Once that's done, the resulting SDRP packet gets forwarded as described in Section 5.2.2 🚀.
Now the MTU situation, which is kind of a big deal 😭 If the encapsulating router decides to forward a datagram along a particular SDRP route that has an MTU smaller than the length of the datagram, then, if the payload header has the Don't Fragment flag set to 1, the router should generate an ICMP Destination Unreachable message with a code meaning "fragmentation needed and DF set", in accordance with [6]. The ICMP message must be sent to the original source host. Then the router should discard the original datagram.
If a router has learned an MTU for a particular SDRP route, either via ICMP messages or via configuration information, and it determines that an SDRP packet must be fragmented before transmission, then it first calculates the effective MTU seen by the payload packet. If the effective MTU is greater than or equal to 512 bytes, the router SHOULD first fragment the payload packet using normal IP fragmentation. SDRP packets are then constructed for each fragment, as described above. Otherwise, the router should first form the SDRP packet and then fragment it 🧩.
Last but not least, a router may use locally originated SDRP packets to verify the feasibility of its SDRP routes 🔍. To do this, the router sets the value of the Probe Indicator field in the SDRP packet to 1. Receipt of an SDRP control packet by the originating router with the "Probe Completed" Notification Code (see Section 7.1) indicates the feasibility of the SDRP route ✅. A persistent lack of SDRP control packets with the "Probe Completed" Notification Code should be used as an indication that the associated SDRP route is not feasible 🥀.
5. Processing SDRP packets 💌
Let's talk about what happens when packets land at a router 👀 We say that a router receives an SDRP packet if the destination address field in the delivery header of the packet arriving at the router contains one of the IP addresses of the router.
When a router receives an SDRP packet, it extracts the Source Route Protocol field from the SDRP header 📦.
5.1 Supporting Transit Policies
A router may be able to verify that a packet it's given to forward doesn't violate any of the transit policies of the domain the router belongs to 🛂. Specific verification mechanisms are a local matter for the router and are outside the scope of this document.
The restriction on those verification mechanisms is that they may take into account only the contents of the SDRP header, the payload header, and the transport protocol header of the payload packet 🔒.
With SDRP, a domain may enforce its transit policies by applying filters based on the information present in the IP header 🎀. For example, a router may initially carefully filter all SDRP traffic from all possible sources. A filter that allows certain SDRP traffic from selected sources to pass through the router could then be installed dynamically to pass similar types of traffic. So by caching the appropriate filtering information, a transit domain can efficiently support transit policies 💅. Other mechanisms for supporting transit policy and implementation techniques are not precluded by this document.
If the router detects that an SDRP packet violates a domain's transit policy, it sends back an SDRP control packet to the 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 policy violation, then the router attempts to forward it as specified in Section 5.2 🚀.
5.2 Forwarding SDRP packets
Procedures for forwarding an SDRP packet depend on:
- a) whether the router has the routing information needed to forward the packet;
- b) whether the SDRP route has been completely traversed;
- c) whether the SDRP route is strict or loose, and
- d) whether the packet is a data or control packet.
When forwarding an SDRP packet (either data or control), a router should not modify the following fields in the delivery header:
- a) Source Address
- b) Don't Fragment flag
Route Setup drama, bestie 😤 If the Source Route Protocol Type of a packet indicates a Route Setup and the router does not or cannot support setup, the router MAY send the encapsulating router a control packet with a Notification Code of Setup Request Rejected. It MAY then modify the data packet so that the Source Route Protocol Type is Explicit Source Route and the Probe Indicator bit is 0, and then forward the packet as described below. The router MAY send notification of a failed setup request only periodically. Alternately, a router MAY silently drop the Route Setup packet 🌙.
5.2.1 Forwarding algorithm pseudo-code ✨
okay so this is the forwarding algorithm pseudo-code 💅 it's basically the whole SDRP forwarding playbook in one spot, and the text after it has the deets 🎀 quick decoder ring first:
LOCAL_DIis the DI of the domain your local system is in 🏠NEXT_HOPis the next hop in the source route, as long as the source route hasn't been fully traversed yet 🛣️NEXT_DIis the DI portion ofNEXT_HOPifNEXT_HOPis from network128.0.0.0🌸NEXT_ROUTERis the IP address of the next router, if the packet is going to be forwarded using SDRP 🧚
NEXT_DI is adjacent if the local domain is adjacent to the domain whose DI is NEXT_DI. NEXT_ROUTER is adjacent if it's the IP address of a router that shares a link with the current router 🔗 And "normal IP forwarding" just means forwarding you can pull off using FIBs built via BGP, IDRP, or one or more IGPs 💖
the pseudo-code has a lot of spots where control messages get sent, and all of them go to the encapsulating router, which is whoever's address is in the source address of the delivery header 📮 this part is so important: every intermediate SDRP router that processes an SDRP packet has to leave that source address of the delivery header untouched 🙈 because that's the address the control messages need to go back to, no cap.
if the packet is a control packet begin
if the Target Router equals an address assigned to the
local router begin
remove the delivery header
process information carried in the control packet
return
end if
if the packet can be forwarded using normal IP forwarding begin
set Next Hop Pointer to Source Route Length
forward the packet using normal IP forwarding
return
end if
end if
if the version field is not 1 begin
if the packet is a data packet begin
generate a control packet with "Unimplemented SDRP version"
end if
discard the packet
return
end if
if the source route protocol type is not 1 begin
if the packet is a data packet begin
generate a control packet with "Unimplemented source route
protocol type"
end if
discard the packet
return
end if
if the Hop Count field is greater than 0 begin
decrement the Hop Count field
end if
if the Hop Count field is 0 begin
if the packet is a data packet begin
generate a control packet with "Hop Count Exceeded"
end if
discard the packet
return
end if
if the packet is a data packet begin
if the packet violates transit policy begin
generate a control packet with "Transit Policy Violation"
discard the data packet
return
end if
end if
set mode to NONE
set advanced to FALSE
if Next Hop Ptr does not equal Source Route Length begin
set NEXT_HOP to the next hop in the source route
while mode equals NONE begin
if NEXT_HOP is from network 127.0.0.0 begin
set the Loose/Strict Source Route bit equal to
the Loose/Strict Source Route Change bit
else if NEXT_HOP is from network 128.0.0.0 begin
set NEXT_DI to the least significant two octets of NEXT_HOP
if NEXT_DI is not equal to LOCAL_DI begin
set mode to DOMAIN
end if
else if NEXT_HOP does not equal an address assigned to the
local router begin
set mode to LOCAL
end if
if mode equals NONE begin
set advanced to TRUE
increment the Next Hop Pointer field
if Next Hop Pointer equals Source Route Length begin
set mode to COMPLETE
else
set NEXT_HOP to the next hop in the source route
end if
end if
end while
end if
if mode equals DOMAIN begin
set route to NONE
if the source route is loose begin
if not advanced begin
find the route, if any, based on Prefix and Prefix Length
if the route is an aggregate formed at the local router begin
set route to NONE
end if
end if
if route equals NONE begin
select a BGP or IDRP route, if any, with a path that includes
NEXT_DI and is not an aggregate formed at the local router
if route equals NONE begin
if the packet is a data packet begin
generate a control packet with "No Route Available"
end if
discard the packet
return
end if
copy the NLRI from the route to the Prefix and Prefix Length
end if
if the route is an IDRP route begin
set appropriate TOS in delivery header
end if
set NEXT_ROUTER from the route
else
set NEXT_ROUTER from the routing information for NEXT_DI
using the D-FIB
if route equals NONE begin
if the packet is a data packet begin
generate a control packet with "No Route Available"
end if
discard the packet
return
end if
if NEXT_DI is not adjacent begin
if the packet is a data packet begin
generate a control packet with "Strict Source Route Failed"
end if
discard the packet
return
end if
end if
end if
end if
if mode equals LOCAL begin
set NEXT_ROUTER equal to NEXT_HOP
if the source route is strict and NEXT_ROUTER is not
adjacent begin
if the packet is a data packet begin
generate a control packet with "Strict Source Route Failed"
end if
discard the packet
return
end if
end if
if mode equals LOCAL or mode equals DOMAIN begin
set the destination address of the delivery header equal
to NEXT_ROUTER
checksum the delivery header
route packet to NEXT_ROUTER using normal IP forwarding
return
end if
if the packet is a control packet begin
discard the packet
end if
remove the delivery header and the SDRP Header
if there is no normal IP route to the payload destination begin
generate a control packet with "No Route Available"
discard the data packet
return
end if
forward the payload using normal IP forwarding
if the probe bit is set begin
generate a control packet with "Probe Completed"
end if5.2.2 Handling an SDRP control packet. 🦋
okay control packets have their own little vibe 🥰 you can tell one is a control packet because the Data packet/Control packet bit in the Flags field of the SDRP Header is 0 🚩
if the Target Router field has an IP address that belongs to the router that got this SDRP packet, then the router should use the info in the Notification Code field, the Source Route Identifier field, and the Payload field to update the status of its SDRP routes 🔄 the full procedures are in Section 7, so go check those out 📚
if the Target Router is somebody else, the router checks whether it can forward the packet to that router using the routing info in its local FIB 🗺️ if it can, the local system sets the destination address of the delivery header to whatever's in the Target Router field and hands the packet off for normal IP forwarding 🚀 if normal IP forwarding isn't possible, the packet may be forwarded the same way an SDRP data packet is (more on that below), but with a few plot twists:
- Control packets are not subject to transit policies. 🙅♀️
- In no case should a control packet be generated in response to an error caused by a control packet. 🛑
- If the source route is completely traversed and the packet still cannot be forwarded via normal IP routing, the packet should be silently dropped. 🤫
5.2.3 Handling an SDRP data packet. 🌈
data packets are the main characters 👑 you know it's a data packet when the Data packet/Control packet bit in the Flags field of the SDRP Header is a one ✨
these get forwarded by sending them along the source route in the SDRP Header 🗺️ once the source route is fully traversed and the packet has made it to the destination domain, the payload can be taken out of the data packet and forwarded normally 🎀 the deets are coming up below 👀
5.2.4 Checking the SDRP version number
first thing's first, an SDRP packet with a version number other than 1 should be discarded 🗑️ and if it was a data packet, a control packet with the Notification Code Unimplemented SDRP version should be generated, as specified in section 6 📮
5.2.5 Checking the Source Route Protocol Type
this document is all about Source Route Protocol Type 1 💜 an SDRP router can support a bunch of Source Route Protocol Types if it wants to, but an SDRP router is NOT required to support all defined Source Route Types 🫶 any packet with a Source Route Protocol Type that isn't supported should be discarded 🙃 and if it was a data packet, a control packet with the Notification Code Unimplemented Source Route Protocol Type should be generated, as specified in section 6 📬
5.2.6 Decrementing and checking Hop Count
when an SDRP packet is getting forwarded and its Hop Count field is non-zero, the Hop Count field should be decremented ⏬ if that lands on zero and the packet was a data packet, a control packet with the Notification Code Hop Count Exceeded gets generated and sent to the encapsulating router (see section 6), and then the packet gets discarded 💀 if it lands on zero and the packet was a control packet, the packet just gets discarded 🫠 and the payload of that control packet should carry the payload header, followed by 64 bits of the payload data from the data packet 🧚♀️
5.2.7 Upholding transit policies
ngl this part is kinda real 🥺 SDRP isn't trying to be a security routing system, so we have to qualify what "upholding transit policy" even means 💖 transit policies are basically a "gentleperson's agreement" that everybody upholds 🤝 the assumption is that nobody's going to maliciously violate them, and that parties will rely on auditing and after-the-fact detection of violations 🕵️♀️ when a security architecture gets developed for IP or other network protocols, it may be used to boost the assurance of transit policy enforcement, but all that is beyond the scope of this document 🌸
a router may examine any data packet to check whether it complies with local transit policies, as described in section 5.1 🔍 if the check fails, the router generates a control packet 🚨 if the check only looked at the contents of the SDRP header, the payload field of that control packet should be empty 🫧 if it looked at both the SDRP header and the payload header, the payload field should carry the payload header 📦 and if it looked at the transport protocol header, the payload field should carry the payload header and the transport header 🎁
the Notification Code field of the SDRP header in that control packet gets set to Transit Policy Violation 💅 and the procedures for building the rest of the SDRP Header of the control packet are in Section 6 📖
5.2.8. Partially traversed source routes ✨
Okay bestie, so if a router gets an SDRP packet with a source route that's only partly traversed 🌸, it pulls out the next hop from the Source Route field. To find the high-order byte of that hop, it uses the Next Hop Pointer field as a 32 bit word offset counted from the start of the Source Route field. The next hop is always four octets long, and there's a whole little procedure for figuring out what it means 💅
Syntactically, every element in the source route looks like an IP address, but there are three different encodings hiding in there 🦋
a) Ooh, first one! If the next hop is an address in network 127.0.0.0, then the Loose/Strict Source Route field gets set equal to the Loose/Strict Source Route Change bit. After that, the Next Hop Pointer goes up by one, the next hop gets read from the Source Route field, and then you check all three cases again 🔁
b) If the next hop is an address in network 128.0.0.0, then the DI of the next domain gets pulled out of the least significant two octets of the next hop. If that extracted DI is the same as the DI of the local domain, the Next Hop Pointer is incremented, the next hop is read from the Source Route field, and you run through these three cases again 🌈. Otherwise, if the extracted DI is different from the DI of the local domain, the next hop is the extracted DI, and the forwarding process MAY proceed.
c) The next hop is any other IP address. If it's equal to any IP address assigned to the local router, the Next Hop Pointer is incremented, the next hop is read from the Source Route field, and these three cases get examined again. Otherwise, the next hop is the IP address of the next router in the source route, and the forwarding process MAY proceed ✨
This procedure for interpreting the next hop wraps up when the next hop is either a router other than the local router, an encoded DI that isn't the local DI, or a completed source route. Periodt 🫶
If upon termination of this procedure the source route is completely traversed, see section 5.2.9.
5.2.8.1. Finding a route to the next hop 🦋
If the next hop is not a DI, then the destination address in the delivery header gets replaced by the next hop address, and the resulting packet can then be forwarded using normal IP forwarding. Otherwise, a DI was extracted from the next hop in the source route, and here's how you find a route to the next domain 🗺
Given the DI of the next domain, the router next consults its D-FIB. If there's no entry in the D-FIB for the next domain, then the packet SHOULD be discarded. If the packet was a data packet, a control message with Notification Code "No Route Available" SHOULD be generated as specified in Section 6. No other actions are necessary 💀
If there is a D-FIB entry, the router next examines the SDRP header to see whether the packet specified a strict source route. If it did, and the next domain is not adjacent to the local domain, then a control packet with the Notification Code "Strict Source Route Failed" SHOULD be generated, as specified in section 6, and the original packet SHOULD be discarded. No other actions are necessary 🙈
If the source route is loose, then BGP or IDRP information MUST be used to insure that there is no loop in reaching the next hop. If the Next Hop Pointer was incremented when determining the next hop, then the router MUST select a BGP or IDRP route with a path that includes the extracted DI, and the NLRI for this route is copied into the Prefix Length and Prefix fields 💜
Otherwise, the Next Hop Pointer was not incremented, and the router SHOULD use the information carried in the Prefix and Prefix Length as an index into its BGP or IDRP routing table. If it finds a matching route, then it MUST select the corresponding D-FIB entry. If the route was formed locally by aggregation, then the router MUST consult its D-FIB and select any route with a path that includes the extracted DI. The NLRI for this route SHOULD be copied into the Prefix Length and Prefix fields 🍓
In either case, the D-FIB entry includes the IP address of the next SDRP-speaking router to which the SDRP packet SHOULD be routed. The destination address in the delivery header gets replaced by this address, and then the resulting packet can be forwarded using normal IP forwarding. Iconic 👑
5.2.8.2. Last Hop Optimization ✨
A small optimization can be performed if there is only a single DI or IP address in the source route that has not been traversed. Lowkey a glow-up for the last hop 🌸
In this case, if the next hop in the SDRP route is a DI, that DI is adjacent to the router processing this packet, the route has a route to the destination address in the payload header in its FIB, and this FIB route passes through the adjacent domain, then the source route MAY be considered completely traversed, and processing MAY proceed as in section 5.2.9.
If the next hop in the SDRP route is an IP address, that IP address is adjacent to the router processing this packet, the router has a route to the destination address in the payload header in its FIB, and this FIB route passes through the adjacent IP address, then the source route MAY be considered completely traversed, and processing MAY proceed as in section 5.2.9 🧚
Since the last hop optimization MAY only be done if the last hop is directly adjacent and reachable, it's irrelevant whether the SDRP route specifies that this is a strict source route or a loose source route hop. Main character energy, no notes 💅
5.2.9. Completely Traversed source routes 🎀
If the SDRP packet received by a router with a completely-traversed source route is a control packet, and if the Target Router field carries an IP address assigned to the router, then the packet SHOULD be processed as specified in Section 7. Otherwise, if the SDRP packet is a control packet, and the packet cannot be forwarded via either SDRP or normal IP forwarding, the packet SHOULD be silently dropped 🥺
The Hop Count field has already been decremented when processing the SDRP header, so don't decrement it again 🙈
The Hop Count field SHOULD now be copied from the SDRP header into the IP TTL field in the payload header. The resulting payload packet is then forwarded using normal IP forwarding. If there's no FIB entry for the destination, then the packet SHOULD be discarded, and a control message with Notification Code "No Route Available" SHOULD be generated as specified in Section 6. If the packet can be forwarded, and the Probe Indication bit is set to one in the SDRP header, then a control message with Notification Code "Probe Completed" SHOULD be generated as specified in section 6 🎉
If a control packet is generated, then it MUST be sent to the encapsulating router. The payload of the control packet SHOULD carry the first 64 bits of the SDRP header and the payload header. Bestie, it's all about that return trip 🦋
6. Originating SDRP control packets 🧚
A router sends a control packet in response to either error conditions, or to successful completion of a probe request (indicated via Probe Indication in the Flags field) 💌
The Data Packet/Control Packet field is set to indicate Control Packet. The following fields are copied from the SDRP header of the Data packet that caused the generation of the Control packet:
Loose/Strict Source RouteSource Route Protocol TypeSource Route IdentifierSource Route LengthfieldPayload Protocol Type
A Control packet SHOULD NOT carry a Probe Indication field 🙅♀️
A router SHOULD never originate a Control packet as the result of an error caused by a control packet. Never a control packet on a control packet, that's the rule 🫶
The Target Router is copied from the source IP address of the delivery header of the SDRP Data packet. This causes the control packet to be returned to the encapsulating router 🔙
The router generating a control packet checks its FIB for a route to the destination depicted by the Target Router field. If such a route is present, then the value of the Destination Address field in the delivery header is set to the Target Router, the Source Address field in the delivery header is set to the IP address of one of the interfaces attached to the local system, and the packet is forwarded via normal IP forwarding 💖
If the FIB does not have a route to the destination depicted by the Target Router field, the local system constructs the Source Route field of the Control packet by reversing the SDRP route carried in the Source Route field of the Data packet. It sets the value of the Next Hop Pointer to the value of the Source Route Length field minus the value of the Next Hop Pointer field of the SDRP data packet that caused generation of the Control Packet. All Loose/Strict Source Route change bits in the new source route SHOULD be set to 0 (loose source route) 🌈
The contents of the Payload field depend on the reason for generating a control packet ✨
The resulting packet is then handled via SDRP Forwarding procedures described in Section 5.2 🦋
7. Processing control information 🌈
A router participating in SDRP MAY receive control information in two forms: SDRP control packets from other routers, and ICMP messages from routers that do not participate in SDRP but are involved in forwarding SDRP packets 💜
7.1. Processing SDRP control packets 📬
okay so most control packets carry info about some of the SDRP routes the router is using 💅 To match what's in an SDRP control packet with the SDRP routes the router actually uses, the router looks at the SDRP header of the control packet and, optionally, the SDRP payload of that control packet (if there is one) ✨
In general, if a control packet carries any of these Notification codes:
No Route AvailableStrict Source Route FailedUnimplemented SDRP VersionUnimplemented Source Route Probe Type
that means the matching SDRP route is not feasible right now 🙈 so it should not be used for packet forwarding. The router must mark the affected routes as not feasible, and may use alternate routes if available 🦋
The router may come back later and try an SDRP route that got marked as infeasible 🔄 How it decides when to retry is outside the scope of this document and is a subject of further study. It need not be standardized and can be a matter of local control 🧚
Receipt of an SDRP control packet that carries Probe Completed means the matching SDRP route is feasible 🌸
Receipt of an SDRP control packet that carries the "Transit Policy Violation" Notification Code shall be interpreted as follows:
- If the control packet carries no payload data, then the matching SDRP route violates transit policy no matter what the payload packet sent along that route contains 💀
- If the control packet carries only the payload header, then the matching SDRP route violates transit policy because of the content of the payload header 🫶
- If the control packet carries the payload header and the transport header, then the matching SDRP route violates transit policy for that particular combination of payload and transport header contents 👑
⚠️ Reminder: all three cases above are about which route is in violation, so read the payload and headers carefully before you decide anything, bestie.
If a router receives an SDRP control packet that carries the "Hop Count Exceeded" Notification Code, the router should use the information in the payload of the control packet to build an ICMP Time Exceeded Message with code time to live exceeded in transit, then send that message to the host named by the source address in the Payload Header 😭🎀
7.2. Processing ICMP messages 🛰️
To match up the information in ICMP messages with the SDRP routes the router uses, the router looks at the portion of the SDRP datagram that ICMP returns to it. This must contain the Source Route Identifier of the SDRP route the router used 🔍
ICMP Destination Unreachable messages with a code meaning "fragmentation needed and DF set" should be used for SDRP MTU discovery, as described in Section 9 🌈
All other ICMP Unreachable messages indicate that the associated route is not feasible 🙅♀️
8. Constructing D-FIBs 🏗️
A BR builds its D-FIB as a result of taking part in either BGP or IDRP. A BR must advertise a route to destinations within its domain to all of its external peers (BRs in adjacent domains), via BGP or IDRP. In BGP and IDRP, a BR must advertise a route to destinations within its domain to all of its external peers (BRs in adjacent domains) 💖
If a BR gets a route to an adjacent domain from a BR in that domain and selects that route as part of its BGP or IDRP Decision Process, then it must propagate this route (via BGP or IDRP) to all other BRs within its domain. A BR may also propagate such a route if 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 Discovery 📏
To participate in Path MTU Discovery ([6]), a router may maintain information about the maximum length of the payload packet that can be carried without fragmentation along a particular SDRP route 🦄
SDRP provides two complementary techniques to support MTU Discovery 🎀
The first one is passive. It is based on the receipt of the ICMP Destination Unreachable messages (as described in Section 7.2). By combining the information in the ICMP message with local information about the SDRP route, the local system can work out the length of a payload packet that would need fragmentation 💅
The second one is active, and it uses the Probe Indicator bit. If an SDRP data packet carries the Probe Indicator bit in the SDRP header and the Don't Fragment flag in the delivery header, and that triggers the last router on the SDRP route to send back an SDRP Control packet (with the Notification Code "Probe Completed"), then the information carried in the payload header of the control packet can be used to determine the length of the payload packet that went through the SDRP route without fragmentation 🔥
10. Acknowledgments 🫶
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 their comments on various aspects of this document 💜
Security Considerations 🔒😱
Security issues are not discussed in this memo.
Authors' Addresses 🖋️
Deborah Estrin
USC/Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, Ca 90292-6695.
Phone: +1 310 822 1511 x 253
EMail: estrin@isi.edu
Tony Li
cisco Systems, Inc.
1525 O'Brien Drive
Menlo Park, CA 94025
Phone: +1 415 526 8186
EMail: tli@cisco.com
Yakov Rekhter
Cisco systems
170 West Tasman Drive
San Jose, CA, USA
Phone: +1 914 528 0090
Fax: +1 408 526-4952
EMail: yakov@cisco.com
Kannan Varadhan
USC/Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, Ca 90292-6695.
Phone: +1 310 822 1511 x 402
EMail: kannan@isi.edu
Daniel Zappala
USC/Information Sciences Institute
4676 Admiralty Way
Marina Del Rey, Ca 90292-6695.
Phone: +1 310 822 1511 x 352
EMail: daniel@isi.eduReferences 📚
[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 Gateway
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 Program
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.📦 where this page comes from
- ietf: rfc1940 1996-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms