MOBILE IP WORKING GROUP Ajoy Singh Internet Draft Irfan Ali Document: draft-singh-mobileip-fcext-00.txt Sebastian Thalanany Category: Standard Track Shreesha Ramana, Motorola Umamaheswar Achari Kakinada, 3Com Corporation Rohit Verma, Deloitte Consulting Flow control extensions to Mobile IP for 3G Wireless Networks Status of this Memo This document is an internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate 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.html. 1. Abstract This draft proposes extensions to the mobile IP as used in third generation wireless network [7,1,14] to provide a flow control mechanism on a per-session basis for data sent from the packet data servicing node (PDSN) to a radio network node (RNN). This extension solves the problem of significant performance degradation when packets are dropped at the RNN due to channel setup latency and rate mismatch between the air interface and link between the RNN and PDSN (RP link). 2. Conventions used in this document 2.1 Requirements keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [8]. Singh et. al, RP Flow Control August 2000 1 draft-singh-mobileip-fcext-00.txt August 2000 2.2 Terminology CDMA Code Division Multiple Access LZW Lempel-Ziv and Welch PDSN Packet Data Serving Node RNN Radio Network Node RP Interface between the RNN and the PDSN RF Radio Frequency 3. Introduction The high level architecture of a third generation cdma2000 network RP interface is shown in Figure 1 [7,1,14]. +---------+ +---------+ +---------+ | | | | | | | RNN |----RP------| PDSN |---------| HA | | | Interface | | | | +---------+ +---------+ +---------+ /|\ | Visited Access Home Network | Provider Network | | \|/ +--------+ | Mobile | | Node | +--------+ Figure 1: The Third Generation cdma2000 Network RP Interface [7,1] In figure 1, GRE encapsulated link layer traffic is exchanged between a PDSN and an RNN. RNN buffers packets received from the PDSN when it is unable to schedule radio resources for transmitting the packets received from the PDSN. The RNN interacts with a mobile node over a low bandwidth RF link, while it interacts with a PDSN over a relatively high bandwidth wired link. This is likely to cause packet loss since the PDSN can transfer packets to the RNN at a higher rate than the rate at which the RNN can transfer these packets to the mobile node over the RF link. Additionally, buffer overflow may occur at the RRN as a result of the following reasons: Handoff signaling latency. Data transfer rate reduction as a result of RF link degradation. Scheduling latency in an overloaded system. Singh et.al, RP Flow Control August 2000 2 draft-singh-mobileip-fcext-00.txt August 2000 The effects of packet losses are amplified when delta compression [2,3] algorithms are used to compress packet headers or LZW based payload compression [4,5] is used. The loss of one compressed packet results in a loss of a larger number of packets. Also, packets subsequent to a dropped packet at the RNN, which are not correctly decompressed by the mobile node, are transmitted on the air- interface. This results in wastage of precious air-interface bandwidth. Moreover, even in cases where no compression is used, the loss of one packet at the RNN could result in multiple PPP frames being dropped at the mobile node as multiple PPP frames could be encapsulated in a single GRE packet or the dropped GRE packet could contain a PPP frame boundary. The objective of the flow-control mechanism is to reduce the packet drops at the RNN. Packets could be buffered at the PDSN or dropped before the compression process at the PDSN. The utility of the proposed flow control mechanism is not limited to links carrying compressed traffic, it may also be used to enhance throughput for non-compressed traffic. 4. Mobile/IP and RP protocol Extensions This section describes extensions to Mobile/IP [9] and RP[7,1,14] protocol required to support flow control at RP interface within the third generation cdma2000 network. 4.1 Registration Request An RNN will send flow control extension as a part of a Registration Request message. The flow control extension SHOULD be attached by RNN as part of Registration Request to negotiate flow control with PDSN. The flow control extension should be attached after the session specific extension defined in the RP interface protocol [7,1,14]. The format of flow control is defined in section 4.2. 4.2. Flow Control Extension This extension is defined to carry information related to flow control for the session between a RNN and a PDSN across the RP interface. It should be a part of the Registration Request and Reply messages. The code field in the request message MUST be set to 1 for the peer to detect flow control support. If the recipient also supports this extension then the code is set to zero, else the code is set to a non-zero value. Singh et.al, RP Flow Control August 2000 3 draft-singh-mobileip-fcext-00.txt August 2000 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 | Length | Code | PPD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Window Size | Starting Tx sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The detailed format of the extension is shown as follows. Type TBD. Length This is one octet field and it indicates the length (in bytes) of the extension, NOT including the Type and Length fields. Code 1 in Request 0 in Reply if accepted Non zero in reply if extension not acceptable. PPD A measure of packet processing delay (PPD). This value is specified in units of 1/10 seconds. For sliding window flow control, see section 6.3 for a description of how this value is determined and used. For ON-OFF flow control, see Section 7. Receive Window Size This Indicates receive window size of sender. In case the value set by the sender is non-zero, then sliding window flow control is being negotiated. In case the value is 0, then ON-OFF flow control is being negotiated. Note that a zero receive window size is not appropriate for sliding window flow control. In reply if code is non-zero this field is not interpreted. Starting Tx Sequence Number Indicates starting transmit sequence number. In reply if code is non-zero this field is not interpreted. When a Registration Request is received by a PDSN, if the PDSN supports the sliding window flow control extension, it sets the expected receive sequence number to the Starting Tx sequence number of the extension. For sliding window flow control, the PDSN also Singh et.al, RP Flow Control August 2000 4 draft-singh-mobileip-fcext-00.txt August 2000 sets the its transmit window size to the receive window size received in the flow control extension and uses the PPD value to compute as a seed to the adaptive algorithm to compute time-out value as specified in Section 6.3. For ON-OFF flow control, the PDSN uses PPD for the timeout value to avoid deadlock situation due to drop of ON signal from the receiver as specified in Section 7. To signal to the RNN that the PDSN supports flow control, a PDSN MUST set the Code to zero in the flow control extension of the Registration Reply message. When the flow control extension is NOT supported by PDSN, the extension (all fields) is copied to the Registration Reply without any changes. For sliding window flow control, the PDSN sets the receive window size to an non-zero value if flow-control is desired for data transfer from RNN to PDSN and to zero value if no flow-control is desired in the Registration Reply message. For ON-OFF flow control the receive window size field is set to zero in the registration reply message. In either flow control schemes, the PDSN sets the starting Tx. sequence number and PPD field to appropriate values. When a Registration Reply is received by an RNN that has sent a Registration Request with a flow control extension, the reply message MUST be processed as described in the following sentences. If the Registration Reply message does not contain the flow control extension or the Code field in the flow control extension is set to a non-zero value, the RNN will assume that the PDSN does not support flow control. Otherwise, based on the flow control mechanism being negotiated, the RNN uses the values in the different fields according to the logic specified above for PDSN. 4.3 Registration Reply The Registration Reply will be sent by a PDSN following the procedure as described in [7,1,14]. The PDSN shall attach a flow control extension with every Registration Reply message sent based on the procedure defined in Section 4.2, when the received Registration Request message contains a flow control extension. PDSN MAY accept or reject proposed flow control by setting appropriate code field of flow control extension as defined in Section 4.2. 5. GRE Extension The GRE header suggested in [10] is modified to add acknowledgement field, which will be used for sending explicit, or piggybacked acknowledgement of received GRE packet. Singh et.al, RP Flow Control August 2000 5 draft-singh-mobileip-fcext-00.txt August 2000 The proposed GRE header will have the following format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S|F| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ON-OFF Signal/Ack Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key Present (bit 2) If the Key Present bit is set to 1, then it indicates that the Key field is present in the GRE header. Otherwise, the Key field is not present in the GRE header. Sequence Number Present (bit 3) If the Sequence Number Present bit is set to 1, then it indicates that the Sequence Number field is present. This field MUST be set to support Window based flow control. Flow control Present (bit 4) If the Flow control Present bit set to 1, then it indicates that the ON-OFF signal/Ack sequence number field is present. Key Field (4 octets) The Key field contains a four octet number, which was inserted by the encapsulator. The key field will be used to send Session id of the RP session. Sequence Number (4 octets) Contains sequence number of the payload. ON-OFF signal/Ack Sequence number (4 octets) If sliding window flow control used, this field contains the sequence number of the highest numbered GRE packet received by Singh et.al, RP Flow Control August 2000 6 draft-singh-mobileip-fcext-00.txt August 2000 the sending peer for this user session. If ON-OFF flow control is used, a non-zero value in this field is an OFF signal and a zero value is a ON signal from the receiver to the sender. This field is present if F bit is 1. 6. Sliding Window Flow Control Mechanism This document proposes a sliding window protocol to provide flow control between a PDSN and an RNN. The main purpose of the sliding window protocol is to provide flow control. The tunnel peers do not perform packet retransmissions. Note: The sliding window mechanism provided here is identical to PPTP RFC [11]. Any recommendations on an improved sliding window mechanism are welcome. 6.1. Sliding Window Protocol The sliding window protocol used on the RP data path is used for flow control by the RP tunnel peers involved in packet transfers. The enhanced GRE protocol allows packet acknowledgments to be piggybacked on data packets. Acknowledgments can also be sent separate from data packets. The main purpose of the sliding window protocol is for flow control and the RP tunnel peers do not perform retransmissions. 6.1.1. Initial Window Size Although each side has indicated (section 7) the maximum size of its receive window, it is recommended that a conservative approach be taken while starting a packet transfer. The initial window size on the transmitter is set to half the maximum size the receiver requested, with a minimum size of one packet. The transmitter stops sending packets when the number of packets awaiting acknowledgment is equal to the current window size. As the receiver successfully digests each window, the window size on the transmitter is bumped up by one packet until the maximum is reached. This method prevents a system from flooding an already congested network in the absence of history information. 6.1.2. Closing the Window When a time-out does occur on a packet transfer, the sender adjusts the size of the transmit window down to one half of it's value when it failed. Fractions are rounded up, and the minimum window size is one. Singh et.al, RP Flow Control August 2000 7 draft-singh-mobileip-fcext-00.txt August 2000 6.1.3 Opening the Window With every successful transmission of a window's worth of packet without a time-out, the transmit window size is increased by one packet until it reaches the maximum window size that was sent by the other side, when the call was connected. As stated earlier, no retransmission is done on a time-out. After a time-out, the transmission resumes with the window starting at one half the size of the transmit window when the time-out occurred and adjusting upward by one each time the transmit window is filled with packets that are all acknowledged without time-outs. 6.1.3. Window Overflow When a receiver's window overflows with too many incoming packets, excess packets are thrown away. This situation should not arise if the sliding window procedures are being properly followed by the transmitter and receiver. It is assumed that, on the transmit side, packets are buffered for transmission and are no longer accepted from the packet source when the transmit buffer fills. 6.1.4. Multi-packet Acknowledgment One feature of the RP sliding window protocol is that it allows the acknowledgment of multiple packets with a single acknowledgment. All outstanding packets with a sequence number lower or equal to the acknowledgment number are considered acknowledged. Time-out calculations are performed using the time the packet corresponding to the highest sequence number being acknowledged was transmitted. Adaptive time-out calculations are only performed when an acknowledgment is received. When multi-packet acknowledgments are used, the overhead of the adaptive time-out algorithm is reduced. The RNN is not required to transmit multi-packet acknowledgments. The RNN can instead acknowledge each packet individually as it is delivered to the higher layer. 6.2. Out-of-sequence Packets Occasionally packets may lose their sequencing across a complicated internetwork. For instance, a PDSN may send packets 0 to 5 to a RNN. As a result of rerouting in the internetwork, packet 4 may arrive at the RNN before packet 3. The RNN acknowledges packet 4, and may assume that packet 3 is lost. This acknowledgment grants window credit beyond packet 4. When the RNN does receive packet 3, it MUST not attempt to transmit it to the corresponding higher layer. To do so could cause problems, as proper PPP or any serial interface protocol operation is based upon receiving packets in sequence. PPP properly deals with the loss of packets, but not with reordering. Therefore, out of Singh et.al, RP Flow Control August 2000 8 draft-singh-mobileip-fcext-00.txt August 2000 sequence packets between the PDSN and RNN MUST be silently discarded, or they may be reordered by the receiver. When packet 5 comes in, it is acknowledged by the RNN since it has a higher sequence number than 4, which was the last highest packet acknowledged by the RNN. Packets with duplicate sequence numbers should never occur since the RNN and PDSN never retransmit GRE packets. A robust implementation will silently discard duplicate GRE packets, if any are received. 6.3 Acknowledgment Time-Outs The RP protocol uses sliding windows and time-outs to provide both user session flow-control across the internetwork and to perform efficient data buffering to keep the RNN-PDSN data channels full without causing receive buffer overflow. RP protocol requires that a time-out be used to recover from dropped data or acknowledgment packets. The implementation of the time-out is vendor-specific. It is suggested that an adaptive time-out be implemented with backoff for congestion control. The time-out mechanism proposed here has the following properties: Independent time-outs for each session. A device (RNN or PDSN) will have to maintain and calculate time-outs for every active session. An administrator-adjustable maximum time-out, MaxTimeOut, unique to each device. An adaptive time-out mechanism that compensates for changing throughput. To reduce packet-processing overhead, vendors may choose not to recompute the adaptive time-out for every received acknowledgment. The result of this overhead reduction is that the time-out will not respond as quickly to rapid network changes. Timer backoff on time-out to reduce congestion. The backed-off timer value is limited by the configurable maximum time-out value. Timer backoff is done every time an acknowledgment time-out occurs. In general, this mechanism has the desirable behavior of quickly backing off upon a time-out, and of slowly decreasing the time-out value as packets are delivered without time-outs. Some definitions: Packet Processing Delay (PPD) is the amount of time required for each side to process the maximum amount of data buffered in their receive packet sliding window. The PPD is the value exchanged between the RNN and PDSN when a call is established. For the PDSN, this number should be small. For a RNN making RF connections, this number could be significant. Singh et.al, RP Flow Control August 2000 9 draft-singh-mobileip-fcext-00.txt August 2000 Sample is the actual amount of time incurred receiving an acknowledgment for a packet. The Sample is measured, not calculated. Round-Trip Time (RTT) is the estimated round-trip time for an Acknowledgment to be received for a given transmitted packet. When the network link is a local network, this delay will be minimal (if not zero). When the network link is the Internet, this delay could be substantial and vary widely. RTT is adaptive: it will adjust to include the PPD and whatever shifting network delays contribute to the time between a packet being transmitted and receiving its acknowledgment. Adaptive Time-Out (ATO) is the time that must elapse before an acknowledgment is considered lost. After a time-out, the sliding window is partially closed and the ATO is backed off. The Packet Processing Delay (PPD) parameter is a 12-bit value exchanged during the Call Control phase that represents tenths of a second (64 means 6.4 seconds). The protocol only specifies that the parameter is exchanged, it does not specify how it is calculated. The determination of PPD values is implementation-dependent, and need not be variable (static time-outs are allowed). The PPD must be exchanged in the call connect sequences, even if it remains constant in an implementation. One possible way to calculate the PPD is: PPD = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate Where, Header is the total size of the IP and GRE headers. MTU is the overall MTU for the internetwork link between the RNN and PDSN. WindowSize represents the number of packets in the sliding window, and is implementation-dependent. The latency of the internetwork could be used to pick a window size sufficient to keep the current session's pipe full. The constant 8 converts octets to bits (assuming ConnectRate is in bits per second). If the ConnectRate is in bytes per second, omit the 8. The value of PPD is used to seed the adaptive algorithm with the initial RTT[n-1] value. 6.3.1. Calculating Adaptive Acknowledgment Time-Out The time-out allocated for the receipt of an acknowledgement is to be determined. If the time-out is set too high, the wait may be unnecessarily long for dropped packets. If the time-out is too short, the time-out may occur just before an acknowledgment arrives. The acknowledgement time-out should be reasonable and responsive to changing network conditions. The suggested adaptive algorithm Singh et.al, RP Flow Control August 2000 10 draft-singh-mobileip-fcext-00.txt August 2000 described below is based on the TCP 1989 implementation and is explained in [11]. 'n' means this iteration of the calculation, and 'n-1' refers to values from the last calculation. DIFF[n] = SAMPLE[n] - RTT[n-1] DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) RTT[n] = RTT[n-1] + (alpha * DIFF[n]) ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)) DIFF represents the error between the last estimated round-trip time and the measured time. DIFF is calculated on each iteration. DEV is the estimated mean deviation. This approximates the standard deviation. DEV is calculated on each iteration and stored for use in the next iteration. Initially, it is set to 0. RTT is the estimated round-trip time of an average packet. RTT is calculated on each iteration and stored for use in the next iteration. Initially, it is set to PPD. ATO is the adaptive time-out for the next transmitted packet. ATO is calculated on each iteration. Its value is limited, by the MIN function, to be a maximum of the configured MaxTimeOut value. Alpha is the gain for the average and is typically 1/8 (0.125). Beta is the gain for the deviation and is typically 1/4 (0.250). Chi is the gain for the time-out and is typically set to 4. To eliminate division operations for fractional gain elements, the entire set of equations can be scaled. With the suggested gain constants, they should be scaled by 8 to eliminate all division. To simplify calculations, all gain values are kept to powers of two so that shift operations can be used in place of multiplication or division. 6.3.2. Congestion Control: Adjusting for Time-Out This section describes how the calculation of ATO is modified in the case where a time-out does occur. When a time-out occurs, the time- out value should be adjusted rapidly upward. Although the GRE packets are not retransmitted when a time-out occurs, the time-out should be adjusted up toward a maximum limit. To compensate for shifting internetwork time delays, a strategy must be employed to increase the time-out when it expires (notice that in addition to increasing the time-out, we are also shrinking the size of the window as described in the next section). For an interval in which a time-out occurs, the new ATO is calculated as: Singh et.al, RP Flow Control August 2000 11 draft-singh-mobileip-fcext-00.txt August 2000 RTT[n] = delta * RTT[n-1] DEV[n] = DEV[n-1] ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)) In this calculation of ATO, only the two values, that contribute to ATO and are stored for the next iteration, are calculated. RTT is scaled by delta, and DEV is unmodified. DIFF is not carried forward and is not used in this scenario. A value of 2 for Delta, the time- out gain factor for RTT, is suggested. 7.ON-OFF Flow Control Mechanism In an ON-OFF flow control scheme, the receiver on detecting congestion event sends an explicit OFF signal to the sender to stop transmitting packets of a particular session. Once the receiver is ready to receive additional packets it sends an ON signal to the sender to restart transmission of a session's packet. The congestion event could be any receiver-defined event such as the average length of buffer dedicated to a flow reaching a high watermark. The congestion clearance signal, in such a case, would be the average queue length below a low watermark. The ON-OFF flow control is simpler than a sliding window flow control in the following manner: 1.The receiver does not need to send explicit/piggybacked acknowledgement of the received packets. While sequence numbering is not needed for flow control, it could still be used to re-order out- of-sequence packets at the receiver. 2.The logic at the sender and receiver is simpler in an ON-OFF flow control scheme. 3.The bandwidth for feedback signaling is lower. Sliding window flow control requires constant updating of the ack sequence number, whereas in ON-OFF flow control, the receiver only sends an OFF or ON signal on detection/clearance of congestion conditions. However, ON-OFF flow control provides coarser flow control than sliding window flow control. In certain situations, such as when the tunneling end-points are not many hops away, ON-OFF flow control may be adequate. The extensions to Mobile IP protocol presented in Section 4 and 5 enable either sliding window flow control or ON-OFF flow control to be used. As stated in Section 4.2, if the Receive window size field in a flow control extension message is set to zero (0), then ON-OFF flow control is being negotiated. Singh et.al, RP Flow Control August 2000 12 draft-singh-mobileip-fcext-00.txt August 2000 Once an RP session has been opened, the sender MAY start transmitting packets in the GRE tunnel. The receiver is NOT REQUIRED to transmit an explicit ON signal to the sender. 7.1 Receiver's Logic On detecting a congestion event, the receiver transmits one or more OF signal to the sender. On the clearance of a congestion event, the sender sends one or more ON signal. The ON/OFF signal could be sent as a separate GRE packet or piggybacked onto data packets. It is RECOMMENDED that the detection of congestion/congestion- clearance events at the receiver be based on averaged values rather than on instantaneous values for graceful operation. In the registration request message, the receiver informs the sender of the approximate time it takes for a congestion event to be cleared at the receiver in the PPD field of the flow control extension. Setting PPD to a low value could result in the sender sending packets to the receiver before a congestion is cleared, leading to packet drops at the receiver. Setting the PPD to a high value could result in the sender taking much longer to resume transmission of packets in case a ON signal is dropped by a network, resulting in lower throughput. As an OPTION, during congestion conditions, the receiver could periodically transmit OFF signals to the transmitter every alpha*PPD (alpha < 1.0) time units. 7.2 Sender's Logic On receiving an OFF signal from the receiver, the sender stops transmission of the tunneled session's packets. It should also start a timer on receipt of every OFF signal. The timeout value of the timer MUST be set to the value of PPD field flow control extension of the registration request message. On receipt of an ON signal or the expiration of the timer, the sender starts transmission of the tunneled session's packet. The timer is used at the sender to avoid a deadlock situation in case ON signals from the receiver are dropped in the network. 7.Security Considerations The flow control extension presented in this section will be used with base R-P interface protocol [7,1,14], so it will follow all the security measures supplied by R-P Interface protocol. No extra security measures are required to support flow control extension. Singh et.al, RP Flow Control August 2000 13 draft-singh-mobileip-fcext-00.txt August 2000 8.IANA Consideration This document specifies one new extension to Mobile IP protocol [9]. The flow control Specific Extension defined in section 6 MUST be assigned the Type value of TBD. 9. References [1] 3GPP2 TSG-A,"3GPP2 Access Network Interfaces Technical Specification (3G-IOS)", Version 4.0.0, December 13 1999. [2] Jacobson, V., "Compressing TCP/IP Headers for low speed Serial links," RFC 1144, February 1990. [3] M. Degermark, B. Nordgren, S.Pink. "IP Header Compression", February 1999. [4] Pall, G., "Microsoft Point to Point Compression (MPPC) Protocol", RFC 2118, March 1997. [5] Friend, Simpson, "PPP LZS-DCP Compression Protocol (LZS-DCP)," RFC 1867, August 1996. [6] Hank, S., Li R., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [7] Yong Chang, et. al, "Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network", draft-ietf- mobileip-ext-02.txt [8] Brander, S., "Key words for use in RFCS to indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [9] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 1996. [10] Gopal Dommety, "Key and Sequence Number Extensions to GRE", draft-dommety-gre-ext-00.txt [11] K. Hamzeh, "Point to point tunneling Protocol", RFC 2637, July 1999. [12] Stevens, R, "TCP/IP Illustrated Volume 1", p. 300, Addison Wesley, 1994. [13] Postel, J.,"Transmission Control Protocol", STD 7, RFC 793, Sept 1981. [14] TR 45.6,"Wireless IP Network standards", Jan 13 2000. Singh et.al, RP Flow Control August 2000 14 draft-singh-mobileip-fcext-00.txt August 2000 12. Acknowledgments The authors of this draft would like to thank author of PPTP informational RFC 2637. This draft uses windowing mechanism proposed in PPTP RFC. 11. Author's Addresses Ajoy Singh Motorola 1501 West Shure Driver Arlington Heights, IL- 60004 Phone: 847-632 6941 Email: asingh1@email.mot.com Irfan Ali Motorola 1501 West Shure Driver Arlington Heights, IL- 60004 Phone: 1-847-632-3281 Email: FIA225@email.mot.com Sebastian Thalanany Motorola 1475 West Shure Drive Arlington Heights, IL - 60004 Phone: (847) 435-9296 Email: sthalan1@email.mot.com Shreesha Ramana Motorola 1501 West Shure Drive Arlington Heights, IL - 60004 Email: QA5831@email.mot.com Umamaheswar A, Kakinand 3Com Corporation, 1800 West Central Road, Mount Prospect, IL -60056 Email: ukakinad@mw.3com.com Rohit Verma 180, N. Stetson Ave. Chicago, IL 60601 Email: rverma@dttus.com Singh et.al, RP Flow Control August 2000 15