Network Working Group Pat R. Calhoun
INTERNET DRAFT Sun Microsystems, Inc.
Danny McPherson
Amber Networks, Inc.
Ken Peirce
December 2000 Malibu Networks, Inc.
L2TP Differentiated Services Extension
<draft-ietf-l2tpext-ds-02.txt>
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2. Abstract
The Layer Two Tunneling Protocol (L2TP) [RFC 2661] provides a
standard method for tunneling PPP [RFC 1661] packets. The current
specification provides no provisions for supporting Differentiated
Services (diffserv) [RFC 2474, RFC 2475] 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.
This document describes mechanisms which enable L2TP to negotiate
desired DS values for the L2TP control connection, as well as
Calhoun, McPherson, Peirce [Page 1]
INTERNET DRAFT December 2000
individual sessions within an L2TP tunnel.
3. 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].
4. Introduction
The L2TP specification currently provides no mechanism for supporting
diffserv (DS). This document describes mechanisms that enable L2TP
to indicate desired DS values to be associated with an L2TP control
connection, as well as individual sessions within an L2TP tunnel.
This document will describe how a set of L2TP peers MAY negotiate a
set of differential services indicators for a tunnel control
connection, as well as for individual sessions within the 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.
5. 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 to use the specified DS
value on all packets within the tunnel's control connection.
Upon receipt of a Start-Control-Connection-Request (SCCRQ) containing
the CCDS AVP, if the tunnel terminator provides no support for the
CCDS AVP it SHOULD ignore the AVP and send a SCCRP to the tunnel
initiator without the CCDS AVP. The tunnel initiator interprets the
absence of the CCDS AVP in the SCCRP as as an indication that the
tunnel terminator is incapable of supporting CCDS.
Upon receipt of a SCCRP that contains no CCDS AVP in response to a
Calhoun, McPherson, Peirce [Page 2]
INTERNET DRAFT December 2000
SCCRQ that contained a CCDS AVP, if the tunnel initiator wants to
continue tunnel establishment it sends a SCCCN; otherwise, it sends a
StopCCN to the tunnel terminator to end the connection. The StopCCN
control message MUST contain a Result Code AVP that indicates CCDS
AVP value [TBD] as the reason for sending the StopCCN.
If the tunnel terminator provides support for CCDS but is unwilling
or unable to support the requested DS value the tunnel terminator
MUST send a SCCRP control message containing a CCDS AVP indicating
the value it's willing to use. If the CCDS AVP value is the same as
the one in the SCCRQ, it signals the acceptence of the requested DS
value. If the value is different it serves as a counter-offer by the
tunnel terminator.
If the tunnel initiator receives an SCCRP that contains a CCDS AVP
with a value other than that requested in the SCCRQ, and the tunnel
initiator is unwilling to use the value, the tunnel initiator MUST
send a StopCCN control message containing a Result Code AVP that
indicates CCDS AVP value [TBD] as the reason for sending the StopCCN.
5.1. Control Connection DS AVP (SCCRQ, SCCRP)
The CCDS AVP is encoded as Vendor ID 43, and the Attribute Value is
the 16-bit quantity 1 (the ID 43 reflects 3Com Corporation, it should
be changed to 0 and an official Attribute Value chosen should this
specification advance on as standards track).
Each CCDS AVP is encoded as follows:
Vendor ID = 43
Attribute = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 43 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | DS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be present in the following message types: SCCRQ and
SCCRP. This AVP MAY be hidden (the H-bit set to 0 or 1) and is
optional (M-bit not set). The length (before hiding) of this AVP
MUST be 8 octets.
Calhoun, McPherson, Peirce [Page 3]
INTERNET DRAFT December 2000
6. Session Operation
As defined in [RFC 2661], a L2TP session is connection-oriented. The
LNS and LAC maintain state for each Call that is initiated or
answered by an LAC. An L2TP Session is created between the LAC and
LNS when an end-to-end PPP connection is established between a Remote
System and the LNS. Datagrams related to the PPP connection are sent
over the Tunnel between the LAC and LNS. There is a one to one
relationship between established L2TP Sessions and their associated
Calls. As such, this document provides a mechanism to enable
discrimination for packets within an particular session from other
packets. For this purpose, we introduce the Session DS (SDS) AVP.
The presence of the SDS AVP serves as an indication to the peer (LAC
or LNS) that the session initiator wishes to use the specified DS
value on all packets within the session.
Upon receipt of a Incoming-Call-Request (ICRQ) or Outgoing-Call-
Request (OCRQ) containing the SDS AVP if the session terminator
provides no support for the requested DS value a Call-Disconnect-
Notify (CDN) message MUST be sent to the peer. The CDN message MUST
contain a Result Code AVP that indicates SDS AVP value [TBD] as the
reason for sending the CDN.
If the session terminator provides support for SDS but is unwilling
or unable to support the requested DS value the session terminator
MUST do one of the following:
1) Send a CDN message containing a Result Code AVP that indicates SDS
AVP value [TBD] as the reason for sending the CDN.
2) Send an Incoming-Call-Reply (ICRP) or Outgoing-Call-Reply (OCRP)
message containing a CDN AVP indicating the DS value the terminator
is willing to use for the session.
3) If the session terminator supports the DS value in the SDS AVP
session establishment MUST continue as defined in [RFC 2661].
If the session initiator receives an ICRP or OCRP that contains an
SDS AVP with a value other than that requested in the ICRQ or OCRQ,
and the session initiator is unwilling to use the value, the session
initiator MUST send a CDN message containing a Result Code AVP that
indicates SDS AVP value [TBD] as the reason for sending the CDN.
If the session initiator receives an ICRP or OCRP that contains a SDS
AVP with a value other than that requested in the ICRP or OCRP, and
the session initiator is willing to use the value, the session
initiator MUST proceed as indicated in [RFC 2661].
Calhoun, McPherson, Peirce [Page 4]
INTERNET DRAFT December 2000
6.1. Session DS AVP (ICRQ, ICRP, OCRQ, OCRP)
The SDS AVP is encoded as Vendor ID 43, and the Attribute Value is a
16-bit quantity 2 (the ID 43 reflects 3Com Corporation, it should be
changed to 0 and an official Attribute Value chosen should this
specification advance on as standards track).
Each SDS AVP is encoded as follows:
Vendor ID = 43
Attribute = 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 43 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | DS Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be present in the following message types: ICRQ, ICRP,
OCRQ and OCRP. This AVP MAY be hidden (the H-bit set to 0 or 1) and
is optional (M-bit is not set 0). The length (before hiding) of this
AVP MUST be 8 octets.
7. DS Value Encoding
The DS value is a left-justified 16-bit field (i.e., the leftmost bit
signifies bit 0 of the DS value, the right-most bit signifies bit
15).
Each DS value is encoded as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+-+
| DSCP | | |0|0|0|0|0|0|0|0|
+--+--+--+--+--+--+--+--+--+--+-+
The 6-bit DSCP field represents the codepoint used to select the per-
hop behavior (PHB), as defined in [RFC 2474]. Bits 6 and 7 are used
by ECN [RFC 2481] and SHOULD not be mapped. Bits 8 through 15 are
reserved for future use and MUST be set to zero.
Upon successful establishment of an L2TP tunnel control connection or
individual L2TP session employing the appropriate DS AVP defined in
this document, a direct mapping of bits 0-7 into the DS field of the
IP header of packets transmitted on the connection SHOULD occur.
Calhoun, McPherson, Peirce [Page 5]
INTERNET DRAFT December 2000
8. DSCP Selection
The requirements or rules of each service and DSCP mapping MUST be
set through administrative policy mechanisms which are outside the
scope of this document.
9. Packet Reordering and Sequence Numbers
Sequence numbers are required to be present in all control messages
and are used to provide reliable delivery on the control connection,
as defined in [RFC 2661]. While packet reordering is inevitably as
much a function of the network as it is local traffic conditioning,
the probability of it occuring when employing the CCDS AVP is same as
when not employing the AVP.
This is because the control connection is contained within a single
behavior aggregate (BA), and as such, all packets within the BA
SHOULD be provided with similar per-hop behaviors (PHBs) throughout
the DS domain.
Data messages MAY use sequence numbers to reorder packets and detect
lost packets. Data messages within a given session employing the SDS
AVP SHOULD not be reordered as all packets within the session are
contained within a single BA.
10. Crossing Differentiated Services Boundaries
With an arbitrary number of domains, signaling DSCPs via L2TP poses
some problems. Other protocols such as RSVP [RFC 2205] can do this
because RSVP is supposed to be processed at every node, and hence a
boundary node can rewrite the DSCPs as it goes by, so that the
signalled DSCPs are always with respect to whatever DS domain the
packet happens to be in.
Note in Section "DS Value Encoding" that a direct mapping of the
reported DS value to the DS field of IP packets transmitted on the
connection is NOT required. By not requiring this flexibility is
provided in the event that a uni-directional section of a tunnel or
session wants to use varying DSCP values in each direction. This is
especially important when considering multi-DS domains with varying
PHBs associated with a given BA.
As a result, it is perfectly acceptable that the outermost DS Field
of packets arriving on a given control connection or session are not
marked with a DSCP value that was negotiated during call setup.
Calhoun, McPherson, Peirce [Page 6]
INTERNET DRAFT December 2000
Currently, however, the preferred model for accommodating multi-
domain DS seems to be that of deploying traffic (re)classifiers at
the edges of DS domains and allowing the administrators of those
domains to coordinate DSCP mappings and associated PHBs as
contractually determined.
11. TODO
The intent of this version of the draft is to solicit feedback on how
L2TP DS should behave. The following areas have been identified as
requiring additional work in this document:
o Add User ID AVP to be used in conjunction with SDS AVP so
that the LNS can determine which user is requesting the
connection, and it can lookup it's local or remote database
for proper authorization parameters.
o Add support for 'default Session DS'. Will likely employ
SDS AVP in SCCRQ/SCCRP for this purpose.
o Need to add support for multiple DSCPs (similar to RSVP
DCLASS/RFC
o Need to provide capability for differing DSCP values to be used
in each direction.
o Need to provide consistency between Control Connection and
Session behavior.
o Need to generalize wording so that Session payload types other
than PPP are included as well.
Presumably, additional issues that require attention will be
uncovered during the San Diego WG meeting.
Calhoun, McPherson, Peirce [Page 7]
INTERNET DRAFT December 2000
12. IANA Considerations
Should this document advance on as standards track official Attribute
Values need to be assigned for the CCDS and SDS AVPs.
13. Security Considerations
This encoding in itself raises no security issues. However, users of
this encoding should consider that modifying a DSCP MAY constitute
theft or denial of service, so protocols using this encoding MUST be
adequately protected. No new security issues beyond those discussed
in [RFC 2474] and [RFC 2475] are introduced here.
14. Acknowledgements
Many thanks to David Black, W. Mark Townsley, Wei Luo, Nishit
Vasavada, Andy Koscinski and John Shriver for their review and
insightful feedback.
15. References
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[RFC 2474] Nichols et al., "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
[RFC 2475] Blake et al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC 2481] Ramakrishnan, K., and Floyd, S., "A Proposal to add
Explicit Congestion Notification (ECN) to IP", RFC 2481,
January 1999.
[RFC 2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661,
August 1999.
Calhoun, McPherson, Peirce [Page 8]
INTERNET DRAFT December 2000
16. Authors' Address
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
Phone: +1 650.786.7733
Email: pcalhoun@eng.sun.com
Danny McPherson
Amber Networks, Inc.
2465 Augustine Drive
Santa Clara, CA 95054
Phone: +1 408.486.6336
Email: danny@ambernetworks.com
Ken Peirce
Malibu Networks, Inc.
1035 Suncast Lane, Suite 130
El Dorado Hills, CA, 95762
Phone: +1 916.941.8814
Email: Ken@malibunetworks.com
Calhoun, McPherson, Peirce [Page 9]
