idnits 2.17.1 draft-ietf-pppext-l2tp-ds-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 70: '... Terminator MUST NOT propose a highe...' RFC 2119 keyword, line 86: '... o MUST, SHALL, or MANDATORY ...' RFC 2119 keyword, line 89: '... o SHOULD or RECOMMEND -- Thi...' RFC 2119 keyword, line 92: '... o MAY or OPTIONAL -- This it...' RFC 2119 keyword, line 112: '...es Indicator AVP MAY be present in ICR...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1998) is 9417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-ferguson-delay-drop-00 Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group Pat R. Calhoun 3 INTERNET DRAFT Sun Microsystems, Inc. 4 Category: Informational Ken Peirce 5 Title: draft-ietf-pppext-l2tp-ds-02.txt 3Com Corporation 6 Date: July 1998 8 Layer Two Tunneling Protocol "L2TP" 9 IP Differential Services Extension 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet- 22 Drafts as reference material or to cite them other than as a 23 ``working draft'' or ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 27 Directories on ftp.ietf.org, nic.nordu.net, ftp.nisc.sri.com, or 28 munnari.oz.au. 30 Abstract 32 The L2TP document [1] defines the base protocol which describes the 33 method of tunneling PPP [2] data. The L2TP base protocol does not 34 address any Differential Services extensions. 36 Since the market is reluctant to outsource dial access without any 37 Quality of Service assurances, this draft addresses this problem by 38 allowing each L2TP Data Session to be assigned an appropriate 39 differential services indicator. 41 Table of Contents 43 1.0 Introduction 44 1.1 Conventions 45 2.0 Quality of Service/Diferential Services Negotiation 46 2.1 Differential Sevices Indicator Exchange 47 2.2 Error Reporting 48 3.0 References 49 4.0 Authors' Addresses 51 1.0 Introduction 53 The L2TP protocol specification does not discuss Quality of 54 Service/Differential Services in any way. The current state of the 55 market has shown that many customers are reluctant to adopt L2TP 56 without any quality of service assurances. 58 This document will describe how two L2TP peers can negotiate a 59 differential services indicator for a dial-in user. Note that each 60 individual session within a tunnel can have its own Diff Serv 61 Indicator. 63 The mechanism defined in this document assumes that the Tunnel 64 Initiator determines what the user's appropriate service level is and 65 sends the value in either the ICRQ or OCRQ messages. The Tunnel 66 Terminator can respond to the message by stating what it believes is 67 the user's appropriate service level. The values of the indicator 68 supplied by the Tunnel Terminator will supercede those provided by 69 the Tunnel Initiator if a difference is found. However, the Tunnel 70 Terminator MUST NOT propose a higher differential service level than 71 was proposed by the Tunnel Initiator. 73 In the case where the Tunnel Terminator does not propose ANY 74 indicator (which is infered by the absence of the QOS AVPs in either 75 the ICRP or OCRP) the Tunnel Initiator will assume no QOS is assigned 76 to the session. 78 A tunnel peer which violates the negotiated differential service 79 level is liable to have it's tunnel shutdown. 81 1.1 Conventions 83 The following language conventions are used in the items of specifi- 84 cation in this document: 86 o MUST, SHALL, or MANDATORY -- This item is an absolute 87 requirement of the specification. 89 o SHOULD or RECOMMEND -- This item should generally be followed 90 for all but exceptional circumstances. 92 o MAY or OPTIONAL -- This item is truly optional and may be 93 followed or ignored according to the needs of the 94 implementor. 96 2.0 Quality of Service/Diferential Services Negotiation 98 This section will define the new AVPs which are required for the 99 Quality of Service extension of the L2TP protocol. The AVPs allow 100 designation of a Quality of Service level for a specific data 101 channel. 103 2.1 Differential Services Indicator AVP 105 The Differential Services indicator AVP is found in the IPv4 header's 106 Type of Service octet. This is the second octet in the header. The 107 actual bit interpretation of the IP Precedence and Type of Service 108 bit fields is left to the appropriate documentation[2][3][4]. This 109 document is concerned with defining a uniform exchange mechanism for 110 the indicator only. 112 The Differential Services Indicator AVP MAY be present in ICRQ, ICRP, 113 OCRQ and OCRP. This message is used to inform the tunnel peer that a 114 set of differential service indicator value SHOULD be used for all 115 packets related to the data channel associated with the Tunnel and 116 Call Identifiers in the L2TP header [1]. 118 The presence of this AVP in the ICRQ or OCRQ indicates that the 119 tunnel initiator wishes to use a specific differential service 120 indicator value on all data packets. However, the value found in the 121 ICRP or OCRP indicate the value which the Tunnel Terminator is 122 willing to accept. However, the Tunnel Terminator MUST NOT propose a 123 higher differential service level than was proposed by the Tunnel 124 Initiator. 126 A tunnel peer which violates the negotiated indicator value is liable 127 to have it's tunnel shutdown. 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 |1|1|0|0| Length | 43 | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | 1 | Diff Serv Indicator Value | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 This AVP MAY be present in the messages shown above. It is encoded 138 with a Vendor ID of 43 (3Com Corporation) with the attribute set 139 to 1, marked as optional, with the indicator value as data. This 140 AVP SHOULD NOT be hidden and is optional. When present, the L2TP 141 peer is indicating that differential services are to be used on IP 142 packets within the session's data channel. 144 2.2 Error Reporting 146 In the event that the peer did not accept the Diff Serv Indicator 147 provided, or is unable to support Differential Services a Call- 148 Disconnect-Notify is returned to the peer. 150 If the indicator provided cannot be used by the peer, the Call- 151 Disconnect-Notify message will include the Diff Serv Indicator AVP as 152 provided in the message that caused the Call-Disconnect-Notify. 154 3.0 References 156 [1] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, 157 A. J. Valencia, W. Verthein, W.M. Townsley, B. Palter, 158 A. Rubens "Layer Two Tunneling Protocol (L2TP)", 159 Internet draft, October 1997 161 [2] D. Clark, J. Wroclawski, "An Approach to Service Allocation in 162 the Internet", draft-clark-diff-svc-alloc-00.txt, July 1997. 164 [3] P. Ferguson, "Simple Differential Services: IP TOS and 165 Precedence, Delay Indication, and Drop Preference,", 166 draft-ferguson-delay-drop-00.txt, November 1997 168 [4] J. Heinanen, "Use of the IPv4 TOS Octet to Support Differential 169 Services", draft-heinanen-diff-tos-octet-01.txt, November 1997 171 4.0 Authors' Addresses 173 Questions about this memo can be directed to: 175 Pat R. Calhoun 176 Technology Development 177 Sun Microsystems, Inc. 178 15 Network Circle 179 Menlo Park, California, 94025 180 USA 182 Phone: 1-650-786-7733 183 Fax: 1-650-786-6445 184 E-mail: pcalhoun@eng.sun.comt 186 Ken Peirce 187 3Com Corporation 188 1800 Central Ave. 189 Mount Prospect, Il, 60056 191 Phone: 1-847-342-6794 192 Fax: 1-847-222-2424 193 E-mail: Ken_Peirce@mw.3com.com