1、 ATIS-0800019 MULTICAST NETWORK SERVICE SPECIFICATION ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications industry. More than 250 companies actively f
2、ormulate standards in ATIS 20 Committees, covering issues including: IPTV, Service Oriented Networks, Home Networking, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support. In addition, numerous Incubators, Focus and Exploratory Groups address em
3、erging industry priorities including “Green”, IP Downloadable Security, Next Generation Carrier Interconnect, IPv6 and Convergence. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a member and major U.S. contributor to the International Telecommun
4、ication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, please visit . Notice of Disclaimer Transport of MPEG-2 Based DVB Services over IP Based Networks, Version 1.4.1.37 ETSI TISPAN 182 019, Telecommun
5、ications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Content Delivery Network (CDN) architecture - Interconnection with TISPAN IPTV architectures; Draft 2/25/09.38 IETF RFC 1112, Host Extensions for IP Multicasting, August 1989.49 IETF RFC 2236, Internet Group Man
6、agement Protocol, Version 2, November 1997.410 IETF RFC 2710, Multicast Listener Discovery (MLD) for IPv6, October 1999.411 IETF RFC 3261, SIP: Session Initiation Protocol, June 2002.412 IETF RFC 3376, Internet Group Management Protocol, Version 3, October 2002.413 IETF RFC 3810, Multicast Listener
7、Discovery Version 2 (MLDv2) for IPv6, June 2004.414 IETF RFC 4604, Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast, August 2006.415 IETF RFC 4607, Source-Specific Multicast for IP, August 2006.416 I
8、ETF RFC 4608, Source-Specific Protocol Independent Multicast in 232/8, August 2006.417 ITU-T Y.2111, Resource and admission control functions in Next Generation Networks, November 2008.51This document is available from the Alliance for Telecommunications Industry Solutions, 1200 G Street N.W., Suite
9、 500, Washington, DC 20005. 2This document is available from the Broadband Forum. 3This document is available from ETSI TISPAN. 4This document is available from the IETF. 5This document is available from the International Telecommunications Union. ATIS-0800019 3 3 DEFINITIONS, ACRONYMS, however, a n
10、etwork of terminals and related devices may be present for this purpose. The domain may also be a mobile end device; in this case, the delivery system of a network provider is a wireless Wide Area Network (WAN). 3.1.4 Customer: See Subscriber. Non-normative. 3.1.5 Delivery Network (DN): A set of phy
11、sical transport/access networks. 3.1.6 Delivery Network Gateway (DNG): A device implementing the Delivery Network Gateway Function. The DNG may also be termed the Residential Gateway (RG) in other standards bodies. 3.1.7 Delivery Network Gateway Function: The set of gateway functions between the net
12、work and service provider domains and the IPTV Terminal Function (ITF). 3.1.8 (User) Device: Also known as home network end devices (HNED), home network device (HND), consumer equipment (CE), terminal, physical device. A piece of Hardware (HW) equipment running its Software (SW) and attached to a Ho
13、me Network and being identified by a Globally Unique Identifier (GUID) such as a MAC address. A single Device can be used by one or more Users. 3.1.9 (Service) Domain: A logical administrative domain interacting with the networks, HW devices, SW components, protocols and data infrastructure as requi
14、red for proper service operation, management, billing, etc. 3.1.10 Home Network: A physical network segment situated on the users premises; comprised of devices, and interconnection between devices and supporting governing protocols with the premises for IPTV. 3.1.11 IGMP v2: Internet Group Manageme
15、nt Protocol version 2 as defined in RFC 2236. This is an enhancement to the original version of the IGMP protocol that added “leave” messaging in conjunction with existing “join” messaging. IGMPv2 does not support SSM since the join and leave messages only define the group address and not the source
16、 address. 3.1.12 IGMP v3: Internet Group Management Protocol version 3 as defined in RFC 3376. IGMPv3 adds support for SSM along with join-leave signaling in a single notification message. IGMPv3 is backwards compatible with IGMPv2 and can support ASM. 3.1.13 IPTV Terminal Function (ITF): Represents
17、 the functionality within the consumer network that is responsible for terminating the IP signal, and converting the content into a renderable format e.g., a Set Top Box (STB). 3.1.14 Join: When a multicast host sends the proper IGMP or Multicast Listener Discovery (MLD) message to become part of th
18、e multicast distribution tree. 3.1.15 Leaf and Branch: Each sub-network that contains at least one multicast host is known as a leaf. In the case of IPTV, the Home Network utilizing the IPTV service becomes a leaf of the IPTV multicast ATIS-0800019 4 distribution tree. When new leaves are added to t
19、he tree, a branch is created. Branches that no longer contain a leaf will be pruned from the tree. 3.1.16 Leave: When a multicast host sends the proper IGMP or MLD message to no longer be part of the multicast distribution tree. 3.1.17 Multicast Control Point Function (MCPF): The Multicast Control P
20、oint Function processes the requests (e.g., IGMP, MLD) for joining or leaving a multicast group and tracking the group membership. The MCPF may interact with the Resource and Admission Control Function (RACF) for the following purposes: Request the RACF to perform resource and admission control base
21、d on the initial processing of multicast requests - e.g., when the transport node is not already part of the requested multicast group. Request the RACF to release related resources when all end users leave an existing multicast group. For more information, see ITU-T Y.2111. 3.1.18 Multicast Distrib
22、ution Tree: The use of packet replication to send a single source stream to multiple multicast hosts. This creates a dynamic tree topology based on group membership within the network. 3.1.19 Multicast Host: This is the end multicast receiver analogous to the ITF when addressing IPTV multicast appli
23、cations. The multicast host uses the IGMP protocol to add and remove itself from the multicast distribution tree. 3.1.20 Multicast Listener Discovery (MLD v1): Multicast Listener Discovery version 1 as defined in RFC 2710. This is the original version of the MLD protocol allowing IPv6 multicast host
24、s to join a multicast tree. MLDv1 does not support SSM since the join and done messages only define the group address and not the source address. 3.1.21 Multicast Listener Discovery (MLD v2): Multicast Listener Discovery version 2 as defined in RFC 3810. MLDv2 adds support for SSM along with join-do
25、ne signaling in a single notification message. MLDv2 is backwards compatible with MLDv1 and can support ASM. 3.1.22 Multicast Route Table: Also known as the mroute table. Before a network element can replicate and forward multicast packets, the multicast packets must be received from an upstream int
26、erface (often noted as the Incoming InterFace or IIF). The mroute table stores all relevant multicast group information such as IIF and source address. If Reverse Path Forward (RPF) is enabled, the mroute table may note which groups fail RPF inspection. 3.1.23 Outgoing InterFace Table (OIF Table): M
27、ulticast does not use standard destination-based routing and instead relies on group membership protocols such as IGMP to help build the multicast distribution tree. Interfaces that have joined a multicast group are added to the OIF table in relation to the respective multicast group. Once added to
28、the table, the network element will create a copy of each multicast packet for the joined multicast group and forward out the requesting interface. 3.1.24 Provider: Non-normative. 3.1.25 Reverse Path Forward (RPF): Used by standard multicast implementations for loop prevention and to build the multi
29、cast distribution tree. If RPF is enabled, network elements will drop multicast packets that are received on an incorrect interface based on the unicast path back towards the source. RPF may be disabled for asymmetric network architectures but other loop prevention techniques must be implemented. AT
30、IS-0800019 5 3.1.26 Service: A set of functionalities enabled by a provider for consumers e.g. providing IP with QoS connectivity, providing an IPTV service, providing IM public connectivity, etc. In order to obtain a Service, a consumer at a minimum needs to become a subscriber to the service and i
31、mplement one or more IPTV Device Classes offered by the Service Provider. 3.1.27 Source-Specific Multicast (SSM): Source-Specific Multicast uses both the source and group address to identify the session traffic noted as (S,G). SSM-enabled protocols are able to differentiate between (S1,G) and (S2,G)
32、 as unique multicast groups, allowing a group address to be reused by different multicast sources. 3.1.28 Subscriber: Also known as customer, account, household, business. A provider point of view for representing an account eligible for certain service consumption. A Subscriber can correspond to on
33、e or more Users. 3.1.29 User: Also known as viewer. It denotes the representation of a human or automated IPTV consumer by a set of its configuration and management data (e.g., application views, profiles, passwords, preferences, etc.). A single User may have access to one or more Devices. 3.2 Acron
34、yms and 2) multicast between the service stratum and the consumer domain. ATIS-0800019 10 Figure 4: IPTV Multicast Service Variants Although very similar in terms of network provider packet replication, the service models will vary from one another and will be treated as having unique service requir
35、ements within this document. Note that while there are requirements for the network infrastructure to support multicast services, this does not imply the multicast service is necessarily contiguous from the SHE interface to the consumer interface. The service provider, in the general case, is consid
36、ered to have a distributed infrastructure. The SHE, VHO, and VSO locations identified in Figure 4 may all contain service provider functions (grooming, content insertion, error correction, failover mechanisms, etc.) that terminate the video streams. This stream termination and processing creates new
37、 service provider video source locations within the SHE, VHO, and VSO. Each of these source locations will be connected into the network provider domain at interface point B. 4.2.1 Transit Intra-Domain Transport The multicast transport service uses interface point B for both ingress and egress of mu
38、lticast content. In most cases, this multicast service is used to deliver multicast packets between video processing sites (each site located within the service provider domain but located in geographically diverse locations). The network provider domain is used to connect these remote sites. The mu
39、lticast topology for the transport service is expected to be a relatively static topology with changes due to: 1) Additions/deletions to the content channel line up. 2) Expansion of the network providers multicast footprint ATIS-0800019 11 The Transit Intra-Domain Transport Services will be termed t
40、he multicast transport service or transport model throughout the remainder of the document. 4.2.2 Consumer IPTV Multicast Delivery Service The consumer multicast service is based on content stream insertion at interface point B and delivered across interface point A to the DNG. This is the consumer
41、portion of the IPTV service. As with the transport model, the delivery of multicast content from interface point B across the NGN transport stratum is expected to be relatively static with changes due to: 1) Additions/deletions to the content channel line up. 2) Expansion of the network providers mu
42、lticast footprint. The multicast distribution tree at interface point A is expected to be very dynamic. The consumer behavior of “channel surfing” or “channel zapping” corresponds to the constant addition and removal of leaf nodes for each multicast group carried across interface point A, through th
43、e DNG, as the ITFs switch between video content. The desired consumer experience for this “channel change” operation is to be rapid. The identification, selection, and navigation between different streams are out of scope for this multicast specification. The data plane requirements for the delivery
44、 of multicast within the home network are out of scope for this multicast specification. The Consumer IPTV Multicast Delivery Service will be termed the consumer multicast service or consumer multicast throughout the remainder of the document. 5 MULTICAST SERVICE TECHNICAL REQUIREMENTS The multicast
45、 IPTV service consists of three fundamental requirements: 1) The multicast-enabled network must allow for the reception of source content from various ingress locations at interface point B. 2) The multicast-enabled network must provide packet replication through the creation of a multicast distribu
46、tion tree or set of multicast distribution trees. 3) The multicast-enabled network must allow multicast hosts to join the multicast trees through the use of IGMP or MLD signaling at interface point A. These three requirements define the most basic multicast service offering. For IPTV, however, the s
47、ervice requirements will be more stringent due to the expected levels of consumer experience. The requirements for the IPTV service along with multicast expectations have been defined in ATIS-0800002, IPTV Architecture Requirements. ATIS-0800002 specifies a broad scope of IPTV architecture requireme
48、nts. The following subsections list the specific architecture requirements that may apply to the multicast service in the context of service delivery, QoS, QoE, NGN, security, service attachment, and other key portions of the IPTV service. These requirements are used as the basis for the technical s
49、pecifications in this document. ATIS-0800019 12 5.1 General Requirements for the Creation of a Multicast Service The requirements for the creation of an IP multicast service for video and non-video applications are captured in the following requirements from ATIS-0800002, IPTV Architecture Requirements: IIF.ARCH.SERVICE.05 The IPTV Architecture shall provide mechanisms to support Pay-Per-View (PPV) services. The PPV session is a multicast session. IIF.ARCH.SERVICE.29 The IPTV Architecture shall support Audio Content (e.g
