idnits 2.17.1 draft-ryan-cdni-capacity-insights-extensions-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 : ---------------------------------------------------------------------------- -- 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 (22 October 2021) is 888 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: 25 April 2022 N. Sopher 7 Qwilt 8 22 October 2021 10 CDNI Capacity Insights Capability Advertisment Extensions 11 draft-ryan-cdni-capacity-insights-extensions-01 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 25 April 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 (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 1.3. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. CDNI Additonal Capability Objects . . . . . . . . . . . . . . 5 62 2.1. Telemetry Capability Object . . . . . . . . . . . . . . . 5 63 2.1.1. Telemetry Source Object . . . . . . . . . . . . . . . 6 64 2.1.1.1. Telemetry Source Types . . . . . . . . . . . . . 7 65 2.1.1.2. Telemetry Source Metric Object . . . . . . . . . 7 66 2.1.2. Telemetry Capability Object Serialization . . . . . . 8 67 2.2. CapacityLimits Capability Object . . . . . . . . . . . . 9 68 2.2.1. Capacity Limit Object . . . . . . . . . . . . . . . . 10 69 2.2.1.1. Capacity Limit Types . . . . . . . . . . . . . . 11 70 2.2.1.2. Capacity Limit Telemetry Source Object . . . . . 11 71 2.2.2. Capacity Limit Object Serialization . . . . . . . . . 12 72 2.3. RequestedCapacityLimits Object . . . . . . . . . . . . . 13 73 2.3.1. Requsted Limits Object . . . . . . . . . . . . . . . 14 74 2.3.2. Telemetry Capability Object Serialization . . . . . . 14 75 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 3.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 15 77 3.1.1. CDNI FCI Telemetry Payload Type . . . . . . . . . . . 16 78 3.1.2. CDNI FCI Capacity Limits Payload Type . . . . . . . . 16 79 3.1.3. CDNI MI Requested Capacity Limits Payload Type . . . 16 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 82 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 84 6.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 achive 99 that, the SVA 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 [OC-RR], 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 [OC-CII]. 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 * 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 * 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 and describes usage of a CDNI Generic Metadata object: 130 * MI.RequestedCapacityLimits: A generic CDNI Metadata object which 131 allows the uCDN to solicit the dCDN to reconsider Limits. This 132 object is being proposed as part of CDNI Metadata Model Extensions 133 [OC-MME] 135 1.1. Terminology 137 The following terms are used throughout this document: 139 * CDN - Content Delivery Network 141 Additionally, this document reuses the terminology defined in 142 [RFC6707], [RFC7336], [RFC8006], [RFC8007], [RFC8008], and [RFC8804]. 143 Specifically, we use the following CDNI acronyms: 145 * uCDN, dCDN - Upstream CDN and Downstream CDN respectively (see 146 [RFC7336] ) 148 1.2. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 1.3. Objectives 158 In order to enable information exchange between a uCDN and a dCDN 159 about acceptable levels of traffic to delegate, a design has been 160 developed as follows: 162 In normal operation a uCDN will communicate with a dCDN, via an 163 interface, to collect and understand any limits that a dCDN has set 164 forth for traffic delegation from a uCDN. These limits will come in 165 the form of metrics such as bits per second, requests per second, 166 etc.. These limits can be thought of as Not to Exceed (NTE) limits. 168 The dCDN should provide access to a telemetry source of near real 169 time metrics that the uCDN can use to track current usage and compare 170 that to the limits the dCDN has put forth and adjust traffic 171 delegation decisions accordingly to keep current usage under the 172 specified limits. In summary, the dCDN will inform the uCDN of 173 limits in how much traffic it should delegate towards the dCDN and 174 then provide a telemetry source that the uCDN can use to track its 175 current usage. This allows for a non ambiguous definition of what a 176 particular limit means and how to track usage against it. 178 Limits that are communicated from the dCDN to the uCDN should be 179 considered valid based on the TTL of the response. The intention is 180 that the limits would be long lived and would represent a reasonable 181 peak limit that the uCDN should target throughout the course of a 182 time period defined by the TTL. 184 In the event that a dCDN needs to inform a uCDN of an update to a 185 previously communicated limit, the dCDN will be able to leverage a 186 uCDN callback endpoint to inform the uCDN of adjusted limits. The 187 most common use case for this would be related to dCDN infrastructure 188 issues which reduced the amount of capacity available. 190 In the inverse of the above, if a uCDN would like to ask a dCDN to 191 reconsider a previously established limit, the uCDN can make a call 192 to the dCDN API interface with a proposed limit. The dCDN can 193 consider the requested limit and choose to send the uCDN an updated 194 limit if it meets the dCDN criteria. This is an asynchronous 195 process. When the uCDN sends the solicitation to the dCDN, the dCDN 196 will acknowledge receipt of the request, but will process the request 197 with no guarantee that it will trigger an update to any limits. 199 2. CDNI Additonal Capability Objects 201 Section 5 of [RFC8008] describes the FCI Capability Advertisement 202 Object, which contains a CDNI Capability Object as well as the 203 capability object type (a CDNI Paylod Type). The section also 204 defines the Capability Objects per such type. Below we define two 205 additional Capability Objects. 207 Note: In the following sections, the term "mandatory-to-specify" is 208 used to convey which properties MUST be included when serializing a 209 given capability object. When mandatory-to-specify is defined as 210 "Yes" for an individual property, it means that if the object 211 containing that property is included in an FCI message, then the 212 mandatory-to-specify property MUST also be included. 214 2.1. Telemetry Capability Object 216 The Telemetry Capability Object is used to define a list of telemetry 217 sources made available by the dCDN to the uCDN. Telemetry data is 218 being defined as near real time aggregated metics of dCDN 219 utilization, such as bits per second egress, and should be specific 220 to the uCDN and dCDN traffic delegation relationship. Telemetry data 221 is uniqiely defined by a source id, a metrics name, along with the 222 footprints that are associated with an FCI.Capability advertisement. 223 Telemetry data is an important component for CDNI delegation. The 224 reasons that Telemetry information is important to traffic delegation 225 is as follows: In situations where there are mutiple delegations, a 226 uCDN will need to incorporate usage information from it's dCDN in 227 such as manner as to allow higher level uCDNs to gain vislibility 228 into traffic that is being delegated to a dCDN. An example of this 229 is if a Content Provider delegates traffic directly to a CDN, and 230 that CDN decides to further delegate traffic to a dCDN, if the 231 Content Provider polls the uCDN for traffic usage, without the uCDN 232 integrating the Telemetry data of it's dCDN, any traffic the uCDN 233 delegated would become invisible to the Content Provider. When 234 defining a Capacity Limit, the meaning of a limit might be considered 235 ambiguous if the uCDN and dCDN are defining current usage via 236 different data sources. Having the dCDN provide a data source 237 defining usage that both itself and the uCDN reference, allows a non 238 ambiguous metric to use when determing current usage and how that 239 compares to a limit 240 Property: sources 242 Description: Telemetry sources made available to the uCDN. 244 Type: A JSON array of Telemetry Source objects (see 245 Section 2.1.1). 247 Mandatory-to-Specify: Yes. 249 2.1.1. Telemetry Source Object 251 The Telemetry Source Object is built of an associated type, a list of 252 exposed metrics, and type-specific configuration data. 254 Property: id 256 Description: A unique identifier of a telemetry source. 258 Type: String. 260 Mandatory-to-Specify: Yes. 262 Property: type 264 Description: A valid telemetry source type. See 265 Section 2.1.1.1. 267 Type: String. 269 Mandatory-to-Specify: Yes. 271 Property: metrics 273 Description: The metrics exposed by this source. 275 Type: A JSON array of Telemetry Source Metric objects (see 276 Section 2.1.1.2). 278 Mandatory-to-Specify: Yes. 280 Property: configuration 281 Description: a source-specific representation of the Telemetry 282 source configuration. For the generic source type, this 283 configuration format is defined out-of-band. For other types, 284 the configuration format will be specified in a yet to be 285 defined Telemetry Interface specification. The goal of this 286 element is to allow for forward compatability with a formal 287 Telemetry interface. 289 Type: A JSON object: TBD 291 Mandatory-to-Specify: No. 293 2.1.1.1. Telemetry Source Types 295 Below are the listed valid telemetry source types. At the time of 296 this draft, the type registry is limit to a single type of Generic. 297 The intention of this type registry is to allow for future extension 298 to reference a yet to be drafted specification for a CDNI Telemetry 299 interface, which would standardize the definition, format,etc of 300 Telemetry data between participants of a CDNI workflow. 302 +=============+======================================+ 303 | Source Type | Description | 304 +=============+======================================+ 305 | generic | An object which allows for | 306 | | advertisement of generic datasources | 307 +-------------+--------------------------------------+ 309 Table 1 311 2.1.1.2. Telemetry Source Metric Object 313 The Telemetry Source Metric Object describe the metric to be exposed. 315 Property: name 317 Description: An identifier unique within this telemetry source. 319 Type: String. 321 Mandatory-to-Specify: Yes. 323 Property: time-granularity 325 Description: Represents the time frame that the data represents 326 in seconds. I.e. is this a data set over 5 minutes, one hour, 327 etc.. 329 Type: Integer. 331 Mandatory-to-Specify: No. 333 Property: data-percentile 335 Description: The percentile calculation the data represents, 336 i.e. 50 percentile would equate to the median over the time- 337 granularity. Lack of a data-percentile will mean that the data 338 is the average over the time representation. 340 Type: Integer. 342 Mandatory-to-Specify: No. 344 Property: latency 346 Description: Time in seconds that the data is behind of real 347 time. This is important to specify to help the uCDN to 348 understand how long it might take to reflect traffic 349 adjustments in the metrics. 351 Type: Integer. 353 Mandatory-to-Specify: No. 355 2.1.2. Telemetry Capability Object Serialization 357 The following shows an example of Telemetry Capability including 2 358 metrics for a source, that is scoped to a footprint. 360 "capabilities": [ 361 { 362 "capability-type": "FCI.Telemetry", 363 "capability-value": { 364 "sources": [ 365 { 366 "id": "capacity_metrics_region1", 367 "type": "generic", 368 "metrics": [ 369 { 370 "name": "egress_5m", 371 "time-granularity": 300, 372 "data-percentile": 50, 373 "latency": 1500 374 }, 375 { 376 "name": "requests_5m", 377 ... 378 } 379 ] 380 } 381 ] 382 }, 383 "footprints": [ 384 385 ] 386 } 387 ] 389 2.2. CapacityLimits Capability Object 391 The Capacity Limits Capability Object enables the dCDN to specify 392 traffic delegation limits to a uCDN within an FCI.Capabilities 393 advertisement. The limits specified by the dCDN will inform the uCDN 394 on how much traffic can be delegated to the dCDN. The limits 395 specified by the dCDN should be considered Not To Exceed (NTE) 396 limits. The limits should be based on near time telemetry data that 397 the dCDN provides to the uCDN. In any instance where there are 398 multiple limits, the uCDN must consider and honor all specified 399 limits and use the most restrictive limit when applicable. 401 Property: total-limits 403 Description: The top level limits for the footprint. This 404 limit represents traffic limits scoped to total delegation from 405 the uCDN towards the dCDN. 407 Type: A JSON array of Capacity Limit objects (see 408 Section 2.2.1). 410 Mandatory-to-Specify: Yes. 412 Property: host-limits 414 Description: Limits for particular CDN Domains. These limits 415 are more specific than the total-limits values since they are 416 scoped to a particual host value. 418 Type: A JSON array of Capacity Limit objects (see 419 Section 2.2.1). 421 Mandatory-to-Specify: No. 423 2.2.1. Capacity Limit Object 425 The Capacity Limit Object is a JSON object which will be used with 426 the total-limits and host-limits objects. 428 Property: limit-type 430 Description: The units of maximum-hard and maximum-soft. 432 Type: String. One of the values listed in Section 2.2.1.1. 434 Mandatory-to-Specify: Yes. 436 Property: maximum-hard 438 Description: The maximum unit of capacity that is available for 439 use. 441 Type: Integer. 443 Mandatory-to-Specify: Yes. 445 Property: maximum-soft 447 Description: A soft limit at which an upstream should consider 448 deducing traffic to prevent hitting the hard limit. 450 Type: Integer. 452 Mandatory-to-Specify: No. 454 Property: telemetry-source 455 Description: Mapping of each a particular limit to a specific 456 metric with relevant real-time data provided by a telemetry 457 source. 459 Type: Capcity Limit Telemetry Source object (see 460 Section 2.2.1.2). 462 Mandatory-to-Specify: No. 464 Property: host 466 Description: The CDN Domain to which the limit applies. 468 Type: String. 470 Mandatory-to-Specify: Only when included within a host-limits 471 array. 473 2.2.1.1. Capacity Limit Types 475 Below are listed the valid capacity limit types. Additional limits 476 would need to be specified and extended into this list. The values 477 specified here represent the types that were identified as being the 478 most relevant metrics for the purposes of traffic delegation between 479 CDNs. 481 +=================+=====================+ 482 | Limit Type | Units | 483 +=================+=====================+ 484 | egress | Bits per second | 485 +-----------------+---------------------+ 486 | requests | Requests per second | 487 +-----------------+---------------------+ 488 | storage-size | Total bytes | 489 +-----------------+---------------------+ 490 | storage-objects | Count | 491 +-----------------+---------------------+ 492 | sessions | Count | 493 +-----------------+---------------------+ 494 | cache-size | Total bytes | 495 +-----------------+---------------------+ 497 Table 2 499 2.2.1.2. Capacity Limit Telemetry Source Object 501 The Capacity Limit Telemetry Source Object refers to a specific 502 metric within a Telementry Source. 504 Property: id 506 Description: Reference to the "id" of a telemetry source 507 defined by a Telemetry Capability object. 509 Type: String. 511 Mandatory-to-Specify: Yes. 513 Property: metric 515 Description: Reference to the "name" property of a metric 516 defined within a telemetry source of an FCI.Telemetry 517 Capability object. 519 Type: String. 521 Mandatory-to-Specify: Yes. 523 2.2.2. Capacity Limit Object Serialization 525 The following shows an example of an FCI.CapacityLimits object. 527 "capabilities": [ 528 { 529 "capability-type": "FCI.CapacityLimits" 530 "capability-value": { 531 "total-limits": [ 532 { 533 "limit-type": "egress", 534 "maximum-hard": 50000000000, 535 "maximum-soft": 25000000000, 536 "telemetry-source": { 537 "id": "capacity_metrics_region1", 538 "metric": "egress_5m" 539 } 540 } 541 ], 542 "host-limits": [ 543 { 544 "host": "serviceA.cdn.example.com", 545 "limits": [ 546 "limit-type": "egress", 547 "maximum-hard": 20000000000, 548 "maximum-soft": 10000000000, 549 "telemetry-source": { 550 "id": "capacity_metrics_region1", 551 "metric": "egress_service2_5m" 553 } 554 ] 555 }, 556 { 557 "host": "serviceB.cdn.example.com", 558 "limits": [ 559 "limit-type": "egress", 560 "maximum-hard": 30000000000, 561 "maximum-soft": 15000000000, 562 "telemetry-source": { 563 "id": "capacity_metrics_region1", 564 "metric": "egress_service2_5m" 565 } 566 ] 567 } 568 ] 569 }, 570 "footprints": [ 571 572 ] 573 } 574 ] 576 2.3. RequestedCapacityLimits Object 578 The MI.RequestedCapacityLimits Generic Metadata object, which is 579 cross referenced in CDNI Metadata Model Extensions [OC-MME], is fully 580 detailed within this document. To enable the uCDN to request changes 581 in dCDN limits, a new metadata object is introduced. Using this 582 object, a uCDN can request that a dCDN reconsider limits, as defined 583 by an FCI.CapacityLimits advertisement. The 584 MI.RequestedCapacityLimits object must be scoped within an 585 MI.HostIndex object and as such must be scoped to a host. The host 586 parameter value must be a CDN-Domain that the dCDN has been 587 configured to accept requests for. It is the responsibility of the 588 dCDN to make any required adjustments to the 589 FCI.CapacityLimits.total-limits if any per host limit updates might 590 exceed values specified via the FCI.CapacityLimits.total-limit. The 591 requested limits must specify a footprint, and that footprint should 592 be one in which the dCDN has advertised a capability to support. 594 Property: requested-limits 596 Description: Capacity Limits being requedted by the uCDN to the 597 dCDN. 599 Type: A JSON array of Requested Limits objects (see 600 Section 2.3.1). 602 Mandatory-to-Specify: Yes. 604 2.3.1. Requsted Limits Object 606 The Requested Limit Object is build of an associated type, a value 607 assocaited with the type, and the footprints that the limit should be 608 associated with. 610 Property: limit-type 612 Description: A limit type as defined in Section 2.2.1.1. 614 Type: String. 616 Mandatory-to-Specify: Yes. 618 Property: limit-value 620 Description: A unit of capacity defined in the maximum-hard 621 property of Section 2.2.1. 623 Type: Integer. 625 Mandatory-to-Specify: Yes. 627 Property: footprints 629 Description: The CDNI Footprint objects this requested limit 630 are associated with. 632 Type: A JSON array of CDNI Footprints (see [RFC8006]). 634 Mandatory-to-Specify: Yes. 636 2.3.2. Telemetry Capability Object Serialization 638 The following shows an example of MI.RequestedCapacityLimits object. 640 { 641 "host": "serviceA.cdn.example.com", 642 "host-metadata": { 643 "metadata": [ 644 ..., 645 { 646 "generic-metadata-type": "MI.RequestedCapacityLimits", 647 "generic-metadata-value": { 648 "requested-limits": [ 649 { 650 "limit-type": "egress", 651 "limit-value": 80000000000, 652 "footprints": [{ 653 "footprint-type": "ipv4cidr", 654 "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"] 655 }] 656 }, 657 { 658 ... 659 } 660 ] 661 } 662 } 663 ] 664 } 665 } 667 3. IANA Considerations 669 3.1. CDNI Payload Types 671 simialr to the type definitions described in section 7.1 of [RFC8006] 672 as well as the types described in section 6.1 of [RFC8008]. 674 This document requests the registration of the three additional 675 payload types: 677 +============================+===============+ 678 | Payload Type | Specification | 679 +============================+===============+ 680 | FCI.Telemetry | RFCthis | 681 +----------------------------+---------------+ 682 | FCI.CapacityLimits | RFCthis | 683 +----------------------------+---------------+ 684 | MI.RequestedCapacityLimits | RFCthis | 685 +----------------------------+---------------+ 687 Table 3 689 [RFC Editor: Please replace RFCthis with the published RFC number for 690 this document.] 692 3.1.1. CDNI FCI Telemetry Payload Type 694 Purpose: The purpose of this Payload Type is to list the supported 695 telemetry sources and the metrics made available by each source). 697 Interface: FCI. 699 Encoding: See section Section 2.1. 701 3.1.2. CDNI FCI Capacity Limits Payload Type 703 Purpose: The purpose of this Payload Type is to define Capacity 704 Limits based on a utilization metrics corresponding to telemetry 705 sources provided by the dCDN. 707 Interface: FCI. 709 Encoding: See section Section 2.2. 711 3.1.3. CDNI MI Requested Capacity Limits Payload Type 713 Purpose: The purpose of this Payload Type is to allow a uCDN to 714 request a CapacityLimit update from a dCDN 716 Interface: MI. 718 Encoding: See section Section 2.3. 720 4. Security Considerations 722 This specification is in accordance with the CDNI Request Routing: 723 Footprint and Capabilities Semantics. As such, it is subject to the 724 security and privacy considerations as defined in Section 8 of 725 [RFC8006] and in Section 7 of [RFC8008] respectively. 727 5. Acknowledgements 729 The authors would like to express their gratitude to TBD for TBD 730 (their guidance / contribution / reviews ...) 732 6. References 734 6.1. Normative References 736 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 737 Requirement Levels", BCP 14, RFC 2119, 738 DOI 10.17487/RFC2119, March 1997, 739 . 741 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 742 "Content Delivery Network Interconnection (CDNI) 743 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 744 . 746 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 747 Interconnection (CDNI) Control Interface / Triggers", 748 RFC 8007, DOI 10.17487/RFC8007, December 2016, 749 . 751 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 752 R., and K. Ma, "Content Delivery Network Interconnection 753 (CDNI) Request Routing: Footprint and Capabilities 754 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 755 . 757 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 758 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 759 May 2017, . 761 [RFC8804] Finkelman, O. and S. Mishra, "Content Delivery Network 762 Interconnection (CDNI) Request Routing Extensions", 763 RFC 8804, DOI 10.17487/RFC8804, September 2020, 764 . 766 6.2. Informative References 768 [OC-CII] Ryan, A., Ed., Rosenblum, B., Goldstein, G., Roskin, R., 769 and G. Bichot, "Open Caching Capacity Insights - 770 Functional Specification (Placeholder before 771 publication)", 772 . 775 [OC-MME] Goldstein, G., Ed., Power, W., Bichot, G., and A. Siloniz, 776 "CDNI Metadata Model Extensions", Version 00, 3 January 777 2022, . 780 [OC-RR] Finkelman, O., Ed., Hofmann, J., Klein, E., Mishra, S., 781 Ma, K., Sahar, D., and B. Zurat, "Open Caching Request 782 Routing - Functional Specification", Version 1.1, 4 783 October 2019, 784 . 787 [OCWG] "Open Caching Home Page", 788 . 790 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 791 Distribution Network Interconnection (CDNI) Problem 792 Statement", RFC 6707, DOI 10.17487/RFC6707, September 793 2012, . 795 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 796 "Framework for Content Distribution Network 797 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 798 August 2014, . 800 [SVA] "Streaming Video Alliance Home Page", 801 . 803 Authors' Addresses 805 Andrew Ryan 806 Limelight Networks 807 1465 N Scottsdale Road, Suite 500 808 Scottsdale 809 , AZ 85257 810 United States of America 812 Email: andrew@andrewnryan.com 813 Ben Rosenblum 814 Vecima 815 4375 River Green Pkwy #100 816 Duluth 817 , GA 30096 818 United States of America 820 Email: ben@rosenblum.dev 822 Nir B. Sopher 823 Qwilt 824 6, Ha'harash 825 Hod HaSharon 826 4524079 827 Israel 829 Email: nir@apache.org