idnits 2.17.1 draft-ryan-cdni-capacity-insights-extensions-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8008, but the abstract doesn't seem to directly say this. It does mention RFC8008 though, so this could be OK. -- The draft header indicates that this document updates RFC8006, but the abstract doesn't seem to directly say this. It does mention RFC8006 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 5, 2021) is 1020 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Ryan 3 Internet-Draft Limelight Networks 4 Updates: 8006,8008 (if approved) B. Rosenblum 5 Intended status: Standards Track Vecima 6 Expires: January 6, 2022 N. Sopher 7 Qwilt 8 July 5, 2021 10 CDNI Capacity Insights Capability Advertisment Extensions 11 draft-ryan-cdni-capacity-insights-extensions-00 13 Abstract 15 Open Caching architecture is a use case of Content Delivery Networks 16 Interconnection (CDNI) in which the commercial Content Delivery 17 Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer 18 serves as the downstream CDN (dCDN). This document supplements to 19 the CDNI Capability Objects defined in RFC 8008 and CDNI Metadata 20 Objects in RFC 8006. The defined Capability Objects structure and 21 interface for advertisments and managment of a downstream CDN 22 capacity. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 6, 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 61 2. CDNI Additonal Capability Objects . . . . . . . . . . . . . . 4 62 2.1. Telemetry Capability Object . . . . . . . . . . . . . . . 4 63 2.1.1. Telemetry Source Object . . . . . . . . . . . . . . . 4 64 2.1.1.1. Telemetry Source Types . . . . . . . . . . . . . 5 65 2.1.1.2. Telemetry Source Metric Object . . . . . . . . . 5 66 2.1.2. Telemetry Capability Object Serialization . . . . . . 6 67 2.2. CapacityLimits Capability Object . . . . . . . . . . . . 7 68 2.2.1. Capacity Limit Object . . . . . . . . . . . . . . . . 8 69 2.2.1.1. Capacity Limit Types . . . . . . . . . . . . . . 9 70 2.2.1.2. Capacity Limit Telemetry Source Object . . . . . 9 71 2.2.2. Capacity Limit Object Serialization . . . . . . . . . 10 72 2.3. RequestedCapacityLimits Object . . . . . . . . . . . . . 11 73 2.3.1. Requsted Limits Object . . . . . . . . . . . . . . . 11 74 2.3.2. Telemetry Capability Object Serialization . . . . . . 12 75 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 3.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 13 77 3.1.1. CDNI FCI Telemetry Payload Type . . . . . . . . . . . 14 78 3.1.2. CDNI FCI Capacity Limits Payload Type . . . . . . . . 14 79 3.1.3. CDNI MI Requested Capacity Limits Payload Type . . . 14 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 84 6.2. Informative References . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 The Streaming Video Alliance [SVA] is a global association that works 90 to solve streaming video challenges in an effort to improve end-user 91 experience and adoption. The Open Caching Working Group [OCWG] of 92 the Streaming Video Alliance [SVA] is focused on the delegation of 93 video delivery requests from commerical CDNs to a caching layer at 94 the ISP's network. Open Caching architecture is a specific use case 95 of CDNI where the commercial CDN is the upstream CDN (uCDN) and the 96 ISP caching layer is the downstream CDN (dCDN). While delegating 97 traffic from one CDN to the other, it is important to make sure that 98 an appropriate amount of traffic is delegated. In order to achives 99 that, the TBD: Open Caching Capacity Insight Specification [OC-CII] 100 defines a feedback mechanism to inform the delegator how much traffic 101 is appropriate to delegate. The traffic level information provided 102 by that interface will be consumed by entities, such as the Open 103 Caching Request router, to help inform that entity's traffic 104 delegation decisions. This document defines and registers CDNI 105 Payload Types (as defined at section 7.1 of [RFC8006]). These 106 Payload types are used for Capability Objects added to those defined 107 at section 4 of [RFC8008], which are required for the Open Caching 108 Capacity Insights Interface. 110 For consistency with other CDNI documents this document follows the 111 CDNI convention of uCDN (upstream CDN) and dCDN (downstream CDN) to 112 represent the commercial CDN and ISP caching layer respectively. 114 This document registers two CDNI Payload Types (section 7.1 of 115 [RFC8006]) for the defined capability objects: 117 o Telemetry Payload Type: A payload type for the capability object 118 which defines the supported telemetry sources, the metrics made 119 available by that source, and corresponding configuration 120 appropriate to the type of the source (host, port, protocol, 121 etc..) 123 o CapacityLimits Payload Type: a payload type for the capability 124 object which defines Capacity Limits based on a set of defined 125 limit types and a mapping from those limits to corresponding 126 telemetry sources for supporting real-time metrics. 128 1.1. Terminology 130 The following terms are used throughout this document: 132 o CDN - Content Delivery Network 134 Additionally, this document reuses the terminology defined in 135 [RFC6707], [RFC7336], [RFC8006], [RFC8007], [RFC8008], and [RFC8804]. 136 Specifically, we use the following CDNI acronyms: 138 o uCDN, dCDN - Upstream CDN and Downstream CDN respectively (see 139 [RFC7336] ) 141 1.2. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 2. CDNI Additonal Capability Objects 151 Section 5 of [RFC8008] describes the FCI Capability Advertisement 152 Object, which contains a CDNI Capability Object as well as the 153 capability object type (a CDNI Paylod Type). The section also 154 defines the Capability Objects per such type. Below we define two 155 additional Capability Objects. 157 Note: In the following sections, the term "mandatory-to-specify" is 158 used to convey which properties MUST be included when serializing a 159 given capability object. When mandatory-to-specify is defined as 160 "Yes" for an individual property, it means that if the object 161 containing that property is included in an FCI message, then the 162 mandatory-to-specify property MUST also be included. 164 2.1. Telemetry Capability Object 166 The Telemetry Capability Object is used to define a list of telemetry 167 sources made available by the dCDN to the uCDN. 169 Property: sources 171 Description: Telemetry sources made available to the uCDN. 173 Type: A JSON array of Telemetry Source objects (see 174 Section 2.1.1). 176 Mandatory-to-Specify: Yes. 178 2.1.1. Telemetry Source Object 180 The Telemetry Source Object is build of an associated type, a list of 181 exposed metrics, and type-specific configuration data. 183 Property: id 185 Description: A unique identifier. 187 Type: String. 189 Mandatory-to-Specify: Yes. 191 Property: type 193 Description: A valid telemetry source type. See 194 Section 2.1.1.1. 196 Type: String. 198 Mandatory-to-Specify: Yes. 200 Property: metrics 202 Description: The metrics exposed by this source. 204 Type: A JSON array of Telemetry Source Metric objects (see 205 Section 2.1.1.2). 207 Mandatory-to-Specify: Yes. 209 Property: configuration 211 Description: Type specific configuration data. 213 Type: TBD. 215 Mandatory-to-Specify: No. 217 2.1.1.1. Telemetry Source Types 219 Below are listed the valid telemetry source types. TBD: How do we 220 extend this list? Do we need a registry? 222 +---------------------------------+---------------------------------+ 223 | Source Type | Description | 224 +---------------------------------+---------------------------------+ 225 | generic | TBD | 226 +---------------------------------+---------------------------------+ 228 2.1.1.2. Telemetry Source Metric Object 230 The Telemetry Source Metric Object describe the metric to be exposed. 232 Property: name 234 Description: An identifier unique within this telemetry source. 236 Type: String. 238 Mandatory-to-Specify: Yes. 240 Property: time-granularity 242 Description: Represents the time frame that the data represents 243 in seconds. I.e. is this a data set over 5 minutes, one hour, 244 etc.. 246 Type: Float (or Integer - TBD). 248 Mandatory-to-Specify: No. 250 Property: data-percentile 252 Description: The percentile calculation the data represents, 253 i.e. 50 percentile would equate to the average over the time- 254 granularity. 256 Type: Float (or Integer - TBD). 258 Mandatory-to-Specify: No. 260 Property: latency 262 Description: Time in second that the data is behind of real 263 time. 265 Type: Float (or Integer - TBD). 267 Mandatory-to-Specify: No. 269 2.1.2. Telemetry Capability Object Serialization 271 The following shows an example of Telemetry Capability including 2 272 sources. 274 "capabilities": [ 275 { 276 "capability-type": "FCI.Telemetry", 277 "capability-value": { 278 "sources": [ 279 { 280 "id": "capacity_metrics_region1", 281 "type": "generic", 282 "metrics": [ 283 { 284 "name": "egress_5m", 285 "time-granularity": 300, 286 "data-percentile": 50, 287 "latency": 1500 288 }, 289 { 290 "name": "requests_5m", 291 } 292 ] 293 } 294 ] 295 }, 296 "footprints": [ 297 298 ] 299 } 300 ] 302 2.2. CapacityLimits Capability Object 304 The Capacity Limits Capability Object represents the limits to be 305 advertised based on a particular Telemetry element.. 307 Property: total-limits-host 309 Description:The "Distinguished CDN-Domain" used for adjustment 310 of the total limits. 312 Type: String. 314 Mandatory-to-Specify: No. Required only if 315 MI.RequestedCapacityLimits is supported. 317 Property: total-limits 319 Description: The top level limits for the footprint. 321 Type: A JSON array of Capacity Limit objects (see 322 Section 2.2.1). 324 Mandatory-to-Specify: Yes. 326 Property: host-limits 328 Description: Limits for particular CDN Domains. 330 Type: A JSON array of Capcity Limit objects (see 331 Section 2.2.1). 333 Mandatory-to-Specify: No. 335 2.2.1. Capacity Limit Object 337 The Capacity Limit Object is built of TBD. 339 Property: limit-type 341 Description: The units of maximum-hard and maximum-soft. 343 Type: String. One of the values listed in Section 2.2.1.1. 345 Mandatory-to-Specify: Yes. 347 Property: maximum-hard 349 Description: The maximum unit of capacity that is available for 350 use. 352 Type: Float (or Integer - TBD). 354 Mandatory-to-Specify: Yes. 356 Property: maximum-soft 358 Description: A soft limit at which an upstream should consider 359 deducing traffic to prevent hitting the hard limit. 361 Type: Float (or Integer - TBD). 363 Mandatory-to-Specify: No. 365 Property: telemetry-source 366 Description: Mapping of each a particular limit to a specific 367 metric with relevant real-time data provided by a telemetry 368 source. 370 Type: Capcity Limit Telemetry Source object (see 371 Section 2.2.1.2). 373 Mandatory-to-Specify: No. 375 Property: host 377 Description: The CDN Domain to which the limit applies. 379 Type: String. 381 Mandatory-to-Specify: Only when is part of the host-limits 382 list. 384 2.2.1.1. Capacity Limit Types 386 Below are listed the valid capacity limit types. TBD: How do we 387 extend this list? Do we need a registry? Maybe omit this list and 388 make it subject ot bootstrapping? 390 +----------------------------------+--------------------------------+ 391 | Limit Type | Units | 392 +----------------------------------+--------------------------------+ 393 | egress | Bits per second | 394 | requests | Requests per second | 395 | storage-size | Total bytes | 396 | storage-objects | Count | 397 | sessions | Count | 398 | cache-size | Total bytes | 399 +----------------------------------+--------------------------------+ 401 2.2.1.2. Capacity Limit Telemetry Source Object 403 The Capacity Limit Telemetry Source Object refers to a specific 404 metric within a Telementry Source. 406 Property: id 408 Description: Reference to the "id" of a telemetry source 409 defined by a Telemetry Capability object. 411 Type: String. 413 Mandatory-to-Specify: Yes. 415 Property: metric 417 Description: Reference to the "name" property of a metric as 418 defined for the referenced telemetry source. 420 Type: String. 422 Mandatory-to-Specify: Yes. 424 2.2.2. Capacity Limit Object Serialization 426 The following shows an example of ... TBD. 428 "capabilities": [ 429 { 430 "capability-type": "FCI.CapacityLimits" 431 "capability-value": { 432 "total-limits-host": "op-b.op-a.com", 433 "total-limits": [ 434 { 435 "limit-type": "egress", 436 "maximum-hard": 50000000000, 437 "maximum-soft": 25000000000, 438 "telemetry-source": { 439 "id": "capacity_metrics_region1", 440 "metric": "egress_5m" 441 } 442 } 443 ], 444 "host-limits": [ 445 { 446 "host": "serviceA.cdn.example.com", 447 "limits": [ 448 "limit-type": "egress", 449 "maximum-hard": 20000000000, 450 "maximum-soft": 10000000000, 451 "telemetry-source": { 452 "id": "capacity_metrics_region1", 453 "metric": "egress_service2_5m" 454 } 455 ] 456 }, 457 { 458 "host": "serviceB.cdn.example.com", 459 "limits": [ 460 "limit-type": "egress", 461 "maximum-hard": 30000000000, 462 "maximum-soft": 15000000000, 463 "telemetry-source": { 464 "id": "capacity_metrics_region1", 465 "metric": "egress_service2_5m" 466 } 467 ] 468 } 469 ] 470 }, 471 "footprints": [ 472 473 ] 474 } 475 ] 477 2.3. RequestedCapacityLimits Object 479 To enable the uCDN to request changes in the dCDN limits, a new 480 metadata object is introduced. As metadata is associated with a 481 host, the total limits for the uCDN on a particular footprint are 482 associated with the "Distinguished CDN-Domain" as defined by 483 [RFC7336]. This will typically be a host utilized in 484 FCI.RedirectTarget, though it can be any arbitrary host as long as it 485 is not one of the CDN-Domains used for serving client requests. This 486 host as used for requested changes in the total limits is defined in 487 the total-limits-host property of FCI.CapacityLimits. Similarly, an 488 adjustment request for any CDN-Domain may be made using the same 489 metadata object associated with the corresponding host. These 490 correspond to the limits defined as host-limits in 491 FCI.CapacityLimits. 493 Property: requested-limits 495 Description: Capacity Limits being requedted by the uCDN to the 496 dCDN. 498 Type: A JSON array of Requested Limits objects (see 499 Section 2.3.1). 501 Mandatory-to-Specify: Yes. 503 2.3.1. Requsted Limits Object 505 The Requested Limit Object is build of an associated type, a value 506 assocaited with the type, and the footprints that the limit should be 507 associated with. 509 Property: limit-type 511 Description: A limit type as defined in Section 2.2.1.1. 513 Type: String. 515 Mandatory-to-Specify: Yes. 517 Property: limit-value 519 Description: A unit of capacity defined in the maximum-hard 520 property of Section 2.2.1. 522 Type: Float (or Integer - TBD). 524 Mandatory-to-Specify: Yes. 526 Property: footprints 528 Description: The CDNI Footprint objects this requested limit 529 are associated with. 531 Type: A JSON array of CDNI Footprints (see [RFC8006]). 533 Mandatory-to-Specify: Yes. 535 2.3.2. Telemetry Capability Object Serialization 537 The following shows an example of MI.RequestedCapacityLimits object. 539 { 540 "host": "op-b.op-a.com", 541 "host-metadata": { 542 "metadata": [ 543 ..., 544 { 545 "generic-metadata-type": "MI.RequestedCapacityLimits", 546 "generic-metadata-value": { 547 "requested-limits": [ 548 { 549 "limit-type": "egress", 550 "limit-value": 80000000000, 551 "footprints": [{ 552 "footprint-type": "ipv4cidr", 553 "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"] 554 }] 555 }, 556 { 557 ... 558 } 559 ] 560 } 561 } 562 ] 563 } 564 } 566 3. IANA Considerations 568 3.1. CDNI Payload Types 570 As described in section 7.1 of [RFC8006] , the "CDNI Payload Types" 571 subregistry was created within the "Content Delivery Network 572 Interconnection (CDNI) Parameters" registry (TBD verify name or omit 573 extra info). The created namespace defines the valid Payload Types, 574 and is already populated with the types described in Section 7.1 of 575 [RFC8006] as well as the types described in section 6.1 of [RFC8008]. 577 This document requests the registration of the two additional payload 578 types: 580 +---------------------------------+---------------------------------+ 581 | Payload Type | Specification | 582 +---------------------------------+---------------------------------+ 583 | FCI.Telemetry | RFCthis | 584 | FCI.CapacityLimits | RFCthis | 585 | MI.RequestedCapacityLimits | RFCthis | 586 +---------------------------------+---------------------------------+ 588 [RFC Editor: Please replace RFCthis with the published RFC number for 589 this document.] 591 3.1.1. CDNI FCI Telemetry Payload Type 593 Purpose: The purpose of this Payload Type is TBD (maybe: to list 594 the supported telemetry sources and the metrics made available by 595 each source). 597 Interface: FCI. 599 Encoding: See section Section 2.1. 601 3.1.2. CDNI FCI Capacity Limits Payload Type 603 Purpose: The purpose of this Payload Type is TBD (maybe: defines 604 Capacity Limits based on a set of defined limit types and a 605 mapping from those limits to corresponding telemetry sources for 606 supporting real-time metrics). 608 Interface: FCI. 610 Encoding: See section Section 2.2. 612 3.1.3. CDNI MI Requested Capacity Limits Payload Type 614 Purpose: The purpose of this Payload Type is to allow a uCDN to 615 request a CapacityLimit update from a dCDN 617 Interface: MI. 619 Encoding: See section Section 2.3. 621 4. Security Considerations 623 This specification is in accordance with the CDNI Request Routing: 624 Footprint and Capabilities Semantics. As such, it is subject to the 625 security and privacy considerations as defined in Section 8 of 626 [RFC8006] and in Section 7 of [RFC8008] respectively. 628 MORE - TBD 630 5. Acknowledgements 632 The authors would like to express their gratitude to TBD for TBD 633 (their guidance / contribution / reviews ...) 635 6. References 637 6.1. Normative References 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, 641 DOI 10.17487/RFC2119, March 1997, 642 . 644 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 645 "Content Delivery Network Interconnection (CDNI) 646 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 647 . 649 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 650 Interconnection (CDNI) Control Interface / Triggers", 651 RFC 8007, DOI 10.17487/RFC8007, December 2016, 652 . 654 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 655 R., and K. Ma, "Content Delivery Network Interconnection 656 (CDNI) Request Routing: Footprint and Capabilities 657 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 658 . 660 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 661 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 662 May 2017, . 664 [RFC8804] Finkelman, O. and S. Mishra, "Content Delivery Network 665 Interconnection (CDNI) Request Routing Extensions", 666 RFC 8804, DOI 10.17487/RFC8804, September 2020, 667 . 669 6.2. Informative References 671 [OC-CII] Finkelman, O., Ed., Hofmann, J., Klein, E., Mishra, S., 672 Ma, K., Sahar, D., and B. Zurat, "Open Caching - Capacity 673 Insights Interface Functional Specification (TBD: write it 674 and fix the reference)", Version 1.1, October 2019, 675 . 678 [OCWG] "Open Caching Home Page", 679 . 682 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 683 Distribution Network Interconnection (CDNI) Problem 684 Statement", RFC 6707, DOI 10.17487/RFC6707, September 685 2012, . 687 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 688 "Framework for Content Distribution Network 689 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 690 August 2014, . 692 [SVA] "Streaming Video Alliance Home Page", 693 . 695 Authors' Addresses 697 Andrew Ryan 698 Limelight Networks 700 5177 Brandin Ct. 702 Fremont 703 , 704 CA 706 94538 708 US 710 Email: 711 andrew@andrewnryan.com 713 Ben Rosenblum 714 Vecima 716 4375 River Green Pkwy #100 718 Duluth 719 , 720 GA 722 30096 724 US 726 Email: 727 ben@rosenblum.dev 729 Nir B. Sopher 730 Qwilt 732 6, Ha'harash 734 Hod HaSharon 735 , 737 4524079 739 Israel 741 Email: 742 nir@apache.org