Endura Network Design Guide 2 - Pelco

C1640M-C (8/08) 1

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.

2 C1640M-C (8/08)

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.

C1640M-C (8/08) 3

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 Solutions

Pelco offers a wide range of IP cameras covering various form factors and including positioning systems. 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 Interface

The WS5200‐MAP interface provides an efficient way to visualize an entire area. A full map editing utility is 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.

4 C1640M-C (8/08)

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.

C1640M-C (8/08) 5

6 C1640M-C (8/08)

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.

C1640M-C (8/08) 7

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.

8 C1640M-C (8/08)

• 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.

C1640M-C (8/08) 9

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:


22/tcp SSH

161/udp SNMP

27235/tcp VPN

60000/tcp System Manager

NET5402R-HD:

10 C1640M-C (8/08)


22/tcp ssh

68/udp dhcp client

123/udp ntp


1900,2900-2901/udp UPnP discovery

4242/tcp HAL

4343/tcp HAL

49152/tcp UPnP communication

31000/udp DecoderApp

31001/udp DecoderApp

NET5301T:


22/tcp ssh

68/udp dhcp client

123/udp ntp



20xxx/udp UPNP Communication

49152/tcp UPNP Communication

NET5301T-I:


21/tcp ftp

22/tcp ssh

23/tcp telnet

68/udp dhcp client

123/udp ntp



4242/tcp HAL

4343/tcp HAL

20xxx/udp UPNP Communication

30001/udp UPNP Communication


NSM5200:

C1640M-C (8/08) 11


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


49152/tcp UPNP Communication

Sarix IP Cameras:


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


5353/udp MDNS

6700-6900/udp RTCP

12 C1640M-C (8/08)

VCD5202:


22/tcp ssh

68/udp dhcp client

123/udp ntp

161/udp snmp


4343/tcp HAL

6000/tcp X11



WS5270:


135/tcp msrpc

139/tcp netbios-ssn

445/tcp microsoft-ds


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.

C1640M-C (8/08) 13

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


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

14 C1640M-C (8/08)

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)


1080p @ 15 FPS 1920 1080 15 3350 7 High (IP)


720p@30 FPS 1280 720 30 3700 15 High (IP)


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)


640x352 @ 30 FPS 640 352 30 1200 15 Baseline


SXVGA @ 15 FPS 1280 960 15 3000 7 High (IP)


SVGA @ 30 FPS 800 608 30 2000 15 Baseline


VGA @ 30 FPS 640 480 30 1600 15 Baseline


IX30


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

C1640M-C (8/08) 15

Standard Resolution MPEG4 IP Cameras and Encoders:

IP110/IP3701/Spectra IV IP/Spectra-Mini IP/NET5301T/NET5308T/ENC53xx (NTSC/PAL)


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

16 C1640M-C (8/08)

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.

C1640M-C (8/08) 17

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

1x1 ALL H.264 2048X1536 30fps

2x2 ALL H.264 2048X1536 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

1+5 1 Large H.264 2048X1536 15fps

5 Small H.264 800x608 15fps

1+12 1 Large H.264 2048X1536 15fps

12 Small H.264 800x608 15fps

2+8 2 Large H.264 2048X1536 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.

18 C1640M-C (8/08)

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.

C1640M-C (8/08) 19

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

20 C1640M-C (8/08)

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

C1640M-C (8/08) 21

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.

22 C1640M-C (8/08)

Example Topology

Example 1: Layer 2 Flat Network

C1640M-C (8/08) 23

Example 2: A Layer 3 network with multicast routing, backwards compatibility with Endura 1.x and VLANs

24 C1640M-C (8/08)

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.

C1640M-C (8/08) 25

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.

26 C1640M-C (8/08)

• 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.

Endura Network Design Guide 2 - Pelco

Documents

Transcript of Endura Network Design Guide 2 - Pelco