Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension
RFC 3308
|
| Document |
Type |
|
RFC - Proposed Standard
(November 2002; No errata)
|
|
Last updated |
|
2012-02-26
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3308 (Proposed Standard)
|
|
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 observable
Show full document text