Internet DRAFT - draft-elwin-l2tpext-diffserv
draft-elwin-l2tpext-diffserv
Elwin Stelzer
Internet Draft Naveen Gowda
Corona Networks, Inc.
April 2001
Expires: October 2001
Differentiated Services on L2TP Sessions
<draft-elwin-l2tpext-diffserv-00.txt>
1.0 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.0 Abstract
L2TP provides layer-2 tunneling over long distances, and a single L2TP
session is likely to carry different type of IP packets. Currently, one
L2TP session carries only one payload session; for PPP session (payload)
the LCP controls the corresponding L2TP session. Assigning one diffserv
code point to a L2TP session, as mentioned in [ref-6] can not provide
differentiated services for the different kind of IP packets that are
tunneled. For example, VoIP and FTP packets, will have to be treated the
same in the backbone, even though the intermediate nodes are diffserv
capable. The direct solution to reflect the tunneled IP packet's DSCP
marking to the constructed outer IP header's DSCP, will have adverse
effects when the L2TP session has sequencing enabled. Also this may not
EXPIRES October 2001 [Page 1]
Internet Draft April 2001
be a proper solution, since the backbone may be in a different diffserv
domain.
This document specifies a solution to this, by adding simple extensions
to L2TP, and this can supplement the solution provided in [ref-6].
This solution may also be used for non-PPP L2TP payload, which is likely
to have similar issues, like carrying Ethernet over L2TP.
3.0 Table of Contents
1.0 Status of this Memo .................................... 1
2.0 Abstract ............................................... 1
3.0 Table of Contents ...................................... 2
4.0 Specification of Requirements .......................... 2
5.0 Introduction ........................................... 2
6.0 Control Connection Operation ........................... 3
6.1 Diffserv Capability AVP ................................ 4
7.0 Session Operation ...................................... 4
7.1 Base Session AVP ....................................... 4
8.0 Multilink (MLPPP) Handling ............................. 5
9.0 Summary and Conclusions ................................ 5
10.0 IANA Considerations .................................... 5
11.0 Security Considerations ................................ 5
12.0 References ............................................. 6
13.0 Authors' Addresses ..................................... 6
4.0 Specification of Requirements
There is a need for multiple L2TP sessions for a single PPP session that
carries multiple application sessions, and hence different class of IP
traffic. The need for this can also be seen in [ref-5].
5.0 Introduction
The solution allows distribution of a single payload (PPP) session over
multiple L2TP sessions. The group of L2TP sessions that transport one
payload (PPP) session is termed as 'L2TP session bundle'. One of the
sessions in this session bundle is called the 'base session', and all
other sessions are 'flow sessions'. A session bundle will have one base
session and 0 or more flow sessions.
The base session is the first session that is created in a session
bundle. For the PPP case, the PPP control packets, are sent over the
EXPIRES October 2001 [Page 2]
Internet Draft April 2001
base session. When there is no other flow session present, the base
session will transport all the payload traffic. However this can not
provide differentiated services for the different type of payload
packets.
When packets are to be differentially treated across LAC and LNS nodes,
the flow sessions are created. The trigger for creating these
additional flow sessions could be based on different criteria, like
packet classification, or based on DSCP value in the payload packet,
or any other configuration. The exact means to do this is outside the
scope of this document.
The flow sessions are dependent on base sessions and can not exist by
themselves. The LAC and LNS need to know which is the base session for
each flow session. Thus when the base session is teared down, the
dependent flow sessions can also to be teared down, because the
dependent L2TP sessions are not LCP controlled. However if a flow
session needs to be explicitly teared down, that can be done with the
regular L2TP mechanism, using CDN. There are no special fields required
in the L2TP header to accommodate this session bundling, like the L2TP
tunnel ID or the L2TP session ID.
When there are multiple L2TP sessions in a L2TP session bundle, the base
session is expected to carry the high priority traffic (EF), as it is
the session that carries payload (PPP) control packets.
The solution mentioned here makes simple extensions to L2TP by adding
two more AVPs, the 'DS Capability AVP' and the 'Base Session AVP'.
Older implementation that do not support these new AVPs will not permit
for these additional flow sessions, and hence implementations supporting
this can coexist with older implementations, and be interoperable.
The L2TP session sequencing need not be disabled with this approach,
since different traffic flows are sent over different L2TP sessions.
Each base session and flow session will maintain its own sequence
numbers.
The SDS AVP mentioned in [ref-6] MAY be used for both the base and flow
sessions in the bundle to associate a DSCP value to the session.
However other means could as well be used for this.
6.0 Control Connection Operation
During the L2TP tunnel creation, an L2TP tunnel terminator needs to know
whether the remote peer has the capability to support this diffserv
extension or not. This is achieved by sending the 'Diffserv Capability
EXPIRES October 2001 [Page 3]
Internet Draft April 2001
AVP'.
6.1 Diffserv Capability AVP
The AVP is valid in the L2TP SCCRQ and SCCRP messages only, and it
MUST NOT be marked Mandatory. The Diff-Serv Capability AVP is encoded
with vendor ID, and the attribute value as 1.
Each DS Capability AVP is encoded as follows:
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 | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Vendor ID is a two octet value, set to 0 to indicate that this is an
IETF-assigned attribute.
Tunnel initiator sends this AVP in SCCRQ and the tunnel terminator will
either respond with same AVP in SCCRP, if it supports this draft or
MUST NOT include this AVP in SCCRP if it doesn't support this draft.
7.0 Session Operation
During flow session creation, the session initiator also sends the
'base-session AVP'. Note that the base session creation MUST NOT have
this AVP present.
7.1 Base Session AVP
This AVP is sent by the session initiator in ICRQ/OCRQ packet. This AVP
informs the peer that the current session may not run payload control
protocol (LCP) over this session. Instead it will directly send the
payload (PPP) data packets. If the peer is willing to accept this
behavior then it SHOULD respond by sending the same AVP in the
ICRP/OCRP. If the session terminator is not willing or doesn't have
resource to support this, then it should not include this AVP in the
ICRP/OCRP. When the session-initiator receives the ICRP/OCRP with this
AVP included in the response, then it can send the payload (PPP) data
packet even on this session, even though payload control packets (LCP)
aren't negotiated on this session. If the ICRP/OCRP doesn't have this
AVP then the session initiator MUST send CDN for this new session and
EXPIRES October 2001 [Page 4]
Internet Draft April 2001
MUST send all the data on the base session itself without trying
to bring up more sessions to distribute the (PPP) data packets.
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 | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type = 2 | Peer Base-Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be present in the following message types: ICRQ/OCRQ and
ICRP/OCRP. 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. Vendor ID is a two octet value, set to 0 to indicate that
this is an IETF-assigned attribute. Session initiator sends this AVP
in ICRQ/OCRQ and the session terminator will either respond with same
AVP in ICRP/OCRP, if it supports this draft or does not include this
AVP if it doesn't support this draft. Peer Base-Session ID is 16-bit
number and it MUST contain the peer's 16-bit session id value of its
base session.
8.0 Multilink (MLPPP) Handling
TBD
9.0 Summary and Conclusions
It is possible to have differentiated services across the LAC and LNS by
having each session correspond to a Diffserv traffic class. Extensions
for L2TP to achieve this are specified in this document.
10.0 IANA Considerations
Should this document advance on as standards track official attribute
values need to be assigned for the Diffserv Capability AVP and Base
Session AVP.
11.0 Security Considerations
This document does not introduce any new security issues beyond those
inherent in L2TP and Diff-Serv, and may use the same mechanisms
proposed for those technologies, where applicable.
EXPIRES October 2001 [Page 5]
Internet Draft April 2001
12.0 References
[ref-1] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," BCP 14 and RFC 2119, March 1997.
[ref-2] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661,
August 1999.
[ref-3] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and
W. Weiss, "An Architecture for Differentiated Services",
RFC 2475, December 1998.
[ref-4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[ref-5] D. Black, "Differentiated Services and Tunnels", RFC 2983,
October 2000.
[ref-6] Calhoun, R., Luo, W., McPherson, D., Peirce, K.,
"L2TP Differentiated Services Extension",
draft-ietf-l2tpext-ds-03.txt, Work in progress, March 2001.
13.0 Authors' Addresses
Elwin Stelzer Eliazer
Corona Networks, Inc.
630 Alder Drive
Milpitas, CA 95035
Phone: 408-519-3832
Email: elwinietf@yahoo.com
Naveen PN Gowda
Corona Networks, Inc.
630 Alder Drive
Milpitas, CA 95035
Phone: 408-519-3800 Ext 512
Email: naveenietf@yahoo.com
EXPIRES October 2001 [Page 6]
