rfc1620.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,067 行 · 第 1/3 页
TXT
1,067 行
Network Working Group B. Braden
Request for Comments: 1620 ISI
Category: Informational J. Postel
ISI
Y. Rekhter
IBM Research
May 1994
Internet Architecture Extensions for Shared Media
Status of This Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
The original Internet architecture assumed that each network is
labeled with a single IP network number. This assumption may be
violated for shared media, including "large public data networks"
(LPDNs). The architecture still works if this assumption is
violated, but it does not have a means to prevent multiple host-
router and router-router hops through the shared medium. This memo
discusses alternative approaches to extending the Internet
architecture to eliminate some or all unnecessary hops.
Table of Contents
1. INTRODUCTION .................................................. 2
2. THE ORIGINAL INTERNET ARCHITECTURE ............................ 2
3. THE PROBLEMS INTRODUCED BY SHARED MEDIA ....................... 4
4. SOME SOLUTIONS TO THE SM PROBLEMS ............................. 7
4.1 Hop-by-Hop Redirection ................................... 7
4.2 Extended Routing ......................................... 11
4.3 Extended Proxy ARP ....................................... 13
4.4 Routing Query Messages ................................... 14
4.5 Stale Routing Information ................................ 14
4.6 Implications of Filtering (Firewalls) .................... 15
5. SECURITY CONSIDERATIONS ....................................... 16
6. CONCLUSIONS ................................................... 17
7. ACKNOWLEDGMENTS ............................................... 17
8. REFERENCES .................................................... 18
Authors' Addresses ............................................... 19
Braden, Postel & Rekhter [Page 1]
RFC 1620 Shared Media IP Architecture May 1994
1. INTRODUCTION
This memo concerns the implications of shared medium networks for the
architecture of the TCP/IP protocol suite. General familiarity with
the TCP/IP architecture and the IP protocol is assumed.
The Internet architecture is founded upon what was originally called
the "Catenet model" [PSC81]. Under this model, the Internet
(originally dubbed "the Catenet") is formed using routers (originally
called "gateways") to interconnect distinct and perhaps diverse
networks. An IP host address (more correctly characterized as a
network interface address) is formed of the pair (net#,host#). Here
"net#" is a unique IP number assigned to the network (or subnet) to
which the host is attached, and "host#" identifies the host on that
network (or subnet).
The original Internet model made the implicit assumptions that each
network has a single IP network number and that networks with
different numbers may interchange packets only through routers.
These assumptions may be violated for networks implemented using a
common "shared medium" (SM) at the link layer (LL). For example,
network managers sometimes configure multiple IP network numbers
(usually subnet numbers) on a single broadcast-type LAN such as an
Ethernet. The large (switched) public data networks (LPDNs), such as
SMDS and B-ISDN, form a potentially more important example of shared
medium networks. Any two systems connected to the same shared medium
network are capable of communicating directly at the LL, without IP
layer switching by routers. This presents an opportunity to optimize
performance and perhaps lower cost by eliminating unnecessary LL hops
through the medium.
This memo discusses how unnecessary hops can be eliminated in a
shared medium, while retaining the coherence of the existing Internet
architecture. This issue has arisen in a number of IETF Working
Groups concerned with LPDNs, including IPLPDN, IP over ATM, IDRP for
IP, and BGP. It is time to take a careful look at the architectural
issues to be solved. This memo first summarizes the relevant aspects
of the original Internet architecture (Section 2), and then it
explains the extra-hop problems created by shared media networks
(Section 3). Finally, it discusses some possible solutions (Section
4).
2. THE ORIGINAL INTERNET ARCHITECTURE
We very briefly review the original architecture, to introduce the
terminology and concepts. Figure 1 illustrates a typical set of four
networks A, ... D, represented traditionally as clouds,
interconnected by routers R2, R3, and R4. Routers R1 and R5 connect
Braden, Postel & Rekhter [Page 2]
RFC 1620 Shared Media IP Architecture May 1994
to other parts of the Internet. Ha, ... Hd represent hosts connected
to these networks.
It is not necessary to distinguish between network and subnet in this
memo. We may assume that there is some address mask associated with
each "network" in Figure 1, allowing a host or router to divide the
32 bits of an IP address into an address for the cloud and a host
number that is defined uniquely only within that cloud.
Ha Hb Hc Hd
| | | |
| | | |
_|_ _|_ _|_ _|_
( ) ( ) ( ) ( )
(Net) (Net) (Net) (Net)
( A ) ( B ) ( C ) ( D )
- R1 --( )-- R2 --( )-- R3 --( )-- R4 --( )-- R5 --
( ) ( ) ( ) ( )
(___) (___) (___) (___)
Figure 1. Example Internet Fragment
An Internet router is connected to local network(s) as a special kind
of host. Indeed, for network management purposes, a router plays the
role of a host by originating and terminating datagrams. However,
there is an important difference between a host and a router: the
routing function is mostly centralized in the routers, allowing hosts
to be "dumb" about routing. Internet hosts are required [RFC-1122]
to make only one simple routing decision: is the destination address
local to the connected network? If the address is not local, we say
it is "foreign" (relative to the connected network or to the host).
A host sends a datagram directly to a local destination address or
(for a foreign destination) to a first-hop router. The host
initially uses some "default" router for any new destination address.
If the default is the wrong choice, that router returns a Redirect
message and forwards the datagram. The Redirect message specifies
the preferred first-hop router for the given destination address.
The host uses this information, which it maintains in a "routing
cache" [RFC-1122], to determine the first-hop address for subsequent
datagrams to the same destination.
To actually forward an IP datagram across a network hop, the sender
must have the link layer (LL) address of the target. Therefore, each
host and router must have some "address resolution" procedure to map
IP address to an LL address. ARP, used for networks with broadcast
capability, is the most common address resolution procedure
Braden, Postel & Rekhter [Page 3]
RFC 1620 Shared Media IP Architecture May 1994
[Plummer82]. If there is no LL broadcast capability (or if it is too
expensive), then there are two other approaches to address
resolution: local configuration tables, and "address-resolution
servers" (AR Servers).
If AR Servers are used for address resolution, hosts must be
configured with the LL address(es) of one or more nearby servers.
The mapping information provided by AR Servers might itself be
collected using a protocol that allows systems to register their LL
addresses, or from static configuration tables. The ARP packet
format and the overall ARP protocol structure (ARP Request/ARP Reply)
may be suitable for the communications between a host and an AR
server, even in the absence of the LL broadcast capabilities; this
would ease conversion of hosts to using AR Servers.
The examples in this memo use ARP for address resolution. At least
some of the LPDN's that are planned will provide sufficient broadcast
capability to support ARP. It is important to note that ARP operates
at the link layer, while the Redirect and routing cache mechanisms
operate at the IP layer of the protocol stack.
3. THE PROBLEMS INTRODUCED BY SHARED MEDIA
Figure 2 shows the same configuration as Figure 1, but now networks
A, B, C, and D are all within the same shared medium (SM), shown by
the dashed box enclosing the clouds. Networks A, ... D are now
logical IP networks (called LIS's in [Laubach93]) rather than
physical networks. Each of these logical networks may (or may not)
be administratively distinct. The SM allows direct connectivity
between any two hosts or routers connected to it. For example, host
Ha can interchange datagrams directly with host Hd or with router R4.
A router that has some but not all of its interfaces connected to the
shared medium is called a "border router"; R1 and R5 are examples.
Figure 2 illustrates the "classical" model [Laubach93] for use of the
Internet architecture within a shared medium, i.e., simply applying
the original Internet architecture described earlier. This will
provide correct but not optimal operation. For example, in the case
of two hosts on the same logical network (not shown in Figure 2), the
original rules will clearly work; the source host will forward a
datagram directly in a single hop to a host on the same logical
network. The original architectural rules will also work for
communication between any pair of hosts shown in Figure 2; for
example, host Ha would send a datagram to host Hd via the four-hop
path Ha -> R2 -> R3 -> R4 -> Hd. However, the classical model does
not take advantage of the direct connectivity Ha -> Hd allowed by the
shared medium.
Braden, Postel & Rekhter [Page 4]
RFC 1620 Shared Media IP Architecture May 1994
Ha Hb Hc Hd
| | | |
---- | ---------- | ---------- | ---------- | ----
| __|__ __|__ __|__ __|__ |
( ) ( ) ( ) ( )
| ( ) ( ) ( ) ( ) |
( Net ) ( Net ) ( Net ) ( Net )
| ( A ) ( B ) ( C ) ( D ) |
( ) ( ) ( ) ( )
| ( ) ( ) ( ) ( ) |
(_____) (_____) (_____) ( ____)
| | | | | | | | | |
--- | | -------- | | -------- | | -------- | | ---
| | | | | | | |
- R1 - --- R2 --- --- R3 --- --- R4 --- --- R5 ---
Figure 2. Logical IP Networks in Shared Medium
This memo concerns mechanisms to achieve minimal-hop connectivity
when it is desired. We should note that is may not always be
desirable to achieve minimal-hop connectivity in a shared medium.
For example, the "extra" hops may be needed to allow the routers to
act as administrative firewalls. On the other hand, when such
firewall protection is not required, it should be possible to take
advantage of the shared medium to allow this datagram to use shorter
paths. In general, it should be possible to choose between firewall
security and efficient connectivity. This is discussed further in
Section 4.6 below.
We also note that the mechanisms described here can only optimize the
path within the local SM. When the SM is only one segment of the
path between source and receiver, removing hops locally may limit the
ability to switch to globally more optimal paths that may become
available as the result of routing changes. Thus, consider Ha-
>...Hx, where host Hx is outside the SM to which host Ha is attached.
Suppose that the shortest global path to Hx is via some border router
Rb1. Local optimization using the techniques described below will
remove extra hops in the SM and allow Ha->Rb1->...Hx. Now suppose
that a later route change outside the SM makes the path Ha->Rb2-
>...Hx more globally optimum, where Rb2 is another border router.
Since Ha does not participate in the routing protocol, it does not
know that it should switch to Rb2. It is possible that Rb2 may not
realize it either; this is the situation:
GC(Ha->Rb2->...Hx) < GC(Ha->Rb1->Rb2->...Hx) < GC(Ha->Rb1->...Hx)
Braden, Postel & Rekhter [Page 5]
RFC 1620 Shared Media IP Architecture May 1994
where GC() represents some global cost function of the specified
path.
Note that ARP requires LL broadcast. Even if the SM supports
broadcast, it is likely that administrators will erect firewalls to
keep broadcasts local to their LIS.
There are three cases to be optimized. Suppose H and H' are hosts
and Rb and Rb' are border routers connected to the same same SM.
Then the following one-hop paths should be possible:
H -> H': Host to host within the SM
H -> Rb: Host to exit router
Rb -> Rb': Entry border router to exit border router,
for transit traffic.
We may or not be able to remove the extra hop implicit in Rb -> R ->
H, where Rb, R, and H are within the same SM, but the ultimate source
is outside the SM. To remove this hop would require distribution of
host routes, not just network routes, between the two routers R and
Rb; this would adversely impact routing scalability.
There are a number of important requirements for any architectural
solution to these problems.
* Interoperability
Modified hosts and routers must interoperate with unmodified
nodes.
* Practicality
Minimal software changes should be required.
* Robustness
The new scheme must be at least as robust against errors in
software, configuration, or transmission as the existing
architecture.
* Security
The new scheme must be at least as securable against subversion
as the existing architecture.
Braden, Postel & Rekhter [Page 6]
RFC 1620 Shared Media IP Architecture May 1994
The distinction between host and router is very significant from an
engineering viewpoint. It is considered to be much harder to make a
global change in host software than to change router software,
because there are many more hosts and host vendors than routers and
router vendors, and because hosts are less centrally administered
than routers. If it is necessary to change the specification of what
a host does (and it is), then we must minimize the extent of this
change.
4. SOME SOLUTIONS TO THE SM PROBLEMS
Four different approaches have been suggested for solving these SM
problems.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?