rfc2684.txt

RFC 的详细文档！

                 |            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)      |
                 |                               |
                 +-------------------------------+







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


   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.

7.  Bridging in an ATM Network

   A bridge with an ATM interface that serves as a link to one or more
   other 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 point-to-multipoint 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
   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 MUST conform to the
   encapsulation described in section 5.  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.

8.  Virtual Private Network (VPN) identification

   The encapsulation defined in this section applies only to  Virtual
   Private Networks (VPNs) that operate over an ATM subnet.

   A mechanism for globally unique identification of Virtual Private
   multiprotocol networks is defined in [11].  The 7-octet VPN-Id
   consists of a 3-octet VPN-related OUI (IEEE 802-1990 Organizationally
   Unique Identifier), followed by a 4-octet VPN index which is
   allocated by the owner of the VPN-related OUI.  Typically, the VPN-
   related OUI value is assigned to a VPN service provider, which then
   allocates VPN index values for its customers.










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


8.1 VPN Encapsulation Header

   The format of the VPN encapsulation header is as follows:

                       VPN Encapsulation Header
                  +-------------------------------+
                  |       LLC  0xAA-AA-03         |
                  +-------------------------------+
                  |        OUI 0x00-00-5E         |
                  +-------------------------------+
                  |        PID 0x00-08            |
                  +-------------------------------+
                  |          PAD 0x00             |
                  +-------------------------------+
                  |   VPN related OUI (3 octets)  |
                  +-------------------------------+
                  |    VPN Index (4 octets)       |
                  +-------------------------------+
                  |                               |
                  |     (remainder of PDU)        |
                  |                               |
                  +-------------------------------+

   When the encapsulation header is used, the remainder of the PDU MUST
   be structured according to the appropiate format described in section
   5 or 6 (i.e., the VPN encapsulation header is prepended to the PDU
   within an AAL5 CPCS SDU).

8.2 LLC-encapsulated routed or bridged PDUs within a VPN

   When a LLC-encapsulated routed or bridged PDU is sent within a VPN
   using ATM over AAL5, a VPN encapsulation header MUST be prepended to
   the appropriate routed or bridged PDU format defined in sections 5.1
   and 5.2, respectively.

8.3 VC multiplexing of routed or bridged PDUs within a VPN

   When a routed or bridged PDU is sent within a VPN using VC
   multiplexing, the VPN identifier MAY either be specified a priori,
   using ATM connection control signalling or adminstrative assignment
   to an ATM interface, or it MAY be indicated using an encapsulation
   header.

   If the VPN is identified using ATM connection control signalling, all
   PDUs carried by the ATM VC are associated with the same VPN.  In this
   case, the payload formats of routed and bridged PDUs MUST be as
   defined in sections 6.1 and 6.2, respectively.  If a PDU is received
   containing a VPN encapsulation header when the VPN has been



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


   identified using ATM signalling, the receiver MAY drop it and/or take
   other actions which are implementation specific.  Specification of
   the mechanism in ATM connection control signalling for carrying VPN
   identifiers is outside the scope of this Memo.

   If a VPN identifier is administratively assigned to an ATM interface,
   then all PDUs carried by any ATM VCs within that interface are
   associated with that VPN.  In this case, the payload formats of
   routed and bridged PDUs MUST be as defined in sections 6.1 and 6.2,
   respectively.  If a PDU is received containing a VPN encapsulation
   header when the VPN identifier has been administratively assigned,
   the receiver MAY drop it and/or take other actions which are
   implementation specific.  Specification of mechanisms (such as MIBs)
   for assigning VPN identifiers to ATM interfaces is outside the scope
   of this memo.

   If the VPN identifier is to be indicated using an encapsulation
   header, then a VPN encapsulation header MUST be prepended to the
   appropriate routed or bridged PDU format defined in sections 6.1 and
   6.2, respectively.

9. Security Considerations

   This memo defines mechanisms for multiprotocol encapsulation over
   ATM. There is an element of trust in any encapsulation protocol:  a
   receiver must trust that the sender has correctly identified the
   protocol being encapsulated.  There is no way to ascertain that the
   sender did use the proper protocol identification (nor would this be
   desirable functionality).  The encapsulation mechanisms described in
   this memo are believed not to have any other properties that might be
   exploited by an attacker. However, architectures and protocols
   operating above the encapsulation layer may be subject to a variety
   of attacks.  In particular, the bridging architecture discussed in
   section 7 has the same vulnerabilities as other bridging
   architectures.

   System security may be affected by the properties of the underlying
   ATM network.  The ATM Forum has published a security framework [12]
   and a security specification [13] which may be relevant.












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


Acknowledgements

   This memo replaces RFC 1483, which was developed by the IP over ATM
   working group, and edited by Juha Heinanen (then at Telecom Finland,
   now at Telia).  The update was developed in the IP-over-NBMA (ION)
   working group, and Dan Grossman (Motorola) was editor and also
   contributed to the work on RFC 1483.

   This material evolved from RFCs [1] and [4] from which much of the
   material has been adopted.  Thanks to their authors Terry Bradley,
   Caralyn  Brown, Andy Malis, Dave Piscitello, and C. Lawrence.  Other
   key contributors to the work included Brian Carpenter (CERN), Rao
   Cherukuri (IBM), Joel Halpern (then at Network Systems), Bob Hinden
   (Sun Microsystems, presently at Nokia), and Gary Kessler (MAN
   Technology).

   The material concerning VPNs was developed by Barbara Fox (Lucent)
   and Bernhard Petri (Siemens).

References

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

   [2]  ITU-T Recommendation I.363.5, "B-ISDN ATM Adaptation Layer (AAL)
        Type 5 Specification", August 1996.

   [3]  ITU-T Recommendation I.365.1, "Frame Relaying Service Specific
        Convergence Sublayer (SSCS), November 1993.

   [4]  Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame
        Relay", RFC 2427, September 1998.

   [5]  Perez M., Liaw, F., Mankin, E., Grossman, D. and A. Malis, "ATM
        Signalling Support for IP over ATM", RFC 1755, February 1995.

   [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 J. Reynolds, "A Standard for the Transmission of
        IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February
        1988.

   [8]  Maher, M., "IP over ATM Signalling - SIG 4.0 Update", RFC 2331,
        April 1998.





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


   [9]  ITU-T Recommendation I.555, "Frame Relay Bearer Service
        Interworking", September 1997.

   [10] Bradner, S. "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [11] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
        RFC 2685, September 1999.

   [12] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-
        0096.000, February 1998.

   [13] The ATM Forum, "ATM Security Specification v1.0", af-sec-
        0100.001, February 1999.





































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


Appendix A.  Multiprotocol Encapsulation over FR-SSCS

   ITU-T Recommendation I.365.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