idnits 2.17.1 draft-ietf-pppext-lbd-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: ---------------------------------------------------------------------------- == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2001) is 8315 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) ** Obsolete normative reference: RFC 2878 (ref. '4') (Obsoleted by RFC 3518) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Carlson 3 INTERNET-DRAFT Sun Microsystems 4 Expires January 2002 July 2001 5 Updates RFC 1990 7 PPP Link Balancing Detection (LBD) 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is the product of the Point-to-Point Protocol 32 Extensions Working Group of the Internet Engineering Task Force 33 (IETF). Comments should be submitted to the ietf-ppp@merit.edu 34 mailing list. Distribution of this memo is unlimited. 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. PPP 40 also defines an extensible Link Control Protocol (LCP), that allows 41 the detection of optional link handling procedures, and a Multilink 42 procedure (MP) [2], that allows operation over multiple parallel 43 links. This document defines an extension to MP called Link 44 Balancing Detection (LBD) and the LCP options that control this 45 extension. This extension allows high-speed implementations to use 46 the single-NCP negotiation model of MP without requiring the cost 47 associated with the unneeded MP datagram buffering and reordering. 49 Table of Contents 51 1. Introduction ........................................... 2 52 2. No-Fragmentation Configuration Option Format ........... 3 53 3. No-MP-Headers Configuration Option Format .............. 4 54 4. Interactions ........................................... 5 55 4.1. Interaction With MRRU and MRU .......................... 5 56 4.2. Interaction With CCP and ECP ........................... 5 57 4.3. Interaction With IGPs .................................. 5 58 4.4. Interaction With QoS ................................... 6 59 5. Bundle Establishment and Tear-Down ..................... 6 60 6. Message Distribution ................................... 7 61 7. Prior Art .............................................. 8 62 8. Security Issues ........................................ 8 63 9. Acknowledgements ....................................... 8 64 10. References ............................................. 8 65 11. Author's Address ....................................... 9 67 1. Introduction 69 PPP negotiation allows for two types of links with regard to multiple 70 link layer entities. A non-MP PPP link is negotiated without the 71 Maximum-Receive-Reconstructed-Unit (MRRU) option and appears as a 72 separate network interface to the network layer and to routing proto- 73 cols. The Multilink PPP (MP) [2] type of link uses the MRRU option 74 and allows multiple PPP links to be bundled into one network inter- 75 face. An MP bundle appears as a single network interface to the net- 76 work layer and to routing protocols. 78 There are many advantages having multiple links between two nodes 79 appear at the network layer to be a single link. While equal-cost 80 multi-path balancing is certainly possible with modern interior gate- 81 way protocols, less stress is placed on scarce routing system 82 resources when link-layer detection of parallel links is employed, 83 allowing current routing protocols to scale better. Also, the rout- 84 ing protocols are more stable when individual link failures are not 85 visible to link-state routing protocols. 87 The main disadvantage to the current MP technique is that it does not 88 constrain the fragmentation that may be done by the peer. For sys- 89 tems employing general purpose CPUs in the data path and with 90 scatter-gather direct memory access (DMA) capability, the reassembly 91 of datagrams fragmented on arbitrary octet boundaries is often not a 92 problem. For systems with very high bandwidth capabilities, these 93 features are often infeasible, and this problem makes regular MP 94 unusable. 96 This document describes a method similar to and compatible with MP's 97 algorithm to detect parallel links between two nodes, but without the 98 MP headers and the associated requirement of fragmentation and 99 sequencing. Instead, datagrams are distributed without MP headers 100 among the links in the bundle in any convenient manner, including 101 based on a flow-identifying hash or on round-robbin service, as long 102 as the chosen mechanism is sufficient for the supported network layer 103 protocols. 105 This technique is also referred to as "load balancing." The differ- 106 ence between LBD and traditional load balancing is that MP's single- 107 NCP model (and associated single network layer address) is used, the 108 configuration of the parallel links is made automatic, and configura- 109 tion errors are detected. This allows peers to discover during LCP 110 negotiation that, for example, links within a configured bundle 111 violate an implementation constraint by having different MRU values, 112 or are provisioned to terminate on the wrong network node. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in BCP 14 [3]. 118 2. No-Fragmentation Configuration Option Format 120 A summary of the No-Fragmentation Configuration Option format for LCP 121 is shown below. The fields are transmitted from left to right. 123 0 1 124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Type | Length | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Type 131 TBD-1 133 Length 135 2 137 The sender of this option in an LCP Configure-Request message is 138 indicating to its peer that it cannot support MP reassembly, and, 139 thus the peer must not fragment messages that it sends. 141 If the peer Configure-Ack's this option, then the peer MUST NOT frag- 142 ment frames using MP fragmentation. It MAY still use MP headers to 143 preserve frame sequencing. If the peer Configure-Reject's this 144 option, then the sender must remove this option from its next 145 Configure-Request message and MAY decline to run MP by also removing 146 its MRRU Configuration Option. Implementations MUST NOT Configure- 147 Nak this option if it appears in the peer's Configure-Request. 149 3. No-MP-Headers Configuration Option Format 151 A summary of the No-MP-Headers Configuration Option format for LCP is 152 shown below. The fields are transmitted from left to right. 154 0 1 155 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Type | Length | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Type 162 TBD-2 164 Length 166 2 168 The sender of this option in an LCP Configure-Request message is 169 indicating to its peer that it cannot support standard MP headers, 170 and thus the peer must not use MP headers on the messages that it 171 sends, and must send network layer messages using their assigned pro- 172 tocol numbers rather than inside protocol 003D. 174 If this option is specified, then the No-Fragmentation option is 175 unnecessary. Fragmentation without MP headers is not supported. 177 If the peer Configure-Ack's this option, then it MUST NOT add MP 178 headers or fragment frames using MP. If the peer Configure-Reject's 179 this option, then the sender must remove this option from its next 180 Configure-Request message and MAY decline to run MP by also removing 181 its MRRU Configuration Option. Implementations MUST NOT Configure- 182 Nak this option if it appears in the peer's Configure-Request. 184 This option MUST NOT be used on links that are intended to carry net- 185 work protocols that cannot tolerate reordering, such as Bridging [4]. 186 See section 6 of this document for details. 188 4. Interactions 190 4.1. Interaction With MRRU and MRU 192 The MRRU option from MP is used to signal the desire to run MP, 193 regardless of whether or not these options are present, and to set 194 the maximum network layer MTU. If the MRRU option is not negotiated, 195 then MP is not enabled and the options in this document have no 196 effect. If an MRRU is negotiated, then the MTU advertised to the 197 local network layer by PPP MUST NOT be greater than the peer's MRRU. 199 If the No-MP-Headers option is used, then the MTU MUST also be lim- 200 ited by the peer's MRU. That is, the MTU is calculated as the 201 minimum of the peer's MRU and MRRU. 203 If the No-Fragmentation option is used without the No-MP-Headers 204 option, the MTU MUST also be limited by the peer's MRU minus the MP 205 overhead (6 octets for the default long sequence numbers, 4 octets 206 for the optional short sequence numbers). 208 4.2. Interaction With CCP and ECP 210 The No-Fragmentation option has no effect on either CCP or ECP. How- 211 ever, when the No-MP-Headers option is negotiated, reordering is pos- 212 sible. To avoid harmful interaction with these protocols, one of the 213 following mechanisms MAY be used: 215 - Attempt to negotiate the per-link forms of CCP and ECP first. 217 - If bundle-level CCP or ECP is required, negotiate to use only 218 history-less algorithms. 220 - If history-less algorithms are unavailable or disabled, then 221 algorithms 222 supporting multiple contexts in an implementation-dependent 223 manner 224 MAY be used by prior arrangement. 226 Otherwise, CCP and ECP should be disabled. Since disabling of MP 227 headers is intended for use with high-speed links where CCP and ECP 228 are also problematic, this last option is RECOMMENDED. 230 4.3. Interaction With IGPs 232 MP bundling has two desirable effects on link-state algorithms. 234 First, by summarizing the physical links into a single virtual link 235 for IP, it reduces the size of the Router LSAs carried. Second, by 236 leaving the IP link existence unchanged when member links join and 237 leave the bundle, it reduces the need to advertise changes in the 238 Router LSAs and the associated network and CPU overhead due to SPF 239 recalculation. 241 It has been suggested that extensions to the OSPF and IS-IS neighbor 242 discovery process could perform the same function as LBD, perhaps in 243 a manner patterned after PNNI. However, doing this would require 244 both new features in each of the link state protocols and changes in 245 the way LSAs are constructed. The LBD mechanism is proposed as a 246 simpler solution. 248 As with link-state routing protocols, MP bundling also improves the 249 stability of the distance-vector routing protocols, such as RIPv2. 250 LBD also adds the ability to handle parallel links, which generally 251 cannot be used by these protocols. 253 4.4. Interaction With QoS 255 The properties of the bundle may be summarized for admittance control 256 by advertising the aggregate bandwidth and maximum reservable 257 bandwidth among the member links. Detailed QoS specification is out- 258 side the scope of this document. 260 5. Bundle Establishment and Tear-Down 262 As with MP, bundle establishment is based on a combination of the 263 peer's supplied MP Endpoint Discriminator (ED) and the peer's iden- 264 tity as determined via link authentication. The algorithm used for 265 LBD is identical to the MP algorithm, and is documented here only for 266 convenience. 268 When authentication (if any was negotiated via LCP) is complete, a 269 check is made before attempting to negotiate any Network Control Pro- 270 tocols (NCPs). If an MRRU is agreed to by both peers and if there is 271 an existing LBD bundle where the ED (or lack thereof) matches the new 272 link's ED (or lack), and the authenticated peer name (or lack 273 thereof) match the new link's peer name (or lack), then this new link 274 should be made part of the bundle and no new NCPs are created. Oth- 275 erwise, this is a separate link, and NCPs should be started. 277 If the local and remote MRRU values do not agree with the bundle or 278 if the presence or absence of the No-Fragmentation or No-MP-Headers 279 options does not agree with the bundle, then the link SHOULD be 280 terminated. An implementation MAY choose instead to renegotiate LCP 281 to repair the error. 283 Tear-down is identical to standard MP and is thus not covered here. 285 6. Message Distribution 287 To distribute messages among the links when LBD is in effect, a few 288 simple rules must be followed. 290 First, since PPP negotiation does not withstand reordering, all PPP 291 negotiation messages MUST be sent over a single link to avoid possi- 292 ble reordering. The first link in a bundle MUST be used to transmit 293 PPP messages until this link is terminated. If the first link is 294 terminated, then one remaining link in the bundle MUST be chosen for 295 subsequent messages. Once that link is chosen, an implementation 296 MUST continue sending all PPP negotiation messages over that single 297 link. Any remaining link in the bundle MAY be chosen, and it is 298 entirely possible that each peer may choose a different link without 299 harm to PPP. 301 Second, PPP negotiation messages MUST be handled when received on any 302 link. An implementation MAY choose to terminate the last link over 303 which negotiation was received if a negotiation message is received 304 over a different link, since this transition implies that the peer 305 has already terminated the prior link. 307 Third, network datagrams SHOULD be distributed over all links as 308 evenly as possible. There are no requirements that any particular 309 distribution algorithm be used. Note, however, that some network 310 protocols behave poorly when subjected to message reordering, thus 311 techniques that reduce the likelihood of reordering (such as deter- 312 ministic hashes of network layer addresses and transport identifiers) 313 are encouraged. For TCP, reordering of IP datagrams usually causes a 314 "slow path" in most implementations to be taken, and can trigger 315 undesirable side-effects, such as fast retransmit. 317 Fourth, network datagrams from protocols that cannot withstand mes- 318 sage reordering MUST be sent over a single link within the bundle. 319 The link for each datagram may be chosen in any manner appropriate 320 for that network layer, and is left to either the network layer 321 specification or prior arrangement between the peers. For instance, 322 an implementation using bridging with VLANs could allocate the VLANs 323 among the available links using the same algorithm as described for 324 PPP negotiation messages. Avoiding the use of the No-MP-Headers 325 option may be preferred in these cases, since the changes to the 326 hash-to-link mapping required when links join or leave the bundle can 327 cause small amounts of reordering. 329 Fifth, the common but technically non-standard practice of using LCP 330 Terminate-Request to terminate a link gracefully without data loss is 331 encouraged in LBD implementations. To do this, an implementation 332 leaves Open state on sending LCP Terminate-Request, but, contrary to 333 RFC 1661, continues processing received datagrams until the peer 334 replies with LCP Terminate-Ack. 336 7. Prior Art 338 The traditional way to implement load balancing for IP over PPP in 339 the absence of LBD is to allow the multiple PPP links to negotiate 340 the same pair of IP endpoint addresses independently. The tradi- 341 tional mechanism has the advantage of simplicity, as it requires no 342 protocol changes, but does not necessarily work when non-IP network 343 protocols are in use, and does not have the routing features of LBD. 344 When that style of load balancing is used, the member links may be 345 advertised as separate unnumbered links. 347 An implementation that refuses to use the IPCP IP-Address option or 348 uses only MPLS cannot use the traditional method and must rely on 349 manual configuration or LBD. 351 8. Security Issues 353 The authentication and bundling techniques are identical to standard 354 MP and the security issues are the same as with RFC 1990. 356 9. Acknowledgements 358 The idea of link-detected balancing itself was inspired by Ross Cal- 359 lon. I am also grateful for the many critiques and ideas offered on 360 the IETF PPP Extensions mailing list and by private mail. In partic- 361 ular, I thank John Bray, Archie Cobbs, and Vernon Schryver. 363 10. References 365 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 366 07/21/1994 368 [2] K. Sklower, et al., "The PPP Multilink Protocol (MP)", RFC 1990, 369 08/1996 371 [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement 372 Levels," BCP 14 and RFC 2119, 03/1997 374 [4] M. Higashiyama and F. Baker, "PPP Bridging Control Protocol 375 (BCP)," RFC 2878, 07/2000. 377 11. Author's Address 379 James Carlson 380 Sun Microsystems 381 1 Network Drive MS UBUR02-212 382 Burlington MA 01803-2757 384 Phone: +1 781 442 2084 385 Fax: +1 781 442 1677 386 Email: james.d.carlson@sun.com