idnits 2.17.1 draft-cheng-intarea-ugccnet-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 24, 2014) is 3653 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: 'RFC0793' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 455, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intarea Working Group M. Cheng 3 Internet-Draft F. Feng 4 Intended status: Standards Track BII Group Holdings Ltd. 5 Expires: October 26, 2014 April 24, 2014 7 The Architecture for Ubiquitous Green Community Control Network 8 draft-cheng-intarea-ugccnet-00 10 Abstract 12 In this document, it identifies gateways for field-bus networks, data 13 storages for archiving and developing data sharing platform, and 14 application units to be important system components for developing 15 digital communities: i.e., building-scale and city-wide ubiquitous 16 facility networking infrastructure. The standard defines a data 17 exchange protocol that generalizes and interconnects these components 18 (gateways, storages, application units) over the IPv4/v6-based 19 networks. This enables integration of multiple facilities, data 20 storages, application services such as central management, energy 21 saving, environmental monitoring and alarm notification systems. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 26, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 59 3. System Architecture . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. Application . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.4. Registry . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Concerns of the network design . . . . . . . . . . . . . . . 4 65 5. System Model . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6. Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6 68 6.2. Definition . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.3. URI-based identification . . . . . . . . . . . . . . . . 6 70 6.4. PointSet . . . . . . . . . . . . . . . . . . . . . . . . 7 71 7. Common communication protocol . . . . . . . . . . . . . . . . 7 72 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 7.2. Component-to-component communication protocol . . . . . . 7 74 7.2.1. Types of component-to-component communication 75 protocol . . . . . . . . . . . . . . . . . . . . . . 7 76 7.2.2. FETCH protocol . . . . . . . . . . . . . . . . . . . 8 77 7.2.3. WRITE protocol . . . . . . . . . . . . . . . . . . . 8 78 7.2.4. TRAP protocol . . . . . . . . . . . . . . . . . . . . 8 79 7.3. Component-to-registry communication protocol . . . . . . 8 80 7.3.1. Type of component-to-registry communication protocol 8 81 7.3.2. REGISTRATION protocol . . . . . . . . . . . . . . . . 9 82 7.3.3. LOOKUP protocol . . . . . . . . . . . . . . . . . . . 9 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 85 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 88 1. Introduction 90 This document identifies gateways for field-bus networks, data 91 storages for archiving and developing data sharing platform, and 92 application units such as for providing user interfaces of analysis 93 and knowing the environmental information to be important system 94 components for developing digital communities: i.e., building-scale 95 and city-wide ubiquitous facility networking infrastructure. The 96 standard defines a data exchange protocol that generalizes and 97 interconnects these components (gateways, storages, application 98 units) over the IPv4/v6-based networks. This opens the application 99 interface to handle the statuses of multi-vendor facilities on a 100 generalized digital infrastructure. The standard assumes distributed 101 operation of the infrastructure by multiple service providers and 102 integrators, and defines a component management protocol that 103 autonomously interoperates such distributed infrastructure. Security 104 requirements are taken into consideration in this standard to ensure 105 the integrity and confidentiality of data. 107 2. Terminology and Conventions 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 o access control: The means to allow authorized entry and usage of 114 resources. 116 o actuator: A transducer that accepts a data sample or samples and 117 converts them into physical action. 119 o eXtensible Markup Language (XML) namespace: A method for 120 distinguishing XML elements and attributes that may have the same 121 name but different meanings. A URL is used as a prefix to a 122 "local name." This combination ensures the uniqueness of the 123 element or attribute name. The URL is used only as a way to 124 create a unique prefix and does not have to resolve to a real page 125 on the Internet. 127 o A transducer that converts a physical, biological, or chemical 128 parameter into a digital signal. 130 o universally unique identifier (UUID): An identifier that has a 131 unique value within some defined universe. In this standard, the 132 query-expression and lookup-expression of transport data structure 133 has a UUID unless otherwise stated. 135 3. System Architecture 137 This protocol specification applies to a TCP/IP-based facility 138 networking architecture. One of the main goals of this specification 139 is to enable interoperability among facility networking components. 140 Thus, GW, Storage and APP, what we call "Component" in this document, 141 have the same generalized communication interface. Registry has 142 different communication interface with these components. A Component 143 works as a part of data- plane, and a Registry works as a part of 144 control- plane. 146 In the networking environment, Registry works as a broker of 147 Components. It manages meta information e.g., the role of each 148 component and the semantics of Point ID, in order to bind components 149 appropriately and autonomously. We here describe them in more detail 150 and show how they collaborate with each other. 152 3.1. Gateway 154 Gateway component has physical sensors and actuators. It generalizes 155 the data model and the access method for those devices, encapsulating 156 each physical (field-bus) data model and access method. It acts on 157 its actuator according to the written value from a component (e.g., 158 APP), and it provides physical sensor readings for other components 159 (e.g., Storage and APP). 161 3.2. Storage 163 Storage component archives the history of data sequences. The 164 written values from other components should be permanently stored in 165 the backend disks. It provides the archived values to the components 166 that have requested them. 168 3.3. Application 170 APP component provides some particular works on sensor readings and 171 actuator commands. It can have user interface to display the latest 172 environmental state. It can also allow a user to input some 173 schedules of actuator settings, and it can as well analyze some 174 sensor data in realtime and provide the result as a virtual device. 176 3.4. Registry 178 The Registry works as a broker of GW, Storage, and APPs. The main 179 role of registry is to bind those components appropriately and 180 autonomously. It is separated from the data-plane. It does not work 181 on sensor readings or actuator settings directly. It should allow 182 system operation without Registry. 184 4. Concerns of the network design 186 All components can behave both as the TCP (IETF RFC 793) initiator 187 and receiver at once. It implies the components should be put on a 188 flat network. A flat network means there are no middle boxes which 189 could disturb bi-directional communications such as NAT routers and 190 firewalls. 192 To avoid the issue, we strongly recommend building IPv6 (IETF RFC 193 2460) network. There could be other solutions than IPv6 such as http 194 proxy based or NAT traversal solutions. However, they would depend 195 on the requirements of the network configuration. This specification 196 does not reject such solutions, but they are required to make 197 interoperable with other systems and not to disturb the 198 specification. 200 5. System Model 202 Component is the basic unit for all the GWs, Storages, and APPs. The 203 interface of Component provides data and query method. GW, Storage, 204 and APP are the inherited classes of Component. Thus, they have the 205 same interface (i.e., data and query method), and they communicate 206 with each other using the same protocol. Here, Query is a method for 207 retrieving data (including event-based data transfer) from Component; 208 Data is a method for pushing data into Component. 210 Registry works as a broker of Components with another type of 211 interface (i.e., registration and lookup method). The interface of 212 Registry provides registration and lookup method. Here, 214 o Registration is a method for registering the role of components 215 and semantics of Points. 217 o Lookup is a method for finding appropriate components and Points. 219 Typical implementations for GWs, Storages, APPs and Registry would 220 be: 222 GW implementations encapsulate field-buses and provide INPUT/OUTPUT 223 access for physical devices (by query and data method). 225 Storage implementations archive the history of data posted by data 226 method, and provide the historical data by query method. 228 APP implementations provide other functionalities. For example, they 229 can have user interface. Data processing component must be also 230 categorized to an APP implementation. 232 Registry implementations manage the relationships between Point ID 233 and components, provide registration of the role of components and 234 semantic of Points by registration method, and provide inquiry of 235 appropriate components and Points by lookup method. 237 This generalization enables open development of facility networking 238 components (i.e., GWs, Storages and APPs) by any vendors. And we 239 would deploy facility networking systems for customer buildings 240 without customized programming, by binding these developed 241 components. 243 The role of Registry is to increase the autonomousness of component- 244 to-component collaboration. It allows autonomous collaboration of 245 components, by sharing the information of component roles in an 246 operational domain (in fact, not only in an operational domain but 247 also with other external domains). 249 6. Point 251 6.1. Introduction 253 This section introduces the concept of Point. A Point shall have an 254 URI-based globally unique identifier. It identifies a dataflow that 255 exchanges data (i.e., sensor readings, actuator commands and meta- 256 control signals) among components. 258 6.2. Definition 260 A Point is an elemental message channel for a specific data sequence 261 among Components. A sequence of sensor readings, actuator commands 262 and others (e.g., virtualized sensor readings, meta-control signals) 263 shall be bound to a Point. We denote a message in a Point (whether 264 it is coming from a sensor or it is outgoing to an actuator) by 265 value. Any object type is allowed for values in a Point. 267 Delivery of values among components shall be made by invoking other 268 components' interface. The provided methods are: 270 Query: to read objects from specified Points 272 Data: to write objects into specified Points 274 By using these methods, a component can get data of the specified 275 Points from another component, and it can also transfer data to 276 another component with specification of the Points. 278 6.3. URI-based identification 280 A Point is associated to a globally unique data sequence. The data 281 shall have been generated from a specific sensor or to a specific 282 actuator in the world. Thus, in order to identify the data sequence 283 globally, each Point should have a globally unique identifier. Note 284 that for private operation, it does not necessarily need to be 285 globally unique. However, it is not recommended. 287 In UGCCNet, every Point shall have a URI for its identifier. 288 Practically, we will first assign IDs for physical sensors and 289 actuators, and then we will use the IDs for the Point IDs. This 290 operation goes well with the traditional facility networking 291 operation. 293 Taking URI for identifiers enables global access (if the Point is 294 public) to the Point. Let X(=http://gw.foo.org/sensor1) be a Point 295 ID. 297 If components do not know the registry server that manages the Point 298 ID (X), they should try to access X directly. Then, the URI can 299 redirect to the registry server. If components already know the 300 registry server for X, Point ID may not need to be reachable. 301 However, in order to obtain operational consistency, the host of the 302 URI should be the host name of the GW (because physical sensors and 303 actuators are attached to the GW). Thus, typical URI format should 304 be: 306 point ID = "http://(GW host name)/(any format to identify the Point 307 in the GW)" 309 6.4. PointSet 311 This specification also defines PointSet to enable hierarchical 312 management of Points. A PointSet aggregates multiple Points and 313 multiple PointSets. This definition allows the conventional 314 operation of grouping of Points hierarchically. However, PointSet 315 feature is optional. All the components should allow operation 316 without pointSet. 318 7. Common communication protocol 320 7.1. General 322 This specification defines two types of communication protocols for 323 components and registry, including the component-to-component 324 communication protocol and component-to-registry communication 325 protocol. The protocol message for component-to-component and 326 component-to-registry communication is intended to use Simple Object 327 Access Protocol (SOAP Version 1.2 Part 1: Messaging Framework"). 329 7.2. Component-to-component communication protocol 331 7.2.1. Types of component-to-component communication protocol 333 This section specifies and describes the following three types of 334 sub-protocols for component-to-component communication. Note that 335 instances of components are GWs, Storages, and APPs. As for the 336 accessing methods to a registry. 338 FETCH protocol -- for data retrieval from a remote component. 340 WRITE protocol -- for data transfer to a remote component. 342 TRAP protocol -- for event query registration and event data 343 transfer. 345 7.2.2. FETCH protocol 347 FETCH is a protocol for data retrieval from a remote component. We 348 here denote the component that inquires data from the remote 349 component by 'Requester', and the component that replies with the 350 data by 'Provider'. 352 7.2.3. WRITE protocol 354 WRITE is a protocol for data transfer to a remote component. We 355 denote the component that submits data to the remote component by 356 Requester, and the component that receives the data by Target. 358 7.2.4. TRAP protocol 360 TRAP is a protocol for event query registration and event data 361 transfer. We here give names for components in the following manner. 363 Requester -- the component that sets event-based query to Provider. 365 Provider -- the component that transmits data when it has received 366 query-matching updates. 368 Callback (Data) -- the components that receives data from the 369 Provider. 371 Callback (Control) -- the components that receives control signals 372 from the Provider. 374 This subsection provides the definition of collaboration among these 375 components. Though the roles are explicitly categorized in general, 376 in most of the practical systems, Callback (Data), Callback (Control) 377 and Requester will be the same component. 379 7.3. Component-to-registry communication protocol 381 7.3.1. Type of component-to-registry communication protocol 383 This section specifies the following two types of sub-protocols for 384 component-to-registry communication. 386 REGISTRATION Protocol -- for registration of the role of components 387 and semantics of Points. 389 LOOKUP Protocol -- for searching appropriate components and Points. 391 7.3.2. REGISTRATION protocol 393 REGISTRATION is a protocol which enables a component to register the 394 role of components and semantics of Points. We denote the component 395 that submits registration request to its Registry by "Registrant". 397 7.3.3. LOOKUP protocol 399 LOOKUP is a protocol for a component to search appropriate access 400 components (for component-to-component communication), and to search 401 Points by semantic-query. We here denote the component that searches 402 appropriate components and Points from its Registry by 'Requester'. 404 8. Security Considerations 406 UGCCNet protocol is basically open. It assumes multi-domain 407 operation and public access from other domain's system components. 408 In this context, security requirements to the system would be listed 409 as follows: 411 o To avoid unintended data disclosure to the public. 413 o To avoid unauthorized access to writable resources. 415 o Availability and confidentiality of remote communication host. 417 o Integrity and confidentiality of data. 419 o To avoid unintended access or operational conflicts. 421 To get confidentiality of remote communication host, we would be able 422 to take VPN, SSL, SSH and other related technologies. HTTPS, or SIP 423 and its security extension would help in getting integrity and 424 confidentiality of data. 426 Access control and access confliction management shall be other 427 important but different types of security issues that should be 428 discussed independently. Generally, access control is used to allow 429 only specific users to access both readable and writable resources, 430 which would certainly help to avoid unauthorized access from or 431 unintended data disclosure to the public (sometimes anonymous) users. 432 In order to manage this, the system would need to introduce the 433 concept of users to identify who is accessing the resources. We 434 assume URI-based identification for user authentication just as Point 435 ID takes URI for its identifier. Authentication of these users and 436 components (probably by taking advantage of the existing 437 authentication platforms) would certainly need to be considered. 439 9. Acknowledgements 441 Funding for the RFC Editor function is currently provided by BII 442 Group. 444 10. Normative References 446 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 447 793, September 1981. 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, March 1997. 452 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 453 (IPv6) Specification", RFC 2460, December 1998. 455 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 456 Resource Identifier (URI): Generic Syntax", STD 66, RFC 457 3986, January 2005. 459 Authors' Addresses 461 Mike Cheng 462 BII Group Holdings Ltd. 463 Beijing 464 P. R. China 466 Email: mikecheng@biigroup.com 468 Frankey Feng 469 BII Group Holdings Ltd. 470 Beijing 471 P. R. China 473 Email: gfeng@biigroup.cn