1 / 10

CDNI Requirements draft -lefaucheur-cdni-requirements-01

CDNI Requirements draft -lefaucheur-cdni-requirements-01. Francois Le Faucheur , Cisco Mahesh Viveganandhan , Cisco Grant Watson, BT Yiu Lee, Comcast IETF 80, Prague. Mohamed Boucadair ( mohamed.boucadair@orange-ftgroup.com )

abie
Download Presentation

CDNI Requirements draft -lefaucheur-cdni-requirements-01

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CDNI Requirementsdraft-lefaucheur-cdni-requirements-01 Francois Le Faucheur, Cisco Mahesh Viveganandhan, Cisco Grant Watson, BT Yiu Lee, Comcast IETF 80, Prague Mohamed Boucadair (mohamed.boucadair@orange-ftgroup.com) Christian Jacquenet (christian.jacquenet@orange-ftgroup.com) Dean Cheng (chengd@huawei.com) Yiu Lee (yiu_lee@cable.comcast.com) IETF77, Anaheim

  2. Requirements Structure • Sets of Requirements • Generic Requirements • Control Protocol Requirements • Request Routing Protocol Requirements • Metadata Distribution Protocol Requirements • Logging Protocol Requirements • Security Requirements • Scopes (in each set): • Initial scope (within potential WG initial charter) • MUST: strong convergence that it is required “day1” • SHOULD/MAY: needs further arbitration on whether it can be supported “day1” • Future scope (outside potential WG initial charter)

  3. uCDN= upstream CDN dCDN= downstream CDN Generic Requirements • R1: Leverage existing protocols. • R2: No change in the user agent (the client). • R3: CDNI solution must not be intrusive into CDNs: • dCDN and uCDN are not required to know each other’s cache topology, cache status,… • R4 & R5: HTTP is the first supported protocol for Delivery and Acquisition. • R8: [should] support cascaded CDNs. • R9: [should] support any kind of CDNI topology (e.g. Star, Ring, Tree etc.) • R10: CDNI must prevent looping • R11: CDNI must consider known issues with 3rd party references

  4. Control Protocol Requirements • These requirements are defined to: • Enable CDNs to communicate for management/bootstrapping prior to the actual content delivery. • Enable uCDN to trigger actions in dCDN • Some highlights: • R15: Content Purge request by uCDN (invalidate/delete an object). • R16: Content Purge Acknowledgment by dCDN. • R17: Trigger Metadata pre-positioning from the uCDN to dCDN. • R18: [should] Trigger content pre-positioning from the uCDN to dCDN

  5. Request Routing Protocol Requirements • These requirements are defined to allow the uCDN Routing-Request System (RRS) to delegate a request to the dCDN RRS. • Highlights: • R27: dCDN can refuse further request delegations (“busy” tone) • R28: [should] dCDN advertises capabilities (e.g. footprint, content types), resources (e.g. streaming bandwidth) and affinities (e.g. delivery cost) • R30: [may] dCDN advertises policy/admin-info (e.g. max requests per second, max aggregate volume) • R31 & R32: efficient for small objects (aka DNS-based) and for large objects (aka HTTP-based) • R33 & R34: Support both Recursive Request Routing and Iterative Request Routing. • R37: Pass the user agent location information. • R38: Pass the content metadata location information.

  6. Metadata Distribution Protocol Requirements • These requirements are defined to allow the uCDN to communicate to dCDN the “distribution metadata” • Highlights: • R45: uCDN provides metadata to dCDN • R46: Support both pre-positioning and dynamic content acquisition • R47: Support metadata “Pull” • R48: Support metadata “Push” • R49 & R50: metadata must convey where/how dCDN can acquire content • R51 & R52: Support real-time Add/Modify/Delete metadata • R53& R54: Metadata data structure must support referencing a single object or a set of objects. • R58 & R59 : Support distribution control policies (geo-blocking, time window & authorization checks (e.g. URI signing) Distribution metadata = metadata that is relevant to, and has to be processed, by CDNs (eg where to acquire content, time window)

  7. Logging Protocol Requirements • In a distributed system such as CDNI, logging is used to track/recreate the chain of events (for accounting, monitoring, analytics, troubleshooting). • Highlights: • R63: Reliable logging. • R64: dCDN provides logging to uCDN for content delivery performed by dCDN on behalf of uCDN • R67: Support offload batch upload of log files.

  8. Security Requirements • A set of requirements to secure CDNI • R74: Support secure channel to exchange data over Internet. • R75: Protect against DOS attack. • R76: [should] non-repudiation of logs. • R77: [should] Protect against spoofed log. • R78: [may] Define a mechanism to delegate credentials to downstream CDN to acquire content from the origin.

  9. Questions?

  10. Two New Terms • Recursive CDNI Request Routing • Consult the downstream CDN to make the routing decision • Iterative CDNI Request Routing • Make the routing decision without consulting downstream CDN

More Related