Network Working Group Shakeel Mustafa INTERNET-DRAFT Technological Concepts Inc. [Request for Comments:XXXX] March 24 2003 [Target Category: Standards Track] An Enhanced Multi-Link PPP with low overhead suitable for multiple scalable bandwidth links Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsolete by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.txt Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Status of this Memo Abstract This document proposes a new architecture for providing an enhanced way of fragmenting PPP protocol frames which is self-scalable to operate over a wide range of multiple links ranging from low-bitrate, sub-T1 line to very high speed SDH hierarchy. The scheme provides a relatively low overhead for fragmentation procedure and can scale very well to accommodate multiple and diverse types of communication links operating at different speed. In addition, the generated data fragments are distributed to the multiple communication links according to their QoS that maximize the real time utilization of the links. This proposal is not intended to limit the scope of functions and procedures described in RFC 1990[1]. This proposal solicits a new type of fragmentation procedure that can be used along with other functions and features described in the RFC 1990. Conditions of Use Technological Concepts Inc. has a U.S. patent pending application with the title ?System and method for transmitting customized Multi Priority Services on a Single or Multiple links over data link layer frames?. If an implementation requires the use of any claims of this patent pending application then Technological Concepts Inc will license such claims on reasonable, non-exclusive and nondiscriminatory terms for use in practicing the proposed standard. General Overview The RFC 1990 [1] was released in an attempt to utilize multiple simultaneous channels between systems, giving users additional bandwidth on demand. The RFC 1990 defines a specific format for the fragmented PPP header. A new PPP header consisting of the Multilink Protocol Identifier 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). PPP multilink fragments are encapsulated using the two bytes protocol identifier 0x00-0x3d. Following the protocol identifier there can be either four byte header or two byte header. After negotiation of an additional PPP LCP option [2], the four byte header may be optionally replaced by a two byte header with only a limited 12 bit sequence space. The Long Sequence Number Fragment Format carries an additional overhead of 6 bytes whereas the Short Sequence Number Fragment Format carries 4 bytes of additional overhead [1] The RFC 1990 does not provide a methodology to slice up PPP traffic constituting of multiple frames in real time and on the fly into multiple fragments with starting and ending boundaries at any arbitrary byte location of the frames. In addition, the RFC does not provide a mechanism that can be effectively utilized to equally distribute the incoming PPP traffic with individual byte granularity into multiple communication links that have different delay and throughput characteristics. The sequence numbering scheme used for keeping track of the fragmented frame described in the said RFC is also for not very scalable, particularly in the scenario when the multiple communication links can range from a low speed (e.g., 56 kbps) to very high speed SDH hierarchy. Also, the RFC proposes a relatively high fragment-header overhead not suitable for low speed access links. To overcome these limitations the present RFC is proposed. Packet Format In this section the modified and proposed layout of individual fragments, which are the "packets" in the Multilink Protocol, is described. As shown in Figure 1 a new sub-framing trailer byte (instead of header) is proposed with its location immediate adjacent and before the FCS field in a PPP frame. Although, the proposed sub-framing trailer can be present at any location in a PPP frame from a known and pre-determine distance from the FCS field. The sub-framing trailer has the following fields: +--------------------+ PPP Header: | Address 0xff | +--------------------+ | Control 0x03 | +--------------------+ | | | fragment data | | | | | +----------------+-+-+ Sub-framing |sequence number |B|E| Trailer: +----------------+-+-+ | FCS | PPP FCS: +--------------------+ | FCS | +--------------------+ FIG. 1 B-bit: The (B)eginning fragment bit is a one-bit field set to 1 on the first data fragment derived from the original frame and set to 0 for all other fragments from the same frame. E-bit :The (E)nding fragment bit is a one-bit field set to 1 on the last data fragment and set to 0 or all other data fragments. A data fragment may have both the (B)eginning and (E)nding fragment bits set to 1. Sequence number field: The sequence number is an initially 6-bit binary number that is incremented modulo 2^6 (ranging 0 to 63) for every data fragment. Notice that the proposed scheme does not require to reserve or pre-assign any specific byte pattern as a protocol identifier followed by the standard PPP header in order to distinguish PPP multilink fragments. It should be noted that RFC 1990 requires PPP multilink fragments to be encapsulated using two bytes as protocol identifier 0x00-0x3d as an additional overhead with every fragmented packet. A simple calculation can reveal that the RFC 1990 overhead with Short Sequence Number Fragment Format, 4 bytes/fragment (2 bytes protocol identifier plus 2 bytes for sequencing and other options) comes out to be 103% more than this proposed scheme. For Long Sequence Number Fragment Format, 6 bytes/fragment (2 bytes protocol identifier plus 4 bytes for sequencing and other options), the overhead is even higher to about 300% more than the present proposed scheme. Fragmentation Procedure The proposed scheme presents a unique method to divide the stream of incoming PPP traffic into multiple fragments, slicing the traffic at any byte boundaries of the frames in real time and on the fly. The amount of data contained in each of the individual fragment is optimized and is made proportional to the transmission characteristics (delay, bandwidth) of the individual links. When using PPP, the delay between channels could be estimated by using LCP echo request and echo reply packets [3]. (In the case of links of different transmission rates, the round trip times should be adjusted to take this into account.). As a first step, a series of data fragments is created by taking a PPP frame, calculating the number of optimum bytes for a particular link, removing the original FCS, calculating a new FCS on the optimum number of bytes and then sending the data fragment on the link. The first data fragment in the series has the B bit set, and the final data fragment has the E bit set. The first fragment sent for a PPP frame may have the sequence number set to any value (including zero), and the sequence number must subsequently be incremented by one for each fragment sent. The sequence number is incremented without regard to the original frame boundaries; if the last fragment in one frame used sequence number "N", then the first fragment of the following frame will use sequence number "N+1". This allows lost fragments (and bursts of lost fragments) to be easily detected. Depending upon the delay and available bandwidth characteristics of the links involved fragments are sliced in such a way that the trailing edge (containing sub-framing bytes) of each of the fragment arrive at the receiving end almost at the same time. The transmitting end determines the amount of data that needs to be transmitted through an individual link is based upon the link capacity. A simple measurement of link capacity is obtained through the multiplication of the available link bandwidth (B) and the transmission delay (D) of a particular link. As the trailing edge of every fragment arrives, the receiver starts putting together the fragments sequentially to reassemble the original frame. For example, as illustrated in Figure 2, the Router A receives a multitude of PPP frames, each with different amount of data in it. The Router A which already knows the delay and bandwidth characteristics of all the available three (3) connected links divide the data in the received frames with byte proportionality s +-+-+----------------+-+-+-------------+-+-+-------+-+ |F|C| D3 |F|C| D2 |F|C| D1 |F| +-+-+----------------+-+-+-------------+-+-+-------+-+ | | | | +--------------------------+ | Router A | +--------------------------+ +--+|(1) +--+|(2) +--+|(3) |F || |F || |F || +--+| +--+| +--+| | || | || | || | || | || | || | || +--+| | || | || |F || | || | || +--+| +--+| | || | |F || +--+| | +--+| |F || | | +--+| | | +--------------------------+ | Router B | +--------------------------+ FIG. 2 Reassembly Procedure The receiver keeps track of the incoming fragments through their sequence numbers and maintains the most recently received sequence number. The receiver detects the end of a reassembled frame when it receives a fragment bearing the (E)nding bit. Reassembly of the frame is complete if all sequence numbers up to that fragment have been received. The receiver detects lost fragments when one or more sequence numbers are skipped. When a lost fragment or fragments are detected, the receiver must discard all currently unassembled and subsequently received fragments until it receives the first fragment that bears the (B)eginning bit. The fragment bearing the (B)eginning bit is used to begin accumulating a new frame. In the event of an error (e.g., one or more fragments lost due to transmission error or reassembly buffer overflow), fragments which cannot be reconstructed back into the original frame must be discarded by the receiver Sequencing Numbering The proposal also presents a novel way of assigning the sequence numbers. As stated the trailing byte containing 6-bit field is used for initial sequencing number. If there is a requirement for higher sequencing number beyond the assigned 6-bit field (2^6 module) then the next upper adjacent byte can also be used for an extended sequencing numbering that can provide a module of 2^6+8 = 2^14 thus giving a sequence range from 0 to 16384. To indicate that the next upper adjacent byte is set for higher sequencing number range the bits in the lower sequence field are all set to 1. As illustrated in FIG. 3 the lower sequencing bits are set to all 1s thus indicating that the next upper adjacent byte will also be used for counting higher sequencing numbers. By the similar procedure whenever the bits in the lower reserved byte(s) for the sequence number field are set to all 1s, the next upper byte is automatically included for counting the extending sequencing number range. For example, the third byte from the first +--------------------+ PPP Header: | Address 0xff | +--------------------+ | Control 0x03 | +--------------------+ | | | fragment data | | | +--------------------+ | sequence number | +----------------+-+-+ Sub-framing |1 1 1 1 1 1|S|L| Trailer: +----------------+-+-+ | FCS | PPP FCS: +--------------------+ | FCS | +--------------------+ FIG. 3 This procedure described above eliminates the need for negotiating an additional PPP LCP option to optionally replace four byte header (Long Sequence Number Fragment Format) with a two byte header (Short Sequence Number Fragment Format) with only a 12 bit sequence space [3]. The devices involved in the fragmentation procedure automatically use the extending sequencing numbering as the need arises. This procedure is very helpful when the multiple links between the source and the destination exist and operate at a very high bandwidth speed with very large and unpredictable differential delays between the links. This proposal also provides a very enhanced and efficient way for reusing the sequencing numbering field. In the proposed scheme when the receiving device processes the last fragment received with the sequence number 63 (maximum range of the initial 6-bit sequencing number field) or higher and it does not have any outstanding fragment with lower sequencing number that needs to be reassemble with the other fragments then it sends a LCP format message to the sending device. The transmitted LCP message indicates to the sending device to roll back to its original sequencing numbering field to the initial start (generate a fresh sequencing number ranging from 0 to 63). Only if the transmitting device does not get this LCP message then it uses the next adjacent upper byte for extended sequencing numbering. This mechanism ensures that additional bytes for sequencing are only used as the demand arises and the procedure is automatic and self-launching. References [1] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, ?The PPP Multilink Protocol (MP)", RFC 1990, August 1996. [2] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994. [3] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994. Authors' Addresses Shakeel Mustafa Technological Concepts, Inc 24831 Hendon St, Laguna Hills, CA 92653 Phone: (949) 510-6023 EMail: shakeel@technologicalconcets.com Notices (A) The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. (B) The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the inf