idnits 2.17.1 draft-wang-core-opcua-transmition-requirements-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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 28, 2016) is 2675 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) == Missing Reference: 'IEC 62541-1' is mentioned on line 91, but not defined == Unused Reference: 'IEC 62541-5' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'I-D.koster-core-coap-pubsub' is defined on line 249, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Core H. Wang 2 Internet Draft C. Pu 3 Interned status: Standards Track P. Wang 4 Expires: July 1, 2017 Y. Yang 5 D. Xiong 6 Chongqing University of 7 Posts and Telecommunications 8 December 28, 2016 10 Requirements Analysis for OPC UA over CoAP 11 draft-wang-core-opcua-transmition-requirements-00 13 Abstract 15 Industrial Internet of Things is an attractive application area for 16 Constrained Application Protocol (CoAP). OPC Unified Architecture 17 (OPC UA) defines a semantic-based information model for industrial 18 control system that can satisfy the requirements of Industry 4.0 19 based on semantic information exchange. This document analyses 20 requirements for OPC UA transmission over CoAP. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on July 1, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with 55 respect to this document. Code Components extracted from this 56 document must include Simplified BSD License text as described in 57 Section 4.e of the Trust Legal Provisions and are provided without 58 warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction ................................................ 2 63 2. Architecture of OPC UA over CoAP............................. 3 64 3. Requirements for OPC UA over CoAP............................ 4 65 3.1. Encoding ............................................... 4 66 3.2. Application Sublayer Optimization ...................... 4 67 3.3. Consistency ............................................ 4 68 3.4. Reliability ............................................ 5 69 4. Security Considerations...................................... 5 70 5. IANA Considerations ......................................... 5 71 6. References .................................................. 6 72 6.1. Normative References.................................... 6 73 6.2. Informative References.................................. 6 74 Authors' Addresses ............................................. 7 76 1. Introduction 78 CoAP is a web application protocol designed for resource constrained 79 devices and limited networks that has been widely used in machine- 80 to-machine (M2M) communications [RFC7252]. However, the purpose of 81 applying CoAP to the Industrial Internet of Things (IIoT) is to 82 provide connectivity for the devices. Whereas the communication of 83 Industry 4.0 is not only based on data transmission, but also based 84 on semantic information exchange. Driven by this, using CoAP in the 85 IIoT, there is a need to provide good support for data transmission 86 of the application layer in the automation field. According to the 87 definition of Industry 4.0 for communication, CoAP needs to support 88 the exchange of semantic information, namely the semantic 89 information model. For the current protocols supporting semantic 90 information model in the IIoT, the information model defined by OPC 91 UA [IEC 62541-1] is very promising and its transmission mode is 92 similar to the transmission mode of CoAP, so it can be applied as a 93 branch of the CoAP message payload. 95 2. Architecture of OPC UA over CoAP 97 With the vision of IIoT in mind, we believe that the architecture of 98 OPC UA over CoAP can be mainly divided into the following two: 100 1) Figure 1 presents a logical layered structure of OPC UA 101 Information Model over CoAP. In the transport layer, DTLS runs on 102 top of UDP to secure transmission. Then, the middle layer utilizes 103 the message mode defined in the CoAP protocol. Last, the information 104 model of OPC UA [IEC TR 62541-5] is defined as an application of 105 CoAP at the top. In such a hierarchical structure, the semantic- 106 based data information in OPC UA can be transmitted in restricted 107 scenarios, so that CoAP can meet the requirements of semantic 108 information transmission. 110 + - - - - - - - - - - - - - - + 111 | OPC UA Information Model | 112 + - - - - - - - - - - - - - - + 113 + - - - - - - - - - - - - - - + 114 | CoAP | 115 + - - - - - - - - - - - - - - + 116 + - - - - - - - - - - - - - - + 117 | UDP | 118 + - - - - - - - - - - - - - - + 119 Figure 1: OPC UA Information Model over CoAP 121 2) In order to take full advantage of the service set defined by OPC 122 UA, this document proposes the other architecture for OPC UA 124 + - - - - - - - - - - - - - - + 125 | OPC UA Information Model | 126 + - - - - - - - - - - - - - - + 127 | OPC UA Services | 128 + - - - - - - - - - - - - - - + 129 + - - - - - - - - - - - - - - + 130 | CoAP | 131 + - - - - - - - - - - - - - - + 132 + - - - - - - - - - - - - - - + 133 | UDP | 134 + - - - - - - - - - - - - - - + 135 Figure 2: OPC UA Information Model and Services over CoAP 137 transmission over CoAP. As shown in Figure 2, the information model of 138 OPC UA is defined as the application of CoAP, moreover, the connection 139 establishment, creation session, publish/subscribe and other functions 140 related to data information interaction are all implemented by the 141 service set defined by OPC UA. CoAP is mainly responsible for the 142 definition of message format and runs over UDP to keep the 143 implementation lightweight. 145 3. Requirements for OPC UA over CoAP 147 3.1. Encoding 149 CoAP messages are encoded in a simple binary format that starts with 150 a fixed-size 4-byte header. The header is followed by a variable- 151 length Token value, which can be between 0 and 8 bytes long. 152 Following the Token value comes a sequence of zero or more CoAP 153 Options in Type-Length-Value (TLV) format, optionally followed by a 154 payload that takes up the rest of the datagram. In addition, the OPC 155 UA protocol coding mainly includes two ways that are binary and XML. 156 Therefore, in order to transmit the information model of OPC UA over 157 CoAP, specific frame formats of CoAP need to be designed to support 158 two kinds of coding modes of OPC UA. 160 3.2. Application Sublayer Optimization 162 For information exchange, the document [draft-ietf-core-coap-pubsub- 163 00] defines the corresponding application sublayer, OPC UA also 164 defines a number of specific communication patterns. For example, in 165 the publish/subscribe mode defined by OPC UA, when the client needs 166 to obtain a data periodically, it will initiate a subscription 167 request to the server. In addition, the server will send the data to 168 the client periodically as it receives the request from the client 169 successfully. Correspondingly, in the publish/subscribe 170 specification of CoAP, it introduces Broker mechanism in which the 171 client sends the state information to the Broker and the Broker 172 provides storage and forwarding function to implement the 173 publish/subscribe function. Comparing above two protocols, their 174 achieving methods have a difference on communication mode of the 175 publish/subscribe function. Therefore, it is necessary to optimize 176 the application sublayer of CoAP to support some particular 177 communication modes of OPC UA. 179 3.3. Consistency 181 The interactive model of CoAP is the client/server model. However, 182 in M2M scenarios, CoAP entities often act as both servers and 183 clients. Comparing to OPC UA, though the interactive model is also 184 the client/server model, there is a set of supported services in the 185 OPC UA server. Consequently, for the great difference of the server 186 definition of these two protocols, we need to tackle with the 187 consistency and integration issues between the CoAP server and the 188 OPC UA server. 190 3.4. Reliability 192 One of the main design goals of CoAP is to satisfy some special 193 requirements such as communication in the constrained scenarios that 194 address power consumption. Hence, in order to reduce network 195 overhead and avoid network congestion, CoAP is designed to run over 196 UDP, which is a good choice to achieve inter-network data 197 transmissions in use of the IP architecture. However, UDP is a 198 connectionless transport layer protocol that provides unreliable 199 information transmission services. In the field of IIoT, we need to 200 ensure the reliability of data transmission to avoid losing some 201 important data information. Moreover, CoAP addresses transmission 202 reliability by defining a message as requiring acknowledgment, 203 obviously this is not enough to meet the high reliability 204 requirements in the field of IIoT, so the reliability of COAP 205 remains to be optimized. 207 4. Security Considerations 209 The security of CoAP includes four modes in which three modes 210 implemented based on the Datagram Transport Layer Security (DTLS) 211 except the non-security mode. However, the security architecture of 212 OPC UA is built on the application layer and the communication layer 213 above the transport layer. Specifically, the application layer 214 adopts the authentication and authorization and the communication 215 layer achieves the security of OPC UA [IEC TR 62541-2] through 216 secure channel encryption. Though OPC UA has four modes, the 217 security model of OPC UA is realized based on Transport Layer 218 Security (TLS). Actually, DTLS is an addition to TLS to solve the 219 unreliable transmission feature of UDP. Currently, some documents 220 show that CoAP needs to support TLS. Therefore, the security of the 221 two protocols can be implemented jointly. 223 5. IANA Considerations 225 This memo includes no request to IANA. 227 6. References 229 6.1. Normative References 231 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 232 Application Protocol", RFC 7252, June 2014, 233 . 235 6.2. Informative References 237 [IEC TR 62541-1] 238 IEC, "OPC unified architecture-Part1: Overview and concepts- 239 IEC 62541", 2016, 240 . 243 [IEC 62541-5] 244 IEC, "OPC unified architecture-Part5: Information Model-IEC 245 62541", 2015, 246 . 249 [I-D.koster-core-coap-pubsub] 250 Koster, M., Keranen, A., and J. Jimenez, "Publish- 251 Subscribe Broker for the Constrained Application Protocol 252 (CoAP)", draft-ietf-core-coap-pubsub-00 (work in 253 progress), Qctober 2016. 255 [IEC TR 62541-2] 256 IEC, "OPC unified architecture-Part2: Security Model-IEC 257 62541", 2016, 258 . 261 Authors' Addresses 263 Heng Wang 264 Chongqing University of Posts and Telecommunications 265 2 Chongwen Road 266 Chongqing, 400065 267 China 269 Phone: (86)-23-6248-7845 270 Email: wangheng@cqupt.edu.cn 272 Chenggen Pu 273 Chongqing University of Posts and Telecommunications 274 2 Chongwen Road 275 Chongqing, 400065 276 China 278 Phone: (86)-23-6246-1061 279 Email: mentospcg@163.com 281 Ping Wang 282 Chongqing University of Posts and Telecommunications 283 2 Chongwen Road 284 Chongqing, 400065 285 China 287 Phone: (86)-23-6246-1061 288 Email: wangping@cqupt.edu.cn 290 Yi Yang 291 Chongqing University of Posts and Telecommunications 292 2 Chongwen Road 293 Chongqing, 400065 294 China 296 Phone: (86)-23-6246-1061 297 Email: 15023705316@163.com 299 Daijing Xiong 300 Chongqing University of Posts and Telecommunications 301 2 Chongwen Road 302 Chongqing, 400065 303 China 304 Phone: (86)-23-6246-1061 305 Email: 15111825021@163.com