ETSI TS 182 032 V1.1.1 (2013-04)

CDN Interconnection Architecture

DTS/NTECH-00002-CDN-I-stage2

General Information

• Status: Published
• Publication Date: 23-Apr-2013
• Technical Committee: NTECH - Network Technologies
• Current Stage: 12 - Completion
• Due Date: 06-May-2013
• Completion Date: 24-Apr-2013

Standards Content (Sample)

Technical Specification
CDN Interconnection Architecture

2 ETSI TS 182 032 V1.1.1 (2013-04)

Reference
DTS/NTECH-00002-CDN-I-stage2
Keywords
architecture, CDN, interconnection
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2013.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 182 032 V1.1.1 (2013-04)
Contents
Intellectual Property Rights . 6
Foreword . 6
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 High-level overview . 9
4.1 CDN interconnection services and capabilities . 9
4.2 CDN interconnection capabilities . 10
4.3 CDN-I basic capability set. 10
4.4 CDN-I extended capability set . 11
4.5 Compliance. 12
5 Overview of functional entities . 12
5.1 Functional architecture for CDN interconnection services . 12
5.2 Functional entities . 12
5.2.1 CDN Interconnection Control Function (ICF) . 13
5.2.2 Request and Content Control Function (RCF) . 13
5.2.3 Distribution of Content Function (DCF) . 13
5.3 Reference points . 13
5.3.1 ICF - ICF (CDN-Ic) . 13
5.3.2 RCF - RCF (CDN-Ir) . 14
5.3.3 DCF - DCF (CDN-Id) . 14
6 Procedures . 14
6.1 CDN interconnection phases . 14
6.1.1 Interconnection establishment . 14
6.1.2 Interconnection phase . 15
6.1.3 Interconnection release . 16
6.2 Content distribution . 18
6.2.1 General . 18
6.2.2 Content distribution control . 18
6.2.2.1 General . 18
6.2.2.2 Upstream-initiated content distribution . 18
6.2.2.3 Downstream-initiated content distribution . 19
6.2.2.4 Upstream-initiated content deletion . 20
6.2.2.5 Downstream notification of content deletion . 21
6.2.3 Content exchange . 22
6.2.3.1 General . 22
6.2.3.2 File transfer . 22
6.2.3.3 Stream set-up. 22
6.2.3.4 Stream release . 23
6.2.3.5 Segmented content . 24
6.3 Request routing . 25
6.3.1 General . 25
6.3.2 Single-delivery request routing . 25
6.3.3 Multiple-delivery request routing . 25
6.4 Reporting . 26
6.4.1 General . 26
6.4.2 Upstream-initiated reporting . 26
ETSI
4 ETSI TS 182 032 V1.1.1 (2013-04)
6.4.3 Downstream-initiated reporting . 27
6.5 Interconnection Control Function Procedures . 27
6.5.1 General . 27
6.5.2 Capabilities exchange . 28
6.5.3 Footprint exchange . 28
6.5.4 Services status exchange . 29
6.6 DRM Procedures . 30
6.6.1 General . 30
6.6.2 Flagging CDN content for DRM . 30
6.6.3 Key exchange for DRM . 30
6.6.3.1 uCDN-initiated key exchange for DRM . 30
6.6.3.2 dCDN-initiated key exchange for DRM . 31
7 Data models . 32
8 Security. 32
8.1 Security feature interoperability . 33
8.2 CDN interconnection service protection . 33
8.2.1 Secure CDN-I connection establishment . 33
8.3 CDN interconnection content and metadata authenticity . 33
8.4 Security policy definition by content provider . 34
Annex A (informative): Interfaces and Functions . 35
A.1 CDN interconnect interfaces under study. 35
A.1.1 ETSI CDN . 35
A.1.2 IETF CDN-I . 36
A.1.2.1 General . 36
A.1.2.2 IETF CDN-I compatibility with ETSI CDN-I . 36
A.1.3 ATIS CSF . 37
A.1.4 FP7 OCEAN . 37
A.2 Functionality of the CDN interconnection . 37
A.2.1 Content distribution, upstream or downstream initiated . 37
A.2.2 File-based and stream-based content . 38
A.2.3 Request routing, per request or not . 39
A.2.4 Reporting or logging . 39
A.2.5 Security mechanisms . 39
A.2.6 Content adaptation . 39
Annex B (informative): Datamodel analysis . 40
B.1 Metadata structure . 40
B.1.1 General . 40
B.1.2 CDN Blacklists/Whitelists . 40
B.1.3 Capabilities required for content delivery . 40
B.1.4 Content Access Lists . 40
B.1.5 Content Manipulation Policy . 40
B.1.6 Multi-Segment related metadata . 41
B.1.7 Security and DRM related metadata . 41
B.1.8 Reporting related metadata . 41
Annex C (informative): Scenarios for using CDN-I procedures . 42
C.1 General . 42
C.2 Basic CDN Interconnection life-cycle. 42
C.3 Premium delivery of content . 43
C.4 Managed delivery of content . 44
C.5 Best-effort delivery of content . 45
Annex D (informative): Datamodels . 46
ETSI
5 ETSI TS 182 032 V1.1.1 (2013-04)
D.1 CDN related data models . 46
D.1.1 CDN information data model . 46
D.1.2 CDN footprint data model . 46
D.1.3 CDN Capabilities data model . 46
D.2 Content related data models . 47
D.2.1 Content related metadata data model. 47
D.2.2 Content distribution reporting data model . 47
D.2.3 Content request source data model . 47
D.2.4 Content delivery reporting data model . 48
D.3 Data model entity relations . 48
History . 49

ETSI
6 ETSI TS 182 032 V1.1.1 (2013-04)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Network Technologies (NTECH).
Introduction
Content Delivery Networks (CDN) are systems for the efficient delivery of digital objects (e.g. files with multimedia
content as video on demand or other file types) and multimedia streams (e.g. live television streams) over IP networks
to many end points and viewers. Typically, a CDN consists of one or more servers that deliver the digital objects and/or
streams, and a management/control system. The management/control system takes care of content distribution, request
routing, reporting, metadata and other aspects that make the system work.
Currently implemented CDNs are based on a widespread network of distribution nodes controlled by a functional entity
taking care of content distribution decisions. The control functional entity keeps track of all content locations, manages
distribution amongst the distribution nodes and/or clusters and also decides which distribution node should serve a
client request.
Every CDN may have a specific network footprint in which it can deliver content effectively. This footprint depends on
the locations of distribution nodes that the CDN controls. It is often inefficient to build new distribution nodes that are
not in the region in which the company running the CDN is operating. A solution is to interconnect two CDNs and
share existing infrastructure for content delivery. Interconnection of CDNs is achieved by interconnecting the
centralized functional entities that represent the logic behind the decisions in each CDN. This is called CDN-I or
Content Delivery Network Interconnection.
The present document defines the architecture and principles of the interconnection between CDNs according to the
requirements defined in TS 102 990 [1], which also contains informational use cases for CDN interconnections.
Other sources of relevant information on CDN interconnection topics are the following organizations:
• ETSI (e.g. TS 182 019 [i.6], TR 102 688-9 [i.1])
• IETF: WG CDN-I (e.g. RFC 6707 [i.2])
• ATIS Cloud Services Forum (e.g. ATIS-0200003 [i.3], ATIS-0200004 [i.5])
ETSI
7 ETSI TS 182 032 V1.1.1 (2013-04)
1 Scope
The present document specifies the architecture and functions of a CDN Interconnection system, implementing the
requirements defined in TS 102 990 [1].
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] ETSI TS 102 990: "Media Content Distribution (MCD); CDN Interconnection, use cases and
requirements".
2.2 Informative references
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI TR 102 688-9: "Media Content Distribution (MCD); MCD framework; Part 9: Content
Delivery Infrastructures (CDI)".
[i.2] IETF RFC 6707: "Content Distribution Network Interconnection (CDNI) Problem Statement",
September 2012.
NOTE: Available at http://tools.ietf.org/html/rfc6707.
[i.3] ATIS-0200003: "CDN Interconnection use case specification and high-level requirements".
NOTE: Available at http://webstore.ansi.org/RecordDetail.aspx?sku=ATIS-0200003.
[i.4] ISO/IEC 23009-1: "MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH)".
[i.5] ATIS-0200004: "CDN interconnection use cases and requirements for multicast-based content
distribution".
NOTE: Available at http://webstore.ansi.org/RecordDetail.aspx?sku=ATIS-0200004.
[i.6] ETSI TS 182 019: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Content Delivery Network (CDN) architecture".
ETSI
8 ETSI TS 182 032 V1.1.1 (2013-04)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
NOTE: Some of the following definitions are from TS 182 019 [i.6] and TR 102 688-9 [i.1].
CDN Interconnection: interconnection between two CDNs, enabling the controlled distribution of content between
those CDNs
content delivery: act of delivering deployed content to a user
Content Delivery Network (CDN): set of functions managing content acquired from content sources, through delivery
to the user
content acquisition: act of acquiring content from a content source
content deployment: act of moving ingested content to one or more network entities, based on content deployment
policies
content distribution: act of moving content in and between CDNs
content ingestion: act of introducing content (and associated data) into the Content Delivery Infrastructure
content item: uniquely addressable content element in a CDN.
NOTE: A content item is defined by the fact that it has its own Content Metadata associated with it. It is the
object of content distribution and request routing operations in a CDN. Example of Content Items are a
video file/stream, an audio file/stream, an image file or segmented content together with an associated
manifest file.
downstream: side of the CDN interconnection that is closest the Consumer
logging: recording events related to content items, request routing and content distribution
manifest file: file that describes the composition of segmented content
metadata: data about content items and CDN network specifics
reporting: providing access to recorded events related to content items, request routing and content distribution
request routing: exchange of information be two CDNs to aid routing of requests of users for content
segmented content: content composed of multiple files, or content composed of multiple streams, or content composed
of one or more files and one or more streams
upstream: side of the CDN interconnection that is closest to the Content Provider
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAC Advanced Audio Coding
ALF Asset Location Function
AMT Automatic Multicast Tunnelling
AS Autonomous System
ATIS Alliance for Telecommunications Industry Solutions
BGP Border Gateway Protocol
CCF Cluster Controller Function
CDF Content Delivery Function
ETSI
9 ETSI TS 182 032 V1.1.1 (2013-04)
CDN Content Delivery Network
NOTE: Industry sometimes uses "Content Distribution Network".
CDNCF Content Delivery Network Control Function
CDN-I Content Delivery Network Interconnection
CSF ATIS Cloud Services Forum
dCDN Downstream Content Delivery Network
DCF Distribution-of-Content Function
dDCF Downstream Distribution-of-Content Function
dICF Downstream Interconnection Control Function
DNS Domain Name System
DNSSEC Domain Name System Security Extensions
dRCF Downstream Request-routing and Content-control Function
DRM Digital Rights Management
FLV Flash video
GPS Global positioning system
HD High Definition
HDS HTTP Dynamic Streaming
HLS HTTP Live Streaming
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
ICF Interconnection Control Function
IP Internet Protocol
MF Manifest File
MPD Media Presentation Description
MPEG Moving Picture Experts Group
MSS Microsoft Media Server
OCEAN Open ContEnt Aware Networks
RCF Request-routing and Content-control Function
REST Representational state transfer
RTMP Real Time Messaging Protocol
RTSP Real Time Streaming Protocol
SDO Standards Developing Organization
SLA Service Level Agreement
SOAP Simple Object Access Protocol
TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking
uCDN Upstream Content Delivery Network
uDCF Upstream Distribution-of-Content Function
UE User Equipment
uICF Upstream Interconnection Control Function
uRCF Upstream Request-routing and Content-control Function
URI Uniform Resource Identifier
URL Uniform Resource Locator
WMV Windows Media Video
4 High-level overview
4.1 CDN interconnection services and capabilities
CDNs are in general autonomous networks offering different services to their users. A CDN's primary function is to
optimize content distribution and delivery. In addition to this primary function many CDNs chose to implement various
other capabilities like content manipulation, digital rights management (DRM), intelligent handling of segmented
content and others.
ETSI
10 ETSI TS 182 032 V1.1.1 (2013-04)
Because of this variation, the present document specifies a basic set of capabilities that every interconnected CDN shall
support. In addition to the basic capability set, the present document specifies an extended capability set, describing
non-mandatory capabilities available for the CDN interconnection environment. The CDN interconnection shall support
a capability exchange mechanism described later in the present document.
Requirements defined in TS 102 990 [1] shall apply.
4.2 CDN interconnection capabilities
Table 4.2.1 provides a table of all the capabilities available for CDN interconnection, grouped into the basic and
extended capability set. It also mentions whether those capabilities are mandatory or optional.
Table 4.2.1: Capability Overview Table
Basic Extended Description
capability capability
set set
Interconnection Mandatory Responsible for management of the peering relationship between two
Control CDNs
Request Routing Mandatory Capabilities responsible for making it possible for CDNs to direct
client requests
Content Distribution Mandatory Distribute content to other interconnected CDN
Footprint Exchange Mandatory Responsible for announcing the network footprints the CDNs are
offering to serve
Metadata Exchange Mandatory Used to exchange content related information
Content Status Mandatory Used for distribution of real-time status related to the content
Exchange
Report Exchange Mandatory Used for possibly delayed distribution of comprehensive information
gathered during the content delivery process
Capability Exchange Mandatory Capability to exchange information about the availability of extended
capabilities in CDNs
Metadata Defined Optional Capability of creating reports according to content provider
Reporting parameters defined in metadata
Content Integrity Optional Capability to maintain content integrity
Control
Content Adaptation Optional Capability to make content processing and adaptation within the CDN
Multi-Segment Optional Capability to handle multi-segment content efficiently (for instance
Content Support logging segment download sessions per session not just per
segment)
Content Access Optional Capability to define advanced content access control rules
Control
Content Security Optional Capability to use cryptographic technologies to maintain content
and DRM security and DRM
Custom Capability Optional Capability to support other (not standardized) capabilities
Support
4.3 CDN-I basic capability set
Every CDN that wants to take part in CDN interconnection shall have a basic set of interconnection related capabilities.
These capabilities give the CDN the ability to properly respond to requests coming from other CDNs. The capabilities
included in the basic service set are listed in figure 4.3.1.
ETSI
11 ETSI TS 182 032 V1.1.1 (2013-04)

Figure 4.3.1: Basic CDN-I capability set
4.4 CDN-I extended capability set
Whereas the basic capability set is sufficient for basic CDN interconnection many CDNs have additional capabilities
that may not be available in all CDNs participating in the CDN federation. The presence of optional capabilities in the
CDN federation requires those CDNs that wish to make use of those capabilities to have the capability to exchange
information about the availability of extended capabilities in CDNs. This capability is called Capability Exchange and it
is mandatory.
Some of the capabilities included in the extended capability set are listed in figure 4.4.1.

Figure 4.4.1: Extended CDN-I capability set
ETSI
12 ETSI TS 182 032 V1.1.1 (2013-04)
4.5 Compliance
A CDN interconnection solution is compliant to the present document if the following points are fulfilled:
• All mandatory services and features are implemented as specified in the present document.
• If an optional service or feature is implemented, then it is implemented as specified in the present document.
• If an optional service or feature is implemented, and the present document specifies multiple options, then it is
implemented according to at least one or those options.
5 Overview of functional entities
5.1 Functional architecture for CDN interconnection services
The overall functional architecture for CDN interconnection service is shown in figure 5.1.1. The functional
architecture is based on a multi-layer architecture that enable separate functionalities used for interconnection of CDNs
that may involve up to 3 different level of functionalities and related reference points required. The first layer is
responsible for content distribution, the second for controlling of content and request, and the third for the controlling of
the interconnection itself. The CDN-I functional architecture should enable CDNs to agreed on a minimal level of
interconnection, depending on available capabilities and their needs. In case of CDN peering both interconnected CDNs
may play both the role of upstream and/or downstream CDN, depending of direction of content request.

Figure 5.1.1: Functional architecture for CDN interconnection services
5.2 Functional entities
The Content Delivery Network contains one or more Distribution of Content Function (DCF) that can be grouped
geographically or administratively in clusters and contains several delivery nodes (that distribute content to other CDN
or to end user) hidden to other CDN. CDN shall contain one or more Request and Content Function (RCF) that process
requests related to content distribution control and routing request. A CDN Interconnection Control Function (ICF) is
responsible for the management of the interconnection. All CDN interconnection entities may support topology hiding
and provide abstraction layer from internal CDN architecture.
NOTE: Co-location of interconnection entities with existing CDN entities is possible. For example in case that
one of the interconnected CDNs is based on ETSI CDN specification [i.6] there is possibility to collocate
ICF with CDNCF, RCF with CCF and DCF with CDF.
ETSI
13 ETSI TS 182 032 V1.1.1 (2013-04)
5.2.1 CDN Interconnection Control Function (ICF)
A CDN Interconnection Control Function (ICF) shall manage, create, terminate and exchange CDN networks
properties, status report required for CDN interconnection between two or more CDNs (CDN peers).
An ICF contains following functionalities:
• Footprint Exchange - enable CDNs exchange footprint information.
• Capability Exchange - the upstream CDN gets information about capabilities of downstream CDN. This
information can be used by Request Control Function.
• Network Status Reporting - the upstream CDN gets status of downstream CDN network. This status is used by
Request Control Function. If for example downstream network reports problems, upstream CDN will serve
request by itself, or via other functional downstream CDN.
• Network Logging - the downstream CDN sends logs to upstream CDN network. These logs are important for
content provider and also for CDN administration.
IP interconnection setup and service agreement between CDN providers shall be realized prior to logical CDN
interconnection. Details of these activities are out of scope of the present document.
5.2.2 Request and Content Control Function (RCF)
The Request and Content Control Function (RCF) is responsible for content control and request routing as well as
exchanging metadata related to content control.
The RCF contains following functionalities:
• Metadata exchange function - Metadata are sent from upstream CDN to downstream CDN. Downstream CDN
can then make room for content and can inform upstream CDN about content handling possibility.
• Content request function - one CDN can request content from other CDN. Different request routing models
can be used (e.g. push/pull model, chaining or redirecting requests).
• Content status reporting - The Upstream CDN gets status of content from downstream CDN. This status can be
than stored local database. Also events can be invoked on status change. Also Downstream CDN can inform
upstream CDN when content status has been changed.
5.2.3 Distribution of Content Function (DCF)
Distribution of Content Function (DCF) is responsible for distribution of content between CDNs in form of files,
streams, metadata.
The DCF contains following functionalities:
• Transfer of file-based content.
• Publication and streaming of stream-based content.
• Content metadata distribution (if metadata distributed with content).
5.3 Reference points
5.3.1 ICF - ICF (CDN-Ic)
This reference point is between two ICFs and it is used for controlling interconnection peer and transferred over this
point information related to CDN capabilities and status, including footprint exchange, capability exchange,
interconnection status reporting and network usage/performance logging.
ETSI
14 ETSI TS 182 032 V1.1.1 (2013-04)
5.3.2 RCF - RCF (CDN-Ir)
This reference point is between two CCFs and it is used for requesting content and to transfer content related
information, including content metadata exchange, content requests and content status reporting.
5.3.3 DCF - DCF (CDN-Id)
This reference point is between two DCFs. Content files, content streams and content related data (if distributed as part
of content) are transferred over this point.
6 Procedures
This clause specifies CDN-I procedures. Clause 6.1 specifies the 3 main phases of interconnection. The following
clauses describe specific procedures related to different capabilities that were agreed during the interconnection phase.
6.1 CDN interconnection phases
The basic process of CDN interconnection may consist of three basic phases:
• Interconnection establishment, during which the CDNs negotiate the interconnection.
• Interconnection phase, during which the CDNs are fully interconnected and able to share their resources.
• Interconnection release, during which the interconnection between the CDNs is released.
The interconnection establishment and release phases may be omitted in systems that prefer manual provisioning and in
that case interconnection establishment and configuration is performed statically by both interconnected CDN providers
before interconnection phase itself.
The procedure related to the interconnection establishment is described in clause 6.1.1, the procedure related to the
interconnection phase is described in clause 6.1.2, and the procedure related to the interconnection release is described
in clause 6.1.1.
6.1.1 Interconnection establishment
The interconnection establishment is a procedure in which an uCDN and a dCDN begin with no relationship between
each other and proceed by exchanging all the information needed to verify each other's identity and thus establish a
secure communication channel between each other. This communication is between the ICFs of the CDNs and spans
the first three steps of the procedure. The rest of the phase consists of three sub procedures in which the dCDN informs
the uCDN about its capabilities, footprint and starts notifying it about its status. After the uCDN receives the first
positive status exchange from the dCDN, it can safely assume that the dCDN is ready to process its requests. The
conclusion of this phase is the establishment of communication between dRCF and uRCF and the whole CDN-I
relationship moves to its interconnection phase.
The interconnection establishment is an optional procedure, which is not used in case both CDN providers agree on
static manual pre-provisioning of CDN interconnection, but if dynamic interconnection establishment is supported by
both CDNs it should follow one of these procedures.
ETSI
15 ETSI TS 182 032 V1.1.1 (2013-04)

Figure 6.1.1.1: Interconnection establishment
NOTE 1: Prior to interconnection establishment procedure, IP interconnection and service level agreement between
interconnected CDN providers and/or content provider are needed.
The interconnection process should begin with the interconnection establishment. This interconnection establishment
is defined by a procedure consisting of following steps:
1) The uCDN sends an interconnection request to the dCDN. This message is sent between the ICFs of the CDNs
and consists of all the information the dCDN needs to decide whether to accept or deny the establishment of
peering relationship with the uCDN. This information may include uCDN's CDN identifier, authentication
data, required peering parameters and others.
2) After the dCDN receives an interconnection offer from an uCDN it analyses its contents and decides whether
to deny it (sending an interconnection deny message and terminating the procedure) or accept it. If it decides
to accept the offer then it sends an interconnection accept message that contains information that the uCDN
can use to make a final decision about establishing the peering relationship with the dCDN. This information
may include dCDN's CDN identifier, authentication data, required peering parameters and others.
3) After the uCDN receives an interconnection accept from a dCDN it analyses its contents and decides whether
to deny it (sending an interconnection deny message and terminating the procedure) or confirm it. If it decides
to confirm it then it sends an interconnection accept message indicating that the peering can begin.
4) After the interconnection is confirmed by the uCDN then the dCDN shall begin its first capability exchange
procedure.
5) After the first capability exchange procedure is finished the dCDN shall begin its first footprint exchange
procedure.
6) After the first footprint exchange procedure is finished the dCDN shall begin its first status exchange
procedure.
NOTE 2: This procedure may be repeated if there are multiple ICFs to be interconnected between the two CDNs.
Both the CDNs should then proceed to the interconnection phase.
6.1.2 Interconnection phase
The second phase is simply called interconnection phase. In interconnection phase shall be both CD
...