rfc1620.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,067 行 · 第 1/3 页
TXT
1,067 行
(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 ---
____|__ __|____ __|____ _|_____
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?