One document matched: draft-ietf-pppext-l2tp-ds-03.txt

Differences from draft-ietf-pppext-l2tp-ds-02.txt

INTERNET DRAFT                                             Pat R. Calhoun
Category: Informational                             Sun Microsystems, Inc.
Title: draft-ietf-pppext-l2tp-ds-03.txt                        Ken Peirce
Date: February 1999                                      3Com Corporation



                  Layer Two Tunneling Protocol "L2TP"
                   IP Differential Services Extension



Status of this Memo

   This document is a submission by the PPP Extensions Working Group of
   the Internet Engineering Task Force (IETF).  Comments should be
   submitted to the l2tp@ipsec.org mailing list.

   Distribution of this memo is unlimited.

   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.


Abstract

   The L2TP document [1] defines the base protocol which describes the
   method of tunneling PPP [2] data. The L2TP base protocol does not
   address any Differential Services extensions.

   Since the market is reluctant to outsource dial access without any
   Quality of Service assurances, this draft addresses this problem by



Calhoun, Peirce           expires August 1999                   [Page 1]





INTERNET DRAFT                                             February 1999


   allowing each L2TP Data Session to be assigned an appropriate
   differential services indicator.


Table of Contents

   1.0 Introduction
       1.1 Conventions
   2.0 Quality of Service/Diferential Services Negotiation
       2.1 Differential Sevices Indicator Exchange
       2.2 Error Reporting
   3.0 References
   4.0 Acknowledgements
   5.0 Authors' Addresses


1.0 Introduction

   The L2TP protocol specification does not discuss Quality of
   Service/Differential Services in any way. The current state of the
   market has shown that many customers are reluctant to adopt L2TP
   without any quality of service assurances.

   This document will describe how two L2TP peers can negotiate a
   differential services indicator for a dial-in user. Note that each
   individual session within a tunnel can have its own Diff Serv
   Indicator.

   The mechanism defined in this document assumes that the Tunnel
   Initiator determines what the user's appropriate service level is and
   sends the value in either the ICRQ or OCRQ messages. The Tunnel
   Terminator can respond to the message by stating what it believes is
   the user's appropriate service level. The values of the indicator
   supplied by the Tunnel Terminator will supercede those provided by
   the Tunnel Initiator if a difference is found.  However, the Tunnel
   Terminator MUST NOT propose a higher differential service level than
   was proposed by the Tunnel Initiator.

   In the case where the Tunnel Terminator does not propose ANY
   indicator (which is infered by the absence of the QOS AVPs in either
   the ICRP or OCRP) the Tunnel Initiator will assume no QOS is assigned
   to the session.

   A tunnel peer which violates the negotiated differential service
   level is liable to have it's tunnel shutdown.


1.1 Conventions



Calhoun, Peirce           expires August 1999                   [Page 2]





INTERNET DRAFT                                             February 1999


   The following language conventions are used in the items of
   specification in this document:

      o  MUST, SHALL, or MANDATORY -- This item is an absolute
         requirement of the specification.

      o  SHOULD or RECOMMEND -- This item should generally be followed
         for all but exceptional circumstances.

      o  MAY or OPTIONAL -- This item is truly optional and may be
         followed or ignored according to the needs of the implementor.


2.0 Quality of Service/Diferential Services Negotiation

   This section will define the new AVPs which are required for the
   Quality of Service extension of the L2TP protocol. The AVPs allow
   designation of a Quality of Service level for a specific data
   channel.


2.1 Differential Services Indicator AVP

   The Differential Services indicator AVP is found in the IPv4 header's
   DS field. This is the second octet in the header. The actual bit
   interpretation of the DS field (formerly the IP Precedence and Type
   of Service bit fields) is left to the appropriate documentation
   [2][3][4]. This document is concerned with defining a uniform
   exchange mechanism for the indicator only.

   The Differential Services Indicator AVP MAY be present in ICRQ, ICRP,
   OCRQ and OCRP. This message is used to inform the tunnel peer that a
   set of differential service indicator value SHOULD be used for all
   packets related to the data channel associated with the Tunnel and
   Call Identifiers in the L2TP header [1].

   The presence of this AVP in the ICRQ or OCRQ indicates that the
   tunnel initiator wishes to use a specific differential service
   indicator value on all data packets. However, the value found in the
   ICRP or OCRP indicate the value which the Tunnel Terminator is
   willing to accept.  However, the Tunnel Terminator MUST NOT propose a
   higher differential service level than was proposed by the Tunnel
   Initiator.

   A tunnel peer which violates the negotiated indicator value is liable
   to have it's tunnel shutdown.





Calhoun, Peirce           expires August 1999                   [Page 3]





INTERNET DRAFT                                             February 1999


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|1|0|0|        Length         |              43               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                1              |  Diff Serv Indicator Value    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This AVP MAY be present in the messages shown above. It is encoded
      with a Vendor ID of 43 (3Com Corporation) with the attribute set
      to 1, marked as optional, with the indicator value as data. This
      AVP SHOULD NOT be hidden and is optional. When present, the L2TP
      peer is indicating that differential services are to be used on IP
      packets within the session's data channel.


2.2 Error Reporting

   In the event that the peer did not accept the Diff Serv Indicator
   provided, or is unable to support Differential Services a Call-
   Disconnect-Notify is returned to the peer.

   If the indicator provided cannot be used by the peer, the Call-
   Disconnect-Notify message will include the Diff Serv Indicator AVP as
   provided in the message that caused the Call-Disconnect-Notify.


3.0 References

   [1] W.M. Townsley, A. J. Valencia, A. Rubens, G.S. Pall, G. Zorn,
       B. Palter, "Layer Two Tunneling Protocol (L2TP)",
       draft-ietf-pppext-l2tp-13.txt, Work in Progress, January 1999.

   [2] Nichols et al., "Definition of the Differentiated Services
       Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
       December 1998.

   [3] Blake et al.,"An Architecture for Differentiated Services",
       RFC 2475, December 1998.

   [4] Bernet, Durham, Reichmeyer, "Requirements of Diff-serv Boundary
       Routers", draft-bernet-diffedge-01.txt, Work in Progress,
       November 1998.


4.0 Acknowledgements

   The Authors would like to acknowledge John Shriver for his useful



Calhoun, Peirce           expires August 1999                   [Page 4]





INTERNET DRAFT                                             February 1999


   comments to an earlier version of this document.


5.0 Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Network and Security Research Center, Sun Labs
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-650-786-7733
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@eng.sun.com


      Ken Peirce
      3Com Corporation
      1800 Central Ave.
      Mount Prospect, Il, 60056

       Phone:  1-847-342-6894
         Fax:  1-847-222-2424
      E-mail:  Ken_Peirce@mw.3com.com
























Calhoun, Peirce           expires August 1999                   [Page 5]