[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-cdni-use-cases

Network Working Group                                          G. Watson
Internet-Draft                                                        BT
Intended status: Experimental                            January 6, 2011
Expires: July 10, 2011


                       CDN Interconnect Use Cases
                     draft-watson-cdni-use-cases-00

Abstract

   [draft-jenkins-cdni-problem-statement] outlines the problem space for
   CDN Interconnection within the IETF.  This documents provides a
   complimentary set of technical use cases for how CDNs may be
   interconnected.  The goal of this document is to outline real world
   use-cases for CDN Interconnect, for the IETF, with the intention of
   supporting the case for formation of a Working Group which would work
   on the definition of standardised, interoperable methods of
   Interconnecting CDNs.  The goal of this document is NOT to define the
   technical solutions to be used.

   The intent of this document is to outline a set of technical use
   cases.  While the technical use cases may be influenced by business-
   related and other non-technical factors, this document does not
   attempt to detail any non-technical aspects of CDN Interconnect.

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 July 10, 2011.



Watson                    Expires July 10, 2011                 [Page 1]


Internet-Draft         CDN Interconnect Use Cases           January 2011


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Single CDN . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Base Use Case for CDN Interconnection  . . . . . . . . . . . .  6
   5.  Intermediate CDNs  . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Other user cases . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10






















Watson                    Expires July 10, 2011                 [Page 2]


Internet-Draft         CDN Interconnect Use Cases           January 2011


1.  Introduction

   There are many possible combinations for the relationships between
   the different parties (Network Service Provider (NSP), CDN Provider,
   Content Service Provider (CSP), etc.) involved in end to end content
   delivery.  However, in the context of interconnecting CDNs the key
   relationships are:

   o  How the CSP interacts with the CDN to publish and deliver content.

   o  How the End User interacts with the interconnected CDNs to request
      and receive content.

   o  How the different CDNs interact with one another to deliver the
      CSP's content to the End User.

   The role of the NSP in the end to end content delivery is excluded
   above because although some NSPs may also have their own CDN which
   may be interconnected with other CDNs (that may or may not have
   direct relationships with an ISP or ISPs), the existence of such
   NSP<->CDN relationships does not affect the information that needs to
   be exchanged across a CDN Interconnect and therefore these NSP<->CDN
   relationships do not need to be specifically called out within the
   use cases.  In other words no NSP-specific information needs to be
   exchanged across a CDN Interconnect.

   Therefore this document will use NSPs to highlight that sets of End
   Users may be attached to different ISP networks but it does not imply
   or exclude any further relationship between the NSP and the CDN.

   Equally, the type of CDNs (e.g.  NSP operated, Over The Top, global
   footprint, regional footprint, etc.) that interact over a CDN
   Interconnect do not need to be explicitly called out within the use
   cases.  Again this is because the type of CDN that exists on either
   side on a CDN Interconnect does not place an specific "CDN type"
   related requirements on the information that needs to be exchanged
   across the interconnect.

   Therefore this document will refer to CDNs in a generic fashion where
   it is meant that any reference to a CDN could refer to any type of
   deployment and operational model for a CDN including both NSP
   operated and Over-the-top CDNs, CDNs that partner with NSPs and those
   that do not, etc.

   In the sections that follow a number of CDN Interconnection use cases
   are described along with an set of interactions between the main
   Actors.  The interactions described are illustrative in order to
   highlight the main touchpoints and interactions, in a number of



Watson                    Expires July 10, 2011                 [Page 3]


Internet-Draft         CDN Interconnect Use Cases           January 2011


   places various details may be glossed over or omitted in order to
   avoid complicating the use case description with layers of detail
   that is not directly relevant to the use case.  For example the use
   cases do not go into detail of how a User Agent is redirected to a
   Surrogate to avoid detailing the details and nuances of DNS versus
   application level redirection.


2.  Terminology

   This document uses terms defined in
   [draft-jenkins-cdni-problem-statement]

   The following additional terms are used:

   Authoritative CDN: A CDN that maintains a direct business
   relationship with a CSP for the delivery of the CSP's Content.

   Request Router: The function responsible for steering or directing a
   Content Request received directly from a User Agent (or received from
   another CDN via a CDNI) to a suitable Surrogate (or alternative CDN).

   Surrogate: A device/function that interacts with other elements of
   the CDN for the control and distribution of Content within the CDN
   and interacts with User Agents for the delivery of the Content.

   End User (EU): The 'real' user of the system, typically a human but
   maybe some combination of hardware and/or software emulating a human
   (e.g. for automated quality monitoring etc.).

   User Agent (UA): Software (or a combination of hardware and software)
   through which the User interacts with the Content Service.  The User
   Agent will communicate with the CSP's Service for the selection of
   content and one or more CDNs for the delivery of the Content.  Such
   communication is not restricted to HTTP and may be via a variety of
   protocols.  Examples of User Agents (non-exhaustive) are: Browsers,
   Set Top Boxes (STB), Dedicated content applications (e.g. media
   players), etc.


3.  Single CDN

   This section outlines an illustrative model for content delivery via
   a single CDN where there is no interconnection with other CDNs.  It
   does not describe all the details and variations but rather the high
   level interactions between the different Actors (CSP, CDN, End User)
   which can be used as a point of comparison with the CDN
   Interconnection use cases described in subsequent sections.



Watson                    Expires July 10, 2011                 [Page 4]


Internet-Draft         CDN Interconnect Use Cases           January 2011


                    +-------+
                    | CSP-1 |
                    +-------+
                        |
                   ,---------.
                ,-'           `-.
               (      CDN-A      )
                `-.           ,-'
                   `---------'
                        |
                   ,---------.
                ,-'    0 or   `-.
               (    more other   )
                `-.  networks ,-'
               /   `---------'  \
              /                  \
       ,---------.            ,---------.
    ,-'           `-.      ,-'           `-.
   (      NSP-X      )    (      NSP-Y      )
    `-.           ,-'      `-.           ,-'
       `---------'            `---------'
            |                      |
        +-------+              +-------+
        | UA-X  |              | UA-Y  |
        +-------+              +-------+



                            Single CDN Use Case

   As shown in the diagram CSP-1 maintains a direct relationship with
   CDN-A and CDN-A delivers content to User Agents attached to NSP-X and
   NSP-Y.  NSP-X and NSP-Y may or may not have a relationship with CDN-A
   and traffic from CDN-A may traverse one or more other networks before
   reaching NSP-X or NSP-Y.

   In order for UA-X to receive content the following illustrative
   interactions occur:

   1.  UA-X selects a piece of Content (as directed by an End User) from
       CSP-1's service (e.g. through a portal or EPG).

   2.  CSP-1 returns a URL for the selected content which resolve to the
       Request Router in CDN-A.

   3.  CDN-A's Request Router will select an appropriate Surrogate
       (Cache) and redirect UA-X to the selected Surrogate in CDN-A.




Watson                    Expires July 10, 2011                 [Page 5]


Internet-Draft         CDN Interconnect Use Cases           January 2011


   4.  UA-X will connect to the selected Surrogate and request the
       Content.


4.  Base Use Case for CDN Interconnection

   This section describes the base use case for CDN Interconnection on
   which the other use cases described in subsequent sections are built
   upon.

   "CSPs have a desire to be able to get (some of their) content to very
   large number of users and/or over many/all geographies and/or with a
   high quality of experience, all without having to maintain direct
   business relationships with many different CDN providers"
   [draft-jenkins-cdni-problem-statement].  In order to minimise the
   number of direct business relationships between a CSP and a set of
   interconnected CDNs, it is assumed that a CSP will only be required/
   desire to have a direct relationship with a single CDN.  The single
   CDN selected by the CSP is referred to as "The Authoritative CDN" in
   this document.  When receiving requests from User Agents, the
   Authoritative CDN will select an appropriate Surrogate in its own CDN
   or will decide to delegate the delivery to another CDN that the
   Authoritative CDN is interconnected with.

   Although the Authoritative CDN makes the decision, that decision may
   be influenced by policies configured by the CDN Operator(s) or the
   CSP, e.g. "geo-blocking" rules that specify the geographic regions
   where content can be delivered from (i.e. the location of the
   Surrogates) and geographic locations where content can be delivered
   to (i.e. the location of the End Users) or based on prior
   notification of CDN capacity/availability from its own CDN surrogates
   or interconnected CDN surrogates.

   There is a large and diverse range of client software and devices
   (referred to as User Agents in this document) used to access CSP
   content via a CDN.  It is assumed that content delivery through a set
   of interconnected CDNs should not require any changes to existing
   User Agents.

   Taking the above two assumptions into account the base use case for
   CDN Interconnection is shown in the diagram below.  To simplify the
   diagram the cloud showing "zero or more other networks" has been
   excluded and NSPs are shown as though they are directly attached to
   CDNs.  This is not intended to imply any direct relationships or to
   exclude the case where one or more networks may exist between the NSP
   illustrated and the CDN.





Watson                    Expires July 10, 2011                 [Page 6]


Internet-Draft         CDN Interconnect Use Cases           January 2011


        +-------+
        | CSP-1 |
        +-------+
            |
       ,---------.            ,---------.
    ,-'           `-.      ,-'           `-.
   (      CDN-A      )==I==(      CDN-B     )
    `-.           ,-'     /`-.           ,-'
       `---------'       /    `---------'
            |        ___/          |
            |       /              |
       ,---------. /          ,---------.
    ,-'           `-.      ,-'           `-.
   (      NSP-X      )    (      NSP-Y      )
    `-.           ,-'      `-.           ,-'
       `---------'            `---------'
            |                      |
        +-------+              +-------+
        | UA-X  |              | UA-Y  |
        +-------+              +-------+

   ==I== CDN Interconnect


                   Base Use Case for CDN Interconnection

   As shown in the diagram CSP-1 maintains a direct relationship with
   CDN-A and so CDN-A is The Authoritative CDN for CSP-1.

   CDN-A maintains a CDN Interconnect with CDN-B.

   CDN-A may decide to delegate the delivery of contentto a UA/NSP to
   CDN-B.  How CDN-A makes such a decision is out of scope for this
   document but some example scenarios include:

   a.  CDN-A has run out of capacity and so decides to use CDN-B to
       handle the overspill rather than deny UA content requests from
       NSP-X.

   b.  CDN-A may not have good coverage of the geographical region NSP-Y
       resides in and so prefers to CDN-B to deliver content to that
       region.

   Let us assume that EU-Y wishes to use CSP-1's service and that CDN-A
   decides to delegate the delivery of the content to CDN-B and that
   CDN-B is willing to perform the delegated delivery.  In order for
   EU-Y to receive content the following illustrative interactions
   occur:



Watson                    Expires July 10, 2011                 [Page 7]


Internet-Draft         CDN Interconnect Use Cases           January 2011


   1.  UA-Y selects a piece of content (as directed by EU-Y) from
       CSP-1's service (e.g. through a portal or EPG).

   2.  CSP-1 returns a URL for the selected content which resolve to the
       Request Router in CDN-A, The Authoritative CDN for CSP-1.

   3.  CDN-A's Request Router makes a decision to delegate the delivery
       to CDN-B.

   4.  CDN-A makes a request to CDN-B to deliver the content on behalf
       of CDN-A and CDN-B responds with details of how CDN-A's Request
       Router should respond to the request.

   5.  CDN-A's Request Router returns the appropriate response to UA-Y.

   6.  UA-Y will connect to CDN-B and request the content.  Depending on
       what CDN-B has returned to CDN-A earlier UA-Y may have connected
       directly to a cache in CDN-B or may have connected to CDN-B's
       Request Router where CDN-B's Request Router will select an
       appropriate Surrogate (or possibly another CDN) and redirect UA-Y
       to the selected Surrogate in CDN-B.

   [Ed: There are a potentially couple of options, the above and the
   option to hand off to CDN-B without making a request first.  Consider
   describing that as an option also?  For example in the case of
   intermediate CDN you might want to hand-off immediately to CDN-C
   rather than relying on various requests flowing from A to B to C and
   back.]


5.  Intermediate CDNs

   This use case extends the base use case by allowing CDN-B to accept a
   delegated content delivery from CDN-A and then delegate the delivery
   to CDN-C.
















Watson                    Expires July 10, 2011                 [Page 8]


Internet-Draft         CDN Interconnect Use Cases           January 2011


        +-------+
        | CSP-1 |
        +-------+
            |
       ,---------.            ,---------.            ,---------.
    ,-'           `-.      ,-'           `-.      ,-'           `-.
   (      CDN-A      )====(      CDN-B      )====(      CDN-B      )
    `-.           ,-'      `-.           ,-'      `-.           ,-'
       `---------'            `---------'            `---------'
                                                          |
                                                          |
                                                     ,---------.
                                                  ,-'           `-.
                                                 (      NSP-Z      )
                                                  `-.           ,-'
                                                     `---------'
                                                          |
                                                      +-------+
                                                      | UA-Z  |
                                                      +-------+

   ==== CDN Interconnect


                        Intermediate CDNs use case


6.  Other user cases

   [Ed: Needs expansion, currently just a placeholer for ideas]

   Acquisition flow (via upstream CDNs and direct to CSP Origin)

   Accounting flow.


7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


8.  Security Considerations

   [Ed: TBD]




Watson                    Expires July 10, 2011                 [Page 9]


Internet-Draft         CDN Interconnect Use Cases           January 2011


9.  Acknowledgements

   Thanks to Ben Niven-Jenkins for some valuable discussions and
   suggestions.


10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [draft-jenkins-cdni-problem-statement]
              Niven-Jenkins, B., "Content Distribution Network
              Interconnection (CDNI) Problem Statement", 2010.


Author's Address

   Grant Watson
   BT


   Email: grant.watson@bt.com




























Watson                    Expires July 10, 2011                [Page 10]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/