Summary 

The Endura system is composed of distributed network components that are systemized together to deliver a scalable, IP video surveil‐
lance solution with an emphasis on delivering real‐time, high quality, live and recorded video streams to surveillance operators. Endura’s 
modular design allows for unrestricted scalability in terms of the number of devices on the network or the number of operators that can 
simultaneously access any given camera. The full assortment of Endura components includes standard resolution and mega pixel fixed 
and PTZ IP cameras; single and multi‐channel video encoders; network video decoders; a Windows‐based user/administrator interface; 
an embedded appliance for matrix‐style keyboard control and monitor wall management and navigation; a high performance, RAID6 
storage architecture with distributed load balancing and active failover support; an embedded, hybrid DVR that can function in a standa‐
lone manner as well as an Endura component; and a centralized system manager.   
 
To support its mission of efficiently scaling in size and scope, Endura relies upon and heavily leverages the performance of the underlying 
IP network.  To ease installing, configuring, and managing hundreds to thousands of system components on the network, Endura utilizes 
UPnP for device discovery.  User roles and permissions are centralized on the main system manager and can be changed or edited from 
any workstation on the network.  Updates can be pushed out to all or select components across the network for remote software up‐
dates.  SNMP is utilized on each component to enable monitoring of performance metrices from any standard SNMP monitoring console.  
In order to support the high aggregate network load introduced by video surveillance traffic, Endura relies upon multicast transmission of 
video and management commands.  Therefore, a network that is enabled to manage and route multicast traffic is paramount for proper 
operation.  These aspects of the system and the bandwidth consumed by sustained, high‐bit rate video packets requires careful planning 
selection, and utilization of network resources.  
 
Depending on the size of the network, number of multicast streams utilized, and recording options configured, Endura has the ability to 
operate in a simplified Layer 2 design or a scalable Layer 3 network. Many factors go into the selection of a network topology and no two 
installations are generally the same.  This guide is designed to provide the information an experienced network engineer needs in order 
to plan a proper network topology to support the needs of a given installation.  Some connection examples are provided for illustration 
purposes only.  For additional assistance with network planning and programming, Pelco offers fee‐based professional services that au‐
thorized integrators and resellers can leverage.    

C1640M-C (8/08) 1
Endura Overview 

Endura is a high performance, scalable, IP video surveillance platform designed to manage, record, and display real‐time, high resolution 
video from several thousand video sources across an IP network.  No longer limited by the confines of analog CCTV systems, Endura 
offers a virtual matrix platform that can deliver any camera to any monitor in a digital solution while still retaining the performance, 
security, and functionality of analog matrix switchers. Designed with scalability in terms of both devices and operators in mind, Endura 
delivers a deterministic user experience regardless if the system has 16 or 1000 cameras or if a single or dozens of operators are 
simultaneously accessing the system.  Built upon open IT standards and leveraging Pelco‐engineered hardware for superior performance, 
maintainability, and serviceability, the Endura architecture can efficiently manage any combination of standard resolution and mega pixel 
resolution fixed and PTZ IP cameras, delivering crystal clear, real‐time video to dozens of operators simultaneously.  There is virtually no 
end to how a system and its components can interact and share video, audio, and control information. 

The Endura IP Video surveillance platform offers all the components necessary for designing, installing, and utilizing complete networked 
digital video ‐systems. With encoders, decoders,  pooled network video storage, PC workstations, video console displays,  IP cameras, 
Megapixel cameras,  DVRs, and advanced management technologies, customers now have the tools necessary for building a high‐
performance, distributed video surveillance system, all delivered over an Ethernet network with total access flexibility. 

ENDURA COMPONENTS 
Endura components take full advantage of leading edge technologies such as Universal Plug and Play (UPnP™), allowing for fast, error‐
proof installations and setup. When an Endura device is added to a system, the device announces itself and its services. The existing 
devices acknowledge the new unit and then begin exchanging information as user preferences and profiles dictate.   

Table 1: Endura Components and Descriptions 

Endura Recording Solutions 

NSM5200  The NSM5200 is a purpose‐built storage platform designed to accommodate the unique requirements of 
video surveillance recording.  Each NSM can accommodate 250Mbps of deterministic write throughput, 
supporting higher camera concentrations per server than previously possible.  In addition, the default 
RAID6 array protects valuable recorded footage from hard disk drive errors.  The performance of the 
system is guaranteed regardless of the health of the system.  The NSM5200 supports a SAS option card or a 
fiber channel card to connect to additional storage.  The SAS option connects the NSM5200 to DAS5200 
storage expansion boxes produced by Pelco.  The accompanying software allows each NSM5200 to serve as 
a NVR server, storage array, and storage cluster manager.  Multiple NSM5200s can be configured in a 
storage pool, providing automatic network load balancing and up to N+N failover. It is capable of 
continuous, scheduled, alarm/event, and motion recording. Pre‐ and post‐alarm, event, and motion 
recording is also available and is fully programmable on a per‐channel basis. The unit maximizes storage 
™
efficiency using EnduraStor , a time‐ and priority‐based grooming technology that can reduce the frame 
rate of stored video based on age or the prioritization of the data. 

DAS5200  The DAS5200 is a direct attached storage box that can be connected to the NSM5200 or any number of 
Pelco video recorders.  Utilizing SAS (Serial Attached SCSI), the DAS5200 can cost effectively increase the 
storage capacity available to a recorder without impacting critical network resources. Each NSM5200 can 
support up to 7 DAS5200 storage expansion modules daisy chained from the NSM5200.  The DAS5200s also 
provide for on‐line storage expansion, allowing users to add additional retention without disrupting 
recording operations.   

2 C1640M-C (8/08)
 DVR5100  The DVR5100 is an embedded hybrid video recorder with local control and display. Ideal as an edge device, 
the DVR5100 can record up to 20 cameras in real time at 4CIF resolution. It supports both analog camera 
inputs and IP camera connections.  When systemized with Endura, the DVR5100 appears as 20 cameras 
with its own NVR.  All of its services are exposed and available to the Endura IP Video Management system 
for configuration and utilization. 

Endura Edge Capture Devices 

NET5301T/NET5301T‐I  The NET5301T encoder is a single input, dual‐stream MPEG‐4 video encoder capable of supporting two 
streams of 4CIF resolution, 30/25 (NTSC/PAL) images per second. It supports audio capture, positioning 
system interfaces as well as relays and alarms. The NET5301T‐I adds video analytics processing at the edge 
and supports various behaviors available through software licenses. 

NET5308T  The NET5308T is an MPEG‐4 , dual‐stream, 8‐input (standard) or 16‐input (optional) encoder capable of 
supporting two streams from each camera input at 4CIF resolution, 30/25 (NTSC/PAL) images per second. 
Like the single channel encoders, the NET5308T supports audio, positioning system (PTZ), and alarm/relay 
interfaces. The NET5308T base unit is an 8‐ input encoder. The NET5308T‐EXP can be added to the same 
base unit to support up to 16 cameras. 

Pelco IP Camera  Pelco offers a wide range of IP cameras covering various form factors and including positioning systems.  
Solutions  Pelco’s range of IP cameras support both MPEG4 and H.264 compression standards and include standard 
resolution as well as mega pixel offerings.   With options for intelligent video analytics, high profile H.264 
compression, PoE support, and industry leading low‐light performance, Pelco’s IP camera offer a 
compelling value proposition for Greenfield installations. 

Endura Viewing Solutions 

WS5200  Workstation  The WS5200 Endura workstation is a Windows®‐compatible viewing and management software interface 
for the Endura system. The WS5200 advanced system management software is required for system 
administration, and it is provided either pre‐bundled with a server (WS5070) or as a software‐only solution. 
The WS5200 displays video compressed in standards‐compliant MPEG4 or H.264 Baseline, Main, or High 
profile.  Depending on the compute power available in the PC, the WS5200 can simultaneously decode up 
to 16 MPEG4 streams at 4CIF resolution, 30/25IPS, or up to 12 H.264 baseline profile streams at 4CIF 
resolution, 30/25IPS, or up to 2 1080p streams in real‐time.  When additional streams are displayed, 
Endura’s EnduraView technology automatically seeks out and displays a lower resolution stream to 
mitigate CPU and network bandwidth load issues.   

WS5200‐MAP Mapping  The WS5200‐MAP interface provides an efficient way to visualize an entire area.  A full map editing utility is 
Interface  provided including the ability to import predefined maps in various formats and easily create layers and 
hyperlinks for efficient navigation.  The customizable icons indicate the occurance of alarms in underlying 
layers, provide for an easy visual verification of the alarm condition as well as convenient management 
tools to acknowledge the alarm or push the associated video onto any network monitor available.  The 
WS5200‐MAP displays thumbnails of live or recorded video in MPEG4 or H.264 Baseline, Main, or High 
profile.   

NET5402R‐HD  The NET5402R‐HD is a high performance, multi‐stream video decoder capable of displaying streams from 
IP cameras and video encoders compressed in standards‐compliant MPEG‐4 or H.264 Baseline, Main, or 
High profiles. The NET5402R‐HD uniquely combines the requirements for real‐time surveillance installa‐
tions with the complexity introduced by today's IP and megapixel cameras. Each decoder drive two high 
definition monitors and  simultaneously decode and display up to 16 MPEG‐4 streams at 4CIF resolution, 
30/25 IPS, or up to 12 H.264 baseline streams at 4CIF resolution, 30/25IPS, or 2 1080p streams at 30IPS.  
When additional streams are displayed, the NET5402R‐HD utilizes EnduraView to automatically seek out 
and display a lower resolution stream to mitigate CPU and network bandwidth load issues.   

C1640M-C (8/08) 3
 VCD5202  The VCD5202 is the ideal user interface for CCTV‐style operation of a virtual matrix system.  The VCD5202 
provides for an icon based, heads‐up menu structure designed to intuitively guide the operator to the 
actions and options available.  When combined with the KBD5000, the VCD5202 provides the same user 
experience on a virtual matrix as operators enjoyed with analog matrixes.  Each VCD5202 can drive two 
high definition monitors and simultaneously decode and display up to 16 MPEG4 4CIF resolution, 30/25IPS 
streams or 12 H.264 Baseline profile 4CIF resolution, 30/25IPS streams, or 2 1080p streams in real‐time.  
When additional streams are displayed, the VCD5202 utilizes EnduraView to automatically seek out and 
display a lower resolution stream to mitigate CPU and network bandwidth load issues.   

NET5301‐TC  The NET5301‐TC transcoder converts MPEG‐4 video from the Endura network into formats that are 
compatible with limited bandwidth networks, such as a local area network (LAN), wide area network 
(WAN), or the Internet. 

GW5000  The GW5000 gateway delivers MPEG4 video from the Endura network to users communicating through a 
public network such as a lLAN, WAN, or the Internet.  

CM9700MDD‐EVS  The CM9700MDD‐EVS is a network interface to the CM9700 analog matrix. Through the CM9700, 
operators can continue to use the existing matrix as their main operator interface while taking advantage 
of Endura as both a recording engine in the background and as a secondary system to the analog matrix. 

Endura System Manager  

SM5000  The SM5000 system manager (SM) is an integrated hardware/software component that provides ‐
distributed administration of multiple devices. The SM5000 also manages system security, functioning as a 
key server for user and device authentication.  In networks without an available DHCP server, the SM5000 
functions as the Endura DHCP server for Endura components.  In networks without an available NTP 
source, the SM5000 also functions as the NTP clock for the Endura system. 

FUNCTIONAL OVERVIEW 
Endura encoders and IP cameras operate with dual streams.  The high resolution and low resolution streams are transmitted to a 
multicast rendezvous group address, allowing any number of viewing devices to subscribe and pull the required stream across the 
network.  The high resolution stream is also pulled across as a unicast stream the NSM5200s.  Each NSM storage pool records the unicast 
stream.  During periods of network load balancing, a second instance of the same unicast stream is pulled across.  Viewing devices utilize 
EnduraView to minimize the CPU and network bandwidth load of decoding multiple simultaneous streams.  Depending on the screen 
configuration and the type of camera being displayed, EnduraView will automatically subscribe to and pull the lower resolution multicast 
stream to minimize the amount of processing power required for decoding and displaying a large number of streams.  When the 
processing power is fully exhausted, EnduraView will decode index frames in the MPEG4 or H.264 stream for non‐active cameras.     

4 C1640M-C (8/08)
  

C1640M-C (8/08) 5
Endura Network Design Considerations 

Endura is designed to deliver high‐quality, low‐latency surveillance video with virtually unlimited scalability and expandability. It heavily 
leverages, and is dependent upon, the network infrastructure. Careful planning and layout of the network is essential.  

When planning an Endura network there are several considerations that should be taken into account when designing the network: 

• Is the installation best served with switching and routing decisions centralized on a core switch or managed at the edge via 
intelligent edge switches? 

• Will the network use a Layer 2, Layer 3, or hybrid approach? 

• Is system scalability a requirement? 

• How much multicast traffic is predicted to be utilized across the network? 

• How many cameras and at what bit‐rate will need to be supported? 

• What other data is utilizing the same network and how much of the network can be provisioned for video surveillance? 

• How many operators will need to access the video and where are they located? 

• Will redundant recording or remote access be required for the video surveillance system? 

CORE‐SWTICHED NETWORK TOPOLOGY 

The centralized network design topology is based on a central network core, which is responsible for all routing decisions. This approach 
requires the use of high‐performance and high‐cost core network equipment. This approach will work if the specified network switch is 
capable of the following:  
• Managing all of the unicast routing decisions  
• Managing all of the multicast routing decisions 
• Handling all Endura network traffic: video, audio, PTZ, and UPnP 
• Handling all other existing network traffic 

This approach may meet your network design requirements; however this approach might not be as scalable as a decentralized design 
since the volume of network traffic and the increased use of switch resources can easily consume the capacity of the core switch.  

If network expansion is a future goal, then a decentralized design, leveraging Layer 3 at the edge, offers a more scalable networking 
solution. 

Considerations for Deployment of a Centralized Approach 

• Centralized designs have components terminated to a single location. Costs associated with terminating all cables to a single 
point can be significantly higher.  

• When components in an Endura network are centralized in a single location HVAC requirement to cool the equipment are much 
more demanding than a decentralized approach.  

• Centralized design approaches can sometimes lead to a single point of failure for the Endura network.  

6 C1640M-C (8/08)
DECENTRALIZED NETWORK TOPOLOGY 

A decentralized network topology is not dependent on a centralized network core. Endura components can be distributed to 
environmentally appropriate IDF closets. These Endura components can be terminated to a switch in the local IDF closet, and then 
backhauled to the MDF for inner‐connectivity. This type of network topology is a significantly more scalable approach than a centralized 
network topology. Either Layer 2 or Layer 3 switches can be used at the edge, but Layer 3 switches will give a network engineer more 
flexibility in distributing the routing load of unicast and multicast traffic throughout available switches in the network. The following 
considerations should be taken when utilizing a decentralized design approach. 
 

• Do the IDF locations have adequate cooling to keep all components within their operational parameters  as defined by the 
manufacturers  recommended specifications? 

•  Can existing network infrastructure be leveraged to limit the amount of cabling pulls needed? 

•  Do the IDF closets have adequate power to handle the devices that will be installed? 

• If routing will be pushed to the edge of the network do the switches support the appropriate routing protocols? 

• Is advanced licensing required to activate the features that will be utilized at the edge of the network?  

• Does the switch at the edge of the network allow for all devices to be connected at the appropriate speed and duplex, while 
reserving enough gigabit uplinks for connectivity to the core?  

• Can the configured uplinks handle the worst case scenario traffic load across the uplink or trunk?   

LAYER 2 DESIGN APPROACH 

The Endura network can be designed utilizing a Layer 2 solution, Layer 3 solution, or a hybrid solution. When utilizing a Layer 2 only 
solution, there are certain considerations that need to be take with respect to switch selection. The following are considerations that 
need to be addressed when considering a Layer 2 only solution.  

• Does communication of the Endura system span multiple subnets or multiple VLANs? If the Endura traffic needs to traverse 
multiple subnets or VLANs a Layer 3 solution should be implemented.  

• Are there a finite number of cameras expected in the deployment of the site, with little or no room for growth and expansion? 
While each switch will vary in it capacity to handle traffic Pelco recommends a Layer 2 approach for sites that have less than 
500 cameras that do not anticipate growth or expansion beyond the 500 camera limit.  

• Does the switch that is selected support appropriate number IGMP entries for the installation? Network engineers should 
determine the worst case scenario for expected IGMP entries on the Layer 2 devices. It is important not to exceed the number 
of IGMP entries the switch can handle, as it will either block multicast traffic, or flood multicast traffic when these limits are 
exceeded. Note: Pelco has conducted tests with switches from HP and Cisco.  If an integrator opts to use a switch that has not 
been tested by Pelco, it will be up to the integrator to consult the switch manufacturer to determine the IGMP limits of the 
device selected.  

• In a Layer 2 only solution, it is critical to ensure that the inner‐connectivity between the switches is capable of handling the 
anticipated traffic load.   

• Careful attention to the standards that a Layer 2 switch supports is crucial when using Layer 2 switching with multi‐channel 
encoders.  With a multi‐channel encoder, up to 16 channels of video can be transmitted through a single Ethernet port.  If a 
switch was to have 96 available ports and 94 of those ports were populated with devices that generate 16 streams of video 
each, 1504 channels of video would be traversing through a single switch. The density of cameras connected to the switch is far 
greater than the number of visually connected ports. Network engineers need to consider the number of video channels or 
camera density that a switch is being asked to handle. If the resources of the switch cannot handle the camera density 
connected, reduction in the number of connections may be necessary.  In addition, some Layer 2 switches use Layer 2 addreses 
to direct map to the CAM tables for IGMP control.  Some multi‐channel encoders increment only the first octet to distinguish 
between channels, leaving the last three octets in‐tact.  Using direct mapping, this will lead to all 8 channels of video being 
routed to the same MAC address on the switch and can cause saturation, flooding, or loss of video.    

C1640M-C (8/08) 7
 • If switches are to be stacked to increase port density, network engineers should determine the operational parameters of the 
switch stack. Stacking allows you to create a much higher port density while simplifying administration, but if stacking the 
switches does not increase the switch resources, the increase in port density can exceed switch resources.     

LAYER 3 DESIGN APPROACH 

When an Endura system is utilizing an Layer 3 approach in it design, there is an inherent need to route Endura traffic between multiple 
VLANs or subnets. If the Endura traffic is going to traverse multiple subnets or VLANs, appropriate multicast routing protocols must be 
utilized to facilitate the multicast traffic throughout the network infrastructure. The following are considerations that need to be 
addressed when implementing a Layer 3 solution with Endura.  

• Layer 3 devices do not all have the ability to process data at line speed. Traditional routers that are utilized to route traffic 
across WAN connections are typically implemented on devices that utilize software routing. Layer 3 switches typically 
implement a hardware solution to handle all Layer 2 switching and Layer 3 routing. Routing for Endura should be performed by 
Layer 3 switches that have the capacity to transfer the data at line speed. Software based routers should only be utilized when 
the expectation is that a low volume of traffic will traverse the link. This traffic volume should remain within the capabilities of 
the WAN router.  

• A Layer 3 solution can be implemented utilizing a centralized routing topology or a distributed routing topology. Based upon 
the routing load that will be handled by a centralized Layer 3 switch, the decision to push the Layer 3 routing to the edge 
devices can help alleviate the strain of a single core switch handling all routing decisions.  

• At least one multicast routing protocol must be utilized to allow multicast routing between VLANs. PIM, DVRMP or MOSPF can 
all be used to route multicast traffic throughout the network. Careful planning must be performed to ensure that the multicast 
limits of the switch, and protocol selected are not exceeded.  

• Careful consideration must be given to the number of Layer 3 hops that the Endura traffic is traversing. As the number of hops 
increase, there will be an expected latency associated with the response of the Endura system. The default TTL limits are as 
follows: 

o  SMLocator service TTL=4 

o Video Streams have a TTL=3 

o Local discover has a TTL=1.  

These limits can be modified to accommodate different network topologies, however, staying within the default TTL limits will 
yield optimum performance.  

8 C1640M-C (8/08)
BASIC REQUIREMENTS 
The Endura system utilizes multiple network protocols for video transmission and command and control: 

• TCP (Transmission Control Protocol) 

• UDP/Unicast (User Datagram Protocol) 

• UDP/Multicast 

• DHCP (Dynamic Host Configuration Protocol) 

• UPnP (Universal Plug and Play) 

• RTP (Real‐Time Transport Protocol) 

• RPC (Remote Procedure Call)   

NETWORK PORTS UTILIZED: 
SM5000:
PORT/(tcp,udp) SERVICE

22/tcp SSH

67/udp DHCP Server

123/udp NTP

1900/udp upnp discovery

2900-2902/udp Locator traffic

3001/tcp Endura Mapping

10000/both SM Configuration

32768-61000/udp UPNP Communication

49152-49155/tcp UPNP Communication

60000/tcp System Manager

60001/both System Manager

60100/tcp Event Arbiter

60200/tcp Script Manager

DVR5100:
PORT/(tcp,udp) SERVICE

22/tcp SSH

161/udp SNMP

27235/tcp VPN

60000/tcp System Manager

NET5402R-HD:

C1640M-C (8/08) 9
 PORT/(tcp,udp) SERVICE

22/tcp ssh

68/udp dhcp client

123/udp ntp

1024-4999/udp UPNP Communication

1900,2900-2901/udp UPnP discovery

4242/tcp HAL

4343/tcp HAL

49152/tcp UPnP communication

31000/udp DecoderApp

31001/udp DecoderApp

NET5301T:
PORT/(tcp,udp) SERVICE

22/tcp ssh

68/udp dhcp client

123/udp ntp

1024-4999/udp UPNP Communication

1900,2900-2901/udp UPnP discovery

20xxx/udp UPNP Communication

49152/tcp UPNP Communication

NET5301T-I:
PORT/(tcp,udp) SERVICE

21/tcp ftp

22/tcp ssh

23/tcp telnet

68/udp dhcp client

123/udp ntp

1024-4999/udp UPNP Communication

1900,2900-2901/udp UPnP discovery

4242/tcp HAL

4343/tcp HAL

20xxx/udp UPNP Communication

30001/udp UPNP Communication

49152/tcp UPnP communication

NSM5200:

10 C1640M-C (8/08)
 PORT/(tcp,udp) SERVICE

22/tcp ssh

68/udp dhcp client

80/tcp http

161/udp snmp

162/udp snmp-trap

199/tcp smux

1781/udp nsterm search

2900-2901/udp UPnP discovery

4343/tcp HAL

10001/tcp NSD

10003/tcp NSM

10005/tcp Heartbeat

10006/tcp Watchdog

16005/tcp nsterm server

25556/tcp db replication

32768-61000/udp UPNP Communication

49152/tcp UPNP Communication

Sarix IP Cameras:
PORT/(tcp,udp) SERVICE

22/tcp SSH

68/udp dhcp client

80/tcp HTTP

81/tcp SOAP

83/tcp GENA

111/both portmap

123/udp NTP

161/udp SNMP

389/tcp LDAP

554/tcp RTSP

514/udp Syslog

718/udp rpc.statd

721/udp rpc.statd

724/tcp rpc.statd

1900,2900-2901/udp UPnP discovery

5353/udp MDNS

6700-6900/udp RTCP

C1640M-C (8/08) 11
 VCD5202:
PORT/(tcp,udp) SERVICE

22/tcp ssh

68/udp dhcp client

123/udp ntp

161/udp snmp

1900,2900-2901/udp UPnP discovery

4343/tcp HAL

6000/tcp X11

32768-61000/udp UPNP Communication

49152/tcp UPnP communication

WS5270:
PORT/(tcp,udp) SERVICE

135/tcp msrpc

139/tcp netbios-ssn

445/tcp microsoft-ds

1024-5000/udp UPNP Communication

4343/tcp HAL

49152-49159/tcp UPNP Communication

PHYSICAL MEDIA REQUIREMENTS  
Physical media used in the Endura network is as follows: 
• 100Base‐T minimum for IP Cameras and Single Channel Encoders. 
• 1000Base‐T minimum is required for all other Endura Devices.  
• Cat6 or Cat6a cabling is recommended with Cat5e as a minimal requirement.   
• Cat6 or Cat6a should be utilized for all uplinks between switches. 
• Single or multi‐mode fiber should be used for distances exceeding copper standards. 
 

BANDWIDTH REQUIREMENTS 
Endura is designed for high‐performance, real‐time video surveillance applications.  As such, it is capable of encoding, recording 
and displaying multiple high resolution, real‐time cameras.  Video traffic not only uses larger data packets than normal network 
data, but it is also constant and extremely sensitive to network congestion and jitter.  Care must be taken to ensure that 
adequate bandwidth is available to support the full functionality of any camera, any recorder, and any view station.  The 
following summarizes some of the standard bit‐rates that Endura and Pelco IP cameras support.  For 3rd party cameras, please 
consult the vendor’s published bit‐rate estimations.  Keep in mind that the complexity of the scene and amount of motion in 
the scene can substantially increase the bit‐rate produced by the camera if some sort of constrained bit‐rate is not utilized.   

12 C1640M-C (8/08)
 Sarix Megapixel IP Cameras:
IXS0 Endura Pre-Sets
Name Width Height FPS Bitrate IFI

MPEG4 4CIF (PAL) 704 576 25 2050 12

Secondary 352 288 25 500 12
MPEG4 4SIF (NTSC) 704 480 30 2000 15
Secondary 352 240 30 450 15
MPEG4 CIF (PAL) 352 288 25 500 12
Secondary 352 288 12.5 300 6
MPEG4 SIF (NTSC) 352 240 30 450 15
Secondary 352 240 15 300 7
H264 SVGA @ 15 FPS 800 608 15 1500 7
Secondary 320 240 15 200 7
H264 VGA @ 30 FPS 640 480 30 1300 15
Secondary 320 240 15 200 7

IX10 Endura Pre-Sets

Name Width Height FPS Bitrate IFI

1.3 MP @ 8 FPS 1280 1024 8 2500 8

Secondary 640 512 2 150 4
720p @ 6 FPS 1280 720 6 1400 6
Secondary 640 352 6 300 6
640x352 @ 30 FPS 640 352 30 1150 15
Secondary 320 176 30 150 15
SXVGA @ 6 FPS 1280 960 6 1850 6
Secondary 640 480 6 450 6
SVGA @ 15 FPS 800 608 15 1500 7
Secondary 320 240 15 200 7
VGA @ 30 FPS 640 480 30 1300 15
Secondary 320 240 10 100 5

C1640M-C (8/08) 13
 IXE20 Endura Pre-Sets
Name Width Height FPS Bitrate IFI Profile

1080p @30 FPS 1920 1080 30 5000 30 High (IP)

Secondary 640 352 5 700 5 Baseline
1080p@25FPS 1920 1080 25 5000 25 High (IP)
Secondary 640 352 5 700 5 Baseline
1080p @ 15 FPS 1920 1080 15 3350 7 High (IP)
Secondary 640 352 15 750 7 Baseline
720p@30 FPS 1280 720 30 3700 15 High (IP)
Secondary 640 352 15 750 15 Baseline
720p@25 FPS 1280 720 25 3700 13 High (IP)
Secondary 640 352 12.5 750 7 Baseline
720p @ 15 FPS 1280 720 15 3000 7 High (IP)
Secondary 640 352 15 750 7 Baseline
640x352 @ 30 FPS 640 352 30 1200 15 Baseline
Secondary 320 176 15 150 7 Baseline
SXVGA @ 15 FPS 1280 960 15 3000 7 High (IP)
Secondary 640 480 15 1000 7 Baseline
SVGA @ 30 FPS 800 608 30 2000 15 Baseline
Secondary 320 240 5 200 5 Baseline
VGA @ 30 FPS 640 480 30 1600 15 Baseline
Secondary 320 240 15 250 5 Baseline

IX30
Name Width Height FPS Bitrate IFI

1080p @ 5 FPS 1920 1080 5 2650 5

Secondary 640 352 2.5 150 4
720p @ 6 FPS 1280 720 6 1400 6
Secondary 640 352 6 300 6
640x352 @ 30 FPS 640 352 30 1150 15
Secondary 320 176 30 150 15
QXGA @ 3 FPS 2048 1536 3 3000 4
Secondary 640 480 3 250 4
SXVGA @ 6 FPS 1280 960 6 1850 6
Secondary 640 480 6 450 6
H264 SVGA @ 15 FPS 800 608 15 1500 7
Secondary 320 240 15 200 7
VGA @ 30 FPS 640 480 30 1300 15
Secondary 320 240 10 100 5

14 C1640M-C (8/08)
 Standard Resolution MPEG4 IP Cameras and Encoders:
IP110/IP3701/Spectra IV IP/Spectra-Mini IP/NET5301T/NET5308T/ENC53xx (NTSC/PAL)
Name Width Height FPS Bitrate IFI

4SIF/4CIF 704 480/576 30/25 2000 15

Secondary 352 240/288 15/12.5 800 7
4SIF/4CIF 704 480/576 15/12.5 1500 7
Secondary 352 240/288 15/12.5 800 7
4SIF/4CIF 704 480/576 10/8.3 1100 5
Secondary 352 240/288 15/12.5 800 7
4SIF/4CIF 704 480/576 6/5 800 3
Secondary 352 240/288 15/12.5 800 7
2SIF/2CIF 704 240/288 30/15 1500 15
Secondary 352 240/288 15/12.5 800 7
2SIF/2CIF 704 240/288 15/12.5 1000 7
Secondary 352 240/288 15/12.5 800 7
2SIF/2CIF 704 240/288 10/8.3 800 5
Secondary 352 240/288 15/12.5 800 7
2SIF/2CIF 704 240/288 6/5 600 3
Secondary 352 240/288 15/12.5 800 7
SIF/CIF 352 240/288 30/25 1000 15
Secondary 176 120/144 15/12.5 800 7
SIF/CIF 352 240/288 15/12.5 800 7
Secondary 176 120/144 15/12.5 800 7
SIF/CIF 352 240/288 10/8.3 500 5
Secondary 176 120/144 15/12.5 800 7
SIF/CIF 352 240/288 6/5 350 3
Secondary 176 120/144 15/12.5 800 7

C1640M-C (8/08) 15
CALCULATING BANDWIDTH REQUIREMENTS: 
This section provides information to assist in the calculation of bandwidth requirements for the Endura network.  We utilize the 
standard resolution, MPEG4 bit‐rates for illustration purposes:  

• Maximum bit‐rate from a standard resolution Pelco IP camera or NET5301T encoder is 7.5 Mbps plus overhead. 

     Up to 3 Mbps total for both multicast live streams: up to 2 Mbps for stream 1 (4CIF); up to 1 Mbps for stream 2 (CIF) 
  + Up to 4 Mbps for two unicast recording streams 
  + 64kbps for audio 
  + ~400kbps for command and control overhead 
7.5 Mbps total with audio and data 
 

NOTES: 
• Live video traffic is only streamed across the network when requested by a view station. 
• Throughput needs to be calculated at various points on the network, depending on how many cameras are going to 
be viewed and at what size. 
 
• Maximum bit‐rate from an NSM5200 or NSM5200 Storage Pool Manager for playback is 100Mbps: 
• Playback is not a stream, but “bursts” of data.  The NSM5200 works in conjunction with the viewing device to cache 
and buffer the playback bursts to provide for smooth playback.   
• As an approximation, assume that each NSM5200 or NSM5200 storage pool manager has a 100 Mbps cap on playback 
data: 
– The NSM5200/NSM5200 pool manager will use as much of the 100 Mbps bandwidth as necessary to transmit 
the requested clip data. 
– The NSM5200/NSM5200 pool manager will divide the 100 Mbps among multiple playback requests (if 
necessary). 
• Playback transmissions are unicast.   
• As the playback stream is the high resolution stream used for recording and a second stream is not available, playback 
represents the worse‐case scenario for bandwidth utilization. 
 

• Maximum bit‐rate at view stations: 

Unlike the encoders or recorders, calculating the bandwidth requirement at the viewing station is a bit more involved.  
Video decoding is a processor intensive operation.  This is compounded when more than one camera is decoded and 
displayed at the same time.  The Endura viewing devices utilize an architecture that takes advantage of any processing 
power available to decode and render the video.  The framework used in Endura utilizes the graphic card’s GPU to render 
video and the host CPU to decode it.  This division of labor allows for more streams to be decoded and displayed 
simultaneously.   

While performance is enhanced, the use of mega pixel cameras and high complexity compression/decompression (codec) 
schemes such as H.264 will eventually push the performance of the system to its physical limits.  In order to mitigate the 
detrimental impact of running a Windows® machine at the maximum capacity of its processor, Endura utilizes 
EnduraView™ to manage the CPU load and network bandwidth when displaying multiple cameras on the same monitor.   

EnduraView is designed to provide the operator with the best image quality and frame rate for a given networked monitor 
and screen layout.  Its primary mission is to ensure that the processing capacity of the decoding device is not over‐
subscribed.  EnduraView is invoked in three different ways: 

o Video Layout Stream Preferences – This provides the operator with the best possible resolution and frame rate 
and is based on the size of the video area and the number of streams the layout can support.  As layouts are 
changed, EnduraView will first attempt to subscribe to a lower resolution, secondary stream.  If the decoding 
demand still exceeds the performance available, EnduraView will decode only I‐frames starting with the last 
recently used stream.  

16 C1640M-C (8/08)
 o Today’s high performance video cards can only render so many frames before they run out of bandwidth.  To 
accommodate variations in performance, the system has a limit of 480 frames per second.  This means that up to 
16 streams can be rendered at 30fps per view station.  The rest of the streams will be displayed at their I‐frame 
rates. 

o Since the CPU does all of the decoding, the system monitors CPU load to determine when to invoke EnduraView.  
When the CPU averages over 70% utilization for more than 30 seconds, EnduraView will be invoked and the 
streams will be changed starting with the last recently used.  If all of the stream are the secondary stream and 
the CPU is still over 70% utilization, the user will receive a warning message to start closing down unnecessary 
applications. 

o The following table provides examples as to the maximum number, size, and framerate of video streams that a 
WS5070 can sustain before EnduraView is invoked: 

Screen Division Video Cell Maximum Performance before EnduraView

H.264 2048X1536
1x1 ALL
30fps
H.264 2048X1536
2x2 ALL
15fps
3x3 ALL H.264 800x608 30fps
3x2 ALL H.264 800x608 30fps
4x3 ALL H.264 800x608 30fps
4x4 ALL H.264 800x608 15fps
H.264 2048X1536
1 Large
1+5 15fps
5 Small H.264 800x608 15fps
H.264 2048X1536
1 Large
1+12 15fps
12 Small H.264 800x608 15fps
H.264 2048X1536
2 Large
2+8 15fps
8 Small H.264 800x608 15fps

 The WS5070 is capable of displaying up to 16 MPEG4 streams at 30/25fps for 4CIF resolution.  It is also capable of displaying 12 
4CIF/30 H.264 streams, or 2 1080p streams.  All Endura view stations (WS5070, NET5402R‐HD, VCD5202) have the same 
performance.  Further, all can span two monitors, therefore displaying up to 32 streams per unit, though not at real‐time.  With 
EnduraView invoked, the worse case scenario for network bandwidth utilization occurs when the system is used to playback 16 
simultaneous streams.   

The worst‐case bandwidth (BWC) requirements for live and playback video is given by the following equation: 

BWC = BW + OH, where 

BW = Bandwidth and is given by the equation BW = NS x BR 

OH = Overhead and is given by the equation OH = 25% x BW  

NS = Number of streams 

BR = Bit rate 

The above equations are general and assume that all playback streams are of the same quality. For information about BR values, 
refer to the bit‐rate charts above or the specific camera manufacturer’s guidelines. 
 

C1640M-C (8/08) 17
 Worst‐Case Bandwidth Calculation in Playback Mode 

When reading the following examples, assume that all recorded video is at 4CIF (2 Mbps) at 30 ips and using the WS5200: 

Example: Playback Video Stream with the WS5200 Endura Workstation 
Each WS5200 can display 16 simultaneous playback streams.  

To calculate the worst‐case bandwidth for the WS5000: 
1. Find the bandwidth.  

BW = NS x BR = 16 x 2 Mbps = 32 Mbps 

2. Find the overhead.  

OH = 25% x BW = 16 x 2 Mbps x 25% = 8 Mbps 

3. Find the worst‐case bandwidth. 

BWC = (NS x BR) + OH = 32 Mbps + 8 Mbps = 40 Mbps 

Of course, if mega pixel resolution cameras are utilized, the bandwidth requirements will be much higher.  Therefore, it is vital 
that all Endura view stations are provisioned with 1Gbps network links. 

18 C1640M-C (8/08)
TOPOLOGY REQUIREMENTS: 

LAYER 2 NETWORK REQUIREMENTS

IGMP Version 2 Layer 2 SNOOPING 

Proper implementation of IGMP snooping at Layer 2 is critical to the success of an Endura installation. IGMP snooping is 
designed to prevent hosts on a local network from receiving traffic from a multicast group they have not explicitly joined.  The 
host explicitly utilizes IGMP Join and Leave messages to control membership to multicast groups it wants to receive.  IGMP joins 
and leaves provide the switches with a mechanism to prune multicast traffic from links that do not contain a multicast 
subscriber (IGMP client).  A switch that does not perform IGMP snooping may, 'flood' multicast traffic to all ports in a broadcast 
domain (or the VLAN equivalent).  Multicast can cause unnecessary or even crippling load on host devices by requiring them to 
process packets they have not solicited.  IGMP Snooping is therefore especially useful for bandwidth‐intensive applications like 
Endura that utilize multicast as a transport.  Each switch has a different capacity for IGMP handling within its tables and 
response to tables becoming overloaded.  Switches that block traffic when the IMGP table is overloaded will drop video streams 
from the network resulting in data loss for recording or live view.  Switches that flood multicast traffic when IGMP tables are 
overloaded will create unnecessary traffic across the network, possibly degrading the quality of Endura video.  

LAYER 2 LINK AGGREGATION 

The implementation of Link aggregation in an Endura network is designed to overcome two problems commonly encountered 
in IP video surveillance installations: bandwidth limitations on uplinks and an absence of fault tolerance or redundancy on 
critical network resources. Combining two or more physical Ethernet links into one logical link via channel bonding helps 
distribute some of the network load across multiple links while creating redundancy in the links themselves. The IEEE standards 
for link aggregation are well defined, but the algorithms that are used by various switch manufactures can cause variations in 
load distribution across trunk links leading to saturation of critical network resources that appear to have adequate bandwidth. 
Depending upon the algorithm used by the switch manufacturer, the introduction of multicast traffic across aggregated trunk 
links can sometimes cause an unbalanced load distribution across the link.   Network engineers should perform careful analysis 
of load distribution across aggregated trunks to ensure that individual links in a trunk are not being saturated. Most switch 
manufacturers assume traditional packet payloads when determining aggregation algorithms. Since video traffic has a larger 
packet size, and is transmitted at a higher packet per second rate, network engineers need to pay special attention to link 
utilization across trunks.  Pelco recommends that any bonded member of an aggregated trunk link should not exceed 50% 
utilization.  Aggregated links that have bonded members that have exceeded 50% utilization tend to exhibit higher latency and 
potential data loss for live and recorded video.   

Note: Some aggregation algorithms can take an extended period of time to redistribute the load across bonded members. 
Network engineers should take these values once the system had initialized and system has been running for at least 24 hours.  

Note: The NSM5200 storage pool consumes two unicast streams of the high resolution stream.  When aggregating links from 
switches that serve cameras to switches that service the storage pool, pay close attention to the aggregate bandwidth utilized 
and consider creating VLANs that can manage the bandwidth across a given aggregation link.   
 

LAYER 3 NETWORK REQUIREMENTS

STATIC ROUTING 

Smaller networks employ static routing tables to forward data across a network by way of fixed paths. Static routing cannot 
adjust to changing line conditions in the same way as dynamic routing.  

UNICAST ROUTING PROTOCOLS 

Endura has the option to utilize unicast or multicast transmission for video and audio recording. In addition, unicast 
transmission can be stipulated for networks that cannot support multicast traffic and have tight limits on the number of 
operators that can view the same video simultaneously. When using unicast for both recording and live view, ensure that the 
system does not exceed the number of simultaneous unicast streams that a given camera or encoder can support.  Keep in 

C1640M-C (8/08) 19
 mind that the NSM5200 storage pool will utilize two unicast streams for load balancing.  One of the following interior gateway 
protocols (IGP) can be used for unicast routing: 

Routing Information Protocol (RIPv2):   RIPv2 is a simple routing protocol that is part of the Transmission Control 
Protocol/Internet Protocol (TCP/IP) suites. It determines a route based on the smallest hop count between source and 
destination. Though mostly obsolete by newer, more flexible routing protocols, RIP is still found on some networks. RIPv2 
replaced the more restrictive RIPv1 and supports variable length subnet masking (VLSM) for more efficient subnetting, 
authentication for security, and multicast routing updates instead of broadcasting them to all hosts on the network. It also has a 
limit of 15 hops. If a route is advertised as having 16 hops, it is flagged as unreachable. One limitation of RIP is the need to 
replicate the entire routing table to active neighbor periodically. This period update occurs via broadcast or multicast, and can 
cause additional load to be placed on network resources.  

Open Shortest Path First (OSPF):  OSPF is a routing protocol that determines the best path for routing IP traffic over a TCP/IP 
network based on distance between nodes and several quality parameters. OSPF is a link state protocol that provides less 
router‐to‐router update traffic than the RIP protocol (distance vector protocol) that it was designed to replace. OSPF has 
several key advantages. First, OSPF only propagates that changes that have occurred to the routing table to its neighboring 
routers. By not forwarding the entire table, the utilization of network resources by the routing protocol is diminished 
significantly. Second, OSPF only replicated the changes to the routing table when an actual link state has changed. By utilizing 
event triggered LSA updates, periodic updates to the routing table can be avoided lowering network utilization for routing 
protocol overhead.  

MULTICAST ROUTING PROTOCOLS 

In a Layer 3 Endura network, multicast routing is used for critical intra‐system communications such as device discovery and 
health check. It is also the preferred approach for transmitting digital video to view stations because multicast transmission 
uses network bandwidth more efficiently. If one or more subnets or VLANs exist, one of the following protocols can be used to 
meet this requirement. 

Protocol Independent Multicast (PIM): PIM is a multicast routing protocol that is used in conjunction with an existing unicast 
routing protocol. PIM comes in two versions: Dense Mode (PIM‐DM) and Sparse Mode (PIM‐SM).   A detailed discussion of PIM 
is presented in Appendix A.   
• Sparse Mode (recommended) is most useful in the following instances:  
– There are few receivers in a group. Switches send multicast traffic only to the devices that request it. 
– The flood and prune cycle depletes PIM routing devices resource significantly.  
– You want to utilize multiple Rendezvous Point to segment the multicast routing traffic load. 
– The flood and prune cycle saturates network links.  
– You want to isolate multicast routing table entries to a segment of the network.  

PIM‐SM is optimized for environments where there are many multipoint data streams. Each data stream is sent to a 
relatively small number of the LANs in the internetwork. PIM‐SM works by defining a rendezvous point. When a sender 
wants to send data, it first sends to the rendezvous point. When a receiver wants to receive data, it registers with the 
rendezvous point. Once the data stream begins to flow from sender to rendezvous point to receiver, the routers in the 
path will optimize the path automatically to remove any unnecessary hops. PIM‐SM assumes that no hosts want the 
multicast traffic unless they specifically ask for it.  

• Dense Mode is most useful in the following instances:  
– All PIM routing switches have the resources available to handle flooded entries in the MRT.  
– There are a few senders and many receivers diversely spread throughout the network topology.  
– The multicast traffic volume is high. Dense Mode forwards multicast data everywhere and lets switches prune out 
traffic that is not requested. (PIM routers maintain a state in the MRT even after traffic is pruned.) 
– Multicast data is periodically flooded everywhere. 
– Note: State refresh on switches will suppress periodic flooding. 
– The multicast traffic stream is constant.   

PIM‐DM uses reverse path forwarding and looks a lot like Distance Vector Multicast Routing Protocol (DVMRP). The most 
significant difference between DVMRP and PIM‐DM is that PIM‐DM utilizes the existing routing table to build it multicast 
routes where DVMRP buildings it own routing table independent of the unicast routing table. By building its own routing 

20 C1640M-C (8/08)
 table additional switch resources are depleted. Both PIM and DVMRP work with either RIP or OSPF, neither requires a 
particular unicast routing protocol for operation. 

Some implementations of PIM simultaneously support Dense Mode for some multipoint groups and Sparse Mode for 
others. 

DVMRP: DVMRP is a routing protocol that supports multicast. Stemming from RIP and used in the Internet's Mbone (multicast 
backbone), DVMRP allows for tunneling multicast messages within unicast packets. It also supports rate limiting and 
distribution control based on ‐destination address, and it is responsible for the following tasks: 
• Routes multicast datagrams 
• Periodically floods multicast traffic (similar to PIM‐DM) 
• Allows use of nonmulticast aware edge devices 

NOTE:  Care should be taken when choosing PIM‐DM or DVMRP as a multicast routing protocol. On Endura systems that include 
wireless devices or require remote access to the system, these protocols have bandwidth limitations that are affected 
negatively by periodic flooding of data streams. 

C1640M-C (8/08) 21
Example Topology 

Example 1: Layer 2 Flat Network 

22 C1640M-C (8/08)
 Example 2: A Layer 3 network with multicast routing, backwards compatibility with Endura 1.x and VLANs 

C1640M-C (8/08) 23
ENDURA PRODUCT SUPPORT 

Pelco provides 24‐hour, seven‐day‐a‐week technical support to assist customers experiencing issues with Pelco equipment; 
contact Pelco Product Support at (800) 289‐9100 or +1 (559) 292‐1981. 

In addition, Pelco provides professional services including switch programming and system commissioning.  Please contact your 
sales representative for assistance with Pelco Professional Services.   

24 C1640M-C (8/08)
Appendix A 

PIM DENSE MODE FOR MULTICAST ROUTING 

Protocol Independent Multicast routing operates in either spare‐mode, dense‐mode or sparse‐dense mode.  Prior to the 
selection of a PIM operating mode, the system architect or network engineer needs to consider the impact the protocol 
selection will have on the network. This section of the Endura Network Design Guide is intended to give a brief overview of PIM 
Dense‐Mode and identify considerations a network engineer should address prior to using PIM Dense Mode.  

PIM DENSE MODE OVERVIEW 

Configuration of PIM‐DM by far is the easiest from an installation stand point. The network engineer will enable PIM‐DM on 
each router on the network that is required to route multicast traffic. PIM‐DM operates in what is referred to as a push model. 
Traffic is initially flooded to all neighbors that have formed a PIM neighbor relationship. Downstream routers will then 
determine if the traffic is necessary and either forward the traffic appropriately or send a prune message to it upstream router 
to suppress the flow of multicast traffic. Keep in mind that even though the traffic has been suppressed, the (S,G) state is still 
maintained in the multicast routing table (MRT). One of the major drawbacks to PIM‐DM is that multicast routing switches that 
are not actively transmitting a multicast flow, may still be required to maintain that state. This can lead to additional resources 
on the switch being consumed even though no active client of that router has requested the multicast traffic. During the flood 
and prune cycle (S,G) states are flooded to every multicast router on the network and every multicast router will maintain the 
(S,G) state as long as the multicast source is actively transmitting. The resulting traffic flow for multicast will follow the Shortest 
Path Tree (SPT) from source to receiver.  

CONSIDERATIONS WHEN USING PIM‐DM 

• Since PIM‐DM will flood traffic throughout the network in order to build (S,G) states in each downstream multicast 
router, careful consideration must be given to the support of state refresh. Multicast routing devices that support 
state refresh will prevent periodic flooding. PIM‐DM operates in a flood and prune cycle, the multicast routing tree is 
flooded every three minutes and relies on pruning mechanisms to determine if downstream routers require the 
multicast traffic or not. Periodic flooding of the network can be a major concern for network where bandwidth is 
limited. Layer 3 devices that support state refresh prevent the countdown timer on the (S,G) entry from expiring. If 
the countdown timer never expires, the multicast source will no longer flood the network periodically after the fist 
initial flood cycle. Network engineers should determine if their Layer 3 routing devices support state refresh. 

• There is a finite limit for each switch with respects to the number of multicast routing table entries the switch can 
handle. If the available Multicast Routing Table entries are exhausted, further entries may fail to be allocated to the 
table resulting in a multicast group that can no longer be routed. As a network engineer you need to ensure that the 
switch that is being utilized is not exceeding its capacity for the Multicast Routing Tables. Pelco has a list of 
recommended switches that have been tested with respects to its MRT capacity. If an integrator chooses to select a 
switch that is not from the recommended switch list, it is up to the integrators or network engineer to contact the 
switch manufacturer to assess the capabilities of the switch and any limitations with respects to multicast routing 
table entries.  

• In addition to the Multicast Routing Table, a selected switch must be able to handle an adequate number of IGMP 
entries as well. Switch manufactures specify the number of IGMP entries a switch can handle, when switches exceed 
these limits they typically will either flood or block multicast traffic. Pelco has a list of recommended switches that 
have been tested with respects to maximum recommended IGMP entries. If an integrator or network engineer selects 
a switch that is not from the recommended switch list, it is up to the integrator or network engineer to contact the 
vendor to determine the IGMP limitations of the switch selected.  

C1640M-C (8/08) 25
 • Due to the limited bandwidth associated with wireless connections, PIM‐DM may not be an appropriate selection. 
The flood and prune cycle may result in a wireless network link that becomes saturated.  

PIM SPARSE MODE OVERVIEW 

While PIM Sparse Mode requires careful consideration during the design process, there are major benefits associated with 
utilizing PIM‐SM as opposed to PIM‐DM. Unlike PIM‐DM, PIM‐SM has a dedicated (RP) Rendezvous Point to send messages to 
build both the shared (*,G) and source (S,G) sides of the tree. The end result is that PIM‐SM will not perform flood and prune 
cycles to build trees for forwarding multicast traffic. When the multicast traffic is not flooded to all PIM enabled devices, 
devices not in the path of transmission will not maintain entries in the multicast routing table. This will result in lower utilization 
of switch resources that are not in the Shortest Path Tree (SPT). 

CONSIDERATIONS WHEN USING PIM‐SM 

Overall, this section jumps right in to PIM‐SM concepts…might need to transistion better… 

• Due to the operation of PIM‐SM, placement of the (RP) Rendezvous point can be a critical decision in Endura Network 
Design. If a centralized Rendezvous Point is selected for all traffic in the Endura network, that switch must be able to 
handle the appropriate number of MRT entries for all traffic traversing the Endura network. An  alternative method would 
be to utilize multiple rendezvous points that serve as candidates for multicast routing. Filtering can be implemented to 
distribute the multicast routing load across multiple Rendezvous Points. This type of application can allow you to distribute 
the multicast routing load across multiple PIM‐SM routers, and if designed properly allow multicast traffic to be isolated to 
intended segments of a network. For example, if a multicast recording network storage pool is implemented and the 
Rendezvous Point also serves as the local (DR) Designated Router, Multicast recorded traffic would use its local (DR) as the 
Rendezvous point and isolate the majority of the multicast flows to the local router. Since the Shortest Path Tree is local to 
the switch multicast recording traffic would stay contained within a segment of the network.  

•  In an implementation utilizing PIM‐SM only the initial video packets will be sent to the Rendezvous Point. If  a single 
Rendezvous Point is used in and Endura network, after the encapsulated video in the register message is sent, all 
remaining video packets will use the (SPT) Shortest Path Tree from source to destination.  

• SPT‐Threshold configuration can be configured to force a multicast flow not to use the Shortest Path Tree. Care should be 
taken if SPT‐Thresholds are to be modified.  

• If a single RP is utilized in PIM‐SM it is critical that the multicast routing switch have enough resources to handle all (*,G) 
and (S,G) entries that will be created in the multicast routing table. Even thought the traffic is traversing the Shortest Path 
Tree, resources must be allocated to handle all existing MRT entries, and any processing of joins and prunes throughout 
the network. Packet replication, RPF recalculation, State maintenance, and Register processing all place create memory 
and CPU loads on the Rendezvous Point. Depending on the size of the Endura network and scalability requirements, 
different Layer 3 devices might be selected as RP based on their resources.  

• Keep in mind that the default response of PIM‐SM ( This is Cisco, and only if pim sparse‐dense‐mode is enabled, may not 
apply to HP) is to fallback to PIM‐DM in the event that an RP cannot be found. Based upon the network topology this may 
or may not be a desired effect. Always take into account the effect reverting to PIM‐DM may have on the network.  

 
 

26 C1640M-C (8/08)