idnits 2.17.1 draft-yang-mif-connection-manager-impl-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 63 has weird spacing: '...ased on appli...' == Line 196 has weird spacing: '...ased on appli...' -- The document date (March 4, 2009) is 5532 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.hui-ip-multiple-connections-ps' is defined on line 227, but no explicit reference was found in the text == Unused Reference: 'I-D.blanchet-mif-problem-statement' is defined on line 232, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hui-ip-multiple-connections-ps-01 == Outdated reference: A later version (-01) exists of draft-blanchet-mif-problem-statement-00 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force J. Yang 2 Internet Draft Huawei 3 Intended status: Informational T. Sun 4 Expires: September 2009 China Mobile 5 S. Fan 6 March 4, 2009 8 Multi-interface Connection Manager Implementation and Requirements 9 draft-yang-mif-connection-manager-impl-req-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on September 4, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 46 This document presents the current implementation and problems 47 encountered in practice of the "Connection Manager." The problems to be 48 addressed exist within an operating system (OS) and platforms above OS. 49 This document focuses on levels above OS and presents the solutions, 50 especially for terminals with multiple interfaces. The scenarios of 51 interface selections are described. 52 Table of Contents 54 1. Introduction................................................2 55 2. Scenarios of multiple interfaces.............................2 56 3. Implementation of Connection Manager.........................3 57 3.1. Connection Handle.......................................3 58 3.2. Interface based connection handle.......................3 59 3.3. Interface and Access Node based connection handle........4 60 4. Problems Encountered In Practice.............................4 61 4.1. Pre-configuration of connection handle in UE............4 62 4.2. Automatic selections based on OS........................5 63 4.3. Automatic selections based on applications.............5 64 5. Conclusions.................................................5 65 6. Informative References.......................................5 66 Author's Addresses.............................................6 68 1. Introduction 70 Along with the development of variant access technologies, terminals 71 are capable of being connected with different networks through 72 multiple interfaces. These interfaces may belong to one or multiple 73 network domains. 75 Applications on terminals need to connect with appropriate network 76 domains through interfaces for the requirement of services, or on 77 behalf of users' preference. 79 This document describes an implementation of interface selection by 80 terminal applications, especially for accessing different network 81 domains. A connection management approach is presented. In addition, 82 the document also identifies the problems caused by different 83 implementations among variant vendors. This will lead to 84 difficulties on customization and development of terminal software. 86 2. Scenarios of multiple interfaces 88 A terminal may have multiple interfaces for network connection, e.g. 89 interfaces for connection with GRPS, WiFi, and BlueTooth. An 90 application sets up a network connection through one of these 91 interfaces. In fact, different network connections may correspond to 92 different network domains, in which different services are provided. 93 Therefore, an application needs to select the right interface for 94 network access. 96 3. Implementation of Connection Manager 98 3.1. Connection Handle 100 In terminal, applications use "connection handle" to dial-up or setup 101 connections. This connection handle can be defined in two ways: 103 o Interface based connection handle. 105 o Interface and access node based connection handle. 107 Application may select the appropriate connection handle to setup 108 connections according to configured policy. 110 3.2. Interface based connection handle 112 As illustrated in Figure 1, a UE have three types of interfaces, i.e., 113 GRPS, WiFi and Bluetooth. Each interface has one corresponding 114 connection handle as Connect 1, Connect 2 and Connect 3. When an 115 application on the terminal starts to connect with the networks, the 116 system selects the connection handle and configures parameters (e.g., 117 SSID, default Proxy, APN parameter) based on the specific requirement 118 of the application. 120 +----+ +------------------------------+ 121 | | GPRS |Connect1->GPRS internet GPRS | 122 | UE |------------| | 123 | | +------------------------------+ 124 | | 125 | | +------------------------------+ 126 | | WiFi |Connect2->WLAN internet WLAN | 127 | |------------| | 128 | | +------------------------------+ 129 | | 130 | | +------------------------------+ 131 | | BlueTooth |Connect3->Bluetooth_internet | 132 | |------------| | 133 | | +------------------------------+ 134 +----+ 136 Figure 1 Interface based connection handle. 138 3.3. Interface and Access Node based connection handle 140 As illustrated in Figure 2, a UE have three network interfaces, i.e., 141 GRPS, WiFi and Bluetooth for network access. As for these interface, 142 each has more than one connection handles. Therefore, a connection 143 handle is determined by the network interface type and access 144 parameters. When an application starts to connect with the network, 145 it may implement based on local policy to select the appropriate 146 connection handle for this specific application. 148 +----+ Connect1->APN= CMWAP:GRPS 149 | | GPRS / 150 | |--------| Connect2->APN=CMNET:GPRS 151 | | \ 152 | | Connect1->APN= CMWAP:GRPS 153 | | 154 | | Connect4->SSID=AP1:WLAN 155 | UE | WiFi / 156 | |--------| Connect5->SSID=AP2:WLAN 157 | | \ 158 | | Connect6->SSID=AP3:WLAN 159 | | 160 | | Connect7->deviceID = B1:BlueTooth 161 | |BlueTooth / 162 | |---------| 163 | | \Connect8->deviceID = B2:BlueTooth 164 +----+ 165 Figure 2 Interface and Node based connection handle. 167 4. Problems Encountered In Practice 169 As described in 3.2 and 3.3, a terminal may have multiple interfaces 170 and each interface may have multiple connection handles for different 171 access nodes. This section presents three implementation approaches 172 and the corresponding problems encountered. 174 4.1. Pre-configuration of connection handle in UE 176 Currently, connection handle of the applications have been pre- 177 configured on the OS. When UE connects to a network, it uses the pre- 178 configured parameters automatically. 180 The problem is that the pre-configured parameters are different among 181 different vendors. Therefore, the applications should be designed 182 into different versions for the variant parameter settings. Moreover, 183 when an application is downloaded or updated, UE should check whether 184 the application is applicable. These increase the complexities and 185 restricts the development of UE applicaitons. 187 4.2. Automatic selections based on OS 189 An application may rely on OS for the selection of a connection 190 handle which is one of the default connection handles maintained by 191 the OS. 193 The problem is that an OS may define one or several default 194 connection handles while, they may not suitable for all applications. 196 4.3. Automatic selections based on applications 198 All connection handles may be tried one by one by an application 199 until a connection is established. 201 The problem is this will cause a long time waiting and bad user 202 experience. Usually, successful connection may be identified in two 203 steps, i.e., network access success and service startup success. 204 Generally, one attempts to connect to a network may take about 3 205 second before time out. If every connect handle try 3 times, then it 206 may take about 9 second in all for network connection. After the link 207 is established, the application tries services according to 208 application layer protocol, such as registration etc. This may take 209 about 4-12 seconds before time out. Therefore, it takes about 7-21 210 second for an application getting connected with network. This will 211 not be a good experience for a user. 213 5. Conclusions 215 The suggestions for standardization are summarized as follows. 217 o Manager for multiple interfaces to achieve better user experiences. 219 o The connection manager is implemented through both network side 220 and terminal side. 222 o Reduces the complexity of new application installation for diverse 223 terminals. 225 6. Informative References 227 [I-D.hui-ip-multiple-connections-ps] Hui, M. and H. Deng, "Problem 228 Statement and Requirement of Simple IP Multi-homing of the 229 Host", draft-hui-ip-multiple-connections-ps-01 (work in 230 progress), November 2008. 232 [I-D.blanchet-mif-problem-statement] Blanchet, M., "Multiple 233 Interfaces Problem Statement", draft-blanchet-mif-problem- 234 statement-00 (work in progress), December 2008. 236 Author's Addresses 238 Jian Yang 239 Huawei Technology 240 Mobile department, Huawei Building 241 Haidian District, 242 Beijing 100086 243 China 244 Email: jian.yang@huawei.com 246 Tao Sun 247 China Moible 248 53A,Xibianmennei Ave., 249 Xuanwu District, 250 Beijing 100053 251 China 252 Email: suntao@chinamobile.com 254 Shunan Fan 255 Huawei Technology 256 Mobile department, Huawei Building 257 Haidian District, 258 Beijing 100086 259 China 260 Email: fanshunan@huawei.com