Internet DRAFT - draft-stephan-cdni-control-operations
draft-stephan-cdni-control-operations
Network Working Group E. Stephan
Internet-Draft G. Bertrand
Intended status: Standards Track A. Marrec
Expires: May 10, 2013 Y. Le Louedec
France Telecom - Orange
November 06, 2012
CDNI Control Operations
draft-stephan-cdni-control-operations-00
Abstract
This memo discusses the role of the CDNI control interface and
proposes a framework clarifying the control operations for CDNI.
It does not make any assumption about the protocol implementation,
which may be either manual or automated. Furthermore, both uCDN and
dCDN could initiate Control operations.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 10, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Stephan, et al. Expires May 10, 2013 [Page 1]
Internet-Draft CDNI Control Operations November 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Stephan, et al. Expires May 10, 2013 [Page 2]
Internet-Draft CDNI Control Operations November 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The role of the CDNI Control Interface . . . . . . . . . . . . 5
2.1. Pre-position,revalidate and purge metadata and content . . 6
2.2. Bootstrapping of the other CDNI interfaces . . . . . . . . 7
3. CDNI Control Framework . . . . . . . . . . . . . . . . . . . . 8
3.1. CDNI Control Operations . . . . . . . . . . . . . . . . . 9
3.2. Control Parameters . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Service Agreement level . . . . . . . . . . . . . . . 10
3.2.2. Delivery Service Level . . . . . . . . . . . . . . . . 13
3.2.3. class-of-requests Level . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Stephan, et al. Expires May 10, 2013 [Page 3]
Internet-Draft CDNI Control Operations November 2012
1. Introduction
The CDNI control Interface is introduced by [RFC6707] along with the
CDNI Metadata, CDNI Request Routing, CDNI Acquisition and CDNI
Logging interfaces. Then [I-D.ietf-cdni-framework] specifies the
high-level functions performed by each of the CDNI interfaces and the
relationships between them. It defines the role of the CDNI control
interface as encompassing "the operations to discover, initialize,
and parameterize the other CDNI interfaces, as well as operations to
pre-position, revalidate, and purge both metadata and content."
Nevertheless [RFC6707] indicates that the "exact inter-CDN control
functionality required to be supported by the CDNI Control interface
is less well defined than the other three CDNI interfaces", and
[I-D.ietf-cdni-framework] reports that "There is some ambiguity as to
the line between the set of trigger-based operations in the CDNI
Control interface and the Metadata interface". The present memo
proposes to fill this gap. It discusses the role of the CDNI control
interface and proposes a framework for working out the specification
of the control operations for CDNI.
1.1. Terminology
The reader must be familiar with the terminology given by [RFC6707]
and by the drafts [I-D.ietf-cdni-requirements] and
[I-D.ietf-cdni-framework].
Following are terms and abbreviations introduced in the document:
Control Parameter: A parameter whose value may be exchanged for
controlling the configuration of the CDNI interfaces;
Control Operation: The exchange of messages for discovering,
initializing, and parameterizing a CDNI interface.
Bootstrapping: A control operation allowing the exchange of the
Parameters required to establish the connectivity between servers
which enforce the CDNI interfaces, including security aspects like
server authentication, encryption, etc.
Class-of-requests: A Class-of-requests identifies a set of content
Requests, related to a specific CSP, received from clients in a
given footprint and sharing common properties. These properties
include:
* Any header, URL parameter, query parameter of an applicative
content request (e.g. of an HTTP content request)
Stephan, et al. Expires May 10, 2013 [Page 4]
Internet-Draft CDNI Control Operations November 2012
* Any header, or sub-domain of the FQDN of a DNS lookup request
Examples:
* Class-of-Requests = all the requests that include the HTTP
header "User-Agent: Mozilla/5.0" related to CSP
"http://*.cdn.example.com" from AS3215
* Class-of-Requests = all the DNS requests from anywhere and
related to CSP "cdn*.example.com"
Delivery Service: A Delivery Service is defined by a set of Class-
of-Requests, related to a given CSP, and a list of parameters that
apply to all these Class-of-Requests (logging format, delivery
quality/capabilities requirements...)
Service Agreement: A service agreement is defined by a uCDN
identifier, a dCDN identifier, a set of Delivery Services and a
list of parameters that apply to the Service Agreement.
Once a Service Agreement is agreed between the administrative
entities managing the CDNs to be interconnected, the upstream CDN
and the downstream CDN of the CDN interconnection must be
configured according to this agreed Service Agreement. For
instance, a given uCDN (uCDN1) may request a given dCDN (dCDN1) to
configure one Delivery Service for handling content requests for
HTTP Adaptive streaming videos delegated by uCDN1 and related to a
specific CSP (CSP1) and another one for handling content requests
for static pictures delegated by uCDN1 and related to CSP1. These
Delivery services would belong to the Service Agreement between
uCDN1 and dCDN1 for CSP1. In this simple example, uCDN1 may
request dCDN1 to include Delivery Service information in its CDNI
Logging, to help uCDN1 to provide relevant reports to CSP1.
CDNI Entity: we call CDNI Entity the end-point of a CDNI
interface.
2. The role of the CDNI Control Interface
This section discusses the role of the CDNI Control interface.
The [I-D.ietf-cdni-framework] defines the role of the CDNI control
interface as:
o "the operations to discover, initialize, and parameterize the
other CDNI interfaces" which are: CDNI request Routing, metadata
and Logging.
Stephan, et al. Expires May 10, 2013 [Page 5]
Internet-Draft CDNI Control Operations November 2012
* The CDNI Control interface has the responsibility of
bootstrapping the other CDNI interfaces, and of updating or
deleting instances of the other CDNI interfaces.
o "as well as operations to pre-position, revalidate, and purge both
metadata and content".
* This is the role of the "trigger" interface which
specifications are still work in progress in the draft
document[I-D.murray-cdni-triggers].
2.1. Pre-position,revalidate and purge metadata and content
Operations to pre-position, revalidate, and purge both metadata and
content are defined in the draft document [I-D.murray-cdni-triggers].
That draft document [I-D.murray-cdni-triggers] defines a "message
flow for trigger" based on a RESTfull web services, and specific
metadata related activities an upstream CDN can trigger.
The "message flow for trigger" allows:
o The upstream CDN to trigger activity in downstream CDN ;
o The upstream CDN to discover the status of the activity.
The activities an upstream CDN can trigger in the downstream CDN and
defined in [I-D.murray-cdni-triggers] are all dedicated to operations
on content objects and content metadata:
o Fetch metadata from uCDN or content from any origin server
including uCDN (preposition) ;
o Revalidate specific metadata or content before re-using it
(invalidate) ;
o Delete specific metadata or content purge.
The interface specified in the draft "CDN Interconnect triggers"
[I-D.murray-cdni-triggers] should not be part of the CDNI control
interface. The main raison is that the trigger interface itself need
to be bootstrapped (which is the role of the CDNI control interface).
There are also other reasons, including the following ones:
o Parameters needed to bootstrap a CDNI interface are static, while
trigger-based operations are dynamic ;
Stephan, et al. Expires May 10, 2013 [Page 6]
Internet-Draft CDNI Control Operations November 2012
o All trigger activities defined in [I-D.murray-cdni-triggers] are
specific to metadata ;
o The CDN entities for (i.e. the "extremities" of) the CDNI control
interface and for the CDNI trigger interface are not necessary the
same.
2.2. Bootstrapping of the other CDNI interfaces
When an upstream CDN operator wants to delegate to a downstream CDN
operator the handling of the content requests belonging to a given
set of class-of-requests, the uCDN and dCDN establish a Service
Agreement. The Service Agreement includes all information required
to set up the CDN interconnection. This Service Agreement can be
specified with a hierarchical datamodel, as depicted in Figure 1:
o A service agreement includes an identifier of uCDN, an identifier
of dCDN, one or several delivery services, and a set of control
parameters that apply to all these delivery services. For
example, let us consider a service agreement that includes two
delivery services: a former one corresponding to a Vod application
with "premium" delivery requirements, and a latter one
corresponding to a Vod application with "standard" delivery
requirements ;
o Each Delivery service associates one or several Class-of-requests
from the same CSP with a set of control parameters that apply to
all these Class-of-requests. To continue with the example
introduced just above, let us consider that the delivery service
corresponding to the Vod application with "premium" delivery
requirements include two different class-of-requests: a former one
corresponding to all the requests from end-users based in France
for http://*.cdn.example.com, and a latter one corresponding to
all the requests from end-users in France for
rtmp://*.cdn.example.com ;
o Each Class-of-requests identifies uniquely a set of requests with
a given footprint and specific properties. In the example
introduced just above, one of the considered class-of-request
corresponds to all the requests from end-users based in France for
http://*.cdn.example.com. And another one corresponds to all the
requests from end-users in France for rtmp://*.cdn.example.com ;
Stephan, et al. Expires May 10, 2013 [Page 7]
Internet-Draft CDNI Control Operations November 2012
+---------------------+
|Service Agreement |
| +----------------+ |
| |Delivery Service| | +----------------------+
| +----------------+ | |Delivery Service |
| |Delivery Service| | | +-----------------+ |
| +----------------+ | | |Class-of-requests| |
| +----------------+ | | +-----------------+ | +-----------------+
| |uCDN identifier | | | |Class-of-requests| | |Class-of requests|
| +----------------+ | | +-----------------+ | | +-----------+ |
| |dCDN identifier | | | |Class-of-requests| | | |footprint | |
| +----------------+ | | +-----------------+ | | +-----------+ |
| +----------------+ | | +-----------------+ | | +-----------+ |
| |Parameters | | | |Parameters | | | |properties | |
| +----------------+ | | +-----------------+ | | +-----------+ |
+---------------------+ +----------------------+ +-----------------+
Figure 1
Once a Service Agreeement is agreed between the operators of the CDNs
to be interconnected, the upstream CDN and the downstream CDN must be
configured for this CDNI interconnection according to the agreed
Service Agreement. Namely, CDNI Request Routing interface, CDNI
metadata interface, CDNI logging interface and CDNI "trigger"
interface must be bootstrapped according to the Service Agreeement.
3. CDNI Control Framework
The CDNI control operations can possibly be performed either manually
or via some automated network protocols; it means the CDNI control
interface can possibly be implemented manually or via some automated
network protocols. Moreover, only a part of these operations are
handled by the CDNI control interface. The other operations are
handled directly by the other CDNI interfaces (namely CDNI request
routing, CDNI metadata, CDNI logging, CDNI acquisition and CDNI
trigger interfaces).
As described in Figure 1, the scope of a Control Operation according
to a Control Parameter value may cover either all the Delivery
Services of a Service agreement or a single Delivery Service. As an
example, the configuration of the format of Logging records may apply
to a single Delivery Service. Furthermore, nothing precludes Control
Parameters associated to a set of Class-of-requests to change. For
instance, an uCDN could require the dCDN to use two Logging formats
for a given Delivery Service: one for the normal mode of operations
and one temporarily for debugging the CDN interconnection.
Stephan, et al. Expires May 10, 2013 [Page 8]
Internet-Draft CDNI Control Operations November 2012
3.1. CDNI Control Operations
The enforcement of a Service Agreeement requires the configuration of
each CDNI functional interface (i.e., including CDNI Metadata, CDNI
Logging and CDNI Request Routing).
The value of the Control Parameters is expected to change rarely for
a given Delivery Service. The core Control Operations are the
following:
1. The configuration of the CDNI interfaces ;
2. The removal of this configuration when it is not required anymore
(e.g., end of the scheduling of the considered Delivery Service).
We illustrate Control Operations on Figure 2. The two CDNs exchange
the control parameters previously agreed by the operators of the
CDNs. Then, each CDN uses these control parameters to configure all
the required CDNI interfaces appropriatly.
------------------------ ----------------------
/ uCDN \ / dCDN \
| +-------------------+ | | +-------------------+ |
| | Control | | | | Control | |
| | | | CDNI | | | |
| | Control | | Control | | Control | |
| | parameters <----------------------> parameters | |
| | | | | | | |
| +-------------------+ | | +-------------------+ |
\ / \ /
------------------------- -----------------------
Figure 2
Figure 1: Bootstrapping of CDNI Interfaces
3.2. Control Parameters
It is in the scope of the CDNI Control interface specification to
define the minimal set of Control Parameters required for
initializing each CDNI interface for a given Service Agreement.
Subsequent sections introduce the information to exchange through the
CDNI Control interface to initialize each CDNI interface for a given
Service Agreement, a given Delivery Service and a given Class-of-
request.
Stephan, et al. Expires May 10, 2013 [Page 9]
Internet-Draft CDNI Control Operations November 2012
3.2.1. Service Agreement level
This section introduces the information to exchange through the CDNI
Control interface to initialize each CDNI interface for a given
Service Agreement.
o Service Agreement identifier;
o uCDN identifier;
o dCDN identifier;
o List of Delivery Service identifier;
Section Section 3.2.2 introduces information to exchange
through the CDNI Control interface to initialize each CDNI
interface for a given Delivery Service
o Connectivity and security control parameters;
Section Section 3.2.1.1 lists information to exchange through
the CDNI Control interface to establish a secure connectivity
among CDNI entities.
o Redirection control parameters
Section Section 3.2.1.2 lists information to exchange through
the CDNI Control interface to redirect Class-of-requests of a
given Service Agreeement.
3.2.1.1. Connectivity and security control parameters
A CDNI Entity acts as the end point for a CDNI interface. A minimal
set of information must be exchanged via the control interface to
enable the connectivity and the security among CDNI entities.
As an example securing a CDNI logging interface using HTTPS requires
the exchange of certificates between the interconnected CDNs:
1. Certificate identifying dCDN's CDNI logging entity;
2. Certificate identifying uCDN's CDNI logging entity;
3. Certificate of the authority of certification;
A CDN having an CDNi entity (e.g. CDNI Logging data server, CDNI
acquisition server) protected by a firewall with strict access rules
must add the IP addresses of the entities of the other CDNs which are
Stephan, et al. Expires May 10, 2013 [Page 10]
Internet-Draft CDNI Control Operations November 2012
allowed to connect to this entity. As examples:
o When a uCDN has a dedicated CDNI acquisition server protected by a
firewall the dCDN must provide the uCDN with the addresses of each
dCDN content servers that could acquire content from this CDNI
acquisition server;
o When the CDNI Logging Server of a dCDN is protected by a firewall
the uCDN must provide the uCDN with the addresses of the uCDN
entities which might access to CDNI logging information on the
dCDN Logging server;
Subsequent sections give an overview of the security Control
Parameters related to each CDNI interface (CDNI Logging, CDNI Request
Routing, CDNI Metadata and CDNI Triggers)
3.2.1.1.1. Triggers
We list below the pieces of information required for the
bootstrapping of the triggers interface for a given Service
Agreement.
The CDNI trigger interface is a RESTful web service offered by dCDN,
according to the draft [I-D.murray-cdni-triggers]. The CDNI Control
interface must enable the communication of the following parameters
from dCDN to uCDN:
o the uri of the CDNI trigger entity within dCDN (i.e. of the server
within the dCDN dedicated to the CDNI trigger interface):
URI_dCDN_trigger_server;
o Certificate identifying dCDN;
o Certificate of the authority of certification;
According to the draft [I-D.murray-cdni-triggers], "The dCDN must
ensure that each uCDN only has access to its own Trigger Status
Resources and the dCDN must ensure that activity triggered by uCDN
only affects metadata or content originating from that uCDN".
Consequently, the CDNI Control interface must enable the dCDN to
authenticate the uCDN. This means the CDNI Control interface must
enable the communication of the following parameter from uCDN to
dCDN:
o Certificate identifying uCDN;
o Certificate of the authority of certification;
Stephan, et al. Expires May 10, 2013 [Page 11]
Internet-Draft CDNI Control Operations November 2012
3.2.1.1.2. CDNI Metadata
We list below the pieces of information required for the
bootstrapping of the CDNI Metadata interface for a given Service
Agreement.
According to the draft [I-D.ietf-cdni-metadata], 'If the URI for the
HostIndex object is not manually configured in the downstream CDN
then the HostIndex URI could be discovered via the CDNI Control
interface. An upstream CDN would provide the URI of the HostIndex
object to the downstream CDN via the CDNI Control Interface.'. In
this second case, the CDNI Control interface must enable the
communication of the following Control Parameters from uCDN to dCDN:
o the uri of the CDNI metadata entity within dCDN (i.e. of the
server within the dCDN dedicated to the CDNI metadata interface):
URI_uCDN_metadata_server;
o Certificate identifying uCDN metadata server;
o Certificate of the authority of certification;
According to the draft [I-D.ietf-cdni-metadata], 'If a malicious
metadata server is contacted by a downstream CDN, the malicious
server may provide metadata to the downstream CDN which denies
service for any piece of content to any user agent. The malicious
server may also provide metadata which directs a downstream CDN to a
malicious origin server instead of the actual origin server. A
malicious metadata client could request metadata for a piece of
content from an upstream CDN. The metadata information may then be
used to glean information regarding the uCDN or to contact an
upstream origin server. The uCDN is expected to authenticate client
requests to prevent this situation.' This means the CDNI Control
interface must enable the communication of the following parameter
from uCDN to dCDN:
o Certificate identifying dCDN metadata server;
o Certificate of the authority of certification;
3.2.1.1.3. CDNI Logging
We list below the pieces of information required for the
bootstrapping of the CDNI Logging interface for a given Service
Agreement.
o URI and protocol to use to request CDNI logging data;
Stephan, et al. Expires May 10, 2013 [Page 12]
Internet-Draft CDNI Control Operations November 2012
* URI_dCDN_logging_server;
* the protocol to use to exchange CDNI Logging data;
* etc.
o parameters securing the CDNI logging interface
3.2.1.1.4. CDNI Request Routing
We list below the pieces of information required for the
bootstrapping of the CDNI Request Routing interface for a given
Service Agreement.
o Control parameters securing the Request Routing CDNI interface
* Certificate identifying dCDN Request Routing/redirection CDNI
entity;
* Certificate identifying uCDN Request Routing/redirection CDNI
entity;
* Certificate identifying dCDN Request Routing/footprint CDNI
entity;
* Certificate identifying uCDN Request Routing/footprint CDNI
entity;
* Certificate of the authority of certification;
[Ed. note: this section will be updated once there will be an agreed
specification for the CDNI Request Routing interface within the CDNI
WG.]
3.2.1.2. Redirection parameters
This section lists the piece of information to exchange through the
CDNI Control interface to redirect Class-of-requests of the Service
Agreeement.
[Ed. note: this section will be updated once there will be an agreed
specification for the CDNI Request Routing interface within the CDNI
WG.]
3.2.2. Delivery Service Level
This section introduces the information to exchange through the CDNI
Control interface to initialize each CDNI interface for a given
Stephan, et al. Expires May 10, 2013 [Page 13]
Internet-Draft CDNI Control Operations November 2012
delivery Service.
o Delivery Service identifier;
o List of identifiers of class-of-requests ;
Section Section 3.2.3 introduces information to exchange
through the CDNI Control interface to initialize each CDNI
interface for a given Class-of-requests
o CDNI Logging parameters;
Section Section 3.2.2.1 lists information to exchange through
the CDNI Control interface to describe the CDNI logging data
for a given Delivey Service.
o CDNI Delivery requirement parameters
Section Section 3.2.2.2 lists information to exchange through
the CDNI Control interface to describe requirements for
handling class-of-requests of a given Delivey Service.
3.2.2.1. CDNI Logging parameters
This section lists a first set of information to exchange through the
CDNI Control interface to describe CDNI logging data for a given
Delivery Service:
o CDNI Logging data format,
o etc.
3.2.2.2. CDNI Delivery Requirements parameters
This section lists information to exchange through the CDNI Control
interface to describe requirements for handling class-of-requests of
a given Delivery Service.
[Ed. note: this section will be updated once there will be an
agreed specification for the CDNI Request Routing interface within
the CDNI WG.]
3.2.3. class-of-requests Level
This section introduces the information to exchange through the CDNI
Control interface to initialize each CDNI interface for a given
Class-of-request.
Stephan, et al. Expires May 10, 2013 [Page 14]
Internet-Draft CDNI Control Operations November 2012
o class-of-requests identifier;
o footprint;
[Ed. note: this section will be updated once there will be an
agreed specification for the CDNI Request Routing interface
within the CDNI WG.]
o Content request commun properties;
[Ed. note: this section will be updated once there will be an
agreed specification for the CDNI Request Routing interface
within the CDNI WG.]
4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
The bootstrapping and the configuration of the CDNI interfaces are
very sensible operations.
Any weakness may harm the CDN that is directly attacked, as well as
the CDNs interconnected with it. In addition it may endanger the
security of the eyeballs and of the distributed content.
6. References
6.1. Normative References
[I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-01 (work in
progress), July 2012.
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M.,
Leung, K., and K. Ma, "CDN Interconnect Metadata",
draft-ietf-cdni-metadata-00 (work in progress),
October 2012.
[I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements",
Stephan, et al. Expires May 10, 2013 [Page 15]
Internet-Draft CDNI Control Operations November 2012
draft-ietf-cdni-requirements-03 (work in progress),
June 2012.
[I-D.ietf-cdni-use-cases]
Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", draft-ietf-cdni-use-cases-10 (work in
progress), August 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012.
6.2. Informative References
[I-D.bertrand-cdni-logging]
Bertrand, G., Emile, S., Peterkofsky, R., Faucheur, F.,
and P. Grochocki, "CDNI Logging Interface",
draft-bertrand-cdni-logging-02 (work in progress),
October 2012.
[I-D.murray-cdni-triggers]
Murray, R. and B. Niven-Jenkins, "CDN Interconnect
Triggers", draft-murray-cdni-triggers-01 (work in
progress), August 2012.
Authors' Addresses
Emile Stephan
France Telecom - Orange
2 avenue Pierre Marzin
Lannion F-22307
France
Email: emile.stephan@orange.com
Stephan, et al. Expires May 10, 2013 [Page 16]
Internet-Draft CDNI Control Operations November 2012
Gilles Bertrand
France Telecom - Orange
38-40 rue du General Leclerc
Issy les Moulineaux, 92130
France
Phone: +33 1 45 29 89 46
Email: gilles.bertrand@orange.com
Anne Marrec
France Telecom - Orange
2 avenue Pierre Marzin
Lannion, 22307
France
Phone: +33 2 96 05 18 71
Email: anne.marrec@orange.com
Yannick Le Louedec
France Telecom - Orange
2 avenue Pierre Marzin
Lannion, 22307
France
Phone: +33 2 96 05 17 64
Email: yannick.lelouedec@orange.com
Stephan, et al. Expires May 10, 2013 [Page 17]
