rfc1620.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,067 行 · 第 1/3 页

   (1)  Hop-by-Hop Redirection

        In this approach, the host Redirect mechanism is extended to
        collapse multiple-hop paths within the same shared medium, hop-
        by-hop.  A router is to be allowed to send, and a host allowed
        to accept, a Redirect message that specifies a foreign IP
        address within the same SM.  We refer to this as a "foreign
        Redirect".  Section 4.1 analyzes this approach in some detail.

   (2)  Extended Routing

        Routing protocols can be modified to know about the SM and to
        provide LL addresses.

   (3)  Extended Proxy ARP

        This is a form of the proxy ARP approach, in which the routing
        problem is solved implicitly by an extended address resolution
        mechanism at the LL.  This approach has been described by
        Heinanen [Heinanen93] and by Garrett et al [Garratt93].

   (4)  Route Query Messages

        This approach has been suggested by Halpern [Halpern93].  Rather
        than adding additional information to routing, this approach
        would add a new IP-layer mechanism using end-to-end query and
        reply datagrams.

   These four are discussed in the following four subsections.

   4.1  Hop-by-Hop Redirection

      The first scheme we consider would operate at the IP layer.  It
      would cut out extra hops one by one, with each router in the path



Braden, Postel & Rekhter                                        [Page 7]

RFC 1620              Shared Media IP Architecture              May 1994


      operating on local information only.  This approach requires both
      host and router changes but no routing protocol changes.

      The basic idea is that the first-hop router, upon observing that
      the next hop is within the same SM, sends a foreign Redirect to
      the source, redirecting it to the next hop.  Successive
      application of this algorithm at each intermediate router will
      eventually result in a direct path from source host to destination
      host, if both are within the same SM.

      Suppose that Ha wants to send a datagram to Hd.  We use the
      notation IP.a for the IP address of entity a, and LL.a for the
      corresponding LL address.  Each line in the following shows an IP
      datagram and the path that datagram will follow, separated by a
      colon.  The notation "Redirect( h, IP.a)" means a Redirect
      specifying IP.a as the best next hop to reach host h.

         (1)  Datagram 1: Ha -> R2 -> R3 -> R4 -> Hd

         (2)  Redirect(Hd, IP.R3): R2 -> Ha

         (3)  Datagram 2: Ha -> R3 -> R4 -> Hd

         (4)  Redirect(Hd, IP.R4): R3 -> Ha

         (5)  Datagram 3: Ha -> R4 -> Hd

         (6)  Redirect(Hd, IP.Hd): R4 -> Ha

         (7)  Datagram 4: Ha -> Hd

      There are three problems to be solved to make hop-by-hop
      redirection work; we label them HH1, HH2, and HH3.

      HH1: Each router must be able to resolve the LL address of the
           source Ha, to send a (foreign) Redirect.

           Let us assume that the link layer provides the source LL
           address when an IP datagram arrives.  If the router
           determines that a Redirect should be sent, then it will be
           sent to the source LL address of the received datagram.

      HH2: A source host must be able to perform address resolution to
           obtain the LL address of each router to which it is
           redirected.

           It would be possible for each router R, upon sending a
           Redirect to Ha, to also send an unsolicited ARP Reply point-



Braden, Postel & Rekhter                                        [Page 8]

RFC 1620              Shared Media IP Architecture              May 1994


           to-point to LL.Ha, updating Ha's ARP cache with LL.R.
           However, there is not guarantee that this unsolicited ARP
           Reply would be delivered.  If it was lost, there would be a
           forwarding black hole.  The host could recover by starting
           over from the original default router; however, this may be
           too inefficient a solution.

           A much more direct and efficient solution would introduce an
           extended ICMP Redirect message (call it XRedirect) that
           carries the LL address as well as the IP address of the
           target.  This would remove the issue of reliable delivery of
           the unsolicited ARP described earlier, because the fate of
           the LL address would be shared with the IP target address;
           both would be delivered or neither would.  (An XRedirect is
           essentially the same as a Redirect in the OSI ES-IS
           protocol).

           Using XRedirect, the previous example becomes:

              (1)  Datagram 1: Ha -> R2 -> R3 -> R4 -> Hd

              (2)  XRedirect(Hd, IP.R3, LL.R3): R2 -> Ha

              (3)  Datagram 2: Ha -> R3 -> R4 -> Hd

              (4)  XRedirect(Hd, IP.R4, LL.R4): R3 -> Ha

              (5)  Datagram 3: Ha -> R4 -> Hd

              (6)  XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha

              (7)  Datagram 4: Ha -> Hd

      HH3: Each router should be able to recognize when it is the first
           hop in the path, since a Redirect should be sent only by the
           first hop router.  Unfortunately this will be possible only
           if the LL address corresponding to the IP source address has
           been cached from an earlier event; a router in this chain
           determines the LL address of the source from the arriving
           datagram (see HH1 above).  If it cannot determine whether it
           is the first hop, a router must always send an [X]Redirect,
           which will be spurious if the router is not the first hop.

           Such spurious [X]Redirects will be sent to the IP address of
           the source host, but using the LL address of the previous-hop
           router.  The propagation scope of [X]Redirects can be limited
           to a single IP hop (see below), so they will go no further
           than the previous-hop router, where they will be discarded.



Braden, Postel & Rekhter                                        [Page 9]

RFC 1620              Shared Media IP Architecture              May 1994


           However, there will be some router overhead to process these
           useless [X]Redirects

      Next, we discuss the changes in hosts and in routers required for
      hop-by-hop redirection.

      o    Host Changes

           The Host Requirements RFC [RFC-1122] specifies the host
           mechanism for routing an outbound datagram in terms of
           sending the datagram directly to a local destination or else
           to the first hop router (to reach a foreign destination)
           [RFC-1122 3.3.1].  Although this mechanism assumes a local
           address, a foreign address for a first-hop router should work
           equally well.

           The target address contained in the routing cache is updated
           by Redirect messages.  There is currently a restriction on
           what target addresses may be accepted in Redirect messages
           [RFC-1122 3.2.2.2], which would prevent foreign Redirects
           from working:

                A Redirect message SHOULD be silently discarded if the
                new router address it specifies is not on the same
                connected (sub-) net through which the Redirect arrived,
                or if the source of the Redirect is not the current
                first-hop router for the specified destination.

           To support foreign Redirects requires simply removing the
           first validity check.  The second check, which requires an
           acceptable Redirect to come from the node to which the
           datagram that triggered the Redirect was sent, is retained.
           The same validity check would be used for XRedirects.

           In order to send a datagram to the target address found in
           the routing cache, a host must resolve the IP address into a
           LL address.  No change should be necessary in the host's IP-
           to-LL resolution mechanism to handle a foreign rather than a
           local address.

           The Hop-by-Hop redirection requires changes to the semantics
           of the IP address that an ICMP Redirect is allowed to carry.
           Under the present definition [Postel81b], an ICMP Redirect
           message is only allowed to carry an IP address of a router.
           In order for the hop-by-hop redirection mechanism to
           eliminate all router hops, allowing two hosts connected to
           the same SM to communicate directly, a [X]Redirect message
           must be able to carry the IP address of the destination host.



Braden, Postel & Rekhter                                       [Page 10]

RFC 1620              Shared Media IP Architecture              May 1994


      o    Router Changes

           The router changes required for hop-by-hop redirection are
           much more extensive than the host changes.  The examples
           given earlier showed the additional router functions that
           would be needed.

           Consider a router that is connected to an SM.  When it
           receives a datagram from the SM, it tests whether the next
           hop is on the same SM, and if so, it sends a foreign
           XRedirect to the source host, using the link layer address
           with which the datagram arrived.

           A router should avoid sending more than a limited number of
           successive foreign Redirects to the same host.  This is
           necessary because an unmodified host may legitimately ignore
           a Redirect to a foreign network and continue to forward
           datagrams to the same router.  A router can accomplish this
           limitation by keeping a cache of foreign Redirects sent.

           Note that foreign Redirects generated by routers according to
           these rules, like the current local Redirects, may travel
           exactly one link-layer hop.  It is therefore reasonable and
           desirable to set their TTL to 1, to ensure they cannot stray
           outside the SM.

           The extra check needed to determine whether to generate a
           Redirect may incur additional processing and thus result in a
           performance degradation; to avoid this, a router may not
           perform the check at all but just forward the packet. The
           scheme with [X]Redirects is not applicable to such a router.

           Finally, note that the hop-by-hop redirection scheme is only
           applicable when the source host is connected to an SM, since
           routers do not listen to Redirects.  To optimize the
           forwarding of transit traffic between entry and exit border
           routers, an extension to routing is required, as discussed in
           the following section.  Conversely, an extension to the
           routing protocol cannot be used to optimize forwarding
           traffic from a host connected to the SM, since a host should
           not listen to routing protocols.

   4.2  Extended Routing

      The routing protocols may be modified to carry additional
      information that is specific to the SM.  The router could use the
      attribute "SameSM" for a route to deduce the shortest path to be
      reported to its neighbors.  It could also carry the LL addresses



Braden, Postel & Rekhter                                       [Page 11]

RFC 1620              Shared Media IP Architecture              May 1994


      with each router IP address.

      For example, the extended routing protocol would allow R2 to know
      that R4 is the best next-hop to reach the destination network in
      the same SM, and to know both IP.R4 and LL.R4, leading to the path
      Ha->R2->R4->Hb.  Further optimization cannot be done with extended
      routing alone, since the host does not participate in routing, and
      because we want the routing protocol to handle only per-network
      information, not per-host information.  Hop-by-hop redirection
      could then be used to eliminate all router hops, as in the
      following sequence:

          (1) Datagram 1: Ha -> R2 -> R4 -> Hd

          (2) XRedirect(Hd, IP.R4, LL.R4): R2 -> Ha

          (3) Datagram 2: Ha -> R4 -> Hd

          (4) XRedirect(Hd, IP.Hd, LL.Hd): R4 -> Ha

          (5) Datagram 3: Ha -> Hd

      There are three aspects to the routing protocol extension:

      (1)  the ability to pass "third-party" information -- a router
           should be able to specify the address (IP address and perhaps
           LL address) of some other router as the next-hop;

      (2)  knowledge of the "SameSM" attribute for routes; and

      (3)  knowledge of LL addresses corresponding to IP addresses of
           routers within the same SM.

      A router must be able to determine that a particular IP address
      (e.g., the source address) is in the same SM.  There are several
      possible ways to make this information available to a router in
      the SM.

      (1)  A router may use a single physical interface to an SM; this
           implies that all its logical interfaces lie within the same
           SM.

      (3)  There might be some administrative structure in the IP
           addresses, e.g., all IP addresses within a particular
           national SM might have a common prefix string.

      (3)  There might be configuration information, either local to the
           router or available from some centralized server (e.g, the



Braden, Postel & Rekhter                                       [Page 12]

RFC 1620              Shared Media IP Architecture              May 1994


           DNS).  Note that a router could consult this server in the
           background while continuing to forward datagrams without
           delay.  The only consequence of a delay in obtaining the
           "SameSM" information would be some unnecessary (but
           temporary) hops.

   4.3  Extended Proxy ARP

      The approach of Heinanen [Heinanen93] was intended to solve the
      problem of address resolution in a shared medium with no broadcast
      mechanism ("Non-Broadcast, MultiAccess" or NBMA).  Imagine that
      the shared medium has a single IP network number, i.e., it is one
      network "cloud".  Heinanen envisions a set of AR Servers within
      this medium.  These AR Servers run some routing protocol among
      themselves.  A source host issues an ARP Request (via a point-to-
      point LL transmission) to an AR Server with which it is
      associated.  This ARP Request is forwarded hop-by-hop at the link
      layer through the AR Servers, towards the AR Server that is
      associated with the destination host.  That AR Server resolves the
      address (using information learned from either host advertisement
      or a configuration file), and returns an ARP Reply back through
      the AR Servers to the source host.

              Ha           Hb           Hc           Hd

              |            |            |            |
         ---- | ---------- | ---------- | ---------- | ----
        (                                                  )
        (        Shared Medium (One Logical Network)       )
        (                                                  )
         ----|--|---------|------------|----------|----|---
             |  |         |            |          |    |
       - R1 -   |         |            |          |    --- R5 ---
            ____|__     __|____      __|____     _|_____