rfc1483.txt

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

               | LAN FCS (VC dependent option) |
               +-------------------------------+

   Note that the 802.5 Access Control (AC) field has no significance
   outside the local 802.5 subnetwork.  It can thus be regarded as the
   last octet of the three octet PAD field, which in case of 802.5 can
   be set to any value (XX).










Heinanen                                                       [Page 11]

RFC 1483                Multiprotocol over AAL5                July 1993


                Payload Format for Bridged 802.6 PDUs
               +---------------+---------------+ -------
               |   Reserved    |     BEtag     |  Common
               +---------------+---------------+  PDU
               |            BAsize             |  Header
               +-------------------------------+ -------
               |    MAC destination address    |
               +-------------------------------+
               |                               |
               |   (remainder of MAC frame)    |
               |                               |
               +-------------------------------+
               |                               |
               |     Common PDU Trailer        |
               |                               |
               +-------------------------------+


                Payload Format for BPDUs
               +-------------------------------+
               |                               |
               |      BPDU as defined by       |
               |     802.1(d) or 802.1(g)      |
               |                               |
               +-------------------------------+

   In case of Ethernet, 802.3, 802.4, 802.5, and FDDI PDUs the presense
   or absence of the trailing LAN FCS shall be identified implicitly by
   the VC, since the PID field is not included.  PDUs with the LAN FCS
   and PDUs without the LAN FCS are thus considered to belong to
   different protocols even if the bridged media type would be the same.

6.  Bridging in an ATM Network

   An ATM interface acting as a bridge must be able to flood, forward,
   and filter bridged PDUs.

   Flooding is performed by sending the PDU to all possible appropriate
   destinations.  In the ATM environment this means sending the PDU
   through each relevant VC.  This may be accomplished by explicitly
   copying it to each VC or by using a multicast VC.

   To forward a PDU, a bridge must be able to associate a destination
   MAC address with a VC.  It is unreasonable and perhaps impossible to
   require bridges to statically configure an association of every


   possible destination MAC address with a VC.  Therefore, ATM bridges



Heinanen                                                       [Page 12]

RFC 1483                Multiprotocol over AAL5                July 1993


   must provide enough information to allow an ATM interface to
   dynamically learn about foreign destinations beyond the set of ATM
   stations.

   To accomplish dynamic learning, a bridged PDU shall conform to the
   encapsulation described within section 4.  In this way, the receiving
   ATM interface will know to look into the bridged PDU and learn the
   association between foreign destination and an ATM station.

7. For Further Study

   Due to incomplete standardization of ATM multicasting, addressing,
   and signalling mechanisms, details related to the negotiation of the
   multiplexing method as well as address resolution had to be left for
   further RFCs.

Acknowledgements

   This document has evolved from RFCs [1] and [4] from which much of
   the material has been adopted.  Thanks to their authors T.  Bradley,
   C.  Brown, A. Malis, D. Piscitello, and C. Lawrence.  In addition,
   the expertise of the ATM working group of the IETF has been
   invaluable in completing the document.  Special thanks Brian
   Carpenter of CERN, Rao Cherukuri of IBM, Dan Grossman of Motorola,
   Joel Halpern of Network Systems, Bob Hinden of Sun Mircosystems, and
   Gary Kessler of MAN Technology Corporation for their detailed
   contributions.

Security Considerations

   Security issues are not addressed in this memo.

References

   [1]  Piscitello, D. and Lawrence, C., "The Transmission of IP
        Datagrams over the SMDS Service".  RFC 1209, Bell Communications
        Research, March 1991.

   [2]  CCITT, "Draft Recommendation I.363".  CCITT Study Group XVIII,
        Geneva, 19 - 29 January, 1993.

   [3]  CCITT, "Draft Recommendation I.36x.1".  CCITT Study Group XVIII,
        Geneva, 19-29 January, 1993.

   [4]  Bradley, T., Brown, C., and Malis, A., "Multiprotocol
        Interconnect over Frame Relay".  RFC 1294, Wellfleet
        Communications, Inc. and BBN Communications, January 1992.




Heinanen                                                       [Page 13]

RFC 1483                Multiprotocol over AAL5                July 1993


   [5]  CCITT, "Draft text for Q.93B".  CCITT Study Group XI, 23
        September - 2 October, 1992.

   [6]  Information technology - Telecommunications and Information
        Exchange Between Systems, "Protocol Identification in the
        Network Layer".  ISO/IEC TR 9577, October 1990.

   [7]  Postel, J. and Reynolds, J., "A Standard for the Transmission of
        IP Datagrams over IEEE 802 Networks".  RFC 1042, ISI, February,
        1988.

Appendix A.  Multiprotocol Encapsulation over FR-SSCS

   I.36x.1 defines a Frame Relaying Specific Convergence Sublayer (FR-
   SSCS) to be used on the top of the Common Part Convergence Sublayer
   CPCS) of the AAL type 5 for Frame Relay/ATM interworking.  The
   service offered by FR-SSCS corresponds to the Core service for Frame
   Relaying as described in I.233.

   An FR-SSCS-PDU consists of Q.922 Address field followed by Q.922
   Information field.  The Q.922 flags and the FCS are omitted, since
   the corresponding functions are provided by the AAL.  The figure
   below shows an FR-SSCS-PDU embedded in the Payload of an AAL5 CPCS-
   PDU.

                FR-SSCS-PDU in Payload of AAL5 CPCS-PDU
               +-------------------------------+ -------
               |      Q.922 Address Field      | FR-SSCS-PDU Header
               |         (2-4 octets)          |
               +-------------------------------+ -------
               |             .                 |
               |             .                 |
               |    Q.922 Information field    | FR-SSCS-PDU Payload
               |             .                 |
               |             .                 |
               +-------------------------------+ -------
               |      AAL5 CPCS-PDU Trailer    |
               +-------------------------------+

   Routed and bridged PDUs are encapsulated inside the FR-SSCS-PDU as
   defined in RFC 1294.  The Q.922 Information field starts with a Q.922
   Control field followed by an optional Pad octet that is used to align
   the remainder of the frame to a convenient boundary for the sender.
   The protocol of the carried PDU is then identified by prefixing the
   PDU by an ISO/CCITT Network Layer Protocol ID (NLPID).

   In the particular case of an IP PDU, the NLPID is 0xCC and the FR-
   SSCS-PDU has the following format:



Heinanen                                                       [Page 14]

RFC 1483                Multiprotocol over AAL5                July 1993


                FR-SSCS-PDU Format for Routed IP PDUs
               +-------------------------------+
               |       Q.922 Addr Field        |
               |       (2 or 4 octets)         |
               +-------------------------------+
               |     0x03 (Q.922 Control)      |
               +-------------------------------+
               |          NLPID  0xCC          |
               +-------------------------------+
               |             .                 |
               |           IP PDU              |
               |    (up to 2^16 - 5 octets)    |
               |             .                 |
               +-------------------------------+

   Note that according to RFC 1294 the Q.922 Address field shall be
   either 2 or 4 octets, i.e., a 3 octet Address field is not supported.

   In the particular case of a CLNP PDU, the NLPID is 0x81 and the FR-
   SSCS-PDU has the following format:

                FR-SSCS-PDU Format for Routed CLNP PDUs
               +-------------------------------+
               |       Q.922 Addr Field        |
               |       (2 or 4 octets)         |
               +-------------------------------+
               |     0x03 (Q.922 Control)      |
               +-------------------------------+
               |         NLPID  0x81           |
               +-------------------------------+
               |              .                |
               |       Rest of CLNP PDU        |
               |    (up to 2^16 - 5 octets)    |
               |              .                |
               +-------------------------------+

   Note that in case of ISO protocols the NLPID field forms the first
   octet of the PDU itself and shall thus not be repeated.

   The above encapsulation applies only to those routed protocols that
   have a unique NLPID assigned.  For other routed protocols (and for
   bridged protocols), it is necessary to provide another mechanism for
   easy protocol identification.  This can be achieved by using an NLPID
   value 0x80 to indicate that an IEEE 802.1a SubNetwork Attachment
   Point (SNAP) header follows.

   See RFC 1294 for more details related to multiprotocol encapsulation
   over FRCS.



Heinanen                                                       [Page 15]

RFC 1483                Multiprotocol over AAL5                July 1993


Appendix B.  List of Locally Assigned values of OUI 00-80-C2

             with preserved FCS   w/o preserved FCS    Media
            ------------------   -----------------    --------------
             0x00-01              0x00-07              802.3/Ethernet
             0x00-02              0x00-08              802.4
             0x00-03              0x00-09              802.5
             0x00-04              0x00-0A              FDDI
             0x00-05              0x00-0B              802.6
                                  0x00-0D              Fragments
                                  0x00-0E              BPDUs

Appendix C.  Partial List of NLPIDs

         0x00    Null Network Layer or Inactive Set (not used with ATM)
         0x80    SNAP
         0x81    ISO CLNP
         0x82    ISO ESIS
         0x83    ISO ISIS
         0xCC    Internet IP

Author's Address

   Juha Heinanen
   Telecom Finland
   PO Box 228
   SF-33101 Tampere
   Finland

   Phone: [phone]

   Email: [e-mail]



















Heinanen                                                       [Page 16]