idnits 2.17.1 draft-chang-mobile-sctp-address-mgt-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 14 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 248 has weird spacing: '... signal for ...' == Line 295 has weird spacing: '... both the ...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2004) is 7131 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2960 (ref. '1') (Obsoleted by RFC 4960) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft M. J. Chang/EWU 3 Document:draft-chang-mobile-sctp-address-mgt-01.txt M. J. Lee/EWU 4 S. J. Koh/KNU 5 Expires: March 2005 October 2004 7 Address Management for Mobile SCTP Handover 8 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes an address management module for mobile 35 Stream Control Transmission Protocol (mSCTP). The module is used for 36 a mobile node to manage the IP addresses associated with an mSCTP 37 association. The address management module utilizes the link layer 38 signal strength information in order to determine when to add or 39 delete end-point IP addresses of a mobile node and how to change the 40 primary path from the mSCTP association when a handover happens. 42 Address Management for Mobile SCTP Handover October 2004 44 Table of Contents 46 1. Introduction...................................................2 47 2. Terminoloby....................................................2 48 3. Address Management for mSCTP...................................3 49 3.1 Communication between AMM and the other modules............4 50 3.2 Operation of AMM...........................................7 51 Security Considerations...........................................8 52 References........................................................9 53 Author's Addresses................................................9 55 1. Introduction 57 The multi-homing feature of Stream Control Transmission Protocol 58 (SCTP)[1] can be used to provide mobility support. Recently, the 59 mobile SCTP(mSCTP)[2] has been proposed as a transport layer mobility 60 solution. For mSCTP handover, a Mobile Node(MN) can send an ADDIP 61 ASCONF chunk to the Correspondent Node(CN) to ensure that a newly 62 obtained IP address is added to the SCTP association. The MN may also 63 request the CN to delete an existing IP address from the SCTP 64 association by sending a DELETEIP ASCONF chunk. The primary data path 65 for an SCTP association may also be changed to the other IP address 66 by using a Set-primary ASCONF chunk. In this way, the MN can perform 67 mSCTP handover to a new location without aid of the network. 69 The current specification of mSCTP specifies the basic requirements 70 and suggestions to utilize Dynamic Address Reconfiguration 71 Extension[3] to support session mobility. Some essential issues, such 72 as when and by which criteria the primary path to be changed or the 73 addition and deletion of the IP addresses mapped to the SCTP 74 association should occur in order to deal with handover seamlessly, 75 are not specified yet. 77 In this document, we describe a logical block named Address 78 Management Module(AMM), which determines when to trigger ADDIP, 79 DELETEIP, and Set-primary ASCONF chunk utilizing the signal strength 80 of the underlying link and informs it to the mSCTP at MN. 82 2. Terminology 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119[4]. 88 Address Management for Mobile SCTP Handover October 2004 90 3. Address Management for mSCTP 92 When handover happens, mSCTP at MN should perform ADDIP for the new 93 IP address DELETEIP for the old one, and Set-primary for the current 94 primary path. Therefore, we define Address Management Module(AMM) 95 which determines when to trigger ADDIP, DELETEIP, and Set-primary 96 ASCONF chunk utilizing the signal strength of the underlying link and 97 informs it to the mSCTP at MN. When AMM triggers mSCTP, mSCTP at MN 98 interacts with peer mSCTP at CN to change the end point mapping or 99 the primary path for the SCTP association. 101 In order to determine when to trigger ADDIP and DELETEIP, AMM uses L2 102 radio signal strength information. AMM triggers mSCTP to perform 103 ADDIP as soon as the signal strength of the new access router exceeds 104 the signal strength threshold value that enables communications 105 (hereinafter, it is called L2-TH). Once an IP address is added, 106 DELETEIP for that address is not triggered until the signal strength 107 from the corresponding access router becomes lower than the L2-TH. 108 With these policies, an SCTP association maintains the MN's IP 109 address corresponding to all of the accessible subnets. Furthermore, 110 an accessible IP address is added to the SCTP association as early as 111 possible. The main purpose of these policies regarding adding or 112 deleting end point IP addresses is to maximize the change that an end 113 point IP address is ready when it is needed for handover. 115 Minimum signal strength that enables communication is the signal 116 strength measured at the boundary of transmission range, and is 117 determined by radio propagation model. For Two-Ray Ground Reflection 118 model, which is the radio propagation model assumed in our 119 simulation experiment, the minimum signal strength that enables 120 communication (i.e., L2-TH) is computed by the following formula: 121 Pt*Gt*Gr*ht**2hr**2 / d**4*L (1) 122 , where Pt, Gt, Gr, ht, hr, d and L denote transmit power, transmit 123 antenna gains, receiver antenna gains, transmit antenna height, 124 receive antenna height, diameter of transmission range, and system 125 loss, respectively. 127 When handover happens, the primary path also needs to be changed. 128 The current mSCTP does not specifically mention about how to change 129 the primary path for handovers. In SCTP, sender is in charge of 130 changing the primary path and it changes the primary path if the 131 primary path experiences repetitive losses over a certain threshold. 132 If it is adopted in mSCTP, therefore, CN should experience multiple 133 data packet losses for each handover before it finally determines to 134 change the primary path and it will lead to significantly long 135 handover latency. 137 Address Management for Mobile SCTP Handover October 2004 139 In order to prevent this, the proposed scheme makes MN, which is the 140 receiver, be in charge of the primary path change, and trigger Set- 141 Primary toward CN when handover happens. Set-Primary from MN 142 notifies CN to change the primary path. In order to determine when 143 to trigger Set-Primary, MN uses L2 radio signal strength information. 144 If the radio signal strength of the primary path becomes lower than 145 a certain threshold (hereinafter it is called Primary-TH), primary 146 path is replaced. The value of Primary-TH should be higher than L2- 147 TH at the minimum in order for MN to trigger Set-Primary before 148 DELETEIP of the primary path. Furthermore, it is desirable for Set- 149 Primary to arrive at CN before MN completely moves out of the 150 transmission range of the old access point. In order to satisfy this 151 condition, the signal strength corresponding to Primary-TH should be 152 at least the signal strength at the boundary of transmission range 153 with diameter (d-d'), where d is the transmission range of the 154 access router and d' is the distance that MN can move during the 155 time for which Set-Primary is delivered from MN to CN. Therefore, 156 based on the formula in (1), the minimum signal strength for 157 Primary-TH that can satisfy the condition is obtained as follows: 158 1/[{(d-d'/d}**4]*L2-TH (2) 159 Note that the value determined by (2) depends on the moving speed of 160 MN and the delay from MN to CN. Actually, the Primary-TH value 161 computed by (2) is an optimal one since increasing Primary-TH value 162 any further would only increase the chance of unnecessary primary 163 path changes. The proposed scheme also let MN select a new primary 164 path utilizing the L2 radio signal strength information of the 165 wireless subnet, and inform it to CN. Among the accessible subnets, 166 the one providing strongest radio signal is selected as the new 167 primary path in order to minimize the possible oscillation. 169 3.1 Communication between AMM and the other modules 171 Figure 1 presents the interaction between AMM and the rest of mSCTP, 172 IP address acquisition module, and link layer respectively. Receiving 173 signals from the link layer and the IP address acquisition module, 174 AMM determines when to trigger ADDIP, DELETEIP, and Set-primary 175 ASCONF chunk and informs it to mSCTP. mSCTP at MN then interacts with 176 peer mSCTP at CN to change the end point mapping or the primary path 177 for the SCTP association. 179 Address Management for Mobile SCTP Handover October 2004 181 Triggering 182 -ADDIP 183 -DELETEIP 184 -Set-primary 185 +-------------+ +-------+ 186 | mobile SCTP |<------- | AMM | 187 +-------------+ +-------+ 189 ^ ^ ^ 190 IPAC| | | 192 +----+ +-----------------------+ 193 | IP | | IP address | 194 | | | acquisition time | 195 +----+ +-----------------------+ 196 L2HC | | L2SS/ 197 | | Max-IN 198 +--------------------------------+ 199 | Link Layer | 200 +--------------------------------+ 202 Figure 1 Signaling between components and AMM 204 As shown in figure 1, link layer sends out following three types of 205 signals to AMM in order to inform AMM about an L2 handover completion 206 or changes of link signal strength: 208 L2HC(L2 Handover Completion): the L2 handover is completed for the 209 interface specified in the signal 211 Max-IN(Interface with Maximum signal strength): the interface 212 providing maximum signal strength has been changed to the one 213 specified in the signal 215 L2SS(L2 Signal Strength): one of the L2 signal strength changes 216 shown in figure 2 has occurred for a certain interface; L2SS 217 specifies the interface for which the change has occurred and the 218 types of signal strength change(S). 220 Address Management for Mobile SCTP Handover October 2004 222 L2-TH Primary-TH 223 <--------------------------------------> 224 | | 225 (1)-------------> | 226 | -------------->(2) 227 (3)--------------------------------> 228 | <------------- (4) 229 (5) <------------ | 230 <------------------------------ (6) 231 | | 232 <--------------------------------------> 234 Figure 2 L2 signal strength change 236 IP address acquisition module sends out IPAC(IP address Acquisition 237 Completion) signal when an IP address acquisition for an interface is 238 completed. The IPAC signal indicates the interface ID and the 239 acquired IP address for that interface. 241 In order to store the information collected from the signals from the 242 link layer and the IP address acquisition module as shown in figure 1, 243 AMM maintains an Address Table as shown in figure 3. The SS(Signal 244 Strength) field of the address table indicates the current signal 245 strength of the interface, and the meaning of the value of this field 246 is shown in table 2. The H flag in the address table indicates 247 whether the L2 handover is completed for the corresponding interface. 248 Receiving L2HC signal for a certain interface, H flag of 249 corresponding entry in the address table can be set. The IP address 250 field of the address table is filled when IPAC signal for the 251 corresponding entry comes in from the IP address acquisition module. 252 In addition to address table, AMM also maintains information such as 253 the interface corresponding to the current primary path and the 254 interface with maximum signal strength. 256 +-------------------------------------------+ 257 | Interface ID | SS | H flag | IP address | 258 +-------------------------------------------+ 259 | : | : | : | : | 260 +--------------+------+--------+------------+ 262 Figure 3 Address Table in AMM 264 Address Management for Mobile SCTP Handover October 2004 266 Table 1 The values of the SS field in the address table 268 +-----------------------------+ 269 | SS | Signal Strength p | 270 +----+------------------------+ 271 | 0 | p < L2-TH | 272 +----+------------------------+ 273 | 1 | L2-TH < p < Primary-TH | 274 +----+------------------------+ 275 | 2 | Primary-TH < p | 276 +----+------------------------+ 278 Table 2 The value of the SS field that mapped 279 by the S value of L2SS signal 281 +---------------------------+ 282 | S field | SS field in | 283 | in L2SS | Address Table | 284 +---------+-----------------+ 285 | 5, 6 | 0 | 286 +---------+-----------------+ 287 | 1, 4 | 1 | 288 +---------+-----------------+ 289 | 2, 3 | 2 | 290 +---------+-----------------+ 292 3.2 Operation of AMM 294 mSCTP at MN sends ADDIP ASCONF chunk for a certain IP address when 295 both the L2 handover and the IP address acquisition of the 296 corresponding interface are competed. That is, by receiving either an 297 L2HC or an IPAC signal, if both the IP address field and the H flag 298 are set for a certain entry of the address table, AMM triggers mSCTP 299 to send ADDIP ASCONF chunk for the corresponding interface. 301 When AMM receives L2SS with S=4 or 6 for the current primary path 302 interface, the primary path should be replaced. AMM first checks 303 whether there is an alternative interface ready to be used as the new 304 primary path. If one is found, it immediately triggers mSCTP to send 305 Set-primary ASCONF chunk in order to replace the primary path with 306 that alternative interface. In order for an interface to be a primary 307 path interface, it should satisfy the following three conditions: 309 Address Management for Mobile SCTP Handover October 2004 311 (1)It is the interface with maximum signal strength and the signal 312 strength is greater than the �Primary-TH? Note that even the 313 interface with the maximum signal strength may not provide the 314 signal strength higher than the Primary-TH. 316 (2)Link layer handover for the interface is completed. 318 (3)IP address acquisition for the interface is completed. 320 If there is no such interface, AMM postpones triggering mSCTP to send 321 Set-primary ASCONF chunk until a path which satisfies all three of 322 the above conditions appears. In order to avoid frequent changes of 323 primary path during handover, the primary path is not replaced until 324 a path which is stable enough is found even though the current one 325 becomes inadequate. In the proposed scheme, a stable path is defined 326 as the path that satisfies the above three conditions. The status of 327 an interface may be transformed to being stable by incoming L2SS, 328 L2HC, or IPAC signals. Having SS being equal to 0 or 1 for the 329 current primary path indicates that the current primary path has 330 become inadequate. Therefore, in this case, AMM triggers mSCTP to 331 send Set-primary ASCONF chunk as soon as interface satisfying all 332 three conditions of the primary path interface shows up. 334 If AMM receives an L2SS signal with S=5 or 6 for a certain interface, 335 AMM triggers mSCTP to send DELETEIP ASCONF chunk in order to delete 336 that interface. If the interface happens to be the current primary 337 path interface, AMM searches an alternative interface to serve as the 338 primary path. If there is no interface ready to replace the primary 339 path, triggering mSCTP to send DELETEIP ASCONF chunk should be 340 postponed. In this case, whenever mSCTP to send Set-primary ASCONF 341 chunk is triggered afterwards, sending DELETEIP ASCONF chunk for the 342 current primary path interface should be triggered together. 344 Security Considerations 346 This document discusses architecture of SCTP mobility support. The 347 associated security issues will be identified as further works go on. 349 Address Management for Mobile SCTP Handover October 2004 351 References 353 [1] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. 354 Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson, "Stream Control 355 Transmission Protocol", RFC 2960, October 2000. 357 [2] M. Riegel, M. Tuxen, "Mobile SCTP", Internet Draft, Internet 358 Engineering Task Force, August 2003. 360 [3] R.Stewart, "Stream Control Transmission Protocol(SCTP) Dynamic 361 Address Reconfiguration", Internet Draft, Internet Engineering 362 Task Force, September 2003. 364 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 365 Levels",RFC 2119, March 1997. 367 Author's Addresses 369 Moon Jeong Chang 370 mjchang@ewha.ac.kr 371 Ewha Womans Univ., Korea 373 Mee Jeong Lee 374 lmj@ewha.ac.kr 375 Ewha Womans Univ., Korea 377 Seok Joo Koh 378 sjkoh@cs.knu.ac.kr 379 Kyungbook National Univ., Korea 381 Full Copyright Statement 383 Copyright (C) The Internet Society (2004). This document is subject 384 to the rights, licenses and restrictions contained in BCP 78, and 385 except as set forth therein, the authors retain all their rights. 387 "This document and the information contained herein are provided on an 388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 390 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 391 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 392 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."