idnits 2.17.1 draft-dreibholz-rserpool-applic-mobility-00.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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 276. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) 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.) -- The document date (Mar 24, 2006) is 6601 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) == Unused Reference: '2' is defined on line 164, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 168, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 172, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 176, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 189, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 224, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 228, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2719 (ref. '5') ** Obsolete normative reference: RFC 2960 (ref. '6') (Obsoleted by RFC 4960) ** Downref: Normative reference to an Informational RFC: RFC 3237 (ref. '7') ** Downref: Normative reference to an Informational RFC: RFC 3257 (ref. '8') ** Obsolete normative reference: RFC 3309 (ref. '9') (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 3344 (ref. '10') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (ref. '11') (Obsoleted by RFC 6275) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-14 == Outdated reference: A later version (-12) exists of draft-ietf-rserpool-arch-10 ** Downref: Normative reference to an Informational draft: draft-ietf-rserpool-arch (ref. '13') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-13 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-asap (ref. '14') == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-13 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-enrp (ref. '15') == Outdated reference: A later version (-18) exists of draft-ietf-rserpool-common-param-10 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-common-param (ref. '16') == Outdated reference: A later version (-10) exists of draft-ietf-rserpool-policies-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-rserpool-policies (ref. '17') -- Possible downref: Normative reference to a draft: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' Summary: 17 errors (**), 0 flaws (~~), 15 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Dreibholz 3 Internet-Draft J. Pulinthanath 4 Expires: September 25, 2006 University of Duisburg-Essen 5 Mar 24, 2006 7 Applicability of Reliable Server Pooling for SCTP-Based Endpoint 8 Mobility 9 draft-dreibholz-rserpool-applic-mobility-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 25, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes a novel mobility concept based on a 43 combination of SCTP with Dynamic Address Reconfiguration extension 44 and Reliable Server Pooling (RSerPool). 46 1. Introduction 48 An increasing amount of Internet devices is getting mobile. 49 Therefore, there is a growing demand for software solutions allowing 50 for a seamless handover of communication sessions between multiple 51 networks, e.g. to allow for a laptop or PDA to use a fast Ethernet 52 connection when available, hand over to a WLAN when moving and hand 53 over again to UMTS when the WLAN becomes unreachable - without 54 interrupting the running communication sessions. 56 Mobility handling is a deficiency of the common IP-based networks. 57 Most of the available solutions are based on the network layer. The 58 disadvantage of such solutions is that fundamental changes in the 59 network infrastructure are needed. Therefore, we propose a new 60 solution based on the upper layers to overcome these disadvantages. 61 In this document, we present our mobility solution based on the SCTP 62 protocol with Dynamic Address Reconfiguration extension and Reliable 63 Server Pooling (RSerPool). 65 2. Existing Mobility Solutions 67 2.1. Mobile IP and Mobile IPv6 69 In the concept of Mobile IP [10] every node must register to a Home- 70 Agent (HA) in its own home network. Then, the nodes are reachable 71 under their home addresses managed by the HA. When a node leaves its 72 home network, it must also register at a Foreign Agent (FA) in the 73 new network. After that, a tunnel is established between the HA and 74 the FA. Any traffic to the mobile node is then tunneled by its HA to 75 the FA and forwarded by the FA to the node itself. Clearly, the 76 detour of all traffic via HA and FA is inefficient and results in an 77 increased transmission delay. 79 Mobile IPv6 [11] is an extension of Mobile IP. In Mobile IPv6, the 80 FA is not needed. The packets will be tunneled from the HA to the 81 Gateway Router in the foreign network, which forwards the packets to 82 the endpoint. The inefficiency due to the detour of traffic as 83 described for Mobile IP remains. 85 2.2. SCTP with Dynamic Address Reconfiguration 87 Using the SCTP protocol (see [6], [9]) together with its Dynamic 88 Address Reconfiguration extension (Add-IP, see [12]), it is possible 89 for a mobile endpoint to inform its peer on address changes. That 90 is, when a moving mobile client gets in the vicinity of an additional 91 radio station, it sends an "ASCONF Add Address Request" to tell its 92 peer that it is now reachable under an additional network-layer 93 address. After that, the peer endpoint can use this additional 94 address for a new SCTP path. When the first radio station becomes 95 unreachable, the node can send an "ASCONF Delete Address Request" to 96 the peer endpoint. After that, the peer removes the corresponding 97 SCTP path to the unusable network-layer address. 99 The following two cases for handovers are possible: 101 o Make-before-Break: An additional SCTP path can be used before the 102 original path becomes unusable. This case is trivial, since there 103 is a continuous connectivity. 105 o Break-before-Make: The original SCTP path becomes unusable before 106 a new SCTP path can be used. For the case that only one endpoint 107 performs a handover procedure at the same time, the mobile 108 endpoint can always use Add-IP to communicate its new address to 109 its peer endpoint. However, when both endpoints perform a 110 handover simultaneously, no endpoint is able to tell its 111 corresponding peer the new address. 113 3. Solutions for Simultaneous Handovers 115 3.1. SCTP with Add-IP and Mobile-IP 117 Using SCTP with Add-IP and Mobile IP/Mobile IPv6, the ASCONF messages 118 will be sent to the home address of the peer node. That is, even 119 when both nodes are mobile, each endpoint is able to reach its peer 120 endpoint using the corresponding home address. However, this 121 solution still requires the full Mobile IP/Mobile IPv6 122 infrastructure. 124 3.2. SCTP with Add-IP and RSerPool 126 Using RSerPool (see [7], [13], [14], [15], [17], [16]), at least one 127 node registers as a Pool Element (PE) at an ENRP server under a Pool 128 Handle (PH) known to both endpoints. Upon handover, it is simply 129 necessary for the PE endpoint to re-register, i.e. to update its 130 registration with its new address. The other endpoint can - in the 131 role of a Pool User (PU) - ask an ENRP server for its peer node's new 132 addresses. After the new address is known, it is able to create a 133 new SCTP path and continue the communication. 135 The usage of RSerPool to provide support for mobile endpoints 136 provides the following advantages: 138 o Simplicity: No Mobile IP/Mobile IPv6 infrastructure is needed. In 139 particular, it is not necessary that the providers of used 140 networks (e.g. public WLAN access points, UMTS providers, etc.) 141 provide any support for the mobility solution. 143 o Efficiency: No tunneling of traffic is necessary. 145 o Deployability: All major SCTP implementations already support the 146 Dynamic Address Reconfiguration extension. It is only necessary 147 to provide support for RSerPool, e.g. in the form of a userspace 148 library, which is much easier to deploy than kernel extensions. 150 o Flexibility: RSerPool provides a complete session layer. That is, 151 providing applications on top of RSerPool makes the support for 152 high availability simple. 154 A more detailed description of our approach for endpoint mobility, as 155 well as a performance analysis using a prototype implementation, can 156 be found in our paper [1]. 158 4. Normative References 160 [1] Dreibholz, T., Jungmaier, A., and M. Tuexen, "A new Scheme for 161 IP-based Internet Mobility", Proceedings of the 28th IEEE Local 162 Computer Networks Conference, November 2003. 164 [2] Dreibholz, T., "An efficient approach for state sharing in 165 server pools", Proceedings of the 27th IEEE Local Computer 166 Networks Conference, October 2002. 168 [3] Dreibholz, T. and E. Rathgeb, "An Application Demonstration of 169 the Reliable Server Pooling Framework", Proceedings of the 24th 170 IEEE Infocom, March 2005. 172 [4] Dreibholz, T. and E. Rathgeb, "Implementing the Reliable Server 173 Pooling Framework", Proceedings of the 8th IEEE International 174 Conference on Telecommunications, June 2005. 176 [5] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., 177 Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework 178 Architecture for Signaling Transport", RFC 2719, October 1999. 180 [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 181 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. 182 Paxson, "Stream Control Transmission Protocol", RFC 2960, 183 October 2000. 185 [7] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, 186 J., and M. Stillman, "Requirements for Reliable Server 187 Pooling", RFC 3237, January 2002. 189 [8] Coene, L., "Stream Control Transmission Protocol Applicability 190 Statement", RFC 3257, April 2002. 192 [9] Stone, J., Stewart, R., and D. Otis, "Stream Control 193 Transmission Protocol (SCTP) Checksum Change", RFC 3309, 194 September 2002. 196 [10] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 197 August 2002. 199 [11] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 200 IPv6", RFC 3775, June 2004. 202 [12] Stewart, R., "Stream Control Transmission Protocol (SCTP) 203 Dynamic Address Reconfiguration", 204 draft-ietf-tsvwg-addip-sctp-14 (work in progress), March 2006. 206 [13] Tuexen, M., "Architecture for Reliable Server Pooling", 207 draft-ietf-rserpool-arch-10 (work in progress), July 2005. 209 [14] Stewart, R., "Aggregate Server Access Protocol (ASAP)", 210 draft-ietf-rserpool-asap-13 (work in progress), February 2006. 212 [15] Stewart, R., "Endpoint Handlespace Redundancy Protocol (ENRP)", 213 draft-ietf-rserpool-enrp-13 (work in progress), February 2006. 215 [16] Stewart, R., "Aggregate Server Access Protocol (ASAP) and 216 Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", 217 draft-ietf-rserpool-common-param-10 (work in progress), 218 February 2006. 220 [17] Tuexen, M. and T. Dreibholz, "Reliable Server Pooling 221 Policies", draft-ietf-rserpool-policies-02 (work in progress), 222 February 2006. 224 [18] Conrad, P. and P. Lei, "Services Provided By Reliable Server 225 Pooling", draft-ietf-rserpool-service-02 (work in progress), 226 October 2005. 228 [19] Dreibholz, T., "Thomas Dreibholz's RSerPool Page", 229 URL: http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/. 231 Authors' Addresses 233 Thomas Dreibholz 234 University of Duisburg-Essen, Institute for Experimental Mathematics 235 Ellernstrasse 29 236 45326 Essen, Nordrhein-Westfalen 237 Germany 239 Phone: +49-201-1837637 240 Fax: +49-201-1837673 241 Email: dreibh@exp-math.uni-essen.de 242 URI: http://www.exp-math.uni-essen.de/~dreibh/ 244 Jobin Pulinthanath 245 University of Duisburg-Essen, Institute for Experimental Mathematics 246 Ellernstrasse 29 247 45326 Essen, Nordrhein-Westfalen 248 Germany 250 Phone: +49-201-1837637 251 Fax: +49-201-1837673 252 Email: jp@exp-math.uni-essen.de 254 Intellectual Property Statement 256 The IETF takes no position regarding the validity or scope of any 257 Intellectual Property Rights or other rights that might be claimed to 258 pertain to the implementation or use of the technology described in 259 this document or the extent to which any license under such rights 260 might or might not be available; nor does it represent that it has 261 made any independent effort to identify any such rights. Information 262 on the procedures with respect to rights in RFC documents can be 263 found in BCP 78 and BCP 79. 265 Copies of IPR disclosures made to the IETF Secretariat and any 266 assurances of licenses to be made available, or the result of an 267 attempt made to obtain a general license or permission for the use of 268 such proprietary rights by implementers or users of this 269 specification can be obtained from the IETF on-line IPR repository at 270 http://www.ietf.org/ipr. 272 The IETF invites any interested party to bring to its attention any 273 copyrights, patents or patent applications, or other proprietary 274 rights that may cover technology that may be required to implement 275 this standard. Please address the information to the IETF at 276 ietf-ipr@ietf.org. 278 Disclaimer of Validity 280 This document and the information contained herein are provided on an 281 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 282 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 283 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 284 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 285 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 288 Copyright Statement 290 Copyright (C) The Internet Society (2006). This document is subject 291 to the rights, licenses and restrictions contained in BCP 78, and 292 except as set forth therein, the authors retain all their rights. 294 Acknowledgment 296 Funding for the RFC Editor function is currently provided by the 297 Internet Society.