idnits 2.17.1 draft-ietf-netconf-udp-pub-channel-05.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 11, 2019) is 1872 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 884 -- Looks like a reference, but probably isn't: '2' on line 429 -- Looks like a reference, but probably isn't: '3' on line 426 -- Looks like a reference, but probably isn't: '4' on line 429 -- Looks like a reference, but probably isn't: '5' on line 429 -- Looks like a reference, but probably isn't: '6' on line 426 -- Looks like a reference, but probably isn't: '7' on line 429 -- Looks like a reference, but probably isn't: '8' on line 429 -- Looks like a reference, but probably isn't: '9' on line 429 -- Looks like a reference, but probably isn't: '0' on line 429 ** 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-17 == Outdated reference: A later version (-08) exists of draft-ietf-netconf-notification-messages-05 == Outdated reference: A later version (-15) exists of draft-ietf-netconf-restconf-notif-13 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-subscribed-notifications-23 == Outdated reference: A later version (-10) exists of draft-zhou-netconf-multi-stream-originators-03 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: September 12, 2019 Huawei 6 March 11, 2019 8 UDP based Publication Channel for Streaming Telemetry 9 draft-ietf-netconf-udp-pub-channel-05 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 September 12, 2019. 43 Copyright Notice 45 Copyright (c) 2019 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. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Transport Mechanisms . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 4 64 3.2. Configured Subscription . . . . . . . . . . . . . . . . . 5 65 4. UDP Transport for Publication Channel . . . . . . . . . . . . 6 66 4.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Data Format of the UPC Message Header . . . . . . . . . . 7 68 4.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.3.1. Reliability Option . . . . . . . . . . . . . . . . . 9 70 4.3.2. Fragmentation Option . . . . . . . . . . . . . . . . 10 71 4.4. Data Encoding . . . . . . . . . . . . . . . . . . . . . . 11 72 5. Using DTLS to Secure UPC . . . . . . . . . . . . . . . . . . 11 73 5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 12 75 5.3. DTLS Session Initiation . . . . . . . . . . . . . . . . . 12 76 5.4. Sending Data . . . . . . . . . . . . . . . . . . . . . . 13 77 5.5. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 14 79 7. A YANG Data Model for Management of UPC . . . . . . . . . . . 14 80 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 86 12.2. Informative References . . . . . . . . . . . . . . . . . 19 87 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 Streaming telemetry refers to sending a continuous stream of 94 operational data from a device to a remote receiver. This provides 95 an ability to monitor a network from remote and to provide network 96 analytics. Devices generate telemetry data and push that data to a 97 collector for further analysis. By streaming the data, much better 98 performance, finer-grained sampling, monitoring accuracy, and 99 bandwidth utilization can be achieved than with polling-based 100 alternatives. 102 Sub-Notif [I-D.ietf-netconf-subscribed-notifications] defines a 103 mechanism that allows a collector to subscribe to updates of YANG- 104 defined data that is maintained in a YANG [RFC7950] datastore. The 105 mechanism separates the management and control of subscriptions from 106 the transport that is used to actually stream and deliver the data. 107 Two transports, NETCONF transport 108 [I-D.ietf-netconf-netconf-event-notifications] and HTTP transport 109 [I-D.ietf-netconf-restconf-notif], have been defined so far for the 110 notification messages. 112 While powerful in its features and general in its architecture, in 113 its current form the mechanism needs to be extended to stream 114 telemetry data at high velocity from devices that feature a 115 distributed architecture. The transports that have been defined so 116 far, NETCONF and HTTP, are ultimately based on TCP and lack the 117 efficiency needed to stream data continuously at high velocity. A 118 lighter-weight, more efficient transport, e.g. a transport based on 119 UDP is needed. 121 o Firstly, data collector will suffer a lot of TCP connections from, 122 for example, many line cards equipped on different devices. 124 o Secondly, as no connection state needs to be maintained, UDP 125 encapsulation can be easily implemented by hardware which will 126 further improve the performance. 128 o Thirdly, because of the lightweight UDP encapsulation, higher 129 frequency and better transit performance can be achieved, which is 130 important for streaming telemetry. 132 This document specifies a higher-performance transport option for 133 Sub-Notif that leverages UDP. Specifically, it facilitates the 134 distributed data collection mechanism described in 135 [I-D.zhou-netconf-multi-stream-originators]. In the case of data 136 originating from multiple line cards, the centralized design requires 137 data to be internally forwarded from those line cards to the push 138 server, presumably on a main board, which then combines the 139 individual data items into a single consolidated stream. The 140 centralized data collection mechanism can result in a performance 141 bottleneck, especially when large amounts of data are involved. What 142 is needed instead is the support for a distributed mechanism that 143 allows to directly push multiple individual substreams, e.g. one from 144 each line card, without needing to first pass them through an 145 additional processing stage for internal consolidation, but still 146 allowing those substreams to be managed and controlled via a single 147 subscription. The proposed UDP based Publication Channel (UPC) 148 natively supports the distributed data collection mechanism. 150 The transport described in this document can be used for transmitting 151 notification messages over both IPv4 and IPv6 [RFC8200]. 153 While this document will focus on the data publication channel, the 154 subscription can be used in conjunction with the mechanism proposed 155 in [I-D.ietf-netconf-subscribed-notifications] with extensions 156 [I-D.zhou-netconf-multi-stream-originators]. 158 2. Terminologies 160 Streaming Telemetry: refers to sending a continuous stream of 161 operational data from a device to a remote receiver. This provides 162 an ability to monitor a network from remote and to provide network 163 analytics. 165 Component Subscription: A subscription that defines the data from 166 each individual telemetry source which is managed and controlled by a 167 single Subscription Server. 169 Component Subscription Server: An agent that streams telemetry data 170 per the terms of a component subscription. 172 3. Transport Mechanisms 174 For a complete pub-sub mechanism, this section will describe how the 175 UPC is used to interact with the Subscription Channel relying on 176 NETCONF or RESTCONF. 178 3.1. Dynamic Subscription 180 Dynamic subscriptions for Sub-Notif are configured and managed via 181 signaling messages transported over NETCONF [RFC6241] or RESTCONF 182 [RFC8040]. The Sub-Notif defined RPCs which are sent and responded 183 via the Subscription Channel (a), between the Subscriber and the 184 Subscription Server of the Publisher. In this case, only one 185 Receiver is associated with the Subscriber. In the Publisher, there 186 may be multiple data originators. Notification messages are pushed 187 on separate channels (b), from different data originators to the 188 Receiver. 190 +--------------+ +--------------+ 191 | Collector | | Publisher | 192 | | | | 193 | (a) (b) | | (a) (b) | 194 +--+------+----+ +--+-------+---+ 195 | | | | 196 | | RPC:establish-subscription | | 197 +----------------------------------------> | 198 | | RPC Reply: OK | | 199 <----------------------------------------+ | 200 | | UPC:notifications | | 201 | <-----------------------------------------+ 202 | | | | 203 | | RPC:modify-subscription | | 204 +----------------------------------------> | 205 | | RPC Reply: OK | | 206 <----------------------------------------+ | 207 | | UPC:notifications | | 208 | <-----------------------------------------+ 209 | | | | 210 | | RPC:delete-subscription | | 211 +----------------------------------------> | 212 | | RPC Reply: OK | | 213 <----------------------------------------+ | 214 | | | | 215 | | | | 216 + + + + 218 Fig. 2 Call Flow For Dynamic Subscription 220 In the case of dynamic subscription, the Receiver and the Subscriber 221 SHOULD be colocated. So UPC can use the source IP address of the 222 Subscription Channel as it's destination IP address. The Receiver 223 MUST support listening messages at the IANA-assigned PORT-X or PORT- 224 Y, but MAY be configured to listen at a different port. 226 For dynamic subscription, the Publication Channels MUST share fate 227 with the subscription session. In other words, when the delete- 228 subscription is received or the subscription session is broken, all 229 the associated Publication Channels MUST be closed. 231 3.2. Configured Subscription 233 For a Configured Subscription, there is no guarantee that the 234 Subscriber is currently in place with the associated Receiver(s). As 235 defined in Sub-Notif, the subscription configuration contains the 236 location information of all the receivers, including the IP address 237 and the port number. So that the data originator can actively send 238 generated messages to the corresponding Receivers via the UPC. 240 The first message MUST be a separate subscription-started 241 notification to indicate the Receiver that the pushing is started. 242 Then, the notifications can be sent immediately without any wait. 244 All the subscription state notifications, as defined in 245 [I-D.ietf-netconf-subscribed-notifications], MUST be encapsulated to 246 be separated notification messages. 248 +--------------+ +--------------+ 249 | Collector | | Publisher | 250 | | | | 251 | (a) (b) | | (a) (b) | 252 +--+------+----+ +--+-------+---+ 253 | | | | 254 | | Capability Exchange | | 255 <----------------------------------------> | 256 | | | | 257 | | Edit config(create) | | 258 +----------------------------------------> | 259 | | RPC Reply: OK | | 260 <----------------------------------------+ | 261 | | UPC:subscription started | | 262 | <-----------------------------------------+ 263 | | UPC:notifications | | 264 | <-----------------------------------------+ 265 | | | | 266 | | Edit config(delete) | | 267 +----------------------------------------> | 268 | | RPC Reply: OK | | 269 <----------------------------------------+ | 270 | | UPC:subscription terminated | | 271 | <-----------------------------------------+ 272 | | | | 273 | | | | 274 + + + + 276 Fig. 3 Call Flow For Configured Subscription 278 4. UDP Transport for Publication Channel 280 4.1. Design Overview 282 As specified in Sub-Notif, the telemetry data is encapsulated in the 283 NETCONF/RESTCONF notification message, which is then encapsulated and 284 carried in the transport protocols, e.g. TLS, HTTP2. The following 285 figure shows the overview of the typical UPC message structure. 287 o The Message Header contains information that can facilitate the 288 message transmission before de-serializing the notification 289 message. 291 o Notification Message is the encoded content that the publication 292 channel transports. The common encoding method includes GPB [1], 293 CBOR [RFC7049], JSON, and XML. 294 [I-D.ietf-netconf-notification-messages] describes the structure 295 of the Notification Message for both single notification and 296 multiple bundled notifications. 298 +-------+ +--------------+ +--------------+ 299 | UDP | | Message | | Notification | 300 | | | Header | | Message | 301 +-------+ +--------------+ +--------------+ 303 Fig. 4 UDP Publication Message Overview 305 4.2. Data Format of the UPC Message Header 307 The UPC Message Header contains information that can facilitate the 308 message transmission before de-serializing the notification message. 309 The data format is shown as follows. 311 0 1 2 3 312 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 313 +-------+---------------+-------+-------------------------------+ 314 | Vers. | Flag | ET | Length | 315 +-------+---------------+-------+-------------------------------+ 316 | Message-Generator-ID | 317 +---------------------------------------------------------------+ 318 | Message ID | 319 +---------------------------------------------------------------+ 320 ~ Options ~ 321 +---------------------------------------------------------------+ 323 Fig. 3 UPC Message Header Format 325 The Message Header contains the following field: 327 o Vers.: represents the PDU (Protocol Data Unit) encoding version. 328 The initial version value is 0. 330 o Flag: is a bitmap indicating what features this packet has and the 331 corresponding options attached. Each bit associates to one 332 feature and one option data. When the bit is set to 1, the 333 associated feature is enabled and the option data is attached. 334 The sequence of the presence of the options follows the bit order 335 of the bitmap. In this document, the flag is specified as 336 follows: 338 * bit 0, the reliability flag; 340 * bit 1, the fragmentation flag; 342 * other bits are reserved. 344 o ET: is a 4 bits identifier to indicate the encoding type used for 345 the Notification Message. 16 types of encoding can be expressed: 347 * 0: GPB; 349 * 1: CBOR; 351 * 2: JSON; 353 * 3: XML; 355 * others are reserved. 357 o Length: is the total length of the message, measured in octets, 358 including message header. 360 o Message-Generator-ID: is a 32-bit identifier of the process which 361 created the notification message. This allows disambiguation of 362 an information source, such as the identification of different 363 line cards sending the notification messages. The source IP 364 address of the UDP datagrams SHOULD NOT be interpreted as the 365 identifier for the host that originated the UPC message. The 366 entity sending the UPC message could be merely a relay. 368 o The Message ID is generated continuously by the message generator. 369 Different subscribers share the same notification ID sequence. 371 o Options: is a variable-length field. The details of the Options 372 will be described in the respective sections below. 374 4.3. Options 376 The order of packing the data fields in the Options field follows the 377 bit order of the Flag field. 379 4.3.1. Reliability Option 381 The UDP based publication transport described in this document 382 provides two streaming modes, the reliable mode an the unreliable 383 mode, for different SLA (Service Level Agreement) and telemetry 384 requirements. 386 In the unreliable streaming mode, the line card pushes the 387 encapsulated data to the data collector without any sequence 388 information. So the subscriber does not know whether the data is 389 correctly received or not. Hence no retransmission happens. 391 The reliable streaming mode provides sequence information in the UDP 392 packet, based on which the subscriber can deduce the packet loss and 393 disorder. Then the subscriber can decide whether to request the 394 retransmission of the lost packets. 396 In most case, the unreliable streaming mode is preferred. Because 397 the reliable streaming mode will cost more network bandwidth and 398 precious device resource. Different from the unreliable streaming 399 mode, the line card cannot remove the sent reliable notifications 400 immediately, but to keep them in the memory for a while. Reliable 401 notifications may be pushed multiple times, which will increase the 402 traffic. When choosing the reliable streaming mode or the unreliable 403 streaming mode, the operate need to consider the reliable requirement 404 together with the resource usage. 406 When the reliability flag bit is set to 1 in the Flag field, the 407 following option data will be attached 409 0 1 2 3 410 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 411 +---------------------------------------------------------------+ 412 | Previous Message ID | 413 +---------------------------------------------------------------+ 415 Fig. 4 Reliability Option Format 417 Current Message ID and Previous Message ID will be added in the 418 packets. 420 For example, there are two subscriber A and B, 421 o Message IDs for the generator are : [1, 2, 3, 4, 5, 6, 7, 8, 9], 422 in which Subscriber A subscribes [1, 2, 3, 6, 7] and Subscriber B 423 subscribes [1, 2, 4, 5, 7, 8, 9]. 425 o Subscriber A will receive [Previous Message ID, Current Message 426 ID] like: [0, 1] [1, 2] [2, 3] [3, 6] [6, 7]. 428 o Subscriber B will receive [Previous Message ID, Current Message 429 ID] like: [0, 1] [1, 2] [2, 4] [4, 5] [5, 7] [7, 8] [8, 9]. 431 4.3.2. Fragmentation Option 433 UDP palyload has a theoretical length limitation to 65535. Other 434 encapsulation headers will make the actual payload even shorter. 435 Binary encodings like GPB and CBOR can make the message compact. So 436 that the message can be encapsulated within one UDP packet, hence 437 fragmentation will not easily happen. However, text encodings like 438 JSON and XML can easily make the message exceed the UDP length 439 limitation. 441 The Fragmentation Option can help not Application layer can split the 442 YANG tree into several leaves. Or table into several rows. But the 443 leaf or the row cannot be split any further. Now we consider a very 444 long path. Since the GPB and CBOR are so compact, it's easy to fit 445 into a UDP packet. But for JSON or XML, it is possible that even one 446 leaf will exceed the UDP boundary. 448 0 1 2 3 449 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 450 +-------------------------------------------------------------+-+ 451 | Fragment Number |L| 452 +-------------------------------------------------------------+-+ 454 Fig. 5 Fragmentation Option Format 456 The Fragmentation Option is available in the message header when the 457 fragmentation flag is set to 1. The option contains: 459 Fragment Number: indicates the sequence number of the current 460 fragment. 462 L: is a flag to indicate whether the current fragment is the last 463 one. When 0 is set, current fragment is not the last one, hence more 464 fragments are expected. When 1 is set, current fragment is the last 465 one. 467 4.4. Data Encoding 469 Subscribed data can be encoded in GPB, CBOR, XML or JSON format. It 470 is conceivable that additional encodings may be supported as options 471 in the future. This can be accomplished by augmenting the 472 subscription data model with additional identity statements used to 473 refer to requested encodings. 475 Implementation may support different encoding method per 476 subscription. When bundled notifications is supported between the 477 publisher and the receiver, only subscribed notifications with the 478 same encoding can be bundled as one message. 480 5. Using DTLS to Secure UPC 482 The Datagram Transport Layer Security (DTLS) protocol [RFC6347] is 483 designed to meet the requirements of applications that need secure 484 datagram transport. 486 DTLS can be used as a secure transport to counter all the primary 487 threats to UDP based Publication Channel: 489 o Confidentiality to counter disclosure of the message contents. 491 o Integrity checking to counter modifications to a message on a hop- 492 by-hop basis. 494 o Server or mutual authentication to counter masquerade. 496 In addition, DTLS also provides: 498 o A cookie exchange mechanism during handshake to counter Denial of 499 Service attacks. 501 o A sequence number in the header to counter replay attacks. 503 5.1. Transport 505 As shown in Figure 6, the DTLS is layered next to the UDP transport 506 is to provide reusable security and authentication functions over 507 UDP. No DTLS extension is required to enable UPC messages over DTLS. 509 +-----------------------------+ 510 | UPC Message | 511 +-----------------------------+ 512 | DTLS | 513 +-----------------------------+ 514 | UDP | 515 +-----------------------------+ 516 | IP | 517 +-----------------------------+ 519 Fig. 6: Protocol Stack for DTLS secured UPC 521 The application implementer will map a unique combination of the 522 remote address, remote port number, local address, and local port 523 number to a session. 525 Each UPC message is delivered by the DTLS record protocol, which 526 assigns a sequence number to each DTLS record. Although the DTLS 527 implementer may adopt a queue mechanism to resolve reordering, it may 528 not assure that all the messages are delivered in order when mapping 529 on the UDP transport. 531 Since UDP is an unreliable transport, with DTLS, an originator or 532 relay may not realize that a collector has gone down or lost its DTLS 533 connection state, so messages may be lost. 535 The DTLS record has its own sequence number, the encryption and 536 decryption will done by DTLS layer, UPC Message layer will not 537 concern this. 539 5.2. Port Assignment 541 The Publisher is always a DTLS client, and the Receiver is always a 542 DTLS server. The Receivers MUST support accepting UPC Messages on 543 the UDP port PORT-Y, but MAY be configurable to listen on a different 544 port. The Publisher MUST support sending UPC messages to the UDP 545 port PORT-Y, but MAY be configurable to send messages to a different 546 port. The Publisher MAY use any source UDP port for transmitting 547 messages. 549 5.3. DTLS Session Initiation 551 The Publisher initiates a DTLS connection by sending a DTLS Client 552 Hello to the Receiver. Implementations MUST support the denial of 553 service countermeasures defined by DTLS. When these countermeasures 554 are used, the Receiver responds with a DTLS Hello Verify Request 555 containing a cookie. The Publisher responds with a DTLS Client Hello 556 containing the received cookie, which initiates the DTLS handshake. 558 The Publisher MUST NOT send any UPC messages before the DTLS 559 handshake has successfully completed. 561 Implementations MUST support DTLS 1.0 [RFC4347] and MUST support the 562 mandatory to implement cipher suite, which is 563 TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246] as specified in DTLS 1.0. If 564 additional cipher suites are supported, then implementations MUST NOT 565 negotiate a cipher suite that employs NULL integrity or 566 authentication algorithms. 568 Where privacy is REQUIRED, then implementations must either negotiate 569 a cipher suite that employs a non-NULL encryption algorithm or else 570 achieve privacy by other means, such as a physically secured network. 572 5.4. Sending Data 574 All UPC messages MUST be sent as DTLS "application_data". It is 575 possible that multiple UPC messages be contained in one DTLS record, 576 or that a publication message be transferred in multiple DTLS 577 records. The application data is defined with the following ABNF 578 [RFC5234] expression: 580 APPLICATION-DATA = 1*UPC-FRAME 582 UPC-FRAME = MSG-LEN SP UPC-MSG 584 MSG-LEN = NONZERO-DIGIT *DIGIT 586 SP = %d32 588 NONZERO-DIGIT = %d49-57 590 DIGIT = %d48 / NONZERO-DIGIT 592 UPC-MSG is defined in section 5.2. 594 5.5. Closure 596 A Publisher MUST close the associated DTLS connection if the 597 connection is not expected to deliver any UPC Messages later. It 598 MUST send a DTLS close_notify alert before closing the connection. A 599 Publisher (DTLS client) MAY choose to not wait for the Receiver's 600 close_notify alert and simply close the DTLS connection. Once the 601 Receiver gets a close_notify from the Publisher, it MUST reply with a 602 close_notify. 604 When no data is received from a DTLS connection for a long time 605 (where the application decides what "long" means), Receiver MAY close 606 the connection. The Receiver (DTLS server) MUST attempt to initiate 607 an exchange of close_notify alerts with the Publisher before closing 608 the connection. Receivers that are unprepared to receive any more 609 data MAY close the connection after sending the close_notify alert. 611 Although closure alerts are a component of TLS and so of DTLS, they, 612 like all alerts, are not retransmitted by DTLS and so may be lost 613 over an unreliable network. 615 6. Congestion Control 617 Congestion control mechanisms that respond to congestion by reducing 618 traffic rates and establish a degree of fairness between flows that 619 share the same path are vital to the stable operation of the Internet 620 [RFC2914]. While efficient, UDP has no build-in congestion control 621 mechanism. Because streaming telemetry can generate unlimited 622 amounts of data, transferring this data over UDP is generally 623 problematic. It is not recommended to use the UDP based publication 624 channel over congestion-sensitive network paths. The only 625 environments where the UDP based publication channel MAY be used are 626 managed networks. The deployments require the network path has been 627 explicitly provisioned for the UDP based publication channel through 628 traffic engineering mechanisms, such as rate limiting or capacity 629 reservations. 631 7. A YANG Data Model for Management of UPC 633 The YANG model defined in Section 9 has two leafs augmented into one 634 place of Sub-Notif [I-D.ietf-netconf-subscribed-notifications], plus 635 one identities. 637 module: ietf-upc-subscribed-notifications 638 augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver: 639 +--rw address? inet:ip-address 640 +--rw port? inet:port-number 642 8. YANG Module 644 file "ietf-upc-subscribed-notifications@2018-10-19.yang" 645 module ietf-upc-subscribed-notifications { 646 yang-version 1.1; 647 namespace 648 "urn:ietf:params:xml:ns:yang:ietf-upc-subscribed-notifications"; 649 prefix upcsn; 650 import ietf-subscribed-notifications { 651 prefix sn; 652 } 653 import ietf-inet-types { 654 prefix inet; 655 } 657 organization "IETF NETCONF (Network Configuration) Working Group"; 658 contact 659 "WG Web: 660 WG List: 662 Editor: Guangying Zheng 663 665 Editor: Tianran Zhou 666 668 Editor: Alexander Clemm 669 "; 671 description 672 "Defines UDP Publish Channel as a supported transport for subscribed 673 event notifications. 675 Copyright (c) 2018 IETF Trust and the persons identified as authors 676 of the code. All rights reserved. 678 Redistribution and use in source and binary forms, with or without 679 modification, is permitted pursuant to, and subject to the license 680 terms contained in, the Simplified BSD License set forth in Section 681 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 682 (https://trustee.ietf.org/license-info). 684 This version of this YANG module is part of RFC XXXX; see the RFC 686 itself for full legal notices."; 688 revision 2018-10-19 { 689 description 690 "Initial version"; 691 reference 692 "RFC XXXX: UDP based Publication Channel for Streaming Telemetry"; 693 } 695 identity upc { 696 base sn:transport; 697 description 698 "UPC is used as transport for notification messages and state 699 change notifications."; 700 } 701 grouping target-receiver { 702 description 703 "Provides a reusable description of a UPC target receiver."; 704 leaf address { 705 type inet:ip-address; 706 description 707 "Ip address of target upc receiver, which can be IPv4 address or 708 IPV6 address."; 709 } 710 leaf port { 711 type inet:port-number; 712 description 713 "Port number of target UPC receiver, if not specify, system 714 should use default port number."; 715 } 716 } 718 augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" { 719 description 720 "This augmentation allows UPC specific parameters to be 721 exposed for a subscription."; 722 uses target-receiver; 723 } 724 } 725 727 9. IANA Considerations 729 This RFC requests that IANA assigns three UDP port numbers in the 730 "Registered Port Numbers" range with the service names "upc" and 731 "upc-dtls". These ports will be the default ports for the UDP based 732 Publication Channel for NETCONF and RESTCONF. Below is the 733 registration template following the rules in [RFC6335]. 735 Service Name: upc 737 Transport Protocol(s): UDP 739 Assignee: IESG 741 Contact: IETF Chair 743 Description: UDP based Publication Channel 745 Reference: RFC XXXX 747 Port Number: PORT-X 748 Service Name: upc-dtls 750 Transport Protocol(s): UDP 752 Assignee: IESG 754 Contact: IETF Chair 756 Description: UDP based Publication Channel (DTLS) 758 Reference: RFC XXXX 760 Port Number: PORT-Y 762 IANA is requested to assign a new URI from the IETF XML Registry 763 [RFC3688]. The following URI is suggested: 765 URI: urn:ietf:params:xml:ns:yang:ietf-upc-subscribed-notifications 766 Registrant Contact: The IESG. 767 XML: N/A; the requested URI is an XML namespace. 769 This document also requests a new YANG module name in the YANG Module 770 Names registry [RFC7950] with the following suggestion: 772 name: ietf-upc-subscribed-notifications 773 namespace: urn:ietf:params:xml:ns:yang:ietf-upc-subscribed-notifications 774 prefix: upcsn 775 reference: RFC XXXX 777 10. Security Considerations 779 TBD 781 11. Acknowledgements 783 The authors of this documents would like to thank Eric Voit, Tim 784 Jenkins, and Huiyang Yang for the initial comments. 786 12. References 788 12.1. Normative References 790 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 791 Requirement Levels", BCP 14, RFC 2119, 792 DOI 10.17487/RFC2119, March 1997, 793 . 795 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 796 RFC 2914, DOI 10.17487/RFC2914, September 2000, 797 . 799 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 800 DOI 10.17487/RFC3688, January 2004, 801 . 803 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 804 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 805 . 807 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 808 Specifications: ABNF", STD 68, RFC 5234, 809 DOI 10.17487/RFC5234, January 2008, 810 . 812 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 813 (TLS) Protocol Version 1.2", RFC 5246, 814 DOI 10.17487/RFC5246, August 2008, 815 . 817 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 818 and A. Bierman, Ed., "Network Configuration Protocol 819 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 820 . 822 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 823 Cheshire, "Internet Assigned Numbers Authority (IANA) 824 Procedures for the Management of the Service Name and 825 Transport Protocol Port Number Registry", BCP 165, 826 RFC 6335, DOI 10.17487/RFC6335, August 2011, 827 . 829 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 830 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 831 January 2012, . 833 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 834 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 835 October 2013, . 837 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 838 RFC 7950, DOI 10.17487/RFC7950, August 2016, 839 . 841 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 842 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 843 . 845 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 846 (IPv6) Specification", STD 86, RFC 8200, 847 DOI 10.17487/RFC8200, July 2017, 848 . 850 12.2. Informative References 852 [I-D.ietf-netconf-netconf-event-notifications] 853 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 854 A. Tripathy, "Dynamic subscription to YANG Events and 855 Datastores over NETCONF", draft-ietf-netconf-netconf- 856 event-notifications-17 (work in progress), February 2019. 858 [I-D.ietf-netconf-notification-messages] 859 Voit, E., Birkholz, H., Bierman, A., Clemm, A., and T. 860 Jenkins, "Notification Message Headers and Bundles", 861 draft-ietf-netconf-notification-messages-05 (work in 862 progress), February 2019. 864 [I-D.ietf-netconf-restconf-notif] 865 Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 866 A. Bierman, "Dynamic subscription to YANG Events and 867 Datastores over RESTCONF", draft-ietf-netconf-restconf- 868 notif-13 (work in progress), February 2019. 870 [I-D.ietf-netconf-subscribed-notifications] 871 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 872 A. Tripathy, "Subscription to YANG Event Notifications", 873 draft-ietf-netconf-subscribed-notifications-23 (work in 874 progress), February 2019. 876 [I-D.zhou-netconf-multi-stream-originators] 877 Zhou, T., Zheng, G., Voit, E., Clemm, A., and A. Bierman, 878 "Subscription to Multiple Stream Originators", draft-zhou- 879 netconf-multi-stream-originators-03 (work in progress), 880 October 2018. 882 12.3. URIs 884 [1] https://developers.google.com/protocol-buffers/ 886 Appendix A. Change Log 888 (To be removed by RFC editor prior to publication) 890 A.1. draft-ietf-zheng-udp-pub-channel-00 to v00 892 o Modified the message header format. 894 o Added a section on the Authentication Option. 896 o Cleaned up the text and removed unnecessary TBDs. 898 A.2. v01 900 o Removed the detailed description on distributed data collection 901 mechanism from this document. Mainly focused on the description 902 of a UDP based publication channel for telemetry use. 904 o Modified the message header format. 906 A.2. v02 908 o Add the section on the transport mechanism. 910 o Modified the fixed message header format. 912 o Add the fragmentation option for the message header. 914 A.2. v03 916 o Clarify term through the document. 918 o Add a section on DTLS support. 920 A.2. v04 922 o Add a section on UPC subscription model. 924 A.2. v05 926 o Remove the redundant solution overview section and refer to the 927 multi stream originator draft. 929 Authors' Addresses 930 Guangying Zheng 931 Huawei 932 101 Yu-Hua-Tai Software Road 933 Nanjing, Jiangsu 934 China 936 Email: zhengguangying@huawei.com 938 Tianran Zhou 939 Huawei 940 156 Beiqing Rd., Haidian District 941 Beijing 942 China 944 Email: zhoutianran@huawei.com 946 Alexander Clemm 947 Huawei 948 2330 Central Expressway 949 Santa Clara, California 950 USA 952 Email: alexander.clemm@huawei.com