idnits 2.17.1 draft-ietf-netconf-udp-pub-channel-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 11, 2017) is 2357 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 467 -- Looks like a reference, but probably isn't: '2' on line 376 -- Looks like a reference, but probably isn't: '3' on line 374 -- Looks like a reference, but probably isn't: '6' on line 374 -- Looks like a reference, but probably isn't: '7' on line 376 -- Looks like a reference, but probably isn't: '4' on line 376 -- Looks like a reference, but probably isn't: '5' on line 376 -- Looks like a reference, but probably isn't: '8' on line 376 -- Looks like a reference, but probably isn't: '9' on line 372 -- Looks like a reference, but probably isn't: '0' on line 376 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-08) exists of draft-ietf-netconf-notification-messages-02 == Outdated reference: A later version (-26) exists of draft-ietf-netconf-subscribed-notifications-07 == Outdated reference: A later version (-25) exists of draft-ietf-netconf-yang-push-11 == Outdated reference: A later version (-10) exists of draft-zhou-netconf-multi-stream-originators-00 Summary: 1 error (**), 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: May 15, 2018 Huawei 6 November 11, 2017 8 UDP based Publication Channel for Streaming Telemetry 9 draft-ietf-netconf-udp-pub-channel-01 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 May 15, 2018. 43 Copyright Notice 45 Copyright (c) 2017 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. UDP Transport for Publication Channel . . . . . . . . . . . . 5 64 4.1. Design Overview . . . . . . . . . . . . . . . . . . . . . 5 65 4.2. Data Format of the Message Header . . . . . . . . . . . . 6 66 4.3. Options . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.3.1. Reliability Option . . . . . . . . . . . . . . . . . 8 68 4.4. Data Encoding . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Congestion Control . . . . . . . . . . . . . . . . . . . . . 9 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 75 9.2. Informative References . . . . . . . . . . . . . . . . . 10 76 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Streaming telemetry refers to sending a continuous stream of 83 operational data from a device to a remote receiver. This provides 84 an ability to monitor a network from remote and to provide network 85 analytics. Devices generate telemetry data and push that data to a 86 collector for further analysis. By streaming the data, much better 87 performance, finer-grained sampling, monitoring accuracy, and 88 bandwidth utilization can be achieved than with polling-based 89 alternatives. 91 Sub-Notif [I-D.ietf-netconf-subscribed-notifications] and YANG-Push 92 [I-D.ietf-netconf-yang-push] defines a mechanism that allows a 93 collector to subscribe to updates of YANG-defined data that is 94 maintained in a YANG [RFC7950] datastore. The mechanism separates 95 the management and control of subscriptions from the transport that 96 is used to actually stream and deliver the data. Two transports have 97 been defined so far, NETCONF [RFC6241] and RESTCONF [RFC8040]. 99 While powerful in its features and general in its architecture, in 100 its current form the mechanism needs to be extended to stream 101 telemetry data at high velocity from devices that feature a 102 distributed architecture. The transports that have been defined so 103 far, NETCONF and RESTCONF, are ultimately based on TCP (Transmission 104 Control Protocol) and lack the efficiency needed to stream data 105 continuously at high velocity. A lighter-weight, more efficient 106 transport, e.g. a transport based on UDP (User Datagram Protocol) is 107 needed. 109 o Firstly, data collector will suffer a lot of TCP connections from, 110 for example, many line cards equipped on different devices. 112 o Secondly, as no connection state needs to be maintained, UDP 113 encapsulation can be easily implemented by hardware which will 114 further improve the performance. 116 o Thirdly, because of the lightweight UDP encapsulation, higher 117 frequency and better transit performance can be achieved, which is 118 important for streaming telemetry. 120 This document specifies a higher-performance transport option for 121 YANG-Push that leverages UDP. Specifically, it facilitates the 122 distributed data collection mechanism described in 123 [I-D.zhou-netconf-multi-stream-originators]. In the case of data 124 originating from multiple line cards, the design requires data to be 125 internally forwarded from those line cards to the push server, 126 presumably on a main board, which then combines the individual data 127 items into a single consolidated stream. The centralized data 128 collection mechanism can result in a performance bottleneck, 129 especially when large amounts of data are involved. What is needed 130 instead is the support for a distributed mechanism that allows to 131 directly push multiple individual substreams, e.g. one from each line 132 card, without needing to first pass them through an additional 133 processing stage for internal consolidation, but still allowing those 134 substreams to be managed and controlled via a single subscription. 135 The proposed UDP publication channel natively supports the 136 distributed data collection mechanism. 138 While this document will focus on the data publication channel, the 139 subscription can be used in conjunction with the mechanism proposed 140 in [I-D.ietf-netconf-yang-push] with necessary extensions 141 [I-D.zhou-netconf-multi-stream-originators]. 143 2. Terminology 145 Streaming telemetry: refers to sending a continuous stream of 146 operational data from a device to a remote receiver. This provides 147 an ability to monitor a network from remote and to provide network 148 analytics. 150 3. Solution Overview 152 The typical distributed data collection solution is shown in Fig. 1. 153 The Subscriber cannot see the Agents directly, so it will send the 154 Global Subscription information to the Master (e.g., main board). 155 When receiving a Global Subscription, the Subscription Server 156 decomposes the subscription request into multiple Component 157 Subscriptions, each involving data from a separate internal telemetry 158 source, for example a line card. The Component Subscriptions are 159 distributed to the Component Subscription Server located in Agents. 160 Subsequently, each Agent generates its own stream of telemetry data, 161 collecting and encapsulating the packets per the Component 162 Subscription and streaming them to the designated Collector.This 163 distributed data collection mechanism may form multiple Publication 164 Channels between the data originators and the Collector. The 165 Collector is able to assemble many pieces of data associated with one 166 Global Subscription. 168 The Publication Channel supports the reliable data streaming, for 169 example for some alarm events. The Collector has the option of 170 deducing the packet loss and the disorder based on the information 171 carried by the notification data. And the Collector will decide the 172 behavior to request retransmission. The Collector can send the 173 retransmission request to the subscriber server for further 174 processing. 176 The rest of the draft describes the UDP based publication channel. 178 retransmission + + Global 179 request | | Subscription 180 +------------------------+ 181 | | | Master | 182 | +--v----v--------+ | 183 | | Subscription | | 184 | | Server | | 185 | +--+----+-----+--+ | 186 | | | | | internal 187 Component +------------------------+ subscription 188 Subscription | | | distribution 189 +---------------+ | +--------------+ 190 | | | 191 +------------------+ +------------------+ +------------------+ 192 | | | | | | | | | 193 | +-------v------+ | | +------v-------+ | | +-----v--------+ | 194 | | Component | | | | Component | | | | Component | | 195 | | Subscription | | | | Subscription | | | | Subscription | | 196 | | Server | | | | Server | | | | Server | | 197 | +--------------+ | | +--------------+ | | +--------------+ | 198 | Agent 1 | | Agent 2 | | Agent n | 199 +---------+--------+ +--------+---------+ +----------+-------+ 200 | | | 201 | | Publication Channel | 202 +--------------+ | +-----------------+ 203 | | | 204 +-v-----v-----v-+ 205 | | 206 | Collector | 207 | | 208 +---------------+ 210 Fig. 1 Distributed Data Collection 212 4. UDP Transport for Publication Channel 214 4.1. Design Overview 216 As specified in YANG-Push, the telemetry data is encapsulated in the 217 NETCONF/RESTCONF notification message, which is then encapsulated and 218 carried in the transport protocols, e.g. TLS, HTTP2. The following 219 figure shows the overview of the UDP publication message structure. 221 o Next to the UDP encapsulation, the DTLS layer is to provide 222 reusable security and authentication functions over UDP. 224 o The Message Header contains information that can facilitate the 225 message transmission before de-serializing the notification 226 message. 228 o Notification Message is the encoded content that the publication 229 channel transports. The common encoding method includes GPB [1], 230 CBOR [RFC7049], JSON, and XML. 231 [I-D.ietf-netconf-notification-messages] describes the structure 232 of the Notification Message for both single notification and 233 multiple bundled notifications. 235 +--------------+ 236 | Notification | 237 | Message | 238 +--------------+ 240 +--------------+ 241 | Message | 242 | Header | 243 +--------------+ 245 +--------------+ 246 | DTLS | 247 +--------------+ 249 +--------------+ 250 | UDP | 251 +--------------+ 253 Fig. 2 UDP Publication Message Overview 255 4.2. Data Format of the Message Header 257 The Message Header contains information that can facilitate the 258 message transmission before de-serializing the notification message. 259 The data format is shown as follows. 261 0 1 2 3 262 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 263 +-------+---------------+-------+-------------------------------+ 264 | Vers. | Flag | ET | Length | 265 +-------+---------------+-------+-------------------------------+ 266 | Notification-Time | 267 +---------------------------------------------------------------+ 268 | Message-Generator-ID | 269 +---------------------------------------------------------------+ 270 ~ Options ~ 271 +---------------------------------------------------------------+ 273 Fig. 3 Message Header Format 275 The Message Header contains the following field: 277 o Vers.: represents the PDU (Protocol Data Unit) encoding version. 278 The initial version value is 0. 280 o Flag: is a bitmap indicating what features this packet has and the 281 corresponding options attached. Each bit associates to one 282 feature and one option data. When the bit is set to 1, the 283 associated feature is enabled and the option data is attached. 284 The sequence of the presence of the options follows the bit order 285 of the bitmap. In this document, the flag is specified as 286 follows: 288 * bit 0, the reliability flag; 290 * other bits are reserved. 292 o ET: is a 4 bits identifier to indicate the encoding type used for 293 the Notification Message. 16 types of encoding can be expressed: 295 * 0: GPB; 297 * 1: CBOR; 299 * 2: JSON; 301 * 3: XML; 303 * others are reserved. 305 o Length: is the total length of the message, measured in octets, 306 including message header. 308 o Message-Generator-ID: is a 32-bit identifier of the process which 309 created the message notification. This allows disambiguation of 310 an information source, such as the identification of different 311 line cards sending the notification messages. 313 o Notification-Time: is the time at which the message leaves the 314 exporter, expressed in seconds since the UNIX epoch of 1 January 315 1970 at 00:00 UTC, encoded as an unsigned 32-bit integer. 317 o Options: is a variable-length field. The details of the Options 318 will be described in the respective sections below. 320 4.3. Options 322 The order of packing the data fields in the Options field follows the 323 bit order of the Flag field. 325 4.3.1. Reliability Option 327 The UDP based publication transport described in this document 328 provides two streaming modes, the reliable mode an the unreliable 329 mode, for different SLA (Service Level Agreement) and telemetry 330 requirements. 332 In the unreliable streaming mode, the line card pushes the 333 encapsulated data to the data collector without any sequence 334 information. So the subscriber does not know whether the data is 335 correctly received or not. Hence no retransmission happens. 337 The reliable streaming mode provides sequence information in the UDP 338 packet, based on which the subscriber can deduce the packet loss and 339 disorder. Then the subscriber can decide whether to request the 340 retransmission of the lost packets. 342 In most case, the unreliable streaming mode is preferred. Because 343 the reliable streaming mode will cost more network bandwidth and 344 precious device resource. Different from the unreliable streaming 345 mode, the line card cannot remove the sent reliable notifications 346 immediately, but to keep them in the memory for a while. Reliable 347 notifications may be pushed multiple times, which will increase the 348 traffic. When choosing the reliable streaming mode or the unreliable 349 streaming mode, the operate need to consider the reliable requirement 350 together with the resource usage. 352 When the reliability flag bit is set to 1 in the Flag field, the 353 following option data will be attached 354 0 1 2 3 355 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 356 +---------------------------------------------------------------+ 357 | Notification ID | 358 +---------------------------------------------------------------+ 359 | Previous Notification ID | 360 +---------------------------------------------------------------+ 362 Fig. 4 Reliability Option Format 364 The notification ID is generated continuously by the message 365 generator. Different subscribers share the same notification ID 366 sequence. Current ID and previous ID will be added in the packets. 368 For example, there are two subscriber A and B, 370 o Notification IDs for the generator are : [1, 2, 3, 4, 5, 6, 7, 8, 371 9], in which Subscriber A subscribes [1,2,3,6,7] and Subscriber B 372 subscribes [1,2,4,5,7,8,9]. 374 o Subscriber A will receive : [0,1][1,2][2,3][3,6][6,7]. 376 o Subscriber B will receive : [0,1][1,2][2,4][4,5][5,7][7,8]. 378 4.4. Data Encoding 380 Subscribed data can be encoded in GPB, CBOR, XML or JSON format. It 381 is conceivable that additional encodings may be supported as options 382 in the future. This can be accomplished by augmenting the 383 subscription data model with additional identity statements used to 384 refer to requested encodings. 386 Implementation may support different encoding method per 387 subscription. When bundled notifications is supported between the 388 publisher and the receiver, only subscribed notifications with the 389 same encoding can be bundled as one message. 391 5. Congestion Control 393 While efficient, UDP has no build-in congestion control mechanism. 394 It is not recommended to use the UDP based publication channel over 395 congestion-sensitive network paths. The deployments require the 396 communications from exporters to collectors are always congestion 397 controllable, i.e., the transport is over dedicated links or the 398 streaming rate can be limited. 400 6. IANA Considerations 402 TBD 404 7. Security Considerations 406 TBD 408 8. Acknowledgements 410 The authors of this documents would like to thank Eric Voit, Tim 411 Jenkins, and Huiyang Yang for the initial comments. 413 9. References 415 9.1. Normative References 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, 419 DOI 10.17487/RFC2119, March 1997, 420 . 422 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 423 and A. Bierman, Ed., "Network Configuration Protocol 424 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 425 . 427 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 428 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 429 October 2013, . 431 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 432 RFC 7950, DOI 10.17487/RFC7950, August 2016, 433 . 435 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 436 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 437 . 439 9.2. Informative References 441 [I-D.ietf-netconf-notification-messages] 442 Voit, E., Bierman, A., Clemm, A., and T. Jenkins, 443 "Notification Message Headers and Bundles", draft-ietf- 444 netconf-notification-messages-02 (work in progress), 445 October 2017. 447 [I-D.ietf-netconf-subscribed-notifications] 448 Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and 449 A. Tripathy, "Custom Subscription to Event Streams", 450 draft-ietf-netconf-subscribed-notifications-07 (work in 451 progress), October 2017. 453 [I-D.ietf-netconf-yang-push] 454 Clemm, A., Voit, E., Prieto, A., Tripathy, A., Nilsen- 455 Nygaard, E., Bierman, A., and B. Lengyel, "YANG Datastore 456 Subscription", draft-ietf-netconf-yang-push-11 (work in 457 progress), October 2017. 459 [I-D.zhou-netconf-multi-stream-originators] 460 Zhou, T., Zheng, G., Voit, E., Clemm, A., and A. Bierman, 461 "Subscription to Multiple Stream Originators", draft-zhou- 462 netconf-multi-stream-originators-00 (work in progress), 463 October 2017. 465 9.3. URIs 467 [1] https://developers.google.com/protocol-buffers/ 469 Appendix A. Change Log 471 (To be removed by RFC editor prior to publication) 473 A.1. draft-ietf-zheng-udp-pub-channel-00 to v00 475 o Modified the telemetry header format. 477 o Add a section on the Authentication Option. 479 o Cleaned up the text and removed unnecessary TBDs. 481 A.2. v01 483 o Removed the detailed description on distributed data collection 484 mechanism from this document. Mainly focused on the description 485 of a UDP based publication channel for telemetry use. 487 o Modified the telemetry header format. 489 Authors' Addresses 490 Guangying Zheng 491 Huawei 492 101 Yu-Hua-Tai Software Road 493 Nanjing, Jiangsu 494 China 496 Email: zhengguangying@huawei.com 498 Tianran Zhou 499 Huawei 500 156 Beiqing Rd., Haidian District 501 Beijing 502 China 504 Email: zhoutianran@huawei.com 506 Alexander Clemm 507 Huawei 508 2330 Central Expressway 509 Santa Clara, California 510 USA 512 Email: alexander.clemm@huawei.com