Application Note

Deploying IPTV and Videoon-demand (VoD)

Using
FlexLights GPON Systems

IPTV Applications v3.doc

Table of Content
1.
2.
2.1.
2.2.
3.
3.1.
3.2.
3.3.
4.
4.1.
4.2.
5.
5.1.
5.2.
5.3.
5.4.

Abstract ................................................................................................................................. 3
Broadcast IPTV and VOD Service Architecture...................................................................... 4
Services description................................................................................................................ 4
IPTV Services Network Architecture ...................................................................................... 5
SDV Services Provisioning................................................................................................... 10
Global Network Provisioning Steps....................................................................................... 10
Per-SDV Subscriber provisioning steps................................................................................. 12
QoS for SDV Services.......................................................................................................... 15
IGMP in the 2500LT ............................................................................................................ 16
Overview.............................................................................................................................. 16
Optimate IPTV Zapping Time Test Results....................................................................... 17
Annex - IP Multicast Technology overview........................................................................... 20
The IP Multicast Group Concept .......................................................................................... 21
IP Multicast Forwarding....................................................................................................... 21
IGMP protocol ..................................................................................................................... 21
IP Multicast Group Addresses .............................................................................................. 22

Table of figures
Figure 1: Typical IPTV and VoD Service network architecture........................................................ 5
Figure 2: IPTV VoD Content Provider Network Headend ............................................................. 6
Figure 3: Regional backbone Network............................................................................................. 7
Figure 4: GPON Distribution/Access Network ................................................................................ 8
Figure 5: Triple-Play Home Network with IPTV and VoD Services ................................................. 9
Figure 6: Optimate IPTV focused IGMP Snooping Test bed ...................................................... 17
Figure 7: IPTV Test configuration................................................................................................. 17
Figure 8: IPTV Test results Join/Leave/channel change Latency ................................................. 19
Figure 8: IPTV Test results Results summary............................................................................. 19
Figure 6: IP Multicast network serving Video over IP application .................................................. 20
Figure 11: IP Multicast address to MAC address mapping............................................................. 23
Figure 12: Two Multicast streams transmitted selectively to requesting ports only..Error! Bookmark
not defined.

Page 2 of 23

FlexLight-Networks

IPTV Applications v3.doc

1. Abstract
Flexlight Optimate GPON system with its 2.5Gbps GPON Downstream BW capacity is
perfectly equipped for servicing broadcast IPTV and Video-On-Demand (VOD) TV content.
This paper helps service providers understand the environment under which both Broadcast
IPTV and VOD services are deployed and realize the exact role of Optimate in efficiently
delivering these services to the customer premises.
To ensure successful IPTV and Video-On-Demand (VoD) implementation, Optimates users
should be well familiar with both IPTV and VOD services architecture and understand the
Optimate service-provisioning scheme for those services.
This application note depicts the service architecture then it describes steps for provisioning
both IPTV and VoD services.

Page 3 of 23

FlexLight-Networks

IPTV Applications v3.doc

2. Broadcast IPTV and VOD Service Architecture

2.1.

Services description

Switched Digital Video (SDV) is a term used for describing Broadcast IPTV and Video-OnDemand (VOD) services provisioning over Data Networks.
2.1.1.
Broadcast IPTV Service
Broadcast IPTV is all about transferring broadcast TV channels over Data Networks.
Broadcast IPTV utilizes IP Multicast1 for distribution of broadcasted TV channel digital
Video and Audio information on a single RTP-over-UDP-over-IP multicast stream to
multiple destinations. With IP Multicast a single stream is flowing through the network and
being duplicated towards multiple egress destination ports on each and every network node
(I.e. IP Router or Ethernet Bridge) along the path to each destination subscriber. This
behavior enables IP Multicast efficiently utilize the network BW resources (As opposed to
delivering a single IP stream per client).
The sources of Broadcast IPTV information are video processors that convert nonpacketized digital video stream resources (e.g. live TV channels) to IP Multicast streams.
IPTV client hosts use Internet Group Management Protocol (IGMP) to join or leave as
listeners of a specific IP Multicast stream. IPTV servers use IGMP to declare being source
for each IP Multicast stream they originate.
A detailed chapter about IPTV provisioning will further explain how IP Multicast is used to
deliver IPTV.
2.1.2.
Video-On-Demand Services
Video-On-Demand (VoD) enables each individual customer on a single Set-Top-Box (STB)
to view a program from a selection of pre-recorded video content (e.g. a movie, recorded
show etc).
The customer may choose to view the selected video content anytime and be able to have a
VCR like control (e.g. play/pause, Rewind and fast forward etc.) while watching. This
requires transmission of a dedicated video content stream to the client STB.
Distribution of VoD, utilizes Unicast IP, which requires dedicated BW resources perwatching client all the way through the path from the Video Server to the client STB.

Refer to ANNEX I for an in-depth IP Multicast tutorial.

Page 4 of 23

FlexLight-Networks

IPTV Applications v3.doc

2.2.

IPTV Services Network Architecture

The IPTV and VOD network topology is a four-tier network hierarchy including
The IPTV and VOD Application Service Provider Network (Head-end)
Regional Backbone & Metro Network
Access Network
Client Premises Network.
Note that in some cases the VoD Content Provider may position secondary VoD server farms
in proximity to major access distributed network clouds for reasons that will be later
explained.
Network
Service
Provider (NSP)
Network
(e.g. ISPs)
Backbone /
Metro
Network

OLT
(Access
Node)

IPTV/VoD
Application
Service
Provider (ASP)
Network
(Headend)

Content Provider
Network

Backbone & Metor

Network

ONT

Customer
Premises
Network

ONT

Customer
Premises
Network

ONT

Customer
Premises
Network

Access Network

CPE

Figure 1: Typical IPTV and VoD Service network architecture

Page 5 of 23

FlexLight-Networks

IPTV Applications v3.doc

2.2.1.
Video Content Service Provider Network The Head End
The top tier of the IPTV Network Architecture is the Video Content Service Provider
Network the source of the digital Video content, known also as the IPTV Headend.
Live Digital video content arrives at the Headend by satellite receivers or via other dedicated
data networks and is being processed into IP Multicast MPEG encoded streams.
Recorded Digital Video information is kept in Video Servers in the Headend itself or in
secondary Headend sites for redundancy, scalability and performance reasons..

Network
Service
Provider (NSP)
Network
(e.g. ISPs)
Regional
Backbone
Network

OLT
(Access
Node)

IPTV/VoD
Application
Service
Provider (ASP)
Network
(Headend)

Content Provider
Network

Video
Network
DB

Customer
Premises
Network

ONT

Customer
Premises
Network

ONT

Customer
Premises
Network

Distribution
(access) Network

Backbone

Video Servers

ONT

DHCP Server

IP Multicast
Router
IGMP Querier

Backbone
CPE
Network
(GbE)

Aggregation
Switch

Live Video
Satellite dish
IP/TV Stream Generator

Figure 2: IPTV VoD Content Provider Network Headend

Besides digital video sources the Headend also include several IPTV and VoD Services
supporting components:
A DHCP Server and a RADIUS Server. The DHCP Server is aimed at providing the
end client STB with IP addresses based on credibility information found in the DHCP
queries and based on service access control authentication and authorization policies
kept in the Radius Server.
An IP Multicast Router, which function as an IGMP Querier.
IPTV & VoD Services management tools used for Services Packages Access Control,
subscriber billing information collection etc are running on a dedicated host or
group of hosts.

Page 6 of 23

FlexLight-Networks

IPTV Applications v3.doc

2.2.2.
Backbone/Metro Network
The Backbone & Metro Network interconnects Application and Content Service Providers
(ASPs) (e.g. IPTV Service Providers) as well as Network Service Providers (NSP) (e.g.
ISPs) on one side to the GPON Access Network, to which the subscribers are connected.
The Backbone is usually associated with Metropolitan Networks that runs various Ethernet
over SONET/SDH or Resilient Packet Ring (IEEE 802.17s RPR) networks.
The dedicated IPTV backbone Layer 2 switched cloud infrastructure (usually implemented by
dedicated VLAN) interconnects the GPON distribution network access node (I.e. OLT)
with the Video Content provider Headend aggregation switch. The IPTV and VoD content
provider must provide such dedicated IPTV VoD VLAN with the exact downstream
bandwidth resources needed for the worst case Bandwidth consumption scenario planned.
Note that over subscription is unacceptable for Video streaming applications. Additionally,
digital streams QoS in terms of constant and minimal delay must be ensured.
Network
Service
Provider (NSP)
Network
(e.g. ISPs)
Regional
Backbone
Network

OLT
(Access
Node)

IPTV/VoD
Application
Service
Provider (ASP)
Network
(Headend)

Content Provider
Network

Network Backbone

ONT

Customer
Premises
Network

ONT

Customer
Premises
Network

ONT

Customer
Premises
Network

Distribution
(access) Network

CPE

MSPP

Metro Ethernet/SDH/SONET
BackBone

ASP
Aggregation
Switch

OLT
MSPP

MSPP

Figure 3: Regional backbone Network

Since the Regional Backbone infrastructure is assumed to be composed of Layer 2 switches

IP Multicast forwarding must be controlled by utilizing IGMP snooping or IGMP proxy to
ensure distribution of IP Multicast streams only to active listeners.

Page 7 of 23

FlexLight-Networks

IPTV Applications v3.doc

2.2.3.
Access Network
The GPON Access Network connects the end-users with the Regional Backbone Network,
which in turn is connected to the Service providers. The regional Metro/Backbone network is
connected via the OLT uplink ports to the Regional Backbone Network while the ONT UNI
(User to Network Interface) ports are connected to the subscriber home network equipment.
The OLT must run IGMP snooping or IGMP proxy to ensure forwarding of the IP Multicast
streams only to those subscribers entitled to. GPON is equipped with a Single Multicast
Copy (SMC) capability, which enables to optimally utilize the GPON downstream shared
media Bandwidth resources. SMC basically caters for one copy of the multicast stream to be
transmitted downstream over the PON. The ONT is allowed to process and forward its own
unique dedicated Port-ID as well as the multicast Port-ID.
Being at the Edge of the Provider Network the GPON Access Network is perfectly
positioned to enforce per-subscriber Service Level agreement. IPTV and VoD Service
Agreement enforcement usually involves in making sure the client runs the exact number of
STB he is paying for and listens only to those channel packages he subscribed.

Network
Service
Provider (NSP)
Network
(e.g. ISPs)
Regional
Backbone
Network

OLT
(Access
Node)

IPTV/VoD
Application
Service
Provider (ASP)
Network
(Headend)

Content Provider
Network

Network Backbone

ONT

Customer
Premises
Network

ONT

Customer
Premises
Network

ONT

Customer
Premises
Network

Distribution
(access) Network

CPE

Figure 4: GPON Distribution/Access Network

Typically, the ONT located at the Home will be connected via a single Ethernet port to a
STB or residential gateway. The Access Network also utilizes various technical measures to
enable all triple-play services share the same UNI port (e.g. Classifying service packets to
different Access Network VLAN).

Page 8 of 23

FlexLight-Networks

IPTV Applications v3.doc

2.2.4.
Client Home network
IPTV and VoD services are assumed to be part of a triple play provisioning where a single
Ethernet port is assumed to provision the Voice (VoIP), TV and Data Services. The figure
below depicts a sample home network that serves several STB+TV sets, several VOIP
phones and couple of Laptops.
Network
Service
Provider (NSP)
Network
(e.g. ISPs)
Regional
Backbone
Network

OLT
(Access
Node)

IPTV/VoD
Application
Service
Provider (ASP)
Network
(Headend)

Content Provider
Network

Distribution
(access) Network

Network Backbone
PC

STB

STB

Laptop

ONT

Customer
Premises
Network

ONT

Customer
Premises
Network

ONT

Customer
Premises
Network

CPE

STB

POTS
POTS

POTS

ONT
ETH

To ONT

Wireless router
"Basic" Switch

Figure 5: Triple-Play Home Network with IPTV and VoD Services

Common residential networks usually include an unmanaged 100Mbps Ethernet switch

connected directly to the ONT. Several STBs are directly connected to that switch together
with a home wireless LAN gateway for provisioning Data and VOIP services.
For the sake of IPTV provisioning, the home network assumes that the home router (the
wireless router in the picture), if exists, never located on the data path between the ONT and
the STB devices. The STB IP subnet and Layer 2 VLAN must be part of the IPTV and VoD
Service Provider VLAN, the reason of which will be clarified in the IPTV provisioning
chapter.
Note that the home network is not required to incorporate QoS enforcement measures or
control IP Multicast traffic distribution. It is assumed that no practical bandwidth limitations
exists that may harm the IPTV, VoD and Data services including control, maintenance and
management traffic (e.g. IGMP signaling and software download to the STB).

Page 9 of 23

FlexLight-Networks

IPTV Applications v3.doc

3. SDV Services Provisioning

Provisioning Switched Digital Video (SDV) Services on Optimate GPON system requires
one-time global infrastructure settings and additional configuration sequence for every newly
added subscriber.

3.1.

Global Network Provisioning Steps

3.1.1.
Service domain infrastructure settings
The SDV services provisioning infrastructure would generally make use of a single 1:N
VLAN domain
In this paper we assume a simplistic provisioning scheme that makes use of a network wide
dedicated single VLAN domain for both IPTV and VoD services. Using dedicated VLAN
domain for SDV services helps secure access and avoids the danger of interacting with other
uses of IP Multicast by other Services (e.g. ISP)
IGMP Snooping, or preferably IGMP Proxy, should be enabled on each aggregation switch
and specifically on the OLT aggregation switch.
The following sections provide detailed descriptions of both VLAN setting and IGMP
Snooping enabling.
3.1.1.1.
Setting SDV dedicated VLAN domain
Having agreed upon a dedicated SDV Service provider VLAN ID across the Backbone and
Access networks requires that the provider configure this VLAN on each OLT GbE card
bridge and set the relevant uplink GigE ports as tagged members of this VLAN.
Accordingly, every line port connected to a SDV Service subscriber SFU (ONT) shall be set
as a tagged member of this VLAN.
3.1.1.2.
Cross network consistent VLAN definition
It is most vital to ensure that all Ethernet switches in the Backbone and access networks on
the SDV Service network are members of the same dedicated VLAN. Additionally every
SDV Service subscriber UNI port must be set as a member of the SDV dedicated VLAN.
3.1.1.3.
Controlling IP Multicast with IGMP Proxy or Snooping
Enabling IGMP Proxy or IGMP snooping across the SDV Service domain is a precondition
to IPTV service deployment.
Specifically on Optimate it is required that OLT will have its IGMP snooping or IGMP
Proxy functionality enabled.
IGMP Snooping at the OLT ensures that an IP Multicast stream is duplicated only to those
ports that joined as listeners to the related IPTV channel IP Multicast stream.
Additional IGMP Proxy behavioral considerations may be added to the OLT to ensure that
bandwidth limitation policies are kept and Channel package access subscription policies are
enforced.
Currently the Optimate supports only IGMP Snooping only, which is limited ensuring that IP
multicast streams flow only to subscriber ports who issued IGMP Join requests.

Page 10 of 23

FlexLight-Networks

IPTV Applications v3.doc

3.1.2.

IGMP Proxy/Snooping standard behavior

3.1.2.1.
IGMP Snooping
IGMP Snooping behavior is described in ANNEX I.
3.1.2.2.
IGMP Proxy
IGMP Proxy ensures that only necessary IGMP Query, Report and Leave messages are
passed on to the Clients/Routers. Basically the purpose of all the following IGMP Proxy
behavioral changes is to minimize the IGMP signaling traffic to the minimum necessary:
IGMP Proxy responds to IGMP Queries once for each IP group address on behalf of
all listeners behind it.
IGMP Proxy passes IGMP Report (Join) messages upstream towards the router
ports (Router ports are switch ports, behind which IP Multicast Routers exist and
accordingly all IP Group sources exists) only once for the first (aggregation switch)
listener of an IP group.
IGMP Proxy passes IGMP Leave messages upstream towards the router ports only
once for the last listener of an IP group on the switch.
IGMP Proxy sends periodic queries to each active IP Multicast stream listener.
Following clauses will elaborate on per subscriber configuration.
3.1.3.
Global Bandwidth planning
This clause specifies the SDV Service downstream BW allocation required on Optimate
GbE card GigE uplink ports.
The SDV Service parameters that need to considered for calculation of IPTV bandwidth
resources include the following:
STB Number
The Total Number of STBs connected to the GbE card.
Channel Number
The Maximum Number of channels transmitted over the SDV
ASB
The Average Stream Bandwidth
MSB
Maximum Stream Bandwidth
The downstream bandwidth that must be allocated on the GbE port can be determined in two
ways:
One policy is to plan for the worst case, in which the SDV Provider gets ready for
the worst-case scenario, in which every client listens to a different IPTV or VoD
channel.
Less conservative but more pragmatic approach is to plan for the more likely case,
which assumes that 80% of the clients watch 20% of the channel selection This
assumption is based on experience. In extreme cases where this assumption does not
hold the provider occasionally compromises on the availability of channels to the
subscribers.

Page 11 of 23

FlexLight-Networks

IPTV Applications v3.doc

3.1.4.
SDV and Data Services Co-existence
Providers strive to provision all triple-play services (IPTV, Internet Access and VOIP) using
the same equipment and the same Ethernet port.
Data and SDV Services may either share the same VLAN domain or use two different VLAN
domains one for every Service
Service classification in the client level
When the subscriber UNI Ethernet port is used for provisioning Data and SDV services, it is
important to ensure that the upstream packets of each service is properly classified to the
right VLAN domain.

3.2.

Per-SDV Subscriber provisioning steps

3.2.1.
SDV Service Definition
An SDV subscriber package incorporates a number of authorized and identifiable STBs. The
Service package includes a pre-defined group of Broadcast TV channels and VoD services.
Both STBs and Channel package are the major components of the SDV Service subscription
agreement, from which the provider derives the dedicated bandwidth requirements for the
specific client.
The SDV provider will strive to enforce this agreement by ensuring that the subscriber has
quality access to the purchased services but on the same time limited to those services only,
to maintain the differentiation between the different Service types.
3.2.1.1.
Channel Package Subscription
The SDV service subscriber package includes a group of Channel packages (e.g. basic
package + sports package + classic package) and an optional VoD service. Some SDV
Service providers allow their clients to subscribe to individual TV channels for per channel
monthly payment.
Each broadcasted TV channel gets a dedicated IP Multicast address while a channel package
(e.g. the Sports channel package; a group of several sports TV channels) is usually allocated
a range of IP Multicast addresses2.
3.2.1.2.
Set-Top-Box allocation
SDV Service package includes an allocation of several STB devices. The SDV Service
provider is responsible to provision and support the STB devices.
Note that the STB is provisioned with measures for supporting special services like the ability
to receive encrypted Video information.

The allocation of IP Multicast addresses must take into consideration both other standard IP Multicast uses
that may collide with the IPTV and be sure that only IP Multicast address is allocated from each group that is
mapped to the same MAC address (Refer to IP Multicast address to Ethernet MAC address Mapping chapter
in ANNEX I

Page 12 of 23

FlexLight-Networks

IPTV Applications v3.doc

3.2.2.
Subscriber bandwidth allocation
Per subscriber IPTV and VoD downstream bandwidth requirements is the product of the
number of STBs simultaneously running on the subscriber premises and the maximum
expected bandwidth per channel. A minimum extra 1Mbps for Control (signaling) traffic must
be allocated.
SDVDownstreamBW = NumberofSTB * MaxChannelBW + ControlBW
On the upstream direction, SDV Service requires just enough bandwidth for Control and
signaling packets. This bandwidth must be added to the bandwidth allocated for Data and
VOIP services.
QoS must be applied on the OLT GbE Bridge on the downstream to ensure that SDV traffic
gets prioritized over the Data traffic. Coexisting VOIP traffic will have to be prioritized over
SDV and Data Services traffic to ensure low delay and zero loss.3
3.2.3.
Set-Top-Box Authentication and Authorization measures
Before a STB can receive the IPTV and VoD channels it must firstly be configured with the
IP host parameters that enable it communicate through the IP network:

IP address

IP Subnet mask

Default gateway or other static IP routes

Domain Name Server IP address

Other configuration items.

These parameters are statically set by the provider or, more likely, dynamically leased from
the Service Provider by using the Dynamic Host Configuration Protocol (DHCP).
3.2.3.1.
STB host configuration via DHCP
For dynamically retrieving the host configuration via DHCP the STB host issues a DHCP
request, in which it provides some credential information, according which the DHCP Server
located in the Metro Network provides the IP Settings to the specified STB. Among the
credential parameters one finds the following:
STB MAC address, (part of the basic DHCP message)
DHCP Option 61 - The Client Identifier, which is usually the box MAC address but
can optionally be any identifier selected by the STB vendor.
DHCP Option 60 - Vendor ID, which includes a uniquely identifiable string that
describes the STB vendor.
o Example a STB running Windows XP OS will issue the MSFT 5.0 Vendor
Id string
DHCP Option 82 Relay Agent Information Will be described in the next section

Refer to the QoS application note for further information on QoS provisioning.

Page 13 of 23

FlexLight-Networks

IPTV Applications v3.doc

The DHCP Server uses the credential parameters provided within the STB DHCP request
together with additional parameters provided by the Layer 2 and Layer 3 DHCP relay agents
to select the appropriate IP parameters for the STB. The parameters provisioned by DHCP
Server are leased for limited time, on the end of which the STB must reissue a DHCP
request4.
Note that providers occasionally allocate IP addresses from different pools dedicated for
different types of SDV Service subscribers. The IP address pools are usually taken as ranges
within the same IP Subnet or, in rare cases, from different IP Subnets that share the same
SDV dedicated VLAN domain.
Dedicated IP addresses are sometimes used for VoD service access request approval.
The information added by an L2 DHCP Relay to the STB DHCP request is aimed at uniquely
identifying the Circuit ID and Agent ID (I.e. UNI port) through which the STB is
connected to the network. The following clause provides an in-depth description of the Layer
2 DHCP Relay behavior.
3.2.3.2.
L2 DHCP Relay Credential Information
The L2 DHCP Relay Agent intercepts DHCP Requests originated by the STB IP hosts in
order to add credential information aimed to help the DHCP Server in its IP address and
other configuration information provisioning policies.
Note: The current version of Optimate does not support DHCP Relay Agent functionality.
The 520NT in Release 7 will support this functionality.
3.2.3.3.
DHCP Relay with DHCP Option 82
The DHCP relay agent inserts the DHCP Relay Agent Information when forwarding clientoriginated DHCP packets to a DHCP server. The Relay Agent Information is added to the
DHCP message in a DHCP Option 825.
Servers recognizing the DHCP Relay Agent option 82 may use this information together with
other credential information provisioned in the DHCP request to carry out IP address
assignment policies.
The DHCP Server echoes the Relay Agent Information option back as is to the relay agent in
DHCP replies, and the DHCP relay agent strips the Relay Agent option before forwarding
the reply to the DHCP client host.
The "Relay Agent Information" option is organized as a single DHCP option that contains
one or more "sub-options" that convey information pre-configured on the relay agent.
The initial sub-options are defined for a DHCP Relay agent that is collocated in the Access
Network edge and is aware to the subscriber unique UNI identity. These include a "circuit
ID" for identifying the incoming UNI port, and a "remote ID" which provides a trusted
identifier for the remote GPON system and subsystem.

4
5

For more information about DHCP protocol refer to IEFT standards RFC2131 and RFC2132.
For DHCP message structure and Option term refer to IETF RFC2131.

Page 14 of 23

FlexLight-Networks

IPTV Applications v3.doc

3.3.

QoS for SDV Services

3.3.1.
QoS for IPTV Traffic
Optimate enables and supports prioritizing the IPTV IP Multicast streams traffic.
The IP Multicast streams received via the GbE card GigE uplink ports are multiplied
downstream towards the GbE card line ports and then sent towards the subscriber STBs
according to the IGMP Snooping/Proxy decision.
The IP Multicast traffic can be classified to the 2nd queue6 on each line port. Providing that
the Bridge line port associated with a certain subscriber is provisioned with enough
bandwidth for the SDV Service and any additional Data & Voice Services, the IP Multicast
traffic QoS is guaranteed.
3.3.2.
QoS for VoD Traffic
As VoD traffic streams are Unicast IP streams it is up to the SDV Service provider to ensure
that the VoD streams are colored with IP Precedence or VLAN CoS in a way that those
values be translated to queue 3 (assuming SP+WFQ scheduling technique on all related line
ports).
Assuming that the BW provisioned for SDV services per every subscriber took the VoD
service requirements into consideration, then the VoD streams are guaranteed with Expedited
Forwarding, thus zero loss and minimum constant delay are assured.

Refer to the QoS Application Note for more information about the OLT and ONTs QoS capabilities

Page 15 of 23

FlexLight-Networks

IPTV Applications v3.doc

4. IGMP in the 2500LT

4.1.

Overview

Normally, the GbE switch would forward IP Multicast packets to all ports residing on the
same VLAN, as any standard Layer 2 switch does. This behavior defeats the purpose of the
switch, which is to limit traffic to the ports that need to receive the data, and in the IP
multicast case such behavior results in an excessive BW consumption on ports, behind which
this traffic is not used.
Two methods exist by which one can deal with multicast in a Layer 2 switching environment
efficiently Using of an IP Group membership registration protocol like IEEE Generic
Multicast Registration Protocol GMRP and IGMP snooping or proxy. IGMP snooping
technology had become the preferred standard, which is also implemented in Optimate
OLT Bridges.
The following picture depicts an IP Multicast control deployment with Optimate GbE CIF.
The GBE CIF configuration includes one (default) VLAN for all ports and IGMP snooping
enabled. One can realize there are two different IP Multicast streams, each of which destined
to a subset of the client group. Note that only client ports that joined the groups receive a
copy of the stream.

Quad FE CIFon ONT

MPEG Video
Stream B

FE to
GPON
ADP

10/100
Eth

10/100
Eth

GbE CIF (on OLT)

Group B
Client

GbE
SP Internet
Access Router

FE to
GPON
ADP

GbE
Switch

CO Router

Group A client
Firewall

Quad
switch

10/100
Eth

GPON

GbE
48

Quad FE CIFon ONT

FE to
GPON
ADP

Video Conferencing
Stream A

10/100
Eth

Group A and
B client

10/100
Eth

Quad
switch

The Bridge forwards IP

Multicast traffic only to
those asked for it

10/100
Eth

Group A Client

10/100
Eth

Firewall
Client of no IP
Multicast group

Figure 6: Two Multicast streams transmitted selectively to requesting ports only

Page 16 of 23

FlexLight-Networks

IPTV Applications v3.doc

4.2.

Optimate IPTV Zapping Time Test Results

This section describe the results of an IPTV focused IGMP Snooping test performed using
Spirent AX/4000 testing tool. The test included Channel verification and Zapping time results.
Test Setup
The test scenario incorporated two different client profiles.
Client profile #1 included 22 subscribers
Client profile #2 included 24 subscribers.
The subscribers were randomly zapping from a selection of 64 MPEG2 encoded IPTV
channels 1.5Mbps each.
4 x 1000NT
1000NT
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth

All subscriber ports and Server

Shared the same VLAN

GbE Card(on OLT)

external
auxiliary
Ethernet
switch

GbE

IP Multicast
Router
Querier

GbE
Switch

GPON

1000NT
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth
10/100 Eth

GbE
IP/TV
Server Side

GbE IPTV
Subscriber side
Per subscriber
dedicated VLAN

AX/4000 IPTV Tester

Figure 7: Optimate IPTV focused IGMP Snooping Test bed

Figure 8: IPTV Test configuration

Page 17 of 23

FlexLight-Networks

IPTV Applications v3.doc

Page 18 of 23

FlexLight-Networks

IPTV Applications v3.doc

Test results
The leave and join latency as measured in the test results shown bellow are around 2 ms and
8 ms for the join and leave requests. This is far less than the 15 ms & 25 ms figures, which
are commonly required in the industry.

Figure 9: IPTV Test results Join/Leave/channel change Latency

Figure 10: IPTV Test results Results summary

Page 19 of 23

FlexLight-Networks

IPTV Applications v3.doc

5. Annex - IP Multicast Technology overview

IP multicast is a bandwidth-efficient technology that reduces traffic by simultaneously
delivering a single stream of information to any number of end host clients. Examples for IP
Multicast based applications are Video content distribution (IPTV), videoconferencing,
distance learning, and other High-bandwidth applications, such as MPEG video, whose
delivery is practical only by using IP Multicast.
Without IP Multicast the source would have to send individual copy of the information to
each receiver, which makes Unicast IP a non-scalable technology for the above applications.
IP Multicast delivers the source information to multiple receivers without adding any
additional burden on the source or the receivers while using the minimum required
bandwidth. Multicast packets are replicated in the network by the IP Multicast routers.
IP Multicast routers are regular IP Routers with the additional ability to forward IP Multicast
packets, based on the forwarding information built by IP Multicast Routing Protocols, such
as Protocol Independent Multicast (PIM), Multicast OSPF (MOSPF) and Distance Vector
Multicast Routing Protocol (DVMRP). The following figure demonstrates how data from
one source is delivered to several interested listeners using IP multicast.
Not a Client
for the specific display

STB Video Monitor

Provider IP Multicast
network cloud

STB Video Monitor

Video

Client Laptop

STB - Video Monitor

Client Laptop
Client Laptop

Figure 11: IP Multicast network serving Video over IP application

Page 20 of 23

FlexLight-Networks

IPTV Applications v3.doc

5.1.

The IP Multicast Group Concept

An arbitrary group of receivers interested in receiving a particular data stream define an IP

Multicast group. The group members do not have any network topology relation nor any
geographical boundaries (I.e. each receiver can be located anywhere on the network as long
as they all connected via IP Multicast capable Routers).
To join a particular IP Multicast group, IP hosts are using Internet Group Management
Protocol (IGMP). An IP host must be a member of a specific IP group to receive the data
stream destined to the group.

5.2.

IP Multicast Forwarding

In Unicast routing, packets are forwarded according to the destination IP address.

Consequently, under stable network condition, an IP Unicast packet is routed through the
network along a single path from the source to the destination host.
In multicast routing, the source is sending traffic to an arbitrary group of hosts represented by
a multicast group address. The multicast router must determine which direction is upstream
(toward the source) and which direction (or directions) is downstream. If there are multiple
downstream paths, the router replicates the packet and forwards the traffic down the
appropriate downstream paths. The routers determine the upstream and downstream
directions by examining their forwarding information. This forwarding information is a
portion of a globally built Multicast group distribution tree.
Multicast-capable routers use IP Multicast routing protocols to collectively create IP
Multicast distribution trees that control the path that IP multicast traffic takes through the
network to reach all receivers. How exactly a {source, group} Multicast distribution tree is
build end-to-end is out of the scope of this paper and is not necessary for understanding of
the IGMP Snooping feature anyway.
Routers use Internet Group Management Protocol (IGMP) to periodically query the
immediate subnet/LAN to determine if known group members are active. If there are two or
more IP Multicast routers on the LAN, one of the routers is elected to assume the
responsibility of querying the LAN for group members. Based on the group membership
information learned from the IGMP, a router can determine which (if any) multicast traffic
needs to be forwarded to each of its immediate IP subnets. Apparently, IGMP is used to
complete building each Multicast group distribution tree leaves.
Only one Router neighboring a switched LAN is responsible to forward IP Multicast group
traffic to the LAN.

5.3.

IGMP protocol

Internet Group Management Protocol (IGMP) is used by IP hosts to dynamically register in

an IP multicast group by sending registration messages to their local multicast router. Under
IGMP, routers listen to IGMP report messages and periodically send out queries to discover
which groups are active or inactive on a particular subnet. When the hosts are members of a
switched LAN there is no need to register each and every host. A single registered host,
whose registration session is heard by the rest of the LAN resident hosts, is sufficient for
registration of all the rest.
5.3.1.
IGMP Version 1
There are two different types of IGMP messages in IGMP Version 1:
Page 21 of 23

FlexLight-Networks

IPTV Applications v3.doc

Query
o Local IP router/Multicast server periodically send IGMP query messages to
learn whether there are listeners for all groups in the immediate LAN/IP
subnet
o When there is no reply to 3 consecutive IGMP membership queries, the router
times out the group and stops forwarding traffic directed toward that group.
Report
o A Host sends to the local IP multicast router IGMP report message
corresponding to a particular multicast group in order to join that specific
group

5.3.2.
IGMP Version 2
For detailed information about IGMP version 2 refer to [IGMPv2]. IGMP Version 2 works
basically the same as Version 1.
In IGMP Version 2 there is an effort to greatly reduce the leave latency compared to IGMP
Version 1, which enables halt unwanted and unnecessary traffic transmission sooner.
There are four types of IGMP messages in IGMP Version 2:
Leave group
o This new message is used by hosts to actively communicate to the local
multicast router their intention to leave the group
Membership query
o Upon receiving a group-specific leave message, the local router sends a
group-specific query message corresponding to the same group in order to
determine whether there are any remaining hosts interested in receiving the
traffic.
o If there are no replies, the router times out the group and stops forwarding the
traffic.
o The router can also use the general query message.
Version 1 membership report (same as above)
Version 2 membership report

5.4.

IP Multicast Group Addresses

A special IP Multicast destination addresses are used to identify an arbitrary listener group
of IP hosts.
The IP Multicast address range is only for the destination address of IP multicast traffic. The
IP source address for multicast packets is always the Unicast source address of the stream
originating host.
The Internet Assigned Numbers Authority (IANA) controls the assignment of IP multicast
addresses. It has assigned the old Class D address space to be used for IP multicast. This
means that all IP multicast group addresses fall in the range of 224.0.0.0 to 239.255.255.255.

Page 22 of 23

FlexLight-Networks

IPTV Applications v3.doc

Reserved Local Subnet Addresses

IANA has reserved addresses 224.0.0.0 through 224.0.0.255 within the Class D range to be used by
network protocols on a local network segment (E.g. 224.0.0.2 is used to deliver packets to all routers
on the same IP subnet). A router should never forward a packet destined to one of these addresses;
they remain local on a particular LAN segment. To ensure compliance with this rule those packets
are always transmitted with an IP time-to-live (TTL) of 1.
Globally Scoped Address
The range of addresses from 224.0.1.0 through 238.255.255.255 is called globally scoped addresses.
They can be used to multicast data between organizations and across the Internet.
A well-known example is 224.0.1.1 IP Multicast address, which has been reserved by IANA for
Network Time Protocol (NTP).
Limited Scope Addresses
The range of addresses from 239.0.0.0 through 239.255.255.255 contains limited scope addresses.
These addresses are defined by the IETF RFC 2365 to be constrained to a local group or
organization.
Routers will typically be configured to prevent multicast traffic destined to any address in this range
from leaving the autonomous system (AS) or any user-defined domain.
A special attention should be given to cases where L2 VPN services serve such IP Multicast
addresses by the Provider device.

Mapping of IP Multicast Addresses to Ethernet MAC addresses

IANA allocated a block of Ethernet MAC addresses whose prefix is (hex) 01:00:5E, half of
which is allocated for multicast addresses. The available range of Ethernet MAC addresses
for IP multicast is 01:00:5e:00:00:00 through 01:00:5e:7f:ff:ff. Thus, only 23 bits in the
Ethernet address correspond to the IP multicast group address. The standard maps the lower
23 bits of the IP multicast group address into these available 23 bits in the Ethernet address,
which means that groups of 32 Multicast IP addresses are each mapped to a single MAC
address. The following diagram depicts the IP Multicast address to Ethernet MAC address
translation.
32 bit

Ethernet MAC address prefix

for IP Multicast is h01:00:5E or
more accurately the 25 bit
binary prefix
0000 0001 : 0000 0000 : 0101
1110 : 0

227 . 243 .

34 . 2

(hex)E3 : F3 : 22 : 02
Class D bits
1110

73 : 22 : 02
5 bits
are lost in transition
process

23 least significent bits

(hex)01 : 00 : 5E : 73 : 22 : 02
48 bits of MAC address

Figure 12: IP Multicast address to MAC address mapping

Page 23 of 23

FlexLight-Networks