idnits 2.17.1 draft-ietf-netconf-udp-pub-channel-03.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 (June 30, 2018) is 2126 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) -- Looks like a reference, but probably isn't: '1' on line 825 -- Looks like a reference, but probably isn't: '2' on line 485 -- Looks like a reference, but probably isn't: '3' on line 482 -- Looks like a reference, but probably isn't: '4' on line 485 -- Looks like a reference, but probably isn't: '5' on line 485 -- Looks like a reference, but probably isn't: '6' on line 482 -- Looks like a reference, but probably isn't: '7' on line 485 -- Looks like a reference, but probably isn't: '8' on line 485 -- Looks like a reference, but probably isn't: '9' on line 485 -- Looks like a reference, but probably isn't: '0' on line 485 ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-22) exists of draft-ietf-netconf-netconf-event-notifications-09 == Outdated reference: A later version (-08) exists of draft-ietf-netconf-notification-messages-03 == Outdated reference: A later version (-15) exists of draft-ietf-netconf-restconf-notif-06 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-subscribed-notifications-13 == Outdated reference: A later version (-10) exists of draft-zhou-netconf-multi-stream-originators-02 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF G. Zheng 3 Internet-Draft T. Zhou 4 Intended status: Standards Track A. Clemm 5 Expires: January 1, 2019 Huawei 6 June 30, 2018 8 UDP based Publication Channel for Streaming Telemetry 9 draft-ietf-netconf-udp-pub-channel-03 11 Abstract 13 This document describes a UDP-based publication channel for streaming 14 telemetry use to collect data from devices. A new shim header is 15 proposed to facilitate the distributed data collection mechanism 16 which directly pushes data from line cards to the collector. Because 17 of the lightweight UDP encapsulation, higher frequency and better 18 transit performance can be achieved. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 1, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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 (https://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 respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Transport Mechanisms . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 5 65 4.2. Configured Subscription . . . . . . . . . . . . . . . . . 7 66 5. UDP Transport for Publication Channel . . . . . . . . . . . . 8 67 5.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 8 68 5.2. Data Format of the UPC Message Header . . . . . . . . . . 8 69 5.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.3.1. Reliability Option . . . . . . . . . . . . . . . . . 10 71 5.3.2. Fragmentation Option . . . . . . . . . . . . . . . . 11 72 5.4. Data Encoding . . . . . . . . . . . . . . . . . . . . . . 12 73 6. Using DTLS to Secure UPC . . . . . . . . . . . . . . . . . . 12 74 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 13 76 6.3. DTLS Session Initiation . . . . . . . . . . . . . . . . . 13 77 6.4. Sending Data . . . . . . . . . . . . . . . . . . . . . . 14 78 6.5. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . 15 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 85 11.2. Informative References . . . . . . . . . . . . . . . . . 17 86 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 Streaming telemetry refers to sending a continuous stream of 93 operational data from a device to a remote receiver. This provides 94 an ability to monitor a network from remote and to provide network 95 analytics. Devices generate telemetry data and push that data to a 96 collector for further analysis. By streaming the data, much better 97 performance, finer-grained sampling, monitoring accuracy, and 98 bandwidth utilization can be achieved than with polling-based 99 alternatives. 101 Sub-Notif [I-D.ietf-netconf-subscribed-notifications] defines a 102 mechanism that allows a collector to subscribe to updates of YANG- 103 defined data that is maintained in a YANG [RFC7950] datastore. The 104 mechanism separates the management and control of subscriptions from 105 the transport that is used to actually stream and deliver the data. 106 Two transports, NETCONF transport 107 [I-D.ietf-netconf-netconf-event-notifications] and HTTP transport 108 [I-D.ietf-netconf-restconf-notif], have been defined so far for the 109 notification messages. 111 While powerful in its features and general in its architecture, in 112 its current form the mechanism needs to be extended to stream 113 telemetry data at high velocity from devices that feature a 114 distributed architecture. The transports that have been defined so 115 far, NETCONF and HTTP, are ultimately based on TCP and lack the 116 efficiency needed to stream data continuously at high velocity. A 117 lighter-weight, more efficient transport, e.g. a transport based on 118 UDP is needed. 120 o Firstly, data collector will suffer a lot of TCP connections from, 121 for example, many line cards equipped on different devices. 123 o Secondly, as no connection state needs to be maintained, UDP 124 encapsulation can be easily implemented by hardware which will 125 further improve the performance. 127 o Thirdly, because of the lightweight UDP encapsulation, higher 128 frequency and better transit performance can be achieved, which is 129 important for streaming telemetry. 131 This document specifies a higher-performance transport option for 132 Sub-Notif that leverages UDP. Specifically, it facilitates the 133 distributed data collection mechanism described in 134 [I-D.zhou-netconf-multi-stream-originators]. In the case of data 135 originating from multiple line cards, the centralized design requires 136 data to be internally forwarded from those line cards to the push 137 server, presumably on a main board, which then combines the 138 individual data items into a single consolidated stream. The 139 centralized data collection mechanism can result in a performance 140 bottleneck, especially when large amounts of data are involved. What 141 is needed instead is the support for a distributed mechanism that 142 allows to directly push multiple individual substreams, e.g. one from 143 each line card, without needing to first pass them through an 144 additional processing stage for internal consolidation, but still 145 allowing those substreams to be managed and controlled via a single 146 subscription. The proposed UDP based Publication Channel (UPC) 147 natively supports the distributed data collection mechanism. 149 The transport described in this document can be used for transmitting 150 notification messages over both IPv4 and IPv6 [RFC8200]. 152 While this document will focus on the data publication channel, the 153 subscription can be used in conjunction with the mechanism proposed 154 in [I-D.ietf-netconf-subscribed-notifications] with extensions 155 [I-D.zhou-netconf-multi-stream-originators]. 157 2. Terminology 159 Streaming Telemetry: refers to sending a continuous stream of 160 operational data from a device to a remote receiver. This provides 161 an ability to monitor a network from remote and to provide network 162 analytics. 164 Component Subscription: A subscription that defines the data from 165 each individual telemetry source which is managed and controlled by a 166 single Subscription Server. 168 Component Subscription Server: An agent that streams telemetry data 169 per the terms of a component subscription. 171 3. Solution Overview 173 The typical distributed data collection solution is shown in Fig. 1. 174 Both the Collector and the Publisher can be distributed. The 175 Collector includes the Subscriber and a set of Receivers. And the 176 Publisher includes a Subscription Server and a set of Component 177 Subscription Servers. The Subscriber cannot see the Component 178 Subscription Servers directly, so it will send the Global 179 Subscription information to the Subscription Server (e.g., main 180 board) via the Subscription Channel. When receiving a Global 181 Subscription, the Subscription Server decomposes the subscription 182 request into multiple Component Subscriptions, each involving data 183 from a separate internal telemetry source, for example a line card. 184 The Component Subscriptions are distributed to the Component 185 Subscription Server. Subsequently, each data originator generates 186 its own stream of telemetry data, collecting and encapsulating the 187 packets per the Component Subscription and streaming them to the 188 designated Receivers. This distributed data collection mechanism may 189 form multiple Publication Channels to the Receivers. The Receiver is 190 able to assemble many pieces of data associated with one Global 191 Subscription. 193 The Publication Channel supports the reliable data streaming, for 194 example for some alarm events. The Collector has the option of 195 deducing the packet loss and the disorder based on the information 196 carried by the notification data. And the Collector may decide the 197 behavior to request retransmission. 199 The rest of the draft describes the UDP based Publication Channel 200 (UPC). 202 +-------------------------------------+ 203 | Collector | 204 | | 205 | +------------+ +-----------+ | 206 | | Subscriber | | Receivers | | 207 | +----+-------+ +--^----^---+ | 208 | | | | | 209 +-------------------------------------+ 210 | | | 211 Subscription | | | Publication 212 Channel | | | Channel 213 | +---------+ | 214 | | | 215 +-------------------------------------+ 216 | | | | | 217 | +----v---+-----+ +------+-------+ | 218 | | Subscription | | Component | | 219 | | Server | | Subscription | | 220 | | | | Servers | | 221 | +--------------+ +--------------+ | 222 | | 223 | Publisher | 224 +-------------------------------------+ 226 Fig. 1 Distributed Data Collection 228 4. Transport Mechanisms 230 For a complete pub-sub mechanism, this section will describe how the 231 UPC is used to interact with the Subscription Channel relying on 232 NETCONF or RESTCONF. 234 4.1. Dynamic Subscription 236 Dynamic subscriptions for Sub-Notif are configured and managed via 237 signaling messages transported over NETCONF [RFC6241] or RESTCONF 238 [RFC8040]. The Sub-Notif defined RPCs which are sent and responded 239 via the Subscription Channel (a), between the Subscriber and the 240 Subscription Server of the Publisher. In this case, only one 241 Receiver is associated with the Subscriber. In the Publisher, there 242 may be multiple data originators. Notification messages are pushed 243 on separate channels (b), from different data originators to the 244 Receiver. 246 +--------------+ +--------------+ 247 | Collector | | Publisher | 248 | | | | 249 | (a) (b) | | (a) (b) | 250 +--+------+----+ +--+-------+---+ 251 | | | | 252 | | RPC:establish-subscription | | 253 +----------------------------------------> | 254 | | RPC Reply: OK | | 255 <----------------------------------------+ | 256 | | UPC:notifications | | 257 | <-----------------------------------------+ 258 | | | | 259 | | RPC:modify-subscription | | 260 +----------------------------------------> | 261 | | RPC Reply: OK | | 262 <----------------------------------------+ | 263 | | UPC:notifications | | 264 | <-----------------------------------------+ 265 | | | | 266 | | RPC:delete-subscription | | 267 +----------------------------------------> | 268 | | RPC Reply: OK | | 269 <----------------------------------------+ | 270 | | | | 271 | | | | 272 + + + + 274 Fig. 2 Call Flow For Dynamic Subscription 276 In the case of dynamic subscription, the Receiver and the Subscriber 277 SHOULD be colocated. So UPC can use the source IP address of the 278 Subscription Channel as it's destination IP address. The Receiver 279 MUST support listening messages at the IANA-assigned PORT-X or PORT- 280 Y, but MAY be configured to listen at a different port. 282 The Publication Channels MUST share fate with the subscription 283 session. In other words, when the delete-subscription is received or 284 the subscription session is broken, all the associated Publication 285 Channels MUST be closed. 287 4.2. Configured Subscription 289 For a Configured Subscription, there is no guarantee that the 290 Subscriber is currently in place with the associated Receiver(s). As 291 defined in Sub-Notif, the subscription configuration contains the 292 location information of all the receivers, including the IP address 293 and the port number. So that the data originator can actively send 294 generated messages to the corresponding Receivers via the UPC. 296 The first message MUST be a separate subscription-started 297 notification to indicate the Receiver that the pushing is started. 298 Then, the notifications can be sent immediately without any wait. 300 All the subscription state notifications, as defined in 301 [I-D.ietf-netconf-subscribed-notifications], MUST be encapsulated to 302 be separated notification messages. 304 +--------------+ +--------------+ 305 | Collector | | Publisher | 306 | | | | 307 | (a) (b) | | (a) (b) | 308 +--+------+----+ +--+-------+---+ 309 | | | | 310 | | Capability Exchange | | 311 <----------------------------------------> | 312 | | | | 313 | | Edit config(create) | | 314 +----------------------------------------> | 315 | | RPC Reply: OK | | 316 <----------------------------------------+ | 317 | | UPC:subscription started | | 318 | <-----------------------------------------+ 319 | | UPC:notifications | | 320 | <-----------------------------------------+ 321 | | | | 322 | | Edit config(delete) | | 323 +----------------------------------------> | 324 | | RPC Reply: OK | | 325 <----------------------------------------+ | 326 | | UPC:subscription terminated | | 327 | <-----------------------------------------+ 328 | | | | 329 | | | | 330 + + + + 332 Fig. 3 Call Flow For Configured Subscription 334 5. UDP Transport for Publication Channel 336 5.1. Design Overview 338 As specified in Sub-Notif, the telemetry data is encapsulated in the 339 NETCONF/RESTCONF notification message, which is then encapsulated and 340 carried in the transport protocols, e.g. TLS, HTTP2. The following 341 figure shows the overview of the typical UPC message structure. 343 o The Message Header contains information that can facilitate the 344 message transmission before de-serializing the notification 345 message. 347 o Notification Message is the encoded content that the publication 348 channel transports. The common encoding method includes GPB [1], 349 CBOR [RFC7049], JSON, and XML. 350 [I-D.ietf-netconf-notification-messages] describes the structure 351 of the Notification Message for both single notification and 352 multiple bundled notifications. 354 +-------+ +--------------+ +--------------+ 355 | UDP | | Message | | Notification | 356 | | | Header | | Message | 357 +-------+ +--------------+ +--------------+ 359 Fig. 4 UDP Publication Message Overview 361 5.2. Data Format of the UPC Message Header 363 The UPC Message Header contains information that can facilitate the 364 message transmission before de-serializing the notification message. 365 The data format is shown as follows. 367 0 1 2 3 368 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 369 +-------+---------------+-------+-------------------------------+ 370 | Vers. | Flag | ET | Length | 371 +-------+---------------+-------+-------------------------------+ 372 | Message-Generator-ID | 373 +---------------------------------------------------------------+ 374 | Message ID | 375 +---------------------------------------------------------------+ 376 ~ Options ~ 377 +---------------------------------------------------------------+ 379 Fig. 3 UPC Message Header Format 381 The Message Header contains the following field: 383 o Vers.: represents the PDU (Protocol Data Unit) encoding version. 384 The initial version value is 0. 386 o Flag: is a bitmap indicating what features this packet has and the 387 corresponding options attached. Each bit associates to one 388 feature and one option data. When the bit is set to 1, the 389 associated feature is enabled and the option data is attached. 390 The sequence of the presence of the options follows the bit order 391 of the bitmap. In this document, the flag is specified as 392 follows: 394 * bit 0, the reliability flag; 396 * bit 1, the fragmentation flag; 398 * other bits are reserved. 400 o ET: is a 4 bits identifier to indicate the encoding type used for 401 the Notification Message. 16 types of encoding can be expressed: 403 * 0: GPB; 405 * 1: CBOR; 407 * 2: JSON; 409 * 3: XML; 411 * others are reserved. 413 o Length: is the total length of the message, measured in octets, 414 including message header. 416 o Message-Generator-ID: is a 32-bit identifier of the process which 417 created the notification message. This allows disambiguation of 418 an information source, such as the identification of different 419 line cards sending the notification messages. The source IP 420 address of the UDP datagrams SHOULD NOT be interpreted as the 421 identifier for the host that originated the UPC message. The 422 entity sending the UPC message could be merely a relay. 424 o The Message ID is generated continuously by the message generator. 425 Different subscribers share the same notification ID sequence. 427 o Options: is a variable-length field. The details of the Options 428 will be described in the respective sections below. 430 5.3. Options 432 The order of packing the data fields in the Options field follows the 433 bit order of the Flag field. 435 5.3.1. Reliability Option 437 The UDP based publication transport described in this document 438 provides two streaming modes, the reliable mode an the unreliable 439 mode, for different SLA (Service Level Agreement) and telemetry 440 requirements. 442 In the unreliable streaming mode, the line card pushes the 443 encapsulated data to the data collector without any sequence 444 information. So the subscriber does not know whether the data is 445 correctly received or not. Hence no retransmission happens. 447 The reliable streaming mode provides sequence information in the UDP 448 packet, based on which the subscriber can deduce the packet loss and 449 disorder. Then the subscriber can decide whether to request the 450 retransmission of the lost packets. 452 In most case, the unreliable streaming mode is preferred. Because 453 the reliable streaming mode will cost more network bandwidth and 454 precious device resource. Different from the unreliable streaming 455 mode, the line card cannot remove the sent reliable notifications 456 immediately, but to keep them in the memory for a while. Reliable 457 notifications may be pushed multiple times, which will increase the 458 traffic. When choosing the reliable streaming mode or the unreliable 459 streaming mode, the operate need to consider the reliable requirement 460 together with the resource usage. 462 When the reliability flag bit is set to 1 in the Flag field, the 463 following option data will be attached 465 0 1 2 3 466 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 467 +---------------------------------------------------------------+ 468 | Previous Message ID | 469 +---------------------------------------------------------------+ 471 Fig. 4 Reliability Option Format 473 Current Message ID and Previous Message ID will be added in the 474 packets. 476 For example, there are two subscriber A and B, 477 o Message IDs for the generator are : [1, 2, 3, 4, 5, 6, 7, 8, 9], 478 in which Subscriber A subscribes [1,2,3,6,7] and Subscriber B 479 subscribes [1,2,4,5,7,8,9]. 481 o Subscriber A will receive [Previous Message ID, Current Message 482 ID] like: [0,1][1,2][2,3][3,6][6,7]. 484 o Subscriber B will receive [Previous Message ID, Current Message 485 ID] like: [0,1][1,2][2,4][4,5][5,7][7,8][8,9]. 487 5.3.2. Fragmentation Option 489 UDP palyload has a theoretical length limitation to 65535. Other 490 encapsulation headers will make the actual payload even shorter. 491 Binary encodings like GPB and CBOR can make the message compact. So 492 that the message can be encapsulated within one UDP packet, hence 493 fragmentation will not easily happen. However, text encodings like 494 JSON and XML can easily make the message exceed the UDP length 495 limitation. 497 The Fragmentation Option can help not Application layer can split the 498 YANG tree into several leaves. Or table into several rows. But the 499 leaf or the row cannot be split any further. Now we consider a very 500 long path. Since the GPB and CBOR are so compact, it's easy to fit 501 into a UDP packet. But for JSON or XML, it is possible that even one 502 leaf will exceed the UDP boundary. 504 0 1 2 3 505 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 506 +-------------------------------------------------------------+-+ 507 | Fagment Number |L| 508 +-------------------------------------------------------------+-+ 510 Fig. 5 Fragmentation Option Format 512 The Fragmentation Option is available in the message header when the 513 fragmentation flag is set to 1. The option contains: 515 Fragment Number: indicates the sequence number of the current 516 fragment. 518 L: is a flag to indicate whether the current fragment is the last 519 one. When 0 is set, current fragment is not the last one, hence more 520 fragments are expected. When 1 is set, current fragment is the last 521 one. 523 5.4. Data Encoding 525 Subscribed data can be encoded in GPB, CBOR, XML or JSON format. It 526 is conceivable that additional encodings may be supported as options 527 in the future. This can be accomplished by augmenting the 528 subscription data model with additional identity statements used to 529 refer to requested encodings. 531 Implementation may support different encoding method per 532 subscription. When bundled notifications is supported between the 533 publisher and the receiver, only subscribed notifications with the 534 same encoding can be bundled as one message. 536 6. Using DTLS to Secure UPC 538 The Datagram Transport Layer Security (DTLS) protocol [RFC6347] is 539 designed to meet the requirements of applications that need secure 540 datagram transport. 542 DTLS can be used as a secure transport to counter all the primary 543 threats to UDP based Publication Channel: 545 o Confidentiality to counter disclosure of the message contents. 547 o Integrity checking to counter modifications to a message on a hop- 548 by-hop basis. 550 o Server or mutual authentication to counter masquerade. 552 In addition, DTLS also provides: 554 o A cookie exchange mechanism during handshake to counter Denial of 555 Service attacks. 557 o A sequence number in the header to counter replay attacks. 559 6.1. Transport 561 As shown in Figure 6, the DTLS is layered next to the UDP transport 562 is to provide reusable security and authentication functions over 563 UDP. No DTLS extension is required to enable UPC messages over DTLS. 565 +-----------------------------+ 566 | UPC Message | 567 +-----------------------------+ 568 | DTLS | 569 +-----------------------------+ 570 | UDP | 571 +-----------------------------+ 572 | IP | 573 +-----------------------------+ 575 Fig. 6: Protocol Stack for DTLS secured UPC 577 The application implementer will map a unique combination of the 578 remote address, remote port number, local address, and local port 579 number to a session. 581 Each UPC message is delivered by the DTLS record protocol, which 582 assigns a sequence number to each DTLS record. Although the DTLS 583 implementer may adopt a queue mechanism to resolve reordering, it may 584 not assure that all the messages are delivered in order when mapping 585 on the UDP transport. 587 Since UDP is an unreliable transport, with DTLS, an originator or 588 relay may not realize that a collector has gone down or lost its DTLS 589 connection state, so messages may be lost. 591 The DTLS record has its own sequence number, the encryption and 592 decryption will done by DTLS layer, UPC Message layer will not 593 concern this. 595 6.2. Port Assignment 597 The Publisher is always a DTLS client, and the Receiver is always a 598 DTLS server. The Receivers MUST support accepting UPC Messages on 599 the UDP port PORT-Y, but MAY be configurable to listen on a different 600 port. The Publisher MUST support sending UPC messages to the UDP 601 port PORT-Y, but MAY be configurable to send messages to a different 602 port. The Publisher MAY use any source UDP port for transmitting 603 messages. 605 6.3. DTLS Session Initiation 607 The Publisher initiates a DTLS connection by sending a DTLS Client 608 Hello to the Receiver. Implementations MUST support the denial of 609 service countermeasures defined by DTLS. When these countermeasures 610 are used, the Receiver responds with a DTLS Hello Verify Request 611 containing a cookie. The Publisher responds with a DTLS Client Hello 612 containing the received cookie, which initiates the DTLS handshake. 614 The Publisher MUST NOT send any UPC messages before the DTLS 615 handshake has successfully completed. 617 Implementations MUST support DTLS 1.0 [RFC4347] and MUST support the 618 mandatory to implement cipher suite, which is 619 TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246] as specified in DTLS 1.0. If 620 additional cipher suites are supported, then implementations MUST NOT 621 negotiate a cipher suite that employs NULL integrity or 622 authentication algorithms. 624 Where privacy is REQUIRED, then implementations must either negotiate 625 a cipher suite that employs a non-NULL encryption algorithm or else 626 achieve privacy by other means, such as a physically secured network. 628 6.4. Sending Data 630 All UPC messages MUST be sent as DTLS "application data". It is 631 possible that multiple UPC messages be contained in one DTLS record, 632 or that a publication message be transferred in multiple DTLS 633 records. The application data is defined with the following ABNF 634 [RFC5234] expression: 636 APPLICATION-DATA = 1*UPC-FRAME 638 UPC-FRAME = MSG-LEN SP UPC-MSG 640 MSG-LEN = NONZERO-DIGIT *DIGIT 642 SP = %d32 644 NONZERO-DIGIT = %d49-57 646 DIGIT = %d48 / NONZERO-DIGIT 648 UPC-MSG is defined in section 5.2. 650 6.5. Closure 652 A Publisher MUST close the associated DTLS connection if the 653 connection is not expected to deliver any UPC Messages later. It 654 MUST send a DTLS close_notify alert before closing the connection. A 655 Publisher (DTLS client) MAY choose to not wait for the Receiver's 656 close_notify alert and simply close the DTLS connection. Once the 657 Receiver gets a close_notify from the Publisher, it MUST reply with a 658 close_notify. 660 When no data is received from a DTLS connection for a long time 661 (where the application decides what "long" means), Receiver MAY close 662 the connection. The Receiver (DTLS server) MUST attempt to initiate 663 an exchange of close_notify alerts with the Publisher before closing 664 the connection. Receivers that are unprepared to receive any more 665 data MAY close the connection after sending the close_notify alert. 667 Although closure alerts are a component of TLS and so of DTLS, they, 668 like all alerts, are not retransmitted by DTLS and so may be lost 669 over an unreliable network. 671 7. Congestion Control 673 Congestion control mechanisms that respond to congestion by reducing 674 traffic rates and establish a degree of fairness between flows that 675 share the same path are vital to the stable operation of the Internet 676 [RFC2914]. While efficient, UDP has no build-in congestion control 677 mechanism. Because streaming telemetry can generate unlimited 678 amounts of data, transferring this data over UDP is generally 679 problematic. It is not recommended to use the UDP based publication 680 channel over congestion-sensitive network paths. The only 681 environments where the UDP based publication channel MAY be used are 682 managed networks. The deployments require the network path has been 683 explicitly provisioned for the UDP based publication channel through 684 traffic engineering mechanisms, such as rate limiting or capacity 685 reservations. 687 8. IANA Considerations 689 This RFC requests that IANA assigns three UDP port numbers in the 690 "Registered Port Numbers" range with the service names "upc" and 691 "upc-dtls". These ports will be the default ports for the UDP based 692 Publication Channel for NETCONF and RESTCONF. Below is the 693 registration template following the rules in [RFC6335]. 695 Service Name: upc 697 Transport Protocol(s): UDP 699 Assignee: IESG 701 Contact: IETF Chair 703 Description: UDP based Publication Channel 705 Reference: RFC XXXX 707 Port Number: PORT-X 709 Service Name: upc-dtls 710 Transport Protocol(s): UDP 712 Assignee: IESG 714 Contact: IETF Chair 716 Description: UDP based Publication Channel (DTLS) 718 Reference: RFC XXXX 720 Port Number: PORT-Y 722 9. Security Considerations 724 TBD 726 10. Acknowledgements 728 The authors of this documents would like to thank Eric Voit, Tim 729 Jenkins, and Huiyang Yang for the initial comments. 731 11. References 733 11.1. Normative References 735 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 736 Requirement Levels", BCP 14, RFC 2119, 737 DOI 10.17487/RFC2119, March 1997, 738 . 740 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 741 RFC 2914, DOI 10.17487/RFC2914, September 2000, 742 . 744 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 745 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 746 . 748 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 749 Specifications: ABNF", STD 68, RFC 5234, 750 DOI 10.17487/RFC5234, January 2008, 751 . 753 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 754 (TLS) Protocol Version 1.2", RFC 5246, 755 DOI 10.17487/RFC5246, August 2008, 756 . 758 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 759 and A. Bierman, Ed., "Network Configuration Protocol 760 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 761 . 763 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 764 Cheshire, "Internet Assigned Numbers Authority (IANA) 765 Procedures for the Management of the Service Name and 766 Transport Protocol Port Number Registry", BCP 165, 767 RFC 6335, DOI 10.17487/RFC6335, August 2011, 768 . 770 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 771 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 772 January 2012, . 774 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 775 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 776 October 2013, . 778 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 779 RFC 7950, DOI 10.17487/RFC7950, August 2016, 780 . 782 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 783 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 784 . 786 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 787 (IPv6) Specification", STD 86, RFC 8200, 788 DOI 10.17487/RFC8200, July 2017, 789 . 791 11.2. Informative References 793 [I-D.ietf-netconf-netconf-event-notifications] 794 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 795 A. Tripathy, "NETCONF Support for Event Notifications", 796 draft-ietf-netconf-netconf-event-notifications-09 (work in 797 progress), May 2018. 799 [I-D.ietf-netconf-notification-messages] 800 Voit, E., Birkholz, H., Bierman, A., Clemm, A., and T. 801 Jenkins, "Notification Message Headers and Bundles", 802 draft-ietf-netconf-notification-messages-03 (work in 803 progress), February 2018. 805 [I-D.ietf-netconf-restconf-notif] 806 Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 807 A. Bierman, "RESTCONF and HTTP Transport for Event 808 Notifications", draft-ietf-netconf-restconf-notif-06 (work 809 in progress), June 2018. 811 [I-D.ietf-netconf-subscribed-notifications] 812 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 813 A. Tripathy, "Customized Subscriptions to a Publisher's 814 Event Streams", draft-ietf-netconf-subscribed- 815 notifications-13 (work in progress), June 2018. 817 [I-D.zhou-netconf-multi-stream-originators] 818 Zhou, T., Zheng, G., Voit, E., Clemm, A., and A. Bierman, 819 "Subscription to Multiple Stream Originators", draft-zhou- 820 netconf-multi-stream-originators-02 (work in progress), 821 May 2018. 823 11.3. URIs 825 [1] https://developers.google.com/protocol-buffers/ 827 Appendix A. Change Log 829 (To be removed by RFC editor prior to publication) 831 A.1. draft-ietf-zheng-udp-pub-channel-00 to v00 833 o Modified the message header format. 835 o Added a section on the Authentication Option. 837 o Cleaned up the text and removed unnecessary TBDs. 839 A.2. v01 841 o Removed the detailed description on distributed data collection 842 mechanism from this document. Mainly focused on the description 843 of a UDP based publication channel for telemetry use. 845 o Modified the message header format. 847 A.2. v02 849 o Add the section on the transport mechanism. 851 o Modified the fixed message header format. 853 o Add the fragmentation option for the message header. 855 A.2. v03 857 o Clarify term through the document. 859 o Add a section on DTLS support. 861 Authors' Addresses 863 Guangying Zheng 864 Huawei 865 101 Yu-Hua-Tai Software Road 866 Nanjing, Jiangsu 867 China 869 Email: zhengguangying@huawei.com 871 Tianran Zhou 872 Huawei 873 156 Beiqing Rd., Haidian District 874 Beijing 875 China 877 Email: zhoutianran@huawei.com 879 Alexander Clemm 880 Huawei 881 2330 Central Expressway 882 Santa Clara, California 883 USA 885 Email: alexander.clemm@huawei.com