diff options
Diffstat (limited to 'doc/rfc1990.txt')
| -rw-r--r-- | doc/rfc1990.txt | 1347 |
1 files changed, 0 insertions, 1347 deletions
diff --git a/doc/rfc1990.txt b/doc/rfc1990.txt deleted file mode 100644 index a4f7ffef..00000000 --- a/doc/rfc1990.txt +++ /dev/null @@ -1,1347 +0,0 @@ - - - - - - -Network Working Group K. Sklower -Request for Comments: 1990 University of California, Berkeley -Obsoletes: 1717 B. Lloyd -Category: Standards Track G. McGregor - Lloyd Internetworking - D. Carr - Newbridge Networks Corporation - T. Coradetti - Sidewalk Software - August 1996 - - - 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. - - The differences between the current PPP Multilink specification (RFC - 1717) and this memo are explained in Section 11. Any system - implementing the additional restrictions required by this memo will - be backwards compatible with conforming RFC 1717 implementations. - -Acknowledgements - - The authors specifically wish to thank Fred Baker of ACC, Craig Fox - of Network Systems, Gerry Meyer of Spider Systems, 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. - - - - - - -Sklower, et. al. Standards Track [Page 1] - -RFC 1990 PPP Multilink August 1996 - - -Table of Contents - - 1. Introduction ................................................ 2 - 1.1. Motivation ................................................ 2 - 1.2. Functional Description .................................... 3 - 1.3. Conventions ............................................... 4 - 2. General Overview ............................................ 4 - 3. Packet Formats .............................................. 7 - 3.1. Padding Considerations .................................... 10 - 4. Trading Buffer Space Against Fragment Loss .................. 10 - 4.1. Detecting Fragment Loss ................................... 11 - 4.2. Buffer Space Requirements ................................. 12 - 5. PPP Link Control Protocol Extensions ........................ 13 - 5.1. Configuration Option Types ................................ 13 - 5.1.1. Multilink MRRU LCP option ............................... 14 - 5.1.2. Short Sequence Number Header Format Option .............. 15 - 5.1.3. Endpoint Discriminator Option ........................... 15 - 6. Initiating use of Multilink Headers ......................... 19 - 7. Closing Member links ........................................ 20 - 8. Interaction with Other Protocols ............................ 20 - 9. Security Considerations ..................................... 21 - 10. References ................................................. 21 - 11. Differences from RFC 1717 .................................. 22 - 11.1. Negotiating Multilink, per se ............................ 22 - 11.2. Initial Sequence Number defined .......................... 22 - 11.3. Default Value of the MRRU ................................ 22 - 11.4. Config-Nak of EID prohibited ............................. 22 - 11.5. Uniformity of Sequence Space ............................. 22 - 11.6. Commencing and Abating use of Multilink Headers .......... 23 - 11.7. Manual Configuration and Bundle Assignment ............... 23 - 12. Authors' Addresses ......................................... 24 - -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. - - - -Sklower, et. al. Standards Track [Page 2] - -RFC 1990 PPP Multilink August 1996 - - - 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. - -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. - - - - - -Sklower, et. al. Standards Track [Page 3] - -RFC 1990 PPP Multilink August 1996 - - - 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. - - 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. - - - -Sklower, et. al. Standards Track [Page 4] - -RFC 1990 PPP Multilink August 1996 - - - 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 - - According to the rules specified in RFC1661, this means that an - implementation MUST accept reassembled packets with and without - leading zeroes present in the Protocol Field of the reassembled - packet. Although it is explicitly forbidden below to include the - Address and Control fields (usually, the two bytes FF 03) in the - material to be fragmented, it is a good defensive programming - practice to accept the packet anyway, ignoring the two bytes if - present, as that is what RFC1661 specifies. - - As a courtesy to implementations that perform better when certain - alignment obtains, it is suggested that a determination be made when - a bundle is created on whether to transmit leading zeroes by - examining whether PFC has been negotiated on the first link admitted - into a bundle. This determination should be kept in force so long as - a bundle persists. - - 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. Since the Protocol Field Compression mode on the member - link allows a sending system to include a leading byte of zero or not - at its discretion, this is an alternative mechanism for generating - even-length packets. - - 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. - - - - -Sklower, et. al. Standards Track [Page 5] - -RFC 1990 PPP Multilink August 1996 - - - 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, et. al. Standards Track [Page 6] - -RFC 1990 PPP Multilink August 1996 - - - 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. - Although it would otherwise be permitted by the PPP spec, - implementations MUST NOT include the Address and Control Field in the - logical entity to be fragmented. 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, et. al. Standards Track [Page 7] - -RFC 1990 PPP Multilink August 1996 - - - 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, et. al. Standards Track [Page 8] - -RFC 1990 PPP Multilink August 1996 - - - 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, et. al. Standards Track [Page 9] - -RFC 1990 PPP Multilink August 1996 - - -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, et. al. Standards Track [Page 10] - -RFC 1990 PPP Multilink August 1996 - - -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. Any sequence number so - detected is assumed to correspond to a fragment which has been lost. - - 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, whose sequence number was deduced - to be U, causes the receiver to discard all fragments up to the - lowest numbered fragment with an ending bit (possibly deduced) - greater than or equal to U. However, the quantity M may jump into - the middle of a chain of packets which can be successful completed. - - - - - -Sklower, et. al. Standards Track [Page 11] - -RFC 1990 PPP Multilink August 1996 - - - 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, et. al. Standards Track [Page 12] - -RFC 1990 PPP Multilink August 1996 - - - 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, et. al. Standards Track [Page 13] - -RFC 1990 PPP Multilink August 1996 - - -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 LCP option indicates that the system sending it - implements the PPP Multilink Protocol. If not rejected, the system - will construe all packets received 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. - - The Max-Receive-Reconstructed unit field is two octets, and specifies - the maximum number of octets in the Information fields of reassembled - packets. A system MUST be able to receive the full 1500 octet - Information field of any reassembled PPP packet although it MAY - attempt to negotiate a smaller, or larger value. The number 1500 - here comes from the specification for the MRU LCP option in PPP; if - this requirement is changed in a future version of RFC 1661, the same - rules will apply here. - - A system MUST include the LCP MRRU option in every LCP negotiation - intended to instantiate a bundle or to join an existing bundle. If - the LCP MRRU option is offered on a link which is intended to join an - existing bundle, a system MUST offer the same Max-Receive- - Reconstruct-Unit value previously negotiated for the bundle. - - A system MUST NOT send any multilink packets on any link unless its - peer has offered the MMRU LCP option and the system has configure- - Ack'ed it during the most recent LCP negotiation on that link. A - system MAY include the MMRU LCP option in a configure-NAK, if its - peer has not offered it (until, according to PPP rules, the peer - configure-Reject's it). - - Note: the MRRU value conveyed im this option corresponds to the MRU - of the bundle when conceptualized as a PPP entity; but the rules for - the Multilink MRRU option are different from the LCP MRU option, as - some value MUST be offered in every LCP negotiation, and that - confirmation of this option is required prior to multilink - interpretation. - - - - - - -Sklower, et. al. Standards Track [Page 14] - -RFC 1990 PPP Multilink August 1996 - - -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. When a peer - system configure-Ack's this option, it MUST transmit all multilink - packets on all links of the bundle with 12 bit sequence numbers or - configure-Reject the option. If 12 bit sequence numbers are desired, - this option MUST be negotiated when the bundle is instantiated, and - MUST be explicitly included in every LCP configure request offered by - a system when the system intends to include that link in an existing - bundle using 12 bit sequence numbers. If this option is never - negotiated during the life of a bundle, sequence numbers are 24 bits - long. - - 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. - - - -Sklower, et. al. Standards Track [Page 15] - -RFC 1990 PPP Multilink August 1996 - - - 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 the Multilink MRRU option, 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, unless - there is manual configuration to the contrary. - It is also permissible to have more than one manually - configured bundle connecting two given systems. - - (2) Discriminator, no authentication: - Discriminator match -> MUST join matching bundle, - discriminator mismatch -> MUST establish new bundle. - - (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 - - - -Sklower, et. al. Standards Track [Page 16] - -RFC 1990 PPP Multilink August 1996 - - - 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 for any - reason; 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. - - 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 - - - - -Sklower, et. al. Standards Track [Page 17] - -RFC 1990 PPP Multilink August 1996 - - - 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. - - 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. - - - - -Sklower, et. al. Standards Track [Page 18] - -RFC 1990 PPP Multilink August 1996 - - - 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. - - 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. Initiating use of Multilink Headers - - When the use of the Multilink protocol has been negotiated on a link - (say Y), and the link is being added to a bundle which currently - contains a single existing link (say X), a system MUST transmit a - Multilink-encapsulated packet on X before transmitting any Multilink- - - - -Sklower, et. al. Standards Track [Page 19] - -RFC 1990 PPP Multilink August 1996 - - - encapsulated packets on Y. - - Since links may be added and removed from a bundle without destroying - the state associated with it, the fragment should be assigned the - appropriate (next) fragment number. As noted earlier, the first - fragment transmitted in the life of a bundle is assigned fragment - number 0. - -7. 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. However, if the there - is a unique link in the bundle, and all the other links were closed - gracefully (with Terminate-Ack), an implementation MAY cease using - multilink - headers. - - 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. - -8. 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 - - - -Sklower, et. al. Standards Track [Page 20] - -RFC 1990 PPP Multilink August 1996 - - - 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. - -9. 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. - -10. 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, RFC 1962, June 1996. - - [6] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July - 1994 - - [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. - - - - -Sklower, et. al. Standards Track [Page 21] - -RFC 1990 PPP Multilink August 1996 - - - [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. - -11. Differences from RFC 1717 - - This section documents differences from RFC 1717. There are - restrictions placed on implementations that were absent in RFC 1717; - systems obeying these restrictions are fully interoperable with RFC - 1717 - compliant systems. - -11.1. Negotiating Multilink, per se - - RFC 1717 permitted either the use of the Short Sequence Number Header - Format (SSNHF) or the Maximum Reconstructed Receive Unit (MRRU) - options by themselves to indicate the intent to negotiate multilink. - This specification forbids the use of the SSNHF option by itself; but - does permit the specific of both options together. Any - implementation which otherwise conforms to rfc1717 and also obeys - this restriction will interoperate with any RFC 1717 implementation. - -11.2. Initial Sequence Number defined - - This specification requires that the first sequence number - transmitted after the virtual link has reached to open state be 0. - -11.3. Default Value of the MRRU - - This specfication removes the default value for the MRRU, (since it - must always be negotiated with some value), and specifies that an - implementation must be support an MRRU with same value as the default - MRU size for PPP. - -11.4. Config-Nak of EID prohibited - - This specification forbids the config-Naking of an EID for any - reason. - -11.5. Uniformity of Sequence Space - - This specification requires that the same sequence format be employed - on all links in a bundle. - - - - - - -Sklower, et. al. Standards Track [Page 22] - -RFC 1990 PPP Multilink August 1996 - - -11.6. Commencing and Abating use of Multilink Headers - - This memo specifies how one should start the use of Multilink Headers - when a link is added, and under what circumstances it is safe to - discontinue their use. - -11.7. Manual Configuration and Bundle Assignment - - The document explicitly permits multiple bundles to be manually - configured in the absence of both the Endpoint Descriminator and any - form of authentication. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Sklower, et. al. Standards Track [Page 23] - -RFC 1990 PPP Multilink August 1996 - - -13. 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 - - - Tom Coradetti - Sidewalk Software - 1190 Josephine Road - Roseville, MN 55113 - - Phone: (612) 490 7856 - EMail: 70761.1664@compuserve.com - - - -Sklower, et. al. Standards Track [Page 24] - |