home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1940.txt < prev    next >
Text File  |  1996-08-08  |  62KB  |  1,516 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          D. Estrin
  8. Request for Comments: 1940                                           USC
  9. Category: Informational                                            T. Li
  10.                                                               Y. Rekhter
  11.                                                            cisco Systems
  12.                                                              K. Varadhan
  13.                                                               D. Zappala
  14.                                                                      USC
  15.                                                                 May 1996
  16.  
  17.  
  18.                          Source Demand Routing:
  19.         Packet Format and Forwarding Specification (Version 1).
  20.  
  21. Status of this Memo
  22.  
  23.    This memo provides information for the Internet community.  This memo
  24.    does not specify an Internet standard of any kind.  Distribution of
  25.    this memo is unlimited.
  26.  
  27. 1.  Overview
  28.  
  29.    The purpose of SDRP is to support source-initiated selection of
  30.    routes to complement the route selection provided by existing routing
  31.    protocols for both inter-domain and intra-domain routes. This
  32.    document refers to such source-initiated routes as "SDRP routes".
  33.    This document describes the packet format and forwarding procedure
  34.    for SDRP.  It also describes procedures for ascertaining feasibility
  35.    of SDRP routes.  Other components not described here are routing
  36.    information distribution and route computation.  This portion of the
  37.    protocol may initially be used with manually configured routes. The
  38.    same packet format and processing will be usable with dynamic route
  39.    information distribution and computation methods under development.
  40.  
  41.    The packet forwarding protocol specified here makes minimal
  42.    assumptions about the distribution and acquisition of routing
  43.    information needed to construct the SDRP routes.  These minimal
  44.    assumptions are believed to be sufficient for the existing Internet.
  45.    Future components of the SDRP protocol will extend capabilities in
  46.    this area and others in a largely backward-compatible manner.
  47.  
  48.    This version of the packet forwarding protocol sends all packets with
  49.    the complete SDRP route in the SDRP header. Future versions will
  50.    address route setup and other enhancements and optimizations.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Estrin, et al                Informational                      [Page 1]
  59.  
  60. RFC 1940                         SDRv1                          May 1996
  61.  
  62.  
  63. 2.  Model of operations
  64.  
  65.    An Internet can be viewed as a collection of routing domains
  66.    interconnected by means of common subnetworks, and Border Routers
  67.    (BRs) attached to these subnetworks.  A routing domain itself may be
  68.    composed of further subnetworks, routers interconnecting these
  69.    subnetworks, and hosts.  This document assumes that there is some
  70.    type of routing present within the routing domain, but it does not
  71.    assume that this intra-domain routing is coordinated or even
  72.    consistent.
  73.  
  74.    For the purposes of this discussion, a BR belongs to only one domain.
  75.    A pair of BRs, each belonging to a different domain, but attached to
  76.    a common subnetwork, form an inter-domain connection. By definition,
  77.    packets that traverse multiple domains must traverse BRs of these
  78.    domains.  Note that a single physical router may act as multiple BRs
  79.    for the purposes of this model.
  80.  
  81.    A pair of domains is said to be adjacent if there is at least one
  82.    pair of BRs, one in each domain, that form an inter-domain
  83.    connection.
  84.  
  85.    Each domain has a globally unique identifier, called a Domain
  86.    Identifier (DI). All the BRs within a domain need to know the DI
  87.    assigned to the domain.  Management of the DI space is outside the
  88.    scope of this document.  This document assumes that Autonomous System
  89.    (AS) numbers are used as DIs.  A domain path (or simply path) refers
  90.    to a list of DIs such as might be taken from a BGP AS path [1, 2, 3]
  91.    or an IDRP RD path [4].  We refer to a route as the combination of a
  92.    network address and domain paths. The network addresses are
  93.    represented by NLRI (Network Layer Reachability Information) as
  94.    described in [3].
  95.  
  96.    This document assumes that the routing domains are congruent to the
  97.    autonomous systems. Thus, within the content of this document, the
  98.    terms autonomous system and routing domain can be used
  99.    interchangeably.
  100.  
  101.    An application residing at a source host inside a domain,
  102.    communicates with a destination host at another domain.  An
  103.    intermediate router in the path from the source host to the
  104.    destination host may decide to forward the packet using SDRP.  It can
  105.    do this by encapsulating the entire IP packet from the source host in
  106.    an SDRP packet.  The router that does this encapsulation is called
  107.    the "encapsulating router."
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Estrin, et al                Informational                      [Page 2]
  115.  
  116. RFC 1940                         SDRv1                          May 1996
  117.  
  118.  
  119.    2.1 SDRP routes
  120.  
  121.       A component in an SDRP route is either a DI (AS number) or an IP
  122.       address.  Thus, an SDRP route is defined as a sequence of domains
  123.       and routers, syntactically expressed as a sequence of DIs and IP
  124.       addresses.  Thus an SDRP route is a collection of source routed
  125.       hops.
  126.  
  127.       Each component of the SDRP route is called a "hop."  The packet
  128.       traverses each component of the SDRP route exactly once.  When a
  129.       router corresponding to one of the components of the SDRP route
  130.       receives the packet from a router corresponding to the previous
  131.       component of the SDRP route, the router will process the packet
  132.       according to the SDRP forwarding rules in this packet.  The next
  133.       component of the SDRP route that this router will forward the
  134.       packet to, is called the "next hop," with respect to this router
  135.       and component of the SDRP route.
  136.  
  137.       An SDRP hop can either be a "strict" source routed hop, or a
  138.       "loose" source routed hop.  A strict source route hop is one in
  139.       which, if the next hop specified is a DI, refers to an immediately
  140.       adjacent domain, and the packet will be forwarded directly to a
  141.       route within the domain; if the next hop specified is an IP
  142.       address, refers to an immediately adjacent router on a common
  143.       subnetwork.  Any other kind of a source route hop is a loose
  144.       source route hop.
  145.  
  146.       A route is a "strict source route" if the current hop being
  147.       executed is processed as a strict source route hop.  Likewise, a
  148.       route is a "loose source route" if the current hop being executed
  149.       is processed as a loose source route hop.
  150.  
  151.       It is assumed that each BR participates in the intra-domain
  152.       routing protocol(s) (IGPs) of the domain to which the BR belongs.
  153.       Thus, a BR may forward a packet to any other BR in its own domain
  154.       using intra-domain routing procedures.  Forwarding a packet
  155.       between two BRs that form an inter-domain connection requires
  156.       neither intra-domain nor the inter-domain routing procedures (an
  157.       inter-domain connection is a common Layer 2 subnetwork).
  158.  
  159.       It is also assumed that all routers participate in the intra-
  160.       domain routing protocol(s) (IGPs) of the domain to which they
  161.       belong.
  162.  
  163.       While SDRP does not require that all domains have a common network
  164.       layer protocol, all the BRs in the domains along a given SDRP
  165.       route are required to support a common network layer.  This
  166.       document specifies SDRP operations when that common network layer
  167.  
  168.  
  169.  
  170. Estrin, et al                Informational                      [Page 3]
  171.  
  172. RFC 1940                         SDRv1                          May 1996
  173.  
  174.  
  175.       protocol is IP ([5]).
  176.  
  177.       While this document requires all the BRs to support IP, the
  178.       document does not preclude a BR from additionally supporting other
  179.       network layer protocols as well (e.g., CLNP, IPX, AppleTalk).  If
  180.       a BR supports multiple network layers, then for the purposes of
  181.       this model, the BR must maintain multiple Forwarding Information
  182.       Bases (FIBs), one per network layer.
  183.  
  184.    2.2 SDRP encapsulation
  185.  
  186.       Forwarding an IP packet along an SDRP route is accomplished by
  187.       encapsulating the entire packet in an SDRP packet.  An SDRP packet
  188.       consists of the SDRP header followed by the SDRP data.  The SDRP
  189.       header carries the SDRP route constructed by the domain that
  190.       originated the SDRP packet.  The SDRP data carries the original
  191.       packet that the source domain decided to forward via SDRP.
  192.  
  193.       An SDRP packet is carried across domains as the data portion of an
  194.       IP packet with protocol number 42.
  195.  
  196.       This document refers to the IP header of a packet that carries an
  197.       SDRP packet as the delivery IP header (or just the delivery
  198.       header).  This document refers to the packet carried as SDRP data
  199.       s the payload packet, and the IP header of the payload packet is
  200.       the payload header.
  201.  
  202.       Thus, an SDRP Packet can be represented as follows:
  203.  
  204.                 +-------------------+--------------+-------------------
  205.                 | Delivery header   |  SDRP header |  SDRP data
  206.                 |    (IP header)    |              | (Payload packet)
  207.                 +-------------------+--------------+--------------------
  208.  
  209.       Each SDRP route may have an MTU associated with it. An MTU of an
  210.       SDRP route is defined as the maximum length of the payload packet
  211.       that can be carried without fragmentation of an SDRP packet.  This
  212.       means that the SDRP MTU as seen by the transport layer and
  213.       applications above the transport layer is the actual link MTU less
  214.       the length of the Delivery and SDRP headers.  Procedures for MTU
  215.       discovery are specified in Section 9.
  216.  
  217.    2.3 D-FIB
  218.  
  219.       It is assumed that a BR participates in either BGP or IDRP.  A BR
  220.       participating in SDRP augments its FIBs with a D-FIB that contains
  221.       routes to domains.  A route to a domain is a triplet <DI, Next-
  222.       Hop, NLRI>, where DI depicts a destination domain, Next-Hop
  223.  
  224.  
  225.  
  226. Estrin, et al                Informational                      [Page 4]
  227.  
  228. RFC 1940                         SDRv1                          May 1996
  229.  
  230.  
  231.       depicts the IP address of the next-hop BR, and NLRI depicts the
  232.       set of reachable destinations within the destination domain.  D-
  233.       FIBs are constructed based on the information obtained from either
  234.       BGP, IDRP, or configuration information.
  235.  
  236.       An SDRP packet is forwarded across multiple domains by utilizing
  237.       the forwarding databases (both FIBs and D-FIBs) maintained by the
  238.       BRs.
  239.  
  240.       The operational status of SDRP routes is monitored via passive
  241.       (Error Reporting) and active (Route Probing) mechanisms. The Error
  242.       Reporting mechanism provides the originator of the SDRP route with
  243.       a failure notification.  The Probing mechanism provides the
  244.       originator of the SDRP route with confirmation of a route's
  245.       feasibility.
  246.  
  247. 3.  SDRP Packet format
  248.  
  249.    The total length of an SDRP packet (header plus data) can be
  250.    determined from the information carried in the delivery IP header.
  251.    The length of the payload packet can be determined from the total
  252.    length of an SDRP packet and the length of its SDRP Header.
  253.  
  254.    The following describes the format of an SDRP packet.
  255.  
  256.        0                   1                   2                   3
  257.        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
  258.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  259.       | Ver |D|S|P|   |   Hop Count   |SourceProtoType|  Payload Type |
  260.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  261.       |                   Source Route Identifier                     |
  262.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  263.       |                         Target Router                         |
  264.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  265.       |                            Prefix                             |
  266.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  267.       |  PrefixLength |  Notification |SrcRouteLength |   NextHopPtr  |
  268.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  269.       |                Source Route ...
  270.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  271.       |                Payload ....
  272.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  273.  
  274.       Version and Flags  (1 octet)
  275.  
  276.       The SDRP version number and control flags are coded in the first
  277.       octet.  Bit 0 is the most significant bit, bit 7 is the least
  278.       significant bit.
  279.  
  280.  
  281.  
  282. Estrin, et al                Informational                      [Page 5]
  283.  
  284. RFC 1940                         SDRv1                          May 1996
  285.  
  286.  
  287.          Version (bits 0 through 2)
  288.  
  289.             The first three bits  contain the Version field indicating
  290.             the version number of the protocol.  The value of this field
  291.             is set to 1.
  292.  
  293.          Flags (bits 3 through 7)
  294.  
  295.             Data packet/Control packet (bit 3)
  296.  
  297.                If the bit is set to 1, then the packet carries data.
  298.  
  299.                Otherwise, the packet carries control information.
  300.  
  301.             Loose/Strict Source Route (bit 4)
  302.  
  303.                The Loose/Strict Source Route indicator is used when
  304.                making a forwarding decision (see Section 5.2).  If this
  305.                bit is set to 1, it indicates that the next hop is a
  306.                Strict Source Route Hop.  If this bit is set to 0, it
  307.                indicates that the next hop is a Loose Source Route.
  308.  
  309.             Probe Indicator (bit 5)
  310.  
  311.                The Probe Indicator is used by the originator of the
  312.                route to request verification of the route's feasibility
  313.                (see Sections 4 and 7.1).  If this bit is set to 1, it
  314.                indicates that the originator is probing the route.  This
  315.                bit should always be set to 0 for control packets.
  316.  
  317.       Hop Count (1 octet)
  318.  
  319.          The Hop Count field carries the maximum number of routers an
  320.          SDRP data packet may traverse. It is decremented by 1 as an
  321.          SDRP data packet traverses a router which forwards the packet
  322.          using SDRP forwarding. Once the Hop Count field reaches the
  323.          value of 0, the router should discard the data packet and
  324.          generate a control packet (see Section 5.2.6).  A router that
  325.          receives a packet with a Hop Count value of 0 should discard
  326.          the data packet, and generate a control packet (see Section
  327.          5.2.6).
  328.  
  329.       Source Route Protocol Type (1 octet)
  330.  
  331.          The Source Route Protocol Type fields indicates the type of
  332.          information that appears in the source route.  The value 1 in
  333.          this field indicates that the contents of the source route are
  334.          as described in this document and indicates an Explicit Source
  335.  
  336.  
  337.  
  338. Estrin, et al                Informational                      [Page 6]
  339.  
  340. RFC 1940                         SDRv1                          May 1996
  341.  
  342.  
  343.          Route.  The value 2 in this field indicates a Route Setup.  The
  344.          syntax of the source route for this value is identical to a
  345.          value of 1, but also has additional semantics which are defined
  346.          in other documents.
  347.  
  348.       Payload Protocol Type (1 octet)
  349.  
  350.          The Payload Protocol Type field indicates the protocol type of
  351.          the payload.  If the payload is an IP datagram, then this field
  352.          should contain the value 1.
  353.  
  354.          Note that this Payload Protocol Type is not the same as the IP
  355.          protocol type[5,7].
  356.  
  357.       Source Route Identifier (4 octets)
  358.  
  359.          The BR  that originates the SDRP packet should insert a 32 bit
  360.          value in this field which will serve as an identifier for the
  361.          source route.  This value needs to be  unique  only in the
  362.          context of the originating BR.
  363.  
  364.       Target Router (4 octets)
  365.  
  366.          This field is meaningful only in control packets.
  367.  
  368.          The Target Router field contains one of the IP addresses of the
  369.          router that originated the SDRP packet that triggered the
  370.          control packet to be returned.
  371.  
  372.       Prefix (4 octets)
  373.  
  374.          The Prefix field contains an IP address prefix.  Only the
  375.          number of bits specified in the Prefix Length are significant.
  376.          The Prefix field is used to prevent routing loops when using
  377.          BGP or IDRP to route to the next AS in a loose source route
  378.          (see Section 4).
  379.  
  380.       Prefix Length (1 octet)
  381.  
  382.          The Prefix Length field indicates the length in bits of the IP
  383.          address prefix.  A length of zero indicates a prefix that
  384.          matches all IP addresses.
  385.  
  386.             Notification Code (1 octet)
  387.  
  388.                This field is only meaningful in control packets.  In
  389.                data packets, this field is transmitted as zero, and
  390.                should be ignored on receipt.
  391.  
  392.  
  393.  
  394. Estrin, et al                Informational                      [Page 7]
  395.  
  396. RFC 1940                         SDRv1                          May 1996
  397.  
  398.  
  399.                This document defines the following values for the
  400.                Notification Code:
  401.  
  402.                1 - No Route Available
  403.  
  404.                2 - Strict Source Route Failed
  405.  
  406.                3 - Transit Policy Violation
  407.  
  408.                4 - Hop Count Exceeded
  409.  
  410.                5 - Probe Completed
  411.  
  412.                6 - Unimplemented SDRP version
  413.  
  414.                7 - Unimplemented Source Route Protocol Type
  415.  
  416.                8 - Setup Request Rejected
  417.  
  418.       Source Route Length (1 octet)
  419.  
  420.          The Source Route Length field indicates the length in 32 bit
  421.          words of the domain level source route carried in the SDRP
  422.          Header.
  423.  
  424.       Next Hop Pointer (1 octet)
  425.  
  426.          The Next Hop Pointer field indicates the offset of the high-
  427.          order byte of the next hop along the route that the packet has
  428.          to be forwarded.  This offset is relative to the start of the
  429.          Source Route field; so if the value of the Next Hop Pointer
  430.          field equals the value of the Source Route Length field, then
  431.          the entire source route has been completely traversed.  All
  432.          other source routes are said to be incompletely traversed.
  433.  
  434.       Source Route (variable)
  435.  
  436.          The components of the source route are syntactically IP
  437.          addresses.
  438.  
  439.          An IP address from network 128.0.0.0 is used to encode a next
  440.          hop that is a domain.  The least significant two octets contain
  441.          the DI, which is an Internet Autonomous System number.
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Estrin, et al                Informational                      [Page 8]
  451.  
  452. RFC 1940                         SDRv1                          May 1996
  453.  
  454.  
  455.        0                   1                   2                   3
  456.        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
  457.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  458.       |      128      .       0       |             D. I.             |
  459.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  460.  
  461.  
  462.          An IP address from the network 127.0.0.0 is used to encode
  463.          characteristics of the source route.  The least significant
  464.          three octets are used as a Source Route Change field.
  465.  
  466.        0                   1                   2                   3
  467.        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
  468.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  469.       |      127      |          Source     Route     Change          |
  470.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  471.  
  472.          Source Route Change (3 octets)
  473.  
  474.             Loose/Strict Source Route Change (bit 1)
  475.  
  476.                The Loose/Strict Source Route Change bit reflects a new
  477.                value of the Loose/Strict Source Route bit in the SDRP
  478.                header.  The value of the Loose/Strict Source Route
  479.                Change bit is copied into the Loose/Strict Source Route
  480.                bit in the SDRP header when a Source Route Change field
  481.                is encountered in processing an SDRP packet.
  482.  
  483.             The rest of the Source Route Change field is transmitted as
  484.             zero, and should be ignored on receipt.
  485.  
  486.       Payload (variable)
  487.  
  488.          The Payload field carries the datagram originated by the end-
  489.          system within the domain that constructed the SDRP packet. The
  490.          Payload field forms the data portion of the SDRP packet.  In a
  491.          control packet this field may be empty or may carry the payload
  492.          header of the packet that triggered the control message (see
  493.          5.2.5).  Note that there is no padding between the Source Route
  494.          and the Payload, and that the Payload may start at any
  495.          arbitrary octet boundary.
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Estrin, et al                Informational                      [Page 9]
  507.  
  508. RFC 1940                         SDRv1                          May 1996
  509.  
  510.  
  511. 4.  Originating SDRP Data packets
  512.  
  513.    This document assumes that a router that originates SDRP packets is
  514.    preconfigured with a set of SDRP routes.  Procedures for constructing
  515.    these routes are outside the scope of this document.  SDRP packet
  516.    forwarding may be deployed initially without additional routing
  517.    protocol support.
  518.  
  519.    An application on a source host generates packets that must be
  520.    delivered to a given destination.  The packet traverses the Internet
  521.    by following normal hop-by-hop routing information.  An intermediate
  522.    router in the path between the source host and the destination host
  523.    may decide to forward some of these packets via SDRP.
  524.  
  525.    When this router receives an IP datagram, the router uses the
  526.    information in the datagram and the local criteria to determine
  527.    whether the datagram should be forwarded along a particular SDRP
  528.    route.  Associated with each set of criteria is a set of one or more
  529.    SDRP routes that should be used to route matching packets.  The exact
  530.    nature of the criteria is a local matter.  The only restrictions this
  531.    document places on the applicability of SDRP routes is that an IP
  532.    datagram that contains a strict source route should not be forwarded
  533.    along an SDRP route, that SDRP encapsulation should never be applied
  534.    to an SDRP packet, and that if SDRP is used with inter-domain routes,
  535.    the destination domain must also run SDRP.
  536.  
  537.    If the router decides to forward a datagram along a particular SDRP
  538.    route, the router constructs the SDRP packet by placing the original
  539.    datagram into the Payload field of the SDRP packet and constructing
  540.    the SDRP header based on the selected SDRP route.  The Next Hop
  541.    pointer is set to 0 (the first entry in the Source Route field of the
  542.    SDRP packet).  The value of the Time To Live field in the payload
  543.    header should be copied into the Hop Count field of the SDRP header.
  544.  
  545.    Even if we assume that interior routing is loop free, it is possible,
  546.    either due to the state of inter-domain routing or due to other SDRP
  547.    routers, that a domain level source route that does not terminate
  548.    with the intended destination domain may lead a packet into a routing
  549.    loop.  Originating SDRP routers that wish to insure that this does
  550.    not occur should include a final domain level hop of the
  551.    destination's domain, i.e. specify the SDRP route as <DI1, DI2, DI3>
  552.    instead of <DI1, DI2>, if the destination host is in domain DI3.  The
  553.    means for determining the DI of the destination domain is outside of
  554.    the scope of this document.
  555.  
  556.    Similarly, when using SDRP for interior routing, it is possible that
  557.    the source route does not coincide with IGP routing.  In this case,
  558.    one means of preventing a loop is to specify the last hop router's IP
  559.  
  560.  
  561.  
  562. Estrin, et al                Informational                     [Page 10]
  563.  
  564. RFC 1940                         SDRv1                          May 1996
  565.  
  566.  
  567.    address as the last address within the source route.  The
  568.    encapsulating router can do this by specifying the source route to
  569.    reach destination host IP3 as <IP1, IP2, IP3> instead of <IP1, IP2>.
  570.  
  571.    The source address field in the delivery header should contain an IP
  572.    address of the router. The value of the Don't Fragment flag of the
  573.    delivery header is copied from the Don't Fragment flag of the payload
  574.    header.  The value of the Type Of Service field in the delivery
  575.    header is copied from the Type Of Service field in the payload
  576.    header.  If the payload header contains an IP security option, that
  577.    option is replicated as an option in the delivery header.  All other
  578.    IP options in the payload header must be ignored.
  579.  
  580.    If the SDRP route that is used is learned from IDRP, then the TOS
  581.    corresponding to this route is copied into the TOS field in the
  582.    delivery header.
  583.  
  584.    The resulting SDRP packet is then forwarded as described in Section
  585.    5.2.2.
  586.  
  587.    If the encapsulating router decides to forward a datagram along a
  588.    particular SDRP route that has an MTU smaller than the length of the
  589.    datagram, then if the payload header has the Don't Fragment flag set
  590.    to 1, the router should generate an ICMP Destination Unreachable
  591.    message with a code meaning "fragmentation needed and DF set" in
  592.    accordance with [6].  The ICMP message must be sent to the original
  593.    source host.  The router should then discard the original datagram.
  594.  
  595.    If a router has learned an MTU for a particular SDRP route, either
  596.    via ICMP messages or via configuration information, and it determines
  597.    that an SDRP packet must be fragmented before transmission, then it
  598.    first calculates the the effective MTU seen by the payload packet.
  599.    If the effective MTU is greater than or equal to 512 bytes, the
  600.    router SHOULD first fragment the payload packet using normal IP
  601.    fragmentation.  SDRP packets are then constructed for each fragment,
  602.    as describe above.  Otherwise, the router should first form the SDRP
  603.    packet, and then fragment it.
  604.  
  605.    A router may use locally originated  SDRP packets to verify the
  606.    feasibility of its SDRP routes. To do this the router sets the value
  607.    of the Probe Indicator field in the SDRP packet to 1.  Receipt of an
  608.    SDRP control packet by the originating router with the "Probe
  609.    Completed" Notification Code (see Section 7.1) indicates feasibility
  610.    of the SDRP route.  Persistent lack of SDRP control packets with the
  611.    "Probe Completed" Notification Code should be used as an indication
  612.    that the associated SDRP route is not feasible.
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Estrin, et al                Informational                     [Page 11]
  619.  
  620. RFC 1940                         SDRv1                          May 1996
  621.  
  622.  
  623. 5.  Processing SDRP packets
  624.  
  625.    We say that a router receives an SDRP packet if the destination
  626.    address field in the delivery header of the packet arriving at the
  627.    router contains one of the IP addresses of the router.
  628.  
  629.    When a router receives an SDRP packet, the router extracts the Source
  630.    Route Protocol field from the SDRP header.
  631.  
  632. 5.1 Supporting Transit Policies
  633.  
  634.    A router may be able to verify that a packet that it is given to
  635.    forward does not violate any of the transit policies that may exist,
  636.    of the domain to which the router belongs.  Specific verification
  637.    mechanisms are a matter that is local to the router and are outside
  638.    the scope of this document.
  639.  
  640.    The restriction on the verification mechanisms is that they may take
  641.    into account only the contents of the SDRP header, the payload
  642.    header, and transport protocol header of the payload packet.
  643.  
  644.    With SDRP a domain may enforce its transit policies by applying
  645.    filters based on the information present in the IP Header. For
  646.    example a router may initially carefully filter all SDRP traffic from
  647.    all possible sources. A filter that allows certain SDRP traffic from
  648.    selected sources to pass through the router could then be installed
  649.    dynamically to pass similar types of traffic.  Thus, by caching
  650.    appropriate filtering information, a transit domain can efficiently
  651.    support transit policies.  Other mechanisms for supporting transit
  652.    policy and implementation techniques are not precluded by this
  653.    document.
  654.  
  655.    If the router detects that the SDRP packet violates a domain's
  656.    transit policy it sends back an SDRP control packet to the
  657.    encapsulating router and discards the violating packet.
  658.  
  659.    SDRP control packets are not subject to transit policies.
  660.  
  661.    If a router does not discard an SDRP packet due to a transit policy
  662.    violation, then the router attempts to forward it as specified in
  663.    Section 5.2.
  664.  
  665. 5.2 Forwarding SDRP packets
  666.  
  667.    Procedures for forwarding of an SDRP packet depend on
  668.  
  669.       a) whether the router has the routing information needed to
  670.          forward the packet;
  671.  
  672.  
  673.  
  674. Estrin, et al                Informational                     [Page 12]
  675.  
  676. RFC 1940                         SDRv1                          May 1996
  677.  
  678.  
  679.       b) whether the SDRP route has been completely traversed;
  680.       c) whether the SDRP route is strict or loose, and
  681.       d) whether the packet is a data or control packet.
  682.  
  683.    When forwarding an SDRP packet (either data or control) a router
  684.    should not modify the following fields in the delivery header:
  685.  
  686.       a) Source Address
  687.       b) Don't Fragment flag
  688.  
  689.    If the Source Route Protocol Type of a packet indicates a Route Setup
  690.    and the router does not or cannot support setup, the router MAY send
  691.    the encapsulating router a control packet with a Notification Code of
  692.    Setup Request Rejected.  It MAY then modify the data packet so that
  693.    the Source Route Protocol Type is Explicit Source Route and the Probe
  694.    Indicator bit is 0, then forwards the packet as described below.  The
  695.    router MAY send notification of a failed setup request only
  696.    periodically.  Alternately, a router MAY silently drop the Route
  697.    Setup packet.
  698.  
  699. 5.2.1 Forwarding algorithm pseudo-code
  700.  
  701.    The following pseudo-code gives an overview of the SDRP forwarding
  702.    algorithm.  Please consult the text below for more details.
  703.  
  704.    Let LOCAL_DI be the DI of the domain of the local system, let
  705.    NEXT_HOP be the next hop in the source route if the source route has
  706.    not been completely traversed, let NEXT_DI be the DI portion of
  707.    NEXT_HOP if NEXT_HOP is from network 128.0.0.0, and let NEXT_ROUTER
  708.    be the IP address of the next router if the packet is to be forwarded
  709.    using SDRP.  We say that NEXT_DI is adjacent if the local domain is
  710.    adjacent to the domain that has NEXT_DI as its DI, and we say that
  711.    NEXT_ROUTER is adjacent if it represents an IP address of a router
  712.    that shares a link with the current router.  Normal IP forwarding
  713.    refers to forwarding that can be accomplished using FIBs constructed
  714.    via BGP, IDRP or one or more IGPs.
  715.  
  716.    The pseudo code requires sending control messages in a number of
  717.    places.  All such control messages must be sent to the encapsulating
  718.    router, which is indicated in the source address of the delivery
  719.    header.  Note too that all intermediate SDRP routers that process an
  720.    SDRP packet must ensure that the source address of the delivery
  721.    header is left untouched, since this source address is the address of
  722.    the encapsulating router to which any control messages must be sent.
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Estrin, et al                Informational                     [Page 13]
  731.  
  732. RFC 1940                         SDRv1                          May 1996
  733.  
  734.  
  735.      if the packet is a control packet begin
  736.        if the Target Router equals an address assigned to the
  737.          local router begin
  738.          remove the delivery header
  739.          process information carried in the control packet
  740.          return
  741.        end if
  742.        if the packet can be forwarded using normal IP forwarding begin
  743.          set Next Hop Pointer to Source Route Length
  744.          forward the packet using normal IP forwarding
  745.          return
  746.        end if
  747.      end if
  748.  
  749.      if the version field is not 1 begin
  750.        if the packet is a data packet begin
  751.          generate a control packet with "Unimplemented SDRP version"
  752.        end if
  753.        discard the packet
  754.        return
  755.      end if
  756.  
  757.      if the source route protocol type is not 1 begin
  758.        if the packet is a data packet begin
  759.          generate a control packet with "Unimplemented source route
  760.            protocol type"
  761.        end if
  762.        discard the packet
  763.        return
  764.      end if
  765.  
  766.  
  767.  
  768.      if the Hop Count field is greater than 0 begin
  769.        decrement the Hop Count field
  770.      end if
  771.      if the Hop Count field is 0 begin
  772.        if the packet is a data packet begin
  773.          generate a control packet with "Hop Count Exceeded"
  774.       end if
  775.        discard the packet
  776.        return
  777.      end if
  778.  
  779.  
  780.      if the packet is a data packet begin
  781.        if the packet violates transit policy begin
  782.          generate a control packet with "Transit Policy Violation"
  783.  
  784.  
  785.  
  786. Estrin, et al                Informational                     [Page 14]
  787.  
  788. RFC 1940                         SDRv1                          May 1996
  789.  
  790.  
  791.          discard the data packet
  792.          return
  793.        end if
  794.      end if
  795.  
  796.      set mode to NONE
  797.      set advanced to FALSE
  798.      if Next Hop Ptr does not equal Source Route Length begin
  799.        set NEXT_HOP to the next hop in the source route
  800.        while mode equals NONE begin
  801.          if NEXT_HOP is from network 127.0.0.0 begin
  802.            set the Loose/Strict Source Route bit equal to
  803.                the Loose/Strict Source Route Change bit
  804.          else if NEXT_HOP is from network 128.0.0.0 begin
  805.            set NEXT_DI to the least significant two octets of NEXT_HOP
  806.            if NEXT_DI is not equal to LOCAL_DI begin
  807.              set mode to DOMAIN
  808.            end if
  809.          else if NEXT_HOP does not equal an address assigned to the
  810.            local router begin
  811.            set mode to LOCAL
  812.          end if
  813.          if mode equals NONE begin
  814.            set advanced to TRUE
  815.            increment the Next Hop Pointer field
  816.            if Next Hop Pointer equals Source Route Length begin
  817.              set mode to COMPLETE
  818.            else
  819.              set NEXT_HOP to the next hop in the source route
  820.            end if
  821.          end if
  822.        end while
  823.      end if
  824.  
  825.  
  826.      if mode equals DOMAIN begin
  827.        set route to NONE
  828.        if the source route is loose begin
  829.          if not advanced begin
  830.            find the route, if any, based on Prefix and Prefix Length
  831.            if the route is an aggregate formed at the local router begin
  832.              set route to NONE
  833.            end if
  834.          end if
  835.          if route equals NONE begin
  836.            select a BGP or IDRP route, if any, with a path that includes
  837.              NEXT_DI and is not an aggregate formed at the local router
  838.            if route equals NONE begin
  839.  
  840.  
  841.  
  842. Estrin, et al                Informational                     [Page 15]
  843.  
  844. RFC 1940                         SDRv1                          May 1996
  845.  
  846.  
  847.              if the packet is a data packet begin
  848.               generate a control packet with "No Route Available"
  849.              end if
  850.              discard the packet
  851.              return
  852.            end if
  853.            copy the NLRI from the route to the Prefix and Prefix Length
  854.          end if
  855.          if the route is an IDRP route begin
  856.            set appropriate TOS in delivery header
  857.          end if
  858.          set NEXT_ROUTER from the route
  859.        else
  860.          set NEXT_ROUTER from the routing information for NEXT_DI
  861.            using the D-FIB
  862.          if route equals NONE begin
  863.            if the packet is a data packet begin
  864.              generate a control packet with "No Route Available"
  865.            end if
  866.            discard the packet
  867.            return
  868.          end if
  869.          if NEXT_DI is not adjacent begin
  870.            if the packet is a data packet begin
  871.              generate a control packet with "Strict Source Route Failed"
  872.            end if
  873.            discard the packet
  874.            return
  875.          end if
  876.        end if
  877.        end if
  878.      end if
  879.  
  880.  
  881.      if mode equals LOCAL begin
  882.        set NEXT_ROUTER equal to NEXT_HOP
  883.        if the source route is strict and NEXT_ROUTER is not
  884.          adjacent begin
  885.          if the packet is a data packet begin
  886.            generate a control packet with "Strict Source Route Failed"
  887.          end if
  888.          discard the packet
  889.          return
  890.        end if
  891.      end if
  892.  
  893.      if mode equals LOCAL or mode equals DOMAIN begin
  894.        set the destination address of the delivery header equal
  895.  
  896.  
  897.  
  898. Estrin, et al                Informational                     [Page 16]
  899.  
  900. RFC 1940                         SDRv1                          May 1996
  901.  
  902.  
  903.          to NEXT_ROUTER
  904.        checksum the delivery header
  905.        route packet to NEXT_ROUTER using normal IP forwarding
  906.        return
  907.      end if
  908.  
  909.      if the packet is a control packet begin
  910.        discard the packet
  911.      end if
  912.      remove the delivery header and the SDRP Header
  913.      if there is no normal IP route to the payload destination begin
  914.        generate a control packet with "No Route Available"
  915.        discard the data packet
  916.        return
  917.      end if
  918.      forward the payload using normal IP forwarding
  919.      if the probe bit is set begin
  920.        generate a control packet with "Probe Completed"
  921.      end if
  922.  
  923. 5.2.2 Handling an SDRP control packet.
  924.  
  925.    An SDRP control packet is indicated by 0 in the Data packet/Control
  926.    packet bit in the Flags field in the SDRP Header.
  927.  
  928.    If the Target Router field of the received SDRP packet contains an IP
  929.    address that is assigned to the router that received this SDRP
  930.    packet, then the router should use the information carried in the
  931.    Notification Code field, the Source Route Identifier field and the
  932.    information carried in the Payload field to update the status of its
  933.    SDRP routes. Details of such procedures are described in Section 7.
  934.  
  935.    Otherwise, the router checks whether it can forward the packet to the
  936.    router specified in the Target Router field by using the routing
  937.    information present in its local FIB. If forwarding is possible then
  938.    the local system sets the destination address of the delivery header
  939.    to the address specified in the Target Router field, and hands the
  940.    packet off for normal IP forwarding.  If normal IP forwarding is
  941.    impossible then the packet may be forwarded in the same manner as an
  942.    SDRP data packet (described below) but with the following exceptions.
  943.  
  944.       - Control packets are not subject to transit policies.
  945.       - In no case should a control packet be generated in response to
  946.         an error caused by a control packet.
  947.       - If the source route is completely traversed and the packet still
  948.         cannot be forwarded via normal IP routing, the packet should be
  949.         silently dropped.
  950.  
  951.  
  952.  
  953.  
  954. Estrin, et al                Informational                     [Page 17]
  955.  
  956. RFC 1940                         SDRv1                          May 1996
  957.  
  958.  
  959. 5.2.3 Handling an SDRP data packet.
  960.  
  961.    An SDRP data packet is indicated by a one in the Data packet/Control
  962.    packet bit in the Flags field in the SDRP Header.
  963.  
  964.    An SDRP data packet is forwarded by sending the packet along the
  965.    source route in the SDRP Header.  When the source route is completely
  966.    traversed and the packet has reached the destination domain, the
  967.    payload may be removed from the data packet and forwarded normally.
  968.    Further details are described below.
  969.  
  970. 5.2.4 Checking the SDRP version number
  971.  
  972.    An SDRP packet that has a version number other than 1 should be
  973.    discarded.  If the SDRP packet was a data packet, then a control
  974.    packet with the Notification Code "Unimplemented SDRP version" should
  975.    be generated as specified in section 6.
  976.  
  977. 5.2.5 Checking the Source Route Protocol Type
  978.  
  979.    This document describes Source Route Protocol Type 1.  An SDRP router
  980.    may support multiple Source Route Protocol Types; however an SDRP
  981.    router is NOT required to support all defined Source Route Types.
  982.    Any packet that has a Source Route Protocol Type which is not
  983.    supported should be discarded.  If the SDRP packet was a data packet,
  984.    then a control packet with the Notification Code "Unimplemented
  985.    Source Route Protocol Type" should be generated as specified in
  986.    section 6.
  987.  
  988. 5.2.6 Decrementing and checking Hop Count
  989.  
  990.    If an SDRP packet is to be forwarded and the Hop Count field is non-
  991.    zero, the Hop Count field should be decremented.  If the resulting
  992.    value is zero and the packet was a data packet, then a control packet
  993.    with the Notification Code "Hop Count Exceeded" should be generated
  994.    and sent to the encapsulating router as specified in section 6, and
  995.    the packet should be discarded.  If the resulting value is zero and
  996.    the packet was a control packet, the packet should be discarded.  The
  997.    payload of the control packet should carry the payload header
  998.    followed by 64 bits of the payload data of the data packet.
  999.  
  1000. 5.2.7 Upholding transit policies
  1001.  
  1002.    It is not a goal of SDRP to create a security routing system.
  1003.    Therefore, we need to qualify our use of the term "upholding transit
  1004.    policy".  It is assumed that transit policies have the nature of a
  1005.    "gentleperson's agreement", and are upheld by all the participants.
  1006.    In other words, it is assumed that there will be no malicious
  1007.  
  1008.  
  1009.  
  1010. Estrin, et al                Informational                     [Page 18]
  1011.  
  1012. RFC 1940                         SDRv1                          May 1996
  1013.  
  1014.  
  1015.    attempts to violate transit policies and that parties will rely on
  1016.    auditing and post facto detection of violations. When a security
  1017.    architecture is developed for IP or other network protocols then it
  1018.    may be applied to increase the assurance of transit policy
  1019.    enforcement. These issues are beyond the scope of this document.
  1020.  
  1021.    A router may examine any data packet to verify if it complies with
  1022.    local transit policies, as described in section 5.1.  If the
  1023.    verification fails, the router generates a control packet.  If the
  1024.    verification referred to only the contents of the SDRP header, then
  1025.    the payload field of the control packet should be empty. If the
  1026.    verification referred to both the contents of the SDRP header and the
  1027.    payload header, then the payload field of the control packet should
  1028.    carry the payload header.  If the verification referred to the
  1029.    transport protocol header, then the payload field of the control
  1030.    packet should carry the payload header and the transport header.
  1031.  
  1032.    The Notification Code field of the SDRP header in the control packet
  1033.    is set to Transit Policy Violation.  The procedures for constructing
  1034.    the rest of the SDRP Header of the control packet are specified in
  1035.    Section 6.
  1036.  
  1037. 5.2.8 Partially traversed source routes
  1038.  
  1039.    If a router receives an SDRP packet with a partially traversed source
  1040.    route, it extracts the next hop of the source route from the Source
  1041.    Route field. The router locates the high-order byte of the
  1042.    appropriate hop by using the Next Hop Pointer field as a 32 bit word
  1043.    offset relative to the start of the Source Route field.  The next hop
  1044.    is always four octets long.  The following procedure is used to
  1045.    interpret the next hop.
  1046.  
  1047.    Syntactically, each element in the source route appears as an IP
  1048.    address.  There are three encodings for the next hop:
  1049.  
  1050.    a) The next hop is an address in network 127.0.0.0.  In this case,
  1051.    the Loose/Strict Source Route field is set equal to the Loose/Strict
  1052.    Source Route Change bit.  Then the Next Hop Pointer is incremented,
  1053.    the next hop is read from the Source Route field, and these three
  1054.    cases are examined again.
  1055.  
  1056.    b) The next hop is an address in network 128.0.0.0.  In this case,
  1057.    the DI of the next domain is extracted from the least significant two
  1058.    octets of the next hop.  If the extracted DI is the same as the DI of
  1059.    the local domain, then the Next Hop Pointer is incremented, the next
  1060.    hop is read from the Source Route field, and these three cases are
  1061.    examined again.  Otherwise, if the extracted DI is different from the
  1062.    DI of the local domain, the next hop is the extracted DI, and the
  1063.  
  1064.  
  1065.  
  1066. Estrin, et al                Informational                     [Page 19]
  1067.  
  1068. RFC 1940                         SDRv1                          May 1996
  1069.  
  1070.  
  1071.    forwarding process may proceed.
  1072.  
  1073.    c) The next hop is any other IP address.  If the next hop is equal to
  1074.    any IP address assigned to the local router, the Next Hop Pointer is
  1075.    incremented, the next hop is read from the Source Route field, and
  1076.    these three cases examined again.  Otherwise, the next hop is the IP
  1077.    address of the next router in the source route and the forwarding
  1078.    process may proceed.
  1079.  
  1080.    The above procedure for interpreting the next hop in the source route
  1081.    finishes when the next hop is either a router other than the local
  1082.    router or an encoded DI that is not the local DI or a completed
  1083.    source route.
  1084.  
  1085.    If upon termination of this procedure the source route is completely
  1086.    traversed, see section 5.2.9.
  1087.  
  1088. 5.2.8.1 Finding a route to the next hop
  1089.  
  1090.    If the next hop is not a DI, then the destination address in the
  1091.    delivery header is replaced by the next hop address and the resulting
  1092.    packet can then be forwarded using normal IP forwarding.  Otherwise,
  1093.    a DI was extracted from the next hop in the source route, and the
  1094.    following procedure is used to find a route to the next domain.
  1095.  
  1096.    Given the DI of the next domain, the router next consults its D-FIB.
  1097.    If no entry exists in the D-FIB for the next domain, then the packet
  1098.    should be discarded.  If the packet was a data packet, a control
  1099.    message with Notification Code "No Route Available" should be
  1100.    generated as specified in Section 6. No other actions are necessary.
  1101.  
  1102.    If there is a D-FIB entry, the router next examines the SDRP header
  1103.    to determine if the packet specified a strict source route.  If so,
  1104.    and the next domain is not adjacent to the local domain, then a
  1105.    control packet with the Notification Code "Strict Source Route
  1106.    Failed" should be generated, as specified in section 6, and the
  1107.    original packet should be discarded.  No other actions are necessary.
  1108.  
  1109.    If source route is loose, then BGP or IDRP information must be used
  1110.    to insure that there is no loop in reaching the next hop.  If the
  1111.    Next Hop Pointer was incremented when determining the next hop, then
  1112.    the router must select a BGP or IDRP route with a path that includes
  1113.    the extracted DI, and the NLRI for this route is copied into the
  1114.    Prefix Length and Prefix fields.
  1115.  
  1116.    Otherwise, the Next Hop Pointer was not incremented, and the router
  1117.    should use the information carried in the Prefix and Prefix Length as
  1118.    an index into its BGP or IDRP routing table.  If it finds a matching
  1119.  
  1120.  
  1121.  
  1122. Estrin, et al                Informational                     [Page 20]
  1123.  
  1124. RFC 1940                         SDRv1                          May 1996
  1125.  
  1126.  
  1127.    route then it must select the corresponding D-FIB entry.  If the
  1128.    route was formed locally by aggregation, then the router must consult
  1129.    its D-FIB and select any route with a path that includes the
  1130.    extracted DI.  The NLRI for this route should be copied into the
  1131.    Prefix Length and Prefix fields.
  1132.  
  1133.    In either case, the D-FIB entry includes the IP address of the next
  1134.    SDRP-speaking router to which the SDRP packet should be routed.  The
  1135.    destination address in the delivery header is replaced by this
  1136.    address.  The resulting packet can then be forwarded using normal IP
  1137.    forwarding.
  1138.  
  1139. 5.2.8.2 Last Hop Optimization
  1140.  
  1141.    A small optimization can be performed if there is only a single DI or
  1142.    IP address in the source route that has not been traversed.
  1143.  
  1144.    In this case, if the next hop in the SDRP route is a DI, that DI is
  1145.    adjacent to the router processing this packet, the route has a route
  1146.    to the destination address in the payload header in its FIB, and this
  1147.    FIB route passes through the adjacent domain, then the source route
  1148.    may be considered completely traversed and processing may proceed as
  1149.    in section 5.2.9.
  1150.  
  1151.    If the next hop in the SDRP route is an IP address, that IP address
  1152.    is adjacent to the router processing this packet, the router has a
  1153.    route to the destination address in the payload header in its FIB,
  1154.    and this FIB route passes through the adjacent IP address, then the
  1155.    source route may be considered completely traversed and processing
  1156.    may proceed as in section 5.2.9.
  1157.  
  1158.    Since the last hop optimization may only be done if the last hop is
  1159.    directly adjacent, and reachable, it is irrelevant whether the SDRP
  1160.    route specifies that this is a strict source route or a loose source
  1161.    route hop.
  1162.  
  1163. 5.2.9 Completely Traversed source routes
  1164.  
  1165.    If the SDRP packet received by a router with a completely-traversed
  1166.    source route is a control packet and if the Target Router field
  1167.    carries an IP address assigned to the router, then the packet should
  1168.    be processed as specified in Section 7.  Otherwise, if the SDRP
  1169.    packet is a control packet, and the packet cannot be forwarded via
  1170.    either SDRP or normal IP forwarding, the packet should be silently
  1171.    dropped.
  1172.  
  1173.    The Hop Count field has already been decremented when processing the
  1174.    SDRP header.  The Hop Count field should now be copied from the SDRP
  1175.  
  1176.  
  1177.  
  1178. Estrin, et al                Informational                     [Page 21]
  1179.  
  1180. RFC 1940                         SDRv1                          May 1996
  1181.  
  1182.  
  1183.    header into the IP TTL field in the payload header.  The resulting
  1184.    payload packet is then forwarded using normal IP forwarding.  If
  1185.    there is no FIB entry for the destination, then the packet should be
  1186.    discarded and a control message with Notification Code "No Route
  1187.    Available" should be generated as specified in Section 6.  If the
  1188.    packet can be forwarded and if the Probe Indication bit is set to one
  1189.    in the SDRP header, then a control message with Notification Code
  1190.    "Probe Completed" should be generated as specified in section 6. If a
  1191.    control packet is generated, then it must be sent to the
  1192.    encapsulating router.  The payload of the control packet should carry
  1193.    the first 64 bits of the SDRP header and the payload header.
  1194.  
  1195. 6.  Originating SDRP control packets
  1196.  
  1197.    A router sends a control packet in response to either error
  1198.    conditions, or to successful completion of a probe request (indicated
  1199.    via Probe Indication in the Flags field).
  1200.  
  1201.    The Data Packet/Control Packet field is set to indicate Control
  1202.    Packet.  The following fields are copied from the SDRP header of the
  1203.    Data packet that caused the generation of the Control packet:
  1204.  
  1205.       - Loose/Strict Source Route
  1206.       - Source Route Protocol Type
  1207.       - Source Route Identifier
  1208.       - Source Route Length field
  1209.       - Payload Protocol Type
  1210.  
  1211.    A Control packet should not carry a Probe Indication field.
  1212.  
  1213.    A router should never originate a Control packet as the result of an
  1214.    error caused by a control packet.
  1215.  
  1216.    The Target Router is copied from the source IP address of the
  1217.    delivery header of the SDRP Data packet.  This causes the control
  1218.    packet to be returned to the encapsulating router.
  1219.  
  1220.    The router generating a control packet checks its FIB for a route to
  1221.    the destination depicted by the Target Router field.  If such a route
  1222.    is present, then the value of the Destination Address field in the
  1223.    delivery header is set to the Target Router, the Source Address field
  1224.    in the delivery header is set to the IP address of one of the
  1225.    interfaces attached to the local system, and the packet is forwarded
  1226.    via normal IP forwarding.
  1227.  
  1228.    If the FIB does not have a route to the destination depicted by the
  1229.    Target Router field, the local system constructs the Source Route
  1230.    field of the Control packet by reversing the SDRP route carried in
  1231.  
  1232.  
  1233.  
  1234. Estrin, et al                Informational                     [Page 22]
  1235.  
  1236. RFC 1940                         SDRv1                          May 1996
  1237.  
  1238.  
  1239.    the Source Route field of the Data packet, sets the value of the Next
  1240.    Hop Pointer to the value of the Source Route Length field minus the
  1241.    value of the Next Hop Pointer field of the SDRP data packet that
  1242.    caused generation of the Control Packet.  All Loose/Strict Source
  1243.    Route change bits in the new source route should be set to 0 (loose
  1244.    source route).
  1245.  
  1246.    The contents of the Payload field depends on the reason for
  1247.    generating a control packet.
  1248.  
  1249.    The resulting packet is then handled via SDRP Forwarding procedures
  1250.    described in Section 5.2.
  1251.  
  1252. 7.  Processing control information
  1253.  
  1254.    A router participating in SDRP may receive control information in two
  1255.    forms, SDRP control packets from other routers and ICMP messages from
  1256.    routers that do not participate in SDRP, but are involved in
  1257.    forwarding SDRP packets.
  1258.  
  1259. 7.1 Processing SDRP control packets
  1260.  
  1261.    Most control packets carry information about some SDRP routes used by
  1262.    the router.  To correlate information carried in the SDRP control
  1263.    packet with the SDRP routes used by the router, the router uses
  1264.    information carried in the SDRP header of the control packet, and
  1265.    optionally in the SDRP payload of the control packet (if present).
  1266.  
  1267.    In general, receipt of any SDRP control packet that carries one of
  1268.    the following Notification codes
  1269.  
  1270.         -    No Route Available
  1271.  
  1272.         -    Strict Source Route Failed
  1273.  
  1274.         -    Unimplemented SDRP Version
  1275.  
  1276.         -    Unimplemented Source Route Probe Type
  1277.  
  1278.    indicates that the corresponding SDRP route is presently not
  1279.    feasible, and thus should not be used for packet forwarding.  The
  1280.    router must mark the affected routes as not feasible, and may use
  1281.    alternate routes if available.
  1282.  
  1283.    The router may at some later point attempt to use an SDRP route that
  1284.    was marked as infeasible.  The criteria used for retrying routes is
  1285.    outside the scope of this document and a subject of further study.
  1286.    It need not be standardizes and can be a matter of local control.
  1287.  
  1288.  
  1289.  
  1290. Estrin, et al                Informational                     [Page 23]
  1291.  
  1292. RFC 1940                         SDRv1                          May 1996
  1293.  
  1294.  
  1295.    Receipt of an SDRP control packet that carries "Probe Completed"
  1296.    Notification code indicates that the corresponding SDRP route is
  1297.    feasible.
  1298.  
  1299.    Receipt of an SDRP control packet that carries the "Transit Policy
  1300.    Violation" Notification Code shall be interpreted as follows:
  1301.  
  1302.       - If the control packet carries no payload data then the
  1303.         corresponding SDRP route violates transit policy regardless of
  1304.         the content of the payload packet carried along that route.
  1305.       - If the control packet carries only the payload header, then
  1306.         the corresponding SDRP route violates transit policy due to
  1307.         the content of the payload header.
  1308.       - If the control packet carries the payload header and the
  1309.         transport header, then the corresponding SDRP route violates
  1310.         transit policy for the particular combination of payload and
  1311.         transport header contents.
  1312.  
  1313.    If a router receives an SDRP control packet that carries "Hop Count
  1314.    Exceeded" Notification Code, the router should use the information in
  1315.    the payload of the Control packet to construct an ICMP Time Exceeded
  1316.    Message with code "time to live exceeded in transit" and send the
  1317.    message to the host indicated by the source address in the Payload
  1318.    Header.
  1319.  
  1320. 7.2 Processing ICMP messages
  1321.  
  1322.    To correlate information carried in the ICMP messages with the SDRP
  1323.    routes used by the router, the router uses the portion of the SDRP
  1324.    datagram returned by ICMP.  This must contain the Source Route
  1325.    Identifier of the SDRP route used by the router.
  1326.  
  1327.    ICMP Destination Unreachable messages with a code meaning
  1328.    "fragmentation needed and DF set" should be used for SDRP MTU
  1329.    discovery as described in Section 9.
  1330.  
  1331.    All other ICMP Unreachable messages indicate that the associated
  1332.    route is not feasible.
  1333.  
  1334. 8.  Constructing D-FIBs.
  1335.  
  1336.    A BR constructs its D-FIB as a result of participating in either BGP
  1337.    or IDRP. A BR must advertise a route to destinations within its
  1338.    domain to all of its external peers (BRs in adjacent domains), via
  1339.    BGP or IDRP.  In BGP and IDRP, a BR must advertise a route to
  1340.    destinations within its domain to all of its external peers (BRs in
  1341.    adjacent domains).
  1342.  
  1343.  
  1344.  
  1345.  
  1346. Estrin, et al                Informational                     [Page 24]
  1347.  
  1348. RFC 1940                         SDRv1                          May 1996
  1349.  
  1350.  
  1351.    If a BR receives a route to an adjacent domain from a BR in that
  1352.    domain and selects that route as part of its BGP or IDRP Decision
  1353.    Process, then it must propagate this route (via BGP or IDRP) to all
  1354.    other BRs within its domain.  A BR may also propagate such a route if
  1355.    it depicts an autonomous system other than the adjacent domain.
  1356.  
  1357.    Since AS numbers are encoded as network numbers in network 128.0.0.0,
  1358.    it is possible to also advertise a route to a domain in BGP or IDRP.
  1359.  
  1360. 9.  SDRP MTU Discovery
  1361.  
  1362.    To participate in Path MTU Discovery ([6]) a router may maintain
  1363.    information about the maximum length of the payload packet that can
  1364.    be carried without fragmentation along a particular SDRP route.
  1365.  
  1366.    SDRP provides two complimentary techniques to support MTU Discovery.
  1367.  
  1368.    The first one is passive and is based on the receipt of the ICMP
  1369.    Destination Unreachable messages (as described in Section 7.2).  By
  1370.    combining information provided in the ICMP message with local
  1371.    information about the SDRP route the local system can determine the
  1372.    length of a payload packet that would require fragmentation.
  1373.  
  1374.    The second one is active and employs the Probe Indicator bit.  If an
  1375.    SDRP data packet that carries the Probe Indicator bit in the SDRP
  1376.    header and Don't Fragment flag in the delivery header triggers the
  1377.    last router on the SDRP route to return an SDRP Control packet (with
  1378.    the Notification Code "Probe Completed"), then the information
  1379.    carried in the payload header of the control packet can be used to
  1380.    determine the length of the payload packet that went through the SDRP
  1381.    route without fragmentation.
  1382.  
  1383. 10.  Acknowledgments
  1384.  
  1385.    The authors would like to thank Scott Bradner (Harvard University),
  1386.    Noel Chiappa (Consultant), Joel Halpern (Newbridge Networks),
  1387.    Christian Huitema (INRIA), and Curtis Villamizar (ANS) for their
  1388.    comments on various aspects of this document.
  1389.  
  1390. Security Considerations
  1391.  
  1392.    Security issues are not discussed in this memo.
  1393.  
  1394.  
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401.  
  1402. Estrin, et al                Informational                     [Page 25]
  1403.  
  1404. RFC 1940                         SDRv1                          May 1996
  1405.  
  1406.  
  1407. Authors' Addresses
  1408.  
  1409.    Deborah Estrin
  1410.    USC/Information Sciences Institute
  1411.    4676 Admiralty Way
  1412.    Marina Del Rey, Ca 90292-6695.
  1413.  
  1414.    Phone: +1 310 822 1511 x 253
  1415.    EMail: estrin@isi.edu
  1416.  
  1417.  
  1418.    Tony Li
  1419.    cisco Systems, Inc.
  1420.    1525 O'Brien Drive
  1421.    Menlo Park, CA 94025
  1422.  
  1423.    Phone: +1 415 526 8186
  1424.    EMail: tli@cisco.com
  1425.  
  1426.  
  1427.    Yakov Rekhter
  1428.    Cisco systems
  1429.    170 West Tasman Drive
  1430.    San Jose, CA, USA
  1431.  
  1432.    Phone: +1 914 528 0090
  1433.    Fax: +1 408 526-4952
  1434.    EMail: yakov@cisco.com
  1435.  
  1436.  
  1437.    Kannan Varadhan
  1438.    USC/Information Sciences Institute
  1439.    4676 Admiralty Way
  1440.    Marina Del Rey, Ca 90292-6695.
  1441.  
  1442.    Phone: +1 310 822 1511 x 402
  1443.    EMail: kannan@isi.edu
  1444.  
  1445.  
  1446.    Daniel Zappala
  1447.    USC/Information Sciences Institute
  1448.    4676 Admiralty Way
  1449.    Marina Del Rey, Ca 90292-6695.
  1450.  
  1451.    Phone: +1 310 822 1511 x 352
  1452.    EMail: daniel@isi.edu
  1453.  
  1454.  
  1455.  
  1456.  
  1457.  
  1458. Estrin, et al                Informational                     [Page 26]
  1459.  
  1460. RFC 1940                         SDRv1                          May 1996
  1461.  
  1462.  
  1463. References
  1464.  
  1465.    [1] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
  1466.        (BGP-3), RFC 1267, October 1991.
  1467.  
  1468.    [2] Rekhter, Y., and P. Gross, "Application of the Border Gateway
  1469.        Protocol in the Internet", RFC 1268, October 1991.
  1470.  
  1471.    [3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
  1472.        RFC 1654, July 1994.
  1473.  
  1474.    [4] Hares, S., "IDRP for IP", IDR Working Group, 1994.
  1475.        Work in Progress.
  1476.  
  1477.    [5] Postel, J., "Internet Protocol - DARPA Internet Program
  1478.        Protocol Specification", STD 5, RFC 791, September 1981.
  1479.  
  1480.    [6] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
  1481.        November 1990.
  1482.  
  1483.    [7] Reynolds, J., and J. Postel, "ASSIGNED NUMBERS", STD 2,
  1484.        RFC 1700, October 1994.
  1485.  
  1486.  
  1487.  
  1488.  
  1489.  
  1490.  
  1491.  
  1492.  
  1493.  
  1494.  
  1495.  
  1496.  
  1497.  
  1498.  
  1499.  
  1500.  
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  
  1506.  
  1507.  
  1508.  
  1509.  
  1510.  
  1511.  
  1512.  
  1513.  
  1514. Estrin, et al                Informational                     [Page 27]
  1515.  
  1516.