rfc2684.txt

RFC 的详细文档！

   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 2427.  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/IEC TR 9577 Network Layer Protocol ID (NLPID).

















Grossman & Heinanen         Standards Track                    [Page 18]

RFC 2684                Multiprotocol Over AALS           September 1999


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

                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 2427, the Q.922 Address field MUST be
   either 2 or 4 octets, i.e., a 3 octet Address field MUST NOT be used.

   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 MUST 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.



Grossman & Heinanen         Standards Track                    [Page 19]

RFC 2684                Multiprotocol Over AALS           September 1999


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

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

Appendix D. Applications of multiprotocol encapsulation

   Mutiprotocol encapsulation is necessary, but generally not
   sufficient, for routing and bridging over the ATM networks.   Since
   the publication of RFC 1483 (the predecessor of this memo), several
   system specifications were developed by the IETF and the ATM Forum to
   address various aspects of, or scenarios for, bridged or routed
   protocols.  This appendix summarizes these applications.

   1) Point-to-point connection between routers and bridges --
      multiprotocol encapsulation over ATM PVCs has been used to provide
      a simple point-to-point link between bridges and routers across an
      ATM network.  Some amount of manual configuration (e.g., in lieu
      of INARP) was necessary in these scenarios.

   2) Classical IP over ATM -- RFC 2225 (formerly RFC 1577) provides an
      environment where the ATM network serves as a logical IP subnet
      (LIS). ATM PVCs are supported, with address resolution provided by
      INARP.  For ATM SVCs, a new form of ARP, ATMARP, operates over the
      ATM network between a host (or router) and an ATMARP server.
      Where servers are replicated to provide higher availability or
      performance, a Server Synchronization Cache Protocol (SCSP)
      defined in RFC 2335 is used. Classical IP over ATM defaults to the
      LLC/SNAP encapsulation.



Grossman & Heinanen         Standards Track                    [Page 20]

RFC 2684                Multiprotocol Over AALS           September 1999


   3) LAN Emulation -- The ATM Forum LAN Emulation specification
      provides an environment where the ATM network is enhanced by LAN
      Emulation Server(s) to behave as a bridged LAN.  Stations obtain
      configuration information from, and register with, a LAN Emulation
      Configuration Server;  they resolve MAC addresses to ATM addresses
      through the services of a LAN Emulation Server;  they can send
      broadcast and multicast frames, and also send unicast frames for
      which they have no direct VC to a Broadcast and Unicast Server.
      LANE uses the VC multiplexing encapsulation foramts for Bridged
      Etherent/802.3 (without LAN FCS) or Bridged 802.5 (without LAN
      FCS) for the Data Direct, LE Multicast Send and Multicast Forward
      VCCS.  However, the initial PAD field described in this memo is
      used as an LE header, and might not be set to all '0'.

   4) Next Hop Resolution Protocol (NHRP) -- In some cases, the
      constraint that Classical IP over ATM serve a single LIS limits
      performance.  NHRP, as defined in RFC 2332, extends Classical to
      allow 'shortcuts' over a an ATM network that supports several
      LISs.

   5) Multiprotocol over ATM (MPOA) -- The ATM Forum Multiprotocol over
      ATM Specification integrates LANE and NHRP to provide a generic
      bridging/routing environment.

   6) IP Multicast -- RFC 2022 extends Classical IP to support IP
      multicast.  A multicast address resolution server (MARS) is used
      possibly in conjunction with a multicast server to provide IP
      multicast behavior over ATM point-to-multipoint and/or point to
      point virtual connections.

   7) PPP over ATM -- RFC 2364 extends multiprotocol over ATM to the
      case where the encapsulated protocol is the Point-to-Point
      protocols.  Both the VC based multiplexing and LLC/SNAP
      encapsulations are used.  This approach is used when the ATM
      network is used as a point-to-point link and PPP functions are
      required.

Appendix E Differences from RFC 1483

   This memo replaces RFC 1483.  It was intended to remove anachronisms,
   provide clarifications of ambiguities discovered by implementors or
   created by changes to the base standards, and advance this work
   through the IETF standards track process.  A number of editorial
   improvements were made, the RFC 2119 [10] conventions applied, and
   the current RFC boilerplate added.  The following substantive changes
   were made.  None of them is believed to obsolete implementations of
   RFC 1483:




Grossman & Heinanen         Standards Track                    [Page 21]

RFC 2684                Multiprotocol Over AALS           September 1999


   -- usage of NLPID encapsulation is clarified in terms of the RFC 2119
      conventions

   -- a pointer to RFC 2364 is added to cover the case of PPP over ATM

   -- RFC 1755 and RFC 2331 are referenced to describe how
      encapsulations are negotiated, rather than a long-obsolete CCITT
      (now ITU-T) working document and references to work then in
      progress

   -- usage of AAL5 is now a reference to ITU-T I.363.5.  Options
      created in AAL5 since the publication of RFC 1483 are selected.

   -- formatting of routed NLPID-formatted PDUs (which are called
      "routed ISO PDUs"
       in RFC 1483) is clarified

   -- clarification is provided concerning the use of padding between
      the PID and MAC destination address in bridged PDUs and the bit
      ordering of the MAC address.

   -- clarification is provided concerning the use of padding of
      Ethernet/802.3 frames

   -- a new encapuslation for VPNs is added

   -- substantive security considerations were added

   -- a new appendix D provides a summary of applications of
      multiprotocol over ATM

Authors' Addresses

   Dan Grossman
   Motorola, Inc.
   20 Cabot Blvd.
   Mansfield, MA 02048

   EMail: [e-mail]


   Juha Heinanen
   Telia Finland
   Myyrmaentie 2
   01600 Vantaa, Finland

   EMail: [e-mail]




Grossman & Heinanen         Standards Track                    [Page 22]

RFC 2684                Multiprotocol Over AALS           September 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Grossman & Heinanen         Standards Track                    [Page 23]