idnits 2.17.1 draft-ietf-pppext-lbd-00.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. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** 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 98: '... o MUST, SHALL, or MANDATORY -- ...' RFC 2119 keyword, line 101: '... o SHOULD or RECOMMEND -- This i...' RFC 2119 keyword, line 104: '... o MAY or OPTIONAL -- This item ...' RFC 2119 keyword, line 114: '...gure-Request with MRRU set to zero MAY...' RFC 2119 keyword, line 115: '... all MP support, including LBD, or MAY...' (15 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 (April 1998) is 9508 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group J. Carlson 3 Internet Draft IronBridge Networks 4 expires in six months April 1998 6 PPP Link Balancing Detection (LBD) 7 9 Status of this Memo 11 This document is the product of the Point-to-Point Protocol 12 Extensions Working Group of the Internet Engineering Task Force 13 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 14 mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 To view the entire list of current Internet-Drafts, please check 30 the "1id-abstracts.txt" listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 32 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 33 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 34 (US West Coast). 36 Abstract 38 The Point-to-Point Protocol (PPP) [1] provides a standard method for 39 transporting multi-protocol datagrams over point-to-point links. 41 PPP also defines an extensible Link Control Protocol, which allows 42 the detection of optional link handling procedures, as well as a 43 Multilink procedure (MP) [2] which allows operation over multiple 44 physical links. This document defines an extension to MP called Link 45 Balancing Detection (LBD). 47 Table of Contents 49 1. Introduction ........................................... 2 50 1.1. Conventions ............................................ 3 51 2. MRRU Configuration Option Modification ................. 3 52 3. Bundle Establishment ................................... 3 53 4. Bundle Tear-Down ....................................... 4 54 5. Message Distribution ................................... 4 55 6. Security Issues ........................................ 5 56 7. References ............................................. 5 57 8. Authors' Addresses ..................................... 5 59 1. Introduction 61 Standard PPP negotiation allows for two types of links with regard to 62 multiple link layer entities. The standard type of PPP link is nego- 63 tiated without the Maximum-Receive-Reconstructed-Unit (MRRU) option 64 and appears as a separate network interface to the network layer and 65 to routing protocols. The Multilink PPP (MP) [2] type of link uses 66 the MRRU option and allows multiple PPP links to be bundled into one 67 network interface. An MP link appears as a single network interface 68 to the network layer and to routing protocols. 70 There are many advantages having multiple links between two nodes 71 appear at the network layer to be a single link. While equal-cost 72 multi-path balancing is certainly possible with modern interior gate- 73 way protocols, less stress is placed on scarce routing system 74 resources when link-layer detection is employed, allowing current 75 routing protocols to scale farther. Also, routing system stability 76 in the face of link failures is usually higher when individual links 77 are not visible to the routing protocols. 79 The main disadvantage to the current MP technique is that it does not 80 constrain the fragmentation which may be done by the peer. For sys- 81 tems employing general purpose CPUs in the data path and with 82 scatter-gather direct memory access (DMA) capability, this is often 83 not a problem. For systems with very high bandwidth capabilities, 84 these features are often infeasible, and this problem makes MP unus- 85 able. 87 This draft describes a method similar to (and compatible with) MP for 88 detecting multiple links to the same node, but without the fragmenta- 89 tion or reordering protection of MP. Instead, datagrams are distri- 90 buted intact among the links in any convenient manner, including 91 based on an IP [3] address hash or simple round-robbin service. 93 1.1. Conventions 95 The following language conventions are used in the items of specifi- 96 cation in this document: 98 o MUST, SHALL, or MANDATORY -- This item is an absolute require- 99 ment of the specification. 101 o SHOULD or RECOMMEND -- This item should generally be followed 102 for all but exceptional circumstances. 104 o MAY or OPTIONAL -- This item is truly optional and may be fol- 105 lowed or ignored according to the needs of the implementor. 107 2. MRRU Configuration Option Modification 109 The MRRU option from MP is modified to allow a new distinguished 110 value. This value is zero, and indicates that the Configure-Request 111 sender wishes to bundle multiple links but refuses to reconstruct 112 received fragmented datagrams or to use the header as defined in MP. 114 The receiver of Configure-Request with MRRU set to zero MAY 115 Configure-Reject it to disable all MP support, including LBD, or MAY 116 send Configure-Nak with a hint set non-zero to request standard MP 117 support, or MAY send Configure-Ack to indicate its willingness to run 118 LBD. 120 Both peers MUST agree that MRRU is not in effect, or that it is zero, 121 or that it has a non-zero value. If MRRU has a non-zero value, how- 122 ever, it need not be identical in each direction. If LCP goes to 123 Open state with the MRRUs set to an illegal set of values (id est, 124 one zero and the other non-zero), then an implementation SHOULD ter- 125 minate the link or MAY choose to renegotiate LCP. 127 3. Bundle Establishment 129 As with MP, bundle establishment is based on a combination of the 130 peer's supplied endpoint discriminator (ED) and the peer's identity 131 as determined via link authentication. The algorithm used for LBD is 132 identical to the MP algorithm, and is documented here only for con- 133 venience. 135 When authentication (if any was negotiated via LCP) is complete, a 136 check is made before attempting to negotiate any Network Control Pro- 137 tocols (NCPs). If an MRRU (either zero or non-zero) is agreed to by 138 both peers and if there is an existing LBD bundle where the ED (or 139 lack thereof) matches the new link's ED (or lack), and the authenti- 140 cated peer name (or lack thereof) match the new link's peer name (or 141 lack), then this new link should be made part of the bundle and no 142 new NCPs are created. Otherwise, this is a separate link, and NCPs 143 should be started. 145 If the local and remote MRRU values do not agree with the bundle, 146 then the link SHOULD be terminated. An implementation MAY choose 147 instead to renegotiate LCP to repair the error. If the MRRU values 148 are zero, then the MRU values MUST also be checked in the same 149 manner. 151 When LBD is in effect, in contrast with standard MP, the value adver- 152 tised to the network layer as the MTU MUST be the peer's requested 153 MRU (or any smaller value), rather than the negotiated MRRU. 155 4. Bundle Tear-Down 157 Tear-down is identical to standard MP and is thus not covered here. 159 5. Message Distribution 161 To distribute messages among the links, a few simple rules must be 162 followed. 164 First, since PPP negotiation does not withstand reordering, all PPP 165 negotiation messages MUST be sent over a single link to avoid possi- 166 ble reordering. The first link in a bundle MUST be used to transmit 167 PPP messages until this link is terminated. If the first link is 168 terminated, then one remaining link in the bundle MUST be chosen for 169 subsequent messages. Once that link is chosen, an implementation 170 MUST continue sending all PPP negotiation messages over that single 171 link. Any remaining link in the bundle MAY be chosen, and it is 172 entirely possible that each peer may choose a different link without 173 harm to the PPP protocol. 175 Second, PPP negotiation messages MUST be handled when received on any 176 link. An implementation MAY choose to terminate the last link over 177 which negotiation was received if negotiation is received over a dif- 178 ferent link, since this transition implies that the peer has already 179 terminated the prior link. 181 Third, network datagrams SHOULD be distributed over all links as 182 evenly as possible. There are no requirements that any particular 183 distribution algorithm be used. Note, however, that some network 184 protocols behave poorly when subjected to message reordering, so 185 techniques which prevent reordering (such as deterministic hashes of 186 network layer addresses) are encouraged. 188 Fourth, the common but technically non-standard practice of using LCP 189 Terminate-Request to gracefully terminate a link without data loss is 190 encouraged in LBD implementations. To do this, an implementation 191 leaves Open state on sending LCP Terminate-Request, but, contrary to 192 RFC 1661 [1], continues processing received datagrams until the peer 193 replies with LCP Terminate-Ack. 195 6. Security Issues 197 The authentication and bundling techniques are identical to standard 198 MP and the security issues are the same as with RFC 1990. 200 7. References 202 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 203 07/21/1994 205 [2] K. Sklower, et al, "The PPP Multilink Protocol (MP)", RFC 1990, 206 08/1996 208 [3] J. Postel, "Internet Protocol", RFC 791, 09/01/1981 210 8. Author's Address 212 James Carlson 213 IronBridge Networks 214 55 Hayden Avenue 215 Lexington MA 02173-7999 217 Phone: +1 781 402 8032 218 Fax: +1 781 402 8092 219 Email: carlson@ironbridgenetworks.com