Elwin Stelzer Internet Draft Naveen Gowda Corona Networks, Inc. April 2001 Expires: October 2001 Differentiated Services on L2TP Sessions 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]