📄 rfc824.txt
字号:
smallest number of Ethernet multicast addresses that can be
simultaneously attended by any host in the VLN, or 64,511,
whichever is smaller. A network composed of hosts with the Intel
31
DOS-26 Rev A Virtual Local Network
RFC 824
and Interlan controllers mentioned above, for example, would have
Min_Attendable equal to 7; (10) a network composed only of hosts
with 3COM Model 3C400 controllers would have Min_Attendable equal
to 64,511, since the controller itself does not restrict the
number of Ethernet multicast addresses to which a host may
attend. (11)
The local address field of a VLN multicast address can be
represented in two octets, in hexadecimal:
mm-mm
From Table 1, mm-mm considered as a decimal integer M is in the
range 1,024 to 65,534. When SendVLNDatagram is invoked with a
VLN multicast datagram, there are two cases:
1. (M - 1,023) <= Min_Attendable. In this case, the datagram
is encapsulated in a "DoD IP" Ethernet frame, and multicast
with the Ethernet address
09-00-08-00-mm-mm
A VLN component which attends VLN multicast addresses in
_______________
(10) Min_Attendable is 7, rather than 8, because one multicast
slot in the controller must be reserved for the host's MHA, as
described in Section 4.2.
(11) For the Cronus Advanced Development Model, Min_Attendable is
currently defined to be 60.
32
DOS-26 Rev A Virtual Local Network
RFC 824
this range should receive Ethernet multicast addresses in
this format, if necessary by registering the addresses with
its Ethernet controller.
2. (M - 1,023) > Min_Attendable. The datagram is encapsulated
in a "DoD IP" Ethernet frame, and transmitted to the
Ethernet broadcast address. A VLN component which attends
VLN multicast addresses in this range must receive all
broadcast frames, and filter them on the basis of frame
type and VLN destination address (found in the IP
destination address field).
There are two drawbacks to this protocol that might induce a
more complex design: 1) because Min_Attendable is the "lowest
common denominator" for the ability of Ethernet controllers to
recognize multicast addresses, some controller capabilities may
be wasted; 2) small VLN addresses (less than Max_Attendable +
1,024) will probably be handled more efficiently than large VLN
multicast addresses. The second factor complicates the
assignment of VLN multicast addresses to functions, since the
particular assignment affects multicast performance.
33
DOS-26 Rev A Virtual Local Network
RFC 824
4.4 Reliability Guarantees
Delivered datagrams are accurate copies of transmitted
datagrams because VLN components do not deliver incoming
datagrams with invalid Frame Check Sequences. The 32 bit CRC
error detecting code applied to Ethernet frames is very powerful,
and the probability of an undetected error occuring "on the wire"
is very small. The probability of an error being introduced
before the checksum is computed or after it is checked is
comparable to the probability of an error in a disk subsystem
before a write operation or after a read; often, but not always,
it can be ignored.
Datagram duplication does not occur because the VLN layer
does not perform datagram retransmissions, the primary source of
duplicates in other networks. Ethernet controllers do perform
retransmission as a result of "collisions" on the channel, but
the "collision enforcement" or "jam" assures that no controller
receives a valid frame if a collision occurs.
The sequencing guarantees hold because mutually exclusive
access to the transmission medium defines a total ordering on
34
DOS-26 Rev A Virtual Local Network
RFC 824
Ethernet transmissions, and because a VLN component buffers all
datagrams in FIFO order, if it buffers more than one datagram.
4.5 Use of Assigned Numbers
On a philosophical note, protocols such as IP and TCP exist
to provide communication services to extensible sets of clients;
new clients and usages continue to emerge over the life of a
protocol. Because a protocol implementation must have some
unambiguous knowledge of the "names" of the clients, sockets,
hosts, networks, etc., with which it interacts, a need arises for
the continuing administration of the 'assigned numbers' related
to the protocol. Typically the organization which declares a
protocol to be a standard also becomes the administrator for its
assigned numbers. The organization will designate an office to
assign numbers to the clients, sockets, hosts, networks, etc.,
that emerge over time. The office will also prepare lists of
number assignments that are distributed to protocol users; the
reference [4] is a list of this kind.
35
DOS-26 Rev A Virtual Local Network
RFC 824
There are three organizations responsible for number
assignment related to the Ethernet-based VLN implementation:
DARPA, Xerox, and the DOS Design/Implementation Project; their
respective roles are described below.
4.5.1 DARPA
DARPA administers the internet network number and internet
protocol number assignments. The Ethernet-based VLN
implementation does not involve DARPA assigned numbers, but any
particular 'instance' of a Cronus VLN is expected to have a class
A or B internet network number assigned by DARPA. For example,
the prototype Cronus system (the Advanced Development Model)
being constructed at Bolt Beranek and Newman, Inc., has class B
network number 128.011.xxx.xxx.
Protocols built above the VLN will make use of other DARPA
assigned numbers, e.g., the Cronus object-operation protocol
requires an internet protocol number.
36
DOS-26 Rev A Virtual Local Network
RFC 824
4.5.2 The Xerox Ethernet Address Administration Office
The Ethernet Address Administration Office at Xerox Corp.
administers Ethernet specific and multicast address assignments,
and Ethernet frame type assignments.
It is the intent of the Xerox internetworking model that
every Ethernet host have a distinct specific address, and that
the address space be large enough to accomodate a very large
population of inexpensive hosts (e.g., personal workstations).
They have therefore chosen to delegate the authority to assign
specific addresses to the manufacturers of Ethernet controllers,
by granting them large blocks of addresses on request.
Manufacturers are expected to assign specific addresses from
these blocks densely, e.g., sequentially, one per controller, and
to consume all of them before requesting another block.
The preceding paragraph explains the Xerox address
assignment policy not because the DOS Design/Implementation
Project intends to manufacture Ethernet controllers (!), but
because Xerox has chosen to couple the assignment of specific and
multicast Ethernet addresses. An assigned block is defined by a
37
DOS-26 Rev A Virtual Local Network
RFC 824
23-bit constant, which specifies the contents of the first three
octets of an Ethernet address, except for the broadcast/multicast
bit (the least significant bit of the first octet). The
possessor of an assigned block thus has in hand 2**24 specific
addresses and 2**24 multicast addresses, to parcel out as
necessary.
The block assigned for use in the Cronus system is defined
by the octets 08-00-08 (hex). The specific addresses in this
block range from 08-00-08-00-00-00 to 08-00-08-FF-FF-FF (hex),
and the multicast addresses range from 09-00-08-00-00-00 to 09-
00-08-FF-FF-FF (hex). Only a fraction of the multicast addresses
are actually utilized, as explained in Sections 4.2 and 4.3.
The Ethernet Address Administration Office has designated a
public frame type, "DoD IP", 08-00 (hex), to be used for
encapsulated internet protocol datagrams. The Ethernet VLN
implementation uses this frame type exclusively for datagram
encapsulation. In addition, the Cronus system uses two private
Ethernet frame types, assigned by the Ethernet Address
Administration Office:
38
DOS-26 Rev A Virtual Local Network
RFC 824
NAME TYPE
Cronus VLN 80-03
Cronus Direct 80-04
(The use of the "Cronus Direct" frame type is not described in
this note.)
The same Ethernet address and frame type assignments will be
used by every instance of a Cronus VLN; no further assignments
from the Ethernet Address Administration Office are anticipated.
4.5.3 The DOS Design/Implementation Project
The DOS Design/Implementation Project assumes responsibility
for the assignment of subtypes of the Ethernet frame type "Cronus
VLN". No assignments of subtypes for purposes unrelated to the
Cronus system design are expected, nor are assignments to other
organizations. The subtypes currently assigned are:
39
DOS-26 Rev A Virtual Local Network
RFC 824
NAME SUBTYPE
Mapping Update 00-01
40
DOS-26 Rev A Virtual Local Network
RFC 824
REFERENCES
[1]
"On holy wars and a plea for peace," Danny Cohen, Computer,
V 14 N 10, October 1981, pp. 48-54.
[2]
"48-bit absolute internet and Ethernet host numbers," Yogen
K. Dalal and Robert S. Printis, Proc. of the 7th Data
Communications Symposium, October 1981.
[3]
"The Ethernet: a local area network, data link layer and
physical layer specifications," Digital Equipment Corp., Intel
Corp., and Xerox Corp., Version 1.0, September 1980.
[4]
"Assigned numbers," Jon Postel, RFC 790, USC/Information
Sciences Institute, September 1981.
[5]
"Internet Protocol - DARPA internet program protocol
specification," Jon Postel, ed., RFC 791, USC/Information
Sciences Institute, September 1981.
[6]
"Internet protocol transition workbook," Network Information
Center, SRI International, Menlo Park, California, March 1982.
[7]
"IP - Local Area Network Addressing Issues," Robert Gurwitz
and Robert Hinden, Bolt Beranek and Newman Inc., (draft)
August 1982.
41
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -