INTERNATIONAL TELECOMMUNICATION UNION FOCUS GROUP ON IPTV

TELECOMMUNICATION FG IPTV-DOC-0190
STANDARDIZATION SECTOR
STUDY PERIOD 2005-2008 English only

WG(s): 4 7th FG IPTV meeting:

Qawra, St Paul’s Bay, Malta, 11-18 December 2007
OUTPUT DOCUMENT
Source: Editors
Title: IPTV Multicast Frameworks
Summary
This document on IPTV multicast frameworks describes functional requirements and frameworks
for supporting multicast capabilities in terms of IPTV network control.
Keywords
IPTV, multicast, unicast
Current status
After carefully reviewing and extensive editing works, this document contains consensus of
information from all the contributions addressed to the working group.
This document describes functional requirements and frameworks for supporting multicast
capabilities in terms of IPTV network control.

This document mainly focuses on the following multicast aspects.

 IPTV multicast functional requirements

 IPTV multicast architecture
 IPTV multicast scenarios
 Design considerations for IPTV multicast network
 Overlay multicast networking
Dependency or relationship to other FG IPTV documents:

 IPTV services requirements

 IPTV architecture
 IPTV network control aspects

Contact: Yeong-il Seo Tel: +82-42-870-8333

KT Fax: +82-42-870-8329
Republic of Korea Email: syi1@kt.co.kr
Juyoung Park Tel: +82-42-860-1028
ETRI Fax: +82-42-861-5404
Republic of Korea Email: jypark@etri.re.kr
Attention: This is a document submitted to the work of ITU-T and is intended for use by the participants to the activities of ITU-T's
Focus Group on IPTV, and their respective staff and collaborators in their ITU-related work. It is made publicly available for
information purposes but shall not be redistributed without the prior written consent of ITU. Copyright on this document is owned by
the author, unless otherwise mentioned. This document is not an ITU-T Recommendation, an ITU publication, or part thereof.
 -2-
FG IPTV-DOC-0190
 -3-
FG IPTV-DOC-0190

CONTENTS
1 Scope...........................................................................................................................5
2 References...................................................................................................................5
3 Definitions...................................................................................................................5
3.1 Terms defined elsewhere..............................................................................5
3.2 Terms defined in this Recommendation.......................................................6
4 Abbreviations and acronyms.......................................................................................7
5 Conventions................................................................................................................7
6 IPTV multicast requirements......................................................................................8
6.1 IPTV multicast transport requirement..........................................................8
6.2 QoS requirements of IPTV multicast............................................................9
6.3 Security requirements of IPTV multicast...................................................12
6.4 Interoperability requirement of IPTV multicast.........................................12
6.5 Service management requirements of IPTV multicast...............................13
7 IPTV Multicast Architecture.....................................................................................13
7.1 Description of entities for Non-NGN IPTV functional architecture..........13
7.2 Description of reference points for Non-NGN IPTV functional architecture16
8 IPTV Multicast scenarios..........................................................................................16
8.1 Native IP multicast scenario.......................................................................16
8.2 Alternative multicast scenarios...................................................................18
9 Design considerations for IPTV multicast network..................................................24
9.1 IPTV multicast transport.............................................................................24
9.2 IPTV multicast QoS....................................................................................28
9.2.1 Types of IPTV multicast QoS.....................................................................28
9.3 IPTV multicast interoperability among service providers..........................30
9.4 IPTV multicast management......................................................................32
10 Overlay multicast networking...................................................................................37
10.1 Control framework for IPTV overlay multicast.........................................37
10.2 Functional framework for IPTV overlay multicast.....................................39
10.3 QoS control in IPTV overlay multicast network........................................39
 -4-
FG IPTV-DOC-0190

IPTV Multicast Frameworks

1 Scope
This document on IPTV multicast frameworks describes functional requirements and frameworks
of supporting multicast capabilities in terms of IPTV network control.
This document considers multicast frameworks for non-NGN environment.

2 References
The following ITU-T Recommendations and other references contain provisions, which, through
reference in this text, constitute provisions of this working document. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision; all
users of this working document are therefore encouraged to investigate the possibility of applying
the most recent edition of the Recommendations and other references listed below. A list of the
currently valid ITU-T Recommendations is regularly published.
The reference to a document within this working document does not give it, as a stand-alone
document, the status of a Recommendation.

[FG IPTV-DOC-0147] ITU-T FG IPTV document IPTV Services Requirements

[FG IPTV-DOC-0181] ITU-T FG IPTV document IPTV Architecture
[FG IPTV-DOC-0190] ITU-T FG IPTV document IPTV Multicast Frameworks
[IETF RFC 2236] IETF RFC 2236(1997), Internet Group Management Protocol, Version 2
[IETF RFC 2710] IETF RFC 2710 (1999), Multicast Listener Discovery (MLD) for IPv6
[IETF RFC 3376] IETF RFC 3376(2002), Internet Group Management Protocol, Version 3
[IETF RFC 3810] IETF RFC 3810(2004), Multicast Listener Discovery Version 2 (MLDv2)
for Ipv6
[IETF RFC 4541] IETF RFC 4541(2006), Considerations for Internet Group Management
Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping
switches
[IETF RFC 4601] IETF RFC 4601(2006), Protocol Independent Multicast – Sparse Mode
(PIM-SM)
[IETF RFC 4604] IETF RFC 4604(2006), Using Internet Group Management Protocol
Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version
2 (MLDv2) for Source-Specific Multicast.
[IETF RFC 4605] IETF RFC 4605(2006), Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding (“IGMP/MLD
Proxying”)

3 Definitions

3.1 Terms defined elsewhere

This Document uses the following terms defined elsewhere:
 -5-
FG IPTV-DOC-0190

3.1.1 Broadcast [ITU-T M.60]: One-way transmission from one point to two or more other
points.
3.1.2 Delivery network gateway (DNG) [ATIS-0800002]: A device implementing the DNGF.
Note: DNG also is commonly referred to as the Residential Gateway (RG).
3.1.3 End-user [ITU-T J.112]: A human being, organization, or telecommunications system that
accesses the network in order to communicate via the services provided by the network.
3.1.4 Network provider [ITU-T Q.1290]: The organization that maintains and operates the
network components required for IPTV functionality. A network provider can optionally
also act as service provider.
3.1.5 Service provider [ITU-T M.1400]: A general reference to an operator that provides
telecommunication services to customers and other users either on a tariff or contract basis.
A service provider may or may not operate a network. A service provider can optionally or
can optionally not be a customer of another service provider.
3.1.6 Subscriber [ITU-T Q.3050.1]: The subscriber is responsible for concluding contracts for
the services subscribed to and for paying for these services.
3.1.7 Subscription [ITU-T Q.1741.3]: A subscription describes the commercial relationship
between the subscriber and the service provider.

3.2 Terms defined in this Recommendation

This Document defines the following terms:
3.2.1 Multicast domain management: A multicast domain is a set of multicast routing and
forwarding instances than can send multicast traffic to each other. These multicast routing
and forwarding instances are referred to as IPTV multicast domain. Thus, multicast domains
map all of a customer’s multicast groups that exist in particular IPTV service members to a
single unique global multicast group. This is achieved by existing or specific group routing
and forwarding capability in the network.
3.2.2 Multicast access control functions: Multicast Access Control Functions is that control a
multicast user access to IPTV multicast tree. The IPTV user can join a multicast service
using these control functions with proper authentication and authorization of the user.
3.2.3 Multicast delivery control functions: Multicast Delivery Control Functions is that can
control IPTV multicast delivery among transport functions.
3.2.4 Overlay network: A virtual network of nodes and logical links that is built on top of the
underlying network infrastructure with the purpose of implement a network service that is
not available in the underlying network infrastructure.
3.2.5 Overlay multicast network: One type of overlay network that provides multicast services
to end users on top of the general network infrastructure.
3.2.6 IPTV multicast interoperability: IPTV multicast interoperability is the exchange of IPTV
service information amongst multicast based IPTV service providers. And to make the
optimal contract and to provide the stable IPTV services amongst multicast based IPTV
service providers.
3.2.7 IPTV service exchange point: IPTV SEP (service exchange point) is identified as a
reference point for handling the service brokering function between IPTV SPs enabling the
optimal contract between IPTV SPs and providing the stable IPTV services amongst IPTV
service providers. IPTV SEP can be located in any peering point.
 -6-
FG IPTV-DOC-0190

4 Abbreviations and acronyms

This document uses the following abbreviations and acronyms.
CAC Connection Admission Control
CCTV Closed-Circuit TV
cIMA child IMA
CP Content Provider
DoS Denial of Service
DRM Digital Rights Management
Note: In this document, the term Service and Content Protection is used instead of Digital
Rights Management.
ECMP Equal Cost Multiple Path
IGMP Internet Group Management Protocol
IMA IPTV Multicast Agent
IP Internet Protocol
ISP Internet Service Provider
MLD Multicast Listener Discovery
QoE Quality of Experience
QoS Quality of Service
pIMA parent IMA
RP Rendezvous Point
SEP Service Exchange Point
SP Service Provider

5 Conventions
In this document:
The keywords “is required to” indicate a requirement which must be strictly followed and from
which no deviation is permitted if conformance to this document is to be claimed.
The keywords “is prohibited from” indicate a requirement which must be strictly followed and
from which no deviation is permitted if conformance to this document is to be claimed.
The keywords “is recommended” indicate a requirement which is recommended but which is not
absolutely required. Thus this requirement need not be present to claim conformance.
The keywords “is not recommended” indicate a requirement which is not recommended but which
is not specifically prohibited. Thus, conformance with this specification can still be claimed even if
this requirement is present.
The keywords “can optionally” indicate an optional requirement which is permissible, without
implying any sense of being recommended. This term is not intended to imply that the vendor’s
implementation must provide the option and the feature can be optionally enabled by the network
operator/service provider. Rather, it means the vendor may optionally provide the feature and still
claim conformance with the specification.
 -7-
FG IPTV-DOC-0190

Note: The terminology and the architecture assumed in this document needs to be checked for
alignment with IPTV architecture document.

6 IPTV multicast requirements

6.1 IPTV multicast transport requirement

The following requirements are duplicates of those identified in IPTV services requirements [FG
IPTV –DOC-0147] and should not be modified in any way without consultation with the group (i.e.
study group question) which owns [FG IPTV –DOC-0147]. In the case of a discrepancy between
the text in this document and that of [FG IPTV –DOC-0147], then the latter text should take
precedence.
 The IPTV architecture is required to support the addressability of particular device such as
ITFs within the end-user Network [ATIS-0800002].
 The IPTV architecture is required to allow for the utilization of Internet protocols and
standards related with multicast transmission[ATIS-0800002].
 The IPTV architecture is recommended to allow the delivery of IPTV services over different
access networks (e.g. cable, optical, xDSL, wireless).
 The IPTV architecture is recommended to adapt dynamically to change in wireless networks
characteristics when the service is delivered over a mobile network (e.g. bandwidth, packet
loss rate, etc.
 The IPTV architecture can optionally support a replacement algorithm for content caching
and distribution.
 The IPTV architecture is required to support a mechanism for NAT traversal [ATIS-
0800002].
 The IPTV architecture is recommended to support the ability of both multicasting and
unicasting transmission schemes.
 The IPTV architecture is required to support the management and enforcement of the
service providers' transport policies by the network provider [ATIS-0800002].
 The IPTV architecture is required to support access networks in case of NGN-based IPTV as
defined in NGN architecture.
 The IPTV architecture is required to support multicast means of communication to all end-
users [ATIS-0800002].
 The IPTV architecture is required to allow the service provider to utilize the network
providers' multicast delivery capabilities [ATIS-0800002].
 The IPTV architecture is recommended to support mechanisms that allow IPTV services to
be distributed to specific group of end-users.
 The IPTV architecture is recommended to support mechanisms for transmitting
identification information related to end-users who want to receive or are selected to receive
IPTV services
 The IPTV architecture is required to support IP filtering functions in the DNGF in order to
prevent selected local multicast traffic on the HNS from appearing on the DN [ATIS-
0800002].
 -8-
FG IPTV-DOC-0190

 The IPTV architecture is recommended to support the ability for the DNGF to implement
standard IP routing functions, per established IETF specifications. [ATIS-0800002]
 The IPTV architecture is recommended to support the ability for the DNGF to support
routing functions per IPv4 specifications. [ATIS-0800002]
 The IPTV architecture is recommended to support both IPv6 and IPv4. [ATIS-0800002]
 The IPTV architecture is recommended to support static and dynamic address allocation
schemes for both IPv4 and IPv6 [ATIS-0800002]
 The IPTV architecture is recommended to support the ability for the DNGF to support the
routing of IP packets between all interfaces toward the access/core network (WAN side of
the HN), and toward the ITF (LAN side of the HN). Specifically, this means: [ATIS-
0800002]
- Routing is recommended to be supported from DN to HNS (downstream flow).
- Routing is recommended to be supported from HNS to DN (upstream flow).
- Routing is recommended to be supported from any HNS to any other HNS (bidirectional
flows).
 The IPTV architecture is recommended to support the ability for the DNGF to support
multiple logical IP interfaces (multiple attachment points at the IP layer) on any particular
physical DN interface [ATIS-0800002].
 The IPTV architecture is recommended to support the ability for the DNGF to assign IP
addresses to devices in the Home Network [ATIS-0800002].
 The IPTV architecture is recommended to support automated configuration capabilities for
the IPTV devices [ATIS-0800002].
 The DNGF is recommended to support NAT/NAPT capability mapping IP address and port
numbers between the public WAN and the LAN(s) [ATIS-0800002].
The following are multicast transport functional requirements in addition to the above service
requirements.
 The IPTV multicast network is recommended to provide identification of multicast group to
the ITF.
 The IPTV multicast network is recommended to maintain multicast session information for
each multicast group, and can optionally announce them to the ITFs.
 The IPTV multicast network is recommended to authenticate and authorize an IPTV
multicast source.
 The IPTV multicast network is recommended to optionally manage the identification of
IPTV multicast tree.
 The IPTV multicast network is required to provide the stable multicast tree management
when the IPTV end-users join and leave.

6.2 QoS requirements of IPTV multicast

The following requirements are duplicates of those identified in IPTV services requirements [FG
IPTV –DOC-0147] and should not be modified in any way without consultation with the group (i.e.
study group question) which owns [FG IPTV –DOC-0147]. In the case of a discrepancy between
the text in this document and that of [FG IPTV –DOC-0147], then the latter text should take
precedence.
 -9-
FG IPTV-DOC-0190

 The IPTV architecture is required to support a framework that identifies the key components
and measurement points for Quality of Service Measurement (QoSM) [ATIS-0800002].
 The IPTV terminal device is recommended to be able to declare Media-providing entities
their usage environments description - e.g. Type of service, Type of Terminal, Type of
transmission medium, User Preferences, Available QoS Level [ATIS-0800002].
 The IPTV architecture, if re-transmission broadcast service is supported, is recommended to
provide comparable Quality of Experience to the end-user as the direct reception.
 The IPTV architecture is required to support the service provider to be able to get QoS
information from the end-user device.
 The IPTV architecture is required to allow the delivery of IPTV services with a defined
Quality of Experience (QoE) for the IPTV end-user [ATIS-0800002].
 The IPTV architecture is recommended to support consistent QoS for the duration of the
service.
 The IPTV architecture is recommended to support a mechanism by which network operators
can integrate IPTV QoS management functions into a common framework with other
services and applications [ATIS-0800002].
 The IPTV architecture can optionally support the delivery of multiple services over the
common IP transport with a manageable IP Quality of Service (QoS); services can
optionally be delivered from multiple service providers or from a single provider [ATIS-
0800002].
 The IPTV architecture is required to support mechanisms for supporting appropriate
resiliency in the service provider infrastructure to maintain a high QoE [ATIS-0800002].
 The IPTV architecture is recommended to support means to provide channel changing times
with sufficient QoE.
 Networks that support IPTV are required to support the IP QoS class and associated
performance requirements specified in Y.1541 [ITU-T Y.1541], which recommends the
selection of relevant specific QoS classes based on application requirements.
 The IPTV architecture is required to support a mechanism for assigning traffic priorities
[ATIS-0800002].
 The IPTV architecture is required to support the relevant mechanisms for IPTV traffic
identification, classification and marking, policing and conditioning, scheduling and
discarding.
 The IPTV architecture is recommended to support mechanisms for dynamic IPTV traffic
load balancing so as to dynamically accommodate with the network load and congestion
conditions at any given time, so as to deliver the set of IPTV services to the end-users with
the relevant level of quality.
 The IPTV architecture is recommended to offer an admission control solution for admission
of IPTV services over the access and core network resources from the home network to the
service source.
 The IPTV architecture is required to support the capability for management of capacity on
the services and network elements [ATIS-0800002].
 - 10 -
FG IPTV-DOC-0190

 The IPTV architecture can optionally support mechanisms to support QoS/QoE parameter
adjustment due to changes of content characteristics on a channel.
 The IPTV architecture is recommended to support an application layer error recovery
mechanism to support sufficient QoE/QoS for unicast distribution of any IPTV service.
 Any application layer error recovery mechanism integrated in the IPTV architecture is
recommended to be flexible to cover a range of networks conditions and IPTV services.
 The IPTV architecture is required to define mechanism to appropriately distinguish different
forms of traffic -- e.g. data and voice [ATIS-0800002].
 The IPTV architecture is recommended to support redundancy and failover mechanisms for
infrastructure components. [ATIS-0800002].
 The IPTV architecture is recommended not to put any constraint on latency sensitive
services. [ATIS-0800002]
 The IPTV architecture is required to define traffic management mechanisms for the
differential treatment of IPTV traffic [ATIS-0800002].
 The IPTV architecture is required to support the ability to configure QoS rules at the DNGF
that govern traffic mapping (upstream or downstream) for the different services [ATIS-
0800002].
 The IPTV architecture (including DNGF) is recommended to support the ability to perform
the bandwidth management of all HNS networks attached to the DNG [ATIS-0800002].
 The IPTV architecture (including DNGF) is recommended to support performing call
admission functions to protect the home network from excessive and harmful traffic on any
HNS, between two HNSs attached to the DNG, and between any HNS and any DN [ATIS-
0800002].
 The IPTV architecture (including DNGF) is recommended to support the ability for the
DNGF to perform policing functions on incoming traffic and drop offending traffic to
protect the home network [ATIS-0800002].
 The IPTV architecture (including DNGF) is recommended to support routing IP traffic
based on provision-able/manageable mechanisms to guarantee QoS for different service
classes [ATIS-0800002].
 The IPTV architecture (including DNGF) is recommended to support mapping downstream
traffic to corresponding local flows to provide QoS for the different services. This includes
L3 to L2 mapping, based on the local HNS [ATIS-0800002].
 The IPTV architecture (including DNGF) is recommended to support mapping upstream
traffic generated by the end-devices to corresponding outgoing flows to provide QoS for the
different services. This includes L2 to L3 mapping [ATIS-0800002].
 Where the Home Network transports multiple latency sensitive traffic types (e.g., the IPTV
services and frequency distribution protocols, or time distribution protocols), these protocols
and the Home Network infrastructure is recommended to be configured such that they do
not impact the latency requirements of each service [ATIS-0800002].
The following are multicast QoS functional requirements in addition to the above service
requirements.
 IPTV service provider is recommended to guarantee the QoS of IPTV multicast traffic.
 - 11 -
FG IPTV-DOC-0190

 IPTV network provider is recommended to provide recovery mechanism for IPTV multicast
traffic due to node failure and link failure.
 IPTV network provider can optionally provide priority based transport for IPTV multicast
traffic.

6.3 Security requirements of IPTV multicast

The following requirements are duplicates of those identified in IPTV services requirements [FG
IPTV –DOC-0147] and should not be modified in any way without consultation with the group (i.e.
study group question) which owns [FG IPTV –DOC-0147]. In the case of a discrepancy between
the text in this document and that of [FG IPTV –DOC-0147], then the latter text should take
precedence.
 The IPTV architecture is required to support the ability for the service provider to prevent
the sending of bulk unsolicited contents to the end-users.
 The IPTV architecture is required to support the service provider to be able to authenticate,
authorize and charge the subscriber.
 The IPTV architecture is recommended to take into account the influence/impact on
performance, quality of service, usability, scalability and cost constraints on deployment of
security.
 The IPTV architecture is required to support protection of content that is transferred over
multicast and/or over unicast streams.
 The IPTV architecture is required to support the capability of preventing the DoS attack to
network.
 The IPTV architecture is required to support the provision of security measures to block
illegal or unwanted traffic.
 The IPTV architecture is required to support network operators to prevent that the network
topology and its resources are visible to unauthorized entities.
 The IPTV architecture is required to be hardened against attacks on multicast capabilities.
 The multicast architecture is required to support the capability of multicast protocol
adjacency authentication in order to establish a reliable peer.
The following are multicast security functional requirements in addition to the above service
requirements.
 The IPTV multicast network is recommended to support the capability of multicast protocol
adjacency authentication in order to establish a reliable peer.
 The IPTV multicast network is recommended to provide the capability of authenticating a
multicast source such that it prevents an unauthorized source from becoming the multicast
source.
 The IPTV multicast network is recommended to support authentication and authorization for
both multicast user as source and multicast user as receiver.

6.4 Interoperability requirement of IPTV multicast

The following requirements are duplicates of those identified in IPTV services requirements [FG
IPTV –DOC-0147] and should not be modified in any way without consultation with the group (i.e.
study group question) which owns [FG IPTV –DOC-0147]. In the case of a discrepancy between
 - 12 -
FG IPTV-DOC-0190

the text in this document and that of [FG IPTV –DOC-0147], then the latter text should take
precedence.
 The IPTV architecture is recommended to support a functional component that presents an
open interface for the 3rd party applications to use the capabilities and resources of the
IPTV network.
 The IPTV architecture is required to support a mechanism that allows for service-based
transport QoS to be managed across multiple network domains [ATIS-0800002].
 The IPTV architecture is recommended to support capabilities for exchange of IPTV
services information between different IPTV services providers. For instance, the service
information can optionally include the source information, channel information, service
start/end time, and QoS information.

6.5 Service management requirements of IPTV multicast

The following requirements are duplicates of those identified in IPTV services requirements [FG
IPTV –DOC-0147] and should not be modified in any way without consultation with the group (i.e.
study group question) which owns [FG IPTV –DOC-0147]. In the case of a discrepancy between
the text in this document and that of [FG IPTV –DOC-0147], then the latter text should take
precedence.
 The IPTV architecture is required to support the ability to trace the source of incoming
content (e.g. messages that have been a cause for complaint by an end-user).
 The IPTV architecture is required to support mechanisms for the IPTV services Provider to
Operate, Administer, Maintain, and Provision (OAMP) IPTV equipments [ATIS-0800002].
 The IPTV architecture is required to support the capability of monitoring the network
elements (e.g. routers) and service elements (e.g. ITF) that report alarms in the event of
faults.
 The IPTV architecture is required to support the service provider be able to upgrade the end-
user device remotely.
 The IPTV architecture is recommended to support the service provider to be able to update
the end-user device remotely, e.g. update software, firmware and virus list.
The following are multicast service management functional requirements in addition to the above
service requirements.
 IPTV network is recommended to support mean(s) for multicast traffic monitoring
(including performance monitoring) and for analysis for each service group.

7 IPTV Multicast Architecture

7.1 Description of entities for Non-NGN IPTV functional architecture

The functional architecture for IPTV multicast shows the principal functional groups in non-NGN
environment. These functional groups provide a more detailed breakdown of the IPTV multicast
functionality.
Note: Multicast architecture descriptions are based on IPTV architecture output document [FG
IPTV-DOC-0181].
 - 13 -
FG IPTV-DOC-0190

7.1.1 End-user Functions for IPTV multicast

The multicast end-user functions include those functions normally provided by the IPTV Terminal
and the end-user Network. The multicast end-user functions are responsible for collecting control
commands from the user, and interacting with the multicast application functions to join and leave
from IPTV multicast groups. Multicast end-user can request the multicast service information. After
receiving this information, they can join the multicast group with some QoS requirements. Then, it
receives multicast data through multicast network transport functions.
7.1.1.1 IPTV Terminal Functions for IPTV multicast
The IPTV Terminal Functions for IPTV multicast includes ‘Application Clients block’, ‘DRM
Client block’, ‘Media Client block’ and ‘Control client functional block’.
1) Linear TV Application client function: It interacts with Linear TV Application to perform
session management, service authorization, presentation of the content metadata, and
execution of the service logic of the Linear TV service.
2) DRM Client block: This block for IPTV multicast is for further study.
3) Media Client block: This block for IPTV multicast is for further study.
4) Control Client functional block: It provides the functions required to communicate with the
IPTV Service Control Function to identify and prepare for the connection to the content
delivery function.
7.1.1.2 Home Network Functions for IPTV multicast
The Home Network Functions for IPTV multicast include ‘Delivery Network Gateway Function
block’.
1) Delivery Network Gateway Function block: This block for IPTV multicast is for further
study.
7.1.2 Application Functions for IPTV multicast
The multicast application functions interact with end-user functions to join and leave of IPTV
multicast services; and this functions support basic multicast control functionality such as IPTV
multicast channel change, pause, resume, etc. Application Functions for IPTV multicast include
‘IPTV application block’, ‘DRM Rights & Key management block’, ‘Application Profile Functions
block’, and ‘Content Preparation block’.
1) IPTV Application block: This block supports Linear TV application functions to perform
session management, service authorization, presentation of the content metadata, and
execution of the service logic of the Linear TV service.
2) DRM Rights & Key Management (multicast Key management) block: This block controls
the protection of the content and is responsible for the management of the content rights and
the keys used to encrypt and decrypt contents. It acquires the content rights (or content
license, originated from Content Provider) from the Content Preparation function, generates
and distributes this security information (rights object or keys) to DRM Client, it may also
provide the keys to Content Encryption.
3) Application Profile Functions block: This block stores the profiles for the IPTV
Applications. Application Profile may be located either within Service User Profile
Functions, or within IPTV applications depending on implementation.
 - 14 -
FG IPTV-DOC-0190

4) Content Preparation block: This block is used to aggregate Content, to manage contents, to
process metadata and to encrypt contents. It may be used to convert the content, which is
delivered by the content owner, into required delivery format.
7.1.3 Service Control Functions for IPTV multicast
The Multicast Service Control Functions for IPTV multicast provides the functions of requesting
and releasing the network and service resources required to support the IPTV multicast services; it
include ‘IPTV service control functional block’ and ‘service user profile function block’.
1) IPTV service control functional block: It provides functions of handling service initiation
and/or termination requests, performing service access control, establishing and maintaining
the network and system resources required to support the required IPTV Terminal
functionality. For example, it can request the Content Delivery Functions to allocate
multicast media server capacity and to request the Network Transport Functions to reserve
Network bandwidth for the multicast media Stream.
2) Service user profile function block: It can be used for storing user profiles, subscriber-
related location data, and presence status data in the Service stratum. The service user
profile functional block performs basic data management and maintenance functions. The
service user profile functional block has responsibility of responses to queries for user
profiles.
7.1.4 Content Delivery Functions for IPTV multicast
Multicast content delivery functions provide the distributed content servers for the IPTV multicast
services. Multicast contents, which are prepared in the application functions, are delivered to the
End-Users via the Network Transport Functions through the Content Delivery Functions.
During multicast service, Application Functions send contents to Content Delivery Functions. In
order to support the efficient multicast services, contents may be stored/cached in the Content
Delivery Functions; which includes ‘Content Distribution & Location Functions block’ and
‘Content Delivery & Storage Functions block’.
1) Content Distribution & Location Functions block: It controls the Delivery & Storage
Functions to optimize content distribution, selection and deliver content to the end user.
2) Content Delivery & Storage Functions block: It distributes, caches, stores and delivers the
content to the end user. They handle the media control messages; Pause and Fast Forwards.
7.1.5 Network Transport Functions for IPTV multicast
The ‘Network Transport Functions’ provides multicast connectivity with transport functions for all
multicast users. The multicast transport functions can support multicast tree construction, multicast
traffic replication and multicast member identification functionalities. Then, multicast traffic is
forwarded along multicast delivery path.
The Network Transport Functions include ‘Authentication and IP allocation functional block’,
‘Resource control functional block’, ‘Multicast Control Point Functions block’, ‘Multicast
Replication Functions block’ and ‘Access Network Functions block’.
1) Authentication and IP allocation functional block: It provides the capability of
authenticating the Delivery Network Gate Functions, connecting the Network Transport and
Control Functions and allocating IP address to the terminal device.
2) Resource control functional block: It provides the capability of controlling network
resources in the Access and Transport networks to allow appropriate resources to be
provided to the Content Streams.
 - 15 -
FG IPTV-DOC-0190

3) Multicast Control Point Functions block: It provides the capability of selecting individual
Multicast stream that is to be delivered, over the access network, to the IPTV Devices. The
request for a Multicast Stream may need to be authorised before it is accepted. This is one
of the Transport Network functions.
4) Multicast Replication Functions block: The functions replicate multicast stream to all the
Multicast Control Points that need to receive it.
5) Access Network Functions block: This block for IPTV multicast is for further study.
7.1.6 Management Functions for IPTV multicast
These functions for IPTV multicast are for further study.
7.1.7 Content Provider Functions for IPTV multicast
Content can come from a number of different sources; the physical interfaces and signals formats
may all be different from each of the sources. E.g. IP networks satellite decoders. It may include
functions such as content ratifying, which means it needs to ratify content license, content access
prioritization and parental control level; it can provide distributed storage servers (e.g. CDN) for
large volumes of video and audio contents.
These functions for IPTV multicast are for further study.

7.2 Description of reference points for Non-NGN IPTV functional architecture

The following references points, defined in IPTV architecture document [FG IPTV-DOC-0181], are
the interfaces among functional blocks which are focused only in the aspect of IPTV multicast.
Reference point E1, E2-Cm, E3, H1, H2, A1, A2, A3, A4, C1, C2, D1, S1, S2, S3, S4, S5, T1, R1,
Md, Mc are identified to be related to IPTV multicast architecture and need further study.

8 IPTV Multicast scenarios

8.1 Native IP multicast scenario

8.1.1 Native IP multicast-based IPTV service delivery solution
Figure 8-1 shows the concept of native IP multicast based IPTV service delivery solution.
In this scheme, each member registers IP multicast group by exchanging IGMPv.x messages with
its access routers; and then each IP multicast router constructs IP multicast tree by exchanging
multicast routing protocol messages; finally data from source flows according to the multicast tree
from source to each receivers.
In this scenario, the network provider can fully manage the multicast based IPTV service delivery.
 - 16 -
FG IPTV-DOC-0190

Figure 8-1: Data distribution scheme with native IP multicast

To provide IPTV service based on native IP multicast, it is required for Network Provider (NP) to
install multicast-capable routers; and the service solution fully depends on IP multicast network.
The native IP multicast-based IPTV service solution has characteristics of tightly related
performance to the condition of NP’s network; therefore this service solution has the merit of
having full-network-speed because multicast forwarding capability is provided by each network
element (i.e., multicast routers).
On the contrary, native IP multicast-based IPTV service solution can support only bounded number
IPTV service channels. Because each network element must handle each state per flow, the NP’s
network may suffer from unbounded number of IPTV service channels.
Therefore, native IP multicast-based IPTV service solution is appropriate for HDTV-quality IPTV
service with bounded number of IPTV service channels.

Figure 8-2: High-level information flow for the case of IP multicast-based IPTV service
 - 17 -
FG IPTV-DOC-0190

Figure 8-2 shows scenario when native IP multicast mechanism is applied to IPTV service. To
provide IPTV service, not only data delivery mechanism but such as IPTV service control, DRM
management are very crucial, but this scenario will only focus on the multicast data delivery
capabilities, the left are considered out of scope.
In the native IP multicast-based IPTV service, Content Provider (CP) asks Service Provider (SP) to
multicast content media (1), and then SP prepares the content media for multicasting to the
announce group (2); but the way of announcing group is also considered as out of scope.
Consumer (IPTV client) exchanges signalling with SP’s IPTV control function for initiating IPTV
service (3).
In native multicast based IPTV service, NP is in charge of replicating and delivering content media
to each receiver; the purpose of network transport function of NP is to configure optimized
multicast tree and then forwards replicated data along the configured multicast tree. The network
provided by NP consists of access, edge, and core network.
To have multicast delivery service, it is required for IPTV client to subscribe a specific multicast
group. IPTV client uses network/resource management function to subscribe the multicast group
(4); IPTV client can join a specific multicast group by using IGMP. IPTV client’s subscribing a
group will be accomplished after following successful NP’s network authentication; then the IPTV
client can be attached to the specific multicast tree. In case of NP, most optimized multicast tree
from SP to consumers is configured by exchanging appropriate routing protocol.
After the successful multicast tree is configured, the content media from SP can be delivered to
IPTV client with help of multicast forwarding capabilities provided by NP (5). The content media,
finally reached at IPTV client’s network transport function, will be delivered to IPTV client
application. To improve video quality suffered by jitter or delay, IPTV client may put appropriate
size of buffer between network transport and client’s application (6).
In case when QoS monitoring is necessary, SP may gather information by asking end IPTV client of
experienced QoS report or by asking NP of network statistics (7); but the details are considered as
out of scope.

8.2 Alternative multicast scenarios

8.2.1 Server-based IPTV service delivery scenario
Figure 8-3 shows the concept of replicated unicast based IPTV service delivery solution.
In this scheme, service provider (SP) provides a media server or server pool; each member connects
media server or server pool; then the media server sends data to every receiver respectively.
Service provider can fully manage the server-based IPTV service delivery, but because media
server cannot support infinite number of receivers, the size of the group is tightly bounded by the
performance of media server or server pool as well as server-side network bandwidth.
 - 18 -
FG IPTV-DOC-0190

Figure 8-3: Data distribution scheme with replicated unicast

8.2.2 CDN-based IPTV service delivery scenario

Figure 8-4 shows the concept of CDN-based IPTV service delivery solution.
In this scheme, service provider pre-installs CDN servers in an appropriate place; each receiver
finds and then connects the nearest CDN server. Then multimedia streams from source are
distributed to each receiver along the data delivery path of CDN servers.
Service provider can fully manage the CDN-based IPTV service delivery; but because service
provider cannot install CDN servers infinitely, the number of installed CDN servers bounds the size
of the group tightly.

Figure 8-4: Data distribution scheme with CDN

To provide CDN-based IPTV service, it is required SP to position CDN server or server pool. CDN-
based IPTV service can be easily deployed; because CDN-based IPTV service can be implemented
over current unicast-based network; so, it is not required to install multicast-enabled network.
The CDN-based IPTV service solution has characteristics of tightly related performance to the
power of CDN server and the number of CDN servers; because CDN server sends content media to
each client repetitiously according to the each IPTV client’s connection to CDN server. The number
 - 19 -
FG IPTV-DOC-0190

of IPTV clients can be served at a same time totally depends on the power of CDN servers and the
number of CDN servers.
However, because each client directly connects to CDN server SP can easily manage each client at
any purpose; for example, SP can monitor each IPTV clients’ presence for billing in real time.
Therefore, CDN-based IPTV service solution is most suitable for IPTV service provider who does
not own a network but wants to provide payable IPTV service to the bounded number of IPTV
clients.

Figure 8-5: High-level information flow for the case of CDN-based IPTV service

Figure 8-5 shows the scenario when CDN mechanism is applied to IPTV service. Because this
scenario only focuses on the multicast data delivery capabilities, the left are considered out of
scope.
To begin with CDN-based IPTV service, CP asks SP to deliver content media; then SP convert the
requested content media into suitable format for IPTV service delivery (1).
To receive IPTV service, IPTV client asks SP for specific IPTV service; and then SP gives
available information about CDN servers to connect (2). IPTV client then tries to connect CDN
server by using the given information from SP (3). Because unicast mechanism is applied to deliver
content media to IPTV clients in CDN-based IPTV service solution (4), NP does not care about
multicast delivery; NP is just for unicast data delivery capabilities (5).
The content media, finally reached at IPTV client’s network transport function, will be delivered to
IPTV client application. To improve video quality suffered by jitter or delay, IPTV client may put
appropriate size of buffer between network transport and client’s application (6).
In case when QoS monitoring is necessary, SP may gather information by asking end IPTV client of
experienced QoS report or by asking NP of network statistics (7); but the details are considered as
out of scope.
 - 20 -
FG IPTV-DOC-0190

8.2.3 P2P-based IPTV service delivery scenario

Figure 8-6 shows the concept of P2P-based IPTV service delivery solution.
In this scheme, each end-node can be both a media producer as well as a media consumer. The way
of communications is as follows; each node discovers its peers and then connects them; each node
can exchange media between themselves.
Because P2P model does not want to have SP’s censorship, this model usually does not involve
node of SP’s. Although the size of group is not logically bounded, it may not be adequate to
distribute contemporary media. To improve data receiving, each node tries to finds more peers as
possible.

Figure 8-6: Data distribution scheme with P2P

8.2.4 Overlay multicast-based IPTV service delivery scenario

Figure 8-7 and figure 8-8 shows a brief concept of overlay multicast-based IPTV service delivery
solution. In overlay multicast mechanism, special overlay nodes emulate the functions of IP
multicast router’s; such as multicast data tree configuration, multicast data forwarding etc.
In this scheme, each overlay node constructs multicast data delivery path from sender to group
dynamically as naïve IP multicast router does. Along the constructed path, each overlay node
forwards data, which comes from its upstream node, to its downstream nodes. The size of group is
not logically bounded, and it is adequate to distribute contemporary media.
The overlay node which substitutes IP multicast router may form a hardware box, a server, or an
end-system; the formation is a deployment or implementation issue. Figure 8-7 shows an overlay
multicast scheme without SP’s participation.
 - 21 -
FG IPTV-DOC-0190

Figure 8-7: Data distribution scheme with overlay multicast without SP

Figure 8-8 shows an overlay multicast scheme with SP’s participation.

Figure 8-8: Data distribution scheme with overlay multicast with SP

To provide overlay multicast-based IPTV service, it is required for IPTV client’s network delivery
function to construct overlay multicast tree and to replicate and forward content media.
Overlay multicast-based IPTV service can be easily deployed. Because overlay multicast-based
IPTV service can be implemented over current unicast-based network; there is no need to change
current network environment.
The noticeable feature of overlay multicast mechanism is that each client can relay received content
media; i.e., each client can act like content producer as well as content consumer. Therefore the
QoS of overlay multicast-based IPTV service is highly affected by the power of each IPTV client.
However, in overlay multicast-based IPTV service solution, only the participated IPTV clients to a
specific IPTV channel share the burden of content media delivery; so it is not required to have
centralized server nor specific network element. Therefore, overly multicast-based IPTV service
does not have any limitation on the number of IPTV service channel.
 - 22 -
FG IPTV-DOC-0190

On the contrary, it is difficult to manage each IPTV clients for billing and presence, because each
contents media delivery elements in overlay multicast-based IPTV service are distributed.
Therefore, overlay multicast-based IPTV service solution is suitable for IPTV service of low-video-
quality (low bit rate) and free IPTV service with no limitation on the number of service channel.
Especially this service solution can be applied for the cyber community purpose, for personal
broadcasting purpose, and for the CCTV broadcasting purpose.

Figure 8-9: High-level information flow for overlay multicast-based IPTV service

Figure 8-9 shows the scenario when overlay multicast mechanism is applied to IPTV service.
Because this scenario only focuses on the multicast data delivery capabilities, the left are considered
out of scope.
To begin with overlay multicast-based IPTV service, CP asks SP to delivery content media and then
SP convert the requested content media into suitable format for IPTV service(1). IPTV client asks
SP to provide IPTV service to receive IPTV service (2).
In overlay multicast environment, each IPTV client constructs overlay multicast tree. Along the
overlay multicast tree, each IPTV client can receive content media from its parent client and can
also relay the received content media to its children clients; therefore it is required for each client to
know the location information of other clients participated in same IPTV channel.
To acquire information about other participated IPTV clients, IPTV client exchange signalling with
SP (3). In overlay multicast-based IPTV service, unicast mechanism is applied to deliver content
media; NP only needs to support unicast data delivery capabilities (4).
The content media, finally reached at IPTV client’s network transport function, will be delivered to
IPTV client application. To improve video quality suffered by jitter or delay, IPTV client may put
appropriate size of buffer between network transport and client’s application (5). Then IPTV client
forwards the received content media to network to support its children clients (6).
 - 23 -
FG IPTV-DOC-0190

In case when QoS monitoring is necessary, SP may gather information by asking end IPTV client of
experienced QoS report or by asking NP of network statistics (7); but the details are considered as
out of scope.

9 Design considerations for IPTV multicast network

9.1 IPTV multicast transport

The physical implementation of IPTV multicast transport can be done by the network elements with
multipoint configurations.
9.1.1 Any Source Multicast and Source Specific Multicast
Two different service models for IP-Multicast are currently supported: Any Source Multicast
(ASM) and Source Specific Multicast (SSM). Within an IPTV Multicast Framework both service
models can be used and also deployed in parallel because ASM and SSM are running in different
address spaces.
ASM generally deploys IGMPv2 or IGMPv3 (MLDv1/MLDv2) without source information and
PIM-Sparse Mode in combination with the Multicast Source Discovery Protocol (MSDP), whereas
SSM deploys IGMPv3/MLDv2 with source information and PIM-Source Specific Multicast as a
routing protocol.
The following section describes Any Source Multicast, Source Specific Multicast, related protocols
and general mechanisms to be deployed within an IP-Multicast enabled IPTV network.
9.1.1.1 Any Source Multicast
Any Source Multicast (ASM) is the classical variant and uses a model where all decisions are made
based on the multicast group address (G) only. Devices are able to join and leave multicast groups
in order to receive IPTV streams. The receivers do not have knowledge about the Multicast senders
within the network. When two IP Multicast senders are sending to the same IP Multicast group
address (G) and a client joins (G), the client receives traffic from both IP Multicast senders.
Sender S1
G

Receiver
Sender S2
Join (*, G) G
Any Source Multicast
enabled IPTV Network
Sender S3
G

Figure 9-1: Any Source Multicast

This model has some significant drawbacks for IPTV deployment:

1. Addressing: Due to the fact that only the IP Multicast address is used it is not possible
to distinguish different senders on the network level. Therefore it is necessary to
implement an entity which manages the use of IP Multicast addresses. This slows the
deployment down because to setup new IPTV channels or change existing IPTV
channels it is necessary to obtain a free (unused) IP Multicast address.
 - 24 -
FG IPTV-DOC-0190

2. Security: In a group based model it is easy to disturb existing IPTV channels by simply
sending traffic to the same group address. To avoid those attacks complex filter
mechanisms are needed at the ingress and/or egress points of the network (and
potentially at customer’s premises to avoid unwanted and disturbing IP Multicast
traffic).
3. Redundancy: On the network level Any Source Multicast usually deploys PIM-SM
(Protocol Independent Multicast – Sparse Mode) a central Rendezvous Point (RP) which
represents a single point of failure. To overcome this problem redundant RPs and
additional protocols are necessary.
4. Complexity: Taking 1-3 into account (as well as some other drawbacks) the use of Any
Source Multicast adds complexity. To reduce the complexity and to overcome the
problems with ASM a new model “Source Specific Multicast” was developed.
9.1.1.2 Source Specific Multicast
Source Specific was developed to overcome the problems encountered by Any Source Multicast.
The main difference between the two models is the use of the source address of the multicast
sender. In contrast to ASM with SSM it is possible to distinguish between a sender (S1) and a
sender (S2) sending to the same IP Multicast address (G). Receivers not only specify the group
address G but also the address of the sender (S), resulting in an IP Multicast channel (S,G). Because
the Unicast address within a network uniquely identifies an end system, the combination of (S,G) is
unique as well. A receiver joining (S1, G) does not receive the traffic from another system sending
to the same IP Multicast address.
Sender S1
G

Receiver
Sender S2
Join (S1, G) G
Source Specific Multicast
enabled IPTV Network
Sender S3
G

Figure 9-2: Source Specific Multicast

Source Specific Multicast solves the following problems:

 Addressing: It is no longer necessary to centrally coordinate the use of IP Multicast
addresses. Any sender can send to any existing IP Multicast group. The network and the
receivers are able to specify a particular sender using an IP Multicast group. IP Multicast
channels (S,G) are handled and routed individually by the network and the clients as
well.
 Security: Denial of Service (DoS) attacks by simply sending to a Multicast group which
is already in use, are no longer possible, because individual senders can be distinguished.
 Complexity: Source Specific Multicast reduces the overall complexity within IPTV. It
solves several issues related to security and addressing and also removes the need for
centralized Rendezvous Points.
 - 25 -
FG IPTV-DOC-0190

SSM is also optimized for One-to-Many deployment scenarios which are typically used within
IPTV. In addition ASM and SSM can be used in parallel (deploying different address ranges) if
necessary. The use of SSM eases the deployment of IPTV and reduces the complexity, allowing
more flexible IPTV services. The IETF has assigned the default address space 232/8 for the use
with Source Specific Multicast.
9.1.2 Multicast group management in access node
Internet Group Management Protocol
IGMP is used between an IP-Multicast capable end system (e.g. IPTV Terminal Device) and a IP-
Multicast capable router. IGMP is available in different versions: IGMPv1, IGMPv2 and IGMPv3.
IGMP is used by end systems to join and leave IP-Multicast groups or channels (depending on the
IGMP version).
 IGMPv1 (RFC1112): IGMPv1 is the oldest version of IGMPv1. Due to the fact that
IGMPv1 does not support a “Leave Message”, IGMPv1 in not widely implemented and was
replaced by IGMPv2/IGMPv3. IGMPv1 supports only the ASM model.
 IGMPv2 (RFC2236)/MLDv1 (RFC2710): IGMPv2 added the capability of end system to
leave a Multicast group by sending a “Leave Messages” to the next node. IGMPv2/MLDv1
supports only the ASM model; both protocols are widely deployed today.
 IGMPv3 (RFC3376)/MLDv2 (RFC3810): The main difference is the support of filter
mechanisms (exclude/include filter) to support Source Specific Multicast. IGMPv3/MLDv2
supports the ASM and the SSM service model.
IGMP transparent snooping
IGMP snooping optimizes the distribution of multicast within an IEEE 802.1 bridging domain so
multicast traffic is only sent on bridge ports where there are known to be active receivers and/or
multicast routers. IGMP snooping functionality resides on IEEE bridging devices that connect
IGMP hosts to IGMP routers and consists of two main components. The first function is the IGMP
snooping control section which:
1) Monitors IGMP messages (and optionally other multicast router messages, such as PIM or
DVMRP hello packets), to determine the port location of the multicast routers and active receivers
within an IEEE bridged domain.
2) Builds per port, per VLAN multicast forwarding tables
3) Maintains basic IGMP membership state on non-router ports to determine when a forwarding
entry should be removed.
The second function is the data forwarding section which:
1) Forwards packets in the 224.0.0.0/24 range which are not IGMP messages on all ports.
2) Forwards multicast packets with a destination IP address outside 224.0.0.0/24, which are not
IGMP according to per VLAN, per port multicast forwarding tables.
This basic mode of operation is often referred to as “transparent IGMP snooping” and does not
absorb, nor alter, nor generate IGMP messages when performing the above functions.
IGMP proxy
IGMP proxy is a function to reduce the number of IGMP/MLD messages in a network and to
enable a device to communicate with a Multicast enabled router without using a IP-Multicast
routing protocol.
 - 26 -
FG IPTV-DOC-0190

Figure 9-3: IGMP proxy functional description

If more than one upstream interface is available (e.g. different VLANs) the following rules apply:
 “Simple Mode”, only one Upstream Interface for IGMP/Multicast”: If only one
upstream interface needs to support Multicast/IGMP it should be possible to select the proxy
interface by static configuration or a dynamic mechanism like a Multicast default route
using the DHCP option 121 (Classless Static Route Option).
 “Extended Mode”, different Upstream Interfaces for IGMP/Multicast: More than one
upstream interface needs to support Multicast/IGMP (e.g. different service VLANs). In this
scenario the Multicast groups/Multicast channels need to be configured on the
corresponding interfaces; e.g. 239/8 on interface #1 and 232/8 on interface #2. The proxy
needs to separate the address spaces, e.g. an IGMP report on interface #1 must not include
information about multicast groups/channels on interface #2. The device must support a
mechanism to configure (assign) the multicast groups/channels to the corresponding
upstream interfaces. This can be done by using static configuration (pre configured device,
using a GUI, etc.) or a dynamic mechanism.
 “Forking Mode”: In this mode IGMP reports are sent to more than one upstream interface.
Queries will be answered on all upstream interfaces which are configured for “Forking
Mode”; reports include information about all Multicast groups/channels the CPE is
subscribed to. It is within the responsibility of the receivers of the membership reports to
take action on the received reports. In a standard scenario only one of the receivers will
forward multicast traffic to avoid duplicate traffic. Other network components can act on the
membership reports (e.g. change filters or QoS settings) without forwarding the traffic (see
Figure 9-4Error: Reference source not found).

)
.2.3
39.1
1. 1.1,2
.
r (10
fic fo
Traf P Multicast Router #1
IGM
forwards traffic
IGMP Join (10.1.1.1, 239.1.2.3)
from STB IGM
CPE with IGMP Proxy/Forking P
and two Upstream Interfaces

Multicast Router #2
drops IGMP, does not
forward traffic

Figure 9-4: IGMP Proxy in Forking Mode

 - 27 -
FG IPTV-DOC-0190

Fast Leave / Immediate Leave

A function associated with IGMP snooping or IGMP routing whereby the switch or router stops
sending immediately the multicast stream when receiving an IGMP leave for the last member on
this requesting interface, i.e. without sending one or more group specific queries and waiting for its
timeout.

9.2 IPTV multicast QoS

9.2.1 Types of IPTV multicast QoS

There are two types of QoS for IPTV multicast.
As the first type of QoS for IPTV multicast, the following should be considered.
 IPTV network is recommended to support of handling multicast traffic differently according
to the requested QoS treatment.
 For differentiated handling of multicast traffic, congestion avoidance and congestion
management mechanism are required because network congestion may cause quality
degradation of IPTV service.
- IPTV network is recommended to support congestion avoidance mechanism to prevent
multicast traffic from being dropped over other lower classes of traffic.
- IPTV network is recommended to support congestion management mechanism to
prioritize multicast traffic over other classes of traffic.
IPTV network is recommended to provide a certain level of QoS when delivering IPTV service
traffic to IPTV end-users. Resource reservation is necessary to guarantee the QoS of IPTV
multicast and congestion control is necessary to maintain the QoS of IPTV multicast. IPTV
network can guarantee QoS by using of resource pre-reservation mechanism. Pre-reserving
mechanism is more efficient than dynamic resource reservation mechanism in that dynamic
reservation mechanism needs to manage dynamic membership with many receivers. Moreover,
pre-reserving mechanism is simple to control and maintain multicast resources
As the second type of QoS for IPTV multicast, IPTV multicast network is recommended to provide
capabilities to ensure sufficient availability for IPTV services.
 IPTV multicast network is recommended to be restored without service intervention in the
event of multicast mechanism abnormalities.
 IPTV multicast network is recommended Multicast distribution trees shall be dynamically
restored in the event of multicast mechanism failures.
 IPTV multicast network is recommended to be fully redundant for avoiding a single point of
failure affects the whole IPTV service.
 IPTV multicast network is recommended to be distributed in a load balanced manner in
order to utilize multicast links efficiently.
9.2.2 QoS aware topology for IPTV multicast service
9.2.2.1 Optimal RP (Rendezvous Point) positioning and RP redundancy
Location of RP affects not only multicast service delay, but also multicast network stability.
Rendezvous point is recommended to support optimal RP positioning; optimal RP positioning
depends upon Service Providers’ network topology and their multicast traffic path which taken
consideration of followings:
 - 28 -
FG IPTV-DOC-0190

 Loop free, delay/jitter independent, stability guarantee topology

 Optimal position to exchange source active information amongst multicast service provider
One of main reasons to apply multicast is to reduce backbone traffic produced by redundant
customers’ request, so it is advantageous to locate RP near the source compare to locate it
somewhere in middle of backbone
Rendezvous point is recommended to support RP redundancy mechanism; IPTV network should be
guaranteed optimized RP redundancy to improve IPTV service stability in case of RP failure. IPTV
network should be designed their RP mechanism not only to maximize service stability, but also to
minimize service recovery time during RP failure.
Once multicast based IPTV Service Providers decide optimal RP position in their multicast
network, they need to consider how to configure RP to maximize service efficiency. There are
basically two ways of selecting RP, one is dynamic RP selection, and the other is static RP
selection. It is often difficult to define one way is superior to the other such that multicast based
IPTV Service Providers should decide which way is the best practice for their own multicast
network. When multicast based IPTV Service Providers design their RP, they should consider the
followings.
 Service recovery time in RP failure. When there happened RP failure, it should minimize
their service recovery time. Normally static RP recovers compare to dynamic RP.
 Operation issues: Configuration & Troubleshooting. RP should be designed in a way that it
should not bring too much operational overhead and should be advantageous to
troubleshooting. In case of static RP, all routers running multicast routing protocol, such as
PIM-SM, must include adequate configuration to designate their RP. However, dynamic RP
does not require duplicate of configuration for all routers. For troubleshooting, dynamic RP
normally require much more complicated steps to track the problem whereas static RP is
relative much simpler to troubleshoot.
 Feasibility issues: Vendor status. When selecting RP with a dynamic way, one thing to keep
in mind is, it should always select an identical RP for the groups in a network. RP for a
group “A” should be RP “A”, it cannot be any other RP for that group. When selecting RP
with a dynamic way, router vendors use some algorithm to select a primary RP among their
RP candidates, but it could be compatibility issues among vendors. So it is essential to check
if they all work with an expected manner.

Anycast RP has been widely adopted in existing IPTV multicast solutions to get service robustness
and scalability，as well as load-balancing. The best working examples of anycast RP in IPTV is
Anycast RP redundancy and anycast source. The Anycast RP mechanism is intended to address the
need for better fail-over (convergence time) and load sharing of source register messages among
RPs in a domain.
9.2.2.2 Load balancing of IPTV multicast
When multicast routers receive a join message, multicast routing protocol normally send its join
message to one of the multicast interfaces. If some groups have the same source, among multiple
multicast interfaces, only one of them is selected and sends the join. In an Equal Cost Multiple Path
(ECMP) environment, all multicast interfaces cannot be used to distribute multicast traffic; instead
only single interface is used. To load share the traffic, multicast source should be distributed for
different groups, and IPTV service provider should be considered for this load sharing
requirements.
 - 29 -
FG IPTV-DOC-0190

 IPTV multicast source is recommended to be distributed to different groups to support load

balancing.
9.2.2.3 Multiple multicast trees of IPTV multicast
Multiple multicast trees include many multicast trees with each tree being constructed from the
multicast source to the receivers and multicast data being delivered among all the multicast trees.
 In multiple multicast trees, every host is recommended to be assigned with equal or similar
level of load to handle equal or similar number of input / output data flows.
 In multiple multicast trees, each host is recommended to be assigned to have minimum
number of children nodes to avoid a single point failure.
 In multiple multicast trees, node positions are recommended to consider the corresponding
hosts capabilities and behaviours. The hosts with higher capabilities for multicast and stable
behaviours are more likely to occupy important positions on the multicast trees.

9.3 IPTV multicast interoperability among service providers

In IPTV markets, there will be various types of service providers; like IPTV transport provider,
content provider, and contents aggregator. Each service provider need service combination of
different type of service providers or need the clear contract with other service provider to get the
quick service spreading. With such a clear internetworking contract amongst IPTV service
providers, user can get any sources from content providers through the IPTV transport provider, and
we can make IPTV service popular.
IPTV service provider should provide capabilities for exchanging IPTV service information
between different IPTV service providers for the interoperability. Especially, for IPTV multicast
interoperability, the fundamental IPTV service information for each IPTV service provider should
be announced to each SP. The purpose of IPTV service information exchange is to share the IPTV
source information received from all IPTV service providers in multicast based IPTV service
environment.
Note: For further study, we need the definition of the IPTV service information for IPTV multicast
interoperability.
The IPTV service information for IPTV multicast interoperability can include ID of content
aggregator or content provider, source IP address block, multicast group information, service start
and end time, QoS/QoE information, traffic rate, video encoding rate.
The following can be considered as the functional requirements to handle multicast address
interoperability.
 The assignment of multicast address for each IPTV service channel is recommended to be
agreed between different IPTV networks for interoperability; for instance, the multicast
address for each IPTV service channel could be unique between different IPTV networks, or
optionally changeable when entering other IPTV network.
 IPv4 multicast addresses of [IETF RFC 3180] range (GLOP addressing in 233/8) are
recommended to use to support interoperable multicast channels.
 IPv4 multicast addresses of [IETF RFC 3138] range (Extended Assignments in 233/8) or
[IETF RFC 2365] range (Administratively scoped block) can be used if there is an
agreement between peering IPTV SPs.
 IP multicast address ranges of [IETF RFC 4607]: Source-Specific Multicast for IP] is
recommended to be supported to use Source Specific Multicast.
 - 30 -
FG IPTV-DOC-0190

Each IPTV Service Provider may have its own multicast address policy and the policy of IPTV SP’s
internal multicast address may not match the inter-Service Provider address policy. Therefore, the
following is recommended to be supported;
 IPTV Service Provider is recommended to support translating multicast addresses from
other IPTV Service Provider to its internal multicast address; the multicast address
translation policy is up to IPTV Service Provider.
 IPv6 multicast addresses of [IETF RFC 3307] range (Allocation Guidelines for IPv6
Multicast Addresses) are recommended to support interoperable multicast channels.
The following can be considered for multicast routing interoperability.
 Multicast BGP between different IPTV service providers is recommended to advertise
multicast source routes. Multicast border gateway protocol (MBGP) is used to advertise
multicast source routes for RPF check. Followings should be considered as the peering
policy that MBGP is using for multicast routing protocol between IPTV service providers.
- Advertising summarized prefixes if possible
- Recommended route filtering policy like default routing information, private addresses
defined by [IETF RFC 1918], all Multicast groups(224/4), ISP’s unicast prefix range
from peer ISP,
- AS Path filtering
- Maximum prefix limit
- Md5 authentication between MBGP peers
 Source active filtering of Multicast Source Discovery protocol (MSDP) is recommended to
use to prevent bogus (S, G) from sending when MSDP is applied. When the MSDP is used
between IPTV Service Providers for their multicast service, MSDP source active filter is
necessary to prevent bogus (S, G) from sending. Followings should be taken care as the
MSDP filtering policy that MBGP is used for multicast routing protocol between IPTV SPs.
- Domain-local multicast applications
- Auto-RP groups
- Administratively scoped groups(239/8)
- Default SSM range(232/8)
- Loopback addresses(127/8)
- Private addresses(RFC1918 range)
 IPTV service provider is recommended to protect its own IPTV network and IPTV source
against the malicious traffic injection from peering service providers (SPs). IPTV service
providers should protect their own IPTV network and IPTV source against the malicious
traffic injection from peering SPs. This function should be implemented in IPTV multicast
interoperability peering point. Followings should be considered as the security policy for
IPTV multicast interoperability.
- uRPF (unicast Reverse Path Forwarding) in peering interface
- Filtering about non-approved group range, source Block and non approved application
port numbers
- PIM (Protocol Independent Multicast) neighbour authentication
- TCP/ICMP message filtering for 224/4
- Protection against multicast source spoofing
- BSR (Bootstrap router) message filtering
- Capability to limit the maximum number of multicast routing information
 - 31 -
FG IPTV-DOC-0190

In IPTV multicast interoperability environment, IPTV service providers should provide the QoS
monitoring function to handle the IPTV service quality measurement, and also IPTV service
providers should provide the QoS management function to keep IPTV service in high quality.
 IPTV service provider is recommended to provide IPTV Service quality measurement and
management function for interoperability.

9.4 IPTV multicast management

9.4.1 IPTV multicast user management
As the current multicast protocol (i.e. IGMP) does not consider Multicast user authentication and
authorization, it is requested a further development of those functions to support IPTV services
efficiently.
Multicast user authentication function controls the authority for users to receive multicast flows.
And through authenticating multicast users, the network can distinguish legal multicast users from
the illegal ones and then can distribute the multicast traffic to the reasonable receivers. Following
procedures should be considered.
 When a user initiates a multicast “join” request to join a certain multicast group with an
account, the duplication point should not accept the request and make him join the group at
once, it should be sent the request to the authentication point.
 The authentication point inquires the account information database and returns the result to
multicast duplication point. The value of the user’s multicast property in the account should
be set by the service layer system.
 According to the authentication result returned from the authentication point, the Multicast
duplication Point should decide whether it allow the user to join the group or not. If allow
the user to join the group, the duplication will add it to distribution table. Whereas it will
refuse the user to join the group.

Figure 9-5: Functional components for Multicast user management

 - 32 -
FG IPTV-DOC-0190

9.4.2 IPTV multicast address management

According to IANA rule, several hundred millions of IPv4 and IPv6 multicast addresses can be used
in the internet. As one of important resources, these multicast addresses, should be managed
effectively.
9.4.2.1 IP multicast address transition
When deploying IPTV broadcasting services, carriers often use one multicast group address
representing an IPTV channel. Unlike the unicast addresses, multicast addresses are not distributed
depending on different countries, areas and carries all over the world. Therefore, during the
operating of IPTV broadcasting service, the corresponding relationship between IPTV channel and
multicast address can be overlapping or conflicting among different carriers or different service
areas of one carrier. As Error: Reference source not found Figure 9-6 shows, carrier A and carrier
B want to interconnect their IPTV direct broadcasting services; or Carrier B created local IPTV
broadcasting service platform in service areas C and D , where the local carriers should interconnect
some broadcasting service sources. With regard to these IPTV service traffic which cross multiple
multicast bearer domains, IPTV MST (multicast service stream transition) needs to be deployed at
the edge of each bearer network domain to check the multicast service traffic from other domains.
 Multicast address is recommended to be changed before entering local domain when there is
a multicast address conflicting.

Figure 9-6: IPTV multicast address transition

 IP multicast address mapping function is recommended to support end-user’s personal

broadcasting service.
 The use of Source Specific Multicast solves the problem with overlapping Multicast
addresses. In case of SSM a combination of a Multicast Group address and the Source
Address of the Multicast sender is used (this combination is unique and allows several
senders to use the same IP Multicast address). It is recommended to deploy Source Specific
Multicast.
9.4.2.2 The control of users’ multicast address
In order to control the development of multicast services on carrier’s network and avoid impact on
carriers’ IPTV broadcasting services, carriers can deploy multicast service controller to manage the
distribution of multicast address uniformly. However, as for the multicast application without
registration, carriers will restrict the usage of these multicast addresses at the access point of IPTV
 - 33 -
FG IPTV-DOC-0190

network. The procedures of applying for multicast service and multicast address are as follows and
shown as Figure 9-7Error: Reference source not found.

Figure 9-7: Control procedure of multicast address

1) In order to carry out services based upon multicast address users should arrange the inquiry
and registration on the PORTAL of carrier-provided Multicast Address and Service Control
Platform.
2) The self-service system check the situation of this multicast address from multicast address
policy controller
3) If this multicast address is available, users will be told that they are allowed to use it.
4) At the same time, multicast address policy controller sends policies to the access point to
allow the multicast services get access.
9.4.2.3 IPTV Multicast Address / Domain Name Management
The function of IPTV Multicast Address / Domain Name Management is an optional one for
network operators, to make their management of multicast address resources more efficiently and
easily. With this function, network operators do not allocate multicast IP addresses to multicast
channels of IPTV service providers directly, but register domain names of these channels, and bind
multicast addresses with their domain names dynamically.
 Multicast IP addresses are managed by network operators.
 Network operators can do domain name registration / deregistration on DNS servers.
 IPTV service providers negotiate domain names of their IPTV channels with network
operators.
 Network operators register domain names of IPTV channels with multicast addresses
dynamically assigned to these channels.
 - 34 -
FG IPTV-DOC-0190

 Network operators inform IPTV service providers about the domain names registered for
their IPTV channels.
 When network operators need to do multicast address management work, they just modify
domain name registration on DNS servers.
- Allocate a multicast address to an IPTV channel: register a domain name with a
multicast address for the IPTV channel.
- Revoke a multicast address from an IPTV channel: deregister the domain name of the
IPTV channel.
- Rearrange multicast addresses: modify domain name registration of IPTV channels.
 IPTV service providers get multicast address information of their IPTV channels by DNS
query, and send IPTV contents to those multicast addresses.
 End users access these IPTV channels by their domain names.
 Network operators can make use of domain name information of IPTV channels to do IPTV
service access control on both multicast sources (IPTV service providers) and multicast
group members (end users).
9.4.2.4 IPTV channel domain name management function for IPTV service providers
The function of IPTV channel domain name management is an optional one for IPTV service
providers, to represent their multicast IPTV channels with constant identifier – domain names,
rather than multicast IP addresses. With this function, IPTV service providers register domain
names of their multicast channels with the help of DNS service providers, and bind multicast IP
addresses with these domain names dynamically.
 Multicast resources (multicast IP addresses) for IPTV services are managed by network
operators.
 Network operators allocate multicast IP addresses to IPTV service providers, with which
IPTV service providers can carry their multicast channels into service.
 There are DNS service providers, who maintain DNS servers, and provide DNS services
(domain name registration, domain name query) to public.
 With the domain name registration service provided by DNS service providers, IPTV
service providers manage domain names of their multicast channels.
- Channel Registration: Register the domain name of an IPTV channel with a multicast IP
address got from network operators.
- Channel Deregistration: Deregister the domain name of an IPTV channel, and withdraw
the multicast IP address assigned to this channel.
- Channel Rearrangement: Modify domain name registration of IPTV channels.
 IPTV service providers represent their multicast channels with domain names when they
release URI information of these channels (such as in EPG).
 Multicast IPTV channel servers get address information of the channel by DNS query,
before broadcasting IPTV contents to the multicast address.
 End users access the multicast IPTV channels by their domain names.

Besides the obvious advantages of representing multicast IPTV channels with domain names, this
solution benefits IPTV service providers in 2 more aspects.
 - 35 -
FG IPTV-DOC-0190

 The solution makes it possible for IPTV service providers to represent multicast IPTV
channels with domain names even network operators do not deploy IPTV multicast address /
domain name management function.
 The solution provides an efficient way to IPTV service providers to manage their multicast
resources (multicast IP addresses) got from network operators dynamically. Rearranging
multicast addresses among their multicast IPTV channels has little impact on other aspects.
9.4.3 IPTV multicast service management
The packet transmission of IPTV Multicast service is usually provided based on UDP, so it can be
less-reliable than TCP based delivery. Because of that reason, we absolutely need to provide the
service management features including service monitoring one to guarantee the service reliability.
9.4.3.1 Definition of IPTV multicast service management
 IPTV multicast service is recommended to provide service monitoring features for the
service status management.
 IPTV multicast service is recommended to provide the statistics as the service reporting
feature.
 IPTV multicast service is recommended to manage each service STBs, stream servers,
management servers.
 IPTV multicast service is recommended to be capable of recovering or handling for the
specific host to get the poor service quality.
9.4.3.2 Necessary information for IPTV multicast service management
 Multicast Group information
- The multicast groups IP, port information are delivered from streaming server to clients
in the live broadcasting connection time. That information is used for checking whether
multicast group information is correct or not.
 Client information
- If the clients start to receive the live broadcasting data, IPTV service management server
can get the information of the each client’s IP, MAC addresses. That information is used
for checking the client’s status.
 Video type information
- When receiving live broadcasting, the clients get the video information like video size
and codec type which is received from the streaming server. That information is used for
video quality measurement data.
 Video Frame information
- With checking the timestamp and sequence number of the media data header, we can get
the exact time information about frame reception and remaking.
- The Sequence number is consecutive one, so the unusual increase can be regarded as the
case of IPTV service frame loss, so it can be used for service quality measurement
factor.
- From the decoding procedure of media data, we can get the I, P, B frame information
which can be used as service quality measurement information.
 Bitrate information
- The Bitrate information can be also used for IPTV service quality measurement factor
 - 36 -
FG IPTV-DOC-0190

 Bitrate (bit/sec) = data size / time

9.4.3.3 IPTV multicast service monitoring features
 For providing IPTV multicast service monitoring, IPTV multicast service is recommended
to provide the performance monitoring feature.
 And, IPTV multicast service is recommended to get the QoS performance data by
manipulating of above IPTV service management information.
 And QoS performance data is recommended to include the measurement values such as fps,
throughput, loss rate, delay, jitter.
 And, for the service monitoring, IPTV multicast service is also recommended to provide the
measurement value of the IPTV multicast service quality, in each period such as daily,
weekly, monthly basis.

10 Overlay multicast networking

This section describes the overlay multicast networking. It is recognized that the usage of the
overlay multicast networking described in this section for IPTV services requires further study.

10.1 Control framework for IPTV overlay multicast

IPTV overlay multicast networking consists of virtual network topologies on top of the physical
network, and it constructs and manages logical multicast path over the unicast/multicast physical
transport network.
In order to provide IPTV multicast function in overlay networks, it is necessary to perform
multicast session control and management for IPTV overlay multicast networking. The IPTV
overlay multicast can use diverse mechanisms for constructing different multicast trees depending
on IPTV applications or other requirements. The overlay IPTV multicast supports efficient routing
and resource usage by overlay multicast control.
In overlay IPTV multicast framework, a logical multicast control path will be created along the
logical delivery path, a multicast data delivery path is constructed over physical transport network,
and a logical multicast, the control path will be created along the logical delivery path for reliable
data transport. IPTV overlay multicast function is performed with cooperation among upstream and
downstream IPTV Multicast Agents (IMAs) at service level. IPTV multicast session management
(ISM) function at will be provided for multicast session configuration and maintenance at service
level. IPTV logical delivery path is established via ISM and IMA at service level, and IPTV
applications can work as if they were in a native IPTV multicast network.
Detailed description of control framework for IPTV overlay multicast are described in Appendix
III.
10.1.1 IPTV Session Manager (ISM)
ISM is involved in session configuration and maintenance for IPTV service flows. A single ISM
can handle one or multiple sessions simultaneously, and it can provide the following functionalities:
 Session initialization: ISM allocates ISID (IPTV Session ID) for new session.
 Session release: Session can be released as needed.
 Session membership management
 Session status monitoring: this function enables reporting of the status of data channel,
 - 37 -
FG IPTV-DOC-0190

monitoring of data throughput, gathering multicast protocol topology information

10.1.2 IPTV Multicast Agent (IMA )
IMA constructs overlay multicast delivery path over physical transport path, and forwards data
along the constructed physical transport path. An IMA consists of two functional modules,
multicast control module and multicast session control module. The main function of former is to
establish multicast delivery path and that of latter to setup multicast session along the paths
constructed by multicast session control module. IMA performs the control functions to exchange
control messages with other entities. Its major functions are as follows.
 Session join: each IMA contacts with Session Manager.
 Session leave: when an IMA wants leave the session, it gives notice to pIMAs and cIMAs
 Session maintenance: relay request and its response will be exchanged between the two
IMAs periodically.
 Loop detection & avoidance
 Partitioning detection & recovering
 Parent switching
 IPTV Session status reporting
In order to perform service level multicast of IPTV streaming applications, the functional blocks for
IPTV service control are shown as figure 11-9.

Figure 10-1: Functional blocks of IPTV session control for IPTV application services

10.1.3 IMA Backup

Because data stream will break if IMA goes out of work, it is important to deploy backup function
for IMA to guarantee service quality. The following IMA backup selection functions are required:
 IMAs broadcast their load status to other IMAs of multicast overlay.
 IMAs responsible for backup selection select backup IMAs based on the received load status.
 - 38 -
FG IPTV-DOC-0190

10.1.4 Media Signalling Proxy

Media signalling proxy is a function to get media status in overlay multicast network by transfer
media connection signalling between end hosts and obtain media session status of end hosts. In
order to get media status of overlay multicast network, media signalling proxy is may be supported
by IPTV overlay multicast system.

10.2 Functional framework for IPTV overlay multicast

10.2.1 Group membership management
The group membership for IPTV overlay multicast considers group size, number of group member
and rate of group membership change. Group membership management function provides the
function to create or maintain the multicast groups. If a multicast group in the physical transport
network is experiencing serious traffic explosion temporarily, the control function of IPTV overlay
multicast will be able to make a global group into multiple sub-groups to avoid the problems.
10.2.2 Admission control for QoS in IPTV overlay multicast network
In order to support QoS for IPTV services in overlay multicast network, resource control function
for IPTV overlay network will perform resource management and admission control function in
IPTV overlay multicast network.
10.2.3 Security for IPTV overlay multicast
IPTV overlay multicast uses shared network resource and multiple distributed overlay resources to
transport data. When a user requests IPTV service, security process needs for IPTV overlay
multicast function.
Overlay multicast confronts with various vulnerabilities and risks that impede from being widely
deployed in mission critical business systems and applications. There are three important security
challenges for the overlay network service model: Confidentiality and Integrity, Authenticity, and
Availability. These three important security challenges can be classified with some properties for
architectures and algorithms for building secure and scaleable information dissemination services
on IPTV overlay networks.
10.2.4 Node functions for IPTV overlay routing
An overlay multicast node function will be designated to perform overlay routing, contents
location control and distribution control function for IPTV services. The designated node has full
knowledge of other multicast node in the session, information on contents server and distribution
control information. In order to keep the updated information on multicast nodes, state updates
occur periodically via broadcasting among all multicast nodes.

10.3 QoS control in IPTV overlay multicast network

Resource control function for IPTV overlay multicast provides interface function for IPTV overlay
multicast QoS control between physical transport and IPTV overlay network. The function
performs collection and management of transport network resource (e.g., DiffServ) via specified
interface (e.g. SNMP)
QoS control function in IPTV overlay multicast network will also provide the measurement
function of overlay multicast performance to ensure high end-to-end IPTV service quality over
IPTV overlay sessions on selected appropriate overlay path. Network measurement includes
receiving, measurement and forwarding functions.
 - 39 -
FG IPTV-DOC-0190

 Receiving function receives measurement requests and forwards them to measurement

function.
 Measurement function measures network performance between network node and
aggregation node or different aggregation nodes based on measurement requests and
forwards results to forwarding function which feeds back results to overlay.
Detailed description of QoS control and resource control functions for IPTV overlay multicast are
described in Appendix II.
 - 40 -
FG IPTV-DOC-0190

Appendix I

IPTV multicast delivery solutions

(This appendix does not form an integral part of this document)

I.1 Hybrid P2P IPTV service multicast delivery solution

Figure I.1 shows the concept of Hybrid P2P IPTV service multicast delivery solution.
In this scheme, the receivers join in multicast group as usually. Then they need to form a P2P group
too. When a receiver find out that he has lost some IP packet, he can send a broadcast message to
his peers to request the lost packets. Then the fast response peer can send the lost packet to it. This
mechanism need the receiver caches some packet in case that it need to retransfer packet to the peer.
In this model multicast routers are control by SP, so SP can tightly manage the communication. P2P
groups does not involve node of SP , but it is need to limit the member in one group because too
many peer will aggravate the receivers’ burden.

Figure I.1: Hybrid P2P IPTV service multicast delivery

I.2 P2P CDN-based IPTV service multicast delivery solution

Figure I.2 shows a generalized distribution scheme with CDN that have the ability of P2P
distribution.
The main problem in this architecture is how to organize CDN servers in SP . In the traditional
CDN, it is based on Client/Server technology. Upstream node (i.e. Servers) can forward data to its
downstream nodes (i.e. Clients) which is not reversible. Even nodes in the same layer can not
exchange data. Nowadays, for the need to improve its high reliability to serve in network, CDN
 - 41 -
FG IPTV-DOC-0190

servers can exchange data from each other which even have P2P abilities according to the
distribution policy of CDN.

Figure I.2: Data distribution scheme with P2P CDN

 - 42 -
FG IPTV-DOC-0190

Appendix II
QoS and Resource Control Functions for IPTV Overlay Multicast
(This appendix does not form an integral part of this document)

II.1 Resource control function

If the information on IPTV transport networks is directly collected and managed by IPTV overlay
nodes to establish overlay transport route and configuration session topology, it will be serious
burden to handle overheads in IPTV overlay networks. It is assumed that resource control functions
for IPTV overlay network is located between IPTV overlay network and physical transport network,
and it performs collection of information about network resource and provides QoS control to
transport network.
As shown in figure II-1 it is necessary that resource control function is introduced to provide
interface function for IPTV overlay multicast QoS control between physical transport and IPTV
overlay network. This function performs collection and management of transport network resource
(e.g., DiffServ) via specified interface (e.g. SNMP). And overlay network nodes create tree
topology and optimized route to support QoS requirements of IPTV users through information
collected by Resource Control function. And RCF can have the interfaces such as COPS, Diameter
and H.248 to install/uninstall the policy decision for transport network. The interface between
overlay network and RCF will be further study, and its interface may be proprietary of IPTV service
providers.
The requirements for resource control are as follows
 The Resource Control Function will collect information for resource control from transport
network with periodic or a periodic. According to initiation of overlay network nodes,
Resource Control function collects data for resource and QoS control.
 Resource control should be able to communicate with Resource Control Function in
heterogeneous or other network.
 The following information collected is transferred to overlay network, and then overlay
network creates route and optimized tree to support QoS for IPTV overlay network.
- Link State Information: it includes available bandwidth information, delay, packet loss
and jitter of link.
- Routing Information: it includes routing algorithm that is used to transport network
equipments and routing information of them (e.g. neighbour routing information, routing
table .etc)
- Multicast Traffic Information: it includes multicast traffic parameters (e.g. channel
information, type of service, user profile, source content information) per channel or
session of IPTV multicast.
II.2 Resource control function for IPTV overlay multicast QoS in wired/wireless/mobile
networks.
The Session Manager configures routes among IPTV overlay network nodes and optimizes tree
topology for multicast sessions according to information of Resource Control Function. RCF has
resource information from transport network such as link state information, routing information,
multicast traffic information and so on. Session manager requests the resource information in
transport network to RCF. RCF verifies the resource status based on gathered information, and
 - 43 -
FG IPTV-DOC-0190

makes the policy decision for the request. Session manager confirms the received message from
RCF, and compares with service information. Then session manager sends the policy installing
request message to RCF. After receiving the policy request message, RCF sends the policy
installing request message to transport network through the configured path for overlay network.
Figure II-1 shows the application of Resource Control Function in wired/wireless/mobile networks
for IPTV overlay multicast QoS control.

Figure II-1: Application of resource control function in wired/wireless/mobile networks for

IPTV overlay multicast QoS control

II.3 Procedure to provide QoS and resource control functions for IPTV overlay multicast

When Session Manger requests information on overlay networking paths to Resource Control
Function, and Resource Control Function collects the transport network information using SNMP.
Resource Control provides the QoS and resource information of transport networks to Session
Manager. In order to compromise the requested requirements on QoS and resource availability of
IPTV overlay multicast paths, Session Manager may re-negotiate with Resource Control Function.
If the provisioning of Resource Control Function is not satisfied by Session Manager, it is ignored
and discarded. Figure II.12shows procedure to create IPTV overlay multicast service to be with
QoS requirements of IPTV overlay multicast paths in IPTV overlay network.
 - 44 -
FG IPTV-DOC-0190

Figure II.2: Procedure to create overlay multicast paths with Resource Reservation and
Control in IPTV Overlay Network

Figure II.3: Procedure to exchange control information for provision of QoS and resource
management in IPTV Overlay Network.
 - 45 -
FG IPTV-DOC-0190

Figure II.3 shows an example of procedure to exchange control information for provision of QoS
and resource management in IPTV Overlay Network (the same procedure of Figure II.2 is likely to
Figure II.2). The RCF in IPTV Overlay Network will have similar function with Policy Decision
Function. PDF performs control function based on the policies from network provider, service
provider or service control function to provide QoS and resource control function to IPTV
information delivery path.
The request for resource reservation and QoS control function on physical transport paths, which
are mapped with logical paths in IPTV overlay network, is initiated by Session Manager, and
delivered to PDF in RCF. PDF installs the policies on physical transport network, and it performs
resource control function on the physical paths. The procedures in Figure II.1 and Figure II.2 are as
follow.
- When IPTV overlay multicast is requested from CPE/CPN, overlay node search the originating
node of contents, and forwards the information of the originating node to Session Manager.
(①~②)
- Session Manager requests the Resource Control Function for the paths in accordance with IPTV
session and service requirements. (③)
- If the requested requirements are met with the physical transport network, Resource Control
Function confirms the resource reservation of the transport network, and applies a policy in
accordance with the requests of Session Manager. (④~⑤)
- Resource Control Function sends the message to install the policy to transport network
according to configured overlay multicast paths. (⑥~⑦)
- Session Manager notifies the configured path to overlay node and confirmation notification will
be sent to the CPE/CPN. (⑨~⑩)

II.4 Network measurement function

In IPTV overlay multicast, the multicast path is constructed between overlay nodes in the
application layer to perform media deliver functions. In order to ensure high end-to-end service
quality of the IPTV services, overlay multicast measurement system needs to be deployed to
measure the IP network performance, e.g. bandwidth, packet loss between overlay nodes such that
the appropriate overlay path is selected.
As shown in Figure II-4, as part of resource control, network measurement functions include
receiving function, measurement function and forwarding function:
 Receiving function receives measurement requests from session manager and forwards them
to measurement function.
 Measurement function measures the network performance between network node and
aggregation node or a different aggregation node based on the above measurement requests
and forwards the results to forwarding function.
 Forwarding function sends the results to overlay network or other network measurement to
share information.
 - 46 -
FG IPTV-DOC-0190

overlay network
overlay network

receiving forwarding
Resource control
function
measuring

IP network
IP network

Figure II-4: Network Measurement Functions

 - 47 -
FG IPTV-DOC-0190

APPENDIX III

Control Framework for IPTV Overlay Multicast

(This appendix does not form an integral part of this document)

III.1 IMA backup

In IPTV overlay multicast, IMA is deployed to control the construction of multicast session and
deliver data among the overlay. Data stream will break if IMA goes out of work. So it is important
to deploy backup function for IMA to guarantee service quality.
As shown in figure III-1, nodes of overlay multicast will report its status to others. The report path
could be different according to different IMA selection mechanism. For a node (IMA or terminal),
report will be transferred to the siblings if backup IMA is selected among siblings or transferred
only to PIMA if backup IMA is selected by PIMA. In other scenario, reports will be transferred
only to IMA if IMA selects its backup itself or IMAs may even exchange data packets among their
siblings to backup each other.
P IMA

re port re port
CIMA CIMA

re port re port re port

te rmina l te rmina l te rmina l

Figure III-1: IMA backup function

Whatever the backup selection mechanism is, following IMA backup selection functions are
required:
 IMAs broadcast their load status to other IMAs of multicast overlay.
 IMAs responsible for backup selection select backup IMAs based on the received load
status.

III.2 Media signalling proxy

In IPTV overlay multicast, media is connected between end users. If media signalling is directly
transferred between end users, IPTV system could not get the exact media connection status to
perform related functions such as accounting for each user. It is proposed that media signalling
proxy for overlay multicast is located between each two end users to perform media protocol proxy
for each two users, hence could report media connection status.
Media signalling proxy is a function to get media status in overlay multicast network by transfer
media connection signalling between end hosts and obtain media session status of end hosts.
 - 48 -
FG IPTV-DOC-0190

In order to get media status of overlay multicast network, media signalling proxy is recommended
to be supported by IPTV overlay multicast system. Figure II-2 shows how media signalling proxy
operates.

IMA

Media Signaling Proxy

(RTSP
Medi proxy)
signallin prox Media
a g
(RTSP
y
Signaling &
proxy)
Connection
RTSP RTSP Status

End
End users
users End
End usersusers

Figure III-2: Media signalling proxy

 - 49 -
FG IPTV-DOC-0190

APPENDIX IV

A Scenario for Service Control Function of Session Manager in IPTV Overlay

Multicast Network

The service control function for IPTV in overlay multicast networking is to provide resource
Request/Release function for IPTV services to Resource Control Function, IPTV service access
control function to Resource Control Function, and to request content delivery control function to
Content Delivery Control Function of IPTV architecture. In order to provide IPTV service control
function, Session Manager in IPTV overlay network performs the following functions:
- Service Resource Request/Release: Session Manger requests resource reservation/release of
transport network to create/terminate IPTV overlay session according to IPTV service
requirements.
- Service Access Control: Session Manager allows IPTV service access to authenticated IPTV
users according to their access rights, subscriber profiles and network policy etc.
- Request Content Delivery Control Function: Session Manager requests the location of
appropriate IPTV content server which can deliver IPTV overlay multicast service to IPTV
user.
Session Manager is cooperated with Content Delivery Control Functions and Resource Control
Function as shown in Figure 1. Content Delivery Control Functions is used to identify appropriate
IPTV content server to deliver IPTV overlay multicast service to the IPTV user. Resource Control
Function provides resource reservation/release between the IPTV server and IPTV user when
Session Manager requests a message to configure and optimize IPTV overlay multicast network.
Each functional entity as shown in Figure 1 is corresponded with functions of IPTV architecture.

Figure III-1: Functional entity for IPTV overlay multicast networking

 - 50 -
FG IPTV-DOC-0190

Figure 2 shows procedure to perform service control function for IPTV in overlay multicast
networking.
- When IPTV overlay multicast service is requested from IPTV user, Content Delivery
Control Functions will search appropriate IPTV content server. It forwards IPTV user’s
request which is contained the location of the IPTV content server and IPTV service
requirements to Session Manager. (①)
- Session Manager in IPTV overlay multicast networking derives the IPTV service parameter
from the IPTV user’s request and it performs authentication between end IPTV user and the
IPTV overlay multicast service. Session Manager requests resource reservation of path
between the IPTV server and IPTV user to Resource Control Function. (②)
- Resource Control Function reserves optimal delivery path according to IPTV service
requirements and network policy after it observes the resource information of transport
network. And it sends result of reserved path to Session Manager. (③)
- Session Manager creates/updates the IPTV overlay session according to reserved delivery
path by Resource Control Function. It notifies the configured path to Content Delivery
Control Functions. Content Delivery Control Functions will update managing IPTV service
information according to the result of IPTV overlay session configuration. (④)

Figure III-2: Example scenario of service control in IPTV overlay multicast networking

________________