rfc1940.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      Prefix Length (1 octet)

         The Prefix Length field indicates the length in bits of the IP
         address prefix.  A length of zero indicates a prefix that
         matches all IP addresses.

            Notification Code (1 octet)

               This field is only meaningful in control packets.  In
               data packets, this field is transmitted as zero, and
               should be ignored on receipt.



Estrin, et al                Informational                      [Page 7]

RFC 1940                         SDRv1                          May 1996


               This document defines the following values for the
               Notification Code:

               1 - No Route Available

               2 - Strict Source Route Failed

               3 - Transit Policy Violation

               4 - Hop Count Exceeded

               5 - Probe Completed

               6 - Unimplemented SDRP version

               7 - Unimplemented Source Route Protocol Type

               8 - Setup Request Rejected

      Source Route Length (1 octet)

         The Source Route Length field indicates the length in 32 bit
         words of the domain level source route carried in the SDRP
         Header.

      Next Hop Pointer (1 octet)

         The Next Hop Pointer field indicates the offset of the high-
         order byte of the next hop along the route that the packet has
         to be forwarded.  This offset is relative to the start of the
         Source Route field; so if the value of the Next Hop Pointer
         field equals the value of the Source Route Length field, then
         the entire source route has been completely traversed.  All
         other source routes are said to be incompletely traversed.

      Source Route (variable)

         The components of the source route are syntactically IP
         addresses.

         An IP address from network 128.0.0.0 is used to encode a next
         hop that is a domain.  The least significant two octets contain
         the DI, which is an Internet Autonomous System number.








Estrin, et al                Informational                      [Page 8]

RFC 1940                         SDRv1                          May 1996


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      128      .       0       |             D. I.             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


         An IP address from the network 127.0.0.0 is used to encode
         characteristics of the source route.  The least significant
         three octets are used as a Source Route Change field.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      127      |          Source     Route     Change          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Source Route Change (3 octets)

            Loose/Strict Source Route Change (bit 1)

               The Loose/Strict Source Route Change bit reflects a new
               value of the Loose/Strict Source Route bit in the SDRP
               header.  The value of the Loose/Strict Source Route
               Change bit is copied into the Loose/Strict Source Route
               bit in the SDRP header when a Source Route Change field
               is encountered in processing an SDRP packet.

            The rest of the Source Route Change field is transmitted as
            zero, and should be ignored on receipt.

      Payload (variable)

         The Payload field carries the datagram originated by the end-
         system within the domain that constructed the SDRP packet. The
         Payload field forms the data portion of the SDRP packet.  In a
         control packet this field may be empty or may carry the payload
         header of the packet that triggered the control message (see
         5.2.5).  Note that there is no padding between the Source Route
         and the Payload, and that the Payload may start at any
         arbitrary octet boundary.










Estrin, et al                Informational                      [Page 9]

RFC 1940                         SDRv1                          May 1996


4.  Originating SDRP Data packets

   This document assumes that a router that originates SDRP packets is
   preconfigured with a set of SDRP routes.  Procedures for constructing
   these routes are outside the scope of this document.  SDRP packet
   forwarding may be deployed initially without additional routing
   protocol support.

   An application on a source host generates packets that must be
   delivered to a given destination.  The packet traverses the Internet
   by following normal hop-by-hop routing information.  An intermediate
   router in the path between the source host and the destination host
   may decide to forward some of these packets via SDRP.

   When this router receives an IP datagram, the router uses the
   information in the datagram and the local criteria to determine
   whether the datagram should be forwarded along a particular SDRP
   route.  Associated with each set of criteria is a set of one or more
   SDRP routes that should be used to route matching packets.  The exact
   nature of the criteria is a local matter.  The only restrictions this
   document places on the applicability of SDRP routes is that an IP
   datagram that contains a strict source route should not be forwarded
   along an SDRP route, that SDRP encapsulation should never be applied
   to an SDRP packet, and that if SDRP is used with inter-domain routes,
   the destination domain must also run SDRP.

   If the router decides to forward a datagram along a particular SDRP
   route, the router constructs the SDRP packet by placing the original
   datagram into the Payload field of the SDRP packet and constructing
   the SDRP header based on the selected SDRP route.  The Next Hop
   pointer is set to 0 (the first entry in the Source Route field of the
   SDRP packet).  The value of the Time To Live field in the payload
   header should be copied into the Hop Count field of the SDRP header.

   Even if we assume that interior routing is loop free, it is possible,
   either due to the state of inter-domain routing or due to other SDRP
   routers, that a domain level source route that does not terminate
   with the intended destination domain may lead a packet into a routing
   loop.  Originating SDRP routers that wish to insure that this does
   not occur should include a final domain level hop of the
   destination's domain, i.e. specify the SDRP route as <DI1, DI2, DI3>
   instead of <DI1, DI2>, if the destination host is in domain DI3.  The
   means for determining the DI of the destination domain is outside of
   the scope of this document.

   Similarly, when using SDRP for interior routing, it is possible that
   the source route does not coincide with IGP routing.  In this case,
   one means of preventing a loop is to specify the last hop router's IP



Estrin, et al                Informational                     [Page 10]

RFC 1940                         SDRv1                          May 1996


   address as the last address within the source route.  The
   encapsulating router can do this by specifying the source route to
   reach destination host IP3 as <IP1, IP2, IP3> instead of <IP1, IP2>.

   The source address field in the delivery header should contain an IP
   address of the router. The value of the Don't Fragment flag of the
   delivery header is copied from the Don't Fragment flag of the payload
   header.  The value of the Type Of Service field in the delivery
   header is copied from the Type Of Service field in the payload
   header.  If the payload header contains an IP security option, that
   option is replicated as an option in the delivery header.  All other
   IP options in the payload header must be ignored.

   If the SDRP route that is used is learned from IDRP, then the TOS
   corresponding to this route is copied into the TOS field in the
   delivery header.

   The resulting SDRP packet is then forwarded as described in Section
   5.2.2.

   If the encapsulating router decides to forward a datagram along a
   particular SDRP route that has an MTU smaller than the length of the
   datagram, then if the payload header has the Don't Fragment flag set
   to 1, the router should generate an ICMP Destination Unreachable
   message with a code meaning "fragmentation needed and DF set" in
   accordance with [6].  The ICMP message must be sent to the original
   source host.  The router should then discard the original datagram.

   If a router has learned an MTU for a particular SDRP route, either
   via ICMP messages or via configuration information, and it determines
   that an SDRP packet must be fragmented before transmission, then it
   first calculates the the effective MTU seen by the payload packet.
   If the effective MTU is greater than or equal to 512 bytes, the
   router SHOULD first fragment the payload packet using normal IP
   fragmentation.  SDRP packets are then constructed for each fragment,
   as describe above.  Otherwise, the router should first form the SDRP
   packet, and then fragment it.

   A router may use locally originated  SDRP packets to verify the
   feasibility of its SDRP routes. To do this the router sets the value
   of the Probe Indicator field in the SDRP packet to 1.  Receipt of an
   SDRP control packet by the originating router with the "Probe
   Completed" Notification Code (see Section 7.1) indicates feasibility
   of the SDRP route.  Persistent lack of SDRP control packets with the
   "Probe Completed" Notification Code should be used as an indication
   that the associated SDRP route is not feasible.





Estrin, et al                Informational                     [Page 11]

RFC 1940                         SDRv1                          May 1996


5.  Processing SDRP packets

   We say that a router receives an SDRP packet if the destination
   address field in the delivery header of the packet arriving at the
   router contains one of the IP addresses of the router.

   When a router receives an SDRP packet, the router extracts the Source
   Route Protocol field from the SDRP header.

5.1 Supporting Transit Policies

   A router may be able to verify that a packet that it is given to
   forward does not violate any of the transit policies that may exist,
   of the domain to which the router belongs.  Specific verification
   mechanisms are a matter that is local to the router and are outside
   the scope of this document.

   The restriction on the verification mechanisms is that they may take
   into account only the contents of the SDRP header, the payload
   header, and transport protocol header of the payload packet.

   With SDRP a domain may enforce its transit policies by applying
   filters based on the information present in the IP Header. For
   example a router may initially carefully filter all SDRP traffic from
   all possible sources. A filter that allows certain SDRP traffic from
   selected sources to pass through the router could then be installed
   dynamically to pass similar types of traffic.  Thus, by caching
   appropriate filtering information, a transit domain can efficiently
   support transit policies.  Other mechanisms for supporting transit
   policy and implementation techniques are not precluded by this
   document.

   If the router detects that the SDRP packet violates a domain's
   transit policy it sends back an SDRP control packet to the
   encapsulating router and discards the violating packet.

   SDRP control packets are not subject to transit policies.

   If a router does not discard an SDRP packet due to a transit policy
   violation, then the router attempts to forward it as specified in
   Section 5.2.

5.2 Forwarding SDRP packets

   Procedures for forwarding of an SDRP packet depend on

      a) whether the router has the routing information needed to
         forward the packet;



Estrin, et al                Informational                     [Page 12]

RFC 1940                         SDRv1                          May 1996


      b) whether the SDRP route has been completely traversed;
      c) whether the SDRP route is strict or loose, and
      d) whether the packet is a data or control packet.

   When forwarding an SDRP packet (either data or control) a router
   should not modify the following fields in the delivery header:

      a) Source Address
      b) Don't Fragment flag

   If the Source Route Protocol Type of a packet indicates a Route Setup
   and the router does not or cannot support setup, the router MAY send
   the encapsulating router a control packet with a Notification Code of
   Setup Request Rejected.  It MAY then modify the data packet so that
   the Source Route Protocol Type is Explicit Source Route and the Probe
   Indicator bit is 0, then forwards the packet as described below.  The
   router MAY send notification of a failed setup request only
   periodically.  Alternately, a router MAY silently drop the Route
   Setup packet.

5.2.1 Forwarding algorithm pseudo-code

   The following pseudo-code gives an overview of the SDRP forwarding
   algorithm.  Please consult the text below for more details.

   Let LOCAL_DI be the DI of the domain of the local system, let
   NEXT_HOP be the next hop in the source route if the source route has
   not been completely traversed, let NEXT_DI be the DI portion of
   NEXT_HOP if NEXT_HOP is from network 128.0.0.0, and let NEXT_ROUTER
   be the IP address of the next router if the packet is to be forwarded
   using SDRP.  We say that NEXT_DI is adjacent if the local domain is
   adjacent to the domain that has NEXT_DI as its DI, and we say that
   NEXT_ROUTER is adjacent if it represents an IP address of a router
   that shares a link with the current router.  Normal IP forwarding
   refers to forwarding that can be accomplished using FIBs constructed
   via BGP, IDRP or one or more IGPs.

   The pseudo code requires sending control messages in a number of
   places.  All such control messages must be sent to the encapsulating
   router, which is indicated in the source address of the delivery
   header.  Note too that all intermediate SDRP routers that process an
   SDRP packet must ensure that the source address of the delivery
   header is left untouched, since this source address is the address of
   the encapsulating router to which any control messages must be sent.







Estrin, et al                Informational                     [Page 13]

RFC 1940                         SDRv1                          May 1996


     if the packet is a control packet begin
       if the Target Router equals an address assigned to the
         local router begin
         remove the delivery header
         process information carried in the control packet
         return
       end if
       if the packet can be forwarded using normal IP forwarding begin
         set Next Hop Pointer to Source Route Length
         forward the packet using normal IP forwarding
         return
       end if
     end if

     if the version field is not 1 begin
       if the packet is a data packet begin
         generate a control packet with "Unimplemented SDRP version"
       end if
       discard the packet
       return
     end if

     if the source route protocol type is not 1 begin
       if the packet is a data packet begin