Network Working Group D. Estrin
`Request for Comments: 1940 USC
`Category: Informational T. Li
` Y. Rekhter
` cisco Systems
` K. Varadhan
` D. Zappala
` USC
` May 1996
`
` Source Demand Routing:
` Packet Format and Forwarding Specification (Version 1).
`
`Status of this Memo
`
` This memo provides information for the Internet community. This memo
` does not specify an Internet standard of any kind. Distribution of
` this memo is unlimited.
`
`1. Overview
`
` The purpose of SDRP is to support source-initiated selection of
` routes to complement the route selection provided by existing routing
` protocols for both inter-domain and intra-domain routes. This
` document refers to such source-initiated routes as "SDRP routes".
` This document describes the packet format and forwarding procedure
` for SDRP. It also describes procedures for ascertaining feasibility
` of SDRP routes. Other components not described here are routing
` information distribution and route computation. This portion of the
` protocol may initially be used with manually configured routes. The
` same packet format and processing will be usable with dynamic route
` information distribution and computation methods under development.
`
` The packet forwarding protocol specified here makes minimal
` assumptions about the distribution and acquisition of routing
` information needed to construct the SDRP routes. These minimal
` assumptions are believed to be sufficient for the existing Internet.
` Future components of the SDRP protocol will extend capabilities in
` this area and others in a largely backward-compatible manner.
`
` This version of the packet forwarding protocol sends all packets with
` the complete SDRP route in the SDRP header. Future versions will
` address route setup and other enhancements and optimizations.
`
`Estrin, et al Informational [Page 1]
`
`FatPipe Exhibit 2024, pg. 1
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
`2. Model of operations
`
` An Internet can be viewed as a collection of routing domains
` interconnected by means of common subnetworks, and Border Routers
` (BRs) attached to these subnetworks. A routing domain itself may be
` composed of further subnetworks, routers interconnecting these
` subnetworks, and hosts. This document assumes that there is some
` type of routing present within the routing domain, but it does not
` assume that this intra-domain routing is coordinated or even
` consistent.
`
` For the purposes of this discussion, a BR belongs to only one domain.
` A pair of BRs, each belonging to a different domain, but attached to
` a common subnetwork, form an inter-domain connection. By definition,
` packets that traverse multiple domains must traverse BRs of these
` domains. Note that a single physical router may act as multiple BRs
` for the purposes of this model.
`
` A pair of domains is said to be adjacent if there is at least one
` pair of BRs, one in each domain, that form an inter-domain
` connection.
`
` Each domain has a globally unique identifier, called a Domain
` Identifier (DI). All the BRs within a domain need to know the DI
` assigned to the domain. Management of the DI space is outside the
` scope of this document. This document assumes that Autonomous System
` (AS) numbers are used as DIs. A domain path (or simply path) refers
` to a list of DIs such as might be taken from a BGP AS path [1, 2, 3]
` or an IDRP RD path [4]. We refer to a route as the combination of a
` network address and domain paths. The network addresses are
` represented by NLRI (Network Layer Reachability Information) as
` described in [3].
`
` This document assumes that the routing domains are congruent to the
` autonomous systems. Thus, within the content of this document, the
` terms autonomous system and routing domain can be used
` interchangeably.
`
` An application residing at a source host inside a domain,
` communicates with a destination host at another domain. An
` intermediate router in the path from the source host to the
` destination host may decide to forward the packet using SDRP. It can
` do this by encapsulating the entire IP packet from the source host in
` an SDRP packet. The router that does this encapsulation is called
` the "encapsulating router."
`
`Estrin, et al Informational [Page 2]
`
`FatPipe Exhibit 2024, pg. 2
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
` 2.1 SDRP routes
`
` A component in an SDRP route is either a DI (AS number) or an IP
` address. Thus, an SDRP route is defined as a sequence of domains
` and routers, syntactically expressed as a sequence of DIs and IP
` addresses. Thus an SDRP route is a collection of source routed
` hops.
`
` Each component of the SDRP route is called a "hop." The packet
` traverses each component of the SDRP route exactly once. When a
` router corresponding to one of the components of the SDRP route
` receives the packet from a router corresponding to the previous
` component of the SDRP route, the router will process the packet
` according to the SDRP forwarding rules in this packet. The next
` component of the SDRP route that this router will forward the
` packet to, is called the "next hop," with respect to this router
` and component of the SDRP route.
`
` An SDRP hop can either be a "strict" source routed hop, or a
` "loose" source routed hop. A strict source route hop is one in
` which, if the next hop specified is a DI, refers to an immediately
` adjacent domain, and the packet will be forwarded directly to a
` route within the domain; if the next hop specified is an IP
` address, refers to an immediately adjacent router on a common
` subnetwork. Any other kind of a 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.
`
` It is assumed that each BR participates in the intra-domain
` 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 domain
` using intra-domain routing procedures. Forwarding a packet
` between two BRs that form an inter-domain connection requires
` neither intra-domain nor the inter-domain routing procedures (an
` 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 they
` belong.
`
` While SDRP does not require that all domains have a common network
` layer protocol, all the BRs in the domains along a given SDRP
` route are required to support a common network layer. This
` document specifies SDRP operations when that common network layer
`
`Estrin, et al Informational [Page 3]
`
`FatPipe Exhibit 2024, pg. 3
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
` protocol is IP ([5]).
`
` While this document requires all the BRs to support IP, the
` document does not preclude a BR from additionally supporting other
` network layer protocols as well (e.g., CLNP, IPX, AppleTalk). If
` a BR supports multiple network layers, then for the purposes of
` 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 accomplished by
` encapsulating the entire packet in an SDRP packet. An SDRP packet
` consists of the SDRP header followed by the SDRP data. The SDRP
` header carries the SDRP route constructed 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 is carried across domains as the data portion of an
` IP packet with protocol number 42.
`
` This document refers to the IP header of a packet that carries an
` SDRP packet as the delivery IP header (or just the delivery
` header). This document refers to the packet carried as SDRP data
` s the payload packet, and the IP header of the payload packet is
` the payload header.
`
` Thus, an SDRP Packet can be represented as follows:
`
` +-------------------+--------------+-------------------
` | Delivery header | SDRP header | SDRP data
` | (IP header) | | (Payload packet)
` +-------------------+--------------+--------------------
`
` Each SDRP route may have an MTU associated with it. An MTU of an
` SDRP route is defined as the maximum length of the payload packet
` that can be carried without fragmentation of an SDRP packet. This
` means that the SDRP MTU as seen by the transport layer and
` applications above the transport layer is the actual link MTU less
` the length of the Delivery and SDRP headers. Procedures for MTU
` discovery are specified in Section 9.
`
` 2.3 D-FIB
`
` It is assumed that a BR participates in either BGP or IDRP. A BR
` participating in SDRP augments its FIBs with a D-FIB that contains
` routes to domains. A route to a domain is a triplet <DI, Next-
` Hop, NLRI>, where DI depicts a destination domain, Next-Hop
`
`Estrin, et al Informational [Page 4]
`
`FatPipe Exhibit 2024, pg. 4
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
` depicts the IP address of the next-hop BR, and NLRI depicts the
` set of reachable destinations within the destination domain. D-
` FIBs are constructed based on the information obtained from either
` BGP, IDRP, or configuration information.
`
` An SDRP packet is forwarded across multiple domains by utilizing
` the forwarding databases (both FIBs and D-FIBs) maintained by the
` BRs.
`
` The operational status of SDRP routes is monitored via passive
` (Error Reporting) and active (Route Probing) mechanisms. The Error
` Reporting mechanism provides the originator of the SDRP route with
` a failure notification. The Probing mechanism provides the
` originator of the SDRP route with confirmation of a route’s
` feasibility.
`
`3. SDRP Packet format
`
` The total length of an SDRP packet (header plus data) can be
` determined from the information carried in the delivery IP header.
` The length of the payload packet can be determined from the total
` 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 first
` octet. Bit 0 is the most significant bit, bit 7 is the least
` significant bit.
`
`Estrin, et al Informational [Page 5]
`
`FatPipe Exhibit 2024, pg. 5
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
` Version (bits 0 through 2)
`
` The first three bits contain the Version field indicating
` the version number of the protocol. The value of this field
` 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 when
` making a forwarding decision (see Section 5.2). If this
` bit is set to 1, it indicates that the next hop is a
` Strict Source Route Hop. If this bit is set to 0, it
` indicates that the next hop is a Loose Source Route.
`
` Probe Indicator (bit 5)
`
` The Probe Indicator is used by the originator of the
` route to request verification of the route’s feasibility
` (see Sections 4 and 7.1). If this bit is set to 1, it
` indicates that 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 is decremented by 1 as an
` SDRP data packet traverses a router which forwards the packet
` using SDRP forwarding. Once the Hop Count field reaches the
` value of 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).
`
` Source Route Protocol Type (1 octet)
`
` The Source Route Protocol Type fields indicates the type of
` information that appears in the source route. The value 1 in
` this field indicates that the contents of the source route are
` as described in this document and indicates an Explicit Source
`
`Estrin, et al Informational [Page 6]
`
`FatPipe Exhibit 2024, pg. 6
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
` Route. The value 2 in this field indicates a Route Setup. The
` syntax of the source route for this value is identical to a
` value of 1, but also has additional semantics which are defined
` in other documents.
`
` Payload Protocol Type (1 octet)
`
` The Payload Protocol Type field indicates the protocol type of
` the payload. If the payload is an IP datagram, then this field
` should contain the value 1.
`
` Note that this Payload Protocol Type is not the same as the IP
` protocol type[5,7].
`
` Source Route Identifier (4 octets)
`
` The BR that originates the SDRP packet should insert a 32 bit
` value in this field which will serve as an identifier for the
` source route. This value needs to be unique only in the
` 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 the
` router that originated the SDRP packet that triggered the
` control packet to be returned.
`
` Prefix (4 octets)
`
` The Prefix field contains an IP address prefix. 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).
`
` Prefix Length (1 octet)
`
` The Prefix Length field indicates the length in bits of the IP
` address prefix. A length of zero indicates a prefix that
` matches all IP addresses.
`
` Notification Code (1 octet)
`
` This field is only meaningful in control packets. In
` data packets, this field is transmitted as zero, and
` should be ignored on receipt.
`
`Estrin, et al Informational [Page 7]
`
`FatPipe Exhibit 2024, pg. 7
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
` This document defines the following values for the
` Notification Code:
`
` 1 - No Route Available
`
` 2 - Strict Source Route Failed
`
` 3 - Transit Policy Violation
`
` 4 - Hop Count Exceeded
`
` 5 - Probe Completed
`
` 6 - Unimplemented SDRP version
`
` 7 - Unimplemented Source Route Protocol Type
`
` 8 - 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 that the packet has
` to be forwarded. 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.
`
`Estrin, et al Informational [Page 8]
`
`FatPipe Exhibit 2024, pg. 8
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`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 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)
`
` The Loose/Strict Source Route Change 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 is 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 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 that the Payload may start at any
` arbitrary octet boundary.
`
`Estrin, et al Informational [Page 9]
`
`FatPipe Exhibit 2024, pg. 9
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
`4. Originating SDRP Data packets
`
` This document assumes that a router that originates SDRP packets is
` preconfigured with a set of SDRP routes. Procedures for constructing
` these routes are outside the scope of this document. SDRP packet
` forwarding may be deployed initially without additional routing
` protocol support.
`
` An application on a source host generates packets that must be
` delivered to a given destination. The packet traverses the Internet
` by following normal hop-by-hop routing information. An intermediate
` router in the path between the source host and the destination host
` may decide to forward some of these packets via SDRP.
`
` When this router receives an IP datagram, the router uses the
` information in the datagram and the local criteria to determine
` whether the datagram should be forwarded along a particular SDRP
` route. Associated with each set of criteria is a set of one or more
` SDRP routes that should be used to route matching packets. The exact
` nature of the criteria is a local matter. The only restrictions this
` document places on the applicability of SDRP routes is that an IP
` datagram that contains a strict source route should not be forwarded
` along an SDRP route, that SDRP encapsulation should never be applied
` 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 SDRP
` route, the router constructs the SDRP packet by placing the original
` datagram into the Payload field of the SDRP packet and constructing
` the SDRP header based on the selected SDRP route. The Next Hop
` pointer is set to 0 (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.
`
` 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 SDRP
` routers, that a domain level source route that does not terminate
` with the intended destination domain may lead a packet into a routing
` loop. Originating SDRP routers that wish to insure that this does
` not occur should include a final domain level hop of the
` destination’s domain, i.e. specify the SDRP route as <DI1, DI2, DI3>
` instead of <DI1, DI2>, if the destination host is in domain DI3. The
` means for determining the DI of the destination domain is outside of
` the scope of this document.
`
` Similarly, when using SDRP for interior routing, it is possible that
` 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 IP
`
`Estrin, et al Informational [Page 10]
`
`FatPipe Exhibit 2024, pg. 10
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
` 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 source address field in the delivery header should contain an IP
` address of the router. The value of the Don’t Fragment flag of the
` delivery header is copied from the Don’t Fragment flag of the payload
` header. The value of 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 is used is learned from IDRP, then the TOS
` corresponding to this route is copied into the TOS field in the
` delivery header.
`
` The resulting SDRP packet is then forwarded as described in Section
` 5.2.2.
`
` 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. The router should then 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 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 describe above. Otherwise, the router should first form the SDRP
` packet, and then fragment it.
`
` 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 feasibility
` of the SDRP route. 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.
`
`Estrin, et al Informational [Page 11]
`
`FatPipe Exhibit 2024, pg. 11
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
`5. Processing SDRP packets
`
` 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, the router 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 that it is given to
` forward does not violate any of the transit policies that may exist,
` of the domain to which the router belongs. Specific verification
` mechanisms are a matter that is local to the router and are outside
` the scope of this document.
`
` The restriction on the verification mechanisms is that they may take
` into account only the contents of the SDRP header, the payload
` header, and 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. Thus, by caching
` 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 the 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 of an SDRP packet depend on
`
` a) whether the router has the routing information needed to
` forward the packet;
`
`Estrin, et al Informational [Page 12]
`
`FatPipe Exhibit 2024, pg. 12
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
` 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
`
` 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, then forwards 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
`
` The following pseudo-code gives an overview of the SDRP forwarding
` algorithm. Please consult the text below for more details.
`
` Let LOCAL_DI be the DI of the domain of the local system, let
` NEXT_HOP be the next hop in the source route if the source route has
` not been completely traversed, let NEXT_DI be the DI portion of
` NEXT_HOP if NEXT_HOP is from network 128.0.0.0, and let NEXT_ROUTER
` be the IP address of the next router if the packet is to be forwarded
` using SDRP. We say that NEXT_DI is adjacent if the local domain is
` adjacent to the domain that has NEXT_DI as its DI, and we say that
` NEXT_ROUTER is adjacent if it represents an IP address of a router
` that shares a link with the current router. Normal IP forwarding
` refers to forwarding that can be accomplished using FIBs constructed
` via BGP, IDRP or one or more IGPs.
`
` The pseudo code requires sending control messages in a number of
` places. All such control messages must be sent to the encapsulating
` router, which is indicated in the source address of the delivery
` header. Note too that all intermediate SDRP routers that process an
` SDRP packet must ensure that the source address of the delivery
` header is left untouched, since this source address is the address of
` the encapsulating router to which any control messages must be sent.
`
`Estrin, et al Informational [Page 13]
`
`FatPipe Exhibit 2024, pg. 13
`Cisco v. FatPipe
`IPR2017-01845
`
`

`

`RFC 1940 SDRv1 May 1996
`
` 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