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 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]