rfc1209.txt

<VC++网络游戏建摸与实现>源代码

        hexadecimal).

      o The EtherType for IP is 2048 (decimal), 0800 (Internet
        hexadecimal).  The EtherType for ARP is 2054 (decimal), 0806
        (Internet hexadecimal).

   IEEE 802.2 LLC Type One Unnumbered Information (UI) communication
   (which must be implemented by all conforming IEEE 802.2 stations) is
   used exclusively.  The Higher Layer Protocol Id (HLPI) field in the
   SIP L3_PDU header MUST be set to the IEEE 802.6 assigned Protocol Id
   value for LLC (decimal 1) [8].  All frames MUST be transmitted in
   standard IEEE 802.2 LLC Type 1 Unnumbered Information format, with
   the DSAP and the SSAP fields of the IEEE 802.2 header set to the
   assigned global SAP value for SNAP (decimal 170) [10].  The 24-bit
   Org Code (Organizationally Unique Identifier Code) in the SNAP MUST
   be set to a value of zero, and the remaining 16 bits are set to the
   EtherType value from Assigned Numbers [11] (2048 for IP, 2054 for
   ARP).

   The data link encapsulation for IP packets is shown in Figure 3 and
   for ARP in Figure 4.  All values shown are in Internet hexadecimal
   format.





IP over SMDS Working Group                                      [Page 6]

RFC 1209            IP and ARP over the SMDS Service          March 1991


     +--------------+---------------------------------------+-------+
     |      SIP     |             LLC / SNAP                |  IP   |
     |              |                                       |       |
     |SIP..|HLPI|...|DSAP|SSAP|Ctrl|   Org Code   |Ethertype|       |
     +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
     |SIP..| 01 |...| AA | AA | 03 |    000000    |  0800   | IP... |
     +-----+----+-+-+----+----+----+----+----+----+----+----+-------+

             Figure 3.  IP Data Link Encapsulation and Values



     +--------------+---------------------------------------+-------+
     |      SIP     |             LLC / SNAP                |  ARP  |
     |              |                                       |       |
     |SIP..|HLPI|...|DSAP|SSAP|Ctrl|   Org Code   |Ethertype|       |
     +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
     |SIP..| 01 |...| AA | AA | 03 |    000000    |  0806   | ARP...|
     +-----+----+-+-+----+----+----+----+----+----+----+----+-------+

             Figure 4.  ARP Data Link Encapsulation and Values

Address Resolution

   The dynamic mapping of 32-bit Internet addresses to SMDS addresses
   SHALL be done via the dynamic discovery procedure of the Address
   Resolution Protocol (ARP) [2].

   Internet addresses are assigned independent of SMDS addresses.  Each
   host implementation MUST know its own Internet address and SMDS
   address and respond to Address Resolution requests appropriately.
   Hosts MUST also use ARP to map Internet addresses to SMDS addresses
   when needed.

   The ARP protocol has several fields that parameterize its use in any
   specific context [2].  These fields are:

           ar$hrd   16 - bits     The Hardware Type Code
           ar$pro   16 - bits     The Protocol Type Code
           ar$hln    8 - bits     Octets in each hardware address
           ar$pln    8 - bits     Octets in each protocol address
           ar$op    16 - bits     Operation Code

      o The hardware type code assigned to SMDS addresses is 14
        (decimal), 0E (Internet hexadecimal) [11].

      o The protocol type code for IP is 2048 (decimal), 0800
        (Internet hexadecimal) [11].



IP over SMDS Working Group                                      [Page 7]

RFC 1209            IP and ARP over the SMDS Service          March 1991


      o The hardware address length for SMDS is 8.

      o The protocol address length for IP is 4.

      o The operation code is 1 for request and 2 for reply.

   The SMDS hardware addresses in ARP packets (ar$sha, ar$tha) MUST be
   carried in SMDS native address format, with the most significant bit
   of the Address Type sub-field as the high order bit of the first
   octet.  Although outside the scope of this document, it is
   RECOMMENDED that SMDS addresses be represented in this format in all
   higher layer Internet protocols (e.g., SNMP).

   Traditionally, ARP requests are broadcast to all directly connected
   stations.  For the SMDS Service, the ARP request packet is
   transmitted to the smds$arp-req hardware address.  In the LIS
   configuration, the smds$arp-req address is set to smds$lis-ga, (the
   SMDS group address that identifies all members of the LIS).  It is
   conceivable that in a larger scale, public configuration, the
   smds$arp-req address would be configured to the address of some ARP-
   server(s) instead of the group address that identifies the entire
   LIS.

IP Broadcast Address

   There is no facility for complete hardware broadcast addressing over
   the SMDS Service.  As discussed in the "LIS Configuration" section,
   an SMDS group address (smds$lis-ga) SHALL be configured to include
   all stations in the same LIS.  The broadcast Internet address (the
   address on that network with a host part of all binary ones) MUST be
   mapped to smds$lis-ga (see also [12]).

IP Multicast Support

   A method of supporting IP multicasting is specified in [13].  It
   would be desirable to fully utilize the SMDS group address
   capabilities to support IP multicasting.  However, the method in [13]
   requires a Network Service Interface which provides multicast-like
   ability to provide dynamic access to the local network service
   interface operations:

      o JoinLocalGroup (group-address)

      o LeaveLocalGroup (group-address)

   The SMDS group address ability does not currently support dynamic
   subscription and removal from group address lists.  Therefore, it is
   RECOMMENDED that in the LIS configuration, if IP multicasting is to



IP over SMDS Working Group                                      [Page 8]

RFC 1209            IP and ARP over the SMDS Service          March 1991


   be supported, the method of IP multicasting described for pure
   broadcast media, such as the Experimental Ethernet, be used.  For
   this method, all Multicast IP addresses are mapped to the same SMDS
   address which the broadcast Internet address is mapped for a given
   LIS.  Thus all Multicast IP addresses are mapped to smds$lis-ga.
   Filtering of multicast packets MUST be performed in the destination
   host.

Trailer Formats

   Some versions of Unix 4.x BSD use a different encapsulation method in
   order to get better network performance with the VAX virtual memory
   architecture.  Trailers SHALL not be used over the SMDS Service.

Byte Order

   As described in Appendix B of the Internet Protocol specification
   [1], the IP datagram is transmitted over the SMDS Service as a series
   of 8-bit bytes.  The byte order of the IP datagram shall be mapped
   directly onto the native SMDS byte order.

MAC Sublayer Details

Packet Size

   The SMDS Service defines a maximum service data unit size of 9188
   information octets.  This leaves 9180 octets for user data after the
   LLC/SNAP header is taken into account.  Therefore, the MTU for IP
   stations operating over the network supporting the SMDS Service SHALL
   be 9180 octets.

   There is no minimum packet size restriction defined for the SMDS
   Service.

Other MAC Sublayer Issues

   The SMDS Service requires that the publicly administered 60-bit
   address plus 4-bit type field format SHALL be used in both source and
   destination address fields of the SIP L3_PDU [3].

IEEE 802.2 Details

   While not necessary for supporting IP and ARP, all implementations
   MUST support IEEE 802.2 standard Class I service in order to be
   compliant with IEEE 802.2.  Some of the functions are not related
   directly to the support of the SNAP SAP (e.g., responding to XID and
   TEST commands directed to the null or global SAP addresses), but are
   part of a general LLC implementation.  Both [4] and [5] describe the



IP over SMDS Working Group                                      [Page 9]

RFC 1209            IP and ARP over the SMDS Service          March 1991


   minimum functionality necessary for a conformant station.
   Implementors should also consult IEEE Std. 802.2 [14] for details.

REFERENCES

    1. Postel, J., "Internet Protocol", RFC 791, USC/Information
       Sciences Institute, September 1981.

    2. Plummer, D., "An Ethernet Address Resolution Protocol - or -
       Converting Network Protocol Addresses to 48.bit Ethernet Address
       for Transmission on Ethernet Hardware", RFC 826, MIT, November
       1982.

    3. "Generic Systems Requirements in support of Switched Multi-
       megabit Data Service", Technical Advisory TA-TSY-000772, Bellcore
       Technical Advisory, Issue 3, October 1989.

    4. Postel, J., and J. Reynolds, "A Standard for the Transmission of
       IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information
       Sciences Institute, February 1988.

    5. Katz, D., "A Proposed Standard for the Transmission of IP
       Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET, October
       1990.

    6. Dix, F., Kelly, M., and R. Klessig, "Access to a Public Switched
       Multi-Megabit Data Service Offering", ACM SIGCOMM CCR, July 1990.

    7. Hemrick, C. and L. Lang, "Introduction to Switched Multi-megabit
       Data Service (SMDS), an Early Broadband Service", publication
       pending in the Proceedings of the XIII International Switching
       Symposium (ISS 90), May 27, 1990 - June 1, 1990.

    8. Institute of Electrical & Electronic Engineers, Inc. IEEE
       Standard 802.6, "Distributed Queue Dual Bus (DQDB) Subnetwork of
       a Metropolitan Area Network (MAN) Standard", December 1990.

    9. IEEE, "IEEE Standards for Local Area Networks: Logical Link
       Control", IEEE, New York, New York, 1985.

   10. IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.

   11. Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
       USC/Information Sciences Institute, March 1990.

   12. Braden, R., and J. Postel, "Requirements for Internet Gateways",
       RFC 1009, USC/Information Sciences Institute, June 1987.




IP over SMDS Working Group                                     [Page 10]

RFC 1209            IP and ARP over the SMDS Service          March 1991


   13. Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
       Stanford University, August 1989.

   14. IEEE,"ANSI/IEEE Std 802.2-1985, ISO Draft International Standard
       8802/2", IEEE, New York, New York, 1985.

Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Dave Piscitello
   Bell Communications Research
   331 Newman Springs Road
   Red Bank, NJ  07701

   Phone: [phone]

   EMail: [e-mail]


   Joseph Lawrence
   Bell Communications Research
   331 Newman Springs Road
   Red Bank, NJ  07701

   Phone: [phone]

   EMail: [e-mail]





















IP over SMDS Working Group                                     [Page 11]