One document matched: draft-chang-mobile-sctp-address-mgt-01.txt
Differences from draft-chang-mobile-sctp-address-mgt-00.txt
Internet Draft M. J. Chang/EWU
Document:draft-chang-mobile-sctp-address-mgt-01.txt M. J. Lee/EWU
S. J. Koh/KNU
Expires: March 2005 October 2004
Address Management for Mobile SCTP Handover
<draft-chang-mobile-sctp-address-mgt-01.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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.
Abstract
This document describes an address management module for mobile
Stream Control Transmission Protocol (mSCTP). The module is used for
a mobile node to manage the IP addresses associated with an mSCTP
association. The address management module utilizes the link layer
signal strength information in order to determine when to add or
delete end-point IP addresses of a mobile node and how to change the
primary path from the mSCTP association when a handover happens.
MJCHANG Expires - March 2005 [Page 1]
Address Management for Mobile SCTP Handover October 2004
Table of Contents
1. Introduction...................................................2
2. Terminoloby....................................................2
3. Address Management for mSCTP...................................3
3.1 Communication between AMM and the other modules............4
3.2 Operation of AMM...........................................7
Security Considerations...........................................8
References........................................................9
Author's Addresses................................................9
1. Introduction
The multi-homing feature of Stream Control Transmission Protocol
(SCTP)[1] can be used to provide mobility support. Recently, the
mobile SCTP(mSCTP)[2] has been proposed as a transport layer mobility
solution. For mSCTP handover, a Mobile Node(MN) can send an ADDIP
ASCONF chunk to the Correspondent Node(CN) to ensure that a newly
obtained IP address is added to the SCTP association. The MN may also
request the CN to delete an existing IP address from the SCTP
association by sending a DELETEIP ASCONF chunk. The primary data path
for an SCTP association may also be changed to the other IP address
by using a Set-primary ASCONF chunk. In this way, the MN can perform
mSCTP handover to a new location without aid of the network.
The current specification of mSCTP specifies the basic requirements
and suggestions to utilize Dynamic Address Reconfiguration
Extension[3] to support session mobility. Some essential issues, such
as when and by which criteria the primary path to be changed or the
addition and deletion of the IP addresses mapped to the SCTP
association should occur in order to deal with handover seamlessly,
are not specified yet.
In this document, we describe a logical block named Address
Management Module(AMM), which determines when to trigger ADDIP,
DELETEIP, and Set-primary ASCONF chunk utilizing the signal strength
of the underlying link and informs it to the mSCTP at MN.
2. Terminology
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[4].
MJCHANG Expires - March 2005 [Page 2]
Address Management for Mobile SCTP Handover October 2004
3. Address Management for mSCTP
When handover happens, mSCTP at MN should perform ADDIP for the new
IP address DELETEIP for the old one, and Set-primary for the current
primary path. Therefore, we define Address Management Module(AMM)
which determines when to trigger ADDIP, DELETEIP, and Set-primary
ASCONF chunk utilizing the signal strength of the underlying link and
informs it to the mSCTP at MN. When AMM triggers mSCTP, mSCTP at MN
interacts with peer mSCTP at CN to change the end point mapping or
the primary path for the SCTP association.
In order to determine when to trigger ADDIP and DELETEIP, AMM uses L2
radio signal strength information. AMM triggers mSCTP to perform
ADDIP as soon as the signal strength of the new access router exceeds
the signal strength threshold value that enables communications
(hereinafter, it is called L2-TH). Once an IP address is added,
DELETEIP for that address is not triggered until the signal strength
from the corresponding access router becomes lower than the L2-TH.
With these policies, an SCTP association maintains the MN's IP
address corresponding to all of the accessible subnets. Furthermore,
an accessible IP address is added to the SCTP association as early as
possible. The main purpose of these policies regarding adding or
deleting end point IP addresses is to maximize the change that an end
point IP address is ready when it is needed for handover.
Minimum signal strength that enables communication is the signal
strength measured at the boundary of transmission range, and is
determined by radio propagation model. For Two-Ray Ground Reflection
model, which is the radio propagation model assumed in our
simulation experiment, the minimum signal strength that enables
communication (i.e., L2-TH) is computed by the following formula:
Pt*Gt*Gr*ht**2hr**2 / d**4*L (1)
, where Pt, Gt, Gr, ht, hr, d and L denote transmit power, transmit
antenna gains, receiver antenna gains, transmit antenna height,
receive antenna height, diameter of transmission range, and system
loss, respectively.
When handover happens, the primary path also needs to be changed.
The current mSCTP does not specifically mention about how to change
the primary path for handovers. In SCTP, sender is in charge of
changing the primary path and it changes the primary path if the
primary path experiences repetitive losses over a certain threshold.
If it is adopted in mSCTP, therefore, CN should experience multiple
data packet losses for each handover before it finally determines to
change the primary path and it will lead to significantly long
handover latency.
MJCHANG Expires ?March 2005 [Page 3]
Address Management for Mobile SCTP Handover October 2004
In order to prevent this, the proposed scheme makes MN, which is the
receiver, be in charge of the primary path change, and trigger Set-
Primary toward CN when handover happens. Set-Primary from MN
notifies CN to change the primary path. In order to determine when
to trigger Set-Primary, MN uses L2 radio signal strength information.
If the radio signal strength of the primary path becomes lower than
a certain threshold (hereinafter it is called Primary-TH), primary
path is replaced. The value of Primary-TH should be higher than L2-
TH at the minimum in order for MN to trigger Set-Primary before
DELETEIP of the primary path. Furthermore, it is desirable for Set-
Primary to arrive at CN before MN completely moves out of the
transmission range of the old access point. In order to satisfy this
condition, the signal strength corresponding to Primary-TH should be
at least the signal strength at the boundary of transmission range
with diameter (d-d'), where d is the transmission range of the
access router and d' is the distance that MN can move during the
time for which Set-Primary is delivered from MN to CN. Therefore,
based on the formula in (1), the minimum signal strength for
Primary-TH that can satisfy the condition is obtained as follows:
1/[{(d-d'/d}**4]*L2-TH (2)
Note that the value determined by (2) depends on the moving speed of
MN and the delay from MN to CN. Actually, the Primary-TH value
computed by (2) is an optimal one since increasing Primary-TH value
any further would only increase the chance of unnecessary primary
path changes. The proposed scheme also let MN select a new primary
path utilizing the L2 radio signal strength information of the
wireless subnet, and inform it to CN. Among the accessible subnets,
the one providing strongest radio signal is selected as the new
primary path in order to minimize the possible oscillation.
3.1 Communication between AMM and the other modules
Figure 1 presents the interaction between AMM and the rest of mSCTP,
IP address acquisition module, and link layer respectively. Receiving
signals from the link layer and the IP address acquisition module,
AMM determines when to trigger ADDIP, DELETEIP, and Set-primary
ASCONF chunk and informs it to mSCTP. mSCTP at MN then interacts with
peer mSCTP at CN to change the end point mapping or the primary path
for the SCTP association.
MJCHANG Expires - March 2005 [Page 4]
Address Management for Mobile SCTP Handover October 2004
Triggering
-ADDIP
-DELETEIP
-Set-primary
+-------------+ +-------+
| mobile SCTP |<------- | AMM |
+-------------+ +-------+
^ ^ ^
IPAC| | |
+----+ +-----------------------+
| IP | | IP address |
| | | acquisition time |
+----+ +-----------------------+
L2HC | | L2SS/
| | Max-IN
+--------------------------------+
| Link Layer |
+--------------------------------+
Figure 1 Signaling between components and AMM
As shown in figure 1, link layer sends out following three types of
signals to AMM in order to inform AMM about an L2 handover completion
or changes of link signal strength:
L2HC(L2 Handover Completion): the L2 handover is completed for the
interface specified in the signal
Max-IN(Interface with Maximum signal strength): the interface
providing maximum signal strength has been changed to the one
specified in the signal
L2SS(L2 Signal Strength): one of the L2 signal strength changes
shown in figure 2 has occurred for a certain interface; L2SS
specifies the interface for which the change has occurred and the
types of signal strength change(S).
MJCHANG Expires - March 2005 [Page 5]
Address Management for Mobile SCTP Handover October 2004
L2-TH Primary-TH
<-------------------------------------->
| |
(1)-------------> |
| -------------->(2)
(3)-------------------------------->
| <------------- (4)
(5) <------------ |
<------------------------------ (6)
| |
<-------------------------------------->
Figure 2 L2 signal strength change
IP address acquisition module sends out IPAC(IP address Acquisition
Completion) signal when an IP address acquisition for an interface is
completed. The IPAC signal indicates the interface ID and the
acquired IP address for that interface.
In order to store the information collected from the signals from the
link layer and the IP address acquisition module as shown in figure 1,
AMM maintains an Address Table as shown in figure 3. The SS(Signal
Strength) field of the address table indicates the current signal
strength of the interface, and the meaning of the value of this field
is shown in table 2. The H flag in the address table indicates
whether the L2 handover is completed for the corresponding interface.
Receiving L2HC signal for a certain interface, H flag of
corresponding entry in the address table can be set. The IP address
field of the address table is filled when IPAC signal for the
corresponding entry comes in from the IP address acquisition module.
In addition to address table, AMM also maintains information such as
the interface corresponding to the current primary path and the
interface with maximum signal strength.
+-------------------------------------------+
| Interface ID | SS | H flag | IP address |
+-------------------------------------------+
| : | : | : | : |
+--------------+------+--------+------------+
Figure 3 Address Table in AMM
MJCHANG Expires - March 2005 [Page 6]
Address Management for Mobile SCTP Handover October 2004
Table 1 The values of the SS field in the address table
+-----------------------------+
| SS | Signal Strength p |
+----+------------------------+
| 0 | p < L2-TH |
+----+------------------------+
| 1 | L2-TH < p < Primary-TH |
+----+------------------------+
| 2 | Primary-TH < p |
+----+------------------------+
Table 2 The value of the SS field that mapped
by the S value of L2SS signal
+---------------------------+
| S field | SS field in |
| in L2SS | Address Table |
+---------+-----------------+
| 5, 6 | 0 |
+---------+-----------------+
| 1, 4 | 1 |
+---------+-----------------+
| 2, 3 | 2 |
+---------+-----------------+
3.2 Operation of AMM
mSCTP at MN sends ADDIP ASCONF chunk for a certain IP address when
both the L2 handover and the IP address acquisition of the
corresponding interface are competed. That is, by receiving either an
L2HC or an IPAC signal, if both the IP address field and the H flag
are set for a certain entry of the address table, AMM triggers mSCTP
to send ADDIP ASCONF chunk for the corresponding interface.
When AMM receives L2SS with S=4 or 6 for the current primary path
interface, the primary path should be replaced. AMM first checks
whether there is an alternative interface ready to be used as the new
primary path. If one is found, it immediately triggers mSCTP to send
Set-primary ASCONF chunk in order to replace the primary path with
that alternative interface. In order for an interface to be a primary
path interface, it should satisfy the following three conditions:
MJCHANG Expires - March 2005 [Page 7]
Address Management for Mobile SCTP Handover October 2004
(1)It is the interface with maximum signal strength and the signal
strength is greater than the æPrimary-TH? Note that even the
interface with the maximum signal strength may not provide the
signal strength higher than the Primary-TH.
(2)Link layer handover for the interface is completed.
(3)IP address acquisition for the interface is completed.
If there is no such interface, AMM postpones triggering mSCTP to send
Set-primary ASCONF chunk until a path which satisfies all three of
the above conditions appears. In order to avoid frequent changes of
primary path during handover, the primary path is not replaced until
a path which is stable enough is found even though the current one
becomes inadequate. In the proposed scheme, a stable path is defined
as the path that satisfies the above three conditions. The status of
an interface may be transformed to being stable by incoming L2SS,
L2HC, or IPAC signals. Having SS being equal to 0 or 1 for the
current primary path indicates that the current primary path has
become inadequate. Therefore, in this case, AMM triggers mSCTP to
send Set-primary ASCONF chunk as soon as interface satisfying all
three conditions of the primary path interface shows up.
If AMM receives an L2SS signal with S=5 or 6 for a certain interface,
AMM triggers mSCTP to send DELETEIP ASCONF chunk in order to delete
that interface. If the interface happens to be the current primary
path interface, AMM searches an alternative interface to serve as the
primary path. If there is no interface ready to replace the primary
path, triggering mSCTP to send DELETEIP ASCONF chunk should be
postponed. In this case, whenever mSCTP to send Set-primary ASCONF
chunk is triggered afterwards, sending DELETEIP ASCONF chunk for the
current primary path interface should be triggered together.
Security Considerations
This document discusses architecture of SCTP mobility support. The
associated security issues will be identified as further works go on.
MJCHANG Expires - March 2005 [Page 8]
Address Management for Mobile SCTP Handover October 2004
References
[1] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T.
Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson, "Stream Control
Transmission Protocol", RFC 2960, October 2000.
[2] M. Riegel, M. Tuxen, "Mobile SCTP", Internet Draft, Internet
Engineering Task Force, August 2003.
[3] R.Stewart, "Stream Control Transmission Protocol(SCTP) Dynamic
Address Reconfiguration", Internet Draft, Internet Engineering
Task Force, September 2003.
[4] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels",RFC 2119, March 1997.
Author's Addresses
Moon Jeong Chang
mjchang@ewha.ac.kr
Ewha Womans Univ., Korea
Mee Jeong Lee
lmj@ewha.ac.kr
Ewha Womans Univ., Korea
Seok Joo Koh
sjkoh@cs.knu.ac.kr
Kyungbook National Univ., Korea
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
"This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
MJCHANG Expires - March 2005 [Page 9] | PAFTECH AB 2003-2026 | 2026-04-24 04:49:05 |