Internet DRAFT - draft-elwin-l2tpext-ipservices
draft-elwin-l2tpext-ipservices
Elwin Stelzer
Internet Draft Naveen Gowda
Corona Networks, Inc.
November 2001
Expires: June 2002
IP Services over L2TP Sessions
<draft-elwin-l2tpext-ipservices-01.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
To support user based IP services over L2TP, existing standards does
not provide direct solutions. This document extends L2TP to address the
shortcomings in L2TP related to this. The document also merges the
extensions mentioned in two other earlier drafts [L2TP-SU] and
[L2TP-SB].
3.0 Table of Contents
1.0 Status of this Memo ................................. 1
2.0 Abstract ............................................ 1
Elwin & Naveen [Page 1]
draft-elwin-l2tpext-ipservices-01 Nov 2001
3.0 Table of Contents ................................... 1
4.0 Introduction ........................................ 2
5.0 Extensions for Session Update ....................... 3
5.1 Session-Update-Notification (SUN) Message ........... 3
6.0 IP Services AVPs .................................... 3
6.1 IPSec AVP ........................................... 4
6.2 QOS AVP ............................................. 5
7.0 Session Bundling for Diffserv ....................... 6
7.1 Control Connection Operation ........................ 7
7.1.1 Bundling Capability AVP ............................. 7
7.2 Session Operation ................................... 8
7.2.1 Base Session AVP .................................... 8
8.0 IANA Considerations ................................. 8
9.0 Security Considerations ............................. 9
10.0 References .......................................... 9
11.0 Authors' Addresses .................................. 10
4.0 Introduction
Once a L2TP session is established, the current standard [L2TP-V2] and
[L2TP-V3] has no explicit mechanism to update the session
characteristics, during the life of the session, between the L2TP
tunnel endpoints. One such requirement for this mechanism is, LNS
informing LAC about the PPP-user's service characteristics, so that
user-specific service actions can be applied at LAC. Eg: DSCP marking.
There is a need for additional messages that will address similar
requirements. An additional message, SUN, is defined in this extension
for this.
This document also describes extensions to L2TP that enables LAC to
apply user-based services over L2TP sessions, such as IPSec and QOS.
The two AVPs, IPSec AVP and QOS AVP, are used to carry information
between LNS and LAC using SUN message.
There is an optional extension in this document, that is applicable for
cases where payload-sequencing is enabled. 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 [L2TP-DS] 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 reflecting
may not be a proper solution for all situations, since the backbone may
be in a different diffserv domain.
Elwin & Naveen [Page 2]
draft-elwin-l2tpext-ipservices-01 Nov 2001
A solution to this is given by defining two more AVPs: Bundling
Capability AVP and Base Session AVP. This solution may also be used for
non-PPP L2TP payload, which is likely to have similar issues, like
carrying Ethernet over L2TP.
5.0 Extensions for Session Update
Following additional message is defined to exchange session
characteristics:
Session-Update-Notification (SUN) message
The SUN is sent either from LAC to LNS or LNS to LAC. On receiving
this the recipient, if needed to respond, responds by sending another
SUN message. There is no change needed in the L2TP state machine to
accomodate this message.
The message can be used for user-specific service information to
be exchanged between LAC and LNS, even after the session is established.
5.1 Session-Update-Notification (SUN) Message
The Session-Update-Notification is sent by the LNS/LAC to update its
peer regarding session parameters. SUN message must be sent only after
session establishment is successful. In case of LNS this message can be
sent after receving ICCN or sending OCCN, and the session reaching the
established state. In case of LAC this message can be sent after sending
ICCN or receiving OCCN, and the session reaching the established state.
Recipient MUST be able to update its session information, if required,
based on the SUN message.
The attribute value for Message Type AVP for SUN message is TBD. The
Mandatory bit for this AVP MUST be Zero, so that the session can
continue even when the peer can not recognize this message.
Other existing or new AVPs can be added to the list of optional AVPs in
this message as and when required.
The following AVPs MUST be present in the SUN:
Message Type
6.0 IP Services Extensions
LNS terminates the PPP session, which is tunneled through LAC. It also
authenticates the incoming user and knows about the services that are
Elwin & Naveen [Page 3]
draft-elwin-l2tpext-ipservices-01 Nov 2001
assigned to the incoming user. In few cases it is required to inform
this service information to the LAC like QOS, IPSec etc. This extension
provides a mechanism for LNS to inform LAC about the services, for a
user. Currently, even though the services can be applied on per site
basis (Ex. apply IPSec for all the session on a tunnel and apply a pre
configured DSCP on all the packets on a tunnel), it is also required to
provide such services based on the incoming user. User specific services
are known only through authentication and as LNS terminates the PPP
incoming user, LNS can send the user speicific service attributes to LAC
through post session establishment messages like SUN. Upon receiving
SUN, LAC will parse all the user specific service attribute AVPs
(explained below) and send the supported Service attributes AVPs
back in another SUN (response) there by informing LNS about the
supported services.
6.1 IPSec AVP
The IPSec AVP is used to inform the tunneling peer to use the
appropriate IPSec parameters for securing the L2TP session.
When the LNS finds out that incoming user needs IPSec service then it
can send this AVP to LAC indicating LAC to send the L2TP packets
encrypted using IPSec. If the LAC supports to provide IPSec for
the requested LNS then it MUST send the same AVP back in response
SUN indicating that the IPSec AVP is valid and LAC will send
all L2TP packets through IPSec. If the LAC doesn't allow this, then
in SUN reply this AVP MUST not be included. Only after receiving
SUN from LAC with IPSec AVP inside it, LNS can assume that LAC can
support this capability.
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 = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPSec Profile Name ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be present SUN message.
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 is 8 + Length of
IPSec-Profile-Name octets. Vendor ID is a two octet value, set to 3961
to indicate that this is an Corona-assigned attribute. Should this draft
become a standard, the Vendor ID would become 0 and an appropriate
Attribute-Type value will be assigned by IANA.
Elwin & Naveen [Page 4]
draft-elwin-l2tpext-ipservices-01 Nov 2001
6.2 QOS AVP
The QOS AVP is used to inform the tunneling peer to use the
appropriate QOS marking and profile to use for the L2TP session.
This AVP can be used to determine how to mark the packets, from the
following options:
a. To reflect the marking from the payload IP packet to the
outer IP header, OR
b. To apply a specific PHB based marking for all packets from
the user (based on PHB ID sent in this AVP), OR
c. To mark based on policy lookup
If the LAC can support what is requested by LNS then it MUST send
the same AVP back in response SUN indicating that the QOS AVP is
valid and LAC will mark accordingly. If the LAC doesn't allow this,
then in response SUN this AVP MUST not be included. Only after
receiving SUN from LAC with QOS AVP inside it, LNS can assume that
LAC can support this capability.
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 | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type = 6 | reserved | FLG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHB ID | QOS Profile Name ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be present in the SUN message.
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 is 10 + Length
of QOS-Profile-Name in octets.
Vendor ID is a two octet value, set to 3961 to indicate that this is
an Corona-assigned attribute. Should this draft become a standard, the
Vendor ID would become 0 and an appropriate Attribute-Type value will
be assigned by IANA. The PHBID is encoded as described in [ref-7].
FLG indicates which type of marking is to be applied at LAC. Following
are the valid values for this:
000 - reflect DSCP from the inner IP packet
Elwin & Naveen [Page 5]
draft-elwin-l2tpext-ipservices-01 Nov 2001
001 - use the PHBID passed, to determine DSCP to mark the packets. For
all other values of FLG, the PHBID is ignored.
010 - do a policy lookup, with the profile mentioned, to determine the
DSCP marking.
011 - reserved
1xx - reserved
7.0 Session Bundling
This section addresses the problem arising due to packet reordering, due
to QOS or any other factors, when payload sequencing is enabled.
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 [DIFF-TN].
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
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.
Elwin & Naveen [Page 6]
draft-elwin-l2tpext-ipservices-01 Nov 2001
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 'Bundling Capability AVP' and the 'Base Session AVP'.
Older implementation that do not support these two 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 [L2TP-DS] 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 to achieve this.
7.1 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 'Bundling Capability
AVP'.
7.1.1 Bundling Capability AVP
The AVP is valid in the L2TP SCCRQ and SCCRP messages only, and it
MUST NOT be marked Mandatory. The Bundling Capability AVP is encoded
with vendor ID, and the attribute value as 1.
Each BC 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 MUST
respond with same AVP in SCCRP, if it supports session bundling and
MUST NOT include this AVP in SCCRP if it doesn't support this.
Elwin & Naveen [Page 7]
draft-elwin-l2tpext-ipservices-01 Nov 2001
7.2 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.2.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
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 extension or does not include this
AVP if it doesn't support this extension. 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 IANA Considerations
Should this document advance on as standards track official attribute
values need to be assigned for IPSec AVP, QOS AVP, Bundling Capability
AVP and Base-Session AVP.
Elwin & Naveen [Page 8]
draft-elwin-l2tpext-ipservices-01 Nov 2001
Also attribute value for SUN message in Message Type AVP needs to be
assigned.
9.0 Security Considerations
This document does not introduce any new security issues beyond those
inherent in L2TP, and may use the same mechanisms proposed for those
technologies, where applicable.
10.0 References
[L2TP-V2] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn,
B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661,
August 1999.
[L2TP-V3] J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, G. Singh Pall, A. Rubens,
B. Palter, "Layer Two Tunneling Protocol(L2TP)", Work in progress, July 2001
[L2TP-SU] Naveen Gowda, Elwin Stelzer, Umesh Sirsiwal, "L2TP Session
Update Mechanism", draft-naveen-l2tpext-sessupdate-00.txt,
Work in progress, June 2001
[L2TP-SB] Naveen Gowda, Elwin Stelzer, "Differentiated Services on
L2TP Sessions", draft-elwin-l2tpext-diffserv-00.txt,
Work in progress, April 2001
[DIFF-AR] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and
W. Weiss, "An Architecture for Differentiated Services",
RFC 2475, December 1998.
[DIFF-TN] D. Black, "Differentiated Services and Tunnels", RFC 2983,
October 2000.
[DIFF-PH] S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behaviour
Identification Codes", RFC 2836, May 2000
[PPP-STD] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
Elwin & Naveen [Page 9]
draft-elwin-l2tpext-ipservices-01 Nov 2001
11.0 Authors' Addresses
Elwin Stelzer Eliazer
Corona Networks, Inc.
630 Alder Drive
Milpitas, CA 95035
Email: elwinietf@yahoo.com
Naveen PN Gowda
Corona Networks, Inc.
630 Alder Drive
Milpitas, CA 95035
Email: naveenietf@yahoo.com
Elwin & Naveen [Page 10]
