idnits 2.17.1 draft-ietf-pppext-l2tp-ds-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 4 instances of too long lines in the document, the longest one being 2 characters 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 78: '... Terminator MUST NOT propose a highe...' RFC 2119 keyword, line 93: '... o MUST, SHALL, or MANDATORY -- ...' RFC 2119 keyword, line 96: '... o SHOULD or RECOMMEND -- This i...' RFC 2119 keyword, line 99: '... o MAY or OPTIONAL -- This item ...' RFC 2119 keyword, line 118: '...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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-13 Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Informational Sun Microsystems, Inc. 4 Title: draft-ietf-pppext-l2tp-ds-03.txt Ken Peirce 5 Date: February 1999 3Com Corporation 7 Layer Two Tunneling Protocol "L2TP" 8 IP Differential Services Extension 10 Status of this Memo 12 This document is a submission by the PPP Extensions Working Group of 13 the Internet Engineering Task Force (IETF). Comments should be 14 submitted to the l2tp@ipsec.org mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The L2TP document [1] defines the base protocol which describes the 40 method of tunneling PPP [2] data. The L2TP base protocol does not 41 address any Differential Services extensions. 43 Since the market is reluctant to outsource dial access without any 44 Quality of Service assurances, this draft addresses this problem by 45 allowing each L2TP Data Session to be assigned an appropriate 46 differential services indicator. 48 Table of Contents 50 1.0 Introduction 51 1.1 Conventions 52 2.0 Quality of Service/Diferential Services Negotiation 53 2.1 Differential Sevices Indicator Exchange 54 2.2 Error Reporting 55 3.0 References 56 4.0 Acknowledgements 57 5.0 Authors' Addresses 59 1.0 Introduction 61 The L2TP protocol specification does not discuss Quality of 62 Service/Differential Services in any way. The current state of the 63 market has shown that many customers are reluctant to adopt L2TP 64 without any quality of service assurances. 66 This document will describe how two L2TP peers can negotiate a 67 differential services indicator for a dial-in user. Note that each 68 individual session within a tunnel can have its own Diff Serv 69 Indicator. 71 The mechanism defined in this document assumes that the Tunnel 72 Initiator determines what the user's appropriate service level is and 73 sends the value in either the ICRQ or OCRQ messages. The Tunnel 74 Terminator can respond to the message by stating what it believes is 75 the user's appropriate service level. The values of the indicator 76 supplied by the Tunnel Terminator will supercede those provided by 77 the Tunnel Initiator if a difference is found. However, the Tunnel 78 Terminator MUST NOT propose a higher differential service level than 79 was proposed by the Tunnel Initiator. 81 In the case where the Tunnel Terminator does not propose ANY 82 indicator (which is infered by the absence of the QOS AVPs in either 83 the ICRP or OCRP) the Tunnel Initiator will assume no QOS is assigned 84 to the session. 86 A tunnel peer which violates the negotiated differential service 87 level is liable to have it's tunnel shutdown. 89 1.1 Conventions 90 The following language conventions are used in the items of 91 specification in this document: 93 o MUST, SHALL, or MANDATORY -- This item is an absolute 94 requirement of the specification. 96 o SHOULD or RECOMMEND -- This item should generally be followed 97 for all but exceptional circumstances. 99 o MAY or OPTIONAL -- This item is truly optional and may be 100 followed or ignored according to the needs of the implementor. 102 2.0 Quality of Service/Diferential Services Negotiation 104 This section will define the new AVPs which are required for the 105 Quality of Service extension of the L2TP protocol. The AVPs allow 106 designation of a Quality of Service level for a specific data 107 channel. 109 2.1 Differential Services Indicator AVP 111 The Differential Services indicator AVP is found in the IPv4 header's 112 DS field. This is the second octet in the header. The actual bit 113 interpretation of the DS field (formerly the IP Precedence and Type 114 of Service bit fields) is left to the appropriate documentation 115 [2][3][4]. This document is concerned with defining a uniform 116 exchange mechanism for the indicator only. 118 The Differential Services Indicator AVP MAY be present in ICRQ, ICRP, 119 OCRQ and OCRP. This message is used to inform the tunnel peer that a 120 set of differential service indicator value SHOULD be used for all 121 packets related to the data channel associated with the Tunnel and 122 Call Identifiers in the L2TP header [1]. 124 The presence of this AVP in the ICRQ or OCRQ indicates that the 125 tunnel initiator wishes to use a specific differential service 126 indicator value on all data packets. However, the value found in the 127 ICRP or OCRP indicate the value which the Tunnel Terminator is 128 willing to accept. However, the Tunnel Terminator MUST NOT propose a 129 higher differential service level than was proposed by the Tunnel 130 Initiator. 132 A tunnel peer which violates the negotiated indicator value is liable 133 to have it's tunnel shutdown. 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |1|1|0|0| Length | 43 | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | 1 | Diff Serv Indicator Value | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 This AVP MAY be present in the messages shown above. It is encoded 144 with a Vendor ID of 43 (3Com Corporation) with the attribute set 145 to 1, marked as optional, with the indicator value as data. This 146 AVP SHOULD NOT be hidden and is optional. When present, the L2TP 147 peer is indicating that differential services are to be used on IP 148 packets within the session's data channel. 150 2.2 Error Reporting 152 In the event that the peer did not accept the Diff Serv Indicator 153 provided, or is unable to support Differential Services a Call- 154 Disconnect-Notify is returned to the peer. 156 If the indicator provided cannot be used by the peer, the Call- 157 Disconnect-Notify message will include the Diff Serv Indicator AVP as 158 provided in the message that caused the Call-Disconnect-Notify. 160 3.0 References 162 [1] W.M. Townsley, A. J. Valencia, A. Rubens, G.S. Pall, G. Zorn, 163 B. Palter, "Layer Two Tunneling Protocol (L2TP)", 164 draft-ietf-pppext-l2tp-13.txt, Work in Progress, January 1999. 166 [2] Nichols et al., "Definition of the Differentiated Services 167 Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, 168 December 1998. 170 [3] Blake et al.,"An Architecture for Differentiated Services", 171 RFC 2475, December 1998. 173 [4] Bernet, Durham, Reichmeyer, "Requirements of Diff-serv Boundary 174 Routers", draft-bernet-diffedge-01.txt, Work in Progress, 175 November 1998. 177 4.0 Acknowledgements 179 The Authors would like to acknowledge John Shriver for his useful 180 comments to an earlier version of this document. 182 5.0 Authors' Addresses 184 Questions about this memo can be directed to: 186 Pat R. Calhoun 187 Network and Security Research Center, Sun Labs 188 Sun Microsystems, Inc. 189 15 Network Circle 190 Menlo Park, California, 94025 191 USA 193 Phone: 1-650-786-7733 194 Fax: 1-650-786-6445 195 E-mail: pcalhoun@eng.sun.com 197 Ken Peirce 198 3Com Corporation 199 1800 Central Ave. 200 Mount Prospect, Il, 60056 202 Phone: 1-847-342-6894 203 Fax: 1-847-222-2424 204 E-mail: Ken_Peirce@mw.3com.com