idnits 2.17.1 draft-groves-coap-webrtcdc-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: On establishment of the CoAP over WebRTC DC the client and server MAY send a CoAP Capability and Settings message (CSM see Section 4.3/[I-D.ietf-core-coap-tcp-tls]) as its first message on the connection to establish CoAP specific capabilities. Any capabilities signalled SHALL not contradict previously negotiated chracteristics. Consideration for the individual options are below: == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: WebRTC DCs allows the indication of whether a SCTP user message is empty through the use of PPIDs (WebRTC String Empty and WebRTC Binary Empty). CoAP defines the use of empty messages. However from the perspective of SCTP these CoAP messages would still contain header information thus PPIDs for empty data MUST not be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: CoAP uses an Empty Confirmable message to provoke a Reset message to check the liveness of an endpoint (so called "CoAP" ping). In WebRTC liveness and the ability to send data is determined through the usage of Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness [RFC7675]. Therefore endpoints utilising CoAP over WebRTC DC MUST not use CoAP "reset" messages. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: CoAP also uses Empty messages to acknowledge a request. This is not required due to the SCTP level acknowledgement. Therefore Empty messages MUST not be used with CoAP over WebRTC. -- The document date (October 17, 2016) is 2748 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-10 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-18 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-16 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-15 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-08 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-12 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-07 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-05 == Outdated reference: A later version (-11) exists of draft-silverajan-core-coap-alternative-transports-09 Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Groves 3 Internet-Draft W. Yang 4 Intended status: Informational Huawei 5 Expires: April 20, 2017 October 17, 2016 7 A WebRTC Data Channel Transport for the Constrained Application Protocol 8 (CoAP) 9 draft-groves-coap-webrtcdc-01 11 Abstract 13 The WebRTC framework defines a generic transport service allowing 14 WEB-browsers and other endpoints to exchange generic data from peer 15 to peer utilizing a Stream Control Transmission Protocol (SCTP) 16 transport. This service is known as Web Real Time Communication 17 WebRTC data channels (WebRTC DC). The use of WebRTC DCs for the 18 Constrained Application Protocol (CoAP) allows WebRTC enabled devices 19 to exchange CoAP data between peers in a secure reliable manner. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 20, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 57 3. Constrained Application Protocol . . . . . . . . . . . . . . 5 58 3.1. Message Model . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Request Response Model . . . . . . . . . . . . . . . . . 6 60 3.3. Intermediaries and Caching . . . . . . . . . . . . . . . 7 61 3.4. Resource Discovery . . . . . . . . . . . . . . . . . . . 7 62 3.5. Opening Handshake . . . . . . . . . . . . . . . . . . . . 7 63 3.6. Message Format . . . . . . . . . . . . . . . . . . . . . 8 64 3.7. Option Format and Value . . . . . . . . . . . . . . . . . 9 65 4. Message Transmission . . . . . . . . . . . . . . . . . . . . 9 66 4.1. Messages and Endpoints . . . . . . . . . . . . . . . . . 10 67 4.2. Messages Transmitted Reliably . . . . . . . . . . . . . . 10 68 4.3. Messages Transmitted without Reliability . . . . . . . . 11 69 4.4. Message Correlation . . . . . . . . . . . . . . . . . . . 11 70 4.5. Message Duplication . . . . . . . . . . . . . . . . . . . 11 71 4.6. Message Size . . . . . . . . . . . . . . . . . . . . . . 11 72 4.7. Congestion Control . . . . . . . . . . . . . . . . . . . 12 73 4.8. Transmission Parameters . . . . . . . . . . . . . . . . . 12 74 5. Request/Response Semantics . . . . . . . . . . . . . . . . . 12 75 6. CoAP URI . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.1. coaps+wr URI scheme . . . . . . . . . . . . . . . . . . . 13 77 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 13 79 7.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 14 80 8. Multicast CoAP . . . . . . . . . . . . . . . . . . . . . . . 14 81 9. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 14 82 10. Interworking . . . . . . . . . . . . . . . . . . . . . . . . 14 83 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 12.1. New WebRTC DC Protocol Value . . . . . . . . . . . . . . 15 86 12.2. Secure Service Name and Port Number Registration . . . . 16 87 12.3. ALPN Protocol ID . . . . . . . . . . . . . . . . . . . . 16 88 12.4. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 16 89 12.5. New SIP Media Feature Tag . . . . . . . . . . . . . . . 16 90 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 92 15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 16.1. Normative References . . . . . . . . . . . . . . . . . . 19 95 16.2. Informative References . . . . . . . . . . . . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 98 1. Introduction 100 Whilst the Constrained Application Protocol (CoAP) [RFC7252] was 101 designed for Internet of Things (IoT) deployments in constrained 102 network environments its ready adoption has seen the use of it in a 103 multitude of different network environments. For example 104 [I-D.silverajan-core-coap-alternative-transports] provides use cases 105 for alternate CoAP transports. 107 [I-D.ietf-core-coap-tcp-tls] highlights a number of issues using the 108 native User Datagram Transport (UDP) and envisages deployments more 109 closely integrated with a Web environment. It also proposes the use 110 of the WebSocket protocol [RFC6455]. The use of CoAP over WebRTC DCs 111 has not yet been discussed. 113 WebRTC is a framework [I-D.ietf-rtcweb-overview] that defines real 114 time protocols for browser-based applications. It allows 115 communications between peer WebRTC endpoints (e.g. browsers) without 116 the need to communicate through a web server. 118 In addition to protocols for the realtime transport of audio and 119 video, the transport of generic peer-to-peer non-media data has been 120 defined using WebRTC DCs. The non-media data is transported using 121 the Stream Control Transmission Protocol (SCTP) [RFC4960] 122 encapsulated in the Datagram Transport Layer Security (DTLS) 123 [RFC6347]. It allows both reliable and partially reliable transport 124 and provides confidentiality, source authenticated and integrity 125 protected transfers. The use of Interactive Connectivity 126 Establishment (ICE) [RFC5245] allows network address translator (NAT) 127 traversal. The SCTP/DTLS association may be shared with existing 128 audio and video streams enabling multiplexing of several data streams 129 over a single port further facilitating NAT traversal. 131 Use cases for WebRTC DCs (section 3.1/[I-D.ietf-rtcweb-data-channel] 132 envisage scenarios where the real-time gaming experience is enhanced 133 by additional object state information. Additional scenarios are 134 considered where information such as heart rate sensor or oxygen 135 saturation sensors could augment audio and video in remote medicine 136 scenarios. The transport of such sensor information is what CoAP has 137 been designed for. 139 This is illustrated in Figure 1 showing the WebRTC Trapeziod with 140 added sensor/CoAP information. The left hand side WebRTC endpoint 141 acts as a CoAP to CoAP proxy. 143 +-----------+ +-----------+ 144 | Web | | Web | 145 | | Signaling | | 146 | |-------------| | 147 | Server | path | Server | 148 | | | | 149 +-----------+ +-----------+ 150 / \ 151 / \ Application- 152 / \ defined over 153 / \ HTTP/Websockets 154 / Application-defined over \ 155 / HTTP/Websockets \ 156 / \ 157 +-----------+ +-----------+ 158 |JS/HTML/CSS| |JS/HTML/CSS| 159 +-----------+ +-----------+ 160 +-----------+ +-----------+ 161 SensorA | | | | 162 CoAP/UDP | | | | 163 +------+ Browser | ------------------------- | Browser + 164 | | Media path | | 165 | | (CoAP/WebRTC DC) | | 166 +-----------+ +-----------+ 168 Figure 1: CoAP and WebRTC Trapeziod 170 By utilizing the WebRTC DC (SCTP over DTLS over ICE/UDP (or ICE/TCP)) 171 transport for CoAP a number of important features are inherited 172 including: congestion control, order and unordered messages delivery, 173 large message transmission by providing segmentation and reassembly 174 and multiple unidirectional streams. A more detailed analysis of the 175 benefits of WebRTC DCs can be found in section 176 5/[I-D.ietf-rtcweb-data-channel]. [I-D.ietf-tsvwg-sctp-dtls-encaps] 177 describes the usage of SCTP over DTLS. 179 WebRTC defines in-band and out-of-band methods for establishing a 180 data channel and indicating its characteristics. The Data Channel 181 Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] 182 provides an in band means of establishing individual data channels. 183 [I-D.ietf-mmusic-data-channel-sdpneg] uses the Session Description 184 Protocol (SDP) [RFC4566] to provide an out-of-band means to establish 185 data channels. 187 By defining the use of CoAP over WebRTC DC it negates the need for 188 the WebRTC endpoint to interwork between any CoAP messages received 189 from local devices to a proprietary WebRTC DC format when signalling 190 a remote WebRTC endpoint. 192 The SCTP Payload Protocol Identifier (PPID) allows the identification 193 of whether a UTF-8 or Binary encoding is being used and thus 194 facilitates the use of text or binary CoAP protocol serializations. 196 2. Requirements Language 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 200 "OPTIONAL" in this document are to be interpreted as described in 201 [RFC2119]. 203 3. Constrained Application Protocol 205 This section describes the use of CoAP over WebRTC DC as a delta to 206 the information contained in section 2/[RFC7252]. 208 Figure 2 shows the CoAP abstract layering as applied to the WebRTC 209 framework. 211 +---------------------------+ 212 | Application | 213 +------+------+-------------+ \ 214 | DCEP | Requests/Responses | | 215 | +--------------------| | CoAP 216 | | Messages | | 217 +------+--------------------+ / 218 | SCTP | 219 +-----------------------------------------+ 220 | STUN | SRTP | DTLS | 221 +-----------------------------------------+ 222 | ICE | 223 +-----------------------------------------+ 224 | UDP1 | UDP2 | UDP3 | ... | 225 +-----------------------------------------+ 227 Figure 2: WebRTC protocol layers including CoAP 229 WebRTC DC mandates the use of SCTP over DTLS. Whilst the above 230 diagram indicates the use of ICE over UDP the use of TCP is also 231 possible in fall back scenarios. 233 3.1. Message Model 235 WebRTC DC allows application protocol messages to be exchanged by 236 peers. WebRTC supports both a reliable and partially reliable 237 methods of transmitting user messages. 239 CoAP [RFC7252] supports four message types "Confirmable, Non- 240 Confirmable, Acknowledge and Reset". As SCTP provides the 241 reliability mechanism the CoAP message types are not needed for CoAP 242 over WebRTC DC. 244 WebRTC DC does not support multicast usage. 246 3.2. Request Response Model 248 WebRTC DCs are realized as a pair of one incoming and one outgoing 249 SCTP stream (with the same identifier) allowing bi-directional 250 communication. Each channel has properties (see section 251 6.4/[I-D.ietf-rtcweb-data-channel] as discussed below: 253 o reliable or unreliable message transmission: WebRTC DCs support 254 the per message indication whether user messages are reliable or 255 partially reliable. Partial reliability indicates that message 256 retransmission is limited to a certain number of retransmissions 257 or lifetime. This loosely parallels to the CoAP usage of 258 Confirmable (CON) or Non-confirmable (NON) messages. 260 o in-order or out-of-order message delivery: WebRTC DCs support the 261 per message indication whether user messages are delivered in or 262 out of order. CoAP has been designed for unreliable transports 263 and therefore assumes that messages may arrive out-of-order. CoAP 264 implements a lightweight reliability mechanism to deal with this 265 issue. 267 o priority: WebRTC DCs allows a priority to specified for stream 268 scheduling. The usage of this is application specific. Usage of 269 CoAP has no impact on this parameter. It's up to the application 270 using CoAP to set this indication. 272 o an optional label: This is an application/implementation specific 273 label. Uniqueness is not guaranteed. Usage of CoAP has no impact 274 on this parameter. 276 o an optional protocol: This is used to indicate the application 277 protocol in use. A value is required to identify the usage of 278 CoAP. 280 As discussed above WebRTC DC supports an unreliable / un-ordered 281 delivery of messages. Implementations utilizing these data channel 282 characteristics may use CoAP messages and request/response model 283 largely unchanged. In this case the CoAP reliability mechanisms 284 would be used. However as WebRTC DC's usage of SCTP is reliable or 285 partially reliable there is some redundancy between the functionality 286 that WebRTC DCs and CoAP provides. 288 The redundancies are identified and discussed in section 289 2/[I-D.ietf-core-coap-tcp-tls]. Namely: 291 1. There is no need to carry acknowledgement semantics at a CoAP 292 level. 294 2. There is no need for duplicate delivery detection. This is part 295 of the SCTP layer. 297 3.3. Intermediaries and Caching 299 As CoAP over WebRTC DC is peer to peer no intermediares or caching is 300 expected. 302 3.4. Resource Discovery 304 The usage of CoAP over WebRTC DC has no foreseeable impacts on 305 resource discovery. 307 3.5. Opening Handshake 309 Prior to the establishment of a CoAP over WebRTC DC the 310 characteristics of the SCTP association and data channel may be 311 negotiated by signalling. See Section 4 for further details. For 312 example when using SDP [I-D.ietf-mmusic-sctp-sdp] the use of the "SDP 313 max-message-size" attribute indicates the maximum received SCTP 314 message size. 316 Further characteristics (such as those described in Section 3.2) are 317 negotiated at the establishment of the WebRTC DC. 319 On establishment of the CoAP over WebRTC DC the client and server MAY 320 send a CoAP Capability and Settings message (CSM see 321 Section 4.3/[I-D.ietf-core-coap-tcp-tls]) as its first message on the 322 connection to establish CoAP specific capabilities. Any capabilities 323 signalled SHALL not contradict previously negotiated chracteristics. 324 Consideration for the individual options are below: 326 o Server-Name Setting: CoAP over WebRTC DC clients MAY use the 327 server-name setting option. The initial value is derived based on 328 the signalling method used to establish the WebRTC peer to peer 329 communications. WebRTC does not mandate a signalling method. For 330 example if Websockets is used then the value may be taken from the 331 HTTP host header field. 333 o Max-message size Capability: The CoAP Max-Message-Size shall not 334 exceed the SCTP message size. 336 o Block-wise Transfer Capability: CoAP over WebRTC DC client and 337 server MAY support the use of BERT 338 (Section 5/[I-D.ietf-core-coap-tcp-tls]). See Section 4.6 for 339 message size considerations. 341 o Ping and Pong Messages: Ping and Pong messages MAY be sent by CoAP 342 over WebRTC DC clients and servers. However its use as a basic 343 keepalive is not required as WebRTC defines a method to determine 344 liveness (see Section 4.1). 346 o Release Messages: CoAP over WebRTC DC clients and servers may 347 support the CoAP Release message. On receipt of a release message 348 the CoAP over WebRTC DC SHALL be closed as per Section 4. 350 o Abort Messages: CoAP over WebRTC DC clients and servers may 351 support the CoAP Abort message. Senders SHALL then close the CoAP 352 over WebRTC DC as per Section 4. 354 3.6. Message Format 356 As discussed in [I-D.ietf-core-coap-tcp-tls] the use of a reliable 357 underlying transport allows the use of a modified CoAP header format. 358 The modified format removes the "Type (T)" and "Message ID" fields 359 and introduces a "length" as illustrated below in Figure 3. 361 0 1 2 3 362 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 |Len=13 | TKL | Length (8-bit)| Code | TKL bytes ... 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Options (if any) ... 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 |1 1 1 1 1 1 1 1| Payload (if any) ... 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 3: CoAP Header with TCP with 8-bit Length in Header 373 CoAP over WebRTC DC implementations shall also use the message format 374 in Figure 3 with the following consideration: 376 o The length field was added for message delimitation to keep 377 messages separate in TCP. WebRTC DC uses the message orientation 378 of SCTP to preserve message boundaries thus the use of single 379 application message per SCTP user message is mandated by the 380 WebRTC framework. The length field shall be set to 0. 382 CoAP [RFC7252] supports the use of different content-formats. WebRTC 383 DC defines the use of PPIDs per SCTP user message as follows: 385 o WebRTC String: to identify a non-empty JavaScript string encoded 386 in UTF-8. 388 o WebRTC Binary: to identify a non-empty JavaScript binary data 389 (ArrayBuffer, ArrayBufferView or Blob). 391 Depending on the content-format (see section 12.3/[RFC7252]) an 392 appropriate PPID to the encoding type SHOULD be used to minimise the 393 need for translating between encodings. For example content type of 394 "text/plain" would result in the use of PPID "WebRTC String". 396 Author's note: Specific mappings for each content-format could be 397 provided however given that the formats may change in the future it 398 may be sufficient to offer broad guidance instead. 400 3.7. Option Format and Value 402 There are no impacts to option formats or values due to the use of 403 CoAP over WebRTC DCs. 405 Author's note: Given that the host is determined by the usage of 406 WebRTC are the Uri-Host and Uri-Port relevant? It would seem that 407 this may be valuable to establish a resource tree independent of 408 WebRTC. 410 4. Message Transmission 412 In order to use a WebRTC DC, a SCTP over DTLS over ICE/UDP (or ICE/ 413 TCP) association must be established. A DTLS connection is 414 established followed by an SCTP association. The out-of-band 415 establishment method through the use of SDP-based Data Channel 416 Negotiation [I-D.ietf-mmusic-data-channel-sdpneg] allows the 417 negotiation of SCTP over DTLS over ICE/UDP as well as the negotiation 418 and establishment of the characteristics of an individual WebRTC DC. 420 The in-band establishment method through the use of the Data Channel 421 Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] only 422 allows for the establishment of a WebRTC DC once the SCTP over DTLS 423 is established. It relies on DATA_CHANNEL_OPEN and DATA_CHANNEL_ACK 424 messages on the relevant SCTP stream to negotiate the properties of 425 the channel. A separate SCTP PPID (50) indicates that the SCTP user 426 message is a WebRTC DCEP message to allow de-multiplexing by the 427 endpoint. 429 WebRTC DCs are realized as a pair of one incoming and one outgoing 430 SCTP stream (with the same identifier). Requests are sent on an 431 outgoing SCTP stream and received on the peer incoming stream. The 432 SCTP stream identifier is bound to the WebRTC DC instance at the 433 establishment of the data channel. The establishment protocol 434 provides rules for determining the SCTP stream IDs. 436 WebRTC DC closure (Stream Reset) is supported through the use of the 437 SCTP stream reconfiguration extension defined in [RFC6525]. The SCTP 438 Stream Reconfiguration reset has the effect of setting the numbering 439 sequence of the SCTP stream back to zero. This is separate function 440 to the CoAP "Reset" message. There is no mapping between the SCTP 441 Stream Reset and the CoAP "Reset" message. 443 4.1. Messages and Endpoints 445 As per section 2.5/[I-D.ietf-core-coap-tcp-tls] requests can be sent 446 from both the connecting host and the endpoint that accepted the 447 connection. Who initiated the SCTP/DTLS connection has no bearing on 448 the meaning of the CoAP terms client and server. 450 WebRTC DC mandates the use of DTLS thus the endpoint is identified 451 depending on the security mode. 453 WebRTC DCs allows the indication of whether a SCTP user message is 454 empty through the use of PPIDs (WebRTC String Empty and WebRTC Binary 455 Empty). CoAP defines the use of empty messages. However from the 456 perspective of SCTP these CoAP messages would still contain header 457 information thus PPIDs for empty data MUST not be used. 459 CoAP uses an Empty Confirmable message to provoke a Reset message to 460 check the liveness of an endpoint (so called "CoAP" ping). In WebRTC 461 liveness and the ability to send data is determined through the usage 462 of Session Traversal Utilities for NAT (STUN) Usage for Consent 463 Freshness [RFC7675]. Therefore endpoints utilising CoAP over WebRTC 464 DC MUST not use CoAP "reset" messages. 466 CoAP also uses Empty messages to acknowledge a request. This is not 467 required due to the SCTP level acknowledgement. Therefore Empty 468 messages MUST not be used with CoAP over WebRTC. 470 4.2. Messages Transmitted Reliably 472 For CoAP messages marked as confirmable the sender SHALL use a 473 reliable SCTP user message. 475 A CoAP endpoint MUST use the ordered delivery SCTP service, as 476 described in [RFC4960], for the CoAP protocol. 478 CoAP receivers MUST NOT generate CoAP "ACK" or "reset" messages. 479 SCTP level acknowledgement mechanisms are used. 481 4.3. Messages Transmitted without Reliability 483 WebRTC DC makes use of the SCTP Partial Reliability (SCTP-PR) 484 Extension [RFC3758]. This extension allows a user to indicate on a 485 per message basis how persistent the transport service should be in 486 attempting to send the message to the receiver. One of the benefits 487 of using this extension identified by [RFC3758] is: 489 1. Some application layer protocols may benefit from being able to 490 use a single SCTP association to carry both reliable content, - 491 such as text pages, billing and accounting information, setup 492 signaling - and unreliable content, e.g., state that is highly 493 sensitive to timeliness, where generating a new packet is more 494 advantageous than transmitting an old one. 496 This benefit is also one of the reasons the CoAP "Non-Confirmable" 497 message was introduced. However the SCTP-PR and the CoAP "Non- 498 Confirmable" message mechanisms differs in their approach. The SCTP- 499 PR mechanism focuses on sender side behaviour (e.g. when to abandon 500 retransmission). The CoAP "Non-Confirmable" message focuses on 501 receiver side behaviour (e.g. must not send a CoAP ACK). Even with 502 the use of SCTP-PR an SCTP receiver will send an SCTP level ACK for a 503 successfully received SCTP CHUNK. The CoAP "Non-Confirmable" message 504 has no effect on the SCTP level function. 506 Therefore the use of a CoAP "Non-Confirmable" message type is 507 redundant as the CoAP receiver will never send a CoAP ACK message in 508 response. 510 SCTP-PR provides a complimentary function and thus CoAP senders who 511 send Non-confirmable messages SHALL also use SCTP-PR for that 512 message. 514 4.4. Message Correlation 516 Due to reliability being handled at the SCTP layers the CoAP "Message 517 ID" is not required. 519 4.5. Message Duplication 521 The SCTP layer provides message duplication protection. The CoAP 522 application level procedure is not required. 524 4.6. Message Size 526 The considerations in section 4.1/[I-D.ietf-core-coap-tcp-tls] 527 regarding message size limitations also apply to the use of WebRTC 528 DCs. However [I-D.ietf-rtcweb-data-channel] indicates that senders 529 SHOULD limit the maximum message size to 16KB to avoid monopolization 530 of the SCTP association. Section 5/[I-D.ietf-tsvwg-sctp-dtls-encaps] 531 provides further details regarding segmentation and reassembly and 532 path maximum transmission unit (MTU) discovery. 534 Interleaving of large user messages is supported by an SCTP protocol 535 extension defined in [I-D.ietf-tsvwg-sctp-ndata]. 537 4.7. Congestion Control 539 SCTP provides congestion control on a per-association basis (see 540 section 5/[I-D.ietf-rtcweb-data-channel]. 542 4.8. Transmission Parameters 544 The application level parameters defined in section 4.8/[RFC7252] are 545 not relevant to SCTP. 547 5. Request/Response Semantics 549 Request and response semantics for CoAP over WebRTC DC is as per 550 section 5/[RFC7252] with the following exceptions: 552 o section 5.2/[RFC7252]: separate responses MUST be used. Given 553 that WebRTC DC provides an SCTP level acknowledgement it is not 554 possible to piggy back CoAP responses. 556 o section 5.3.1/[RFC7252]: due to the use of DTLS the advice 557 regarding token use without using TLS is invalid. 559 o section 5.3.2/[RFC7252]: In addition CoAP request/response 560 matching is unique to a particular WebRTC DC (SCTP StreamID pair). 562 o section 5.8/[RFC7252]: It is not possible to use a 4.05 563 piggybacked response. 565 6. CoAP URI 567 CoAP [RFC7252] defines the "coap" and "coaps" URI schemes for 568 identifying CoAP resources and providing a means of locating the 569 resource. [RFC7252] defines these resources for use with CoAP over 570 UDP. 572 Section 8/[RFC7252] (Multicast CoAP), does not apply to the URI 573 schemes defined in the present specification. 575 Resources made available via the "coaps+wr" schemes have no shared 576 identity with the other scheme or with the "coap" or "coaps" scheme, 577 even if their resource identifiers indicate the same authority (the 578 same host listening to the same port). The schemes constitute 579 distinct namespaces and, in combination with the authority, are 580 considered to be distinct origin servers. 582 6.1. coaps+wr URI scheme 584 coaps-wr-URI = "coaps+wr:" "//" host [ ":" port ] path-abempty 585 [ "?" query ] 587 The semantics defined in section 6.3/[RFC7252], apply to this URI 588 scheme, with the following changes: 590 o The port SHALL be omitted. The underlying UDP or TCP port and 591 SCTP port is negotiated prior to the establishment of the CoAP 592 over WebRTC DC. 594 7. Discovery 596 7.1. Service Discovery 598 WebRTC does not define peer discovery mechanisms. Peers discover 599 each other through the use of the ICE protocol. ICE candidates need 600 to be sent from peer to peer via signalling. The Javascript Session 601 Establishment Protocol (JSEP) [I-D.ietf-rtcweb-jsep] details the 602 generic SDP media descriptions for peer endpoints to determine the 603 characteristics of a session. The actual signalling protocol between 604 application servers is unspecified. WebRTC endpoints MUST implement 605 the network functions detailed by JSEP including ICE functionality. 607 Whilst the inter-application server signalling protocol is 608 unspecified, the Session Initiation Protocol (SIP) is able to carry 609 SDP for the purposes of establishing a CoAP over WebRTC DC session. 610 SIP allows the use of media feature tags to indicate user agent 611 capabilities [RFC3840]. In order to indicate that a SIP user agent 612 supports the use of CoAP a new "sip.coap" media feature tag is 613 proposed. A CoAP-capable endpoint SHOULD include this media feature 614 tag in its REGISTER requests and OPTION responses. It SHOULD also 615 include the media feature tag in INVITE and UPDATE [RFC3311] requests 616 and responses. Presence of the media feature tag in the contact 617 field of a requestor response can be used to determine that the far 618 end supports CLUE. 620 The exchange of SDP results in: the underlying transport address 621 (e.g. IPv4 or IPv6), the underlying transport port (e.g. UDP port) 622 the SCTP port and the SCTP StreamID used for the CoAP WebRTC DC being 623 exchanged between the peer endpoints. 625 7.2. Resource Discovery 627 On establishment of a CoAP WebRTC DC endpoints are able to use the 628 resource discovery mechanism defined in [RFC6690] for CoAP resources. 630 8. Multicast CoAP 632 WebRTC DCs do not support multicast. 634 9. Securing CoAP 636 This document defines how to convey CoAP over WebRTC DCs. The WebRTC 637 security architecture [I-D.ietf-rtcweb-security-arch] mandates the 638 use of DTLS for data channels. The use of DTLS 1.2 is compatible 639 with CoAP [RFC7252] which allows makes use of DTLS 1.2. 641 The use of DTLS for WebRTC is detailed in 642 [I-D.ietf-rtcweb-security-arch]. 644 10. Interworking 646 An WebRTC endpoint supporting CoAP may in affect act as a gateway 647 between local sensor devices and a remote peer endpoint. The local 648 sensors may utilise CoAP over an alternate signalling transport such 649 as UDP to the local WebRTC endpoint. The WebRTC endpoint may then 650 utilise CoAP over WebRTC to signal to the remote peer. 652 A CoAP gateway when converting to and from a WebRTC transport will in 653 general perform the following functions: 655 o Map received Empty CoAP message to SCTP level operations and 656 discard the empty message. 658 o Map received ACK message to SCTP level operations and discard the 659 ACK message. 661 o Separate piggy-backed messages. 663 o Provide a mapping between received and sent Tokens in order to 664 match requests and responses. 666 Other behaviour depends on the type of proxy behaviour the gateway is 667 performing. See section 5.7/[RFC7252] for more details. 669 11. Security Considerations 671 Security considerations for WebRTC are discussed in 672 [I-D.ietf-rtcweb-security]. 674 The use of CoAP over WebRTC can potentially negate the risks 675 mentioned in: 677 o section 11.3/[RFC7252] on insecure UDP and multicast being used to 678 aid an amplification attack. 680 o section 11.4/[RFC7252] on IP address spoofing and section 681 11.5/[RFC7252] on Cross-Protocol attacks. 683 o section 11.6/[RFC7252] may also not be relevant as WebRTC 684 endpoints are not expected to be severely constrained. 686 Of particular relevance to the support of CoAP over WebRTC DC is 687 access to local devices. Devices generating CoAP data are 688 essentially the same as cameras and microphones in that they may 689 expose sensitive data about the user or the location of the device. 690 Thus the guidance of section 4.1/[I-D.ietf-rtcweb-security] applies 691 to devices generating CoAP data. Whilst CoAP has been designed for 692 constrained devices where there is no user interface to inform/ 693 request consent, it is assumed that device utilising WebRTC DC for 694 CoAP is more likely at minimum a Class 2 [RFC7228] device that could 695 facilitate consent. 697 The CoAP media feature tag defined by this document tag may be 698 present in sessions not utilising CoAP, which increases the metadata 699 available about the sending device, which can help an attacker 700 differentiate between multiple devices and help them identify 701 otherwise anonymised users via the fingerprint of features their 702 device supports. To prevent this, SIP signalling SHOULD always be 703 encrypted using TLS [RFC5630]. 705 12. IANA Considerations 707 12.1. New WebRTC DC Protocol Value 709 NOTE: This registration is exactly the same as the registration in 710 [I-D.savolainen-core-coap-websockets]. 712 This document requests the registration of the subprotocol name 713 "coap.v1" in the WebSocket Subprotocol Name Registry. 715 o Subprotocol Identifier: coap.v1 716 o Subprotocol Common Name: Constrained Application Protocol (CoAP) 718 o Subprotocol Definition: This document 720 12.2. Secure Service Name and Port Number Registration 722 No need has been identified to register a new service name and port 723 number for CoAP over WebRTC. Port number allocation is dynamic. The 724 use of the SCTP over DTLS over UDP/TCP results in a layering of 725 services. 727 12.3. ALPN Protocol ID 729 [I-D.ietf-core-coap-tcp-tls] defines a new "coap" application 730 protocol negotiation protocol identity. However as the DTLS 731 connection is used to establish a WebRTC application the protocol 732 identifiers defined in [I-D.ietf-rtcweb-alpn] MUST be used. Note: 733 that confidentiality protection does not extend to WebRTC DCs. 735 12.4. URI Schemes 737 This document registers a new URI scheme "coaps+wr" for the use of 738 CoAP over WebRTC DCs. The "coaps+wr" URI schemes can be compared to 739 the "https" URI scheme. 741 The IANA is requested to add this new URI schemes to the registry 742 established with [RFC7595]. 744 12.5. New SIP Media Feature Tag 746 This specification registers a new media feature tag in the SIP 747 [RFC3264] tree per the procedures defined in [RFC2506] and [RFC3840]. 749 Media feature tag name: sip.coap 751 ASN.1 Identifier: 1.3.6.1.8.4.30 753 Summary of the media feature indicated by this tag: This feature tag 754 indicates that the device supports the Constrained Application 755 Protocol (CoAP). 757 Values appropriate for use with this feature tag: Boolean. 759 The feature tag is intended primarily for use in the following 760 applications, protocols, services, or negotiation mechanisms: This 761 feature tag is useful to indicate the support of CoAP. 763 Related standards or documents: This document 764 Security Considerations: Security considerations for this media 765 feature tag are discussed in Section 11. 767 Name(s) and email address(es) of person(s) to contact for further 768 information: 770 o CORE workgroup: core@ietf.org 772 o CORE chairs: core-chairs@ietf.org 774 Intended usage: COMMON 776 13. Examples 778 The example SDP Offer shows a CoAP over WebRTC DC utilising out-of- 779 band negotiation [I-D.ietf-mmusic-data-channel-sdpneg]. It is based 780 on the example in section 7.2/[I-D.ietf-rtcweb-jsep]. Modified lines 781 are indicated with ">>>" at the start of the line. These indicators 782 are NOT part of the SDP syntax. Note: some lines have been broken 783 into two lines for formatting reasons. 785 v=0 786 o=- 4962303333179871723 1 IN IP4 0.0.0.0 787 s=- 788 t=0 0 789 a=group:BUNDLE a1 d1 790 a=ice-options:trickle 791 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 792 c=IN IP4 0.0.0.0 793 a=rtcp:9 IN IP4 0.0.0.0 794 a=mid:a1 795 a=msid:57017fee-b6c1-4162-929c-a25110252400 796 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 797 a=sendrecv 798 a=rtpmap:96 opus/48000/2 799 a=rtpmap:0 PCMU/8000 800 a=rtpmap:8 PCMA/8000 801 a=rtpmap:97 telephone-event/8000 802 a=rtpmap:98 telephone-event/48000 803 a=maxptime:120 804 a=ice-ufrag:ATEn1v9DoTMB9J4r 805 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 806 a=fingerprint:sha-256 807 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 808 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 809 a=setup:actpass 810 a=rtcp-mux 811 a=rtcp-rsize 812 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 813 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 814 a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7 816 m=application 0 UDP/DTLS/SCTP webrtc-datachannel 817 c=IN IP4 0.0.0.0 818 a=bundle-only 819 a=mid:d1 820 a=fmtp:webrtc-datachannel max-message-size=65536 821 a=sctp-port 5000 822 a=fingerprint:sha-256 823 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 824 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 825 a=setup:actpass 826 >>>a=dcmap:0 subprotocol="coap.v1";"label="coap" 828 Figure 4: Example SDP Offer 830 14. Acknowledgements 832 We would like to thank the authors of [I-D.ietf-core-coap-tcp-tls] 833 and [I-D.savolainen-core-coap-websockets] for providing a framework 834 for this document. In addition we would like to thank Carsten 835 Bormann for his feedback on message format. 837 15. Changelog 839 Changes from version 00: 841 o Updated message format to align with draft-core-coap-tcp-tls-04 843 o Updates to align with draft-core-coap-tcp-tls-04 as a result of 844 the merger with websockets. Added section on opening handshake. 845 Added support of CoAP capability messages and BERT. 847 16. References 849 16.1. Normative References 851 [I-D.ietf-mmusic-data-channel-sdpneg] 852 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 853 and (. (Unknown), "SDP-based Data Channel Negotiation", 854 draft-ietf-mmusic-data-channel-sdpneg-10 (work in 855 progress), September 2016. 857 [I-D.ietf-mmusic-sctp-sdp] 858 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 859 "Session Description Protocol (SDP) Offer/Answer 860 Procedures For Stream Control Transmission Protocol (SCTP) 861 over Datagram Transport Layer Security (DTLS) Transport.", 862 draft-ietf-mmusic-sctp-sdp-18 (work in progress), October 863 2016. 865 [I-D.ietf-rtcweb-alpn] 866 Thomson, M., "Application Layer Protocol Negotiation for 867 Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb- 868 alpn-04 (work in progress), May 2016. 870 [I-D.ietf-rtcweb-data-channel] 871 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 872 Channels", draft-ietf-rtcweb-data-channel-13 (work in 873 progress), January 2015. 875 [I-D.ietf-rtcweb-data-protocol] 876 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 877 Establishment Protocol", draft-ietf-rtcweb-data- 878 protocol-09 (work in progress), January 2015. 880 [I-D.ietf-rtcweb-jsep] 881 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 882 Session Establishment Protocol", draft-ietf-rtcweb-jsep-16 883 (work in progress), September 2016. 885 [I-D.ietf-rtcweb-overview] 886 Alvestrand, H., "Overview: Real Time Protocols for 887 Browser-based Applications", draft-ietf-rtcweb-overview-15 888 (work in progress), January 2016. 890 [I-D.ietf-rtcweb-security] 891 Rescorla, E., "Security Considerations for WebRTC", draft- 892 ietf-rtcweb-security-08 (work in progress), February 2015. 894 [I-D.ietf-rtcweb-security-arch] 895 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 896 rtcweb-security-arch-12 (work in progress), June 2016. 898 [I-D.ietf-tsvwg-sctp-dtls-encaps] 899 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 900 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 901 dtls-encaps-09 (work in progress), January 2015. 903 [I-D.ietf-tsvwg-sctp-ndata] 904 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 905 "Stream Schedulers and User Message Interleaving for the 906 Stream Control Transmission Protocol", draft-ietf-tsvwg- 907 sctp-ndata-07 (work in progress), July 2016. 909 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 910 Requirement Levels", BCP 14, RFC 2119, 911 DOI 10.17487/RFC2119, March 1997, 912 . 914 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 915 Registration Procedure", BCP 31, RFC 2506, 916 DOI 10.17487/RFC2506, March 1999, 917 . 919 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 920 with Session Description Protocol (SDP)", RFC 3264, 921 DOI 10.17487/RFC3264, June 2002, 922 . 924 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 925 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 926 2002, . 928 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 929 Conrad, "Stream Control Transmission Protocol (SCTP) 930 Partial Reliability Extension", RFC 3758, 931 DOI 10.17487/RFC3758, May 2004, 932 . 934 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 935 "Indicating User Agent Capabilities in the Session 936 Initiation Protocol (SIP)", RFC 3840, 937 DOI 10.17487/RFC3840, August 2004, 938 . 940 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 941 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 942 July 2006, . 944 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 945 RFC 4960, DOI 10.17487/RFC4960, September 2007, 946 . 948 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 949 (ICE): A Protocol for Network Address Translator (NAT) 950 Traversal for Offer/Answer Protocols", RFC 5245, 951 DOI 10.17487/RFC5245, April 2010, 952 . 954 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 955 Initiation Protocol (SIP)", RFC 5630, 956 DOI 10.17487/RFC5630, October 2009, 957 . 959 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 960 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 961 January 2012, . 963 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 964 Transmission Protocol (SCTP) Stream Reconfiguration", 965 RFC 6525, DOI 10.17487/RFC6525, February 2012, 966 . 968 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 969 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 970 . 972 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 973 Constrained-Node Networks", RFC 7228, 974 DOI 10.17487/RFC7228, May 2014, 975 . 977 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 978 Application Protocol (CoAP)", RFC 7252, 979 DOI 10.17487/RFC7252, June 2014, 980 . 982 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 983 and Registration Procedures for URI Schemes", BCP 35, 984 RFC 7595, DOI 10.17487/RFC7595, June 2015, 985 . 987 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 988 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 989 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 990 October 2015, . 992 16.2. Informative References 994 [I-D.ietf-core-coap-tcp-tls] 995 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 996 Silverajan, B., and B. Raymor, "CoAP (Constrained 997 Application Protocol) over TCP, TLS, and WebSockets", 998 draft-ietf-core-coap-tcp-tls-05 (work in progress), 999 October 2016. 1001 [I-D.savolainen-core-coap-websockets] 1002 Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over 1003 WebSockets", draft-savolainen-core-coap-websockets-07 1004 (work in progress), June 2016. 1006 [I-D.silverajan-core-coap-alternative-transports] 1007 Silverajan, B. and T. Savolainen, "CoAP Communication with 1008 Alternative Transports", draft-silverajan-core-coap- 1009 alternative-transports-09 (work in progress), December 1010 2015. 1012 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1013 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1014 . 1016 Authors' Addresses 1018 Christian Groves 1019 Huawei 1021 Email: Christian.Groves@nteczone.com 1023 Weiwei Yang 1024 Huawei 1026 Email: tommy@huawei.com