[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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
                      <draft-ietf-sdr-erp-00.txt>



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 <address prefix, next hop>.

   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 <Source Address, Flow Label, ERP Header>.  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 <Source Address, Flow Label, ERP Header>,
   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]