idnits 2.17.1 draft-baba-iot-interconnection-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 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 IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2096 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Pattern 1' on line 358 -- Looks like a reference, but probably isn't: 'Pattern 4' on line 365 -- Looks like a reference, but probably isn't: 'Pattern 2' on line 361 -- Looks like a reference, but probably isn't: 'Pattern 3' on line 363 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force H. Baba 3 Internet-Draft The University of Tokyo 4 Intended status: Informational I. Miyake 5 Expires: January 3, 2019 IoT Square Inc. 6 J. Matsumura 7 BizMobile Inc. 8 Y. Ishida 9 Japan Network Enabler Corporation 10 July 2, 2018 12 Study Report on a Framework for Cloud Inter-connection toward the 13 Realization of IoT 14 draft-baba-iot-interconnection-00 16 Abstract 18 This paper describes issues for solutions through cloud inter- 19 connection to structural problems, which are called as "silo effects" 20 found in cloud-connected electric home appliances, housing equipment 21 and sensors in the face of increasingly accelerated connection of 22 them. Specifically, this paper explains an inter-connection 23 agreement considered to be required for enhancement of cloud inter- 24 connection, what performance guarantee as well as IoT supervising and 25 management should be, necessity of inter-connection HUB which is able 26 to provide inter-connection amongst the preponderance of private 27 cloud groups. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 3, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Draft Framework for Cloud Inter-connection . . . . . . . . . 3 65 3. Interconnection Agreement . . . . . . . . . . . . . . . . . . 4 66 4. IoT Device Operation Confirmation and Monitoring . . . . . . 5 67 5. Interconnection HUB . . . . . . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 71 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 To date, based on the results of interviews with "Things" companies, 77 the authors of this paper, the Autors, issued a Problem Statement on 78 IoT [1], and reported on an experiment of WebAPI [2]. With further 79 interviewing and experiments, various requirements specification on a 80 base for securing cloud inter-connection in the anticipated IoT 81 society become clearer. 83 Currently, the use of various connected devices, hereinafter "IoT 84 Devices" is largely expected to become a using scene of IoT, and such 85 IoT Device manufacturers operates their private cloud groups, the 86 "Cloud", where IoT Devices are connected one after another. It 87 depends on the manufactures whether API of one cloud is open to a 88 third party or whether the cloud remains closed just for itself just 89 like a "silo". However, it is expected that API be open by 90 manufacturers in charge to third parties in the near future and a 91 large variety of values shall be created through cloud inter- 92 connection of IoT Devices that are connected to the other cloud 93 groups with a similar structure. Several cloud inter-connection 94 services, enabling one cloud with aforementioned IoT Devices to 95 connect with another cloud with IoT Devices, have already been 96 provided. 98 Thus, by combining cloud-connected IoT Devices, or "connected 99 Things", just like toy blocks being built freely through cloud inter- 100 connection, the era for creating a variety of benefits for users 101 seems to approach us. 103 As far as users select and handle connected Things on their own 104 response, there are not any significant issues. However, those whom 105 you cannot expect IT literacy like elder people should be able to get 106 access to benefits from IoT. If we stand on such an assumption, 107 there seem to be many open issues. 109 The Authors conducted interviews with 9 market players including IoT 110 service providers and those who were preparing to provide IoT 111 services and undertook research and summarized issues that those 112 players felt with regard to cloud inter-connection. In parallel with 113 other researching experience, we discussed on what framework would be 114 required for doing IoT service provider businesses at smart houses. 115 This paper outlines the findings from such discussions. 117 2. Draft Framework for Cloud Inter-connection 119 Not assuming the style where users enjoy combination of the use of 120 IoT Devices like DIY but assuming the one where so called service 121 providers offer IoT services to users on a "do-it-for-me (DIFM)" 122 manner, issues different from DIY style become more patent in the 123 light of responsibility for customers and business continuity. Those 124 issues are well diversified but may be summarized into three core 125 categories as follows: 127 (1) Inter-connection Agreement 129 Commercial cloud inter-connection requires some kind of contracts 130 without any doubt. Such contracting procedures are very common in 131 the Internet market. However, manufacturers of home appliances 132 and housing equipment have no experience and they feel worried. 134 (2) Operation Confirmation and Operation Monitoring of IoT Devices 136 Once being cloud-connected, it is necessary that not products of 137 one manufacture but also ones made by others are operated with 138 commands sent out of one's cloud server. At the development stage 139 of services and during operation of the services, the operation 140 monitoring of one's IoT Devices being connected with other's cloud 141 group just with commands of one's. 143 (3) Inter-connection Infrastructure 145 Currently a large number of manufacturers proceed with activities 146 in getting appliances and equipment that used to operate on a 147 standalone basis connected to the Internet. Those pieces of 148 appliances and equipment are independent of each other, namely 149 "silos". Therefore, in case of connecting all those pieces with 150 one another, the number of ways to connect needs to be N(N-1)/2. 151 To do this, much resources shall be required. As was seen in 152 telephone and the Internet, if HUBs connecting with one another 153 are put in place, this issue would be less cumbersome to some 154 extent. 156 The framework, comprising of above three points, shall be explained 157 in details in the following chapter. 159 3. Interconnection Agreement 161 In the era of IoT, it is desirable to facilitate contracting between 162 businesses smoothly by preparing a boilerplate format for an 163 interconnection agreement in advance. As described in the previous 164 chapter, because of the lack of experience in home appliances and 165 housing equipment manufacturers, needless to say, any guidelines or 166 formats would give great comfort to them. The benefits from an 167 interconnection agreement are to define responsibility of each 168 contracting party and clarify consent of the parties. 170 For example, manufacturers of gas cookers have been working on 171 operational linkage between a gas cooker and air conditioner in order 172 to harness the increase of room temperature. Possibly a universal 173 remote controller may be linked with a gas cooker and then the user 174 can of course operate an air conditioner with the gas cooker 175 controller. However, unless there is consent from the manufacturer 176 of the air conditioner on this link operation, the gas cooker 177 manufacturer seems to hesitate to pursue this due to his feeling that 178 this is not a fair business behavior. 180 Following precedents in the Internet, the contents of the 181 interconnection agreement include demarcation of responsibility, 182 procedures in operation and maintenance, cost allocation, technical 183 specifications, and general prohibitions. In addition to such 184 contents, however, the interconnection agreement becomes 185 significantly valuable by proving that participating parties formally 186 agree upon commercial terms of cloud inter-connection. 188 Of course, the agreement stipulates terms on malfunctioning of IoT 189 Devices. For example, there is a structure where an energy 190 management application located in a cloud group of lighting equipment 191 of Manufacturer A gives a command to a cloud group of air 192 conditioning equipment of Manufacturer B. By chance, one air 193 conditioner starts malfunctioning and the user may call a customer 194 service of Manufacturer A that provides DIFM energy management 195 services to the user. In this case, problems are 1) how the fault 196 can be isolated and 2) how this user's report can be transferred to 197 Manufacturer B if the fault is identified to come from the other 198 service provider, namely Manufacturer B. 200 In case of one manufacture Authors interviewed with, regarding 1) 201 above, the provider asks the user confirm the lighting operation by 202 its universal remote controller. If operates, the manufacturer 203 process the user's report for the moment as a problem of Manufacturer 204 A. If not operates, the user report could be handled as a problem of 205 Manufacturer B. Manufacture A does not escalate the user's report to 206 Manufacture B in case of 2) above. At a glance, this behavior of 207 Manufacture A may not be sincere, but this is related with the 208 treatment of personal information. Nowadays, manufacturers collect 209 personal information of the user only in case they really need such 210 information. Following this information policy, if a lighting remote 211 controller does not operate the air conditioner, problem of 212 Manufacture B is suspected. However, Manufacturer A does not ask the 213 user for his/her personal information. Instead, they ask the user to 214 call Manufacturer B once again. 216 Because there are very extraordinary restrictions on transfer of 217 personal information among service providers in many countries, 218 aforementioned treatment of users has to prevail. Contrarily this 219 treatment is totally opposite to a direction of the one-stop services 220 that users generally look for. 222 Regarding cloud inter-connection, several opinions on issues in 223 business continuity were heard. Namely, in case of formulating DIFM 224 services containing services provided by others, the DIFM service 225 providers are concerned with adverse impacts of the suspension or 226 cancellation of other providers' services on his/her DIFM services. 227 The interconnection agreement does not make other providers promise 228 to continue the provision of the services to the DIFM providers. 229 However, the agreement possibly defines responsibility of advance 230 notification and a certain lead time for countermeasure formulation. 231 Therefore, the interconnection agreement is meaningful in this 232 regard. 234 4. IoT Device Operation Confirmation and Monitoring 236 As was mentioned before, it is prerequisite to secure function of 237 operation confirmation of related IoT Devices in DIFM business in its 238 services development and in processing claims of users during service 239 provision. Even in the experimental service development stage, it is 240 often necessary to identify where a fault occurs and how to isolate 241 the fault in case that IoT Device does not perform as it is expected. 242 This articulates an issue related to inter-operability which is the 243 purpose of inter-connection. Especially, fault identification and 244 capacity to recover the identified faults are very significant 245 issues. 247 In interviewing with IoT service providers, their capacity to process 248 users' claims involves the following three functions. 250 1) Monitoring fault incidents; 252 2) Fault isolation; and 254 3) On-site fault recovery capability 256 As of now, generally operational confirmation and monitoring 257 functions comprise the following items. 259 1) Alive monitoring of IoT Devices through confirmation on ping 260 signal communications; 262 2) Understanding of fault situations and history by remote reading 263 of equipment log; and 265 3) Alarm monitoring beyond pre-set threshold levels such as data 266 traffic volume 268 However, if the number of IoT Devices increases rapidly from now on, 269 a set of aforementioned simple monitoring functions may not be 270 efficient in terms of recovery capacity and cost competitiveness. It 271 is necessary to re-examine the scalability of current operation and 272 monitoring systems carefully and introduce required new technologies 273 for effective operational monitoring of widely proliferated IoT 274 Devices from now on. 276 5. Interconnection HUB 278 When a large number of manufacturers start the operation of 279 independent cloud groups, their mutual interconnection becomes more 280 and more complex as is mentioned before. Telephone and the Internet 281 are supported with so called interconnection gateway switch and IX 282 structures, achieving inter-connection among service providers. 284 +---------------+ 285 [Pattern 1] | IoT HUB | 286 +------+ +--------------+ | | 287 | IoT +----+ Private |App|+----+| Cloud | | 288 |Device| | Cloud | || Driver| | 289 +------+ +--------------+ | | 290 <----------------+ | | 291 Inter-Cloud| | | 292 Interconnection| | | 293 <----------------+ | | 294 +------+ +--------------+ | | 295 | IoT +----+ Private |App|+----+| Cloud | | 296 |Device| | Cloud | || Driver| | 297 +------+ +--------------+ | | 298 Application-Cloud Interconnection 299 <---------------------------------> [Pattern 4] 300 | | +---------------+ 301 <---------------+ | | Web |+---+ Application | 302 Device-Cloud| | | API || | (B2C/Service) | 303 Interconnection| | | +---------------+ 304 <---------------+ | | 305 [Pattern 2] | | 306 +------+ | | 307 | IoT +------------------------+| Thing | | 308 |Device| || Driver| | 309 +------+ | | 310 | | 311 [Pattern 3] | | 312 +------+ +-------------+ | | 313 | IoT | | Gateway | | | 314 |Device+-----+| Thing | +----+ | 315 | | || Driver| | | | 316 +------+ +-------------+ | | 317 | Database | 318 | Directory | 319 | Description | 320 +-------++------+ 321 || 322 +-------++------+ 323 | Sekisyo | 324 | Service[1] | 325 +---------------+ 327 Figure 1: Structure of IoT HUB. 329 Of course, in the IoT world, similar arrangements to connect among 330 cloud groups are possible. There is one difference from the era of 331 telephone and the Internet. This is no existence of inter-connection 332 communication protocols such as SS#7 and BGP4 here. 334 During the interviews with the providers, no one mentioned the 335 necessity of standardization of inter-cloud interconnection 336 communication protocols. Contrarily, many providers told that they 337 would utilize whatever they can use in an extremely businesslike 338 manner. Actually already existing inter-cloud interconnection 339 services do not specially focus on this issue. So it is considered 340 that interconnection HUBs would necessarily be structured in way HUBs 341 accommodate various different kinds of protocols. In order to 342 connect different protocols that respective cloud group utilize with 343 one another, the HUB side needs to be equipped with a driver module 344 matching each of the cloud groups to be connected. Authors call this 345 as a "printer driver model." 347 And according to a research of Authors, interconnection services 348 already put in place tend to take similar patterns such as inter- 349 cloud interconnection and application-cloud connection. Therefore it 350 is necessary to proceed with interconnections with different patterns 351 in order to make it more universal. 353 Service providers as a bussiness that Authors are considering are at 354 least the following four patterns. The University of Tokyo continues 355 with its research, recognizing requirements for infrastructures for 356 interconnection of those items. 358 [Pattern 1] Service providers with their private cloud connecting 359 with IoT devices, 361 [Pattern 2] preparing device drivers to IoT devices, 363 [Pattern 3] supplying gateways which connect IoT devices, and 365 [Pattern 4] application and service providers with with others IoT 366 devices. 368 6. Security Considerations 370 Regarding security, pattern 2 of service providers specified in 371 Chapter 5 may contain some vulnerability and thus precaution is 372 required. 374 7. Privacy Considerations 376 Regarding privacy, Chapter 2 touches upon concerns on privacy among 377 inter-connected service providers in case of fault isolation after 378 IoT Device malfunctioning. 380 8. Acknowledgement 382 This paper contains findings of the study funded by the Ministry of 383 Internal Affairs and Communications of Japan as well as research 384 activities of IoT Committee of Internet Association Japan. We hereby 385 touch upon such facts and show our gratitude to those who relate to 386 the study and committee activities. 388 9. Normative References 390 [1] Baba, H., Ishida, Y., Amatsu, T., Kunitake, K., and K. 391 Maeda, "Problems in and among industries for the prompt 392 realization of IoT and safety considerations", 2018, 393 . 395 [2] Baba, H., Ishida, Y., Amatsu, T., Masuda, H., Ogura, S., 396 and K. Kunitake, "Report on Problem Solving Experiment for 397 Realization of Web-API-based IoT", 2018, . 400 Authors' Addresses 402 Hiroyuki Baba 403 The University of Tokyo 404 Institute of Industrial Science 405 4-6-1 Komaba 406 Meguro-ku, Tokyo 153-8505 407 Japan 409 Email: hbaba@iis.u-tokyo.ac.jp 411 Izaya Miyake 412 IoT Square Inc. 413 Hibiya Parkfront. 414 2-1-6, Uchisaiwai-cho 415 Chiyoda-ku, Tokyo 100-0011 416 Japan 418 Email: izmiyake@iot-sq.com 419 Jun Matsumura 420 BizMobile Inc. 421 Kanda Business Cube 3F 422 5-1, Kandatomiyama-cho 423 Chiyoda-ku, Tokyo 101-0043 424 Japan 426 Email: jumatsum@bizmobile.co.jp 428 Yoshiki Ishida 429 Japan Network Enabler Corporation 430 7F S-GATE Akasaka-Sanno. 431 1-8-1 Akasaka 432 Minato-ku, Tokyo 107-0052 433 Japan 435 Email: ishida@jpne.co.jp