One document matched: draft-singh-mobileip-fcext-00.txt
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
<draft-singh-mobileip-fcext-00.txt>
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
| PAFTECH AB 2003-2026 | 2026-04-23 11:26:36 |