Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension
RFC 3308
Document | Type | RFC - Proposed Standard (November 2002; No errata) | |
---|---|---|---|
Authors | Pat Calhoun , Wei Luo , Ken Peirce , Danny McPherson | ||
Last updated | 2012-02-26 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3308 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Thomas Narten | ||
IESG note | Published as RFC 3308 | ||
Send notices to | <mark@townsley.net> |
Network Working Group P. Calhoun Request for Comments: 3308 Black Storm Networks Category: Standards Track W. Luo Cisco Systems, Inc. D. McPherson TCB K. Peirce Malibu Networks, Inc. November 2002 Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes mechanisms which enable the Layer Two Tunneling Protocol (L2TP) to negotiate desired Per Hop Behavior (PHB) code for the L2TP control connection, as well as individual sessions within an L2TP tunnel. L2TP provides a standard method for tunneling PPP packets. The current specification provides no provisions for supporting Differentiated Services (diffserv) over the L2TP control connection or subsequent data sessions. As a result, no standard mechanism currently exists within L2TP to provide L2TP protocol negotiations for service discrimination. Calhoun, et. al. Standards Track [Page 1] RFC 3308 L2TP Diffserv Extension November 2002 Table of Contents 1. Specification of Requirements ............................... 2 2. Introduction ................................................ 2 3. Control Connection Operation ................................ 3 3.1. Control Connection DS AVP (SCCRQ, SCCRP) .................... 4 4. Session Operation ........................................... 4 4.1. Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) ..................... 6 5. DS AVPs Correlation ......................................... 6 6. PHB Encoding ................................................ 6 7. DSCP Selection .............................................. 7 8. Packet Reordering and Sequence Numbers ...................... 7 9. Crossing Differentiated Services Boundaries ................. 7 10. IANA Considerations ......................................... 8 11. Security Considerations ..................................... 8 12. Acknowledgements ............................................ 8 13. References .................................................. 8 14. Authors' Addresses .......................................... 9 15. Full Copyright Statement .................................... 10 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Introduction The L2TP specification currently provides no mechanism for supporting diffserv (DS). This document describes mechanisms that enable L2TP to indicate desired PHB code, as defined in [RFC 3140], to be associated with an L2TP control connection, as well as individual sessions within an L2TP tunnel. The actual bit interpretation of the DS field is beyond the scope of this document, and is purposefully omitted. This document is concerned only with defining a uniform exchange and subsequent mapping mechanism for the DS AVPs. Calhoun, et. al. Standards Track [Page 2] RFC 3308 L2TP Diffserv Extension November 2002 3. Control Connection Operation As defined in [RFC 2661], a control connection operates in-band over a tunnel to control the establishment, release, and maintenance of sessions and of the tunnel itself. As such, this document provides a mechanism to enable discrimination of L2TP control messages from other packets. For this purpose, we introduce the Control Connection DS (CCDS) AVP. The presence of the CCDS AVP serves as an indication to the peer (LAC or LNS) that the tunnel initiator wishes both the tunnel initiator and terminator to use the per-hop behavior(s) (PHB(s)) indicated by the AVP's PHB code for all packets within the tunnel's control connection. A PHB is a description of the externally observableShow full document text