High-quality and resilient

IPTV multicast architecture

Technical White Paper

An overview of ResIP multicast

architecture design guidelines

2/20

High-quality and resilient IPTV multicast architecture Technical White Paper

Executive summary

Profit from emerging broadband services for residential

customers.

Nokia Siemens Networks and Juniper Networks have joined together to develop
and implement carrier-grade end-to-end Next Generation Network (NGN) solutions
with best-in-class QoS, reliability, management, and security.
The Resilient IP (ResIP) Certified solutions are the product of more than three
years of joint solution development work focused on validating, optimizing, and
certifying IP solutions for voice, video, and data applications end-to-end.

Tested and verified engineering excellence to provide

best-in-class IPTV solutions.

Nokia Siemens Networks and Juniper cooperate to provide a complete, optimized

ResIP Certified IPTV solution. The ResIP Lab combines best-of-breed products
with design know-how to provide solutions that minimize technical deployment
risks, ensure interoperability and scale. The end result is a quicker time to market
and an assured user experience for IPTV services.

Contents
2

Executive summary

Introduction

Meeting end user expectations for IPTV

Network aspects

Access network architecture

12

Core network design concepts

16

Conclusion

17

About Nokia Siemens Networks

and Juniper Networks

19

Abbreviations

3/20

This document focuses on:

The ResIP design for IPTV

services for efficient deployments and reliability.

Network aspects, which are influenced by the introduction of IPTV services

regarding required bandwidth, reliability, network responsiveness, and QoS.
Different access network architectures are described, focusing on the currently
discussed VLAN models.
The Layer 2 control mechanism and how this tool improves dynamic QoS
concepts are described.
Protocol Independent Multicast Sparse Mode (PIM-SM), Protocol Independent
Multicast Source Specific Multicast (PIM-SSM) or Point-to-Point MPLS LSPs
can be used for distributing the IPTV content through the IP backbone.

Leverage expertise from two

industry leaders.

Service providers can tailor the ResIP Certified solutions and engineering work
to their specific network environment. Nokia Siemens Networks and Juniper
Networks offer professional network planning and implementation services to help
carriers customize their IPTV solution.

4/20

High-quality and resilient IPTV multicast architecture Technical White Paper

1. Introduction

Nokia Siemens Networks

and Juniper Networks
demonstrate combined voice
and video expertise in the
joint ResIP Lab.

Telecom operators around the world are facing the challenge of declining voice
revenues due to increased competition and the mass proliferation of mobile
communications. In addition, cable TV operators are adding voice services to
their traditional cable offering, and are thus entering into the domain of telecommunication carriers.
Studies have shown that end customers will pay for an attractive service bundle
comprising voice, video, and data, and prefer to have a single bill from a trusted
operator for all their service needs. Under these conditions, it has become mandatory for the incumbent fixed line carriers to reposition themselves in the changed
competitive landscape. There is a strong need to migrate from simple infrastructure provider to a one-stop service provider.
The new business model for the carriers will be driven by the expectations of end
users for multimedia services. The operators network must be able to support the
multimedia services requirements, i.e. the need to have voice, data, video on demand (VoD), and TV broadcast services. The success of service bundling is
dependent on satisfying the expectations of the end user.
Early movers on the IPTV market have faced the risk of suffering from technical
barriers and challenges. In several cases, technical issues have led to stalled
projects, incomplete service offerings, and unexpected quality degradation of the
services. This in turn has affected the acceptance of the triple-play services and
resulted in negative impact on margins and increased customer churn.

Innovative online
entertainment and
communication via TV.

Nokia Siemens Networks and Juniper Networks partner to develop complete

solutions to help service providers to successfully introduce and grow triple-play
services. Expertise from both companies have been brought together in the ResIP
Lab to validate, optimize, and certify IP solutions that service providers can use to
deliver VoIP trunking, triple-play, and now IPTV services with an assured quality of
experience.

5/20

2. Meeting end user

expectations for IPTV
User expectations already
settled by existing
distribution technologies.

Introduction of new services always involve a number of commercial and technical

risks. The success of services is dependent on meeting the requirements and expectations of end users. TV services have been available for a long time over
legacy infrastructures including terrestrial broadcast, cable networks, and satellite.
End users have come to expect a level of service regarding availability, latency,
and quality. Therefore, it is vital to keep the technical risks to a minimum and to
meet user expectations and needs. To make the IPTV services a success, it is
required to establish IP networks that guarantee the quality of service (QoS) even
under adverse network conditions.
End user requirements are driving the need for:
assured quality of service in real time including fast interactive responsiveness
and minimum number of visual and acoustic defects
a broad portfolio of video service offerings such as broadcast TV, VoD, personal
video recording, or time-shift TV and the availability of premium content
high availability, i.e. no single point of failure and fast recovery mechanisms for
sub-second failover times
easy and convenient handling

ResIP Certified IPTV

solution provides carriers
with industry-leading broadband video programs.

In addition to the end users expectation, service providers need to reduce costs
(from both the equipment point of view and the operational point of view) and
increase revenues. Network operators must:
optimize the utilization of network resources in both unicast and multicast
environments
minimize operational efforts through advanced management tools and zerotouch provisioning recommendations
be quicker to market with new services
be flexible and maintain investment protection to address a broad range of
access types, network architectures, aggregation technologies, and existing
protocol environments

6/20

High-quality and resilient IPTV multicast architecture Technical White Paper

3. Network aspects
The introduction of IPTV services, including both broadcast TV and on-demand
services, onto todays broadband IP networks changes several aspects of these
networks.

3.1. Bandwidth dimensioning

IPTV and VoD services require high bandwidth capacities and predictable performance, placing additional requirements on the network. Depending on the
compression and coding technology, the following transmission rates should be
considered:
MPEG-2-coded SD VoD video streams or IPTV stream per one TV channel:
3.5-5 Mbit/s
H.264-coded (MPEG-4 part 10) SD VoD video streams or IPTV stream per one
TV channel: up to 2 Mbit/s
HD signals will need 8-12 Mbit/s coded with H.264
IPTV and video services have different influences on available network resources.
Several factors have to be considered before the implementation of an IPTV
service including:

Influence of broadcast TV (IPTV) services

Key elements of the ResIP
Certified IPTV solution are
the design guidelines and
the proof-of-concept.

The total number of IPTV channels streamed online determines the total bandwidth requirements. The total transmission rate of the IPTV content measured in
Mbit/s equals the sum of all concurrent streams. Each IPTV channel is sent only
once from the video headend to the network, independent of the number of potential TV broadcast receivers. The distribution to all subscribers is achieved by
multicast implementations in the core and the access networks. For example, if
30 IPTV channels are broadcast and each channel is encoded by H.264 codec
providing a gross bit rate of 2 Mbit/s (incl. Ethernet overhead), 60 Mbit/s bandwidth
is required for the IPTV service. The calculated 60 Mbit/s IPTV traffic will be transmitted via the network operators IP core network to the DSLAMs independent of
the number of end customers. This amount of traffic does not affect the throughput
of the IP core network dramatically.
In the core network, typically all offered IPTV channels are distributed without
considering the current usage of every channel. However, in the access network,
bandwidth can be reduced by supporting IGMP (Internet Group Multicast Protocol)
snooping in the aggregation switches and edge routers. IGMP snooping can passively snoop on IGMP Query, Report and Leave (IGMP version 2) packets transferred between IP multicast routers/switches and IP multicast hosts to learn the
IP multicast group membership. It checks IGMP packets passing through it, picks
out the group registration information, and configures multicasting accordingly.
Without IGMP snooping, multicast traffic is treated in the same manner as broadcast traffic, that is, it is forwarded to all ports. With IGMP snooping, multicast traffic
of a group is only forwarded to ports that have members of that group. IGMP
snooping with proxy reporting can help reduce the IGMP Membership Report
messages.
Statistics in existing IPTV installations have shown that about 50% of all offered
channels are requested by at least one user per DSLAM. This number depends
on the ratio of free TV and pay TV channels or the quality of the electronic
program guide (EPG).

7/20

Influence of video-on-demand services

VoD produces high bandwidth constraints on the network as unicast frames are
used for streaming video signals to the end user. VoD is therefore highly resource
consuming. Total transmission rate equals the sum of all concurrent video streams.
For example, a VoD service planned for 10,000 IPTV subscribers must be capable of handling VoD requests for 10% of IPTV subscribers. A realistic average
number that is commonly used for budgetary calculations is 10%. Thus, 1,000
simultaneously transmitted movies encoded in H.264 format at 2 Mbit/s gross bit
rate will produce 2 Gbit/s traffic. The IP core network must be capable of handling
the additional traffic load.

3.2. Reliability
Reliability is one of the key requirements for networks delivering IPTV services.
Avoidance of any single point of failure and subsecond restoration times is a key
fundamental of all ResIP design concepts. This includes both the IP core network
and the access/aggregation network. The IP core network can be based on either
the Interior Gateway Protocol (IGP) like IS-IS or OSPF or on an MPLS backbone.
The access and aggregation network is Ethernet-based with redundant interconnection of the video headend equipment to the IP core network. An example for a
resilient multicast network design is shown in Figure 1.
This network design assumes that the multicast replication is achieved in the
DSLAM, and that that and the multicast traffic is distributed from the redundant
IP edge via a multicast VLAN to the DSLAMs. Usually there is only one IPTV edge
location in the network. In some situations, geographic redundancy is required and
there are two IPTV edge locations. However, there are usually multiple IP edges,
one for each regional access and aggregation network. For the access and aggregation network, two options are generally possible. First, the topology can be
built as a tree structure, using Rapid Spanning Tree Protocol (RSTP) or Multiple
STP (MSTP) to resolve redundant paths. Secondly, ring topologies are emerging
to improve reliability. The innovative Nokia Siemens Networks Ethernet Ring
Protection (ERP) provides very fast switch-over times in case of ring failures.

IPTV edge

IP edge

G1

G1

G2
G1+G2

Resilient
aggregation

IP core

G1
G2

G2
G1+G2

Figure 1: Redundant multicast network design

8/20

High-quality and resilient IPTV multicast architecture Technical White Paper

3.3. Quality of service

IPTV is a real-time service that has very stringent QoS requirements, specifically
packet loss and delay. A small amount of delay does not directly affect the quality
of experience of IPTV. However, a delay longer than 1 second may result in a less
than satisfying end user experience if a neighbor with traditional TV service is able
to watch a goal in an important soccer game several seconds in advance. Packet
loss will likely cause visible artifacts due to the high compression rates of MPEG
encoded TV signals. In order to have less than one visible artifact per movie on
the TV screen, the packet loss rate must be lower than 10-6.
As quality of service is a comprehensive subject in the network design, a separate
document will highlight the ResIP QoS recommendations for IPTV.

3.4. Network responsiveness

One prominent aspects of a good user experience for IPTV services includes
fast channel change (also known as zapping). Channel change delay, i.e. the
time between pushing the remote control button and the first video frame being
rendered on the viewing device, is mainly influenced by the following:
processing of the remote control request
IGMP control processing (set-top box (STB), residential gateway, network)
data plane protocol stack processing, including DSL interleaving delay, decryption, FEC, etc.
STB jitter buffer delay
Buffer for video encoding
MPEG decoder delay for resynchronizing with the new program

Experience, knowledge and

leadership ResIP Certified
IPTV solution.

The latency of IGMP processing in the network (e.g. the residential gateway,
DSLAM and BSR) also directly adds to the overall zapping delay.
The required size of the jitter buffer depends on the jitter of the media stream received by the STB. The jitter generated by a well-engineered high bandwidth IP
network is less than 50 ms. The video source itself should also produce low jitter
streams.
MPEG decoder delay usually makes up the largest part of the overall delay
budget, because the decoder must usually wait for an I-frame to resynch. Also,
additional decoding delay results due to the use of B-frames which are encoded
using past and future I- and P-frames. This delay depends on the compression
rate, the encoding algorithm and the number of B- and P-frames between two
I-frames (GOP). This results in a tradeoff between channel change delay and
compression rate. High compression rates imply a large GOP with extensive use
of B-frames, and therefore result in a large encoding/decoding delay.
To improve the responsiveness from a users perspective, the STB immediately
shows a dialogue box with the program name, time, channel, etc. upon receiving a
zapping request for another channel via the remote control. This ensures that end
users will never view a black screen while waiting.
The DSL Forum has recently finished the specification (TR-101) for the fundamental architecture for Ethernet-based DSL aggregation networks, which also includes
definitions for the delivery of multicast services.

9/20

4. Access network
architecture
TR-101 differentiates between two different approaches for connecting broadband
DSL users to the aggregation network, first the so-called 1:1 (also known as VLAN
per subscriber) and secondly the N:1 (also known as VLAN per service) mode.

4.1. VLAN per subscriber

The 1:1 approach, shown in Figure 2, puts the subscriber at the center of the consideration. It provides simple connectivity to the IP network for delivery of multiple
services. Introducing a new service does not require a new VLAN configuration.
This option uses stacked VLANs due to scalability concerns.
The inner VLAN tag identifies the subscribers port at the DSLAM. The outer
VLAN tag identifies the DSLAM, and can be added by the DSLAM or by the
next aggregation switch. In most cases, this approach is used with a single edge
model, i.e. all services are provided by a single IP edge router, the broadband
service router (BSR).
Besides the subscriber VLANs, a special multicast VLAN is used. The multicast
VLAN is a service VLAN, which is single-tagged only. The multicast VLAN is used
for distributing the multicast traffic from the IP edge to the DSLAMs, and for transporting IGMP messages between the multicast router (M- or E-series) and the
multicast hosts (i.e. the STBs).
This multicast VLAN can be terminated at the BSR, but as an option could also
be terminated at any other IP edge router. Both the DSLAM and the aggregation
switches support IGMP for a dynamic optimization of the multicast distribution.

xDSL

IP DSLAM
1
2
3
4
K

Port 3
VLAN

1
3

TV
xDSL

IP DSLAM
1
2
3
4
L

Ethernet
switch

DSLAM-x
VLAN

K
1

Port 3
VLAN

Ethernet
switch

DSLAM-x
VLAN

BSR
1

DSLAM-y
VLAN

DSLAM-y
VLAN

TV
1

Port 3
VLAN
xDSL

IP DSLAM

TV

DSLAM-z
VLAN

DSLAM-z
VLAN

TV

TV

1
2
3
4
M

Porttag

Figure 2: Reference architecture for VLAN per subscriber

IPTV headend

10/20

High-quality and resilient IPTV multicast architecture Technical White Paper

IP DSLAM
HSI
VoD/TV
VoIP

1
2
3
4
K

HSI-X
VoD-X
TV
VoIP-X

IP edge
TV
Ethernet
switch

IP DSLAM
HSI
VoD/TV
VoIP

1
2
3
4
L

HSI-Y
VoD-Y
TV
VoIP-Y

Ethernet
switch
GE/10GE

BRAS
HSIX,Y,Z
IP edge
VoDX,Y,Z

IP DSLAM
HSI
VoD/TV
VoIP

1
2
3
4
M

HSI-Z
VoD-Z
TV
VoIP-Z

Figure 3: Reference architecture for VLAN per service

4.2. VLAN per service

The alternative is based on service-specific VLANs in the aggregation network.
The basic goal is to optimize the delivery of different services through the access and aggregation network and to use optimized edge routers to the IP core
(multiple edge). It includes not only the multicast VLAN, which in Figure 2 is
considered as always being a service VLAN, but also specific VLANs for data
services or voice services. This approach is shown in Figure 3.
In most cases, this is linked to the usage of service-specific PVCs or VLANs
on the DSL link. The residential gateway must forward the Ethernet frames on
the appropriate PVC or VLAN service. The two described options are the basic
models. It is, of course, possible to mix both approaches in one network, e.g.
having all service VLANs connected to a single edge router, or having multiple
C-VLANs per subscriber connected to service-specific edge routers.

4.3. Layer 2 control

VLAN per subscriber and VLAN per service can both be enhanced by the use
of a Layer 2 control mechanism. The DSL Forums TR-059 defined queuing and
scheduling mechanisms to avoid congestion in the access network while dealing
with multiple flows with distinct QoS requirements, commonly called hierarchical
scheduling. A mandatory requirement for hierarchical scheduling is that the BSR
must have knowledge about the access network, the various links being used,
and their respective rates.

IP edge
VoIPX,Y,Z

TV
headend

11/20

However, some of this information is dynamic in nature (e.g. DSL sync

rate) and cannot come from a provisioning or inventory management OSS
system.
Instead, a Layer 2 control mechanism can provide this dynamic information
from the DSLAM to the BSR when a DSL line resynchronizes. This information is available in the BSR independent of any active user session, unlike other proposed mechanisms using an extended DHCP relay agent or
PPPoE intermediate agent.
In addition to QoS support, Layer 2 control can also be used to close the
functional gap for end-to-end connectivity tests between the BSR and the
CPE. Traditionally, ATMs F4/F5 loopback tests have been used for operation and troubleshooting. Since Ethernet is getting a more important role
as a Layer aggregation network, it must test and troubleshoot connectivity
in the case of a mixed Ethernet and ATM access network (including the
local loop). While Ethernet OAM standards (e.g. IEEE 802.1ag) are still
work in progress (especially in a mixed Ethernet and ATM scenario),
Layer 2 control has successfully been used to close this gap and to test
the connectivity between the BSR and the CPE including the local loop.

4.4. Multicast replication

Multicast replication is one of the essential components in efficient delivery
of IPTV broadcast services. Depending on the network topology and service subscription rates, generally all network elements including DSLAMs,
aggregation switches and IP edge routers perform multicast replication, as
it is shown in Figure 4. In VDSL networks where the short range of VDSL
results in low number of subscribers per DSLAM, the last multicast replication point can also be the first aggregation switch instead of the DSLAM itself.

xDSL

Multicast
replication

IP DSLAM
1
2
3
4
K

Multicast and
shaping/subscr.
TV
xDSL

IP DSLAM

Ethernet
switch

Ethernet
switch

1
2
3
4
L

BSR

xDSL

IP DSLAM
1
2
3
4
M

L2C (RAM, OAM)

IPTV headend

Figure 4: Layer 2 control and multicast replication

12/20

High-quality and resilient IPTV multicast architecture Technical White Paper

5. Core network
design concepts
Optimized for scale.

This paper addresses three different mechanisms for distributing multicast traffic
throughout the IP backbone. Two of them, PIM SSM and PIM SM, are based on
IGP only, and the third, P2MP LSPs, are based on the MPLS multicast distribution
concept.

5.1. PIM SSM

The PIM SSM mode, shown in Figure 5, requires the edge router to know about
the IP address S of the multicast source providing the multicast group G. The
router will issue a PIM Join request directly towards the corresponding source.
This Join request will be forwarded along the shortest path (in terms of the IGP)
to the multicast source until it reaches a router which is already aware of the multicast group G. The existing SPT is then extended down to the requesting edge
router. In general, there are two ways the edge router can determine the IP address S of the corresponding multicast source:
a) The receiver uses IGMPv3 to signal its request for a certain multicast group
address G and explicitly includes the multicast source address S in every
IGMP Join message (IGMP v1/2 does not provide that functionality).
b) By configuration, the edge router knows about a mapping G > S. Whenever
either an IGMPv1/2 Join message or an IGMPv3 Join message without explicitly specifying the IP address of the multicast source occurs, the edge
router uses this mapping to identify the right multicast source for multicast
group address G.

Active

Multicast
traffic for Group G

Static SSM mapping

(IMGPv1/2 > IGMPv3)
Multicast
Receiver 3

Receiver DR
Receiver DR
Standby

IGMP v1/2

Multicast
Receiver 2

Receiver DR

Multicast
Receiver 1

Figure 5: PIM SSM scenario with static SSM mapping at the edge

13/20

Multicast
traffic for Group G

Active

Register messages
Multicast
Receiver 3
SPTs for (S,G)
Receiver DR
Receiver DR

Standby

Multicast
Receiver 2
Receiver DR

RPT for (*,G)

but not for (S,G)
Multicast
Receiver 1

Figure 6: PIM SM scenario

5.2. PIM SM
In this PIM mode, shown in Figure 6, the edge router does not need to know which
multicast source can provide the multicast data for a certain group address G. The
routers do need to know whom to ask to get the information about the multicast
source for G: the instance to ask is another router called Rendezvous Point (RP).
This kind of multicast distribution is used in the IP backbone when the range of potential multicast group addresses is quite large, the multicast source IP addresses
are not really known from the beginning, or the multicast source IP addresses are
subject to change quite often during the time. There are a couple of options for how
to choose an RP. The preferred option is the so-called Anycast RP.
In this option, each potential RP router is equipped with two loopback addresses,
a primary and a secondary one. The secondary loopback address does not need
to be unique throughout the network. The Anycast RP concept is to define the RP
via the secondary IP address and assure that each such secondary IP address
occurs at least twice in the network. Any time an edge router has to contact the RP,
it will automatically be led to the nearest router (in terms of IGP metrics) with a certain secondary loopback address. This assures that the time in which a new multicast group cannot be joined when an RP fails is the time the IGP needs to converge.
Moreover, RP load balancing is achieved automatically.

14/20

High-quality and resilient IPTV multicast architecture Technical White Paper

Active

Multicast traffic for

Group G is mapped
into P2MP LSF

Multicast
Receiver 3

Receiver DR
Receiver DR
Standby

Multicast
Receiver 2
Receiver DR

Multicast traffic
for Group G

P2MP LSP
Multicast
Receiver 1

Figure 7: Point-to-Multipoint LSP scenario.

5.3. P2MP LSPs

The MPLS solution is less dynamic than the PIM solutions. The basic assumption
is that the edge routers always have active multicast receivers attached to them.
All these edge routers are LSP egress routers of certain P2MP LSPs. On the other
hand, the ingress point of each P2MP LSP is a border router which connects directly
to a multicast source (in most cases via a redundant Layer 2 network). At this ingress point the received multicast data traffic from the multicast source is by configuration mapped into the corresponding P2MP LSPs.
When the multicast data traffic is sent by the source, then the multicast traffic is
switched along the P2MP LSP and replicated wherever necessary. At each P2MP
LSP egress point, the multicast data traffic is now available and will be sent further
down to the subscriber when a PIM or IGMP request is received.
Since the P2MP LSPs are set up via RSVP, the full Traffic Engineering capabilities
are available for P2MP LSPs when the LSP is set up similarly to the common point
to point LSPs. During operation Fast Reroute can also be used to protect against
failures.

15/17
15/20

High Quality and Resilient IPTV Multicast Architecture Technical White Paper

6. Conclusion

5.4. Summary
PIM SM is recommended in the IP backbone when the range of potential multicast
group addresses is quite large, the multicast source IP addresses are not really
known from the beginning, or the multicast source IP addresses are subject to
change quite often during the time. Therefore the typical multicast applications to
use PIM SM are voice, video conferencing (if realized by multicast at all), or gaming. The ResIP recommendation is to use PIM SSM or P2MP LSPs for IPTV
services.
Combining the multicast features with an intelligent implementation in the equipment (i.e. routers and switches), a subsecond failover time can be achieved for
physical and also Layer 3 failures. A number of failure types need to be looked at.
This includes e.g. a link failure in the core, a failure of a router, or a failure of the
multicast source itself. A concept has been developed to assure a subsecond failover time for all these failure cases (this includes the failure detection as well as
the failure recovery).

16/20

High-quality and resilient IPTV multicast architecture Technical White Paper

6. Conclusion

The Nokia Siemens Networks and Juniper Networks ResIP Certified IPTV solution
has been certified in the ResIP Lab. It is based on mechanisms drawn from the
Nokia Siemens Networks SURPASS Home Entertainment solution, the Nokia
Siemens Networks SURPASS Carrier Ethernet, the Juniper Networks M- and
T-series routing platform, and the Juniper Networks E-series Broadband Services
Routers. The solution reduces operational costs through a well-designed subscriber management using Zero Touch Provisioning.

Engineering rules and design

guidelines are available for
service providers who want to
take advantage of the ResIP
engineering excellence.

User expectations of high-quality services delivered over a broadband network will

be no different from what is expected of todays legacy video broadcast systems.
Continuous service availability will be taken for granted, and QoS should not be
compromised, even when a failure occurs in the network. Video services put strict
demands on packet loss and delay; to some extent, these requirements are even
higher than for voice. Nokia Siemens Networks and Juniper Networks have
developed a QoS design that identifies various traffic types, and manages each
according to its specific requirements across multiple links and network elements.
The Nokia Siemens Networks and Juniper Networks ResIP Certified IPTV solution
also addresses critical aspects of network security. The solution applies common
security policies across the entire network to secure voice and video services from
network-based attacks and to protect against DoS attacks.

Nokia Siemens Networks

SURPASS Integration Solutions
support customers for fast and
riskless integration of new services on multi-vendor networks.

SURPASS Integration Solutions offers tailor-made support for the effective and
fast integration of new products and applications in todays complex and heterogeneous multi-vendor networks, and allows network operators to participate in the
ResIP outcomes.
Our approach is based on an in-depth understanding of your needs, priorities, and
requirements, thus enabling us to develop an optimized solution. We analyze your
business requirements and customize products and applications to your specific
needs. Prior to implementing the solution, we perform comprehensive tests such
as performance and conformance testing, interoperability checks, and technical
verification in a reference system to ensure proven end-to-end functionality.
Integration projects carried out by Nokia Siemens Networks result in faster
revenue generation, while keeping expenditure to a minimum by delivering the
right quality, at the right cost, and at the right time, and should you wish to see
how our standard solution would meet your demands, we can carry out a trial on
site or at one of our Nokia Siemens Networks Integration Laboratories.

Learn more!

For more information about SURPASS Carrier-Grade IP Solutions and the

ResIP PoC Lab visit www.resip.net.
For more about Juniper Networks routers, visit www.juniper.net.

17/20

7. About Nokia Siemens

Networks
and Juniper Networks
Nokia Siemens Networks is:
A Juniper Networks Authorized Education Center
to enable operators engineers;

The solution-based expertise and experience Nokia Siemens Networks has

gained in worldwide installations of voice and packet networks has resulted in a
range of unrivalled offerings. Nokia Siemens Networks is a strong and reliable
partner that offers a stable relationship for conducting successful business in the
highly competitive carrier market. Our experience and know-how can also be
demonstrated with regard to our customer base, strategic partners, and in the
availability of more than one hundred certified IP experts worldwide. This global
presence and a strong service organization support carriers 24 hours a day,
7 days a week.

An official partner in the

Juniper Networks Content
and Applications Alliance
to develop revenue generating solutions for operators;

Nokia Siemens Networks works together with preferred partner companies, all at
the leading edge in their segment, including Juniper Networks, with its leading IP
product portfolio for BSR solutions, edge and core networks, and security
technologies.

The first Juniper partner to

have achieved the status
of Juniper Networks Authorized Global Support Provider, which offers the full
range of support services
from installation to optimization worldwide.

Juniper Networks has been helping its customers build the largest, most reliable,
and most profitable IP networks in the world for nearly ten years. This blend of
world-class offerings and partnerships and our global presence and expertise offer
the best possible guarantee that Nokia Siemens Networks Next Generation
Network solutions are truly carrier-grade.
Nokia Siemens Networks and Juniper Networks have collaborated to develop an
end-to-end IP architecture for next generation networks that supports voice, video,
and data solutions as SURPASS Home Entertainment and SURPASS
VoIP@Home.
This architecture enables service providers to offer an assured experience
based on customer and application requirements. ResIP Certified Solutions
that have already undergone stringent testing are available to service providers for immediate deployment.

18/20

High-quality and resilient IPTV multicast architecture Technical White Paper

Nokia Siemens Networks and Juniper Networks are working together to solve the
toughest challenges service providers are currently facing. ResIP is designed to
help service providers through these tough times of decreasing voice revenue and
declining customer base. It includes a well-defined program to develop, test, and
certify all technology for the next generation architecture and solutions. The resulting benefits to service providers is a fully tested and complete network architecture
that allow multiple certified solutions to be deployed for new revenue opportunities.
Nokia Siemens Networks is one of the largest players in the global telecommunications industry. Nokia Siemens Networks is the only provider in the market
that offers its customers a full-range portfolio, from devices for end users to complex network infrastructures for enterprises and carriers, as well as related services. Nokia Siemens Networks Communications is the worlds innovation leader
in convergent technologies, products, and services for wireless, fixed, and enterprise networks.
Juniper Networks is the leader in enabling secure and assured communications
over a single IP network. The companys purpose-built, high-performance IP
platforms enable customers to support many different services and applications
at scale. Service providers, enterprises, governments, and research and education institutions worldwide rely on Juniper Networks to deliver products for building networks that are tailored to the specific needs of their users, services, and
applications. Juniper Networks portfolio of proven networking and security solutions supports the complex scale, security, and performance requirements of
the worlds most demanding networks.

19/20

8. Abbreviations

ATM
BSR
C-VLAN
CPE
DHCP
DR
DSL
DSLAM
EPG
ERP
FEC
FTTH
GOP
HDTV
HSI
IEEE
IGMP
IGP
IP
IPoE
IPTV
IS-IS
L2C
LSP
Mbit/s
MPEG
MPLS

Asynchronous Transfer Mode

Broadband Services Router
Customer VLAN
Customer Premises Equipment
Dynamic Host Configuration Protocol
Designated Router
Digital Subscriber Line
Digital Subscriber Line Access
Multiplexer
Electronic Program Guide
Ethernet Ring Protection
Forward Error Correction
Fiber to the Home
Group of Pictures
High-Definition Television
High-Speed Internet
Institute of Electrical and
Electronics Engineers
Internet Group Management Protocol
Interior Gateway Protocol
Internet Protocol
Internet Protocol over Ethernet
Internet Protocol Television
Intermediate System to Intermediate
System
Layer 2 Control
Label Switched Path
Megabit per Second
Motion Pictures Expert Group
Multiprotocol Label Switching

MPLS-TE
OAM
OAM&P
PIM-SM
PIM-SSM
PoC
PPP
PPPoE
P2MP
PVC
QoS
RAM
ResIP
RP
RSTP
RSVP
S-VLAN
SDTV
SPT
STB
STP
VLAN

MPLS Traffic Engineering

Operation and Maintenance
Operation and Maintenance &
Provisioning
Protocol Independent Multicast
Sparse Mode
Protocol Independent Multicast
Source-Specific Mode
Proof-of-Concept
Point-to-Point Protocol
PPP over Ethernet
Point-to-Multipoint
Permanent Virtual Circuit
Quality of Service
Rate Adaptive Mode
Resilient IP
Rendevouz Point
Rapid Spanning Tree Protocol
Resource Reservation Protocol
Service VLAN
Standard-Definition Television
Shortest Path First
Set-Top Box
Spanning Tree Protocol
Virtual LAN

Nokia Siemens Networks Corporation

P.O. Box 1
02022 Nokia Siemens Networks
Finland
Visiting address:
Karaportti 3, Espoo, Finland
Switchboard +358-71-400-4000 (Finland)
Switchboard +49-89-515-901 (Germany)
The contents of this document are copyright 2008 Nokia Siemens Networks.
All rights reserved. A license is hereby granted to download and print a copy of
this document for personal use only. No other license to any other intellectual property rights is granted herein. Unless expressly permitted herein, reproduction,
transfer, distribution, or storage of part, or all, of the contents in any form without
the prior written permission of Nokia Siemens Networks is prohibited. The content
of this document is provided AS IS, without warranties of any kind with regards to
its accuracy or reliability, and specifically excluding all implied warranties, for example of merchantability, fitness for purpose, title, and non-infringement. In no event shall
Nokia Siemens Networks be liable for any special, indirect, or consequential damages, or any damages whatsoever resulting from loss of use, data, or profits, arising
out of, or in connection with, the use of the document. Nokia Siemens Networks
reserves the right to revise the document or withdraw it at any time without prior
notice. Nokia Siemens Networks and the Wave logo are registered trademarks of
Nokia Siemens Networks. Nokia Siemens Networks product names are either
trademarks or registered trademarks of Nokia Siemens Networks. Other product
and company names mentioned herein may be trademarks or trade names of their
respective owners.
Order No. C401-00114-WP-200803-1-EN

www.nokiasiemensnetworks.com