One document matched: draft-chang-mobile-sctp-address-mgt-00.txt
Internet Draft M. J. Chang/EWU
Document:draft-chang-mobile-sctp- M. J. Lee/EWU
address-mgt-00.txt S. J. Koh/ETRI
Expires: September 2004 March 2004
Address Management for Mobile SCTP Handover
<draft-chang-mobile-sctp-address-mgt-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 [1].
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 - September 2004 [Page 1]
Address Management for Mobile SCTP Handover March 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............3
3.2 Operation of AMM...........................................6
Security Considerations...........................................7
References........................................................8
Author's Addresses................................................8
1. Introduction
The multi-homing feature of Stream Control Transmission Protocol
(SCTP)[2] can be used to provide mobility support. Recently, the
mobile SCTP(mSCTP)[3] 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[4] 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.
MJCHANG Expires - September 2004 [Page 2]
Address Management for Mobile SCTP Handover March 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.
In order to determine when to trigger the primary path change, AMM
also 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 is set slightly higher than L2-TH in order to
have the primary path change occur before deleting the primary path.
While satisfying this condition, the Primary-TH should be as low as
possible in order to reduce the number of unnecessary primary path
changes. In addition, we suggest that AMM selects a new primary path
utilizing the L2 radio signal strength information of the wireless
subnet, 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 - September 2004 [Page 3]
Address Management for Mobile SCTP Handover March 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:
(1)L2HC(L2 Handover Completion): the L2 handover is completed for the
interface specified in the signal
(2)Max-IN(Interface with Maximum signal strength): the interface
providing maximum signal strength has been changed to the one
specified in the signal
(3)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 - September 2004 [Page 4]
Address Management for Mobile SCTP Handover March 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 - September 2004 [Page 5]
Address Management for Mobile SCTP Handover March 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 - September 2004 [Page 6]
Address Management for Mobile SCTP Handover March 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 - September 2004 [Page 7]
Address Management for Mobile SCTP Handover March 2004
References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP,
RFC 2026, October 1996.
[2] 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.
[3] M. Riegel, M. Tuxen, "Mobile SCTP" Internet Draft, Internet
Engineering Task Force, August 2003.
[4] R.Stewart, "Stream Control Transmission Protocol(SCTP) Dynamic
Address Reconfiguration" Internet Draft, Internet Engineering
Task Force, September 2003.
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@etri.re.kr
ETRI, Korea
MJCHANG Expires - September 2004 [Page 8]
Address Management for mSCTP support March 2004
Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 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 information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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 - September 2004 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 04:49:32 |