idnits 2.17.1 draft-wang-core-opcua-transmission-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 : ---------------------------------------------------------------------------- ** There are 42 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 25, 2017) is 2646 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: 'I-D.wang-core-opcua-transmition-requirements' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-http-mapping' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'Gruer' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-coap-pubsub' is defined on line 266, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-wang-core-opcua-transmition-requirements-00 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-00 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Core P. Wang 2 Internet Draft C. Pu 3 Interned status: Standards Track H. Wang 4 Expires: July 29, 2017 Y. Yang 5 L. Shao 6 Chongqing University of 7 Posts and Telecommunications 8 January 25, 2017 10 OPC UA Message Transmission Method over CoAP 11 draft-wang-core-opcua-transmission-00 13 Abstract 15 In Industrial applications, it is very attractive to implement the 16 exchange of semantic information utilizing OPC UA Transmitting in 17 CoAP. This document provides some transmission methods for message 18 of OPC UA over CoAP. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on July 29, 2017. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with 53 respect to this document. Code Components extracted from this 54 document must include Simplified BSD License text as described in 55 Section 4.e of the Trust Legal Provisions and are provided without 56 warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ................................................ 2 61 2. Transmission scheme ......................................... 3 62 2.1. Proxy for OPC UA-CoAP................................... 3 63 2.2. Direct transmission..................................... 4 64 2.3. REST transmission for OPC UA............................ 4 65 3. Publish subscription for OPC UA and CoAP .................... 6 66 4. Security Considerations...................................... 6 67 5. IANA Considerations ......................................... 6 68 6. References .................................................. 6 69 6.1. Normative References.................................... 6 70 6.2. Informative References.................................. 6 71 Authors' Addresses ............................................. 7 73 1. Introduction 75 Internet of things is one of the attractive applications for CoAP. 76 Utilizing OPC UA Transmitting over CoAP could meet the demand for 77 industry 4.0 based on the exchange of semantic information[draft- 78 wang-core-opcua-transmition-requirements-00]. Similar to OPC UA, 79 CoAP message is exchanged in server/client mode. However, their 80 transmission is not the same. Driven by this, to use OPC UA 81 Transmitting over CoAP, the major problem to be solved is how OPC UA 82 packets are transmitted over CoAP. For the transport layer of OPC UA, 83 the main message transmission method is TCP or HTTP, and CoAP's 84 design inspiration comes from HTTP, thus, there are some connections 85 in transmission method between them. This proposal provides some 86 transmission methods for message of OPC UA over CoAP, so that a 87 communication could be established between client and server. 89 2. Transmission scheme 91 2.1. Proxy for OPC UA-CoAP 93 OPC UA is a protocol mainly for application layer, which defines 94 many services for the different needs of industrial applications. 95 Message is exchanged mainly through server/client mode, utilizing 96 TCP or HTTPS. When security is ignored, OPC UA can be considered to 97 support HTTP transmission. CoAP's design inspiration comes mainly 98 from HTTP, the two can be mapped between each other to meet the 99 needs of some special scenes [draft-ietf-core-http-mapping-17]. 100 Combined with the characteristics of OPC UA and CoAP, a CoAP proxy 101 can be established between OPC UA client and OPC UA server. The 102 architecture is shown in Figure 1. 104 - - - - - - - - - - - - - - - 105 // + - - - - + \\ 106 || | UA-CoAP | || 107 || // | server | || 108 || // + - - - - + || 109 || // || 110 || // || 111 + - - - - + HTTP Request + - - - - - - + CoAP Request + - - - - + || 112 | UA | - - - - - - - - > | UA-to-CoAP | - - - - - - - > | UA-CoAP | || 113 | client | < - - - - - - - - | PROXY | < - - - - - - - | server | || 114 + - - - - + HTTP Response + - - - - - - + CoAP Response + - - - - + || 115 || \\ || 116 || \\ || 117 || \\ || 118 || \\ + - - - - + || 119 || \\ | UA-CoAP | || 120 || | server | || 121 \\ + - - - - + // 122 - - - - - - - - - - - - - - - - 123 Figure 1. Proxy for OPC UA-to-CoAP 125 As shown in Figure 1, assume all OPC UA servers are based on CoAP 126 [draft-wang-core-opcua-transmition-requirements-00], and all OPC UA- 127 CoAP server can be viewed as a network, introducing UA-to-CoAP proxy 128 at the boundary of the network. When a traditional OPC UA client 129 initiates an HTTP request to the UA-CoAP server in the network, the 130 UA-to-CoAP proxy maps the http request to the corresponding CoAP 131 request and sends it to the UA-CoAP server in the network. After 132 receiving the request, the UA-CoAP server sends a response to the 133 UA-CoAP proxy. The proxy maps the CoAP response to the HTTP response 134 and returns it to the UA client. For the UA client, the network 135 proxy and conversion is transparent, in this way, the transfer of 136 OPC UA in CoAP does not need to make any changes to the UA Client. 138 2.2. Direct transmission 140 The transmission of OPC UA supports TCP protocol and HTTP protocol, 141 when security is ignored, OPC UA can be considered to support HTTP 142 transmission. On the other hand, CoAP is seen as a simplified HTTP 143 protocol so that it can be applied to resource - constrained network. 144 Therefore, this document considers the use of CoAP to directly 145 transfer OPC UA messages. OPC UA packets are encoded in either 146 binary or xml format, and the optional fields in the CoAP header 147 specify parameters that support these two formats, and the option 148 field in the CoAP header can specify parameters that support both 149 formats. Therefore, according to the format specified by the CoAP 150 header, the entire packet of the OPC UA can be encapsulated in the 151 payload of the CoAP message for direct transmission, as shown in 152 Figure 2. Noted that this method of transmission needs to be 153 modified on the server side and the client side of the OPC UA 154 according to CoAP. 156 + - - - - - - + CoAP Request + - - - - - - + 157 | UA client | - - - - - - - - - - > | UA server | 158 | | < - - - - - - - - - - | | 159 + - - - - - - + CoAP Response + - - - - - - + 161 Figure 2. Direct transmission OPC UA based on CoAP 163 2.3. REST transmission for OPC UA 165 OPC UA is a set of data exchange specifications for industrial 166 communication, the core of the OPC UA protocol is information 167 modeling and transmission, which marks each node in the address 168 space with a unique identifier. A series of state interactions are 169 needed before performing normal reading and writing, including 170 message handshaking, opening a secure channel, creating a session, 171 activating a session, etc. Besides, some states also need to be 172 maintained during read and write operations. 174 In OPC UA, each node has an independent identifier in the address 175 space, and different types of nodes can establish contact with each 176 other by reference. OPC UA defines a variety of services, and these 177 services are fixed, the user cannot arbitrarily modify, each service 178 is invoked through a single message, without relying on the previous 179 message, the service response is also completed by a separate 180 message and do not rely on other messages. The above features are in 181 line with the REST architecture, due to CoAP is based on the REST 182 architecture. Therefore, it is possible to simplify the interaction 183 before the OPC UA performs the normal communication, and carry the 184 OPC UA message by using the communication mode of the CoAP. 185 Communication process is shown in Figure 3. 187 + - - - - + + - - - - + + - - - - + + - - - - + 188 | client | | server | | client | | server | 189 + - - - - + + - - - - + + - - - - + + - - - - + 190 | Hello | | | 191 | - - - - - - - - - > | | | 192 | Acknowledge | | | 193 | < - - - - - - - - - | | | 194 |OpenSecureChannelReq | | | 195 | - - - - - - - - - > | | | 196 |OpenSecureChannelRes | | | 197 | < - - - - - - - - - | | | 198 | CreateSessionReq | | | 199 | - - - - - - - - - > | | | 200 | CreateSessionRes | | | 201 | < - - - - - - - - - | | | 202 | ActivateSessionReq | | | 203 | - - - - - - - - - > | | | 204 | ActivateSessionRes | | | 205 | < - - - - - - - - - | | | 206 | Request | | CoAPRequest | 207 | - - - - - - - - - > | | - - - - - - - - - > | 208 | Response | | CoAPResponse | 209 | < - - - - - - - - - | | < - - - - - - - - - | 210 a Traditional OPC UA communication b REST architecture communication 211 Figure 3. The communication of traditional OPC UA and the REST 212 transmission 214 In Figure 3(a), the traditional OPC UA requires a series of 215 interactions between normal read and write operations. Figure 3 (b) 216 shows that when using CoAP to carry OPC UA message, the interaction 217 process is significantly reduced, which is conducive to the 218 application of OPC UA in the restricted scene. The cost of 219 simplifying the interaction process is that the secure channel 220 number is set to 0 by default, how to conduct secure data 221 interaction needs further discussion[RESTful Industrial 222 Communication With OPC UA]. 224 3. Publish subscription for OPC UA and CoAP 226 As an application sublayer, CoAP provides publish-subscribe 227 functionality, primarily for resource or network-constrained 228 scenarios. Introducing broker into the network [draft-ietf-core- 229 coap-pubsub-00], when a node needs to sleep, the node information is 230 sent to the broker agent, when a node requests to obtain information 231 of this node, the broker release function can provide information. 232 OPC UA defines the publish-and-subscribe function as a service in 233 the service set. The client initiates the subscription request 234 directly to the server, and the server periodically sends the 235 information to the client. Comparing the characteristics of the two 236 protocols, it is found that each of them has its own advantages. 237 Joint design can be conducted for restricted devices. 239 4. Security Considerations 241 5. IANA Considerations 243 This memo includes no request to IANA. 245 6. References 247 6.1. Normative References 249 6.2. Informative References 251 [I-D.wang-core-opcua-transmition-requirements] 252 Wang, H., Pu, C., and Wang, P., " Requirements Analysis for 253 OPC UA over CoAP", draft-wang-core-opcua-transmition- 254 requirements-00 (work in progress), December 2016. 256 [I-D.ietf-core-http-mapping] 257 Castellani, A., Loreto, S., and Rahman, A., " Guidelines for 258 HTTP-to-CoAP Mapping Implementations", draft-ietf-core-http- 259 mapping-17 (work in progress), November 2016. 261 [Gruer] 262 Finn, N., Gruer, S., Pfrommer, J., and Palm, F., "RESTful 263 Industrial Communication With OPC UA", IEEE Trans. Ind. 264 Informat., Vol. 12, No. 5, October 2016. 266 [I-D.ietf-core-coap-pubsub] 267 Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe 268 Broker for the Constrained Application Protocol(CoAP)", 269 draft-ietf-core-coap-pubsub-00 (work in progress), October 270 2016. 272 Authors' Addresses 274 Ping Wang 275 Chongqing University of Posts and Telecommunications 276 2 Chongwen Road 277 Chongqing, 400065 278 China 280 Phone: (86)-23-6246-1061 281 Email: wangping@cqupt.edu.cn 283 Chenggen Pu 284 Chongqing University of Posts and Telecommunications 285 2 Chongwen Road 286 Chongqing, 400065 287 China 289 Phone: (86)-23-6246-1061 290 Email: mentospcg@163.com 292 Heng Wang 293 Chongqing University of Posts and Telecommunications 294 2 Chongwen Road 295 Chongqing, 400065 296 China 298 Phone: (86)-23-6248-7845 299 Email: wangheng@cqupt.edu.cn 301 Yi Yang 302 Chongqing University of Posts and Telecommunications 303 2 Chongwen Road 304 Chongqing, 400065 305 China 307 Phone: (86)-23-6248-7845 308 Email: 382991208@qq.com 310 Lun Shao 311 Chongqing University of Posts and Telecommunications 312 2 Chongwen Road 313 Chongqing, 400065 314 China 315 Phone: (86)-23-6246-1061 316 Email: yjsslcqupt@163.com