rfc1940.txt

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

5.2.8.2 Last Hop Optimization

   A small optimization can be performed if there is only a single DI or
   IP address in the source route that has not been traversed.

   In this case, if the next hop in the SDRP route is a DI, that DI is
   adjacent to the router processing this packet, the route has a route
   to the destination address in the payload header in its FIB, and this
   FIB route passes through the adjacent domain, then the source route
   may be considered completely traversed and processing may proceed as
   in section 5.2.9.

   If the next hop in the SDRP route is an IP address, that IP address
   is adjacent to the router processing this packet, the router has a
   route to the destination address in the payload header in its FIB,
   and this FIB route passes through the adjacent IP address, then the
   source route may be considered completely traversed and processing
   may proceed as in section 5.2.9.

   Since the last hop optimization may only be done if the last hop is
   directly adjacent, and reachable, it is irrelevant whether the SDRP
   route specifies that this is a strict source route or a loose source
   route hop.

5.2.9 Completely Traversed source routes

   If the SDRP packet received by a router with a completely-traversed
   source route is a control packet and if the Target Router field
   carries an IP address assigned to the router, then the packet should
   be processed as specified in Section 7.  Otherwise, if the SDRP
   packet is a control packet, and the packet cannot be forwarded via
   either SDRP or normal IP forwarding, the packet should be silently
   dropped.

   The Hop Count field has already been decremented when processing the
   SDRP header.  The Hop Count field should now be copied from the SDRP



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


   header into the IP TTL field in the payload header.  The resulting
   payload packet is then forwarded using normal IP forwarding.  If
   there is no FIB entry for the destination, then the packet should be
   discarded and a control message with Notification Code "No Route
   Available" should be generated as specified in Section 6.  If the
   packet can be forwarded and if the Probe Indication bit is set to one
   in the SDRP header, then a control message with Notification Code
   "Probe Completed" should be generated as specified in section 6. If a
   control packet is generated, then it must be sent to the
   encapsulating router.  The payload of the control packet should carry
   the first 64 bits of the SDRP header and the payload header.

6.  Originating SDRP control packets

   A router sends a control packet in response to either error
   conditions, or to successful completion of a probe request (indicated
   via Probe Indication in the Flags field).

   The Data Packet/Control Packet field is set to indicate Control
   Packet.  The following fields are copied from the SDRP header of the
   Data packet that caused the generation of the Control packet:

      - Loose/Strict Source Route
      - Source Route Protocol Type
      - Source Route Identifier
      - Source Route Length field
      - Payload Protocol Type

   A Control packet should not carry a Probe Indication field.

   A router should never originate a Control packet as the result of an
   error caused by a control packet.

   The Target Router is copied from the source IP address of the
   delivery header of the SDRP Data packet.  This causes the control
   packet to be returned to the encapsulating router.

   The router generating a control packet checks its FIB for a route to
   the destination depicted by the Target Router field.  If such a route
   is present, then the value of the Destination Address field in the
   delivery header is set to the Target Router, the Source Address field
   in the delivery header is set to the IP address of one of the
   interfaces attached to the local system, and the packet is forwarded
   via normal IP forwarding.

   If the FIB does not have a route to the destination depicted by the
   Target Router field, the local system constructs the Source Route
   field of the Control packet by reversing the SDRP route carried in



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


   the Source Route field of the Data packet, sets the value of the Next
   Hop Pointer to the value of the Source Route Length field minus the
   value of the Next Hop Pointer field of the SDRP data packet that
   caused generation of the Control Packet.  All Loose/Strict Source
   Route change bits in the new source route should be set to 0 (loose
   source route).

   The contents of the Payload field depends on the reason for
   generating a control packet.

   The resulting packet is then handled via SDRP Forwarding procedures
   described in Section 5.2.

7.  Processing control information

   A router participating in SDRP may receive control information in two
   forms, SDRP control packets from other routers and ICMP messages from
   routers that do not participate in SDRP, but are involved in
   forwarding SDRP packets.

7.1 Processing SDRP control packets

   Most control packets carry information about some SDRP routes used by
   the router.  To correlate information carried in the SDRP control
   packet with the SDRP routes used by the router, the router uses
   information carried in the SDRP header of the control packet, and
   optionally in the SDRP payload of the control packet (if present).

   In general, receipt of any SDRP control packet that carries one of
   the following Notification codes

        -    No Route Available

        -    Strict Source Route Failed

        -    Unimplemented SDRP Version

        -    Unimplemented Source Route Probe Type

   indicates that the corresponding SDRP route is presently not
   feasible, and thus should not be used for packet forwarding.  The
   router must mark the affected routes as not feasible, and may use
   alternate routes if available.

   The router may at some later point attempt to use an SDRP route that
   was marked as infeasible.  The criteria used for retrying routes is
   outside the scope of this document and a subject of further study.
   It need not be standardizes and can be a matter of local control.



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


   Receipt of an SDRP control packet that carries "Probe Completed"
   Notification code indicates that the corresponding SDRP route is
   feasible.

   Receipt of an SDRP control packet that carries the "Transit Policy
   Violation" Notification Code shall be interpreted as follows:

      - If the control packet carries no payload data then the
        corresponding SDRP route violates transit policy regardless of
        the content of the payload packet carried along that route.
      - If the control packet carries only the payload header, then
        the corresponding SDRP route violates transit policy due to
        the content of the payload header.
      - If the control packet carries the payload header and the
        transport header, then the corresponding SDRP route violates
        transit policy for the particular combination of payload and
        transport header contents.

   If a router receives an SDRP control packet that carries "Hop Count
   Exceeded" Notification Code, the router should use the information in
   the payload of the Control packet to construct an ICMP Time Exceeded
   Message with code "time to live exceeded in transit" and send the
   message to the host indicated by the source address in the Payload
   Header.

7.2 Processing ICMP messages

   To correlate information carried in the ICMP messages with the SDRP
   routes used by the router, the router uses the portion of the SDRP
   datagram returned by ICMP.  This must contain the Source Route
   Identifier of the SDRP route used by the router.

   ICMP Destination Unreachable messages with a code meaning
   "fragmentation needed and DF set" should be used for SDRP MTU
   discovery as described in Section 9.

   All other ICMP Unreachable messages indicate that the associated
   route is not feasible.

8.  Constructing D-FIBs.

   A BR constructs its D-FIB as a result of participating in either BGP
   or IDRP. A BR must advertise a route to destinations within its
   domain to all of its external peers (BRs in adjacent domains), via
   BGP or IDRP.  In BGP and IDRP, a BR must advertise a route to
   destinations within its domain to all of its external peers (BRs in
   adjacent domains).




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


   If a BR receives a route to an adjacent domain from a BR in that
   domain and selects that route as part of its BGP or IDRP Decision
   Process, then it must propagate this route (via BGP or IDRP) to all
   other BRs within its domain.  A BR may also propagate such a route if
   it depicts an autonomous system other than the adjacent domain.

   Since AS numbers are encoded as network numbers in network 128.0.0.0,
   it is possible to also advertise a route to a domain in BGP or IDRP.

9.  SDRP MTU Discovery

   To participate in Path MTU Discovery ([6]) a router may maintain
   information about the maximum length of the payload packet that can
   be carried without fragmentation along a particular SDRP route.

   SDRP provides two complimentary techniques to support MTU Discovery.

   The first one is passive and is based on the receipt of the ICMP
   Destination Unreachable messages (as described in Section 7.2).  By
   combining information provided in the ICMP message with local
   information about the SDRP route the local system can determine the
   length of a payload packet that would require fragmentation.

   The second one is active and employs the Probe Indicator bit.  If an
   SDRP data packet that carries the Probe Indicator bit in the SDRP
   header and Don't Fragment flag in the delivery header triggers the
   last router on the SDRP route to return an SDRP Control packet (with
   the Notification Code "Probe Completed"), then the information
   carried in the payload header of the control packet can be used to
   determine the length of the payload packet that went through the SDRP
   route without fragmentation.

10.  Acknowledgments

   The authors would like to thank Scott Bradner (Harvard University),
   Noel Chiappa (Consultant), Joel Halpern (Newbridge Networks),
   Christian Huitema (INRIA), and Curtis Villamizar (ANS) for their
   comments on various aspects of this document.

Security Considerations

   Security issues are not discussed in this memo.









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


Authors' Addresses

   Deborah Estrin
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina Del Rey, Ca 90292-6695.

   Phone: [phone] x 253
   EMail: [e-mail]


   Tony Li
   cisco Systems, Inc.
   1525 O'Brien Drive
   Menlo Park, CA 94025

   Phone: [phone]
   EMail: [e-mail]


   Yakov Rekhter
   Cisco systems
   170 West Tasman Drive
   San Jose, CA, USA

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Kannan Varadhan
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina Del Rey, Ca 90292-6695.

   Phone: [phone] x 402
   EMail: [e-mail]


   Daniel Zappala
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina Del Rey, Ca 90292-6695.

   Phone: [phone] x 352
   EMail: [e-mail]





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


References

   [1] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3
       (BGP-3), RFC 1267, October 1991.

   [2] Rekhter, Y., and P. Gross, "Application of the Border Gateway
       Protocol in the Internet", RFC 1268, October 1991.

   [3] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
       RFC 1654, July 1994.

   [4] Hares, S., "IDRP for IP", IDR Working Group, 1994.
       Work in Progress.

   [5] Postel, J., "Internet Protocol - DARPA Internet Program
       Protocol Specification", STD 5, RFC 791, September 1981.

   [6] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
       November 1990.

   [7] Reynolds, J., and J. Postel, "ASSIGNED NUMBERS", STD 2,
       RFC 1700, October 1994.





























Estrin, et al                Informational                     [Page 27]