Multicast Considerations in Support of CDN-I
draft-tarapore-mboned-multicast-cdni-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Percy Tarapore , Robert Sayko , Ramki Krishnan | ||
| Last updated | 2012-07-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tarapore-mboned-multicast-cdni-00
MBONED Working Group Percy S. Tarapore
Internet Draft Robert Sayko
Intended status: BCP AT&T
Expires: January 9, 2013 Ram Krishnan
Brocade
July 9, 2012
Multicast Considerations in Support of CDN-I
draft-tarapore-mboned-multicast-cdni-00.txt
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 9, 2012.
Copyright Notice
Copyright (c) 2012 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
Tarapore, et al Expires January 9, 2013 [Page 1]
Internet-Draft Multicast Considerations in Support of CDN-I July 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
This document examines the current capabilities of multicast to
support content distribution in an environment involving multiple
Service Providers joining together to form a Content Distribution
Network Interconnection (CDN-I) Federation.
Table of Contents
1. Introduction...................................................2
2. CDN Nomenclature...............................................3
3. Multicast Use Cases for a CDN-I Federation.....................4
3.1. Native Multicast Use Case.................................5
3.2. Automatic Multicast Tunneling Use Cases...................5
3.2.1. AMT Interconnection Between P-CDN and S-CDN..........6
3.2.2. AMT Tunnel Connecting S-CDN and EU...................7
3.2.3. AMT Tunnel Connecting EU to P-CDN Through Non-Multicast
S-CDN.......................................................7
4. Content Types Suitable for Multicast-based CDN.................8
4.1. Live Content..............................................8
4.2. "Delayed-Play" Download...................................8
4.3. "Instant-Play" Download...................................8
5. Evaluation of Native Multicast for CDN.........................9
6. Evaluation of AMT for CDN......................................9
7. Security Considerations.......................................10
8. IANA Considerations...........................................10
TBD..............................................................10
9. Conclusions...................................................10
10. References...................................................11
10.1. Normative References....................................11
10.2. Informative References..................................11
11. Acknowledgments..............................................11
1. Introduction
Content Providers (CP) are experiencing significant growth in demand
for all types of internet-based content. A single "over-the-top" CP
would require significant resources to deliver content that could be
requested from anywhere in the world. Service Providers (SP) are
taking advantage of this situation by forming Content Distribution
Network (CDN) Federations for the purpose of distributing content on
behalf of Content Providers (CP). There are several advantages to
such CDN Federations:
Tarapore, et al Expires January 9, 2013 [Page 2]
Internet-Draft Multicast Considerations in Support of CDN-I July 2012
o CPs can simply contract with one or more SPs in a CDN Federation
for delivery of their content. This enables CPs to concentrate on
their main objective - creation of content.
o SPs can expand their geographic reach via distribution agreements
with Federation members without developing costly resources
outside their local territories.
Multicast-based delivery mechanisms are a natural fit for content
distribution in the proposed CDN Federations. The scope of this
document is strictly focused on the interactions between CDN
Federation members to support multicast-based content distribution.
The purpose of this document is the detailed examination of
applicable multicast techniques and the identification of detailed
data/metadata/parameters that will have to be exchanged by CDN
Federation members to enable multicast-based content distribution.
2. CDN Nomenclature
Terminology utilized to describe end-to-end user requests is
described as follows.
There are many entities involved in distribution of the content from
the CP all the way to the End User (EU). Figure 1 is a diagram
depicting the basic logical relationships among the various roles
involved in content delivery. Besides the CP and EU, the two
remaining major entities are the two members of a CDN Federation -
the Primary CDN Provider (P-CDN) and the Supporting CDN Provider (S-
CDN) [A-0200003]. The relationships between these entities are as
follows - see Figure 1.
1. The Content Provider owns the content and specifies conditions of
delivery and use. The End User interacts with the CP (link 1 in
the figure) for authentication and authorization, and to reach an
agreement to obtain specific content (content selection, content
purchase, acknowledgement of conditions of use). The CP has the
legal right to distribute content and specify conditions for
distribution.
2. The CP has an agreement and interacts with the P-CDN for deploying
content (link 2).
3. The P-CDN in turn has an agreement with an S-CDN for deploying and
distributing content (link 3).
Tarapore, et al Expires January 9, 2013 [Page 3]
Internet-Draft Multicast Considerations in Support of CDN-I July 2012
4. The End User is attached to S-CDN for access and obtains the
content from the S-CDN (link 4). The End User also interacts with
the CP (link 1) as indicated above.
-----------------------------------------------
| (1) |
v |
+---------+ +---------+ +---------+ +---------+
| | | | | | | |
| Content | | Primary | | Suppor- | | End |
| Provider| --> | CDN | --> | -ting | --> | User |
| | (2) | | (3) | CDN | (4) | |
| | | | | | | |
+---------+ +---------+ +---------+ +---------+
Figure 1 - Relationships in a CDN Federation
Note that all SPs in the CDN Federation can play the role of P-CDN
(active relationship with a CP) as well as an S-CDN (attach EUs and
distribute content from P-CDN to EUs).
3. Multicast Use Cases for a CDN-I Federation
Use cases involving multicast methods for distributing content in a
CDN Federation have been described in [A-0200004].
Tarapore, et al Expires January 9, 2013 [Page 4]
Internet-Draft Multicast Considerations in Support of CDN-I July 2012
3.1. Native Multicast Use Case
------------------- -------------------
/ P-CDN \ / S-CDN \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ | | |
| | | +------+ | | +------+ | +----+
| | CS |------>| BR |-|---------|->| BR |-------------|--->| EU |
| | | +------+ | I1 | +------+ | I2 +----+
\ +----+ / \ /
\ / \ /
\ / \ /
------------------- -------------------
CS = Content Server
BR = Border Router
I1 = P-CDN and S-CDN Multicast Interconnection (MBGP or BGMP)
I2 = S-CDN and EU Multicast Connection
Figure 1 - Content Distribution via End to End Native Multicast
This case assumes that both CDN Providers as well as the
interconnection between them and the connection between the EU and S-
CDN are all multicast enabled.
A variation of this "pure" Native Multicast case is when the
interconnection I1 between the CDNs is multicast enabled via a
Generic Routing Encapsulation Tunnel (GRE) [RFC2784] instead of
utilizing MBGP or BGMP protocols.
3.2. Automatic Multicast Tunneling Use Cases
In reality, the initial introduction of multicast may not be fully
multicast enabled resulting in "Multicast Islands" requiring
Automatic Multicast Tunnels (AMT) for enabling multicast connections
between them [IETF-ID-AMT].
Tarapore, et al Expires January 9, 2013 [Page 5]
Internet-Draft Multicast Considerations in Support of CDN-I July 2012
3.2.1. AMT Interconnection Between P-CDN and S-CDN
------------------- -------------------
/ P-CDN \ / S-CDN \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ | | |
| | | +------+ | | +------+ | +----+
| | CS |------>| AR |-|---------|->| AG |-------------|--->| EU |
| | | +------+ | I1 | +------+ | I2 +----+
\ +----+ / \ /
\ / \ /
\ / \ /
------------------- -------------------
AR = AMT Relay
AG = AMT Gateway
I1 = AMT Interconnection between P-CDN and S-CDN
I2 = S-CDN and EU Multicast Connection
Figure 3 - AMT Interconnection between P-CDN and S-CDN
This configuration assumes both CDN Providers are multicast enabled.
Only the interconnection between them is not multicast enabled and
hence, an AMT tunnel is established between them as shown in Figure
3.
Tarapore, et al Expires January 9, 2013 [Page 6]
Internet-Draft Multicast Considerations in Support of CDN-I July 2012
3.2.2. AMT Tunnel Connecting S-CDN and EU
------------------- -------------------
/ P-CDN \ / S-CDN \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ | | |
| | | +------+ | | +------+ +------+ | +----+
| | CS |------>| BR |-|---------|->| BR |--->| AR |-|--->| EU |
| | | +------+ | I1 | +------+ +------+ | I2 +----+
\ +----+ / \ /
\ / \ /
\ / \ /
------------------- -------------------
CS = Content Server
BR = Border Router
AR = AMT Relay
I1 = P-CDN and S-CDN Multicast Interconnection (MBGP or BGMP)
I2 = AMT Connection between S-CDN and EU
Figure 4 - AMT Tunnel Connecting S-CDN and EU
This case involves EU devices that are not multicast enabled. Hence
an AMT Tunnel is established between the S-CDN AMT Relay and the EU
device. This implies one tunnel per EU - potentially several AMT
tunnels may need to be setup.
Note that there could be configurations involving both situations
described in 3.2.1 and 3.2.2.
3.2.3. AMT Tunnel Connecting EU to P-CDN Through Non-Multicast S-CDN
This Use Case assumes that EU attached to the non-multicast enabled
S-CDN has a device populated with a client that establishes an AMT
tunnel to the AMT Relay in the P-CDN.
This configuration is needed when the S-CDN is not multicast-enabled.
This is the most "extreme" AMT case as the length of the tunnels as
well as the number of tunnels can be large.
Tarapore, et al Expires January 9, 2013 [Page 7]
Internet-Draft Multicast Considerations in Support of CDN-I July 2012
------------------- -------------------
/ P-CDN \ / S-CDN \
/ (Multicast Enabled) \ / (Non-Multicast \
/ \ / Enabled) \
| +----+ | | |
| | | +------+ | | | +----+
| | CS |------>| AR |-|---------|-----------------------|--->| EU |
| | | +------+ | | | I2 +----+
\ +----+ / \ /
\ / \ /
\ / \ /
------------------- -------------------
CS = Content Source
AR = AMT Relay
I2 = AMT Tunnel Connecting EU to P-CDN Relay through Non-Multicast
Enabled S-CDN.
Figure 5 - AMT Tunnel Connecting P-CDN AMT Relay and EU
4. Content Types Suitable for Multicast-based CDN
This section highlights applications and content types that are
suitable for multicast-based delivery in a CDN Federation. Any unique
aspects of specific applications/content types that require special
attention are duly noted.
4.1. Live Content
Live events and presentations such as live radio an sporting events
are examples. Delivery is via simple multicast means.
Additional detail TBD
4.2. "Delayed-Play" Download
This includes download of movies and software updates. Delivery is
via repeated multicasting of content.
Additional detail TBD
4.3. "Instant-Play" Download
This includes Video-on-Demand (VoD) and on-demand streaming. Delivery
is via simultaneous repeated multicast of content segments.
Tarapore, et al Expires January 9, 2013 [Page 8]
Internet-Draft Multicast Considerations in Support of CDN-I July 2012
Additional detail TBD
5. Evaluation of Native Multicast for CDN
Use Case 3.1 describes Native Multicast configurations. This is the
"simplest" multicast case in that a single standard set of protocols
supports end-to-end content delivery from the CP to EU via two or
more fully multicast-enabled CDN Providers. It also provides for
efficient use of bandwidth and resources.
Use Case 2a does deploy an AMT Tunnel for interconnecting two CDN
Providers; the rest of the configuration is Native Multicast - this
assumes that the EU devices are also multicast-enabled.
Thus existing Native Multicast capabilities need to be examined to
determine their ability to fully support content distribution in a
CDN Federation. A list of issues requiring examination is as follows:
o Delivery - Identification and communication of {Source, Group}
information and DNS information for provisioning across CDNs.
Details to be provided.
o Routing/Peering - Identification and acknowledgement of external
IP addresses particularly when utilizing a GRE Tunnel for
interconnecting CDNs. Details to be provided.
o Back-Office Functions - Identification of appropriate
data/metadata collected by Native Multicast to support usage of
content for billing, settlements, logging, etc. Details to be
provided.
o Security - Determine ability of Native Multicast to deal with
security risks such as bot attacks, denial of service, etc.
Details to be provided.
o Others - To Be Determined
6. Evaluation of AMT for CDN
Use Cases 3.2.1, 3.2.2, and 3.2.3 describe the possible
configurations involving AMT Tunnels. The likeliest scenario is a
combination of Use Cases 3.2.1 and 3.2.2.
Tarapore, et al Expires January 9, 2013 [Page 9]
Internet-Draft Multicast Considerations in Support of CDN-I July 2012
Use Case 3.2.3 becomes problematic if the length of the AMT Tunnels
connecting the EUs to the P-CDN AMT Gateway become prohibitively
long.
In all cases, there may be a concern if the total number of AMT
Tunnels required is large. The list of issues that need to be
examined for the AMT scenarios to support content distribution in a
CDN Federation includes all identified issues in the Native Multicast
case:
o Delivery - Identification and communication of {Source, Group}
information and DNS information for provisioning across CDNs.
Details to be provided.
o Routing/Peering - Identification and acknowledgement of external
IP addresses when utilizing AMT Tunnels for interconnecting CDNs.
Details to be provided.
o Back-Office Functions - Identification of appropriate
data/metadata collected via AMT to support usage of content for
billing, settlements, logging, etc. Details to be provided.
o Security - Determine ability of AMT to deal with security risks
such as bot attacks, denial of service, etc. Details to be
provided.
o Others - To Be Determined
These have to be separately investigated for the AMT cases.
In addition, there may be a need to examine the scope of additional
resources in terms of bandwidth capacity and additional network
elements particularly for Use Cases 3.2.2 and 3.2.3.
7. Security Considerations
TBD
8. IANA Considerations
TBD
9. Conclusions
TBD
Tarapore, et al Expires January 9, 2013 [Page 10]
Internet-Draft Multicast Considerations in Support of CDN-I July 2012
10. References
10.1. Normative References
[RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000
[IETF-ID-AMT] G. Bumgardner, "Automatic Multicast Tunneling", draft-
ietf-mboned-auto-multicast-13, April 2012, Work in progress
10.2. Informative References
[A-0200003] P. Tarapore, "CDN Interconnection Use Case Specifications
and High Level Requirements", ATIS Standard A-0200003, June 2011
(contact Nicole Butler at nbutler@atis.org using code IETF12 to
receive a free copy before September 30, 2012)
[A-0200004] P. Tarapore and R. Sayko, "CDN Interconnection Use Cases
and Requirements for Multicast-Based Content Distribution", ATIS
Standard A-0200004, January 2012 (contact Nicole Butler at
nbutler@atis.org using code IETF12 to receive a free copy before
September 30, 2012)
11. Acknowledgments
Tarapore, et al Expires January 9, 2013 [Page 11]
Internet-Draft Multicast Considerations in Support of CDN-I July 2012
Authors' Addresses
Percy S. Tarapore
AT&T
Phone: 1-732-420-4172
Email: tarapore@att.com
Robert Sayko
AT&T
Phone: 1-732-420-3292
Email: rs1983@att.com
Ram Krishnan
Brocade
Phone:
Email: ramk@brocade.com
Tarapore, et al Expires January 9, 2013 [Page 12]