Subject: draft-ietf-l2tpext-ds-01.txt

From: Danny McPherson <[email-masked]>
Date: Fri, 08 Dec 2000 15:08:22 -0700

I'll post it to [email-masked] after San Diego is over.  

Note especially the TODO section.  Comments welcome, I'll be discussing the 
highlights Thursday.

-danny

========================================================================
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-01.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: [email-masked]

   Danny McPherson
   Amber Networks, Inc.
   2465 Augustine Drive
   Santa Clara, CA  95054
   Phone: +1 408.486.6336
   Email: [email-masked]

   Ken Peirce
   Malibu Networks, Inc.
   1035 Suncast Lane, Suite 130
   El Dorado Hills, CA, 95762
   Phone: +1 916.941.8814
   Email: [email-masked]

Calhoun, McPherson, Peirce                             	[Page 9]