rfc824.txt

RFC 相关的技术文档

        1.  The ability to encapsulate a VLN datagram in a single PLN
            datagram.

        2.  An efficient broadcast addressing mode.

        3.  Natural resistance to datagram replication during
            transmission.

        4.  Sequencing guarantees like those of the VLN interface.

        5.  A strong error-detecting code (datagram checksum).

      Good candidates include Ethernet, the Flexible Intraconnect, and

      Pronet, among others.








                                     21








      DOS-26 Rev A                                Virtual Local Network
      RFC 824



      4  A VLN Implementation Based on Ethernet


           The Ethernet local network specification is the result of a

      collaborative effort by Digital Equipment Corp., Intel Corp., and

      Xerox Corp.  The Version 1.0 specification [3] was released in

      September, 1980. Useful background information on the Ethernet

      internetworking model is supplied in [2].


           The Ethernet VLN implementation begins with the assumption,

      in accordance with the model developed in [2], that the addresses

      of specific Ethernet hosts are arbitrary, 48 bit quantities, not

      under the control of DOS Design/Implementation Project.  The VLN

      implementation must, therefore, develop a strategy to map VLN

      addresses to specific Ethernet addresses.


           A second important assumption is that the VLN-address-to-

      Ethernet-address mapping should not be maintained manually in

      each VLN host.  Manual procedures are too cumbersome and error-

      prone when a local network may consist of hundreds of hosts, and

      hosts may join and leave the network frequently.  A protocol is

      described below which allows hosts to dynamically construct the

      mapping, beginning only with knowledge of their own VLN and




                                     22








      DOS-26 Rev A                                Virtual Local Network
      RFC 824



      Ethernet host addresses.


           The succeeding sections discuss the VLN implementation based

      on the Ethernet PLN in detail, as designed for the Cronus

      prototype currently being assembled by Bolt Beranek and Newman,

      Inc.





      4.1  Datagram Encapsulation


           An internet datagram is encapsulated in an Ethernet frame by

      placing the internet datagram in the Ethernet frame data field,

      and setting the Ethernet type field to "DoD IP".


           To guarantee agreement by the sending and receiving VLN

      components on the ordering of internet datagram octets within an

      encapsulating Ethernet frame, the Ethernet octet ordering is

      required to be consistent with the IP octet ordering.

      Specifically, if IP(i) and IP(j) are internet datagram octets and

      i<j, and EF(k) and EF(l) are the Ethernet frame octets which

      represent IP(i) and IP(j) once encapsulated, then k<l.  Bit






                                     23








      DOS-26 Rev A                                Virtual Local Network
      RFC 824



      orderings within octets must also be consistent. (6)







      4.2  VLN Specific Addressing Mode


           Each VLN component maintains a virtual-to-physical address

      map (the VPMap) which translates a 32 bit specific VLN host

      address (7) in this cluster to a 48 bit Ethernet address.  (8)

      The VPMap data structure and the operations on it can be

      efficiently implemented using standard hashing techniques.  Only

      three operations defined on the VPMap are discussed in this note:

      ClearVPMap, TranslateVtoP, and StoreVPPair.


           Each host has an Ethernet host address (EHA) to which its

      controller will respond, determined by Xerox and the controller

      manufacturer (see Section 4.5.2).  At host initialization time,
      _______________
      (6) See [1] for a lively discussion of the problems arising  from
      the failure of communicants to agree upon consistent orderings.
      (7) Since the high-order 22 bits of the address are constant  for
      all  specific  host addresses in a cluster, only the low-order 10
      bits of the address are significant.
      (8) The least significant bit of the first octet of the  Ethernet
      address  is  always 0, since these are not broadcast or multicast
      addresses.




                                     24








      DOS-26 Rev A                                Virtual Local Network
      RFC 824





       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination Address                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Destination Address (contd.)  |        Source Address         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Source Address (contd.)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type  ("DoD IP")         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |Version|  IHL  |Type of Service|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Total Length           |        Identification         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Flags|     Fragment Offset     |  Time to Live |    Protocol   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Header Checksum         |         Source Address        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Source Address (contd.)    |      Destination Address      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Destination Address (contd.)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      .                                                               .
      .                            Data                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Frame Check Sequence                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Table 3. An Encapsulated Internet Datagram



                                     25








      DOS-26 Rev A                                Virtual Local Network
      RFC 824



      the local VLN component establishes a second host address, the

      multicast host address (MHA), constructed from the host's VLN

      address.  Represented as a sequence of octets in hexadecimal, the

      MHA has the form:



               A  B  C  D  E  F

              09-00-08-00-hh-hh

      A is the first octet transmitted, and F the last.  The two octets

      E and F contain the host local address:



                  E         F

              000000hh  hhhhhhhh
                    ^          ^
                   MSB        LSB


           When the VLN client invokes SendVLNDatagram to send a

      specifically addressed datagram, the local VLN component

      encapsulates the datagram in an Ethernet frame and transmits it

      without delay.  The Source Address in the Ethernet frame is the

      EHA of the sending host.  The Ethernet Destination Address is

      formed from the destination VLN address in the datagram, and is

      either:




                                     26








      DOS-26 Rev A                                Virtual Local Network
      RFC 824



          - the EHA of the destination host, if the TranslateVtoP
            operation on the VPMap succeeds,

        or

          - the MHA formed from the host number in the destination VLN
            address, as described above.


           When a VLN component receives an Ethernet frame with type

      "DoD IP", it decapsulates the internet datagram and delivers it

      to its client.  If the frame was addressed to the EHA of the

      receiving host, no further action is taken, but if the frame was

      addressed to the MHA of the receiving host the VLN component will

      broadcast an update for the VPMaps of the other hosts.  This will

      permit the other hosts to use the EHA of this host for future

      traffic.  The type field of the Ethernet frame containing the

      update is "Cronus VLN", and the format of the data octets in the

      frame is:




       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Subtype ("Mapping Update")  |        Host VLN Address       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Host VLN Address (contd.)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      When a local VLN component receives an Ethernet frame with type



                                     27








      DOS-26 Rev A                                Virtual Local Network
      RFC 824



      "Cronus VLN" and subtype "Mapping Update", it performs a

      StoreVPPair operation using the Ethernet Source Address field and

      the host VLN address sent as frame data.


           This multicast mechanism could be extended to perform other

      address mapping functions, for example, to discover the addresses

      of a cluster's gateways.  Suppose all gateways register the same

      Multicast Gateway Address (MGA, analogous to MHA) with their

      Ethernet controllers; the MGA then becomes a "logical name" for

      the gateway function in a Cronus cluster.  If a host needs to

      send a datagram out of the cluster and doesn't know what specific

      gateway address to use, the host can multicast the datagram to

      all gateways by sending to MGA.  One or more of the gateways can

      forward the datagram, and transmit a "Gateway Mapping Update"

      (containing the gateway's specific Ethernet address) back to the

      originating host.  Specific gateway addresses could be cached in

      a structure similar to the VPMap, keyed to the destination

      network number. (9)

      _______________
      (9) Because the Cronus Advanced Development  Model  will  contain
      only  one  gateway,  a  simpler  mechanism  will  be  implemented
      initially; the specific Ethernet address of the gateway  will  be
      "well-known" to all VLN components.




                                     28








      DOS-26 Rev A                                Virtual Local Network
      RFC 824



           The approach just outlined suggests that all knowledge of

      the existence and connectivity of gateways would be isolated in

      the VLN layer of cluster hosts.  Other mechanisms, e.g., based on

      the ICMP component of the Internet Protocol, could be used

      instead to disseminate information about gateways to cluster

      hosts (see [7]).  These would require, however, specific Ethernet

      addresses to be visible above the VLN layer, a situation the

      current design avoids.






      4.3  VLN Broadcast and Multicast Addressing Modes


           A VLN datagram will be transmitted in broadcast mode if the

      argument to SendVLNDatagram specifies the VLN broadcast address

      (local address = 65,535, decimal) as the destination.  Broadcast

      is implemented in the most straightforward way:  the VLN datagram

      is encapsulated in an Ethernet frame with type "DoD IP", and the

      frame destination address is set to the Ethernet broadcast

      address.  The receiving VLN component merely decapsulates and

      delivers the VLN datagram.





                                     29








      DOS-26 Rev A                                Virtual Local Network
      RFC 824



           The implementation of the VLN multicast addressing mode is

      more complex, for several reasons.  Typically, each VLN host will

      define a constant called Max_Attended, equal to the maximum

      number of VLN multicast addresses which can be simultaneously

      "attended" by this host.  Max_Attended should not be a function

      of the particular Ethernet controller(s) the host may be using,

      but only of the software resources (buffer space and processor

      time) that the host dedicates to VLN multicast processing.  The

      protocol below permits a host to attend any number of VLN

      multicast addresses, from 0 to 64,511 (the entire VLN multicast

      address space), independent of the controller in use.


           Understanding of the VLN multicast protocol requires some

      knowledge of the behavior of existing Ethernet controllers.  The

      Ethernet specification does not specify whether a controller must

      perform multicast address recognition, or if it does, how many

      multicast addresses it must be prepared to recognize.  As a

      result Ethernet controller designs vary widely in their behavior.

      For example, the 3COM Model 3C400 controller follows the first

      pattern and performs no multicast address recognition, instead

      passing all multicast frames to the host for further processing.




                                     30








      DOS-26 Rev A                                Virtual Local Network
      RFC 824



      The Intel Model iSBC 550 controller permits the host to register

      a maximum of 8 multicast addresses with the controller, and the

      Interlan Model NM10 controller permits a maximum of 63 registered

      addresses.


           It would be possible to implement the VLN multicast mode

      using only the Ethernet broadcast mechanism.  This would imply,

      however, that every VLN host would receive and process every VLN

      multicast, often only to discard the datagram because it is

      misaddressed.  More efficient operation is possible if at least

      some Ethernet multicast addresses are used, since Ethernet

      controllers with multicast recognition can discard misaddressed

      frames more rapidly than their hosts, reducing both the processor

      time and buffer space demands upon the host.


           The protocol specified below satisfies the design

      constraints and is especially simple.


           A VLN-wide constant, Min_Attendable, is equal to the