idnits 2.17.1 draft-paik-nemo-multihoming-problem-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: ---------------------------------------------------------------------------- == There are 2 instances 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 5 longer pages, the longest (page 1) being 62 lines 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.) -- The document date (October 17, 2003) is 7496 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) == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group E. K. Paik 3 Internet-Draft H. S. Cho 4 Expires: April 16, 2004 Seoul National University 5 T.Ernst 6 Keio University 7 October 17, 2003 9 Multihomed Mobile Networks Problem Statements 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 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 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 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 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document describes the needs for multihoming support in 41 network mobility (NEMO). Issues from designing and implementing 42 multihomed mobile networks are analyzed in terms of mutiple 43 connections management and usage. 45 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 47 2. Terms and Abbreviation . . . . . . . . . . . . . . . . . . . . 2 48 3. The need for Multihoming. . . . . . . . . . . . . . . .. . . . 2 49 4. Issue Statements . . . . . . . . . . . . . . . . . . . . . . . 3 50 5. Route Optimization Considerations. . . . . . . . . . . . . . . 4 51 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 4 52 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 5 55 1. Introduction 57 Multihomed mobile networks [1] provide advantage of enhancing 58 session continuity and load balancing to the whole mobile networks. 60 NEMO is based on mobile IPv6 [2], but multihoming in NEMO raises 61 new problems that do not arise in mobile IPv6. 63 In this document, a case is made for why multihoming is needed for 64 NEMO and what the prerequisite issues for developing multihomed 65 mobile networks. 67 2. Terms and Abbreviation 69 It is assumed that readers are familar with the terminologies and 70 abbreviations as defined in [1] and [2], and classifications in 71 [3]. 73 3. The need for multihoming 75 There are two basic motivations for multihoming. 77 1) Multihomed mobile networks enhance the session preservation of 78 the mobile router (MR) used for mobile network nodes (MNNs). Since 79 a wireless link is not as stable as a wired link, session 80 preservation is an important issue in the case of mobile networks. 81 Especially in the case of NEMO, the session preservation of the MR 82 concerns not only the MR itself but also the one or more MNNs 83 behind it. If the MR can not maintain a continuous session, more 84 than one or more MNNs will not be able maintain their sessions 85 either. As the number of MNNs increases, the impact of MR session 86 disconnection also increases. Therefore the session preservation of 87 the MR is critical in NEMO. 89 2) Multihomed mobile networks share traffic load more efficiently 90 by selecting the best available connection or enabling multiple 91 connections simultaneously. Since all traffic goes through the MR 92 in a mobile network, load sharing at the MR is critical. 94 4. Issue Statements 96 4.1 Connection availability 98 Multiple connections of MRs can be used simultaneously or one at a 99 time. 101 1) When multiple connections are used simultaneously, the mode of 102 operation can be either primary-secondary or peer-to-peer. These 103 configurations can be useful especially for large mobile networks, 104 but there are many implementation issues which need to be 105 addressed, e.g. which connection will be selected for each traffic 106 folw that goes into/out of the mobile network ? 108 2) When only one connection can be used at a time, e.g. in the case 109 where a single connection has to substitute for all of the other 110 failed connections, a connection selection mechanism is needed. The 111 connection selection can depend on which connection is available at 112 that time. 114 4.2 Connection selection 116 4.2.1 Who selects a connection ? 118 The connection can be selected by the home agent (HA), the MR, 119 and/or the MNN. 121 1) The HA can select a connection based on the binding update 122 information in the binding cache. 124 2) The MR can select a connection since the MR is one of the main 125 bodies of the connection. 127 3) The MNN should be able to select a connection, e.g. in case 128 where a user wants to select a particular access technology among 129 the available technologies for reasons of cost or data rate. 131 4) A hybrid mechanism should be also available, e.g. one in which 132 the HA, the MR, and/or the MNN coordinate to select a connection. 134 4.2.2 Connection selection problem analysis 136 Connection selection problem can be analyzed as follows. 138 1) Selection by the HA: HAs coordination is needed when there are 139 multiple HAs. 141 2) Selection by the MR: This should allow communication between MRs 142 in the case where there is multihoming with multiple MRs. [4] is an 143 examples of MRs coordination for selecting a connection. 145 3) Selection by the MNN: The MNN selects an MR when there are 146 multiple MRs. For example, it can be a problem of prefix selection 147 when MRs advertise different prefixes. 149 The MNN selects a HA when there are multiple HAs. For example, it 150 can be a problem of Internet service provider (ISP) selection when 151 each HA is associated with different ISP. Multiple HAs can be 152 associated with different locations, access technologies, ISPs, and 153 so on. 155 4.3 Scalability 157 Should a new solution meets the all the eight configurations and 158 the scenarios mentioned in [3]? 160 5. Route Optimization Considerations 162 RO problems in multihomed mobile networks are dependant on how the 163 connections are available and selected. 165 1) In case of multiple HAs and HoAs, new route optimization may be 166 possible by routing between CN and multiple HAs with different 167 HoAs. 169 2) When multiple connections are available simultaneously, how the 170 CN knows about the availability and optimizes route ? 172 6. Security Considerations 174 Security threats are dependant on how the connections are available 175 and selected. So we will add security problems when they are 176 encountered as the basic multihoming issues in NEMO are analyzed. 178 References 180 [1] Ernst, T. and H. Lach, "Network Mobility Support 181 Terminology", Internet Draft: 182 draft-ietf-nemo-terminology-00.txt, Work In Progress, 183 May 2003. 185 [2] Johnson, D. B., Perkins, C. E. and Arkko, J., "Mobility 186 Support in IPv6", Internet Draft: 187 draft-ietf-mobileip-ipv6-24.txt, Work In Progress, 188 June 2003. 190 [3] C. Ng, J. Charbon, �Multi-Homing Issues in Bi-directional 191 Tunneling,� Internet Draft: 193 draft-ng-nemo-multihoming-issues-01.txt, Work In Progress, 194 May 2003. 196 [4] Eun Kyoung Paik and Yanghee Choi, "Management of Multiple 197 Mobile Routers for Continuous Multimedia in Mobile WLANs," 198 Lecture Notes in Computer Science, Springer-Verlag, 199 vol. 2532, Dec. 2002, pp.680-687. 201 Authors' Addresses 203 Eun Kyoung Paik 204 Multimedia and Computer Communications Lab. 205 Seoul National University 206 ENG4190, School of Electronic Engineering and Computer Science 207 Seoul National University 208 Seoul 151-744, Korea 210 Phone: +82 2 880 1832 211 Fax: +82 2 872 2045 212 EMail: eun@mmlab.snu.ac.kr 213 URL: htpp://mmlab.snu.ac.kr/~eun 215 Ho-Sik Cho 216 Multimedia and Computer Communications Lab. 217 Seoul National University 218 ENG4190, School of Electronic Engineering and Computer Science 219 Seoul National University 220 Seoul 151-744, Korea 222 Phone: +82 2 880 1832 223 Fax: +82 2 872 2045 224 EMail: hscho@mmlab.snu.ac.kr 225 URL: htpp://mmlab.snu.ac.kr/~hscho 227 Thierry Ernst 228 Jun Murai Lab. 229 Keio University K2 Town Campus 230 1488-8 Ogura, Saiwai-ku, Kawasaki 231 Kanagawa 212-0054 232 Japan 234 Phone: +81-44-580-1600 235 EMail: ernst@sfc.wide.ad.jp 236 URL: htpp://www.sfc.wide.ad.jp/~ernst