idnits 2.17.1 draft-wang-core-opcua-transmission-01.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 : ---------------------------------------------------------------------------- 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 (March 13, 2017) is 2572 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.ietf-core-coap-tcp-tls' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-coap-pubsub' is defined on line 444, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-07 == Outdated reference: A later version (-03) exists of draft-wang-core-opcua-transmition-requirements-00 == Outdated reference: A later version (-13) 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 P. Wang 2 Internet Draft C. Pu 3 Intended status: Standards Track H. Wang 4 Expires: September 14, 2017 Y. Yang 5 L. Shao 6 Chongqing University of 7 Posts and Telecommunications 8 J. Hou 9 Huawei Technologies 10 March 13, 2017 12 OPC UA Message Transmission Method over CoAP 13 draft-wang-core-opcua-transmission-01 15 Abstract 17 OPC Unified Architecture (OPC UA) is a data exchange standard that 18 provides interoperability in industrial automation. With the coming 19 Industry 4.0, it is of great importance to implement the exchange of 20 semantic information utilizing OPC UA Transmitting in CoAP. This 21 document provides some transmission methods for message of OPC UA 22 over CoAP. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on September 14, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction ................................................ 2 65 1.1. Conventions and Terminology ............................ 3 66 2. Overview of OPC UA .......................................... 3 67 2.1. Protocol Stack ......................................... 3 68 2.2. Request/Response Model ................................. 4 69 3. Specification of OPC UA over CoAP ........................... 5 70 4. Transmission scheme ......................................... 6 71 4.1. Proxy for OPC UA-CoAP .................................. 6 72 4.2. Direct transmission .................................... 7 73 4.3. REST transmission for OPC .............................. 8 74 5. Publish subscription for OPC UA and CoAP .................... 9 75 6. Security Considerations ..................................... 9 76 7. IANA Considerations ......................................... 9 77 8. References ................................................. 10 78 8.1. Normative References .................................. 10 79 8.2. Informative References ................................ 10 80 Authors' Addresses ............................................ 11 82 1. Introduction 84 Internet of things is one of the attractive applications for CoAP 85 [RFC7252]. Utilizing OPC UA [IEC TR 62541-1] Transmitting over CoAP 86 could meet the demand for industry 4.0 based on the exchange of 87 semantic information [I-D.wang-core-opcua-transmition-requirements]. 88 Similar to OPC UA, CoAP message is exchanged in server/client mode. 89 However, their transmission is not the same. Driven by this, to use 90 OPC UA Transmitting over CoAP, the major problem to be solved is how 91 OPC UA packets are transmitted over CoAP. For the transport layer of 92 OPC UA, the main message transmission method is TCP or HTTP, and 93 CoAP's design inspiration comes from HTTP, thus, there are some 94 connections in transmission method between them. This document 95 provides some transmission methods for message of OPC UA over CoAP, 96 so that a communication could be established between OPC UA client 97 and OPC UA server. 99 1.1. Conventions and Terminology 101 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 [RFC2119]. 106 OPC: OLE for Process Control 108 OPC UA: OPC Unified Architecture 110 SOAP: Simple Object Access Protocol 112 2. Overview of OPC UA 114 OPC Unified Architecture (OPC UA), standardized as IEC 62541, is a 115 client-server communication protocol developed by OPC Foundation for 116 safe, reliable data exchange in industrial automation. It is the 117 evolution product of OPC (OLE for Process Control, where OLE denotes 118 Object Linking and Embedding), the widely used standard process for 119 automation technology, and is of great importance in realizing 120 industry 4.0. By introducing Service-oriented architecture (SOA), 121 OPC UA enables an open, cross-platform communication with the 122 advantages of web services, robust security and integrated data 123 model. 125 2.1. Protocol Stack 127 OPC UA is an application layer protocol that can be built on an 128 existing layer 5, 6 or 7 protocol such TCP/IP, TLS or HTTP. The OPC 129 UA application layer consists of four sublayers: UA Application, 130 Serialization Layer, Secure Channel Layer and Transport Layer (see 131 Figure 1). 133 Serialization Layer includes two kinds of data encoding methods: UA 134 Binary and UA XML. The UA XML, based on SOAP/HTTP or SOAP/HTTPS, is 135 firewall friendly. On the other hand, the UA Binary, with least 136 overhead and resource cost, offers an optimized speed and throughput. 138 The security layer varies according to the selected encoding format. 139 For the HTTPS-based situation, security is guaranteed at TLS but 140 Security Channel should still be presented even empty. It is 141 worthwhile noting that the communication based on SOAP/HTTP has been 142 deprecated since 2015 due to the lack of industrial approbation in 143 the WS Secure Conversation. 145 For the transport layer (not the layer in OSI 7 layer model), 146 options can be UA TCP, HTTPS, SOAP/HTTPS, and SOAP/HTTP. OPC UA 147 defines a UA TCP protocol, which differs from HTTP in two main 148 features: the allowance of responses to be returned in any order and 149 to be returned on a different TCP transport end-point. In addition, 150 UA TCP defines the interaction with the upper security channel. 152 +-------------------------------------------------------+ ------ 153 | UA Application | 154 +-------------------------------------------------------+ 155 +--------------------------+ +--------------------------+ 156 | UA Binary | | UA XML | 157 +--------------------------+ +--------------------------+ 158 +--------------+ +--------------+ App 159 | UA Secure | | WS Secure | 160 | Conversation | | Conversation | Layer 161 +--------------+ +--------------+ 162 +--------------+ +---------+ +---------+ +--------------+ 163 | | | | | SOAP | | SOAP | 164 | UA TCP | | HTTPS | |---------| |--------------| 165 | | | | | HTTPS | | HTTP | 166 +--------------+ +---------+ +---------+ +--------------+ ------ 167 +-------------------------------------------------------+ 168 | TCP/IP | 169 +-------------------------------------------------------+ 171 Figure 1: Layering of OPC UA over TCP/IP 173 2.2. Request/Response Model 175 The message exchange in UA binary mode is illustrated in Figure 2. 176 After opening the socket, the client starts the connection with the 177 server by using "hello" (HEL) and "acknowledge" (ACK) messages. 178 Afterwards, a pair of messages is needed to open the security 179 channel and define the encryption property. Then another two pairs 180 of messages are exchanged so as to create and activate a session 181 between the client and the server respectively. After these steps, 182 the connection is initiated and the client can send request messages 183 for services. When the request/response process is finished, a 184 reverse process is required for disconnection. 186 Client Secure UA UA Secure Server 187 Channel TCP TCP Channel 188 | | | Open Socket | | | 189 | | | - - - - - - - - - > | | | 190 | | | Hello | | | 191 | | | - - - - - - - - - > | | | 192 | | | Acknowledge | | | 193 | | | < - - - - - - - - - | | | 194 | | | | | | 195 | | |OpenSecureChannelReq | | | 196 | | - - - - - - - - - - - - - - - - - > | | 197 | | |OpenSecureChannelRes | | | 198 | | < - - - - - - - - - - - - - - - - - | | 199 | | | | | | 200 | | | CreateSessionReq | | | 201 | - - - - - - - - - - - - - - - - - - - - - - - - - > | 202 | | | CreateSessionRes | | | 203 | < - - - - - - - - - - - - - - - - - - - - - - - - - | 204 | | | ActivateSessionReq | | | 205 | - - - - - - - - - - - - - - - - - - - - - - - - - > | 206 | | | ActivateSessionRes | | | 207 | < - - - - - - - - - - - - - - - - - - - - - - - - - | 208 | | | | | | 209 | | | Request | | | 210 | = = = = = = = = = = = = = = = = = = = = = = = = = > | 211 | | | Response | | | 212 | < = = = = = = = = = = = = = = = = = = = = = = = = = | 214 Figure 2: Request/Response Process of UA TCP 216 3. Specification of OPC UA over CoAP 218 As mentioned in section 2.1, OPC UA communications can be processed 219 through four options, among which two are related to HTTPS: HTTPS => 220 UA Binary; HTTPS => SOAP => UA XML. HTTPS is a security-guaranteed 221 protocol consisting of a HTTP layer over Transport Layer Security 222 (TLS), thus the UA Security Channel can be left empty. 224 Constrained Application Protocol (CoAP) is an application layer 225 protocol for constrained nodes and networks, which is designed to 226 easily translate to HTTP for integration with the web. Although CoAP 227 is built on the unreliable transport layer UDP, it offers a security 228 mode binding to Datagram Transport Layer Security (DTLS). This 229 document proposes a transmission scheme based on CoAPs (CoAP + DTLS) 230 for constrained scenarios. The transmission based on CoAP over 231 Transport Layer Security (TLS) is also possible. Such "CoAP + TLS" 232 transmission scheme is under development [I-D.ietf-core-coap-tcp- 233 tls] and would be covered in the future version. 235 The protocol stack of the CoAP based OPC UA is illustrated in Figure 236 3 including two options at Serialization Layer: UA Binary and UA XML. 237 OPC UA packets are encoded in either binary or xml format, and the 238 option field in the CoAP header can specify parameters that support 239 both formats. Therefore, according to the format specified by the 240 CoAP header, the entire packet of the OPC UA can be encapsulated in 241 the payload of the CoAP message for direct transmission. 243 +-------------------------------+ ------ 244 | UA Application | 245 +-------------------------------+ 246 +--------------+ +--------------+ 247 | UA Binary | | UA XML | App 248 +--------------+ +--------------+ 249 +-------------------------------+ 250 | Secure Channel | Layer 251 +-------------------------------+ 252 +-------------------------------+ 253 | CoAP | 254 +-------------------------------+ ------ 255 +-------------------------------+ 256 | UDP, DTLS | 257 +-------------------------------+ 259 Figure 3: Layering of OPC UA over UDP 261 Both binary and XML encoding modes are based on the CoAP with an 262 empty UA secure channel in between. For the XML encoding mode, since 263 CoAP layer supports XML encoding format, the SOAP layer in the 264 original stack is not needed. 266 4. Transmission scheme 268 4.1. Proxy for OPC UA-CoAP 270 OPC UA is a protocol mainly for application layer, which defines 271 many services for the different needs of industrial applications. 272 Message is exchanged mainly through server/client mode, utilizing 273 TCP or HTTPS. When security is ignored, OPC UA can be considered to 274 support HTTP transmission. CoAP's design inspiration comes mainly 275 from HTTP, the two can be mapped between each other to meet the 276 needs of some special scenes [RFC8075]. Combined with the 277 characteristics of OPC UA and CoAP, a CoAP proxy can be established 278 between OPC UA client and OPC UA server. The architecture is shown 279 in Figure 4. 281 ----------------------------- 282 // +---------+ \\ 283 || | UA-CoAP | || 284 || // | server | || 285 || // +---------+ || 286 || // || 287 || // || 288 +---------+ HTTP Request +------------+ CoAP Request +---------+|| 289 | UA | ------------> |HTTP-to-CoAP| -------------> | UA-CoAP ||| 290 | client | <------------ | PROXY | <------------- | server ||| 291 +---------+ HTTP Response +------------+ CoAP Response +---------+|| 292 || \\ || 293 || \\ || 294 || \\ || 295 || \\ +---------+ || 296 || \\ | UA-CoAP | || 297 || | server | || 298 \\ +---------+ // 299 ------------------------------ 300 Figure 4: Proxy for OPC UA to CoAP 302 As shown in Figure 5, assume all OPC UA servers are based on CoAP 303 [I-D.wang-core-opcua-transmition-requirements], and all OPC UA- 304 CoAP server can be viewed as a network, introducing UA-to-CoAP proxy 305 at the boundary of the network. When a traditional OPC UA client 306 initiates an HTTP request to the UA-CoAP server in the network, the 307 UA-to-CoAP proxy maps the http request to the corresponding CoAP 308 request and sends it to the UA-CoAP server in the network. After 309 receiving the request, the UA-CoAP server sends a response to the 310 UA-CoAP proxy. The proxy maps the CoAP response to the HTTP response 311 and returns it to the UA client. For the UA client, the network 312 proxy and conversion is transparent, in this way, the transfer of 313 OPC UA in CoAP does not need to make any changes to the UA Client. 315 4.2. Direct transmission 317 The transmission of OPC UA supports TCP protocol and HTTP protocol, 318 when security is ignored, OPC UA can be considered to support HTTP 319 transmission. On the other hand, CoAP is seen as a simplified HTTP 320 protocol so that it can be applied to resource-constrained network. 321 Therefore, this document considers the use of CoAP to directly 322 transfer OPC UA messages. OPC UA packets are encoded in either 323 binary or xml format, and the optional fields in the CoAP header 324 specify parameters that support these two formats, and the option 325 field in the CoAP header can specify parameters that support both 326 formats. Therefore, according to the format specified by the CoAP 327 header, the entire packet of the OPC UA can be encapsulated in the 328 payload of the CoAP message for direct transmission, as shown in 329 Figure 5. Noted that this method of transmission needs to be 330 modified on the server side and the client side of the OPC UA 331 according to CoAP. 333 + - - - - - - + CoAP Request + - - - - - - + 334 | UA client | - - - - - - - - - - > | UA server | 335 | | < - - - - - - - - - - | | 336 + - - - - - - + CoAP Response + - - - - - - + 338 Figure 5: Direct transmission OPC UA based on CoAP 340 4.3. REST transmission for OPC UA 342 OPC UA is a set of data exchange specifications for industrial 343 communication, the core of the OPC UA protocol is information 344 modeling and transmission, which marks each node in the address 345 space with a unique identifier. A series of state interactions are 346 needed before performing normal reading and writing, including 347 message handshaking, opening a secure channel, creating a session, 348 activating a session, etc. Besides, some states also need to be 349 maintained during read and write operations. 351 In OPC UA, each node has an independent identifier in the address 352 space, and different types of nodes can establish contact with each 353 other by reference. OPC UA defines a variety of services, and these 354 services are fixed, the user cannot arbitrarily modify, each service 355 is invoked through a single message, without relying on the previous 356 message, the service response is also completed by a separate 357 message and do not rely on other messages. The above features are in 358 line with the REST architecture, due to CoAP is based on the REST 359 architecture. Therefore, it is possible to simplify the interaction 360 before the OPC UA performs the normal communication, and carry the 361 OPC UA message by using the communication mode of the CoAP. 362 Communication process is shown in Figure 6. 364 + - - - - + + - - - - + 365 | client | | server | 366 + - - - - + + - - - - + 367 | | 368 | | 369 | CoAPRequest | 370 | - - - - - - - - - > | 371 | CoAPResponse | 372 | < - - - - - - - - - | 374 Figure 6: REST architecture communication of OPC UA 376 In Figure 2, the traditional OPC UA requires a series of 377 interactions between normal read and write operations. Figure 6 378 shows that when using CoAP to carry OPC UA message, the interaction 379 process is significantly reduced, which is conducive to the 380 application of OPC UA in the restricted scene. The cost of 381 simplifying the interaction process is that the secure channel 382 number is set to 0 by default, how to conduct secure data 383 interaction needs further discussion. 385 5. Publish subscription for OPC UA and CoAP 387 As an application sublayer, CoAP provides publish-subscribe 388 functionality, primarily for resource or network-constrained 389 scenarios. Introducing broker into the network [I-D.ietf-core- 390 coap-pubsub], when a node needs to sleep, the node information is 391 sent to the broker agent, when a node requests to obtain information 392 of this node, the broker release function can provide information. 393 OPC UA defines the publish-and-subscribe function as a service in 394 the service set. The client initiates the subscription request 395 directly to the server, and the server periodically sends the 396 information to the client. Comparing the characteristics of the two 397 protocols, it is found that each of them has its own advantages. 398 Joint design can be conducted for constrained applications. 400 TODO. 402 6. Security Considerations 404 7. IANA Considerations 406 This memo includes no request to IANA. 408 8. References 410 8.1. Normative References 412 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 413 Application Protocol", RFC 7252, June 2014, 414 . 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", RFC 2119, March 1997, 418 . 420 [RFC8075] Castellani, A., Loreto, S., and A. Rahman, "Guidelines for 421 HTTP-to-CoAP Mapping Implementations", RFC 8075, November 422 2016, . 424 8.2. Informative References 426 [IEC TR 62541-1] 427 IEC, "OPC unified architecture-Part1:Overview and concepts- 428 IEC 62541", 2016, < 429 https://webstore.iec.ch/preview/info_iec62541- 430 1%7Bed2.0%7Den.pdf>. 432 [I-D.ietf-core-coap-tcp-tls] 433 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 434 Silverajan, B., and B. Raymor, "CoAP (Constrained Application 435 Protocol) over TCP, TLS, and WebSockets", draft-ietf-core- 436 coap-tcp-tls-07 (work in progress), March 2017. 438 [I-D.wang-core-opcua-transmition-requirements] 439 Wang, H., Pu, C., Wang, P., Yang, Y., and D. Xiong, 440 "Requirements Analysis for OPC UA over CoAP", draft-wang- 441 core-opcua-transmition-requirements-00 (work in progress), 442 December 2016. 444 [I-D.ietf-core-coap-pubsub] 445 Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe 446 Broker for the Constrained Application Protocol(CoAP)", 447 draft-ietf-core-coap-pubsub-00 (work in progress), October 448 2016. 450 Authors' Addresses 452 Ping Wang 453 Chongqing University of Posts and Telecommunications 454 2 Chongwen Road 455 Chongqing, 400065 456 China 458 Phone: (86)-23-6246-1061 459 Email: wangping@cqupt.edu.cn 461 Chenggen Pu 462 Chongqing University of Posts and Telecommunications 463 2 Chongwen Road 464 Chongqing, 400065 465 China 467 Phone: (86)-23-6246-1061 468 Email: mentospcg@163.com 470 Heng Wang 471 Chongqing University of Posts and Telecommunications 472 2 Chongwen Road 473 Chongqing, 400065 474 China 476 Phone: (86)-23-6248-7845 477 Email: wangheng@cqupt.edu.cn 479 Yi Yang 480 Chongqing University of Posts and Telecommunications 481 2 Chongwen Road 482 Chongqing, 400065 483 China 485 Phone: (86)-23-6248-7845 486 Email: 382991208@qq.com 488 Lun Shao 489 Chongqing University of Posts and Telecommunications 490 2 Chongwen Road 491 Chongqing, 400065 492 China 493 Phone: (86)-23-6246-1061 494 Email: yjsslcqupt@163.com 496 Jianqiang Hou 497 Huawei Technologies CO.,LTD 498 101 Software Avenue, 499 Nanjing 210012 500 China 502 Phone: (86)-15852944235 503 Email: houjianqiang@huawei.com