Content DistributionInternetworking

IETF BOF

December 12, 2000

Phil RzewskiGary Tomlinson

Content Networking

• Using IETF “application layer” protocols as transport– e.g. HTTP, RTSP

• Routing & forwarding of requests & responses instead of packets

Example Content Network: Hierarchical caching

ISP

client

“edge” / “access”caches

“parent”cache(s)

• Typically static forwarding rules– HTTP parenting– ICP

• Example request forwarding– Single path– Redundant– URL partitioning

foo.combar.com

Example Content Network:Content Distribution Network (CDN)s

CDN

client

“surrogates”

“request-routing”system(s)

• Request routing systems map a client to a surrogate– e.g. DNS

• Example request forwarding– Ask another surrogate– Seek origin

Local DNS

Content Distribution Internetworking

CDN

ISP

• Interconnect Content Networks

• Different administrative domains

• Different technologies

Content Distribution Internetworking

• Area of CDI interest lies in communication across these boundaries

• Details within each Content Network should be irrelevant

??? ???

??? ???

Key Terms&

Concepts

Surrogate“A delivery server, other than the origin. Receives a mapped

request and delivers the corresponding content.”

client

Content Network

surrogate

origin

Delivery“The activity of presenting a

publisher’s content forconsumption by a client.”

delivery

Distribution“The activity of moving a publisher’s content from

its origin to one or more surrogates.

CNorigin

CN

CN

Injection(aka “origin distribution peering”)

“Publishing of content into one-or-moreContent Networks by origins.”

Content Signal“A message delivered through a distribution systemthat specifies information about an item of content.”

e.g. to indicate the origin has a new version ofsome piece of content

Request-Routing“The activity of steering or directing a request from a

client to a suitable surrogate.”

CN

CN

client

Accounting“Measurement and recording of distribution and delivery activities,

especially when the information recorded is ultimately used as a basis for the subsequent transfer of money, goods, or obligations”

CN

CN

CN

Drafting teams

• Two design teams produced 8 of the 9 drafts

• The two teams were aligned with Content Bridge & Content Alliance

• Sharing and cooperation developed late so there is some overlap

Understandingthe Strawman

Drafts

draft-day-cdnp-model-04.txt• Introduction, background, & vocabulary on

CDNs

– CDN examples provided

• Introduction & vocabulary on developing CDN interconnection technology

– CDN peering examples provided

– Content Peering Gateways (CPG) defined

• Some high-level operational considerations included

draft-day-cdnp-scenarios-02.txt

• Used to collect the communities of interest requirements

• Describes representative configurations that can be realized when internetworking CDNs.

• Framed by the concepts:– CONTENT has value– DISTRIBUTION has value– CLIENTS have value

draft-green-cdnp-gen-arch-02.txt

• Presents three main architectural elements– Request-Routing Peering System– Distribution Peering System– Accounting Peering System

• For each architectural element, presents:– Known requirements– Problems that need further investigation

• Security considerations

draft-green-cdnp-gen-arch-02.txtConceptual View of Peered CDNs

CPG CPG

CPG

CDN A

Request-Routing

Distribution

Accounting

CDN B

Request-Routing

Distribution

Accounting

CDN C

Request-Routing

Distribution

Accounting

surrogatessurrogates

surrogates

clients

draft-green-cdnp-gen-arch-02.txtRequest-Routing Peering System Architecture

Surrogates

CDN A

client

AuthoritativeRequest-Routing

System

Request-RoutingSystem

CDN C

Request-RoutingCPG

Request-RoutingSystem

Request-RoutingCPG

Request-RoutingCPG

Surrogate Surrogates

CDN B

Request-RoutingCPG

Request-RoutingSystem

Surrogate Surrogates

(1st Level)

(2nd Level)

Inter-CDN Request-Routing

Inter-CDN Recursive Request-Routing

draft-cain-cdnp-known-request-routing-00.txt

• Presents known mechanisms to direct client requests to surrogate servers.

– DNS request-routing

– Transport-layer request-routing

– Application-layer request-routing

• Discusses measurements, metrics, and feedback

draft-deleuze-cdnp-dnsmap-peer-00.txt

• Proposes a DNS-based Mapping System

• Focused on determining the next hop toward the appropriate surrogate

• Describes an approach using CNAME

• Proposes naming criteria to describe– Delivery service

– Delivery Footprint

draft-green-cdnp-gen-arch-02.txtDistribution Peering System Architecture

Surrogates

CDN A

Origin

DistributionSystem

CDN C

DistributionCPG

DistributionSystem

DistributionCPG

DistributionCPG

Surrogate Surrogates

CDN B

DistributionCPG

DistributionSystem

Surrogates

Origin Distribution Peering

Inter-CDN Distribution Peering

DistributionCPG

draft-green-cdnp-gen-arch-02.txtAccounting Peering System Architecture

Surrogates

CDN A

Origin

AccountingSystem

CDN C

AccountingCPG

AccountingSystem

AccountingCPG

AccountingCPG

Surrogate Surrogates

CDN B

AccountingCPG

AccountingSystem

Surrogates

Origin Accounting Peering

Inter-CDN Accounting Peering

AccountingCPG

BillingOrganization

Billing Accounting Peering

draft-gilletti-cdnp-aaa-reqs-00.txt

• Requirements for CDN Accounting Peering– Framed against ongoing work of AAA WG

• Details on CDN Accounting Peering models– Additional terminology

– Transaction models

– Accounting messaging

• Lists problems to be solved

draft-rzewski-oacp-00.txt

• Origin/Access Content Peering for HTTP

• Specific (“vertical”) implementation proposal of a way to pass control & accounting between origin & access endpoints.

– Roles described for specific types of content networks (Hoster/CDN, Operator, Access Provider)

• Note Request- Routing is a “null case” in the implementation

New Content Published by Content Provider

Content signals for changed URLs sent to Content Relay at Hoster/CDN

Content signals for changed URLs forwarded to Content Relay at Operator

Content signals for changed URLs forwarded to Content Relay Surrogate at Access Provider

Changed content may be retrieved by Content Relay at Access Provider (HTTP GET)

Content signals for changed URLs forwarded to Access Caches

Access clients request content from Access Caches, if it is not in Access Cache, content is pulled from Content Gateway Surrogate (parent cache)

draft-rzewski-oacp-00.txtAccess Provider (ISP)Hoster/CDN

Content Relay

ContentInjector

ContentRelay

Surrogate

AccessCaches

Origin

Content Relay

OperatorOperator

www.com

AccessClients

draft-rzewski-cndistcs-00.txt

• Proposes specific content signals– HTTP DELETE method for

“invalidation”

– Also additional “CND: GET” header to kick off pre-load

Log info is collected and summarized at Access Caches in regular intervals

Access log info is collated at Accounting Relay at Access Provider

Access log information centralized & passed through Operator for settlement and billing

Near real-time summaries are forwarded to Accounting Gateway at Hoster/CDN

draft-rzewski-oacp-00.txtISP 1

Hoster/CDN

AccountingRelay

AccountingRelay

SummaryLogging

AccessCachesOrigin

ISP 2

AccountingRelay

SummaryLogging

AccessCaches

OperatorAccounting

Relay

Settlement& Billing

Access Providers (ISPs)

AccessClients

draft-rzewski-cnacct-00.txt

• Proposes SQUID-like summary log format

• Proposes using HTTP POST to pass log information between networks

OrganizationGoing Forward

Possible Informal StructureModels

ScenariosArchitectureFramework

“umbrella”

AccountingKnown methods

Requirement specificationsProposed protocols

Implementation debate

DistributionKnown methods

Requirement specificationsProposed protocols

Implementation debate

Request-RoutingKnown methods

Requirement specificationsProposed protocols

Implementation debate

“communities of interest”

Other WGs

AAA

WEBI

DNSext

.

.

.