idnits 2.17.1 draft-ietf-pppext-multilink-12.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-19) 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. ** 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 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 47 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([2]), 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 175: '... o MUST, SHALL or MANDATORY -- th...' RFC 2119 keyword, line 178: '... o SHOULD or RECOMMENDED -- the i...' RFC 2119 keyword, line 181: '... o MAY or OPTIONAL -- the item is...' RFC 2119 keyword, line 231: '... implementation MUST accept reassembl...' RFC 2119 keyword, line 249: '...d below, member links SHOULD negotiate...' (57 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 955 has weird spacing: '...otiated over ...' -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'N' on line 590 -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1334 (ref. '3') (Obsoleted by RFC 1994) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1700 (ref. '7') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keith Sklower 2 INTERNET DRAFT University of California, Berkeley 3 Expires: June 15, 1996 4 Brian Lloyd 5 Glenn McGregor 6 Lloyd Internetworking 8 Dave Carr 9 Newbridge Networks Corporation 11 Tom Coradetti 12 Sidewalk Software 14 The PPP Multilink Protocol (MP) 15 draft-ietf-pppext-multilink-12.txt 17 Status of This Memo 19 This document is an Internet Draft. 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 25 months. Internet Drafts may be updated, replaced, or obsoleted by 26 other documents at any time. It is not appropriate to use Internet 27 Drafts as reference material or to cite them other than as a "working 28 draft" or "work in progress." 30 Please check the 1id-abstracts.txt listing contained in the internet- 31 drafts Shadow Directories to learn the current status of any Internet 32 Draft. Distribution of this Memo is unlimited. 34 Abstract 36 This document proposes a method for splitting, recombining and 37 sequencing datagrams across multiple logical data links. This work 38 was originally motivated by the desire to exploit multiple bearer 39 channels in ISDN, but is equally applicable to any situation in which 40 multiple PPP links connect two systems, including async links. This 41 is accomplished by means of new PPP [2] options and protocols. 43 Draft PPP Multilink December 1995 45 The differences between the current PPP Multilink specification (RFC 46 1717) and this memo are explained in Section 10. Any system 47 implementing the additional restrictions required by this memo will 48 be backwards compatible with conforming RFC 1717 implementations. | 49 Differences from the Stockholm draft (multilink-11.txt) are indicated | 50 by change bars. 52 Please send comments to ietf-ppp@merit.edu. 54 Acknowledgements 56 The authors specifically wish to thank Fred Baker of ACC, Craig Fox 57 of Network Systems, Gerry Meyer of Spider Systems, Dan Brennan of 58 Penril Datability Networks, Vernon Schryver of SGI (for the 59 comprehensive discussion of padding), and the members of the IP over 60 Large Public Data Networks and PPP Extensions working groups, for 61 much useful discussion on the subject. 63 Table of Contents 65 1. Introduction ................................................ 3 66 1.1. Motivation ................................................ 3 67 1.2. Functional Description .................................... 3 68 1.3. Conventions ............................................... 4 69 2. General Overview ............................................ 4 70 3. Packet Formats .............................................. 7 71 3.1. Padding Considerations .................................... 10 72 4. Trading Buffer Space Against Fragment Loss .................. 10 73 4.1. Detecting Fragment Loss ................................... 11 74 4.2. Buffer Space Requirements ................................. 12 75 5. PPP Link Control Protocol Extensions ........................ 13 76 5.1. Configuration Option Types ................................ 13 77 5.1.1. Multilink MRRU LCP option ............................... 14 78 5.1.2. Short Sequence Number Header Format Option .............. 15 79 5.1.3. Endpoint Discriminator Option ........................... 15 80 6. Initiating use of Multilink Headers ......................... 19 | 81 7. Closing Member links ........................................ 20 82 8. Interaction with Other Protocols ............................ 20 83 9. Security Considerations ..................................... 21 84 10. References ................................................. 22 85 11. Differences from RFC 1717 .................................. 23 86 11.1. Negotiating Multilink, per se ............................ 23 87 11.2. Initial Sequence Number defined .......................... 23 88 11.3. Default Value of the MRRU ................................ 23 89 11.4. Config-Nak of EID prohibited ............................. 23 90 11.5. Uniformity of Sequence Space ............................. 23 91 11.6. Commencing and Abating use of Multilink Headers .......... 23 | 92 11.7. Manual Configuration and Bundle Assignment ............... 24 | 94 Draft PPP Multilink December 1995 96 12. Expiration Date of this Draft .............................. 24 97 13. Authors' Addresses ......................................... 25 99 1. Introduction 101 1.1. Motivation 103 Basic Rate and Primary Rate ISDN both offer the possibility of 104 opening multiple simultaneous channels between systems, giving users 105 additional bandwidth on demand (for additional cost). Previous 106 proposals for the transmission of internet protocols over ISDN have 107 stated as a goal the ability to make use of this capability, (e.g., 108 Leifer et al., [1]). 110 There are proposals being advanced for providing synchronization 111 between multiple streams at the bit level (the BONDING proposals); 112 such features are not as yet widely deployed, and may require 113 additional hardware for end system. Thus, it may be useful to have a 114 purely software solution, or at least an interim measure. 116 There are other instances where bandwidth on demand can be exploited, 117 such as using a dialup async line at 28,800 baud to back up a leased 118 synchronous line, or opening additional X.25 SVCs where the window 119 size is limited to two by international agreement. 121 The simplest possible algorithms of alternating packets between 122 channels on a space available basis (which might be called the Bank 123 Teller's algorithm) may have undesirable side effects due to 124 reordering of packets. 126 By means of a four-byte sequencing header, and simple synchronization 127 rules, one can split packets among parallel virtual circuits between 128 systems in such a way that packets do not become reordered, or at 129 least the likelihood of this is greatly reduced. 131 1.2. Functional Description 133 The method discussed here is similar to the multilink protocol 134 described in ISO 7776 [4], but offers the additional ability to split 135 and recombine packets, thereby reducing latency, and potentially 136 increase the effective maximum receive unit (MRU). Furthermore, 137 there is no requirement here for acknowledged-mode operation on the 138 link layer, although that is optionally permitted. 140 Multilink is based on an LCP option negotiation that permits a system 141 to indicate to its peer that it is capable of combining multiple 142 physical links into a "bundle". Only under exceptional conditions 143 would a given pair of systems require the operation of more than one 145 Draft PPP Multilink December 1995 147 bundle connecting them. 149 Multilink is negotiated during the initial LCP option negotiation. A 150 system indicates to its peer that it is willing to do multilink by 151 sending the multilink option as part of the initial LCP option 152 negotiation. This negotiation indicates three things: 154 1. The system offering the option is capable of combining multiple 155 physical links into one logical link; 157 2. The system is capable of receiving upper layer protocol data 158 units (PDU) fragmented using the multilink header (described 159 later) and reassembling the fragments back into the original PDU 160 for processing; 162 3. The system is capable of receiving PDUs of size N octets where N 163 is specified as part of the option even if N is larger than the 164 maximum receive unit (MRU) for a single physical link. 166 Once multilink has been successfully negotiated, the sending system 167 is free to send PDUs encapsulated and/or fragmented with the 168 multilink header. 170 1.3. Conventions 172 The following language conventions are used in the items of 173 specification in this document: 175 o MUST, SHALL or MANDATORY -- the item is an absolute requirement 176 of the specification. 178 o SHOULD or RECOMMENDED -- the item should generally be followed 179 for all but exceptional circumstances. 181 o MAY or OPTIONAL -- the item is truly optional and may be 182 followed or ignored according to the needs of the implementor. 184 2. General Overview 186 In order to establish communications over a point-to-point link, each 187 end of the PPP link must first send LCP packets to configure the data 188 link during Link Establishment phase. After the link has been 189 established, PPP provides for an Authentication phase in which the 190 authentication protocols can be used to determine identifiers 191 associated with each system connected by the link. 193 The goal of multilink operation is to coordinate multiple independent 194 links between a fixed pair of systems, providing a virtual link with 196 Draft PPP Multilink December 1995 198 greater bandwidth than any of the constituent members. The aggregate 199 link, or bundle, is named by the pair of identifiers for two systems 200 connected by the multiple links. A system identifier may include 201 information provided by PPP Authentication [3] and information 202 provided by LCP negotiation. The bundled links can be different 203 physical links, as in multiple async lines, but may also be instances 204 of multiplexed links, such as ISDN, X.25 or Frame Relay. The links 205 may also be of different kinds, such as pairing dialup async links 206 with leased synchronous links. 208 We suggest that multilink operation can be modeled as a virtual PPP 209 link-layer entity wherein packets received over different physical 210 link-layer entities are identified as belonging to a separate PPP 211 network protocol (the Multilink Protocol, or MP) and recombined and 212 sequenced according to information present in a multilink 213 fragmentation header. All packets received over links identified as 214 belonging to the multilink arrangement are presented to the same 215 network-layer protocol processing machine, whether they have 216 multilink headers or not. 218 The packets to be transmitted using the multilink procedure are 219 encapsulated according to the rules for PPP where the following 220 options would have been manually configured: 222 o No async control character Map 223 o No Magic Number 224 o No Link Quality Monitoring 225 o Address and Control Field Compression 226 o Protocol Field Compression 227 o No Compound Frames 228 o No Self-Describing-Padding 230 According to the rules specified in RFC1661, this means that an | 231 implementation MUST accept reassembled packets with and without | 232 leading zeroes present in the Protocol Field of the reassembled | 233 packet. Although it is explicitly forbidden below to include the | 234 Address and Control fields (usually, the two bytes FF 03) in the | 235 material to be fragmented, it is a good defensive programming | 236 practice to accept the packet anyway, ignoring the two bytes if | 237 present, as that is what RFC1661 specifies. | 239 As a courtesy to implementations that perform better when certain | 240 alignment obtains, it is suggested that a determination be made when | 241 a bundle is created on whether to transmit leading zeroes by | 242 examining whether PFC has been negotiated on the first link admitted | 243 into a bundle. This determination should be kept in force so long as | 244 a bundle persists. | 246 Draft PPP Multilink December 1995 248 Of course, individual links are permitted to have different settings 249 for these options. As described below, member links SHOULD negotiate 250 Self-Describing-Padding, even though pre-fragmented packets MUST NOT 251 be padded. Since the Protocol Field Compression mode on the member | 252 link allows a sending system to include a leading byte of zero or not 253 at its discretion, this is an alternative mechanism for generating 254 even-length packets. 256 LCP negotiations are not permitted on the bundle itself. An 257 implementation MUST NOT transmit LCP Configure-Request, -Reject, 258 -Ack, -Nak, Terminate-Request or -Ack packets via the multilink 259 procedure, and an implementation receiving them MUST silently discard 260 them. (By "silently discard" we mean to not generate any PPP packets 261 in response; an implementation is free to generate a log entry 262 registering the reception of the unexpected packet). By contrast, 263 other LCP packets having control functions not associated with 264 changing the defaults for the bundle itself are permitted. An 265 implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo- 266 Request, Echo-Reply and Discard-Request Packets. 268 The effective MRU for the logical-link entity is negotiated via an 269 LCP option. It is irrelevant whether Network Control Protocol 270 packets are encapsulated in multilink headers or not, or even over 271 which link they are sent, once that link identifies itself as 272 belonging to a multilink arrangement. 274 Note that network protocols that are not sent using multilink headers 275 cannot be sequenced. (And consequently will be delivered in any 276 convenient way). 278 For example, consider the case in Figure 1. Link 1 has negotiated 279 network layers NL 1, NL 2, and MP between two systems. The two 280 systems then negotiate MP over Link 2. 282 Frames received on link 1 are demultiplexed at the data link layer 283 according the PPP network protocol identifier and can be sent to NL 284 1, NL 2, or MP. Link 2 will accept frames with all network protocol 285 identifiers that Link 1 does. 287 Frames received by MP are further demultiplexed at the network layer 288 according to the PPP network protocol identifier and sent to NL 1 or 289 NL 2. Any frames received by MP for any other network layer 290 protocols are rejected using the normal protocol reject mechanism. 292 Draft PPP Multilink December 1995 294 Figure 1. Multilink Overview. 296 Network Layer 297 ------------- 298 ______ ______ 299 / \ / \ 300 | NL 1 | | NL 2 | 301 \______/ \______/ 302 | | | | | | 303 | | +-------------o-o-o-+ 304 | +------+ +-----+ | | | 305 | | | | | | 306 | +------o--o-------+ + | 307 | | |__|_ | | 308 | | / \ | | 309 | | | MLCP | <--- Link Layer 310 | | \______/ Demultiplexing 311 | | | | | 312 | | | | | 313 | | | <--- Virtual Link 314 | | | | | 315 | | | | | 316 | | | | | 317 | | + | | 318 ___|_| | ___|_| 319 / \ | / \ 320 | LCP |------+-----| LCP | <--- Link Layer 321 \______/ \______/ Demultiplexing 322 | | 323 | | 324 Link 1 Link 2 326 3. Packet Formats 328 In this section we describe the layout of individual fragments, which 329 are the "packets" in the Multilink Protocol. Network Protocol 330 packets are first encapsulated (but not framed) according to normal 331 PPP procedures, and large packets are broken up into multiple 332 segments sized appropriately for the multiple physical links. 333 Although it would otherwise be permitted by the PPP spec, 334 implementations MUST NOT include the Address and Control Field in the 335 logical entity to be fragmented. A new PPP header consisting of the 336 Multilink Protocol Identifier, and the Multilink header is inserted 337 before each section. (Thus the first fragment of a multilink packet 338 in PPP will have two headers, one for the fragment, followed by the 339 header for the packet itself). 341 Draft PPP Multilink December 1995 343 Systems implementing the multilink procedure are not required to 344 fragment small packets. There is also no requirement that the 345 segments be of equal sizes, or that packets must be broken up at all. 346 A possible strategy for contending with member links of differing 347 transmission rates would be to divide the packets into segments 348 proportion to the transmission rates. Another strategy might be to 349 divide them into many equal fragments and distribute multiple 350 fragments per link, the numbers being proportional to the relative 351 speeds of the links. 353 PPP multilink fragments are encapsulated using the protocol 354 identifier 0x00-0x3d. Following the protocol identifier is a four 355 byte header containing a sequence number, and two one bit fields 356 indicating that the fragment begins a packet or terminates a packet. 357 After negotiation of an additional PPP LCP option, the four byte 358 header may be optionally replaced by a two byte header with only a 12 359 bit sequence space. Address & Control and Protocol ID compression 360 are assumed to be in effect. Individual fragments will, therefore, 361 have the following format: 363 Figure 2: Long Sequence Number Fragment Format. 365 +---------------+---------------+ 366 PPP Header: | Address 0xff | Control 0x03 | 367 +---------------+---------------+ 368 | PID(H) 0x00 | PID(L) 0x3d | 369 +-+-+-+-+-+-+-+-+---------------+ 370 MP Header: |B|E|0|0|0|0|0|0|sequence number| 371 +-+-+-+-+-+-+-+-+---------------+ 372 | sequence number (L) | 373 +---------------+---------------+ 374 | fragment data | 375 | . | 376 | . | 377 | . | 378 +---------------+---------------+ 379 PPP FCS: | FCS | 380 +---------------+---------------+ 382 Draft PPP Multilink December 1995 384 Figure 3: Short Sequence Number Fragment Format. 386 +---------------+---------------+ 387 PPP Header: | Address 0xff | Control 0x03 | 388 +---------------+---------------+ 389 | PID(H) 0x00 | PID(L) 0x3d | 390 +-+-+-+-+-------+---------------+ 391 MP Header: |B|E|0|0| sequence number | 392 +-+-+-+-+-------+---------------+ 393 | fragment data | 394 | . | 395 | . | 396 | . | 397 +---------------+---------------+ 398 PPP FCS: | FCS | 399 +---------------+---------------+ 401 The (B)eginning fragment bit is a one bit field set to 1 on the first 402 fragment derived from a PPP packet and set to 0 for all other 403 fragments from the same PPP packet. 405 The (E)nding fragment bit is a one bit field set to 1 on the last 406 fragment and set to 0 for all other fragments. A fragment may have 407 both the (B)eginning and (E)nding fragment bits set to 1. 409 The sequence field is a 24 bit or 12 bit number that is incremented 410 for every fragment transmitted. By default, the sequence field is 24 411 bits long, but can be negotiated to be only 12 bits with an LCP 412 configuration option described below. 414 Between the (E)nding fragment bit and the sequence number is a 415 reserved field, whose use is not currently defined, which MUST be set 416 to zero. It is 2 bits long when the use of short sequence numbers 417 has been negotiated, 6 bits otherwise. 419 In this multilink protocol, a single reassembly structure is 420 associated with the bundle. The multilink headers are interpreted in 421 the context of this structure. 423 The FCS field shown in the diagram is inherited from the normal 424 framing mechanism from the member link on which the packet is 425 transmitted. There is no separate FCS applied to the reconstituted 426 packet as a whole if transmitted in more than one fragment. 428 Draft PPP Multilink December 1995 430 3.1. Padding Considerations 432 Systems that support the multilink protocol SHOULD implement Self- 433 Describing-Padding. A system that implements self-describing-padding 434 by definition will either include the padding option in its initial 435 LCP Configure-Requests, or (to avoid the delay of a Configure-Reject) 436 include the padding option after receiving a NAK containing the 437 option. 439 A system that must pad its own transmissions but does not use Self- 440 Describing-Padding when not using multilink, MAY continue to not use 441 Self-Describing-Padding if it ensures by careful choice of fragment 442 lengths that only (E)nding fragments of packets are padded. A system 443 MUST NOT add padding to any packet that cannot be recognized as 444 padded by the peer. Non-terminal fragments MUST NOT be padded with 445 trailing material by any other method than Self-Describing-Padding. 447 A system MUST ensure that Self-Describing-Padding as described in RFC 448 1570 [11] is negotiated on the individual link before transmitting 449 any multilink data packets if it might pad non-terminal fragments or 450 if it would use network or compression protocols that are vulnerable 451 to padding, as described in RFC 1570. If necessary, the system that 452 adds padding MUST use LCP Configure-NAK's to elicit a Configure- 453 Request for Self-Describing-Padding from the peer. 455 Note that LCP Configure-Requests can be sent at any time on any link, 456 and that the peer will always respond with a Configure-Request of its 457 own. A system that pads its transmissions but uses no protocols 458 other than multilink that are vulnerable to padding MAY delay 459 ensuring that the peer has Configure-Requested Self-Describing- 460 Padding until it seems desireable to negotiate the use of Multilink 461 itself. This permits the interoperability of a system that pads with 462 older peers that support neither Multilink nor Self-Describing- 463 Padding. 465 4. Trading Buffer Space Against Fragment Loss 467 In a multilink procedure one channel may be delayed with respect to 468 the other channels in the bundle. This can lead to fragments being 469 received out of order, thus increasing the difficulty in detecting 470 the loss of a fragment. The task of estimating the amount of space 471 required for buffering on the receiver becomes more complex because 472 of this. In this section we discuss a technique for declaring that a 473 fragment is lost, with the intent of minimizing the buffer space 474 required, yet minimizing the number of avoidable packet losses. 476 Draft PPP Multilink December 1995 478 4.1. Detecting Fragment Loss 480 On each member link in a bundle, the sender MUST transmit fragments 481 with strictly increasing sequence numbers (modulo the size of the 482 sequence space). This requirement supports a strategy for the 483 receiver to detect lost fragments based on comparing sequence 484 numbers. The sequence number is not reset upon each new PPP packet, 485 and a sequence number is consumed even for those fragments which 486 contain an entire PPP packet, i.e., one in which both the (B)eginning 487 and (E)nding bits are set. 489 An implementation MUST set the sequence number of the first fragment 490 transmited on a newly-constructed bundle to zero. (Joining a 491 secondary link to an exisiting bundle is invisible to the protocol, 492 and an implementation MUST NOT reset the sequence number space in 493 this situation). 495 The receiver keeps track of the incoming sequence numbers on each 496 link in a bundle and maintains the current minimum of the most 497 recently received sequence number over all the member links in the 498 bundle (call this M). The receiver detects the end of a packet when 499 it receives a fragment bearing the (E)nding bit. Reassembly of the 500 packet is complete if all sequence numbers up to that fragment have 501 been received. 503 A lost fragment is detected when M advances past the sequence number 504 of a fragment bearing an (E)nding bit of a packet which has not been 505 completely reassembled (i.e., not all the sequence numbers between 506 the fragment bearing the (B)eginning bit and the fragment bearing the 507 (E)nding bit have been received). This is because of the increasing 508 sequence number rule over the bundle. Any sequence number so 509 detected is assumed to correspond to a fragment which has been lost. 511 An implementation MUST assume that if a fragment bears a (B)eginning 512 bit, that the previously numbered fragment bore an (E)nding bit. 513 Thus if a packet is lost bearing the (E)nding bit, and the packet 514 whose fragment number is M contains a (B)eginning bit, the 515 implementation MUST discard fragments for all unassembled packets 516 through M-1, but SHOULD NOT discard the fragment bearing the new 517 (B)eginning bit on this basis alone. 519 The detection of a lost fragment, whose sequence number was deduced 520 to be U, causes the receiver to discard all fragments up to the 521 lowest numbered fragment with an ending bit (possibly deduced) 522 greater than or equal to U. However, the quantity M may jump into 523 the middle of a chain of packets which can be successful completed. 525 Draft PPP Multilink December 1995 527 Fragments may be lost due to corruption of individual packets or 528 catastrophic loss of the link (which may occur only in one 529 direction). This version of the multilink protocol mandates no 530 specific procedures for the detection of failed links. The PPP link 531 quality management facility, or the periodic issuance of LCP echo- 532 requests could be used to achieve this. 534 Senders SHOULD avoid keeping any member links idle to maximize early 535 detection of lost fragments by the receiver, since the value of M is 536 not incremented on idle links. Senders SHOULD rotate traffic among 537 the member links if there isn't sufficient traffic to overflow the 538 capacity of one link to avoid idle links. 540 Loss of the final fragment of a transmission can cause the receiver 541 to stall until new packets arrive. The likelihood of this may be 542 decreased by sending a null fragment on each member link in a bundle 543 that would otherwise become idle immediately after having transmitted 544 a fragment bearing the (E)nding bit, where a null fragment is one 545 consisting only of a multilink header bearing both the (B)egin and 546 (E)nding bits (i.e., having no payload). Implementations concerned 547 about either wasting bandwidth or per packet costs are not required 548 to send null fragments and may elect to defer sending them until a 549 timer expires, with the marginally increased possibility of lengthier 550 stalls in the receiver. The receiver SHOULD implement some type of 551 link idle timer to guard against indefinite stalls. 553 The increasing sequence per link rule prohibits the reallocation of 554 fragments queued up behind a failing link to a working one, a 555 practice which is not unusual for implementations of ISO multilink 556 over LAPB [4]. 558 4.2. Buffer Space Requirements 560 There is no amount of buffering that will guarantee correct detection 561 of fragment loss, since an adversarial peer may withhold a fragment 562 on one channel and send arbitrary amounts on the others. For the 563 usual case where all channels are transmitting, you can show that 564 there is a minimum amount below which you could not correctly detect 565 packet loss. The amount depends on the relative delay between the 566 channels, (D[channel-i,channel-j]), the data rate of each channel, 567 R[c], the maximum fragment size permitted on each channel, F[c], and 568 the total amount of buffering the transmitter has allocated amongst 569 the channels. 571 When using PPP, the delay between channels could be estimated by 572 using LCP echo request and echo reply packets. (In the case of links 573 of different transmission rates, the round trip times should be 574 adjusted to take this into account.) The slippage for each channel 576 Draft PPP Multilink December 1995 578 is defined as the bandwidth times the delay for that channel relative 579 to the channel with the longest delay, S[c] = R[c] * D[c,c-worst]. 580 (S[c-worst] will be zero, of course!) 582 A situation which would exacerbate sequence number skew would be one 583 in which there is extremely bursty traffic (almost allowing all 584 channels to drain), and then where the transmitter would first queue 585 up as many consecutively numbered packets on one link as it could, 586 then queue up the next batch on a second link, and so on. Since 587 transmitters must be able to buffer at least a maximum- sized 588 fragment for each link (and will usually buffer up at least two) A 589 receiver that allocates any less than S[1] + S[2] + ... + S[N] + F[1] 590 + ... + F[N], will be at risk for incorrectly assuming packet loss, 591 and therefore, SHOULD allocate at least twice that. 593 5. PPP Link Control Protocol Extensions 595 If reliable multilink operation is desired, PPP Reliable Transmission 596 [6] (essentially the use of ISO LAPB) MUST be negotiated prior to the 597 use of the Multilink Protocol on each member link. 599 Whether or not reliable delivery is employed over member links, an 600 implementation MUST present a signal to the NCP's running over the 601 multilink arrangement that a loss has occurred. 603 Compression may be used separately on each member link, or run over 604 the bundle (as a logical group link). The use of multiple 605 compression streams under the bundle (i.e., on each link separately) 606 is indicated by running the Compression Control Protocol [5] but with 607 an alternative PPP protocol ID. 609 5.1. Configuration Option Types 611 The Multilink Protocol introduces the use of additional LCP 612 Configuration Options: 614 o Multilink Maximum Received Reconstructed Unit 615 o Multilink Short Sequence Number Header Format 616 o Endpoint Discriminator 618 Draft PPP Multilink December 1995 620 5.1.1. Multilink MRRU LCP option 622 Figure 4: Multilink MRRU LCP option 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Type = 17 | Length = 4 | Max-Receive-Reconstructed-Unit| 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 The presence of this LCP option indicates that the system sending it 631 implements the PPP Multilink Protocol. If not rejected, the system 632 will construe all packets received on this link as being able to be 633 processed by a common protocol machine with any other packets 634 received from the same peer on any other link on which this option 635 has been accepted. 637 The Max-Receive-Reconstructed unit field is two octets, and specifies 638 the maximum number of octets in the Information fields of reassembled 639 packets. A system MUST be able to receive the full 1500 octet 640 Information field of any reassembled PPP packet although it MAY 641 attempt to negotiate a smaller, or larger value. The number 1500 642 here comes from the specification for the MRU LCP option in PPP; if 643 this requirement is changed in a future version of RFC 1661, the same 644 rules will apply here. 646 A system MUST include the LCP MRRU option in every LCP negotiation 647 intended to instantiate a bundle or to join an existing bundle. If 648 the LCP MRRU option is offered on a link which is intended to join an 649 existing bundle, a system MUST offer the same Max-Receive- 650 Reconstruct-Unit value previously negotiated for the bundle. 652 A system MUST NOT send any multilink packets on any link unless its 653 peer has offered the MMRU LCP option and the system has configure- 654 Ack'ed it during the most recent LCP negotiation on that link. A 655 system MAY include the MMRU LCP option in a configure-NAK, if its 656 peer has not offered it (until, according to PPP rules, the peer 657 configure-Reject's it). 659 Note: the MRRU value conveyed im this option corresponds to the MRU 660 of the bundle when conceptualized as a PPP entity; but the rules for 661 the Multilink MRRU option are different from the LCP MRU option, as 662 some value MUST be offered in every LCP negotiation, and that 663 confirmation of this option is required prior to multilink 664 interpretation. 666 Draft PPP Multilink December 1995 668 5.1.2. Short Sequence Number Header Format Option 670 Figure 5: Short Sequence Number Header Format Option 672 0 1 673 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Type = 18 | Length = 2 | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 This option advises the peer that the implementation wishes to 679 receive fragments with short, 12 bit sequence numbers. When a peer 680 system configure-Ack's this option, it MUST transmit all multilink 681 packets on all links of the bundle with 12 bit sequence numbers or 682 configure-Reject the option. If 12 bit sequence numbers are desired, 683 this option MUST be negotiated when the bundle is instantiated, and 684 MUST be explicitly included in every LCP configure request offered by 685 a system when the system intends to include that link in an existing 686 bundle using 12 bit sequence numbers. If this option is never 687 negotiated during the life of a bundle, sequence numbers are 24 bits 688 long. 690 An implementation wishing to transmit multilink fragments with short 691 sequence numbers MAY include the multilink short sequence number in a 692 configure-NAK to ask that the peer respond with a request to receive 693 short sequence numbers. The peer is not compelled to respond with 694 the option. 696 5.1.3. Endpoint Discriminator Option 698 Figure 7: Endpoint Discriminator Option 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Type = 19 | Length | Class | Address ... 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 The Endpoint Discriminator Option represents identification of the 707 system transmitting the packet. This option advises a system that 708 the peer on this link could be the same as the peer on another 709 existing link. If the option distinguishes this peer from all 710 others, a new bundle MUST be established from the link being 711 negotiated. If this option matches the class and address of some 712 other peer of an existing link, the new link MUST be joined to the 713 bundle containing the link to the matching peer or MUST establish a 714 new bundle, depending on the decision tree shown in (1) through (4) 715 below. 717 Draft PPP Multilink December 1995 719 To securely join an existing bundle, a PPP authentication protocol 720 [3] must be used to obtain authenticated information from the peer to 721 prevent a hostile peer from joining an existing bundle by presenting 722 a falsified discriminator option. 724 This option is not required for multilink operation. If a system | 725 does not receive the Multilink MRRU option, but does receive the | 726 Endpoint Discriminator Option, and there is no manual configuration 727 providing outside information, the implementation MUST NOT assume 728 that multilink operation is being requested on this basis alone. 730 As there is also no requirement for authentication, there are four 731 sets of scenarios: 733 (1) No authentication, no discriminator: 734 All new links MUST be joined to one bundle, unless | 735 there is manual configuration to the contrary. | 736 It is also permissible to have more than one manually | 737 configured bundle connecting two given systems. | 739 (2) Discriminator, no authentication: 740 Discriminator match -> MUST join matching bundle, 741 discriminator mismatch -> MUST establish new bundle. 743 (3) No discriminator, authentication: 744 Authenticated match -> MUST join matching bundle, 745 authenticated mismatch -> MUST establish new bundle. 747 (4) Discriminator, authentication: 748 Discriminator match and authenticated match -> MUST join bundle, 749 discriminator mismatch -> MUST establish new bundle, 750 authenticated mismatch -> MUST establish new bundle. 752 The option contains a Class which selects an identifier address space 753 and an Address which selects a unique identifier within the class 754 address space. 756 This identifier is expected to refer to the mechanical equipment 757 associated with the transmitting system. For some classes, 758 uniqueness of the identifier is global and is not bounded by the 759 scope of a particular administrative domain. Within each class, 760 uniqueness of address values is controlled by a class dependent 761 policy for assigning values. 763 Each endpoint may chose an identifier class without restriction. 764 Since the objective is to detect mismatches between endpoints 765 erroneously assumed to be alike, mismatch on class alone is 766 sufficient. Although no one class is recommended, classes which have 768 Draft PPP Multilink December 1995 770 universally unique values are preferred. 772 This option is not required to be supported either by the system or 773 the peer. If the option is not present in a Configure-Request, the 774 system MUST NOT generate a Configure-Nak of this option for any 775 reason; instead it SHOULD behave as if it had received the option 776 with Class = 0, Address = 0. If a system receives a Configure-Nak or 777 Configure-Reject of this option, it MUST remove it from any 778 additional Configure-Request. 780 The size is determined from the Length field of the element. For 781 some classes, the length is fixed, for others the length is variable. 782 The option is invalid if the Length field indicates a size below the 783 minimum for the class. 785 An implementation MAY use the Endpoint Discriminator to locate 786 administration or authentication records in a local database. Such 787 use of this option is incidental to its purpose and is deprecated 788 when a PPP Authentication protocol [3] can be used instead. Since 789 some classes permit the peer to generate random or locally assigned 790 address values, use of this option as a database key requires prior 791 agreement between peer administrators. 793 The specification of the subfields are: 795 Type 796 19 = for Endpoint Discriminator 798 Length 799 3 + length of Address 801 Class 802 The Class field is one octet and indicates the identifier 803 address space. The most up-to-date values of the LCP Endpoint 804 Discriminator Class field are specified in the most recent 805 "Assigned Numbers" RFC [7]. Current values are assigned as 806 follows: 808 0 Null Class 810 1 Locally Assigned Address 812 2 Internet Protocol (IP) Address 814 3 IEEE 802.1 Globally Assigned MAC Address 816 4 PPP Magic-Number Block 818 Draft PPP Multilink December 1995 820 5 Public Switched Network Directory Number 822 Address 823 The Address field is one or more octets and indicates the 824 identifier address within the selected class. The length and 825 content depend on the value of the Class as follows: 827 Class 0 - Null Class 829 Maximum Length: 0 831 Content: 832 This class is the default value if the option is not 833 present in a received Configure-Request. 835 Class 1 - Locally Assigned Address 837 Maximum Length: 20 839 Content: 841 This class is defined to permit a local assignment in the 842 case where use of one of the globally unique classes is not 843 possible. Use of a device serial number is suggested. The 844 use of this class is deprecated since uniqueness is not 845 guaranteed. 847 Class 2 - Internet Protocol (IP) Address 849 Fixed Length: 4 851 Content: 853 An address in this class contains an IP host address as 854 defined in [8]. 856 Class 3 - IEEE 802.1 Globally Assigned MAC Address 858 Fixed Length: 6 860 Content: 862 An address in this class contains an IEEE 802.1 MAC address 863 in canonical (802.3) format [9]. The address MUST have the 864 global/local assignment bit clear and MUST have the 865 multicast/specific bit clear. Locally assigned MAC 866 addresses should be represented using Class 1. 868 Draft PPP Multilink December 1995 870 Class 4 - PPP Magic-Number Block 872 Maximum Length: 20 874 Content: 876 This is not an address but a block of 1 to 5 concatenated 877 32 bit PPP Magic-Numbers as defined in [2]. This class 878 provides for automatic generation of a value likely but not 879 guaranteed to be unique. The same block MUST be used by an 880 endpoint continuously during any period in which at least 881 one link is in the LCP Open state. The use of this class 882 is deprecated. 884 Note that PPP Magic-Numbers are used in [2] to detect 885 unexpected loopbacks of a link from an endpoint to itself. 886 There is a small probability that two distinct endpoints 887 will generate matching magic-numbers. This probability is 888 geometrically reduced when the LCP negotiation is repeated 889 in search of the desired mismatch, if a peer can generate 890 uncorrelated magic-numbers. 892 As used here, magic-numbers are used to determine if two 893 links are in fact from the same peer endpoint or from two 894 distinct endpoints. The numbers always match when there is 895 one endpoint. There is a small probability that the 896 numbers will match even if there are two endpoints. To 897 achieve the same confidence that there is not a false match 898 as for LCP loopback detection, several uncorrelated magic- 899 numbers can be combined in one block. 901 Class 5 - Public Switched Network Directory Number 903 Maximum Length: 15 905 Content: 907 An address in this class contains an octet sequence as 908 defined by I.331 (E.164) representing an international 909 telephone directory number suitable for use to access the 910 endpoint via the public switched telephone network [10]. 912 6. Initiating use of Multilink Headers | 914 When the use of the Multilink protocol has been negotiated on a link | 915 (say Y), and the link is being added to a bundle which currently | 916 contains a single existing link (say X), a system MUST transmit a | 917 Multilink-encapsulated packet on X before transmitting any Multilink- | 919 Draft PPP Multilink December 1995 921 encapsulated packets on Y. | 923 Since links may be added and removed from a bundle without destroying | 924 the state associated with it, the fragment should be assigned the | 925 appropriate (next) fragment number. As noted earlier, the first | 926 fragment transmitted in the life of a bundle is assigned fragment | 927 number 0. 929 7. Closing Member links 931 Member links may be terminated according to normal PPP LCP procedures 932 using LCP Terminate-Request and Terminate-Ack packets on that member 933 link. Since it is assumed that member links usually do not reorder 934 packets, receipt of a terminate ack is sufficient to assume that any 935 multilink protocol packets ahead of it are at no special risk of 936 loss. 938 Receipt of an LCP Terminate-Request on one link does not conclude the 939 procedure on the remaining links. 941 So long as any member links in the bundle are active, the PPP state 942 for the bundle persists as a separate entity. However, if the there | 943 is a unique link in the bundle, and all the other links were closed | 944 gracefully (with Terminate-Ack), an implementation MAY cease using | 945 multilink headers. | 947 If the multilink procedure is used in conjunction with PPP reliable 948 transmission, and a member link is not closed gracefully, the 949 implementation should expect to receive packets which violate the 950 increasing sequence number rule. 952 8. Interaction with Other Protocols 954 In the common case, LCP, and the Authentication Control Protocol 955 would be negotiated over each member link. The Network Protocols 956 themselves and associated control exchanges would normally have been 957 conducted once, on the bundle. 959 In some instances it may be desirable for some Network Protocols to 960 be exempted from sequencing requirements, and if the MRU sizes of the 961 link did not cause fragmentation, those protocols could be sent 962 directly over the member links. 964 Although explicitly discouraged above, if there were several member 965 links connecting two implementations, and independent sequencing of 966 two protocol sets were desired, but blocking of one by the other was 967 not, one could describe two multilink procedures by assigning 968 multiple endpoint identifiers to a given system. Each member link, 970 Draft PPP Multilink December 1995 972 however, would only belong to one bundle. One could think of a 973 physical router as housing two logically separate implementations, 974 each of which is independently configured. 976 A simpler solution would be to have one link refuse to join the 977 bundle, by sending a Configure-Reject in response to the Multilink 978 LCP option. 980 9. Security Considerations 982 Operation of this protocol is no more and no less secure than 983 operation of the PPP authentication protocols [3]. The reader is 984 directed there for further discussion. 986 Draft PPP Multilink December 1995 988 10. References 990 [1] Leifer, D., Sheldon, S., and B. Gorsline, "A Subnetwork Control 991 Protocol for ISDN Circuit-Switching", University of Michigan 992 (unpublished), March 1991. 994 [2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, 995 RFC 1661, Daydreamer, July 1994. 997 [3] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 998 1334, Lloyd Internetworking, Daydreamer, October 1992. 1000 [4] International Organisation for Standardization, "HDLC - 1001 Description of the X.25 LAPB-Compatible DTE Data Link 1002 Procedures", International Standard 7776, 1988 1004 [5] Rand, D., "The PPP Compression Control Protocol (CCP)", PPP 1005 Extensions Working Group, Work in Progress. 1007 [6] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 1008 1994 1010 [7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1011 USC/Information Sciences Institute, October 1994. 1013 [8] Postel, J., Editor, "Internet Protocol - DARPA Internet Program 1014 Protocol Specification", STD 5, RFC 791, USC/Information Sciences 1015 Institute, September 1981. 1017 [9] Institute of Electrical and Electronics Engineers, Inc., "IEEE 1018 Local and Metropolitan Area Networks: Overview and Architecture", 1019 IEEE Std. 802-1990, 1990. 1021 [10] The International Telegraph and Telephone Consultative Committee 1022 (CCITT), "Numbering Plan for the ISDN Area", Recommendation I.331 1023 (E.164), 1988. 1025 [11] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer, 1026 January 1994. 1028 Draft PPP Multilink December 1995 1030 11. Differences from RFC 1717 1032 This section documents differences from RFC 1717. There are 1033 restrictions placed on implementations that were absent in RFC 1717; 1034 systems obeying these restrictions are fully interoperable with RFC 1035 1717 - compliant systems. 1037 11.1. Negotiating Multilink, per se 1039 RFC 1717 permitted either the use of the Short Sequence Number Header 1040 Format (SSNHF) or the Maximum Reconstructed Receive Unit (MRRU) 1041 options by themselves to indicate the intent to negotiate multilink. 1042 This specification forbids the use of the SSNHF option by itself; but 1043 does permit the specific of both options together. Any 1044 implementation which otherwise conforms to rfc1717 and also obeys 1045 this restriction will interoperate with any RFC 1717 implementation. 1047 11.2. Initial Sequence Number defined 1049 This specification requires that the first sequence number 1050 transmitted after the virtual link has reached to open state be 0. 1052 11.3. Default Value of the MRRU 1054 This specfication removes the default value for the MRRU, (since it 1055 must always be negotiated with some value), and specifies that an 1056 implementation must be support an MRRU with same value as the default 1057 MRU size for PPP. 1059 11.4. Config-Nak of EID prohibited 1061 THis specification forbids the config-Naking of an EID for any 1062 reason. 1064 11.5. Uniformity of Sequence Space 1066 This specification requires that the same sequence format be employed 1067 on all links in a bundle. | 1069 11.6. Commencing and Abating use of Multilink Headers | 1071 This draft specifies how one should start the use of Multilink | 1072 Headers when a link is added, and under what circumstances it is safe | 1073 to discontinue their use. | 1075 Draft PPP Multilink December 1995 1077 11.7. Manual Configuration and Bundle Assignment | 1079 THe draft explicitly permits multiple bundles to be manually | 1080 configured in the absence of both the Endpoint Descriminator and any | 1081 form of authentication. 1083 12. Expiration Date of this Draft 1085 June 15th, 1996 1087 Draft PPP Multilink December 1995 1089 13. Authors' Addresses 1091 Keith Sklower 1092 Computer Science Department 1093 384 Soda Hall, Mail Stop 1776 1094 University of California 1095 Berkeley, CA 94720-1776 1097 Phone: (510) 642-9587 1098 EMail: sklower@CS.Berkeley.EDU 1100 Brian Lloyd 1101 Lloyd Internetworking 1102 3031 Alhambra Drive 1103 Cameron Park, CA 95682 1105 Phone: (916) 676-1147 1106 EMail: brian@lloyd.com 1108 Glenn McGregor 1109 Lloyd Internetworking 1110 3031 Alhambra Drive 1111 Cameron Park, CA 95682 1113 Phone: (916) 676-1147 1114 EMail: glenn@lloyd.com 1116 Dave Carr 1117 Newbridge Networks Corporation 1118 600 March Road 1119 P.O. Box 13600 1120 Kanata, Ontario, 1121 Canada, K2K 2E6 1123 Phone: (613) 591-3600 1124 EMail: dcarr@Newbridge.COM 1126 Tom Coradetti 1127 Sidewalk Software 1128 1190 Josephine Road 1129 Roseville, MN 55113 1131 Phone: (612) 490 7856 1132 Email: 70761.1664@compuserve.com