idnits 2.17.1 draft-unyte-netconf-udp-pub-channel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No 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 9, 2020) is 1510 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 853 ** 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 (-15) exists of draft-ietf-netconf-https-notif-01 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 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 Huawei 5 Expires: September 10, 2020 A. Clemm 6 Futurewei 7 T. Graf 8 Swisscom 9 P. Francois 10 INSA-Lyon 11 March 9, 2020 13 UDP based Publication Channel for Streaming Telemetry 14 draft-unyte-netconf-udp-pub-channel-00 16 Abstract 18 This document describes a UDP-based publication channel for streaming 19 telemetry use to collect data from devices. A new shim header is 20 proposed to facilitate the distributed data collection mechanism 21 which directly pushes data from line cards to the collector. Because 22 of the lightweight UDP encapsulation, higher frequency and better 23 transit performance can be achieved. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 10, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Transport Mechanisms . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 4 69 3.2. Configured Subscription . . . . . . . . . . . . . . . . . 5 70 4. UDP Transport for Publication Channel . . . . . . . . . . . . 6 71 4.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 6 72 4.2. Data Format of the UPC Message Header . . . . . . . . . . 7 73 4.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.3.1. Fragmentation Option . . . . . . . . . . . . . . . . 8 75 4.4. Data Encoding . . . . . . . . . . . . . . . . . . . . . . 9 76 5. Using DTLS to Secure UPC . . . . . . . . . . . . . . . . . . 10 77 5.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 11 79 5.3. DTLS Session Initiation . . . . . . . . . . . . . . . . . 11 80 5.4. Sending Data . . . . . . . . . . . . . . . . . . . . . . 11 81 5.5. Closure . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 12 83 7. A YANG Data Model for Management of UPC . . . . . . . . . . . 13 84 8. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 88 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 90 12.2. Informative References . . . . . . . . . . . . . . . . . 18 91 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 94 1. Introduction 96 Streaming telemetry refers to sending a continuous stream of 97 operational data from a device to a remote receiver. This provides 98 an ability to monitor a network from remote and to provide network 99 analytics. Devices generate telemetry data and push that data to a 100 collector for further analysis. By streaming the data, much better 101 performance, finer-grained sampling, monitoring accuracy, and 102 bandwidth utilization can be achieved than with polling-based 103 alternatives. 105 Sub-Notif [RFC8639] defines a mechanism that allows a collector to 106 subscribe to updates of YANG-defined data that is maintained in a 107 YANG [RFC7950] datastore. The mechanism separates the management and 108 control of subscriptions from the transport that is used to actually 109 stream and deliver the data. Three transports, NETCONF transport 110 [RFC8640], RESTCONF transport [I-D.ietf-netconf-restconf-notif] and 111 HTTPS transport [I-D.ietf-netconf-https-notif], have been defined so 112 far for the notification messages. 114 While powerful in its features and general in its architecture, in 115 its current form the mechanism needs to be extended to stream 116 telemetry data at high velocity from devices that feature a 117 distributed architecture. The transports that have been defined so 118 far, NETCONF and HTTP, are ultimately based on TCP and lack the 119 efficiency needed to stream data continuously at high velocity. A 120 lighter-weight, more efficient transport, e.g. a transport based on 121 UDP is needed. 123 o Firstly, data collector will suffer a lot of TCP connections from, 124 for example, many line cards equipped on different devices. 126 o Secondly, as no connection state needs to be maintained, UDP 127 encapsulation can be easily implemented by hardware which will 128 further improve the performance. 130 o Thirdly, because of the lightweight UDP encapsulation, higher 131 frequency and better transit performance can be achieved, which is 132 important for streaming telemetry. 134 This document specifies a higher-performance transport option for 135 Sub-Notif that leverages UDP. Specifically, it facilitates the 136 distributed data collection mechanism described in 137 [I-D.zhou-netconf-multi-stream-originators]. In the case of data 138 originating from multiple line cards, the centralized design requires 139 data to be internally forwarded from those line cards to the push 140 server, presumably on a main board, which then combines the 141 individual data items into a single consolidated stream. The 142 centralized data collection mechanism can result in a performance 143 bottleneck, especially when large amounts of data are involved. What 144 is needed instead is the support for a distributed mechanism that 145 allows to directly push multiple individual substreams, e.g. one from 146 each line card, without needing to first pass them through an 147 additional processing stage for internal consolidation, but still 148 allowing those substreams to be managed and controlled via a single 149 subscription. The proposed UDP based Publication Channel (UPC) 150 natively supports the distributed data collection mechanism. 152 The transport described in this document can be used for transmitting 153 notification messages over both IPv4 and IPv6 [RFC8200]. 155 While this document will focus on the data publication channel, the 156 subscription can be used in conjunction with the mechanism proposed 157 in [RFC8639] with extensions 158 [I-D.zhou-netconf-multi-stream-originators]. 160 2. Terminologies 162 Streaming Telemetry: refers to sending a continuous stream of 163 operational data from a device to a remote receiver. This provides 164 an ability to monitor a network from remote and to provide network 165 analytics. 167 3. Transport Mechanisms 169 For a complete pub-sub mechanism, this section will describe how the 170 UPC is used to interact with the Subscription Channel relying on 171 NETCONF or RESTCONF. 173 3.1. Dynamic Subscription 175 Dynamic subscriptions for Sub-Notif are configured and managed via 176 signaling messages transported over NETCONF [RFC6241] or RESTCONF 177 [RFC8040]. The Sub-Notif defined RPCs which are sent and responded 178 via the Subscription Channel (a), between the Subscriber and the 179 Subscription Server of the Publisher. In this case, only one 180 Receiver is associated with the Subscriber. In the Publisher, there 181 may be multiple data originators. Notification messages are pushed 182 on separate channels (b), from different data originators to the 183 Receiver. 185 +--------------+ +--------------+ 186 | Collector | | Publisher | 187 | | | | 188 | (a) (b) | | (a) (b) | 189 +--+------+----+ +--+-------+---+ 190 | | | | 191 | | RPC:establish-subscription | | 192 +----------------------------------------> | 193 | | RPC Reply: OK | | 194 <----------------------------------------+ | 195 | | UPC:notifications | | 196 | <-----------------------------------------+ 197 | | | | 198 | | RPC:modify-subscription | | 199 +----------------------------------------> | 200 | | RPC Reply: OK | | 201 <----------------------------------------+ | 202 | | UPC:notifications | | 203 | <-----------------------------------------+ 204 | | | | 205 | | RPC:delete-subscription | | 206 +----------------------------------------> | 207 | | RPC Reply: OK | | 208 <----------------------------------------+ | 209 | | | | 210 | | | | 211 + + + + 213 Fig. 2 Call Flow For Dynamic Subscription 215 In the case of dynamic subscription, the Receiver and the Subscriber 216 SHOULD be colocated. So UPC can use the source IP address of the 217 Subscription Channel as it's destination IP address. The Receiver 218 MUST support listening messages at the IANA-assigned PORT-X or PORT- 219 Y, but MAY be configured to listen at a different port. 221 For dynamic subscription, the Publication Channels MUST share fate 222 with the subscription session. In other words, when the delete- 223 subscription is received or the subscription session is broken, all 224 the associated Publication Channels MUST be closed. 226 3.2. Configured Subscription 228 For a Configured Subscription, there is no guarantee that the 229 Subscriber is currently in place with the associated Receiver(s). As 230 defined in Sub-Notif, the subscription configuration contains the 231 location information of all the receivers, including the IP address 232 and the port number. So that the data originator can actively send 233 generated messages to the corresponding Receivers via the UPC. 235 The first message MUST be a separate subscription-started 236 notification to indicate the Receiver that the pushing is started. 237 Then, the notifications can be sent immediately without any wait. 239 All the subscription state notifications, as defined in [RFC8639], 240 MUST be encapsulated to be separated notification messages. 242 +--------------+ +--------------+ 243 | Collector | | Publisher | 244 | | | | 245 | (a) (b) | | (a) (b) | 246 +--+------+----+ +--+-------+---+ 247 | | | | 248 | | Capability Exchange | | 249 <----------------------------------------> | 250 | | | | 251 | | Edit config(create) | | 252 +----------------------------------------> | 253 | | RPC Reply: OK | | 254 <----------------------------------------+ | 255 | | UPC:subscription started | | 256 | <-----------------------------------------+ 257 | | UPC:notifications | | 258 | <-----------------------------------------+ 259 | | | | 260 | | Edit config(delete) | | 261 +----------------------------------------> | 262 | | RPC Reply: OK | | 263 <----------------------------------------+ | 264 | | UPC:subscription terminated | | 265 | <-----------------------------------------+ 266 | | | | 267 | | | | 268 + + + + 270 Fig. 3 Call Flow For Configured Subscription 272 4. UDP Transport for Publication Channel 274 4.1. Design Overview 276 As specified in Sub-Notif, the telemetry data is encapsulated in the 277 NETCONF/RESTCONF notification message, which is then encapsulated and 278 carried in the transport protocols, e.g. TLS, HTTP2. The following 279 figure shows the overview of the typical UPC message structure. 281 o The Message Header contains information that can facilitate the 282 message transmission before de-serializing the notification 283 message. 285 o Notification Message is the encoded content that the publication 286 channel transports. The common encoding method includes GPB [1], 287 CBOR [RFC7049], JSON, and XML. 288 [I-D.ietf-netconf-notification-messages] describes the structure 289 of the Notification Message for both single notification and 290 multiple bundled notifications. 292 +-------+ +--------------+ +--------------+ 293 | UDP | | Message | | Notification | 294 | | | Header | | Message | 295 +-------+ +--------------+ +--------------+ 297 Fig. 4 UDP Publication Message Overview 299 4.2. Data Format of the UPC Message Header 301 The UPC Message Header contains information that can facilitate the 302 message transmission before de-serializing the notification message. 303 The data format is shown as follows. 305 0 1 2 3 306 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 307 +-------+---------------+-------+-------------------------------+ 308 | Vers. | Flag | ET | Length | 309 +-------+---------------+-------+-------------------------------+ 310 | Message-Generator-ID | 311 +---------------------------------------------------------------+ 312 | Message ID | 313 +---------------------------------------------------------------+ 314 ~ Options ~ 315 +---------------------------------------------------------------+ 317 Fig. 3 UPC Message Header Format 319 The Message Header contains the following field: 321 o Vers.: represents the PDU (Protocol Data Unit) encoding version. 322 The initial version value is 0. 324 o Flag: is a bitmap indicating what features this packet has and the 325 corresponding options attached. Each bit associates to one 326 feature and one option data. When the bit is set to 1, the 327 associated feature is enabled and the option data is attached. 329 The sequence of the presence of the options follows the bit order 330 of the bitmap. In this document, the flag is specified as 331 follows: 333 * bit 0, the fragmentation flag; 335 * other bits are reserved. 337 o ET: is a 4 bits identifier to indicate the encoding type used for 338 the Notification Message. 16 types of encoding can be expressed: 340 * 0: GPB; 342 * 1: CBOR; 344 * 2: JSON; 346 * 3: XML; 348 * others are reserved. 350 o Length: is the total length of the message, measured in octets, 351 including message header. 353 o Message-Generator-ID: is a 32-bit identifier of the process which 354 created the notification message. This allows disambiguation of 355 an information source, such as the identification of different 356 line cards sending the notification messages. The source IP 357 address of the UDP datagrams SHOULD NOT be interpreted as the 358 identifier for the host that originated the UPC message. The 359 entity sending the UPC message could be merely a relay. 361 o The Message ID is generated continuously by the message generator. 362 Different subscribers share the same notification ID sequence. 364 o Options: is a variable-length field. The details of the Options 365 will be described in the respective sections below. 367 4.3. Options 369 The order of packing the data fields in the Options field follows the 370 bit order of the Flag field. 372 4.3.1. Fragmentation Option 374 UDP palyload has a theoretical length limitation to 65535. Other 375 encapsulation headers will make the actual payload even shorter. 376 Binary encodings like GPB and CBOR can make the message compact. So 377 that the message can be encapsulated within one UDP packet, hence 378 fragmentation will not easily happen. However, text encodings like 379 JSON and XML can easily make the message exceed the UDP length 380 limitation. 382 The Fragmentation Option can help not Application layer can split the 383 YANG tree into several leaves. Or table into several rows. But the 384 leaf or the row cannot be split any further. Now we consider a very 385 long path. Since the GPB and CBOR are so compact, it's easy to fit 386 into a UDP packet. But for JSON or XML, it is possible that even one 387 leaf will exceed the UDP boundary. 389 0 1 2 3 390 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 391 +-------------------------------------------------------------+-+ 392 | Fragment Number |L| 393 +-------------------------------------------------------------+-+ 395 Fig. 5 Fragmentation Option Format 397 The Fragmentation Option is available in the message header when the 398 fragmentation flag is set to 1. The option contains: 400 Fragment Number: indicates the sequence number of the current 401 fragment. 403 L: is a flag to indicate whether the current fragment is the last 404 one. When 0 is set, current fragment is not the last one, hence more 405 fragments are expected. When 1 is set, current fragment is the last 406 one. 408 4.4. Data Encoding 410 Subscribed data can be encoded in GPB, CBOR, XML or JSON format. It 411 is conceivable that additional encodings may be supported as options 412 in the future. This can be accomplished by augmenting the 413 subscription data model with additional identity statements used to 414 refer to requested encodings. 416 Implementation may support different encoding method per 417 subscription. When bundled notifications is supported between the 418 publisher and the receiver, only subscribed notifications with the 419 same encoding can be bundled as one message. 421 5. Using DTLS to Secure UPC 423 The Datagram Transport Layer Security (DTLS) protocol [RFC6347] is 424 designed to meet the requirements of applications that need secure 425 datagram transport. 427 DTLS can be used as a secure transport to counter all the primary 428 threats to UDP based Publication Channel: 430 o Confidentiality to counter disclosure of the message contents. 432 o Integrity checking to counter modifications to a message on a hop- 433 by-hop basis. 435 o Server or mutual authentication to counter masquerade. 437 In addition, DTLS also provides: 439 o A cookie exchange mechanism during handshake to counter Denial of 440 Service attacks. 442 o A sequence number in the header to counter replay attacks. 444 5.1. Transport 446 As shown in Figure 6, the DTLS is layered next to the UDP transport 447 is to provide reusable security and authentication functions over 448 UDP. No DTLS extension is required to enable UPC messages over DTLS. 450 +-----------------------------+ 451 | UPC Message | 452 +-----------------------------+ 453 | DTLS | 454 +-----------------------------+ 455 | UDP | 456 +-----------------------------+ 457 | IP | 458 +-----------------------------+ 460 Fig. 6: Protocol Stack for DTLS secured UPC 462 The application implementer will map a unique combination of the 463 remote address, remote port number, local address, and local port 464 number to a session. 466 Each UPC message is delivered by the DTLS record protocol, which 467 assigns a sequence number to each DTLS record. Although the DTLS 468 implementer may adopt a queue mechanism to resolve reordering, it may 469 not assure that all the messages are delivered in order when mapping 470 on the UDP transport. 472 Since UDP is an unreliable transport, with DTLS, an originator or 473 relay may not realize that a collector has gone down or lost its DTLS 474 connection state, so messages may be lost. 476 The DTLS record has its own sequence number, the encryption and 477 decryption will done by DTLS layer, UPC Message layer will not 478 concern this. 480 5.2. Port Assignment 482 The Publisher is always a DTLS client, and the Receiver is always a 483 DTLS server. The Receivers MUST support accepting UPC Messages on 484 the UDP port PORT-Y, but MAY be configurable to listen on a different 485 port. The Publisher MUST support sending UPC messages to the UDP 486 port PORT-Y, but MAY be configurable to send messages to a different 487 port. The Publisher MAY use any source UDP port for transmitting 488 messages. 490 5.3. DTLS Session Initiation 492 The Publisher initiates a DTLS connection by sending a DTLS Client 493 Hello to the Receiver. Implementations MUST support the denial of 494 service countermeasures defined by DTLS. When these countermeasures 495 are used, the Receiver responds with a DTLS Hello Verify Request 496 containing a cookie. The Publisher responds with a DTLS Client Hello 497 containing the received cookie, which initiates the DTLS handshake. 498 The Publisher MUST NOT send any UPC messages before the DTLS 499 handshake has successfully completed. 501 Implementations MUST support DTLS 1.0 [RFC4347] and MUST support the 502 mandatory to implement cipher suite, which is 503 TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246] as specified in DTLS 1.0. If 504 additional cipher suites are supported, then implementations MUST NOT 505 negotiate a cipher suite that employs NULL integrity or 506 authentication algorithms. 508 Where privacy is REQUIRED, then implementations must either negotiate 509 a cipher suite that employs a non-NULL encryption algorithm or else 510 achieve privacy by other means, such as a physically secured network. 512 5.4. Sending Data 514 All UPC messages MUST be sent as DTLS "application_data". It is 515 possible that multiple UPC messages be contained in one DTLS record, 516 or that a publication message be transferred in multiple DTLS 517 records. The application data is defined with the following ABNF 518 [RFC5234] expression: 520 APPLICATION-DATA = 1*UPC-FRAME 522 UPC-FRAME = MSG-LEN SP UPC-MSG 524 MSG-LEN = NONZERO-DIGIT *DIGIT 526 SP = %d32 528 NONZERO-DIGIT = %d49-57 530 DIGIT = %d48 / NONZERO-DIGIT 532 UPC-MSG is defined in section 5.2. 534 5.5. Closure 536 A Publisher MUST close the associated DTLS connection if the 537 connection is not expected to deliver any UPC Messages later. It 538 MUST send a DTLS close_notify alert before closing the connection. A 539 Publisher (DTLS client) MAY choose to not wait for the Receiver's 540 close_notify alert and simply close the DTLS connection. Once the 541 Receiver gets a close_notify from the Publisher, it MUST reply with a 542 close_notify. 544 When no data is received from a DTLS connection for a long time 545 (where the application decides what "long" means), Receiver MAY close 546 the connection. The Receiver (DTLS server) MUST attempt to initiate 547 an exchange of close_notify alerts with the Publisher before closing 548 the connection. Receivers that are unprepared to receive any more 549 data MAY close the connection after sending the close_notify alert. 551 Although closure alerts are a component of TLS and so of DTLS, they, 552 like all alerts, are not retransmitted by DTLS and so may be lost 553 over an unreliable network. 555 6. Congestion Control 557 Congestion control mechanisms that respond to congestion by reducing 558 traffic rates and establish a degree of fairness between flows that 559 share the same path are vital to the stable operation of the Internet 560 [RFC2914]. While efficient, UDP has no build-in congestion control 561 mechanism. Because streaming telemetry can generate unlimited 562 amounts of data, transferring this data over UDP is generally 563 problematic. It is not recommended to use the UDP based publication 564 channel over congestion-sensitive network paths. The only 565 environments where the UDP based publication channel MAY be used are 566 managed networks. The deployments require the network path has been 567 explicitly provisioned for the UDP based publication channel through 568 traffic engineering mechanisms, such as rate limiting or capacity 569 reservations. 571 7. A YANG Data Model for Management of UPC 573 The YANG model defined in Section 9 has two leafs augmented into one 574 place of Sub-Notif [RFC8639], plus one identities. 576 module: ietf-upc-subscribed-notifications 577 augment /sn:subscriptions/sn:subscription/sn:receivers/sn:receiver: 578 +--rw address? inet:ip-address 579 +--rw port? inet:port-number 581 8. YANG Module 583 file "ietf-upc-subscribed-notifications@2020-02-26.yang" 584 module ietf-upc-subscribed-notifications { 585 yang-version 1.1; 586 namespace 587 "urn:ietf:params:xml:ns:yang:ietf-upc-subscribed-notifications"; 588 prefix upcsn; 589 import ietf-subscribed-notifications { 590 prefix sn; 591 reference 592 "RFC 8639: Subscription to YANG Notifications"; 593 } 594 import ietf-inet-types { 595 prefix inet; 596 reference 597 "RFC 6991: Common YANG Data Types"; 598 } 600 organization "IETF NETCONF (Network Configuration) Working Group"; 601 contact 602 "WG Web: 603 WG List: 605 Editor: Guangying Zheng 606 608 Editor: Tianran Zhou 609 611 Editor: Alexander Clemm 612 "; 614 description 615 "Defines UDP Publish Channel as a supported transport for subscribed 616 event notifications. 618 Copyright (c) 2018 IETF Trust and the persons identified as authors 619 of the code. All rights reserved. 621 Redistribution and use in source and binary forms, with or without 622 modification, is permitted pursuant to, and subject to the license 623 terms contained in, the Simplified BSD License set forth in Section 624 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 625 (https://trustee.ietf.org/license-info). 627 This version of this YANG module is part of RFC XXXX; see the RFC 629 itself for full legal notices."; 631 revision 2020-02-26 { 632 description 633 "Initial version"; 634 reference 635 "RFC XXXX: UDP based Publication Channel for Streaming Telemetry"; 636 } 638 identity upc { 639 base sn:transport; 640 description 641 "UPC is used as transport for notification messages and state 642 change notifications."; 643 } 645 identity encode-cbor { 646 base sn:encoding; 647 description 648 "Encode data using CBOR as described in RFC 7049."; 649 reference 650 "RFC 7049: Concise Binary Object Representation"; 651 } 653 identity encode-gpb { 654 base sn:encoding; 655 description 656 "Encode data using gpb."; 657 } 659 grouping target-receiver { 660 description 661 "Provides a reusable description of a UPC target receiver."; 663 leaf address { 664 type inet:ip-address; 665 description 666 "IP address of target upc receiver, which can be IPv4 address or 667 IPV6 address."; 668 } 669 leaf port { 670 type inet:port-number; 671 description 672 "Port number of target UPC receiver, if not specify, system 673 should use default port number."; 674 } 676 leaf enable-fragmentation { 677 type boolean; 678 default false; 679 description 680 "The switch for the fragmentation feature. When disabled, the 681 publisher will not allow fragmentation for a very large data"; 682 } 683 } 685 augment "/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver" { 686 description 687 "This augmentation allows UPC specific parameters to be 688 exposed for a subscription."; 689 uses target-receiver; 690 } 691 } 692 694 9. IANA Considerations 696 This RFC requests that IANA assigns three UDP port numbers in the 697 "Registered Port Numbers" range with the service names "upc" and 698 "upc-dtls". These ports will be the default ports for the UDP based 699 Publication Channel for NETCONF and RESTCONF. Below is the 700 registration template following the rules in [RFC6335]. 702 Service Name: upc 704 Transport Protocol(s): UDP 706 Assignee: IESG 708 Contact: IETF Chair 710 Description: UDP based Publication Channel 711 Reference: RFC XXXX 713 Port Number: PORT-X 715 Service Name: upc-dtls 717 Transport Protocol(s): UDP 719 Assignee: IESG 721 Contact: IETF Chair 723 Description: UDP based Publication Channel (DTLS) 725 Reference: RFC XXXX 727 Port Number: PORT-Y 729 IANA is requested to assign a new URI from the IETF XML Registry 730 [RFC3688]. The following URI is suggested: 732 URI: urn:ietf:params:xml:ns:yang:ietf-upc-subscribed-notifications 733 Registrant Contact: The IESG. 734 XML: N/A; the requested URI is an XML namespace. 736 This document also requests a new YANG module name in the YANG Module 737 Names registry [RFC7950] with the following suggestion: 739 name: ietf-upc-subscribed-notifications 740 namespace: urn:ietf:params:xml:ns:yang:ietf-upc-subscribed-notifications 741 prefix: upcsn 742 reference: RFC XXXX 744 10. Security Considerations 746 TBD 748 11. Acknowledgements 750 The authors of this documents would like to thank Eric Voit, Tim 751 Jenkins, and Huiyang Yang for the initial comments. 753 12. References 754 12.1. Normative References 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, 758 DOI 10.17487/RFC2119, March 1997, 759 . 761 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 762 RFC 2914, DOI 10.17487/RFC2914, September 2000, 763 . 765 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 766 DOI 10.17487/RFC3688, January 2004, 767 . 769 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 770 Security", RFC 4347, DOI 10.17487/RFC4347, April 2006, 771 . 773 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 774 Specifications: ABNF", STD 68, RFC 5234, 775 DOI 10.17487/RFC5234, January 2008, 776 . 778 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 779 (TLS) Protocol Version 1.2", RFC 5246, 780 DOI 10.17487/RFC5246, August 2008, 781 . 783 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 784 and A. Bierman, Ed., "Network Configuration Protocol 785 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 786 . 788 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 789 Cheshire, "Internet Assigned Numbers Authority (IANA) 790 Procedures for the Management of the Service Name and 791 Transport Protocol Port Number Registry", BCP 165, 792 RFC 6335, DOI 10.17487/RFC6335, August 2011, 793 . 795 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 796 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 797 January 2012, . 799 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 800 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 801 October 2013, . 803 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 804 RFC 7950, DOI 10.17487/RFC7950, August 2016, 805 . 807 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 808 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 809 . 811 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 812 (IPv6) Specification", STD 86, RFC 8200, 813 DOI 10.17487/RFC8200, July 2017, 814 . 816 [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 817 E., and A. Tripathy, "Subscription to YANG Notifications", 818 RFC 8639, DOI 10.17487/RFC8639, September 2019, 819 . 821 [RFC8640] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, 822 E., and A. Tripathy, "Dynamic Subscription to YANG Events 823 and Datastores over NETCONF", RFC 8640, 824 DOI 10.17487/RFC8640, September 2019, 825 . 827 12.2. Informative References 829 [I-D.ietf-netconf-https-notif] 830 Jethanandani, M. and K. Watsen, "An HTTPS-based Transport 831 for Configured Subscriptions", draft-ietf-netconf-https- 832 notif-01 (work in progress), October 2019. 834 [I-D.ietf-netconf-notification-messages] 835 Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A. 836 Clemm, "Notification Message Headers and Bundles", draft- 837 ietf-netconf-notification-messages-08 (work in progress), 838 November 2019. 840 [I-D.ietf-netconf-restconf-notif] 841 Voit, E., Rahman, R., Nilsen-Nygaard, E., Clemm, A., and 842 A. Bierman, "Dynamic subscription to YANG Events and 843 Datastores over RESTCONF", draft-ietf-netconf-restconf- 844 notif-15 (work in progress), June 2019. 846 [I-D.zhou-netconf-multi-stream-originators] 847 Zhou, T., Zheng, G., Voit, E., and A. Clemm, "Subscription 848 to Multiple Stream Originators", draft-zhou-netconf-multi- 849 stream-originators-10 (work in progress), November 2019. 851 12.3. URIs 853 [1] https://developers.google.com/protocol-buffers/ 855 Authors' Addresses 857 Guangying Zheng 858 Huawei 859 101 Yu-Hua-Tai Software Road 860 Nanjing, Jiangsu 861 China 863 Email: zhengguangying@huawei.com 865 Tianran Zhou 866 Huawei 867 156 Beiqing Rd., Haidian District 868 Beijing 869 China 871 Email: zhoutianran@huawei.com 873 Alexander Clemm 874 Futurewei 875 2330 Central Expressway 876 Santa Clara, California 877 USA 879 Email: alex@futurewei.com 881 Thomas Graf 882 Swisscom 883 Binzring 17 884 Zuerich 8045 885 Switzerland 887 Email: thomas.graf@swisscom.com 889 Pierre Francois 890 INSA-Lyon 891 Lyon 892 France 894 Email: pierre.francois@insa-lyon.fr