idnits 2.17.1 draft-sjkoh-mobile-sctp-handover-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'SCTP-Multi' on line 366 ** Obsolete normative reference: RFC 2960 (ref. '1') (Obsoleted by RFC 4960) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-05 == Outdated reference: A later version (-09) exists of draft-riegel-tuexen-mobile-sctp-01 == Outdated reference: A later version (-04) exists of draft-coene-sctp-multihome-03 ** Obsolete normative reference: RFC 3344 (ref. '7') (Obsoleted by RFC 5944) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-20 == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-04 -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? == Outdated reference: A later version (-04) exists of draft-sjkoh-mobile-sctp-mobileip-00 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Seok Joo Koh 2 Internet Engineering Task Force Hee Young Jung 3 Category: Informational Sung Han Kim 4 February 2003 Jun Seob Lee 5 Expires August 2003 ETRI 7 Use of SCTP for Seamless Handover 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are valid for a maximum of six months and may be 17 updated, replaced, or obsoleted by other documents at any time. It 18 is inappropriate to use Internet-Drafts as reference material or to 19 cite them other than as a "work in progress". 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 Abstract 28 The Stream Control Transmission Protocol (SCTP) is a new reliable 29 transport protocol that provides the multihoming feature. Without 30 support of routers in the networks, the SCTP with the ADDIP 31 extension (called mobile SCTP) can be used to provide seamless 32 handover for the mobile host that is changing its IP subnetworks 33 during the session. In the present form, the use of mobile SCTP is 34 targeted for handover of the mobile sessions that are originated 35 from the mobile clients (located in mobile networks) toward the 36 fixed servers (located in the fixed networks). The support for the 37 opposite directional session (initiated by fixed node to mobile 38 node) requires an additional location management scheme such as 39 Mobile IP. In this document, we discuss the generic procedures for 40 seamless handover of mobile SCTP and the concerned implementation 41 issues. 43 1. Introduction 45 SCTP (Stream Control Transmission Protocol), as defined in RFC 2960 46 [1, 2, 3], is a reliable transport layer protocol. The SCTP is 47 featured multi-streaming and multihoming, differently from TCP. It 48 is noted that the multihoming feature of SCTP enables the SCTP to 49 support the IP mobility. 51 More specifically, the SCTP with the ADDIP extension [4], which is 52 called mobile SCTP (mSCTP) in this document, can be used to provide 53 seamless handover for mobile hosts that are moving into different 54 IP network regions during the active session [5, 6]. 56 The mobile SCTP may be used as an alternative scheme against the 57 handover schemes based on Mobile IP [7, 8, 9, 10]. Differently from 58 the Mobile IP based handover schemes, which rely on the support of 59 network routers for tunneling between access routers, the mobile 60 SCTP provides the handover management at the transport layer 61 without help of routers. 63 The mobile SCTP, in the present form, is targeted for the client- 64 server service model, in which the mobile client initiates an SCTP 65 session with the fixed server. To be applicable for the peer-to- 66 peer model, in which a fixed node is allowed to initiate an SCTP 67 session with a mobile node, the mSCTP must be used along with an 68 additional location management scheme such as Mobile IP, which is 69 discussed in [11]. 71 This document is intended to continue a discussion to explore the 72 use of SCTP for IP mobility support. Please send comments to the 73 mailing list . To subscribe to this mailing list, 74 please send a mail to . 76 1.1 Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 80 this document are to be interpreted as described in RFC 2119. 82 1.2 Acknowledgement 84 The authors would like to give special thanks to the following 85 people in ETRI for their valuable comments: 87 Jae Hong Min 88 Jung Soo Park 89 Juyoung Park 90 Mee Jung Lee 92 2. Use of Mobile SCTP for IP Mobility Support 94 In this section, we discuss motivations on the use of SCTP for IP 95 mobility support, in the viewpoint of IP mobility management issues 96 and SCTP multihoming feature. 98 2.1 IP Mobility Management Issues 100 At the time of the fixed-mobile convergence trends, the IP mobility 101 management issues have been focused and are regarded as a core 102 technology required for providing seamless mobility in the wireless 103 mobile networks such as WLAN, 3G Cellular. 105 IP mobility management issues can be classified into Location 106 Management and Handover Management as follows: 108 a. Location Management 110 Location Management is used to identify the current location of 111 mobile nodes and also to keep track of the their location 112 changes as they move on. 114 In Mobile IP [7, 8], the mobility agents such as Home Agent (HA) 115 and Foreign Agent (only for IPv4) are employed for location 116 management as well as data transport. In the schemes, Home 117 Address (HoA) and Care-of Address (CoA) are used for a terminal 118 identifier and a location identifier of the IP host, 119 respectively. For location management, the Mobile IP uses the 120 binding update messages, in which a mobile node has to inform 121 its current location (CoA) to its HA. 123 b. Handover Management 125 The handover management is targeted to provide the mobile hosts 126 for seamless handover whenever they change their point of 127 attachment to IP networks (as represented by cell regions or IP 128 subnets). The main objective of the handover management is to 129 minimize the service disruption due to data loss and/or handover 130 latency during handover. 132 In Mobile IP, the Low Latency handover for MIPv4 (LMIPv4) [9] 133 and Fast Handover for MIPv6 (FMIPv6) [10] schemes have been 134 designed for handover management. These schemes rely on the 135 tunneling between old and new access routers for seamless 136 handover. 138 The mobile SCTP can be used as an alternative scheme against LMIPv4 139 and FMIPv6 for seamless handover. Differently from the Mobile IP 140 handover schemes that rely on the help of network routers for 141 tunneling between access routers, the mobile SCTP provides the 142 handover management at the transport layer without help of routers. 144 2.2 SCTP Multihoming Feature 146 The SCTP intrinsically provides the multihoming feature [1, 2, 3], 147 in which a mobile node is allowed to simultaneously bind multiple 148 IP addresses to its network interface. 150 The recent works on the SCTP include the ADDIP extension [4]. The 151 ADDIP extension enables the SCTP to add, delete and change the IP 152 addresses during active SCTP association. 154 In this document, the SCTP implementation with the ADDIP extension 155 is called the mobile SCTP (mSCTP) [5]. The mSCTP can be used for 156 seamless handover while the mobile node is moving into different IP 157 network regions over the session period. This document aims at 158 discussing the use of mSCTP for seamless handover, which includes 159 the specific handover procedures and associated implementation 160 issues. 162 2.3 Session Type considered in Mobile SCTP 164 Sessions considered in mobile communications can be classified into 165 the following two types: 167 a. Session originated from mobile host toward fixed host 169 b. Session originated from fixed host toward mobile host 171 The mobile sessions in (a) seem to be a natural extension of the 172 client-server model, in which the mobile host originating the 173 session can be viewed as a client, while the counter endpoint will 174 function as a server. 176 On the other hand, the case (b) requires the additional location 177 management functionality for the session originator to find the 178 current location of the mobile host and to keep track of the 179 location changes, which has so far been addressed by Mobile IP [7, 180 8]. 182 The mobile SCTP, in the present form, is targeted for seamless 183 handover of mobile session associated with the case (a). To support 184 the session type of the case (b), the mSCTP must be used along with 185 an additional location management scheme such as Mobile IP, which 186 is discussed in [11]. 188 3. Generic Procedures for Seamless Handover 190 The mobile SCTP (mSCTP) can be used to provide seamless handover 191 for mobile client who is roaming between two different IP networks 192 characterized by different IP address prefixes. 194 In this section, we describe the generic algorithm of mobile SCTP 195 for handover in the procedural manner, which is designed based on 196 the scheme in [5]. 198 More specifically, we consider a mobile client (MC) that initiates 199 an SCTP association with a fixed server (FS), and then moves from 200 Location A (2.2.2.x domain) to Location B (3.3.3.x domain), as 201 shown in Figure 1. Figure 1 illustrates an example of the use of 202 mobile SCTP for seamless handover in IPv4 networks. Based on this 203 figure, the handover procedures are described in the succeeding 204 sections. 206 [1.1.1.2] 207 +----+ 208 | FS | 209 +----+ 210 || 211 ########## 212 # Router # [1.1.1.1] 213 ########## 214 || 215 ******* 216 *** *** 217 ** ** 218 ** Internet ** 219 ** ** 220 ** ** 221 *** *** 222 || ******** || 223 || || 224 ####### ####### 225 [2.2.2.1] # AR1 # # AR2 # [3.3.3.1] 226 ####### ####### 227 | | 228 Location A | | Location B 229 | | 230 +----+ +----+ 231 | MC |=========>| MC | 232 +----+ +----+ 233 [2.2.2.2] [3.3.3.2] 235 Figure 1. Example of Mobile SCTP for Seamless Handover 237 3.1 Session Initiation by Mobile Client 239 We assume that the MC initiates an SCTP association with the FS. 240 The resulting SCTP association has the set of IP addresses with 241 [2.2.2.2] for MC and [1.1.1.2] for FS. It is also assumed that the 242 MC can get an IP address ([2.2.2.2]) with help of a suitable 243 address configuration mechanism such as DHCP or stateless address 244 auto-configuration (in IPv6). 246 Note that the FS is in the single homing with [1.1.1.2], which will 247 be discussed later more in details. The MC is also in single homing 248 state, in which the IP address [2.2.2.2] is set to its primary IP 249 address in the SCTP initiation process. 251 3.2 Obtaining an IP address for a new location 253 Let us assume that the MC moves from Location A to Location B. In 254 this phase, we also need to assume that the MC can obtain a new IP 255 address belonging to the Location B, which may be possible with 256 help of the DHCP or IPv6 address auto-configuration capability in 257 the Location B. 259 Obtaining a new IP address may also rely on the support of the 260 wireless signaling control at the physical layer, in order for the 261 MC to get the IP address information via IP control packets from 262 the Location B. 264 By SCTP implementations, the newly obtained IP address ([3.3.3.2] 265 in the example) MUST be signaled or informed to the SCTP protocol 266 stack, and then the SCTP will bind the new IP address to the 267 existing IP address list managed by the SCTP association. 269 3.3 Adding the new IP address to the SCTP association 271 After obtaining a new IP address, the SCTP of MC MUST inform the 272 Fixed Server about the new IP address by sending Address 273 Configuration Change (ASCONF) Chunk to the FS. The MC may receive 274 the corresponding ASCONF-ACK Chunk from the FS. 276 The MC is now in the dual homing state. The old IP address is still 277 used as the primary address ([2.2.2.2] in the example), while the 278 new IP address ([3.3.3.2] in the example) will be used as the 279 backup path against the data losses by the SCTP in the FS side. 281 3.4 Changing the Primary IP address 283 While the MC continues to move toward the Location B, it needs to 284 change its primary IP address to the new IP address according at an 285 appropriate rule. Actually, the configuration of a specific rule 286 for changing the primary IP address is a challenging issue of the 287 mobile SCTP. 289 Some of the possible rules for triggering the primary IP address 290 change are listed below: 292 a. As soon as a new IP address is detected 294 When a new IP address is detected, the MC may trigger the 295 primary IP address change by sending the ASCONF Chunk 296 containing the parameter. 298 This choice may be preferred in terms of the handover 299 latency, in particular, for the fast-moving MC. However, it 300 is less suitable when the MC shows a so-called oscillation 301 (or ping-pong) behavior across those two locations. 303 b. By using a threshold of the data losses experienced 305 This rule is applied when the SCTP of MC has a pre- 306 configured threshold on data loss. If the number or rate of 307 the lost data chunks is greater than the threshold value, 308 and if the MC is in the multi-homing state, then it can 309 trigger the primary address change toward the FS. 311 The selection of an appropriate threshold value is for 312 further study, and may depend on implementations and the 313 mobility behavior considered. 315 c. By using an explicit indication from the underlying layer 316 (e.g., by comparison of strength of the detected wireless 317 signals) 319 If the underlying physical layer can detect and compare the 320 signal strength of the physical media, and also inform the 321 SCTP about a certain indication (possibly by using a up- 322 call), then the MC may trigger the primary address change 323 according to the indication. 325 This rule is a more preferred choice, but seems to depend on 326 the wireless system concerned and its implementations. 328 If once the primary address is changed, the FS will send the 329 upcoming data over the new primary IP address, while the backup 330 (old) address may be used to recover the lost data chunks. 332 3.5 Deleting the old IP address from the SCTP association 334 As the MC progresses to move toward the Location B, if the old IP 335 address gets inactive, the MC MUST delete the IP address from the 336 address list. 338 The rule for determining that the IP address is inactive may also 339 be implemented by using additional information from the underlying 340 network or physical layer, as done in the previous step (for 341 changing the primary address.) 343 3.6 Repeating the handover procedures 345 The procedural steps for seamless handover described above, from 346 3.1 through 3.5, will be repeated whenever the MC moves to a new 347 location, until the SCTP association will be released. 349 4. Implementation Issues on Mobile SCTP 351 4.1 Requirement for Mobile SCTP 353 The only requirement for providing the seamless handover based on 354 SCTP is that the MC and FS hosts are equipped with the Mobile SCTP 355 implementations, (i.e., SCTP with ADDIP extension.) 357 All the others issues described below depend on implementations. 359 4.2 Number of IP addresses used by Fixed Server 361 In this document, we assume that the FS is in the single homing. As 362 an alternative, the FS may assign two or more IP addresses to the 363 network interface, so as to enable easy distinction of the two 364 links at the MC. This allows SCTP to represent different links by 365 different entries in the host routing table of the MC. For more 366 information on this issue, please refer to [mSCTP] and [SCTP-Multi]. 368 4.3 Dynamic IP address configuration 370 The basic assumption for seamless handover to a new IP subnet 371 region is that the MC is able to obtain a new IP address from the 372 new location. Typically, this will be implemented by using DHCP in 373 IPv4 networks and DHCPv6 or Stateless address auto-configuration in 374 IPv6 networks. 376 The handover latency incurred for obtaining the new IP address via 377 DHCP or IPv6 needs to be examined by experiments. The concerned 378 handover latency also includes the delay required for the handover 379 delay between the wireless links. 381 4.4 AAA Functionality 383 It is envisioned that the deployment of mSCTP will be done along 384 with the appropriate AAA server in the respective access network 385 domains. The AAA server is used to authenticate and the MC in the 386 locations, and also to authorize the new IP address configuration 387 via DHCP and IPv6 stateless configuration. However, this issue is 388 outside the scope of mSCTP. 390 4.5 Link Layer Support of Multi-homing 392 It is noted that the multi-homing capability for Mobile Client is 393 not easy to support, which actually depends on the characteristics 394 of the wireless links considered such as Wireless LAN (WLAN) or 3G 395 Cellular. 397 In a certain system such as WLAN, it may not be allowed for an MC 398 to simultaneously bind two different Access Points (APs), in which 399 the multi-homing is not easy to support. On the other hand, the 400 wireless links used in Cellular systems are expected to easily 401 support the link-level multi-homing features. 403 The multi-homing feature enables the mSCTP to support seamless 404 handover by simultaneous binding of two different addresses while 405 staying the overlapping region. Time interval for an MC to stay in 406 the overlapping region will give impact on the performance of the 407 handover procedures. 409 4.6 Measuring the Wireless Signal Strength at the Physical Layer 411 Part of seamless handover based on mSCTP depends on the support of 412 the underlying physical and link layers to measure the wireless 413 signal strength. The measured signal strength information can 414 helpfully used for the SCTP to trigger the addition and deletion of 415 IP addresses, and the change of the primary address. The handover 416 performance will depend on such capability in terms of data loss 417 and delay during handover. 419 5. Security Considerations 421 This document discusses the use of mobile SCTP for seamless 422 handover. The concerned security issues may be identified as the 423 further works go on. 425 6. References 427 [1] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 428 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 429 "Stream Control Transmission Protocol", RFC 2960, October 2000 431 [2] Ong, L. and Yoakum, J., "An Introduction to the Stream Control 432 Transmission Protocol (SCTP)", RFC 3286, May 2002 434 [3] Coene, L., "Stream Control Transmission Protocol Applicability 435 Statement", RFC 3257, April 2002 437 [4] Stewart, R., "Stream Control Transmission Protocol (SCTP) 438 Dynamic Address Reconfiguration", draft-ietf-tsvwg-addip-sctp- 439 05, May 2002 441 [5] Riegel, M. and Tuexen M., "Mobile SCTP", draft-riegel-tuexen- 442 mobile-sctp-01, August 2002 444 [6] Coene, L. (ed.), "Multihoming issues in the SCTP", draft-coene- 445 sctp-multihome-03, February 2002 447 [7] Perkins, C. (ed.), "IP Mobility Support for IPv4", RFC 3344, 448 August 2002 450 [8] Johnson, D., et al., "Mobility Support in IPv6", draft-ietf- 451 mobileip-ipv6-20, January 2003 453 [9] Malki, K. L., et al., "Low Latency Handoffs in Mobile IPv4", 454 draft-ietf-mobileip-lowlatency-handoffs-v4-04, June 2002 456 [10] Koodli, R., et al., "Fast Handovers for Mobile IPv6", draft- 457 ietf-mobileip-fast-mipv6-05, September 2002 459 [11] Koh, S. J., Jung, H. Y., Kim, S. H. and Lee, J. S., "SCTP with 460 Mobile IP for IP Mobility Support", draft-sjkoh-mobile-sctp- 461 mobileip-00, February 2003 463 Authors' Addresses 465 Seok Joo Koh 466 sjkoh@etri.re.kr 467 361 Kajung-Dong Yusung-Gu, Taejon 305-350, Korea 469 Hee Young Jung 470 hyjung@etri.re.kr 471 361 Kajung-Dong Yusung-Gu, Taejon 305-350, Korea 473 Sung Han Kim 474 sh-kim@etri.re.kr 475 361 Kajung-Dong Yusung-Gu, Taejon 305-350, Korea 477 Jun Seob Lee 478 juns@etri.re.kr 479 361 Kajung-Dong Yusung-Gu, Taejon 305-350, Korea 481 Full Copyright Statement 483 Copyright (C) The Internet Society (2003). All Rights Reserved. 485 This document and translations of it may be copied and furnished to 486 others, and derivative works that comment on or otherwise explain it 487 or assist in its implementation may be prepared, copied, published 488 and distributed, in whole or in part, without restriction of any 489 kind, provided that the above copyright notice and this paragraph are 490 included on all such copies and derivative works. However, this 491 document itself may not be modified in any way, such as by removing 492 the copyright notice or references to the Internet Society or other 493 Internet organizations, except as needed for the purpose of 494 developing Internet standards in which case the procedures for 495 copyrights defined in the Internet languages other than English. 497 The limited permissions granted above are perpetual and will not be 498 revoked by the Internet Society or its successors or assigns. 500 This document and the information contained herein is provided on an 501 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 502 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 503 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 504 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 505 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."