1 2 3 4 5 6 7Network Working Group K. Sklower 8Request for Comments: 1990 University of California, Berkeley 9Obsoletes: 1717 B. Lloyd 10Category: Standards Track G. McGregor 11 Lloyd Internetworking 12 D. Carr 13 Newbridge Networks Corporation 14 T. Coradetti 15 Sidewalk Software 16 August 1996 17 18 19 The PPP Multilink Protocol (MP) 20 21 22Status of this Memo 23 24 This document specifies an Internet standards track protocol for the 25 Internet community, and requests discussion and suggestions for 26 improvements. Please refer to the current edition of the "Internet 27 Official Protocol Standards" (STD 1) for the standardization state 28 and status of this protocol. Distribution of this memo is unlimited. 29 30Abstract 31 32 This document proposes a method for splitting, recombining and 33 sequencing datagrams across multiple logical data links. This work 34 was originally motivated by the desire to exploit multiple bearer 35 channels in ISDN, but is equally applicable to any situation in which 36 multiple PPP links connect two systems, including async links. This 37 is accomplished by means of new PPP [2] options and protocols. 38 39 The differences between the current PPP Multilink specification (RFC 40 1717) and this memo are explained in Section 11. Any system 41 implementing the additional restrictions required by this memo will 42 be backwards compatible with conforming RFC 1717 implementations. 43 44Acknowledgements 45 46 The authors specifically wish to thank Fred Baker of ACC, Craig Fox 47 of Network Systems, Gerry Meyer of Spider Systems, Dan Brennan of 48 Penril Datability Networks, Vernon Schryver of SGI (for the 49 comprehensive discussion of padding), and the members of the IP over 50 Large Public Data Networks and PPP Extensions working groups, for 51 much useful discussion on the subject. 52 53 54 55 56 57 58Sklower, et. al. Standards Track [Page 1] 59 60RFC 1990 PPP Multilink August 1996 61 62 63Table of Contents 64 65 1. Introduction ................................................ 2 66 1.1. Motivation ................................................ 2 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 ................................................. 21 85 11. Differences from RFC 1717 .................................. 22 86 11.1. Negotiating Multilink, per se ............................ 22 87 11.2. Initial Sequence Number defined .......................... 22 88 11.3. Default Value of the MRRU ................................ 22 89 11.4. Config-Nak of EID prohibited ............................. 22 90 11.5. Uniformity of Sequence Space ............................. 22 91 11.6. Commencing and Abating use of Multilink Headers .......... 23 92 11.7. Manual Configuration and Bundle Assignment ............... 23 93 12. Authors' Addresses ......................................... 24 94 951. Introduction 96 971.1. Motivation 98 99 Basic Rate and Primary Rate ISDN both offer the possibility of 100 opening multiple simultaneous channels between systems, giving users 101 additional bandwidth on demand (for additional cost). Previous 102 proposals for the transmission of internet protocols over ISDN have 103 stated as a goal the ability to make use of this capability, (e.g., 104 Leifer et al., [1]). 105 106 There are proposals being advanced for providing synchronization 107 between multiple streams at the bit level (the BONDING proposals); 108 such features are not as yet widely deployed, and may require 109 additional hardware for end system. Thus, it may be useful to have a 110 purely software solution, or at least an interim measure. 111 112 113 114Sklower, et. al. Standards Track [Page 2] 115 116RFC 1990 PPP Multilink August 1996 117 118 119 There are other instances where bandwidth on demand can be exploited, 120 such as using a dialup async line at 28,800 baud to back up a leased 121 synchronous line, or opening additional X.25 SVCs where the window 122 size is limited to two by international agreement. 123 124 The simplest possible algorithms of alternating packets between 125 channels on a space available basis (which might be called the Bank 126 Teller's algorithm) may have undesirable side effects due to 127 reordering of packets. 128 129 By means of a four-byte sequencing header, and simple synchronization 130 rules, one can split packets among parallel virtual circuits between 131 systems in such a way that packets do not become reordered, or at 132 least the likelihood of this is greatly reduced. 133 1341.2. Functional Description 135 136 The method discussed here is similar to the multilink protocol 137 described in ISO 7776 [4], but offers the additional ability to split 138 and recombine packets, thereby reducing latency, and potentially 139 increase the effective maximum receive unit (MRU). Furthermore, 140 there is no requirement here for acknowledged-mode operation on the 141 link layer, although that is optionally permitted. 142 143 Multilink is based on an LCP option negotiation that permits a system 144 to indicate to its peer that it is capable of combining multiple 145 physical links into a "bundle". Only under exceptional conditions 146 would a given pair of systems require the operation of more than one 147 bundle connecting them. 148 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: 153 154 1. The system offering the option is capable of combining multiple 155 physical links into one logical link; 156 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; 161 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. 165 166 167 168 169 170Sklower, et. al. Standards Track [Page 3] 171 172RFC 1990 PPP Multilink August 1996 173 174 175 Once multilink has been successfully negotiated, the sending system 176 is free to send PDUs encapsulated and/or fragmented with the 177 multilink header. 178 1791.3. Conventions 180 181 The following language conventions are used in the items of 182 specification in this document: 183 184 o MUST, SHALL or MANDATORY -- the item is an absolute requirement 185 of the specification. 186 187 o SHOULD or RECOMMENDED -- the item should generally be followed 188 for all but exceptional circumstances. 189 190 o MAY or OPTIONAL -- the item is truly optional and may be 191 followed or ignored according to the needs of the implementor. 192 1932. General Overview 194 195 In order to establish communications over a point-to-point link, each 196 end of the PPP link must first send LCP packets to configure the data 197 link during Link Establishment phase. After the link has been 198 established, PPP provides for an Authentication phase in which the 199 authentication protocols can be used to determine identifiers 200 associated with each system connected by the link. 201 202 The goal of multilink operation is to coordinate multiple independent 203 links between a fixed pair of systems, providing a virtual link with 204 greater bandwidth than any of the constituent members. The aggregate 205 link, or bundle, is named by the pair of identifiers for two systems 206 connected by the multiple links. A system identifier may include 207 information provided by PPP Authentication [3] and information 208 provided by LCP negotiation. The bundled links can be different 209 physical links, as in multiple async lines, but may also be instances 210 of multiplexed links, such as ISDN, X.25 or Frame Relay. The links 211 may also be of different kinds, such as pairing dialup async links 212 with leased synchronous links. 213 214 We suggest that multilink operation can be modeled as a virtual PPP 215 link-layer entity wherein packets received over different physical 216 link-layer entities are identified as belonging to a separate PPP 217 network protocol (the Multilink Protocol, or MP) and recombined and 218 sequenced according to information present in a multilink 219 fragmentation header. All packets received over links identified as 220 belonging to the multilink arrangement are presented to the same 221 network-layer protocol processing machine, whether they have 222 multilink headers or not. 223 224 225 226Sklower, et. al. Standards Track [Page 4] 227 228RFC 1990 PPP Multilink August 1996 229 230 231 The packets to be transmitted using the multilink procedure are 232 encapsulated according to the rules for PPP where the following 233 options would have been manually configured: 234 235 o No async control character Map 236 o No Magic Number 237 o No Link Quality Monitoring 238 o Address and Control Field Compression 239 o Protocol Field Compression 240 o No Compound Frames 241 o No Self-Describing-Padding 242 243 According to the rules specified in RFC1661, this means that an 244 implementation MUST accept reassembled packets with and without 245 leading zeroes present in the Protocol Field of the reassembled 246 packet. Although it is explicitly forbidden below to include the 247 Address and Control fields (usually, the two bytes FF 03) in the 248 material to be fragmented, it is a good defensive programming 249 practice to accept the packet anyway, ignoring the two bytes if 250 present, as that is what RFC1661 specifies. 251 252 As a courtesy to implementations that perform better when certain 253 alignment obtains, it is suggested that a determination be made when 254 a bundle is created on whether to transmit leading zeroes by 255 examining whether PFC has been negotiated on the first link admitted 256 into a bundle. This determination should be kept in force so long as 257 a bundle persists. 258 259 Of course, individual links are permitted to have different settings 260 for these options. As described below, member links SHOULD negotiate 261 Self-Describing-Padding, even though pre-fragmented packets MUST NOT 262 be padded. Since the Protocol Field Compression mode on the member 263 link allows a sending system to include a leading byte of zero or not 264 at its discretion, this is an alternative mechanism for generating 265 even-length packets. 266 267 LCP negotiations are not permitted on the bundle itself. An 268 implementation MUST NOT transmit LCP Configure-Request, -Reject, 269 -Ack, -Nak, Terminate-Request or -Ack packets via the multilink 270 procedure, and an implementation receiving them MUST silently discard 271 them. (By "silently discard" we mean to not generate any PPP packets 272 in response; an implementation is free to generate a log entry 273 registering the reception of the unexpected packet). By contrast, 274 other LCP packets having control functions not associated with 275 changing the defaults for the bundle itself are permitted. An 276 implementation MAY transmit LCP Code-Reject, Protocol-Reject, Echo- 277 Request, Echo-Reply and Discard-Request Packets. 278 279 280 281 282Sklower, et. al. Standards Track [Page 5] 283 284RFC 1990 PPP Multilink August 1996 285 286 287 The effective MRU for the logical-link entity is negotiated via an 288 LCP option. It is irrelevant whether Network Control Protocol 289 packets are encapsulated in multilink headers or not, or even over 290 which link they are sent, once that link identifies itself as 291 belonging to a multilink arrangement. 292 293 Note that network protocols that are not sent using multilink headers 294 cannot be sequenced. (And consequently will be delivered in any 295 convenient way). 296 297 For example, consider the case in Figure 1. Link 1 has negotiated 298 network layers NL 1, NL 2, and MP between two systems. The two 299 systems then negotiate MP over Link 2. 300 301 Frames received on link 1 are demultiplexed at the data link layer 302 according the PPP network protocol identifier and can be sent to NL 303 1, NL 2, or MP. Link 2 will accept frames with all network protocol 304 identifiers that Link 1 does. 305 306 Frames received by MP are further demultiplexed at the network layer 307 according to the PPP network protocol identifier and sent to NL 1 or 308 NL 2. Any frames received by MP for any other network layer 309 protocols are rejected using the normal protocol reject mechanism. 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338Sklower, et. al. Standards Track [Page 6] 339 340RFC 1990 PPP Multilink August 1996 341 342 343 Figure 1. Multilink Overview. 344 345 Network Layer 346 ------------- 347 ______ ______ 348 / \ / \ 349 | NL 1 | | NL 2 | 350 \______/ \______/ 351 | | | | | | 352 | | +-------------o-o-o-+ 353 | +------+ +-----+ | | | 354 | | | | | | 355 | +------o--o-------+ + | 356 | | |__|_ | | 357 | | / \ | | 358 | | | MLCP | <--- Link Layer 359 | | \______/ Demultiplexing 360 | | | | | 361 | | | | | 362 | | | <--- Virtual Link 363 | | | | | 364 | | | | | 365 | | | | | 366 | | + | | 367 ___|_| | ___|_| 368 / \ | / \ 369 | LCP |------+-----| LCP | <--- Link Layer 370 \______/ \______/ Demultiplexing 371 | | 372 | | 373 Link 1 Link 2 374 3753. Packet Formats 376 377 In this section we describe the layout of individual fragments, which 378 are the "packets" in the Multilink Protocol. Network Protocol 379 packets are first encapsulated (but not framed) according to normal 380 PPP procedures, and large packets are broken up into multiple 381 segments sized appropriately for the multiple physical links. 382 Although it would otherwise be permitted by the PPP spec, 383 implementations MUST NOT include the Address and Control Field in the 384 logical entity to be fragmented. A new PPP header consisting of the 385 Multilink Protocol Identifier, and the Multilink header is inserted 386 before each section. (Thus the first fragment of a multilink packet 387 in PPP will have two headers, one for the fragment, followed by the 388 header for the packet itself). 389 390 391 392 393 394Sklower, et. al. Standards Track [Page 7] 395 396RFC 1990 PPP Multilink August 1996 397 398 399 Systems implementing the multilink procedure are not required to 400 fragment small packets. There is also no requirement that the 401 segments be of equal sizes, or that packets must be broken up at all. 402 A possible strategy for contending with member links of differing 403 transmission rates would be to divide the packets into segments 404 proportion to the transmission rates. Another strategy might be to 405 divide them into many equal fragments and distribute multiple 406 fragments per link, the numbers being proportional to the relative 407 speeds of the links. 408 409 PPP multilink fragments are encapsulated using the protocol 410 identifier 0x00-0x3d. Following the protocol identifier is a four 411 byte header containing a sequence number, and two one bit fields 412 indicating that the fragment begins a packet or terminates a packet. 413 After negotiation of an additional PPP LCP option, the four byte 414 header may be optionally replaced by a two byte header with only a 12 415 bit sequence space. Address & Control and Protocol ID compression 416 are assumed to be in effect. Individual fragments will, therefore, 417 have the following format: 418 419 Figure 2: Long Sequence Number Fragment Format. 420 421 422 +---------------+---------------+ 423 PPP Header: | Address 0xff | Control 0x03 | 424 +---------------+---------------+ 425 | PID(H) 0x00 | PID(L) 0x3d | 426 +-+-+-+-+-+-+-+-+---------------+ 427 MP Header: |B|E|0|0|0|0|0|0|sequence number| 428 +-+-+-+-+-+-+-+-+---------------+ 429 | sequence number (L) | 430 +---------------+---------------+ 431 | fragment data | 432 | . | 433 | . | 434 | . | 435 +---------------+---------------+ 436 PPP FCS: | FCS | 437 +---------------+---------------+ 438 439 440 441 442 443 444 445 446 447 448 449 450Sklower, et. al. Standards Track [Page 8] 451 452RFC 1990 PPP Multilink August 1996 453 454 455 Figure 3: Short Sequence Number Fragment Format. 456 457 458 +---------------+---------------+ 459 PPP Header: | Address 0xff | Control 0x03 | 460 +---------------+---------------+ 461 | PID(H) 0x00 | PID(L) 0x3d | 462 +-+-+-+-+-------+---------------+ 463 MP Header: |B|E|0|0| sequence number | 464 +-+-+-+-+-------+---------------+ 465 | fragment data | 466 | . | 467 | . | 468 | . | 469 +---------------+---------------+ 470 PPP FCS: | FCS | 471 +---------------+---------------+ 472 473 The (B)eginning fragment bit is a one bit field set to 1 on the first 474 fragment derived from a PPP packet and set to 0 for all other 475 fragments from the same PPP packet. 476 477 The (E)nding fragment bit is a one bit field set to 1 on the last 478 fragment and set to 0 for all other fragments. A fragment may have 479 both the (B)eginning and (E)nding fragment bits set to 1. 480 481 The sequence field is a 24 bit or 12 bit number that is incremented 482 for every fragment transmitted. By default, the sequence field is 24 483 bits long, but can be negotiated to be only 12 bits with an LCP 484 configuration option described below. 485 486 Between the (E)nding fragment bit and the sequence number is a 487 reserved field, whose use is not currently defined, which MUST be set 488 to zero. It is 2 bits long when the use of short sequence numbers 489 has been negotiated, 6 bits otherwise. 490 491 In this multilink protocol, a single reassembly structure is 492 associated with the bundle. The multilink headers are interpreted in 493 the context of this structure. 494 495 The FCS field shown in the diagram is inherited from the normal 496 framing mechanism from the member link on which the packet is 497 transmitted. There is no separate FCS applied to the reconstituted 498 packet as a whole if transmitted in more than one fragment. 499 500 501 502 503 504 505 506Sklower, et. al. Standards Track [Page 9] 507 508RFC 1990 PPP Multilink August 1996 509 510 5113.1. Padding Considerations 512 513 Systems that support the multilink protocol SHOULD implement Self- 514 Describing-Padding. A system that implements self-describing-padding 515 by definition will either include the padding option in its initial 516 LCP Configure-Requests, or (to avoid the delay of a Configure-Reject) 517 include the padding option after receiving a NAK containing the 518 option. 519 520 A system that must pad its own transmissions but does not use Self- 521 Describing-Padding when not using multilink, MAY continue to not use 522 Self-Describing-Padding if it ensures by careful choice of fragment 523 lengths that only (E)nding fragments of packets are padded. A system 524 MUST NOT add padding to any packet that cannot be recognized as 525 padded by the peer. Non-terminal fragments MUST NOT be padded with 526 trailing material by any other method than Self-Describing-Padding. 527 528 A system MUST ensure that Self-Describing-Padding as described in RFC 529 1570 [11] is negotiated on the individual link before transmitting 530 any multilink data packets if it might pad non-terminal fragments or 531 if it would use network or compression protocols that are vulnerable 532 to padding, as described in RFC 1570. If necessary, the system that 533 adds padding MUST use LCP Configure-NAK's to elicit a Configure- 534 Request for Self-Describing-Padding from the peer. 535 536 Note that LCP Configure-Requests can be sent at any time on any link, 537 and that the peer will always respond with a Configure-Request of its 538 own. A system that pads its transmissions but uses no protocols 539 other than multilink that are vulnerable to padding MAY delay 540 ensuring that the peer has Configure-Requested Self-Describing- 541 Padding until it seems desireable to negotiate the use of Multilink 542 itself. This permits the interoperability of a system that pads with 543 older peers that support neither Multilink nor Self-Describing- 544 Padding. 545 5464. Trading Buffer Space Against Fragment Loss 547 548 In a multilink procedure one channel may be delayed with respect to 549 the other channels in the bundle. This can lead to fragments being 550 received out of order, thus increasing the difficulty in detecting 551 the loss of a fragment. The task of estimating the amount of space 552 required for buffering on the receiver becomes more complex because 553 of this. In this section we discuss a technique for declaring that a 554 fragment is lost, with the intent of minimizing the buffer space 555 required, yet minimizing the number of avoidable packet losses. 556 557 558 559 560 561 562Sklower, et. al. Standards Track [Page 10] 563 564RFC 1990 PPP Multilink August 1996 565 566 5674.1. Detecting Fragment Loss 568 569 On each member link in a bundle, the sender MUST transmit fragments 570 with strictly increasing sequence numbers (modulo the size of the 571 sequence space). This requirement supports a strategy for the 572 receiver to detect lost fragments based on comparing sequence 573 numbers. The sequence number is not reset upon each new PPP packet, 574 and a sequence number is consumed even for those fragments which 575 contain an entire PPP packet, i.e., one in which both the (B)eginning 576 and (E)nding bits are set. 577 578 An implementation MUST set the sequence number of the first fragment 579 transmited on a newly-constructed bundle to zero. (Joining a 580 secondary link to an exisiting bundle is invisible to the protocol, 581 and an implementation MUST NOT reset the sequence number space in 582 this situation). 583 584 The receiver keeps track of the incoming sequence numbers on each 585 link in a bundle and maintains the current minimum of the most 586 recently received sequence number over all the member links in the 587 bundle (call this M). The receiver detects the end of a packet when 588 it receives a fragment bearing the (E)nding bit. Reassembly of the 589 packet is complete if all sequence numbers up to that fragment have 590 been received. 591 592 A lost fragment is detected when M advances past the sequence number 593 of a fragment bearing an (E)nding bit of a packet which has not been 594 completely reassembled (i.e., not all the sequence numbers between 595 the fragment bearing the (B)eginning bit and the fragment bearing the 596 (E)nding bit have been received). This is because of the increasing 597 sequence number rule over the bundle. Any sequence number so 598 detected is assumed to correspond to a fragment which has been lost. 599 600 An implementation MUST assume that if a fragment bears a (B)eginning 601 bit, that the previously numbered fragment bore an (E)nding bit. 602 Thus if a packet is lost bearing the (E)nding bit, and the packet 603 whose fragment number is M contains a (B)eginning bit, the 604 implementation MUST discard fragments for all unassembled packets 605 through M-1, but SHOULD NOT discard the fragment bearing the new 606 (B)eginning bit on this basis alone. 607 608 The detection of a lost fragment, whose sequence number was deduced 609 to be U, causes the receiver to discard all fragments up to the 610 lowest numbered fragment with an ending bit (possibly deduced) 611 greater than or equal to U. However, the quantity M may jump into 612 the middle of a chain of packets which can be successful completed. 613 614 615 616 617 618Sklower, et. al. Standards Track [Page 11] 619 620RFC 1990 PPP Multilink August 1996 621 622 623 Fragments may be lost due to corruption of individual packets or 624 catastrophic loss of the link (which may occur only in one 625 direction). This version of the multilink protocol mandates no 626 specific procedures for the detection of failed links. The PPP link 627 quality management facility, or the periodic issuance of LCP echo- 628 requests could be used to achieve this. 629 630 Senders SHOULD avoid keeping any member links idle to maximize early 631 detection of lost fragments by the receiver, since the value of M is 632 not incremented on idle links. Senders SHOULD rotate traffic among 633 the member links if there isn't sufficient traffic to overflow the 634 capacity of one link to avoid idle links. 635 636 Loss of the final fragment of a transmission can cause the receiver 637 to stall until new packets arrive. The likelihood of this may be 638 decreased by sending a null fragment on each member link in a bundle 639 that would otherwise become idle immediately after having transmitted 640 a fragment bearing the (E)nding bit, where a null fragment is one 641 consisting only of a multilink header bearing both the (B)egin and 642 (E)nding bits (i.e., having no payload). Implementations concerned 643 about either wasting bandwidth or per packet costs are not required 644 to send null fragments and may elect to defer sending them until a 645 timer expires, with the marginally increased possibility of lengthier 646 stalls in the receiver. The receiver SHOULD implement some type of 647 link idle timer to guard against indefinite stalls. 648 649 The increasing sequence per link rule prohibits the reallocation of 650 fragments queued up behind a failing link to a working one, a 651 practice which is not unusual for implementations of ISO multilink 652 over LAPB [4]. 653 6544.2. Buffer Space Requirements 655 656 There is no amount of buffering that will guarantee correct detection 657 of fragment loss, since an adversarial peer may withhold a fragment 658 on one channel and send arbitrary amounts on the others. For the 659 usual case where all channels are transmitting, you can show that 660 there is a minimum amount below which you could not correctly detect 661 packet loss. The amount depends on the relative delay between the 662 channels, (D[channel-i,channel-j]), the data rate of each channel, 663 R[c], the maximum fragment size permitted on each channel, F[c], and 664 the total amount of buffering the transmitter has allocated amongst 665 the channels. 666 667 When using PPP, the delay between channels could be estimated by 668 using LCP echo request and echo reply packets. (In the case of links 669 of different transmission rates, the round trip times should be 670 adjusted to take this into account.) The slippage for each channel 671 672 673 674Sklower, et. al. Standards Track [Page 12] 675 676RFC 1990 PPP Multilink August 1996 677 678 679 is defined as the bandwidth times the delay for that channel relative 680 to the channel with the longest delay, S[c] = R[c] * D[c,c-worst]. 681 (S[c-worst] will be zero, of course!) 682 683 A situation which would exacerbate sequence number skew would be one 684 in which there is extremely bursty traffic (almost allowing all 685 channels to drain), and then where the transmitter would first queue 686 up as many consecutively numbered packets on one link as it could, 687 then queue up the next batch on a second link, and so on. Since 688 transmitters must be able to buffer at least a maximum- sized 689 fragment for each link (and will usually buffer up at least two) A 690 receiver that allocates any less than S[1] + S[2] + ... + S[N] + F[1] 691 + ... + F[N], will be at risk for incorrectly assuming packet loss, 692 and therefore, SHOULD allocate at least twice that. 693 6945. PPP Link Control Protocol Extensions 695 696 If reliable multilink operation is desired, PPP Reliable Transmission 697 [6] (essentially the use of ISO LAPB) MUST be negotiated prior to the 698 use of the Multilink Protocol on each member link. 699 700 Whether or not reliable delivery is employed over member links, an 701 implementation MUST present a signal to the NCP's running over the 702 multilink arrangement that a loss has occurred. 703 704 Compression may be used separately on each member link, or run over 705 the bundle (as a logical group link). The use of multiple 706 compression streams under the bundle (i.e., on each link separately) 707 is indicated by running the Compression Control Protocol [5] but with 708 an alternative PPP protocol ID. 709 7105.1. Configuration Option Types 711 712 The Multilink Protocol introduces the use of additional LCP 713 Configuration Options: 714 715 o Multilink Maximum Received Reconstructed Unit 716 o Multilink Short Sequence Number Header Format 717 o Endpoint Discriminator 718 719 720 721 722 723 724 725 726 727 728 729 730Sklower, et. al. Standards Track [Page 13] 731 732RFC 1990 PPP Multilink August 1996 733 734 7355.1.1. Multilink MRRU LCP option 736 737 Figure 4: Multilink MRRU LCP option 738 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Type = 17 | Length = 4 | Max-Receive-Reconstructed-Unit| 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 745 The presence of this LCP option indicates that the system sending it 746 implements the PPP Multilink Protocol. If not rejected, the system 747 will construe all packets received on this link as being able to be 748 processed by a common protocol machine with any other packets 749 received from the same peer on any other link on which this option 750 has been accepted. 751 752 The Max-Receive-Reconstructed unit field is two octets, and specifies 753 the maximum number of octets in the Information fields of reassembled 754 packets. A system MUST be able to receive the full 1500 octet 755 Information field of any reassembled PPP packet although it MAY 756 attempt to negotiate a smaller, or larger value. The number 1500 757 here comes from the specification for the MRU LCP option in PPP; if 758 this requirement is changed in a future version of RFC 1661, the same 759 rules will apply here. 760 761 A system MUST include the LCP MRRU option in every LCP negotiation 762 intended to instantiate a bundle or to join an existing bundle. If 763 the LCP MRRU option is offered on a link which is intended to join an 764 existing bundle, a system MUST offer the same Max-Receive- 765 Reconstruct-Unit value previously negotiated for the bundle. 766 767 A system MUST NOT send any multilink packets on any link unless its 768 peer has offered the MMRU LCP option and the system has configure- 769 Ack'ed it during the most recent LCP negotiation on that link. A 770 system MAY include the MMRU LCP option in a configure-NAK, if its 771 peer has not offered it (until, according to PPP rules, the peer 772 configure-Reject's it). 773 774 Note: the MRRU value conveyed im this option corresponds to the MRU 775 of the bundle when conceptualized as a PPP entity; but the rules for 776 the Multilink MRRU option are different from the LCP MRU option, as 777 some value MUST be offered in every LCP negotiation, and that 778 confirmation of this option is required prior to multilink 779 interpretation. 780 781 782 783 784 785 786Sklower, et. al. Standards Track [Page 14] 787 788RFC 1990 PPP Multilink August 1996 789 790 7915.1.2. Short Sequence Number Header Format Option 792 793 Figure 5: Short Sequence Number Header Format Option 794 795 0 1 796 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Type = 18 | Length = 2 | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 801 This option advises the peer that the implementation wishes to 802 receive fragments with short, 12 bit sequence numbers. When a peer 803 system configure-Ack's this option, it MUST transmit all multilink 804 packets on all links of the bundle with 12 bit sequence numbers or 805 configure-Reject the option. If 12 bit sequence numbers are desired, 806 this option MUST be negotiated when the bundle is instantiated, and 807 MUST be explicitly included in every LCP configure request offered by 808 a system when the system intends to include that link in an existing 809 bundle using 12 bit sequence numbers. If this option is never 810 negotiated during the life of a bundle, sequence numbers are 24 bits 811 long. 812 813 An implementation wishing to transmit multilink fragments with short 814 sequence numbers MAY include the multilink short sequence number in a 815 configure-NAK to ask that the peer respond with a request to receive 816 short sequence numbers. The peer is not compelled to respond with 817 the option. 818 8195.1.3. Endpoint Discriminator Option 820 821 Figure 7: Endpoint Discriminator Option 822 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Type = 19 | Length | Class | Address ... 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 829 The Endpoint Discriminator Option represents identification of the 830 system transmitting the packet. This option advises a system that 831 the peer on this link could be the same as the peer on another 832 existing link. If the option distinguishes this peer from all 833 others, a new bundle MUST be established from the link being 834 negotiated. If this option matches the class and address of some 835 other peer of an existing link, the new link MUST be joined to the 836 bundle containing the link to the matching peer or MUST establish a 837 new bundle, depending on the decision tree shown in (1) through (4) 838 below. 839 840 841 842Sklower, et. al. Standards Track [Page 15] 843 844RFC 1990 PPP Multilink August 1996 845 846 847 To securely join an existing bundle, a PPP authentication protocol 848 [3] must be used to obtain authenticated information from the peer to 849 prevent a hostile peer from joining an existing bundle by presenting 850 a falsified discriminator option. 851 852 This option is not required for multilink operation. If a system 853 does not receive the Multilink MRRU option, but does receive the 854 Endpoint Discriminator Option, and there is no manual configuration 855 providing outside information, the implementation MUST NOT assume 856 that multilink operation is being requested on this basis alone. 857 858 As there is also no requirement for authentication, there are four 859 sets of scenarios: 860 861 (1) No authentication, no discriminator: 862 All new links MUST be joined to one bundle, unless 863 there is manual configuration to the contrary. 864 It is also permissible to have more than one manually 865 configured bundle connecting two given systems. 866 867 (2) Discriminator, no authentication: 868 Discriminator match -> MUST join matching bundle, 869 discriminator mismatch -> MUST establish new bundle. 870 871 (3) No discriminator, authentication: 872 Authenticated match -> MUST join matching bundle, 873 authenticated mismatch -> MUST establish new bundle. 874 875 (4) Discriminator, authentication: 876 Discriminator match and authenticated match -> MUST join bundle, 877 discriminator mismatch -> MUST establish new bundle, 878 authenticated mismatch -> MUST establish new bundle. 879 880 The option contains a Class which selects an identifier address space 881 and an Address which selects a unique identifier within the class 882 address space. 883 884 This identifier is expected to refer to the mechanical equipment 885 associated with the transmitting system. For some classes, 886 uniqueness of the identifier is global and is not bounded by the 887 scope of a particular administrative domain. Within each class, 888 uniqueness of address values is controlled by a class dependent 889 policy for assigning values. 890 891 Each endpoint may chose an identifier class without restriction. 892 Since the objective is to detect mismatches between endpoints 893 erroneously assumed to be alike, mismatch on class alone is 894 sufficient. Although no one class is recommended, classes which have 895 896 897 898Sklower, et. al. Standards Track [Page 16] 899 900RFC 1990 PPP Multilink August 1996 901 902 903 universally unique values are preferred. 904 905 This option is not required to be supported either by the system or 906 the peer. If the option is not present in a Configure-Request, the 907 system MUST NOT generate a Configure-Nak of this option for any 908 reason; instead it SHOULD behave as if it had received the option 909 with Class = 0, Address = 0. If a system receives a Configure-Nak or 910 Configure-Reject of this option, it MUST remove it from any 911 additional Configure-Request. 912 913 The size is determined from the Length field of the element. For 914 some classes, the length is fixed, for others the length is variable. 915 The option is invalid if the Length field indicates a size below the 916 minimum for the class. 917 918 An implementation MAY use the Endpoint Discriminator to locate 919 administration or authentication records in a local database. Such 920 use of this option is incidental to its purpose and is deprecated 921 when a PPP Authentication protocol [3] can be used instead. Since 922 some classes permit the peer to generate random or locally assigned 923 address values, use of this option as a database key requires prior 924 agreement between peer administrators. 925 926 The specification of the subfields are: 927 928 Type 929 19 = for Endpoint Discriminator 930 931 Length 932 3 + length of Address 933 934 Class 935 The Class field is one octet and indicates the identifier 936 address space. The most up-to-date values of the LCP Endpoint 937 Discriminator Class field are specified in the most recent 938 "Assigned Numbers" RFC [7]. Current values are assigned as 939 follows: 940 941 0 Null Class 942 943 1 Locally Assigned Address 944 945 2 Internet Protocol (IP) Address 946 947 3 IEEE 802.1 Globally Assigned MAC Address 948 949 4 PPP Magic-Number Block 950 951 952 953 954Sklower, et. al. Standards Track [Page 17] 955 956RFC 1990 PPP Multilink August 1996 957 958 959 5 Public Switched Network Directory Number 960 961 Address 962 The Address field is one or more octets and indicates the 963 identifier address within the selected class. The length and 964 content depend on the value of the Class as follows: 965 966 Class 0 - Null Class 967 968 Maximum Length: 0 969 970 Content: 971 This class is the default value if the option is not 972 present in a received Configure-Request. 973 974 Class 1 - Locally Assigned Address 975 976 Maximum Length: 20 977 978 Content: 979 980 This class is defined to permit a local assignment in the 981 case where use of one of the globally unique classes is not 982 possible. Use of a device serial number is suggested. The 983 use of this class is deprecated since uniqueness is not 984 guaranteed. 985 986 Class 2 - Internet Protocol (IP) Address 987 988 Fixed Length: 4 989 990 Content: 991 992 An address in this class contains an IP host address as 993 defined in [8]. 994 995 Class 3 - IEEE 802.1 Globally Assigned MAC Address 996 997 Fixed Length: 6 998 999 Content: 1000 1001 An address in this class contains an IEEE 802.1 MAC address 1002 in canonical (802.3) format [9]. The address MUST have the 1003 global/local assignment bit clear and MUST have the 1004 multicast/specific bit clear. Locally assigned MAC 1005 addresses should be represented using Class 1. 1006 1007 1008 1009 1010Sklower, et. al. Standards Track [Page 18] 1011 1012RFC 1990 PPP Multilink August 1996 1013 1014 1015 Class 4 - PPP Magic-Number Block 1016 1017 Maximum Length: 20 1018 1019 Content: 1020 1021 This is not an address but a block of 1 to 5 concatenated 1022 32 bit PPP Magic-Numbers as defined in [2]. This class 1023 provides for automatic generation of a value likely but not 1024 guaranteed to be unique. The same block MUST be used by an 1025 endpoint continuously during any period in which at least 1026 one link is in the LCP Open state. The use of this class 1027 is deprecated. 1028 1029 Note that PPP Magic-Numbers are used in [2] to detect 1030 unexpected loopbacks of a link from an endpoint to itself. 1031 There is a small probability that two distinct endpoints 1032 will generate matching magic-numbers. This probability is 1033 geometrically reduced when the LCP negotiation is repeated 1034 in search of the desired mismatch, if a peer can generate 1035 uncorrelated magic-numbers. 1036 1037 As used here, magic-numbers are used to determine if two 1038 links are in fact from the same peer endpoint or from two 1039 distinct endpoints. The numbers always match when there is 1040 one endpoint. There is a small probability that the 1041 numbers will match even if there are two endpoints. To 1042 achieve the same confidence that there is not a false match 1043 as for LCP loopback detection, several uncorrelated magic- 1044 numbers can be combined in one block. 1045 1046 Class 5 - Public Switched Network Directory Number 1047 1048 Maximum Length: 15 1049 1050 Content: 1051 1052 An address in this class contains an octet sequence as 1053 defined by I.331 (E.164) representing an international 1054 telephone directory number suitable for use to access the 1055 endpoint via the public switched telephone network [10]. 1056 10576. Initiating use of Multilink Headers 1058 1059 When the use of the Multilink protocol has been negotiated on a link 1060 (say Y), and the link is being added to a bundle which currently 1061 contains a single existing link (say X), a system MUST transmit a 1062 Multilink-encapsulated packet on X before transmitting any Multilink- 1063 1064 1065 1066Sklower, et. al. Standards Track [Page 19] 1067 1068RFC 1990 PPP Multilink August 1996 1069 1070 1071 encapsulated packets on Y. 1072 1073 Since links may be added and removed from a bundle without destroying 1074 the state associated with it, the fragment should be assigned the 1075 appropriate (next) fragment number. As noted earlier, the first 1076 fragment transmitted in the life of a bundle is assigned fragment 1077 number 0. 1078 10797. Closing Member links 1080 1081 Member links may be terminated according to normal PPP LCP procedures 1082 using LCP Terminate-Request and Terminate-Ack packets on that member 1083 link. Since it is assumed that member links usually do not reorder 1084 packets, receipt of a terminate ack is sufficient to assume that any 1085 multilink protocol packets ahead of it are at no special risk of 1086 loss. 1087 1088 Receipt of an LCP Terminate-Request on one link does not conclude the 1089 procedure on the remaining links. 1090 1091 So long as any member links in the bundle are active, the PPP state 1092 for the bundle persists as a separate entity. However, if the there 1093 is a unique link in the bundle, and all the other links were closed 1094 gracefully (with Terminate-Ack), an implementation MAY cease using 1095 multilink 1096 headers. 1097 1098 If the multilink procedure is used in conjunction with PPP reliable 1099 transmission, and a member link is not closed gracefully, the 1100 implementation should expect to receive packets which violate the 1101 increasing sequence number rule. 1102 11038. Interaction with Other Protocols 1104 1105 In the common case, LCP, and the Authentication Control Protocol 1106 would be negotiated over each member link. The Network Protocols 1107 themselves and associated control exchanges would normally have been 1108 conducted once, on the bundle. 1109 1110 In some instances it may be desirable for some Network Protocols to 1111 be exempted from sequencing requirements, and if the MRU sizes of the 1112 link did not cause fragmentation, those protocols could be sent 1113 directly over the member links. 1114 1115 Although explicitly discouraged above, if there were several member 1116 links connecting two implementations, and independent sequencing of 1117 two protocol sets were desired, but blocking of one by the other was 1118 not, one could describe two multilink procedures by assigning 1119 1120 1121 1122Sklower, et. al. Standards Track [Page 20] 1123 1124RFC 1990 PPP Multilink August 1996 1125 1126 1127 multiple endpoint identifiers to a given system. Each member link, 1128 however, would only belong to one bundle. One could think of a 1129 physical router as housing two logically separate implementations, 1130 each of which is independently configured. 1131 1132 A simpler solution would be to have one link refuse to join the 1133 bundle, by sending a Configure-Reject in response to the Multilink 1134 LCP option. 1135 11369. Security Considerations 1137 1138 Operation of this protocol is no more and no less secure than 1139 operation of the PPP authentication protocols [3]. The reader is 1140 directed there for further discussion. 1141 114210. References 1143 1144 [1] Leifer, D., Sheldon, S., and B. Gorsline, "A Subnetwork Control 1145 Protocol for ISDN Circuit-Switching", University of Michigan 1146 (unpublished), March 1991. 1147 1148 [2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, 1149 RFC 1661, Daydreamer, July 1994. 1150 1151 [3] Lloyd, B., and W. Simpson, "PPP Authentication Protocols", RFC 1152 1334, Lloyd Internetworking, Daydreamer, October 1992. 1153 1154 [4] International Organisation for Standardization, "HDLC - 1155 Description of the X.25 LAPB-Compatible DTE Data Link 1156 Procedures", International Standard 7776, 1988 1157 1158 [5] Rand, D., "The PPP Compression Control Protocol (CCP)", PPP 1159 Extensions Working Group, RFC 1962, June 1996. 1160 1161 [6] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 1162 1994 1163 1164 [7] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1165 USC/Information Sciences Institute, October 1994. 1166 1167 [8] Postel, J., Editor, "Internet Protocol - DARPA Internet Program 1168 Protocol Specification", STD 5, RFC 791, USC/Information Sciences 1169 Institute, September 1981. 1170 1171 [9] Institute of Electrical and Electronics Engineers, Inc., "IEEE 1172 Local and Metropolitan Area Networks: Overview and Architecture", 1173 IEEE Std. 802-1990, 1990. 1174 1175 1176 1177 1178Sklower, et. al. Standards Track [Page 21] 1179 1180RFC 1990 PPP Multilink August 1996 1181 1182 1183 [10] The International Telegraph and Telephone Consultative Committee 1184 (CCITT), "Numbering Plan for the ISDN Area", Recommendation I.331 1185 (E.164), 1988. 1186 1187 [11] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer, 1188 January 1994. 1189 119011. Differences from RFC 1717 1191 1192 This section documents differences from RFC 1717. There are 1193 restrictions placed on implementations that were absent in RFC 1717; 1194 systems obeying these restrictions are fully interoperable with RFC 1195 1717 - compliant systems. 1196 119711.1. Negotiating Multilink, per se 1198 1199 RFC 1717 permitted either the use of the Short Sequence Number Header 1200 Format (SSNHF) or the Maximum Reconstructed Receive Unit (MRRU) 1201 options by themselves to indicate the intent to negotiate multilink. 1202 This specification forbids the use of the SSNHF option by itself; but 1203 does permit the specific of both options together. Any 1204 implementation which otherwise conforms to rfc1717 and also obeys 1205 this restriction will interoperate with any RFC 1717 implementation. 1206 120711.2. Initial Sequence Number defined 1208 1209 This specification requires that the first sequence number 1210 transmitted after the virtual link has reached to open state be 0. 1211 121211.3. Default Value of the MRRU 1213 1214 This specfication removes the default value for the MRRU, (since it 1215 must always be negotiated with some value), and specifies that an 1216 implementation must be support an MRRU with same value as the default 1217 MRU size for PPP. 1218 121911.4. Config-Nak of EID prohibited 1220 1221 This specification forbids the config-Naking of an EID for any 1222 reason. 1223 122411.5. Uniformity of Sequence Space 1225 1226 This specification requires that the same sequence format be employed 1227 on all links in a bundle. 1228 1229 1230 1231 1232 1233 1234Sklower, et. al. Standards Track [Page 22] 1235 1236RFC 1990 PPP Multilink August 1996 1237 1238 123911.6. Commencing and Abating use of Multilink Headers 1240 1241 This memo specifies how one should start the use of Multilink Headers 1242 when a link is added, and under what circumstances it is safe to 1243 discontinue their use. 1244 124511.7. Manual Configuration and Bundle Assignment 1246 1247 The document explicitly permits multiple bundles to be manually 1248 configured in the absence of both the Endpoint Descriminator and any 1249 form of authentication. 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290Sklower, et. al. Standards Track [Page 23] 1291 1292RFC 1990 PPP Multilink August 1996 1293 1294 129513. Authors' Addresses 1296 1297 Keith Sklower 1298 Computer Science Department 1299 384 Soda Hall, Mail Stop 1776 1300 University of California 1301 Berkeley, CA 94720-1776 1302 1303 Phone: (510) 642-9587 1304 EMail: sklower@CS.Berkeley.EDU 1305 1306 1307 Brian Lloyd 1308 Lloyd Internetworking 1309 3031 Alhambra Drive 1310 Cameron Park, CA 95682 1311 1312 Phone: (916) 676-1147 1313 EMail: brian@lloyd.com 1314 1315 1316 Glenn McGregor 1317 Lloyd Internetworking 1318 3031 Alhambra Drive 1319 Cameron Park, CA 95682 1320 1321 Phone: (916) 676-1147 1322 EMail: glenn@lloyd.com 1323 1324 1325 Dave Carr 1326 Newbridge Networks Corporation 1327 600 March Road 1328 P.O. Box 13600 1329 Kanata, Ontario, 1330 Canada, K2K 2E6 1331 1332 Phone: (613) 591-3600 1333 EMail: dcarr@Newbridge.COM 1334 1335 1336 Tom Coradetti 1337 Sidewalk Software 1338 1190 Josephine Road 1339 Roseville, MN 55113 1340 1341 Phone: (612) 490 7856 1342 EMail: 70761.1664@compuserve.com 1343 1344 1345 1346Sklower, et. al. Standards Track [Page 24] 1347 1348