HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:39:33 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 17 Oct 1994 23:00:00 GMT ETag: "3050a6-92f7-2ea301f0" Accept-Ranges: bytes Content-Length: 37623 Connection: close Content-Type: text/plain Source Demand Routing Working Group Peter Ford INTERNET DRAFT LANL Tony Li cisco Systems Yakov Rekhter T.J. Watson Research Center, IBM Corp. October 1994 Explicit Routing Protocol (ERP) for IPv6 Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 1. Introduction This document specifies the format and processing of the IPv6 Explicit Routing Protocol (ERP) Header. The purpose of this header is to provide IPv6 forwarding functionality comparable to SDRP [SDRP]. The reader should be familiar with [IPv6]. 2. Acknowledgments This document is based on "Source Demand Routing: Packet Format and Forwarding Specification (Version 1)" [SDRP] and "Source Demand Routing: Route Setup" [SDRP-SETUP]. 3. Model of Operation Expiration Date April 1995 [Page 1] INTERNET DRAFT October 1994 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. For the purposes of this document, 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 connected sets of Routing Domains may be grouped into Routing Domain Confederations. A domain may belong to more than one confederation. The confederations may be nested, disjoint, or overlapped. 3.1 Addressing Assumptions Each domain has a globally unique identifier, called a Routing Domain Identifier (RDI). All the BRs within a domain need to know the RDI assigned to the domain. Likewise, each routing domain confederation has a globally unique identifier, called a Routing Domain Confederation Identifier (RDCI). This document assumes that RDIs and RDCIs are expressed as IPv6 addresses, and assigned based on the unicast address prefixes assigned to domains and confederations. A subscriber RD should use as its RDI an address taken out of the unicast address prefix assigned to it. A multihomed RD should use as its RDI an address taken out of one of the unicast address prefixes assigned to it. A service provider should use as its RDI an address taken out of the unicast address prefix that the provider uses for assigning addresses to systems within the provider. Finally, an RDI of a domain may be constructed by taking a unicast address out of any unicast address prefix assigned to the domain. If a service provider forms a Routing Domain Confederation with some of its subscribers and the subscribers take their addresses out of the provider, then an address taken out of the unicast address prefix assigned to the provider should be used as the RDCI of the confederation. An RDCI of a confederation may be also constructed by taking a unicast address out of any unicast address prefix assigned to any domain within the confederation, provided that this unicast address is different from any other RDI or RDCI. The address taken out for RDI or RDCI can not be used for unicast address assignment. Expiration Date April 1995 [Page 2] INTERNET DRAFT October 1994 The assumptions made here, combined with the assumption that unicast addresses are globally unambiguous, guarantee that non-multicast IPv6 addresses (except for the block allocated for private use) are globally unambiguous and that each assigned address can represent either (a) unicast address, or (b) RDI, or (c) RDCI. A router may have one or more unicast addresses, one RDI, one or more RDCIs associated with it. It is assumed that at the minimum each router has to have at least one unicast address, but may also have at most one domain identifier and one or more confederation identifiers. For the rest of the document, when we refer to an address of a router this reference may include either a unicast address or RDI or RDCI associated with the router. 3.2 ERP Route Definition An ERP route is defined as a sequence of elements (called forwarding hops), where each hop may depict a router, a domain, or a confederation. Each hop is syntactically expressed as a unicast address. Thus, an ERP route is syntactically expressed as a sequence of unicast addresses. Semantically an ERP route is defined as an arbitrary intermix of routers, domains, and confederations. A hop within an ERP route can either be "strict" or "loose". Forwarding to a strict next hop requires that the next hop be adjacent to the current hop. Forwarding to a loose next hop doesn't impose this requirement. The definition of what constitute an "adjacent" hop depends on the type (i.e., unicast address, RDI, RDCI) of the current and the next hop, and is defined as follows. A hop with unicast address A is adjacent to a hop with unicast address B, if there are elements N and M, N with unicast addresses A and X, and M with unicast addresses B and Y, and addresses X and Y share a common subnetwork. A hop with unicast address A is adjacent to a hop with domain identifier B, if there is an element N with domain identifier B and unicast address X, so that A is adjacent to X (as defined above). In this case any element with domain identifier B is adjacent to A. A hop with a unicast address A is adjacent to a hop with confederation identifier B if there is an element N with confederation identifier B and unicast address X, so that A is adjacent to X (as defined above). A hop with domain identifier A is adjacent to a hop with domain identifier B if there exist two elements, M and N, M with domain identifier A and unicast address X, and N with domain identifier B and unicast address Y, such that X is adjacent to Y (as defined Expiration Date April 1995 [Page 3] INTERNET DRAFT October 1994 above). A hop with domain identifier A is adjacent to a hop with confederation identifier B if there exist two elements, M and N, M with domain identifier A and unicast address X, and N with confederation identifier B and unicast address Y, such that X is adjacent to Y (as defined above). A hop with confederation identifier A is adjacent to a hop with confederation identifier B if there exist two elements, M and N, M with confederation identifier A and unicast address X, and N with confederation identifier B and unicast address Y, such that X is adjacent to Y (as defined above). Note that the notion of "adjacent" is reflexive. That is, if A is adjacent to B, then B is adjacent to A. 3.3 Setup In some cases, commonly known as "flows", where the duration of a packet stream is significantly longer than the end-to-end round-trip delay, and particularly where the amount of payload in the packet is small, it may be worthwhile to "set up" the ERP route by saving state information in routers that have to process the route, instead of carrying the full ERP route in every packet. Once this state is established, the originator of the ERP route can use a combination of Source Address and Flow Label carried in the fixed header to refer to the ERP route rather than carrying the full route in each data packet, thereby reducing the ERP Header size and transmission time. It is important to the protocol that it does not impose setup on routers that are short on state space or that otherwise restrict setup. Therefore, the desire for setup is simply flagged by the the originator of the ERP route, and the routers that have to process the ERP route may choose to accept or reject the request. If all of the routers that have to process the ERP route accept, then the originator can begin using a route identifier (as carried by the Flow Label field of the Fixed Header) to refer to the saved state. If any router refuses setup, the originator must continue including the full ERP route in each data packet or else try a different route. When a router rejects a setup request, it sends an ICMP message containing the route identifier to the originator of the request. ICMP messages are also used in this manner if a router loses or is missing state for a particular route identifier. When a router accepts a setup request, it continues forwarding the request along the ERP route. Successful route setup is indicated when the final router on the ERP route sends an ICMP message containing Flow Label to the originator of the route. Expiration Date April 1995 [Page 4] INTERNET DRAFT October 1994 3.4 Forwarding Information Base (FIB) Model It is assumed that each router maintains a conventional unicast Forwarding Information Base (FIB), where each entry in the FIB is represented as a tuple
. It is assumed that if a router shares a common subnetwork with a BR, then the router has information about all the RDIs and RDCIs the BR belongs to. The mechanisms by which this information is acquired are outside the scope of this document. This information is represented in the FIB as a set of tuples, where the address prefix component of each tuple specifies a particular RDI or RDCI (expressed as a 16 octets IPv6 address) of the BR and the next hop component specifies the IPv6 unicast address of the BR. This also applies to the case where the router is a BR itself. If the next hop depicts a router that is not directly connected to the local system (doesn't share a common subnetwork), then it is assumed that the FIB contains an entry that allows to derive the immediate next hop (the next hop on a common subnetwork). In addition to conventional FIB a router may maintain a Flow Label cache. This cache is used to support setups. Each entry in the cache is a triplet . An entry in the cache is uniquely identified by its the first two components of the triplet (Source Address and Flow Label). Each entry in the cache can be timed out at any time, and should be timed out periodically. The particular policy used for timing out cache entries is a local matter. 4. Explicit Forwarding Header format An ERP Header is a type of an IPv6 Routing Header. The value of the Routing Type field of the IPv6 Routing Header is set to 1 for an ERP Header. The ERP Header format is defined as following: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header |Routing Type=1 | Flags |NestL| FwdDirLen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NextHopPtr | Strict/Loose Bit Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding Directions, a list of IPv6 addresses | | (integral multiple of 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expiration Date April 1995 [Page 5] INTERNET DRAFT October 1994 Next Header - 8-bit selector. Identifies the type of the header immediately following the Routing header. Uses the same values as the IPv4 Protocol field [RFC-1340] plus new types defined for IPv6. Routing Type - 1. Flags (5 bits): MRE, Must Report Errors (bit 0). If this bit is set to 1, and a router can not further forward a packet, the router must generate an ICMP error message. If this bit is set to 0, and a router can not further forward a packet the router should not generate an ICMP error message. FFD, Behavior on Failure of Forwarding Directions (bit 1). If this bit it set to 1, it indicates that if a router can not further forward a packet the router must abort the ERP route (as specified in Section 7). SAS, Source Address Swap (bit 2). If this bit is set to 1, it indicates that the entity that added the current ERP Header to a packet placed the source address from the fixed header as the first element in the Forwarding Directions, and placed its own unicast address as the source address in the fixed header. '''.in 14 FLS, Flow Label Saved (bit 4) If this bit is set to 1, then the low-order 28 bits of the second element in the Forwarding Directions field contain a Flow Label. Nesting Level (3 bits). The Nesting Level field is used to control the number of ERP Headers carried by a packet. The maximum number of ERP Headers that can be carried by a packet is 8. Forwarding Directions Length (1 octet unsigned integer). The Forwarding Directions Length field contains the number of Forwarding Directions hops in the header. Length of the header can be calculated from this value (length = FwdDirLen * 16 + 8) The value of this field shall not exceed 24. Expiration Date April 1995 [Page 6] INTERNET DRAFT October 1994 Next Hop Pointer (1 octet unsigned integer). The Next Hop Pointer field contains the index of next hop to be processed. The first element in the Forwarding Directions has index 0. The value of this field shall not exceed 24. Strict/Loose Bit Mask (24 bits). The Strict/Loose Bit Mask is used when making a forwarding decision. If the N-th bit (N not equal 1) in the Strict/Loose Bit Mask field is set to 1, it indicates that the N-th element in the Forwarding Directions is a Strict Hop (with respect to the (N-1) element). If this bit is set to 0, it indicates that the N-th element in the Forwarding Directions is a Loose Hop (with respect to the (N-1) element). The value of the first bit in the Strict/Loose Bit Mask field specifies whether the first element in the Forwarding Directions is a Strict or a Loose Hop with respect to the entity that originated an ERP route. Forwarding Directions (variable length, multiple of 16 octets). The elements of the Forwarding Directions (hops) are syntactically IPv6 addresses. Semantically Forwarding Directions can contain an arbitrary intermix of unicast addresses, RDIs, and RDCIs. 5. Originating ERP Routes This document assumes that an entity that attaches an ERP Header to a packet is preconfigured with a set of ERP routes. Procedures for constructing these routes are outside the scope of this document. Use of ERP capabilities may be deployed initially without additional routing information exchange protocol support. An entity that is capable of attaching ERP Headers is expected to use information carried in a packet combined with the local criteria to determine whether the packet should be forwarding along a particular ERP route. Associated with each set of criteria is a set of one or more ERP routes that should be used to route matching packets. The exact nature of the criteria is a local matter. An ERP Header may be attached to a packet by either an entity that originated the packet or by an entity that forwards the packet. For example, either a host that originates a packet, or any router that forwards the packet may attached an ERP Header to the packet. An ERP Header is attached to a packet by placing the Header immediately after the fixed header. A packet may carry more than one ERP Headers. Each such header is Expiration Date April 1995 [Page 7] INTERNET DRAFT October 1994 referred to by its nesting level (as carried in the Nesting Level field of the header). The first Header attached to a packet is referred to as the level 1 ERP Header. The level 1 ERP Header is identified by the Next Header field in the ERP Header (the value of the field is other than Routing Header). The outermost ERP Header (the one that immediately follows the fixed header) is referred to as the "current" ERP Header. When an entity attaches the level 1 ERP Header to a packet, the entity must put the destination address, as specified in the destination address field of the fixed header of the packet, as the last element in the Forwarding Directions of the ERP Header. Thus, the last element in the Forwarding Directions field of the level 1 ERP Header is the destination address of the packet. Any router may attach a level 1 ERP Header to a packet that the router has to forward. Only a router that is identified by the current element in the Forwarding Directions field of the current ERP Header can attach a non-level 1 ERP Header to the packet, and only when the next element in the Forwarding Directions is specified as a Loose Hop. The entity that attaches the level 1 ERP Header to a packet specifies the maximum allowed number of nested ERP Headers. When a router wants to attach an ERP Header to a packet that already has one or more ERP Headers the router decrements the Nesting Level from the current ERP Header by 1 and places it in the Nesting Level field of the ERP Header it wants to attach. No further ERP Headers can be attached to a packet whose current ERP Header carries zero as the value of the Nesting Level field. When an entity other than the one that originates a packet, attaches an ERP Header to the packet, the entity places the source address from the fixed header as the first element in the Forwarding Directions field, places its own unicast address in the source address field of the fixed header, and sets the Source Address Swap flag to 1. If the value of the Flow Label field in the fixed header is non-zero, then this value is placed in the low-order 28 bits of the second element in the Forwarding Directions field, the Flow Label Save flag is set to 1, and the value of the NextHopPtr field is set to 2. Otherwise (the value of the Flow Label field is zero), the value of the NextHopPtr field is set to 1. If the Flow Label is zero, then the actual ERP route starts from the second element of the Forwarding Directions, otherwise the route starts from the third element of the Forwarding Directions. If an entity that originates a packet attaches an ERP Header to the packet, then the entity must set the Source Address Swap flag to 0, Flow Label Save flag to 0, and set the value of the NextHopPtr to 0. We say that a packer carries an implicit ERP Header if the packet's forwarding is done using the setup capabilities, and the actual ERP Header that was used during the setup is omitted. Otherwise, ''we Expiration Date April 1995 [Page 8] INTERNET DRAFT October 1994 say that the Header is explicit. An entity originating an ERP route (the originator) may request an ERP setup by setting the appropriate bits in the Flow Label field, and setting all other fields as described above. It is suggested to set the Must Report Errors flag to 1. The originator may wait a full round-trip time (provided that this time is know by the originator) for a response to the setup request, in the meantime sending subsequent packets with an explicit ERP Header. There is no limit, however, to the number or frequency of setup requests, thus the entity may repeat the setup. Once the originator receives a response indicating that the setup is successfully completed the originator may start sending packets with an implicit ERP Header. The originator may choose to send packets with the implicit ERP Header immediately after sending the setup request. This may be useful if the packets will be useless after waiting a full round-trip time. In this case, the packets will be delivered if the setup is successful, but may be dropped otherwise. 6. Processing packets with ERP routes We say that a router receives a packet with an ERP route if the destination address in the fixed header of the packet that arrives at the router depicts one of the addresses of the router and the packet carries at least one ERP Header. In the case where a router receives a packet with an explicit ERP Header we say that the packet carries a completed ERP route if either (a) the Header is Level 1 and the value of the NextHopPtr field in the Header is one less than the value of the FwdDirLen field, or (b) the Header is other than Level 1 and the value of the NextHopPtr field in the Header is equal to the value of the FwdDirLen field. Otherwise, we say that the received packet carries an incomplete (non-empty) ERP route. In the case where a router receives a packet with an implicit ERP Header the router checks for a presence of an entry in its Flow Label cache whose Source Address is equal to the Source Address field of the fixed header of the packet, and whose Flow Label is equal to the Flow Label field of the fixed header. If no such entry is found, the packet is processed as described in Section 7. If such an entry is found, then we say that the packet carries a completed ERP route if the ERP Header associated with the entry is either (a) a Level 1 and the value of the NextHopPtr field in the Header is one less than the value of the FwdDirLen field, or (b) is other than Level 1 and the value of the NextHopPtr field in the Header is equal to the value of the FwdDirLen field. If such an entry is found, but neither (a) nor (b) are satisfied, then we say that the received packet carries an incomplete (empty) ERP route. Expiration Date April 1995 [Page 9] INTERNET DRAFT October 1994 6.1 Processing packets with a completed ERP route When a router receives a packet with an explicit ERP Header and the ERP route is completed then the packet is processed as follows. If the current ERP Header is a Level 1 header, then the last element in the Forwarding Directions is placed in the Destination Address field of the fixed header. If the Source Address Swap flag in the current ERP Header is set to 1, then the first element in the Forwarding Directions field is swapped with the Source Address field of the fixed header. If the Flow Label Save flag in the current ERP Header is set to 1, then the low-order 28 bits of the second element in the Forwarding Directions field is placed in the Flow Label field of the fixed header. If the current ERP Header is not a Level 1 header, then the current header must be removed from the packet. If the current ERP Header is a Level 1 header, then it may be removed from the packet. In addition, if the Flow Setup Request flag in the Header is set to 1, and the router is willing to accommodate the setup request (as described in Section 6.4) the router generates an ICMP message to the entity depicted by the source address in the fixed header indicating that the setup request has been successfully completed. When a router receives a packet with an implicit ERP Header and the ERP route is completed then the packet is processed as described in the previous paragraph, except that instead of the current ERP Header the router uses the ERP Header associated with the entry in the Flow Label cache identified by the Source Address and Flow Label fields of the packet's fixed header. After the above procedures are completed the packet is submitted for normal forwarding procedure. 6.2 Processing packets with an incomplete ERP route and explicit ERP Header If a router receives a packet with an incomplete ERP route, and the destination address in the fixed header is one of the unicast addresses associated with the router, the router must check whether the current element in the Forwarding Directions of the current ERP Header, as pointed by the NextHopPtr, specifies an address associated with the router. If this condition isn't satisfied, then further handling of the packet is done as described in Section 7. If this condition is satisfied, then the packet is processed as follows. If the current ERP Header is a Level 1 header and the value of the NextHopPtr field is two less than the value of the FwdDirLen field, or if the current ERP Header is not a Level 1 header and the value of the NextHopPtr field is one less than the value of the FwdDirLen field, the router increments the value of the NextHopPtr field by 1, and then follows the procedures specified in Section 6.1. Expiration Date April 1995 [Page 10] INTERNET DRAFT October 1994 Otherwise, the router extracts the next element from the Forwarding Directions (the next element is the element that immediately follows the current element in the Forwarding Directions) and the strict/loose indicator associated with the next element (the indicator is extracted from the Strict/Loose Bit Mask field). Further processing depends on whether the next element specifies a Loose Hop (see Section 6.2.1) or a Strict Hop (see Section 6.2.2). 6.2.1 Loose Next Hop If the next element in the Forwarding Directions is a Loose Hop, then the router places the address, as specified in the next element, in the destination address field of the fixed header, increments the value of the Next Hop Pointer by 1, and submits the packet for normal forwarding procedure. If the forwarding procedure can not forward the packet (based on the destination address specified in the fixed header), then further handling of the packet is done as described in Section 7. 6.2.2 Strict Next Hop If the next element in the Forwarding Directions is a Strict Hop, then the router performs a lookup in its FIB (using the "longest match" algorithm) using the address specified in the next element as an index. If no matching tuple is found, then further handling of the packet is done as described in Section 7. If the next hop component of the found tuple specifies an entity that shares a common subnetwork with the router, then the router checks whether any of the addresses associated with that entity are equal to the address specified by the next element in the Forwarding Directions. If that is the case, then the value of the Next Hop Pointer field is incremented by 1. The address specified by the next hop component of the found tuple is placed in the destination address field of the fixed header and the packet is then submitted for normal forwarding procedure. If the forwarding procedure can not forward the packet (based on the destination address specified in the fixed header), then further handling of the packet is done as described in Section 7. 6.3 Processing packets with an incomplete ERP route and implicit ERP Header If a router receives a packet with an implicit ERP Header that carry an incomplete ERP route, and the destination address in the fixed Expiration Date April 1995 [Page 11] INTERNET DRAFT October 1994 header is one of the unicast addresses associated with the router, the router extracts from its Flow Label cache an entry identified by the Source Address and Flow Label fields of the packet's fixed header. If the ERP Header associated with the extracted entry is a Level 1 header and the value of the NextHopPtr field is two less than the value of the FwdDirLen field, or if the Header is not a Level 1 header and the value of the NextHopPtr field is one less than the value of the FwdDirLen field, the router follows the procedures specified in Section 6.1. Otherwise, the router extracts the next element from the Forwarding Directions (the next element is the element that immediately follows the current element in the Forwarding Directions) and the strict/loose indicator associated with the next element (the indicator is extracted from the Strict/Loose Bit Mask field). Further processing depends on whether the next element specifies a Loose Hop (see Section 6.3.1) or a Strict Hop (see Section 6.3.2). 6.3.1 Loose Next Hop If the next element in the Forwarding Directions is a Loose Hop, then the router places the address, as specified in the next element, in the destination address field of the fixed header, and submits the packet for normal forwarding procedure. If the forwarding procedure can not forward the packet (based on the destination address specified in the fixed header), then further handling of the packet is done as described in Section 7. 6.3.2 Strict Next Hop If the next element in the Forwarding Directions is a Strict Hop, then the router performs a lookup in its FIB (using the "longest match" algorithm) using the address specified in the next element as an index. If no matching tuple is found, then further handling of the packet is done as described in Section 7. If the next hop component of the found tuple specifies an entity that shares a common subnetwork with the router, then the router checks whether any of the addresses associated with that entity are equal to the address specified by the next element in the Forwarding Directions. The address specified by the next hop component of the found tuple is placed in the destination address field of the fixed header and the packet is then submitted for normal forwarding procedure. If the forwarding procedure can not forward the packet (based on the destination address specified in the fixed header), then further handling of the packet is done as described in Section 7. Expiration Date April 1995 [Page 12] INTERNET DRAFT October 1994 6.4 Processing packets with Setup Request If a router receives a packet with an ERP route and the packet carries a setup request, then in addition to the procedures described in Sections 6.1 and 6.2 (including 6.2.1 and 6.2.2), the router performs the following procedures. If the router is willing to accommodate the setup request, then the router constructs a triplet , where the value of the first element (Source Address) is set to the value of the Source Address from the fixed header, the value of the second element (Flow Label) is set to the value of the Flow Label field of the fixed header, and the value of the third element is set to the value of all the ERP Headers carried by the packet. The router then checks whether the triplet is present in its Flow Label cache, and if not then adds to the cache an entry that contains the triplet. If the router is unwilling to accommodate the setup request, and Must Report Error flag is set to 1, then the router generates an ICMP message to the entity depicted by the source address in the fixed header indicating that the setup request can not be accommodated. The rules by which a router decides whether to accommodate a setup request are outside the scope of this document. 7 Error Handling If the MRE is set to 1, then the router generates an ICMP error message back to the entity specified in the source address of the fixed header. If the MRE is set to 0, then no ICMP error messages should be generated. If the Behavior on Failure of Forwarding Directions bit in the current ERP Header of a packet is set to 1, and the Header carries a non-empty ERP route then the packet is processed as follows. If the current ERP Header is a Level 1 header, then the value of the NextHopPtr field is set to one less than the value of the FwdDirLen field. Otherwise, the value of the NextHopPtr field is set to the value of the FwdDirLen field. The packet is then processed as described in Section 6.1. If the Behavior on Failure of Forwarding Directions bit in the current ERP Header of a packet is set to 1, the Header carries an empty ERP route, and the Header is not a level 1 Header, then the packet is processed as described in Section 6.1. If the Behavior on Failure of Forwarding Directions bit in the current ERP Header of a packet is set to 1, the Header carries an empty ERP route, and the Header is a level 1 Header, then the packet is discarded. If the Behavior on Failure of Forwarding Directions bit in the Expiration Date April 1995 [Page 13] INTERNET DRAFT October 1994 current ERP Header of a packet is set to 0, then the packet is discarded. 8 Path MTU Handling 9. ERP ICMP Message Format [Need to define format of an ICMP message associated with ERP. The message should be able to carry one of the following indications: (a) Setup Request completed (b) Setup Request refused (c) Can't satisfy Forwarding Directions (d) No Flow Label cache entry found In addition to the indication the message should carry as much of the original packet as possible, but at the minimum the fixed header and all the ERP Headers.] 10. Authors' Address Peter Ford Los Alamos National Laboratory Los Alamos Phone: (505) 665-0058 e-mail: peter@goshawk.lanl.gov Tony Li cisco Systems, Inc. 1525 O'Brien Drive Menlo Park, CA 94025 email: tli@cisco.com Yakov Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 704 Yorktown Heights, NY 10598 Phone: (914) 784-7361 email: yakov@watson.ibm.com 7. References Expiration Date April 1995 [Page 14] INTERNET DRAFT October 1994 [RFC-1340] Reynolds, J. and Postel, J. "Assigned Numbers". July 1992. RFC 1340. [SDRP] Estrin, D., Li, T. , Rekhter, Y., and Varadhan K., "Source Demand Routing: Packet Format and Forwarding Specification (Version 1)" 22 March, 1994. Internet Draft. [SDRP-SETUP] Estrin, D., Zappala, D., Li, T., "Source Demand Routing: Route Setup", June 1993, Internet Draft. [SIPP-16] Deering, S., "Simple Internet Protocol Plus (SIPP) Specification (128 bit address version)". 17 July 1994. Internet Draft. Expiration Date April 1995 [Page 15]