idnits 2.17.1 draft-ietf-netconf-udp-pub-channel-02.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 18, 2018) is 2231 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 640 -- Looks like a reference, but probably isn't: '2' on line 468 -- Looks like a reference, but probably isn't: '3' on line 466 -- Looks like a reference, but probably isn't: '4' on line 468 -- Looks like a reference, but probably isn't: '5' on line 468 -- Looks like a reference, but probably isn't: '6' on line 466 -- Looks like a reference, but probably isn't: '7' on line 468 -- Looks like a reference, but probably isn't: '8' on line 468 -- Looks like a reference, but probably isn't: '9' on line 464 -- Looks like a reference, but probably isn't: '0' on line 468 == Missing Reference: 'RFC6335' is mentioned on line 540, but not defined ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-22) exists of draft-ietf-netconf-netconf-event-notifications-08 == 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-04 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-subscribed-notifications-10 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-15 == Outdated reference: A later version (-10) exists of draft-zhou-netconf-multi-stream-originators-01 Summary: 1 error (**), 0 flaws (~~), 8 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 19, 2018 Huawei 6 March 18, 2018 8 UDP based Publication Channel for Streaming Telemetry 9 draft-ietf-netconf-udp-pub-channel-02 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 19, 2018. 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 . . . . . . . . . . . . . . . . . 6 66 5. UDP Transport for Publication Channel . . . . . . . . . . . . 7 67 5.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 7 68 5.2. Data Format of the Message Header . . . . . . . . . . . . 8 69 5.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.3.1. Reliability Option . . . . . . . . . . . . . . . . . 10 71 5.3.2. Fragmentation Option . . . . . . . . . . . . . . . . 11 72 5.4. Data Encoding . . . . . . . . . . . . . . . . . . . . . . 11 73 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 12 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 10.2. Informative References . . . . . . . . . . . . . . . . . 13 80 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 Streaming telemetry refers to sending a continuous stream of 87 operational data from a device to a remote receiver. This provides 88 an ability to monitor a network from remote and to provide network 89 analytics. Devices generate telemetry data and push that data to a 90 collector for further analysis. By streaming the data, much better 91 performance, finer-grained sampling, monitoring accuracy, and 92 bandwidth utilization can be achieved than with polling-based 93 alternatives. 95 Sub-Notif [I-D.ietf-netconf-subscribed-notifications] and YANG-Push 96 [I-D.ietf-netconf-yang-push] defines a mechanism that allows a 97 collector to subscribe to updates of YANG-defined data that is 98 maintained in a YANG [RFC7950] datastore. The mechanism separates 99 the management and control of subscriptions from the transport that 100 is used to actually stream and deliver the data. Two transports, 101 NETCONF transport [I-D.ietf-netconf-netconf-event-notifications] and 102 HTTP transport [I-D.ietf-netconf-restconf-notif], have been defined 103 so far for the notification messages. 105 While powerful in its features and general in its architecture, in 106 its current form the mechanism needs to be extended to stream 107 telemetry data at high velocity from devices that feature a 108 distributed architecture. The transports that have been defined so 109 far, NETCONF and HTTP, are ultimately based on TCP and lack the 110 efficiency needed to stream data continuously at high velocity. A 111 lighter-weight, more efficient transport, e.g. a transport based on 112 UDP is needed. 114 o Firstly, data collector will suffer a lot of TCP connections from, 115 for example, many line cards equipped on different devices. 117 o Secondly, as no connection state needs to be maintained, UDP 118 encapsulation can be easily implemented by hardware which will 119 further improve the performance. 121 o Thirdly, because of the lightweight UDP encapsulation, higher 122 frequency and better transit performance can be achieved, which is 123 important for streaming telemetry. 125 This document specifies a higher-performance transport option for 126 YANG-Push that leverages UDP. Specifically, it facilitates the 127 distributed data collection mechanism described in 128 [I-D.zhou-netconf-multi-stream-originators]. In the case of data 129 originating from multiple line cards, the centralized design requires 130 data to be internally forwarded from those line cards to the push 131 server, presumably on a main board, which then combines the 132 individual data items into a single consolidated stream. The 133 centralized data collection mechanism can result in a performance 134 bottleneck, especially when large amounts of data are involved. What 135 is needed instead is the support for a distributed mechanism that 136 allows to directly push multiple individual substreams, e.g. one from 137 each line card, without needing to first pass them through an 138 additional processing stage for internal consolidation, but still 139 allowing those substreams to be managed and controlled via a single 140 subscription. The proposed UDP based Publication Channel (UPC) 141 natively supports the distributed data collection mechanism. 143 The transport described in this document can be used for transmitting 144 notification messages over both IPv4 and IPv6 [RFC8200]. 146 While this document will focus on the data publication channel, the 147 subscription can be used in conjunction with the mechanism proposed 148 in [I-D.ietf-netconf-yang-push] with extensions 149 [I-D.zhou-netconf-multi-stream-originators]. 151 2. Terminology 153 Streaming Telemetry: refers to sending a continuous stream of 154 operational data from a device to a remote receiver. This provides 155 an ability to monitor a network from remote and to provide network 156 analytics. 158 3. Solution Overview 160 The typical distributed data collection solution is shown in Fig. 1. 161 Both the Collector and the Subscribed Domain can be distributed. The 162 Collector includes the Subscriber and a set of Receivers. And the 163 Subscribed Domain includes a Master and a set of Agents. The 164 Subscriber cannot see the Agents directly, so it will send the Global 165 Subscription information to the Master (e.g., main board) via the 166 Subscription Channel. When receiving a Global Subscription, the 167 Master decomposes the subscription request into multiple Component 168 Subscriptions, each involving data from a separate internal telemetry 169 source, for example a line card. The Component Subscriptions are 170 distributed to the Agents. Subsequently, each data originator 171 generates its own stream of telemetry data, collecting and 172 encapsulating the packets per the Component Subscription and 173 streaming them to the designated Receivers. This distributed data 174 collection mechanism may form multiple Publication Channels between 175 the Data Originators and the Receivers. The Collector is able to 176 assemble many pieces of data associated with one Global Subscription. 178 The Publication Channel supports the reliable data streaming, for 179 example for some alarm events. The Collector has the option of 180 deducing the packet loss and the disorder based on the information 181 carried by the notification data. And the Collector will decide the 182 behavior to request retransmission. 184 The rest of the draft describes the UDP based Publication Channel 185 (UPC). 187 +---------------------------------+ 188 | Collector | 189 | | 190 | +------------+ +-----------+ | 191 | | Subscriber | | Receivers | | 192 | +----+-------+ +--^----^---+ | 193 | | | | | 194 +---------------------------------+ 195 | | | 196 Subscription | | | Publication 197 Channel | | | Channel 198 | +---------+ | 199 | | | 200 +---------------------------------+ 201 | | | | | 202 | +---v---+--+ +------+-+ | 203 | | Master | | Agents | | 204 | +----------+ +--------+ | 205 | | 206 | Subscribed Domain | 207 +---------------------------------+ 209 Fig. 1 Distributed Data Collection 211 4. Transport Mechanisms 213 For a complete pub-sub mechanism, this section will describe how the 214 UPC is used to interact with the Subscription Channel relying on 215 NETCONF or RESTCONF. 217 4.1. Dynamic Subscription 219 Dynamic subscriptions for YANG-Push [I-D.ietf-netconf-yang-push] are 220 configured and managed via signaling messages transported over 221 NETCONF [RFC6241] or RESTCONF [RFC8040]. The YANG-Push defined RPCs 222 are sent and responded via the Subscription Channel (a), between the 223 Subscriber and the Master of the Subscribed Domain. In this case, 224 only one Receiver is associated with the Subscriber. In the 225 Subscribed Domain, there may be multiple Data Originators. 226 Notification messages are pushed on separate channels (b), from 227 different Data Originators to the Receiver . 229 +--------------+ +--------------+ 230 | Collector | | Subscribed | 231 | | | Domain | 232 | (a) (b) | | (a) (b) | 233 +--+------+----+ +--+-------+---+ 234 | | | | 235 | | RPC:establish-subscription | | 236 +----------------------------------------> | 237 | | RPC Reply: OK | | 238 <----------------------------------------+ | 239 | | UPC:notifications | | 240 | <-----------------------------------------+ 241 | | | | 242 | | RPC:modify-subscription | | 243 +----------------------------------------> | 244 | | RPC Reply: OK | | 245 <----------------------------------------+ | 246 | | UPC:notifications | | 247 | <-----------------------------------------+ 248 | | | | 249 | | RPC:delete subscription | | 250 +----------------------------------------> | 251 | | RPC Reply: OK | | 252 <----------------------------------------+ | 253 | | | | 254 | | | | 255 + + + + 257 Fig. 2 Call Flow for Dynamic Subscription 259 In the case of dynamic subscription, the Receiver and the Subscriber 260 SHOULD be collocated. So UPC can use the source IP address of the 261 Subscription Channel as it's destination IP address. The Receiver 262 MUST support listening messages at the IANA-assigned PORT-X, but MAY 263 be configured to listen at a different port. 265 4.2. Configured Subscription 267 For a Configured Subscription, there is no guarantee that the 268 Subscriber is currently in place with the associated Receiver(s). As 269 defined in [I-D.ietf-netconf-yang-push], the subscription 270 configuration contains the location information of all the receivers, 271 including the IP address and the port number. So that the Data 272 Originator can actively send generated messages to the corresponding 273 Receivers via the UPC. 275 The first message MUST be a separate subscription-started 276 notification to indicate the Receiver that the pushing is started. 277 Then, the notifications can be sent immediately without any wait. 279 All the subscription state notifications, as defined in 280 [I-D.ietf-netconf-subscribed-notifications], MUST be encapsulated to 281 be separated notification messages. 283 +--------------+ +--------------+ 284 | Collector | | Subscribed | 285 | | | Domain | 286 | (a) (b) | | (a) (b) | 287 +--+------+----+ +--+-------+---+ 288 | | | | 289 | | Capability Exchange | | 290 <----------------------------------------> | 291 | | | | 292 | | Edit config(create) | | 293 +----------------------------------------> | 294 | | RPC Reply: OK | | 295 <----------------------------------------+ | 296 | | UPC:subscription started | | 297 | <-----------------------------------------+ 298 | | UPC:notifications | | 299 | <-----------------------------------------+ 300 | | | | 301 | | Edit config(delete) | | 302 +----------------------------------------> | 303 | | RPC Reply: OK | | 304 <----------------------------------------+ | 305 | | UPC:subscription terminated | | 306 | <-----------------------------------------+ 307 | | | | 308 | | | | 309 + + + + 311 Fig. 3 Call Flow for Configured Subscription 313 5. UDP Transport for Publication Channel 315 5.1. Design Overview 317 As specified in YANG-Push, the telemetry data is encapsulated in the 318 NETCONF/RESTCONF notification message, which is then encapsulated and 319 carried in the transport protocols, e.g. TLS, HTTP2. The following 320 figure shows the overview of the typical UDP publication message 321 structure. 323 o The Message Header contains information that can facilitate the 324 message transmission before de-serializing the notification 325 message. 327 o Notification Message is the encoded content that the publication 328 channel transports. The common encoding method includes GPB [1], 329 CBOR [RFC7049], JSON, and XML. 330 [I-D.ietf-netconf-notification-messages] describes the structure 331 of the Notification Message for both single notification and 332 multiple bundled notifications. 334 +-------+ +--------------+ +--------------+ 335 | UDP | | Message | | Notification | 336 | | | Header | | Message | 337 +-------+ +--------------+ +--------------+ 339 Fig. 4 UDP Publication Message Overview 341 5.2. Data Format of the Message Header 343 The Message Header contains information that can facilitate the 344 message transmission before de-serializing the notification message. 345 The data format is shown as follows. 347 0 1 2 3 348 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 349 +-------+---------------+-------+-------------------------------+ 350 | Vers. | Flag | ET | Length | 351 +-------+---------------+-------+-------------------------------+ 352 | Subscribed Domain ID | 353 +---------------------------------------------------------------+ 354 | Message ID | 355 +---------------------------------------------------------------+ 356 ~ Options ~ 357 +---------------------------------------------------------------+ 359 Fig. 5 Message Header Format 361 The Message Header contains the following field: 363 o Vers.: represents the PDU (Protocol Data Unit) encoding version. 364 The initial version value is 0. 366 o Flag: is a bitmap indicating what features this packet has and the 367 corresponding options attached. Each bit associates to one 368 feature and one option data. When the bit is set to 1, the 369 associated feature is enabled and the option data is attached. 371 The sequence of the presence of the options follows the bit order 372 of the bitmap. In this document, the flag is specified as 373 follows: 375 * bit 0, the reliability flag; 377 * bit 1, the fragmentation flag; 379 * other bits are reserved. All the reserved bits MUST be set to 380 0. 382 o ET: is a 4 bits identifier to indicate the encoding type used for 383 the Notification Message. While 16 types of encoding can be 384 expressed, this document specifies the following usage: 386 * 0: GPB; 388 * 1: CBOR; 390 * 2: JSON; 392 * 3: XML; 394 * others are reserved. 396 o Length: is the total length of the message, measured in octets, 397 including message header. If the notification message is 398 fragmented, this Length indicates the actual length of the current 399 message fragmentation. 401 o Subscribed Domain ID: is a 32-bit identifier of the Subscribed 402 Domain. With this parameter, the receiver can easily identify 403 messages generated from the same Subscription Domain. One 404 possible value is the visible IPv4 address of the Master. 406 o The Message ID is generated continuously by the Data Originator. 407 Different subscribers share the same Message ID sequence. 408 Different fragmentations of one message share the same Message ID. 410 o Options: is a variable-length field. The details of the Options 411 will be described in the respective sections below. 413 5.3. Options 415 The order of packing the data fields in the Options field follows the 416 bit order of the Flag field. 418 5.3.1. Reliability Option 420 The UDP based publication transport described in this document 421 provides two streaming modes, the reliable mode an the unreliable 422 mode, for different SLA (Service Level Agreement) and telemetry 423 requirements. 425 In the unreliable streaming mode, the line card pushes the 426 encapsulated data to the data collector without any sequence 427 information. So the subscriber does not know whether the data is 428 correctly received or not. 430 The reliable streaming mode provides sequence information in the UDP 431 packet, based on which the subscriber can deduce the packet loss and 432 disorder. Then the subscriber can decide whether to request the 433 retransmission of the lost packets. 435 In most case, the unreliable streaming mode is preferred. Because 436 the reliable streaming mode will cost more network bandwidth and 437 precious device resource. Different from the unreliable streaming 438 mode, the line card cannot remove the sent reliable notifications 439 immediately, but to keep them in the memory for a while. Reliable 440 notifications may be pushed multiple times, which will increase the 441 traffic. When choosing the reliable streaming mode or the unreliable 442 streaming mode, the operate need to consider the reliable requirement 443 together with the resource usage. 445 When the reliability flag bit is set to 1 in the Flag field, the 446 following option data will be attached 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 | Previous Message ID | 452 +---------------------------------------------------------------+ 454 Fig. 4 Reliability Option Format 456 The Data Originator has the capability of index the Previous Message 457 ID for the message. Together with the current Message ID, the 458 Receiver can detect whether the current message is in a right order. 460 For example, there are two subscriber A and B, 462 o Message IDs for the generator are : [1, 2, 3, 4, 5, 6, 7, 8, 9], 463 in which Subscriber A subscribes [1,2,3,6,7] and Subscriber B 464 subscribes [1,2,4,5,7,8,9]. 466 o Subscriber A will receive : [0,1][1,2][2,3][3,6][6,7]. 468 o Subscriber B will receive : [0,1][1,2][2,4][4,5][5,7][7,8]. 470 5.3.2. Fragmentation Option 472 UDP payload has a theoretical length limitation to 65535. Other 473 encapsulation headers will make the actual payload even shorter. 474 Binary encodings like GPB and CBOR can generate a compact 475 notification message. So that the message can fit in one UDP packet. 476 In this case, fragmentation will not easily happen. However, text 477 encodings like JSON and XML can easily generate a notification 478 message exceeding the UDP length limitation. 480 The fragmentation flag in the fixed header is set to 1 only when the 481 Notification Message is actually fragmented. And the Fragmentation 482 Option is available in the message header when the fragmentation flag 483 is set to 1. 485 The Fragmentation Option is formatted as follow: 487 0 1 2 3 488 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 489 +-------------------------------------------------------------+-+ 490 | Fragment Number |L| 491 +---------------------------------------------------------------+ 493 Fig. 5 Fragmentation Option Format 495 This option contains: 497 o Fragment Number: indicates the sequence number of the current 498 fragment. Together with the Message ID, the Receiver can compose 499 the entire Notification Message. 501 o L: is a flag to indicate whether the current fragment is the last 502 one. When 0 is set, current fragment is not the last one, hence 503 more fragments are expected. When 1 is set, current fragment is 504 the last one. 506 5.4. Data Encoding 508 Subscribed data can be encoded in GPB, CBOR, XML or JSON format. It 509 is conceivable that additional encodings may be supported as options 510 in the future. This can be accomplished by augmenting the 511 subscription data model with additional identity statements used to 512 refer to requested encodings. 514 Implementation may support different encoding method per 515 subscription. When bundled notifications is supported between the 516 publisher and the receiver, only subscribed notifications with the 517 same encoding can be bundled as one message. 519 6. Congestion Control 521 Congestion control mechanisms that respond to congestion by reducing 522 traffic rates and establish a degree of fairness between flows that 523 share the same path are vital to the stable operation of the Internet 524 [RFC2914]. While efficient, UDP has no build-in congestion control 525 mechanism. Because streaming telemetry can generate unlimited 526 amounts of data, transferring this data over UDP is generally 527 problematic. It is not recommended to use the UPC over congestion- 528 sensitive network paths. The only environments where the UPC MAY be 529 used are managed networks. The deployments require the network path 530 has been explicitly provisioned for the UPC through traffic 531 engineering mechanisms, such as rate limiting or capacity 532 reservations. 534 7. IANA Considerations 536 This RFC requests that IANA assigns one UDP port number in the 537 "Registered Port Numbers" range with the service names "udp-pub-ch". 538 This port will be the default port for the UDP based publication 539 channel for NETCONF and RESTCONF. Below is the registration template 540 following the rules in [RFC6335]. 542 Service Name: udp-pub-ch 544 Transport Protocol(s): UDP 546 Assignee: IESG 548 Contact: IETF Chair 550 Description: NETCONF Call Home (SSH) 552 Reference: RFC XXXX 554 Port Number: PORT-X 556 8. Security Considerations 558 TBD 560 9. Acknowledgements 562 The authors of this documents would like to thank Eric Voit, Tim 563 Jenkins, and Huiyang Yang for the initial comments. 565 10. References 567 10.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, 571 DOI 10.17487/RFC2119, March 1997, 572 . 574 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 575 RFC 2914, DOI 10.17487/RFC2914, September 2000, 576 . 578 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 579 and A. Bierman, Ed., "Network Configuration Protocol 580 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 581 . 583 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 584 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 585 October 2013, . 587 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 588 RFC 7950, DOI 10.17487/RFC7950, August 2016, 589 . 591 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 592 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 593 . 595 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 596 (IPv6) Specification", STD 86, RFC 8200, 597 DOI 10.17487/RFC8200, July 2017, 598 . 600 10.2. Informative References 602 [I-D.ietf-netconf-netconf-event-notifications] 603 Prieto, A., Voit, E., Clemm, A., Nilsen-Nygaard, E., and 604 A. Tripathy, "NETCONF Support for Event Notifications", 605 draft-ietf-netconf-netconf-event-notifications-08 (work in 606 progress), February 2018. 608 [I-D.ietf-netconf-notification-messages] 609 Voit, E., Birkholz, H., Bierman, A., Clemm, A., and T. 610 Jenkins, "Notification Message Headers and Bundles", 611 draft-ietf-netconf-notification-messages-03 (work in 612 progress), February 2018. 614 [I-D.ietf-netconf-restconf-notif] 615 Voit, E., Tripathy, A., Nilsen-Nygaard, E., Clemm, A., 616 Prieto, A., and A. Bierman, "RESTCONF and HTTP Transport 617 for Event Notifications", draft-ietf-netconf-restconf- 618 notif-04 (work in progress), January 2018. 620 [I-D.ietf-netconf-subscribed-notifications] 621 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 622 A. Tripathy, "Custom Subscription to Event Streams", 623 draft-ietf-netconf-subscribed-notifications-10 (work in 624 progress), February 2018. 626 [I-D.ietf-netconf-yang-push] 627 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 628 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 629 Subscription", draft-ietf-netconf-yang-push-15 (work in 630 progress), February 2018. 632 [I-D.zhou-netconf-multi-stream-originators] 633 Zhou, T., Zheng, G., Voit, E., Clemm, A., and A. Bierman, 634 "Subscription to Multiple Stream Originators", draft-zhou- 635 netconf-multi-stream-originators-01 (work in progress), 636 November 2017. 638 10.3. URIs 640 [1] https://developers.google.com/protocol-buffers/ 642 Appendix A. Change Log 644 (To be removed by RFC editor prior to publication) 646 A.1. draft-ietf-zheng-udp-pub-channel-00 to v00 648 o Modified the message header format. 650 o Added a section on the Authentication Option. 652 o Cleaned up the text and removed unnecessary TBDs. 654 A.2. v01 655 o Removed the detailed description on distributed data collection 656 mechanism from this document. Mainly focused on the description 657 of a UDP based publication channel for telemetry use. 659 o Modified the message header format. 661 A.2. v02 663 o Add the section on the transport mechanism. 665 o Modified the fixed message header format. 667 o Add the fragmentation option for the message header. 669 Authors' Addresses 671 Guangying Zheng 672 Huawei 673 101 Yu-Hua-Tai Software Road 674 Nanjing, Jiangsu 675 China 677 Email: zhengguangying@huawei.com 679 Tianran Zhou 680 Huawei 681 156 Beiqing Rd., Haidian District 682 Beijing 683 China 685 Email: zhoutianran@huawei.com 687 Alexander Clemm 688 Huawei 689 2330 Central Expressway 690 Santa Clara, California 691 USA 693 Email: alexander.clemm@huawei.com