rfc3355.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 732 行 · 第 1/2 页

   An implementation MUST be able to accept an incoming call that offers
   LLC encapsulated L2TP in the caller's request.  The called peer's
   implementation MUST reject a call setup request that only offers an
   encapsulation that it does not support.  Implementations originating
   a call offering both protocol encapsulation techniques MUST be able
   to accept the use of either encapsulation techniques.

   When originating an LLC encapsulated call that is to carry an L2TP
   payload, the [Q.2931] B-LLI IE user information layer 2 protocol
   field SHALL be encoded to select LAN Logical Link Control
   (ISO/IEC8802-2) in octet 6.  See [RFC2331] Appendix A for an example.

   When originating a VC-multiplexed call that is to carry an L2TP
   payload, the [Q.2931] B-LLI IE user information layer 2 protocol
   field SHALL be encoded to select no layer 2 protocol in octet 6 and
   layer 3 protocol field SHALL be encoded to select ISO/IEC TR 9577
   [ISO9577] in octet 7.  Furthermore, as per DSL Forum TR-037
   [DSLF037], the extension octets specify VC-multiplexed L2TP by using
   the SNAP IPI, followed by an OUI owned by IANA, followed by the PID
   assigned by IANA for L2TP.  Thus, the User Information layer 3
   protocol field is encoded:  0B 80 00 00 5E 00 07.  The AAL5 frame's





Singh, et. al.              Standards Track                     [Page 7]

RFC 3355                     L2TP Over AAL5                  August 2002


   payload field will always contain an L2TP PDU.  The SNAP IPI is
   employed only to use the IANA L2TP protocol value to specify the VC-
   multiplexed PDU.

   If the caller offers both encapsulation methods and the called peer
   accepts the call, the called peer SHALL specify the encapsulation
   method by including exactly one B-LLI IE in the Connect message.

   If an SVC tunnel is reset in accordance with section 4.1 of
   [RFC2661], both ends MUST clear the SVC.  Any user sessions on the
   tunnel will be terminated by the reset.  Either end MAY attempt to
   re-establish the tunnel upon receipt of a new request from a client.

7.2 Connection Setup Failure

   When a connection setup fails, the L2TP entity that attempted the
   connection setup MAY consider the called entity unreachable until
   notified that the unreachable entity is available.  The conditions
   under which an entity determines that another is unreachable and how
   it determines that the other is available again are implementation
   decisions.

7.3 Connection Teardown

   When there are no active sessions on an SVC tunnel, either end MAY
   optionally clear the connection.

8. Connection Failure

   Upon notification that an AAL5 SVC connection has been cleared, an
   Implementation SHALL tear down the tunnel and return the control
   connection to the idle state.

9. Security Considerations

   The Layer Two Tunneling Protocol base specification [RFC2661]
   discusses basic security issues regarding L2TP tunneling.  It is
   possible that the L2TP over AAL5 tunnel security may be compromised
   by the attack of ATM transport network itself.  The ATM Forum has
   published a security framework [AFSEC1] and a security specification
   [AFSEC2] that define procedures to guard against common threats to an
   ATM transport network.  Applications that require protection against
   threats to an ATM switching network are encouraged to use
   authentication headers, or encrypted payloads, and/or the ATM-layer
   security services described in [AFSEC2].






Singh, et. al.              Standards Track                     [Page 8]

RFC 3355                     L2TP Over AAL5                  August 2002


10. Acknowledgments

   This document draws heavily on material from: "PPP Over AAL5" (RFC
   2364) by George Gross, Manu Kaycee, Arthur Lin, Andrew Malis, and
   John Stephens and an earlier document of L2TP over AAL5 by Nagraj
   Arunkumar, Manu Kaycee, Tim Kwok, and Arthur Lin.

   Special thanks to Mike Davison, Arthur Lin, John Stevens for making
   significant contributions to the initial version of this document.

   Special thanks to David Allan of Nortel for his invaluable review of
   this document.

   The security section of this document is based upon RFC 3337, "Class
   Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2
   (AAL2)", by Bruce Thompson, Bruce Buffam and Thima Koren.

11. References

   [RFC2661] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G.,
             Zorn, G. and B. Palter, "Layer Two Tunneling Protocol
             (L2TP)", RFC 2661, August 1999.

   [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
             STD 51, RFC 1661, July 1994.

   [SIG31]   The ATM Forum, "ATM User-Network Interface Specification
             V3.1", af-uni-0010.002, 1994.

   [ITU93]   International Telecommunication Union, "B-ISDN ATM
             Adaptation Layer (AAL) Specification", ITU-T Recommendation
             I.363, March 1993.

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

   [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
             over ATM Adaptation Layer 5", RFC 2684, September 1999.

   [Q.2931]  International Telecommunication Union, "Broadband
             Integrated Service Digital Network (B-ISDN) Digital
             Subscriber Signaling System No.2 (DSS2) User Network
             Interface Layer 3 Specification for Basic Call/Connection
             Control", ITU-T Recommendation Q.2931, Feb. 1995.

   [FRF8]    The Frame Relay Forum, "Frame Relay/ATM PVC Service
             Interworking Implementation Agreement", FRF.8, April 1995.




Singh, et. al.              Standards Track                     [Page 9]

RFC 3355                     L2TP Over AAL5                  August 2002


   [ISO9577] ISO/IEC DTR 9577.2, "Information technology -
             Telecommunications and Information exchange between systems
             - Protocol Identification in the network layer", 1995-08-
             16.

   [RFC2331] Maher, M., "ATM Signaling Support for IP over ATM - UNI
             Signaling 4.0 Update", RFC 2331, April 1998.

   [DSLF037] DSL Forum Technical Report TR-037, "Auto-Configuration for
             the Connection Between the DSL Broadband Network
             Termination (B-NT) and the Network using ATM", March 2001.

   [SIG40]   ATM Forum, "ATM User-Network Interface (UNI) Signaling
             Specification Version 4.0", af-sig-0061.000, finalized July
             1996; available at ftp://ftp.atmforum.com/pub.

   [DUBR]    ATM Forum, "Addendum to TM 4.1: Differentiated UBR", af-
             tm-0149.000, finalized July, 2000; available at
             ftp://ftp.atmforum.com/pub

   [ILMIA]   ATM Forum, "Addendum to the ILMI Auto-configuration
             extension", af-nm-00165.000, April 2001.

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

   [AFSEC2]  The ATM Forum, "ATM Security Specification v1.1", af-sec-
             0100.002, March 2001























Singh, et. al.              Standards Track                    [Page 10]

RFC 3355                     L2TP Over AAL5                  August 2002


Appendix A.  Acronyms

   AAL5    ATM Adaptation Layer Type 5

   ATM     Asynchronous Transfer Mode

   B-LLI   Broadband Low Layer Information

   CPCS    Common Part Convergence Sublayer

   IANA    Internet Assigned Numbers Authority

   IE      Information Element

   L2TP    Layer Two Tunneling Protocol

   LAC     L2TP Access Concentrator

   LLC     Logical Link Control

   LNS     L2TP Network Server

   MTU     Maximum Transfer Unit

   MRU     Maximum Receive Unit

   NSP     Network Service Provider

   OUI     Organizationally Unique Identifier

   PDU     Protocol Data Unit

   PID     Protocol Identifier

   PPP     Point-to-Point Protocol

   PVC     Permanent Virtual Circuit

   SAP     Service Access Point

   SNAP    Subnetwork Address Protocol

   SVC     Switched Virtual Circuit

   VC      Virtual Circuit






Singh, et. al.              Standards Track                    [Page 11]

RFC 3355                     L2TP Over AAL5                  August 2002


Authors' Addresses

   Rollins Turner
   Paradyne Corporation
   8545 126th Avenue North
   Largo, FL 33773

   EMail: [e-mail]


   Rene Tio
   Redback Networks, Inc.
   300 Holger Way
   San Jose, CA 95134

   EMail: [e-mail]


   Ajoy Singh
   Motorola
   1421 West Shure Dr,
   Arlington Heights, IL 60004

   EMail: [e-mail]


   Suhail Nanji
   Redback Networks, Inc.
   300 Holger Way
   Sunnyvale, CA 95134

   EMail: [e-mail]



















Singh, et. al.              Standards Track                    [Page 12]

RFC 3355                     L2TP Over AAL5                  August 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.



















Singh, et. al.              Standards Track                    [Page 13]