ATIS 0200004-2012 CDN Interconnection Use Cases and Requirements for Multicast-Based Content Distribution.pdf

1、 TECHNICAL REPORT ATIS-0200004 CDN INTERCONNECTION USE CASES AND REQUIREMENTS FOR MULTICAST-BASED CONTENT DISTRIBUTION ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainmen

2、t and communications industry. More than 200 companies actively formulate standards in ATIS Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platf

3、orms and Emerging Networks. In addition, numerous Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Connected Vehicle, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational

4、 Partner for the 3rd Generation Partnership Project (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited by the American Nationa

5、l Standards Institute (ANSI). For more information, please visit . Notice of Disclaimer multicast has to be turned on end-to-end in every layer 3 device between the source and the recipient to function. With the Internet, many local service providers and customer equipment (e.g., home routers) are n

6、ot multicast-enabled. Since multicast is not ubiquitous, IETF defined an interim solution ietf-id-AMT, called Automatic IP Multicast Tunneling (AMT)6. AMT multicast provides a way to simply connect together multicast islands and ease the transition to ubiquitous multicast deployment without requirin

7、g wide-scale changes. It is a hybrid solution that allows a multicast-enabled host (e.g., the multicast-enabled media player) connected to a unicast network with no native multicast support to exchange Source Specific Multicast (SSM) traffic with a native multicast infrastructure without the need fo

8、r any explicit tunnels between the receiver and the source. AMT uses an encapsulation interface so that no changes to a host stack or applications are required because AMT is agnostic to higher level protocols. Table 1: Multicast Terminology Term Definition (Source, Group) (S, G) Multicast address n

9、otation is in the format of addresses that indicate the multicast group and its source of information. Source (S) is the source IP address. With this service, it is the Multicast Media Server. Group (G) is the multicast IP address. The group IP address may be reused for different sources. In essence

10、, devices in a multicast group listen for (share) a single address that identifies a multicast session. The Multicast address can be dynamically assigned for a specific multicast session. This algorithm enables packets to be forwarded to only members of the group. Anycasting Anycast is a network add

11、ressing and routing scheme whereby data is routed to the “nearest“ or “best“ destination as viewed by the routing topology. With anycast, each destination address identifies a set of receiver endpoints, but only one of them is chosen at any given time to receive information from any given sender. BG

12、P is used to simultaneously announce the same destination IP address from many different routers. Thisresults in packets addressed to the destination address being routed to the “nearest” point on the network announcing the given destination IP address. External Border Gateway Protocol (eBGP) Extern

13、al Border Gateway Protocol (eBGP) is the protocol used to transport information to other BGP enabled systems in different autonomous systems (AS). Border Gateway Multicast Protocol (BGMP) The Border Gateway Multicast Protocol (BGMP) is an on-going IETF project that is attempting to design a true int

14、er-domain multicast routing protocol. BGMP should be able to scale in order to operate in the global Internet RFC3913. 6The IETF specification can be found at . An earlier version of this Internet Draft was titled Automatic IP Multicast Without Explicit Tunnels. ATIS-0200004 5 Term Definition Multic

15、ast Extensions for BGP (MBGP) Multiprotocol Extensions for BGP (MBGP), sometimes referred to as Multiprotocol BGP or Multicast BGP and defined in RFC4760, is an extension to Border Gateway Protocol that allows different types of addresses (known as address families) to be distributed in parallel. Wh

16、ereas standard BGP supports only IPv4 unicast addresses, Multiprotocol BGP supports IPv4 and IPv6 addresses and it supports unicast and multicast variants of each. Multiprotocol BGP allows information about the topology of IP Multicast-capable routers to be exchanged separately from the topology of

17、normal IPv4 unicast routers. Thus, it allows a multicast routing topology different from the unicast routing topology. Although MBGP enables the exchange of inter-domain multicast routing information, other protocols such as the Protocol Independent Multicast family are needed to build trees and for

18、ward multicast traffic. Multicast Multicast is a method of transmitting data across a network that allows many clients to receive the same data stream. This minimizes the amount of bandwidth required to transmit the data to a group of network clients. Multicast transmission requires that the routers

19、 and switches on the network be multicast-enabled, which means that they can transmit class-D IP addresses and interpret multicast information packets. Source-Specific Multicast (SSM) Source-specific multicast (SSM) is used by hosts (e.g., PC) to receive data from one particular source only. With SS

20、M, a host identifies a multicast data stream with a source and group address pair (S, G), rather than by group address alone as with Any Source Multicast (ASM). SSM is useful in applications like video broadcasting where there is one source. Protocol-Independent Multicast Protocol-Independent Multic

21、ast (PIM) is a family of multicast routing protocols for Internet Protocol (IP) networks that provide one-to-many and many-to-many distribution of data over a LAN, WAN or the Internet. It is termed protocol-independent because PIM does not include its own topology discovery mechanism, but instead us

22、es routing information supplied by other traditional routing protocols such as the Border Gateway Protocol (BGP). There are four variants of PIM: PIM Sparse Mode (PIM-SM) explicitly builds unidirectional shared trees rooted at a rendezvous point (RP) per group, and optionally creates shortest-path t

23、rees per source. PIM-SM generally scales fairly well for wide-area usage RFC4601. PIM Dense Mode (PIM-DM) uses dense multicast routing. It implicitly builds shortest-path trees by flooding multicast traffic domain-wide, and then pruning back branches of the tree where no receivers are present. PIM-D

24、M is straightforward to implement but generally has poor scaling properties. The first multicast routing protocol, DVMRP, used dense-mode multicast routing RFC3973. Bidirectional PIM explicitly builds shared bi-directional trees. It never builds a shortest path tree, so may have longer end-to-end de

25、lays than PIM-SM, but scales well because it needs no source-specific state RFC5015. PIM source-specific multicast (PIM-SSM) builds trees that are rooted in just one source, offering a more secure and scalable model for a limited amount of applications (mostly broadcasting of content). In SSM, an IP

26、 datagram is transmitted by a source S to an SSM destination address G, and receivers can receive this datagram by subscribing to channel (S,G) RFC3569. Internet Group Management Protocol (IGMP) Internet Group Management Protocol (IGMP) is a multicast group membership/management discovery protocol w

27、hich allows recipients to directly connect and disconnect to the source of a multicast session. Multicast Listener Discovery (MLD ) Just like IGMP in IPv4, the purpose of this protocol is to enable each IPv6 router to discover the presence of multicast listeners on its directly attached links and to

28、 determine specifically which multicast addresses are of interest to those nodes. Generic Routing Encapsulation (GRE) Defined by RFC2784, Generic Routing Encapsulation (GRE)is a simple IP packet encapsulation protocol. A GRE tunnel is used when IP packets need to be sent from one network to another,

29、 without being parsed or treated like IP packets by any intervening routers. GRE tunnels are designed to be completely stateless. This means that each tunnel end-point does not keep any information about the state or availability of the remote tunnel end-point. Normally, a GRE tunnel interface comes

30、 up as soon as it is configured and it stays up as long as there is a valid tunnel source address or interface which is up. The tunnel destination IP address must also be routable, which is true even if the other side of the tunnel has not been configured. This means that a static route or Policy Ba

31、sed Routing (PBR) forwarding of packets via the GRE tunnel interface remains in effect even though the GRE tunnel packets do not reach the other end of the tunnel. ATIS-0200004 6 5.1 Multicast Basics The basic concept of Multicast is very simple. A single stream of content is delivered into a networ

32、k from a source. The network elements (i.e., routers) then replicate and distribute the stream toward end-points that make a request into the network to receive the stream. Thus, the replication and distribution resembles a spanning tree graph. This is a highly efficient distribution method as compa

33、red with unicast, which requires a separate and distinct copy of the stream for each and every end-user requesting the content. This comparison is depicted in the following figure. Figure 1: Multicast Contrasted with Unicast Distribution of Content Figure 1 is a very generic depiction of the Multica

34、st model, but it demonstrates that Multicast is extremely scalable from a network and server perspective. In addition, Multicast changes the network engineering paradigm in that previously network capacity was driven by the backbone, server/cached, or uplink capacities, but now, is driven by compone

35、nts of the network that do not support Multicast routing, such as the access network and the EU (local loop) access. Some other significant benefits of multicast are: As a standard layer-3 service, it is protocol agnostic and does not care what content is being carried. It helps moderate network pea

36、ks. This is actually where most of the network savings derives from, since capacity is better utilized. However, Multicast also presents new paradigms and challenges compared to the unicast model: Multicast relies on the Transport (Layer 4) protocol called User Datagram Protocol (UDP). This protocol

37、 is considered an unreliable protocol because it does not use implicit handshaking dialogs as does Transmission Control Protocol/Internet Protocol (TCP/IP). Therefore, levels of reliability may need to be ATIS-0200004 7 achieved by the application, error correction algorithms at the end-points, vari

38、ous multicasting techniques (e.g., dual streams), and combinations of these. Multicast also makes it more difficult to account for the number of end-points receiving the content. This is unlike Unicast, where the origin/source originates a stream for each end user only the last multicast enabled net

39、work element before the end-user has the ability to track the number and identity of the end-users. Figure 2 depicts a more specific example of content distribution via native multicast between two CDN Provider network domains. Figure 2: Native to Native Multicast Delivery Between Two CDN Providers

40、In this example, users on the S-CDN attempt to join a multicast source on the P-CDN. Both networks are native Multicast enabled and so is the interconnection between them. 5.2 Automatic Multicast Tunneling Since Multicast may not be ubiquitously available in all networks or even across a single netw

41、ork, a technique/method is required to connect or bridge these Multicast network islands. The IETF is developing just such a standard titled Automatic IP Multicast Tunneling (AMT). The AMT standard addresses intra and inter-domain tunneling of Multicast through Unicast tunnels. The draft standard is

42、 available from: . There are essentially two components to the AMT specification: ATIS-0200004 8 1. AMT Relays: These serve the purpose of tunneling UDP multicast traffic to the receivers (i.e., End Points). The AMT Relay will receive the traffic/content natively from the multicast media source and

43、will replicate the stream on behalf of the downstream AMT Gateways, encapsulating the multicast packets into unicast packets and sending them over the tunnel toward the AMT Gateway. In addition, the AMT Relay may perform various usage and activity statistics collection 2. AMT Gateway (GW): The Gatew

44、ay will reside on an on End-Point this may be a Personal Computer (PC), Set Top Box (STB), or even in another network. The AMT Gateway receives join and leave requests from the Application via an Application Programming Interface (API). In this manner, the Gateway allows the endpoint to conduct itse

45、lf as a true Multicast End-Point. The AMT Gateway will encapsulate AMT messages into UDP packets and send them through a tunnel (across the unicast-only infrastructure) to the AMT Relay. This results in moving the replication point closer to the end user, and cuts down on traffic across the network;

46、 thus, the linear costs of adding unicast subscribers can be avoided. However, unicast replication is still required for each requesting endpoint within the unicast-only network. Using an Anycast IP address for AMT Relays allows for all AMT Gateways to find the “closest” AMT Relay the nearest edge o

47、f the multicast topology of the source. There are several scenarios for inter-domain multicast connectivity using AMT. Figure 3: AMT Tunneled Multicast (EU on S-CDN Joins Multicast from P-CDN) In this example, the End User on the S-CDN attempts to join the multicast source on the P-CDN, which is mul

48、ticast enabled. The S-CDN is not multicast enabled and neither is the interconnection between P-CDN and S-CDN. ATIS-0200004 9 Figure 4: AMT Tunneled Multicast Between Two MC-Enabled CDNs In this example, two multicast enabled CDN Providers have a non-multicast enabled interconnection. An AMT tunnel

49、is established between them. This enables an end user on the S-CDN to join the multicast source on the P-CDN. ATIS-0200004 10 5.3 Content Types Suitable for Multicast Table 2: Content Types Suitable for Multicast Delivery Content Delivery Modes Content Delivery Examples Delivery Technologies should that fail, the applications can resort to requesting the data via a unicast option (if available). There can be other information in the manifest as well, such as bitrates available or formats, and this may also be used by the application to decide on wheth