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