Video services
Video services
Video groups
Video services are supported on:
MS-ISA
MS-ISA2
MS-ISM (two MS-ISA2 on a single line card)
ESA
These MS-ISA and ESA variants are referred to as ISAs in this section.
Both MS-ISA and MS-ISA2 support FCC/RET, VQM, and perfect stream functionality. The ESA supports only FCC/RET.
When configured in the router, ISAs are logically grouped into video groups for video services. A video group allows multiple ISAs/ESAs for an application. The system performs load balancing between the ISAs. Mixing ISA, ISA2, and ESA in the same video group is not recommended. All ISAs within a video group are always active, there are no standby ISAs.
Video groups provide a redundancy mechanism to guard against hardware failure within a group where the system automatically re-balances tasks to the group excluding the failed MS-ISA or ESA-VM. Video groups also pool the processing capacity of all the group members and increases the application throughput because of the increased packet processing capability of the group. The buffer usage is typically identical for all members of the video group, so increasing the number of members in a group does not increase the scaling numbers for parameters bounded by available buffering, but there is still the increase in performance gained from the pooled packet processor capacity. A video service must be enabled at the video group level before that service can be used.
A video application may restrict the number of ISAs supported in a video group to a smaller number. Please contact your local Nokia representative for more information about video application specifications.
Video SAP
The video group logically interfaces to a service instance with a video Service Access Point (SAP). Like a SAP for connectivity services, the video SAP allows the assignment of an ingress and egress filter policy and QoS policy.
Ingress and egress directions for the filter and QoS policy are named based on the perspective of the router which is the opposite perspective of the ISA. An ‟egress” policy is one that applies to traffic egressing the router and ingressing the ISA. An ‟ingress” policy is one that applies to traffic ingressing the router and egressing the video. Although potentially confusing, the labeling of ingress and egress for the ISA policies was chosen so that existing policies for connectivity services can be reused on the ISA unchanged.
If no filter or QoS policy is configured, the default policies are used.
One of the key attributes of a video SAP is a video group association. The video SAP’s video group assignment is what determines which video group services on that video SAP. The video groups configuration determines what video services are available.
Video interface
A video interface is a logical IP interface associated with a video SAP and provides the IP addressing for a video SAP.
A video interface can have up to 16 IP addresses assigned in a VPRN service instance.
Video interface properties
The video application is supported on various platforms but the video interface has different characteristics on the following platforms:
-
7750 SR-7, 7750 SR-12, 7750 SR-12e
For 7750 SR-7, 7750 SR-12, 7750 SR-12e, the video interface is a logical interface regardless of whether ISA or ESA is used. For these platforms, the video interface uses direct protocol as the routing policy to export to IGP or BGP protocols. Use the following command to configure the routing policy for a video interface as direct protocol:
-
MD-CLI
configure policy-options policy-statement entry from protocol name direct
-
classic CLI
configure router policy-options policy-statement entry from protocol direct
-
-
7750 SR-1, 7750 SR-1s, 7750 SR-2ss, 7750 SR-7s
For 7750 SR-1, 7750 SR-1s, 7750 SR-2ss, 7750 SR-7s, the video interface is modeled as a route. Only ESA is supported on these platforms. For these platforms, the video interface uses video protocol as the routing policy to export to IGP or BGP protocols. Use the following command to configure the routing policy for a video interface as video protocol:
-
MD-CLI
configure policy-options policy-statement entry from protocol name video
-
classic CLI
configure router policy-options policy-statement from protocol video
-
Multicast information policies
Multicast information policies on the 7750 SR and 7450 ESS serve multiple purposes. In the context of a service with video services, the multicast information policy assigned to the service provides configuration information for the multicast channels and defines video policy elements for a video interface.
This section describes the base elements of a multicast information policy in support of a video service. Specific video service features require additional configuration in the multicast information policy which are described in the sections dedicated to the video feature.
Multicast information policies are named hierarchically structured policies composed of channel bundles which contain channels which contain source-overrides.
Bundles are assigned a name and contain a collection of channels. Attributes not defined for a named bundle are inherited from the special default bundle named ‟default”.
*A:ALA-48configmcast-mgmtmcast-info-plcy# info ---------------------------------------------- bundle "default" create exit ---------------------------------------------- *A:ALA-48configmcast-mgmtmcast-info-plcy#
-
Channels are ranges of IP multicast address identified by a start IP multicast address (GGstart) and optional end IP multicast address (Gend), so the channels encompasses (*,Gstart) through (*,Gend). A channel attribute is inherited from its bundle unless the attribute is explicitly assigned in which case the channel attribute takes precedence.
-
A source-override within a channel are IP multicast addresses within the channel with a specific source IP address (Soverride), so the source-override encompass (Soverride,Gstart) through (Soverride,Gend). A source-override attribute is inherited from its channel unless the attribute is explicitly assigned in the source-override channel in which case the source-override channel attribute takes precedence.
For a IP multicast channel (*,G) or (S,G), the most specific policy element in the hierarchy that matches applies to that channel.
A multicast information policy is assigned to a service instance. For video services, the multicast information policy assigned to the service determines the video group for a given IP multicast channel. When a channel is assigned to a video group, the channel is sent to the video group for buffering or processing as appropriate depending on the video services enabled on the video group. If no video group is assigned to a channel, the channel is still distributed within the service instance, but no video services are available for that channel.
In addition to bundles, channels and source-overrides, multicast information policies also include video policies. Video policies define attributes for the video interfaces within the service instance.
Video policy attributes are specific to the video feature and are covered in detail in the applicable video feature section. Video policies are mentioned here because they are an element of the multicast information policy and provide the link to configuration for a video interface.
Perfect stream protection
To protect against network interruption or reconvergence, it is often more efficient to protect the stream using an alternate transmission path. This can be a separate physical interface, transmission link, system, or even technology.
Perfect stream is also known as duplicate stream in some markets. Perfect stream protection allows an operator to split a single multicast stream (single S,G and common SSRC) into two different transmission paths that may have different transmission characteristics, such as latency or jitter. Instead of selecting one stream for retransmission to the client, the perfect stream protection feature evaluates each stream packet-by-packet, selecting the first, valid packet for retransmission.
A circular buffer is used for perfect stream protection which incorporates both packet-by-packet selection (based on RTP sequence number/timestamp and SSRC) and a re-ordering function whereby any out-of-sequence packets are placed into the buffer in order, therefore creating a corrected, in-order stream.
Playout rate is a function in ingest rate, however because the two streams may be delayed between one-another a few assumptions are made:
The first arriving packet is always put into the buffer, allowing for the backup medium to wander in terms of latency and jitter.
Because the source is the same, the rate at which a packet is put into the buffer (from either stream) can be assumed to be the normal bitrate.
The output RTP stream is always maintained in-sequence and the playout speed is always controlled. A moving window calculated against the time stamp smooths jitter that may occur between packets or the two contributing streams. The playout stream is described in Perfect stream selection.
Perfect stream selection
This section describes perfect stream protection and provides details about packet selection on playout.
Stream identification
Stream selection is a simple selection algorithm that is applicable to any number of input streams. It is a prerequisite for stream selection that RTPv2 encapsulation be used in UDP.
Each service is identified by multicast source, group/destination address and current synchronization source (SSRC). After the service has been identified, the ISA monitors its ingress for:
traffic with a DA of the multicast group
traffic with a DA of the ISA (unicast)
Traffic is further checked as having RTP-in-UDP payload, RTP version 2.
The SSRC of each incoming RTP packet is learned as a unique source. Only one SSRC is supported for each stream; as SSRC may change during abnormal situations (such as encoder failover), it can be updated.
An SSRC can only be updated when a Loss of Transport (LoT) occurs, as other perfect streams (with the original SSRC) may still be operational. When an LoT occurs, the SSRC is deleted, the buffers are purged, and the RTP sequence counters are reset. The SSRC is extracted from the next valid RTP packet and the sequence starts over.
One RTP packet from the perfect stream is selected for insertion into the video ISA buffer. After a packet is selected, the RTP sequence counter is incremented and any further RTP packets received by the ISA with the previous sequence number are discarded.
In summary, perfect stream selection is a FIFO algorithm for RTP packet selection; this is considered optimal because:
All stream sources are identical. Therefore, for any sequence number, the payload should also be identical.
Most bit errors should be detected by the CRC-32 algorithm applied to Ethernet, SDH, and so on.
These devices typically discard frames where bit errors occur, with the net result being that the video ISA receives a bit error-free stream (though packet loss can occur).
The UDP checksum is verified by the video ISA (after input VQM) and any failures result in a silent discard of the packet.
VQM can be used in conjunction with perfect stream protection.
VQM can be used to monitor the quality of two duplicate ingress multicast streams and the egress multicast stream (after perfect stream selection). This is particularly useful to compare between the ingress and egress multicast. Monitoring the egress multicast after perfect stream selection can provide an insight to the customer viewing experience.
Initial sequence identification
When a service is defined and is enabled (no shutdown), the video ISA monitors for valid RTP packets and on first receipt of a valid RTP packet learn the following information:
SSRC
sequence number
timestamp (as timestamp is profile-specific, MPEG2-TS are assumed)
The packet is inserted into the video ISA playout buffer associated with that particular service and playout when directed (playout algorithm).
Packet selection
Each valid RTP packet received for a specific service is inserted into the buffer if there is no existing RTP packet that matches the sequence number. When sequence numbers and timestamps discontinue, the video ISA makes a limited attempt to validate the MPEG stream. The video ISA code adopts a philosophy to ensure that sequence numbers and timestamps increment correctly. If packets are non-contiguous, the packet selection algorithm adapts.
Duplicate packets are detected by sequence number or timestamp, unless M-bit resets the timestamp. A packet that is already in the buffer and which has the same sequence number as a received packet (or one recently played out) is discarded. The system monitors the incoming sequence number on each RTP packet. If a packet takes more than 1.5 seconds, it is considered late and is discarded.
In a multiprogram transport stream (MPTS), the timestamp is uniquely set for every RTP packet, as any RTP packet many contain a number of multiplexed elementary streams. As a result, playout is based on the embedded timestamp in each RTP packet. In a single-program transport stream the inverse occurs. Many RTP packets can share the same timestamp as it is referenced from the start of a picture (and a picture can span many RTP packets). As an SPTS does not contain audio, its application is limited to content production and so only MPTS are supported.
Timestamp discontinuities do occur and are normally represented with the Marker bit (M) being set.
Playout time is determined by an internal playout timestamp. The playout timestamp is set independently from the actual timestamp in the packet. The recovered clock can compute the expected timestamp for the very next incoming RTP packet.
When a packet is received, it is first compared to existing packets in the buffer based on sequence number (assuming that a stream may be delayed for hundreds of milliseconds by a backup path yet still be valid); jitter tolerance is only evaluated if this packet is determined to be a new RTP packet eligible for buffer insertion. If jitter tolerance is exceeded, then a timestamp discontinuity is assumed and instead of setting the playout timestamp based on the contained RTP timestamp, the actual received time (offset by playout-buffer) is set for the RTP packet playout timestamp.
In normal operation, the clock is recovered from the timestamp field in the RTP header, is offset by the playout buffer configuration parameter, and is used to schedule playout of the packet. The playout clock is synchronized with the sender by using an adaptive clock recovery algorithm to correct for wander.
Algorithm summary
For a service marked LoT, if a loss of transport occurred, purge the buffer and reset all counters/timers.
If the service is UP, check the RTP packet sequence number. Compare to sequence numbers contained in the buffer. If no match then check last played sequence number. If the sequence number of this packet is between last played and last played + 4096 then consider this packet late and discard.
Check the expected timestamp recovered clock value and compare to RTP timestamp. If the expected timestamp is (-ve)jitter tolerance<timestamp<(+ve)jitter tolerance then the packet is admitted to the buffer with a playout timestamp per the embedded RTP timestamp. If jitter tolerance is not maintained this marks a discontinuity event. Set playout timestamp to current clock + playout buffer and enqueue.
Clock recovery
RFC 2250, RTP Payload Format for MPEG1/MPEG2 Video, defines the timestamp format for MPEG2 video streams (which may carry H.264 video): a 90kHz clock referenced to the PCR. Each ingest RTP packet has it’s timestamp inspected and it is used in an adaptive clock recovery algorithm. Importantly, these adjustments occur on ingress (not on playout). This serves as a long-term, stable, ingress stream recovered clock.
The 90kHz ingress stream recovered clock is adjusted for each service to account for the encoder’s reference clock/difference between the clock in the 7750 SR. This input timestamp is derived from the same RTP packet that is inserted into the buffer, and therefore may be subjected to significant jitter. The clock adjustment algorithm must only adjust clock in extremely small increments (in the order of microseconds) over a very long sample period (not bitrate) of at least 30 minutes.
Playout
Playout is the process of regenerating the stream based on the playout timestamp.
The playout is an exact offset to the ingress stream-recovered clock and serves as playout time for the video ISA. Because the timestamp is used for buffer playout, CBR, capped VBR, and VBR streams are all supported without pre-configuration. The playout buffer mechanism effectively removes network-induced jitter and restores the output to the rate of the original encoder.
Loss of transport
In the circumstance that the playout buffer is emptied an LoT is indicated. The video ISA resets playout timestamp, clock, sequence number, and so on for this event and awaits the next valid RTP packet for this service.
Perfect stream in relation to FCC/RET
Perfect stream can enhance the end user experience by removing network induced faults to the multicast stream. The egress of the perfect stream can be fed back into a separate ISA for the FCC/RET application. This ensures that the end user gets the best IPTV viewing experience from the start of a channel change. The perfect stream can be sent to the FCC/RET ISA by using extranet where FCC/RET resides on a separate VPRN instance.
Perfect stream in relation to VQM
Perfect stream uses two identical multicast streams traversing two diverse network paths to construct a multicast stream that is less susceptible to network faults. VQM can be configured in conjunction with perfect stream, which allows VQM to monitor the two ingress as well as the egress streams. By using the VQM statistics from all three streams, the operator can assess the quality of the network transporting the multicast stream, the performance of perfect stream, and the viewing quality for the end user. VQM and Perfect Stream can be enabled on the same video-group (the same ISA).
Video quality monitoring
The following terminology is used in this section:
TNC is an acronym for Technically Non-Conformant.
QoS is an acronym for Quality of Service.
POA is an acronym for Program Off Air.
TNC event (also known as impaired event) refers to a trap/alarm that detects an impairment event and is therefore termed TNC.
An impaired event is said to have occurred if:
A PAT/PMT syntax error occurs in that second.
Continuity counter errors were detected.
PAT /PMT/PCR PIDs were not present in the video stream for a time period equal to or greater than the configured TNC value in the respective alarm.
The default value of the impaired threshold in terms of milliseconds is:
PAT (100 ms)
PCR (100 ms)
PMT (400 ms)
An unreferenced PID is seen in the video stream which has not been referred in the PMT.
TNC seconds (also known as impaired seconds) refer to the number of seconds elapsed before an impaired event was detected and a TNC SNMP trap was sent. Although multiple TNC events may have occurred within a second, counters in the show>video>channel>analyzer command only increment once per second.
QoS event (also known as degraded event) refers to a trap/alarm that detects a degraded event and is therefore termed QoS. A QoS event is said to have occurred if PAT/PMT/PCR PIDs are absent in the video stream for a time period equal to or greater than the configured QoS value in their respective alarms.
The default value of the degraded threshold in terms of milliseconds is:
-
PAT (200 ms)
-
PCR (200 ms)
-
PMT (800 ms)
-
QoS seconds (also known as degraded seconds) refer to the number of seconds elapsed before a degraded event was detected and a QoS SNMP trap was sent. Although multiple QoS events may have occurred within a second, counters in the show>video>channel>analyzer command only increment once per second.
POA event (also known as error event) refers to a trap/alarm that detects an error event and is therefore termed POA.
A POA event has occurred if:
-
A synchronization loss error has occurred for that particular second. A synchronization loss is said to have occurred if more than 1 consecutive synchronization byte error is seen in the stream.
-
PAT/PMT/PCR PIDs are absent from the video stream for a time period equal to or greater than the configured POA value.
The default value of the degraded threshold in terms of milliseconds is:
-
PAT (500 ms)
-
PCR (500 ms)
-
PMT (2000 ms)
-
-
Traffic loss has occurred for that particular second.
-
A transport error indicator or TEI indicator is set in the transport stream packet header for that particular second in the video stream.
-
POA seconds (also known as error seconds) refer to the number of seconds elapsed before an errored event was detected and a POA SNMP trap was sent. Although multiple POA events may have occurred within a second, counters in the show>video>channel>analyzer command only increment once per second.
Good seconds refer to the number of seconds where there are no impaired, degraded, or error events.
PID stats are described in PID stats — description of fields
Field | Description |
---|---|
PID |
Displays the value of the PID. |
Is PCR PID |
Can be set to Yes or No. If set to Yes, then it indicates that the PID is the PCR PID. |
TEI Err Sec |
Counts the number of seconds TEI was set for that particular PID. |
Absent Err Secs |
The number of seconds for which the PID was not seen for a particular interval of time which is decided by the alarms set for the Non-Vid PID Absent and Video PID Absent. |
PID bitrate |
Calculated by counting the number of times the PID occurred in the last second x 188 x 8.
|
CC Err Secs |
Number of seconds Continuity Counter errors were seen for that particular PID in the stream. |
PID Type |
Specifies that the PID is either video, audio, PAT, PMT, or PCR. |
MPEG Stream Type |
If the PID is video or audio, this field indicates how the video or
audio is encoded. For example:
|
To address interval statistics, except for the PID statistics all other statistics described above have interval statistics. Information can be obtained about stream status for the last 1 minute, 5 minute, and 15 minute interval.
MDI - Media Delivery Index (RFC 4445, A Proposed Media Delivery Index (MDI))
Delay Factor (RFC 4445)
The delay factor is a value which indicates the minimum amount of time a STB buffers to resolve network jitter (that is, it is the minimum STB buffer depth in ms). RTP timestamp is used as the definitive time indicator (the notional drain rate).
Loss Rate (RFC 4445)
The Media Loss Rate is the number of media (Transport Stream) packets lost over a specific time interval. This is reported in TS/sec. Each RTP packet lost is assumed to have 7 TS packets lost.
In many instances IPTV operators are unable to identify the cause of visual impairments which are present in almost every video distribution network because the IPTV network has so many moving parts While head end transport-stream monitoring; full reference video analysis (comparing the source content to the encoded output), and; STB probes allow an operator to establish whether the contribution source, the encoder, or the network is the problem the network is a very complex thing.
Operators can use another measurement point in the network, just before the last mile such that network faults can be characterized as being between the head end and last mile (transport) or in the last-mile itself.
The multicast video quality monitoring solution provides an inspection point for the multicast video stream that is combined with other analysis methods to create a full view of video issues and help troubleshoot the part of the network causing the issue.
Video quality monitoring is one part of a video assurance program and is combined with:
TS analysis on the encoder output (to detect encoder errors)
Full-reference PSNR and PQR on the encoder output (to detect over-encoding, noise and other contribution or encoding artifacts)
STB reporting (such as packet-loss, RET events, packet errors) from the entire STB population
STB probes performing full-reference monitoring (against test streams)
STB probes performing channel-change times, estimated PSNR, and so on
Multicast video monitoring within the network can be positioned as complementary to STB reporting and head end analysis, and but should not attempt to perform either of these functions. Because the network node is not capable of decrypting a MPEG transport stream is primarily used to identify correctable and uncorrectable network errors, correlate them with network events (such as routing re-convergence, interface failure, and so on) and provide summary reports and alarms.
For operators who do not have existing STB probes or reporting, a network-based VQM solution can provide insight into quality issues the network may be contributing to, possibly reducing the amount of STB probe investment that is needed. (that is, both probes and the 7750 SR VQM reports many of the same issues in terms of picture quality, fewer probes are needed to test channel change delay, and so on).
The metrics which VQM can report are based on the use of RTP streams which provide per-packet sequencing and an indication of picture type. These two parameters along with measured bitrate allow VQM to produce estimated MOSv scores for both stream ingress (uncorrected) and stream egress (corrected) outputs.
Reportable metrics include:
Relevant SCTE-143 error counters
PAT
PMT
PCR
transport errors, and so on
ETSI TR 101 290
PID
SI repetition
degraded blocks/intervals, and so on
MDI (RFC 4445)
forwarded and impaired I-/B-/P-frame counts
GOP length
video/audio/stream bitrate
These metrics are collected for each multicast group and have relevant parameters. Use the command show video channel analyzer address group-address detail to generate a numeric metrics summary report for a specific multicast group. Other information that is also captured by VQM but can only be expressed on a per-PID basis uses the command show video channel pid address group-address. The per-PID information captured by VQM includes:
- CC Err secs
- TEI Err secs
- Absent Err secs
The following is example output generated by the show video channel analyzer address group-address detail command:
*A:vmq-11# show video channel analyzer address 239.0.1.1 detail
===============================================================================
Video channel analyzer detail
===============================================================================
Channel number : 1
-------------------------------------------------------------------------------
Service Id : 31905555 Interface Name : vi-1
Group Address : 239.0.1.1 Source Address : 10.10.10.10
MDI Delay Factor : 4 MDI Loss Rate : 0
Good Secs : 0
===============================================================================
GOP Stats
===============================================================================
Min Max Avg
-------------------------------------------------------------------------------
GOP Length 10 31 24
Frames/Sec 21 28 25
===============================================================================
Frame Stats
===============================================================================
I-Frame P-Frame B-Frame
-------------------------------------------------------------------------------
Good 42 957 0
Bad 0 0 0
===============================================================================
Error Stats
===============================================================================
POA Events QoS Events TNC Events
-------------------------------------------------------------------------------
PAT Rep 0 1215 0
PMT Rep 0 0 0
PCR Rep 0 0 1
PAT Syntax Err - 0 -
PMT Syntax Err - 0 -
Sync Byte Err - 0 -
Sync Loss 0 - -
Unref PID - - 34600
Traffic Loss 0 - -
-------------------------------------------------------------------------------
Overall 30285 77 4238
-------------------------------------------------------------------------------
Reoccurring events only increment counter once every second
-------------------------------------------------------------------------------
Number of channels : 1
===============================================================================
*A:vmq-11# show video channel pid address 239.0.1.1
===============================================================================
Video Channel PID
===============================================================================
Service Id : 31905555 Interface Name : vi-1
Group Address : 239.0.1.1 Source Address : 10.10.10.10
PID : 0 PID Type : pat
MPEG Stream Type : 0 Is PCR PID : No
Cc Err Secs : 0 TEI Err Secs : 0
Absent Err Secs : 0 PID Bitrate : 0
Service Id : 31905555 Interface Name : vi-1
Group Address : 239.0.1.1 Source Address : 10.10.10.10
PID : 100 PID Type : pmt
MPEG Stream Type : 0 Is PCR PID : No
Cc Err Secs : 0 TEI Err Secs : 0
Absent Err Secs : 0 PID Bitrate : 0
Service Id : 31905555 Interface Name : vi-1
Group Address : 239.0.1.1 Source Address : 10.10.10.10
PID : 101 PID Type : video
MPEG Stream Type : 27 Is PCR PID : Yes
Cc Err Secs : 0 TEI Err Secs : 0
Absent Err Secs : 0 PID Bitrate : 5564800
Service Id : 31905555 Interface Name : vi-1
Group Address : 239.0.1.1 Source Address : 10.10.10.10
PID : 201 PID Type : audio
MPEG Stream Type : 3 Is PCR PID : No
Cc Err Secs : 0 TEI Err Secs : 0
Absent Err Secs : 0 PID Bitrate : 204544
Service Id : 31905555 Interface Name : vi-1
Group Address : 239.0.1.1 Source Address : 10.10.10.10
PID : 202 PID Type : audio
MPEG Stream Type : 3 Is PCR PID : No
Cc Err Secs : 0 TEI Err Secs : 0
Absent Err Secs : 0 PID Bitrate : 132352
Service Id : 31905555 Interface Name : vi-1
Group Address : 239.0.1.1 Source Address : 10.10.10.10
PID : 401 PID Type : other
MPEG Stream Type : 6 Is PCR PID : No
Cc Err Secs : 0 TEI Err Secs : 0
Absent Err Secs : 30310 PID Bitrate : 0
Number of pids for this channel: 6
-------------------------------------------------------------------------------
Number of channels : 1
===============================================================================
Event alarms are reported by log, syslog, or SNMP. The following is an example of a trap:
1 2017/02/11 18:11:20.42 UTC WARNING: VIDEO #2009 Base Video[1/video-300]
Service Id - 300, Video interface - video-300, Group address - 192.0.2.6, Source address - 10.20.13.2 Last 10 seconds of analyzer state is good good good good good good good good good poa
A trap is only raised when a POA, QoS, or TNC event occurs within the last 10 seconds. The trap captures events within the last 10 seconds. In the example above, the first nine seconds were ‟good”, which indicates that no events occurred and that every single RTP packet was received. At the 10-second mark, a POA event occurred, which triggered the SNMP trap. This sampling continues every 10 seconds. If an event (POA, QoS, or TNC) continues to be detected, an SNMP trap is raised every 10 seconds.
When the analyzer detects 10 seconds of a ‟good” condition, another trap is raised to clear the alarm for the multicast (S,G). Subsequent alarms are raised and SNMP traps are triggered only when the analyzer detects another event (POA, QoS, or TNC).
61 2016/10/18 15:40:56.83 UTC WARNING: VIDEO #2010 Base Video[1/video-300]
Analyzer state is cleared for - Service Id - 300, Video interface - video-300, Group address - 192.0.2.6, Source address - 10.20.13.2
VQM is an optional module available on the input side, or output side of the video ISA. On input, it is applied before perfect stream protection. Conversely when on the output side it is applied only to multicast streams after perfect stream protection.
Because of the large number of channels and the nature of measuring input and output sides, VQM is highly reliant on the use of RTP extensions to provide relevant transmission metrics to the VQM analysis module. In a typical head end, a multicast stream is scrambled to encrypt its video or audio. When this encryption occurs, it is typical for the entire payload of the transport stream (for the nominated PID) to be completely scrambled. The consequence of such is that the video and audio PES headers, which reveal much about the picture and timing information, are unavailable to the VQM program.
VQM uses intelligent RTP re-wrapping. RTP re-wrapping is a prerequisite for ad insertion and Fast Channel Change (FCC) and involves marking packets before encryption based on the picture type (most importantly, the start of the I frame of IDR frame in H.264.
The VSA as currently defined, re-multiplexes each transport stream into a new RTP packet. By doing so it allows the separation of different picture types into their own respective RTP packets, and the separation of audio packets from video packets to allow different synchronization in events of FCC. In effect, it pulls the elementary streams back into their component forms while retaining the syntax and structure of the MPTS.
For information about VSAs, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.
Meanwhile, additional information can be made available, before scrambling, of the picture information for quality analysis. The quality analysis performed by the VQM module emphasizes impairments caused by network issues and transport stream syntax given the relative proximity of the router to the customer.
When the video ISA is deployed alongside the ALU VSA re-wrapper, a custom RTP header extension is sent with each RTP packet. The RTP header is shown in RTP header.
Where:
B (Frame Begin Flag): set if a frame starts in this packet
E (Frame End Flag): set if a frame finishes in this packet
ST (Stream Type)
00 video
01 audio
10 data/padd/other
11 Reserved
S (Switch bit): set to 1 in all RTP packets from the moment
the client should do the IGMP join (rewrap does not fill it)
r: reserved (set to 1)
PRI: Packet Priority (coarse)
FPRI: Fine-grained priority
PRI FPRI dec DSCP
--- ---- --- ----
3 7 31 AF41 Video IDR frame
3 0 24 AF41 Audio
2 0 16 AF41 Reference frame (P in MPEG2, I or P or some Bs in AVC)
1 7 15 AF42 Non-reference frame (most Bs in MPEG2, some Bs in AVC)
1 5 13 AF42 Trans-GOP frames, undecodable in some circumstances (some Bs in MPEG2)
0 4 4 AF43 Rest of cases (data, secondary videos, etc)
0 1 1 AF43 Padding packets
where AF41=100010, AF42=100100, AF43=100110 (DSCP bits in the IP header)
VoIP/video/teleconferencing performance measurements
The feature provides ability to measure and provide statistics to allow reporting on voice and video quality for VoIP and teleconferencing (A/V) applications. A sampled deployment is shown in Voice/video monitoring deployment example . Although a distributed model is shown, a hub-and spoke model, with AA-ISA deployed only on one side of the traffic flow, is also supported.
Because of network-based AA, the operator has an ability to monitor voice, video, teleconferencing applications for an AA subscriber regardless of the type of that subscriber (a residential subscriber vs. a user of a business VPN service). AA-ISA monitors UDP/RTP/RTCP/SDP headers for each initiated call/application session (sampling may be provided – although, it is expected that a sampling rate is smaller than that of TCP-applications because of the nature of the voice/video applications – longer lasting and smaller number of sessions/calls per subscriber). AA ISA gathers statistics and computes MOS-scores/R-factor results per each call/ application session. At the end of a call (/application session closure), AA-ISA sends the statistics and computed scores to a Cflowd collector (the Cflowd infrastructure was introduced for TCP-performance but modified to carry voice/video specific data is used). The collector summarizes and presents the results to the operator/end user.
Mean Opinion Score (MOS) performance measurements solution architecture
AA-ISA integrates a third party MOS software stack to perform VoIP and video MOS measurements. This software provides:
call quality analysis using optimized ITU-T G.107
measurements of perceptual effects of burst packet loss and recency using ETSI TS 101 329-5 Annex E Extensions
measurements and analysis of RTCP XR (RFC3611) VoIP metrics payloads
AA software monitors the associated SDP channel and passes codec information (when available) to the subsystem which monitors VoIP. The video bearer channels traffic generates a wide variety of A/V performance metrics such as:
call quality metrics
listening and conversational quality MOS scores (MOS-LQ, MOS-CQ)
listening and conversational quality R-factors (R-LQ, R-CQ)
estimated PESQ scores (MOS-PQ)
separate R-factors for burst and gap conditions (R-Burst, R-Gap)
video MOS-V and audio MOS-A
video transmission quality (VSTQ)
video stream metrics
good and impaired I, B, P, SI, SP frame counts
automatic detection of GoP structure and other key video stream attributes such as image size, bit rate, codec type
transport (IP/RTP) metrics
packet loss rate, packet discard rate, burst/gap loss rates
packet delay variation/jitter
degradation factors (degradation because of loss, jitter, codec, delay, signal level, noise level, echo, recency)
When a flow terminates, AA software retrieves the flow MOS parameters from the subsystems, formats the info into a Cflowd record and forwards the record to a configured Cflowd collector (RAM).
RAM collects Cflowd records, summarizes these records using route of interest information (source/destinations). In addition, RAM provides the user with statistics (min/max/ avg values) for the different performance parameters that are summarized.
Retransmission and Fast Channel Change
RET and FCC overview
The following sections provide an overview of RET and FCC.
Retransmission
Retransmission (RET) for RTP (RFC 3550, RTP: A Transport Protocol for Real-Time Applications) is based on a client/server model where the client sends negative acknowledgments (NACKs) using Real-time Transport Control Protocol (RTCP) (RFC 4585, Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)) to a RET server when the client detects missing sequence numbers in the RTP stream. The RET server which caches the RTP stream, for example in a circular buffer, detects missing sequence numbers in the replies to the NACKs by resending the missing RTP packets as illustrated in RET server retransmission of a missing frame.
The format of the reply must be agreed upon by the RET client and server and can be an exact copy (Payload Type 33 as defined in RFC 3551, RTP Profile for Audio and Video Conferences with Minimal Control) or sent with a different Payload Type using an encapsulating RET header format (RFC 4588, RTP Retransmission Payload Format).
RET has been defined in standards organizations by the IETF in the above-noted RFCs and Digital Video Broadcasting (DVB) in ‟Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks (DVB-IPTV Phase 1.4)” which describes the STB standards.
STBs that have a port of the Nokia RET/FCC Client SDK are an example of a standards-compliant RET Client implementation.
FCC
FCC is an Nokia method based on a client/server model for providing fast channel changes on multicast IPTV networks distributed over RTP. During a fast channel change, the FCC client initiates a unicast FCC session with the FCC server where the FCC server caches the video stream and sends the channel stream to the FCC client starting at the beginning of a Group of Pictures (GOP). Beginning at a GOP in the past minimizes the visual channel transition on the client/STB, but the FCC unicast stream must be sent at an accelerated rate in the time domain to allow the unicast stream to catch up to the main multicast stream, at which point, the FCC server signals to the client to join the main RTP stream.
FCC client/server protocol illustrates the FCC client and server communication.
There are two techniques for compressing the FCC unicast stream in time to allow the unicast session to catch up to the multicast stream: bursting and denting. When bursting, the stream is sent at a rate faster than multicast stream, for example, the stream can be ‟bursted” at 130% (or 30% over the nominal) multicast rate. ‟Denting” is a technique where less important video frames are dropped by the FCC server and not sent to the FCC client. Hybrid mode combines bursting and denting.
Bursting is illustrated in FCC bursting sent faster than nominal rate and denting is illustrated in FCC denting removing less important frames .
When the unicast session has caught up to the multicast session, the FCC server signals to the FCC client to join the main multicast stream. The FCC server then sends the unicast session at a lower rate called the ‟handover” rate until the unicast session is terminated.
The FCC server functionality requires the Nokia 5910 Video Services Appliance (VSA) Re-Wrapper which is used to encapsulate and condition the multicast channel streams into RTP, adding important information in the RTP extension header. Also, the ISA FCC server requires an STB FCC client based on the Nokia FCC/RET Client SDK.
Retransmission server
The ISA RET server is supported within an IES or VPRN service context as applicable to the platform.
Whether the RET server is active for a specific multicast channel is defined in the multicast information policy where channels are defined. The channel configuration for the RET server within the policy is an explicit enable/disable of the local RET server (that is, whether the channel should be buffered), the RET buffer size for the channel in the ISA and a channel type (Picture-in-Picture (PIP), Standard Definition (SD) or High Definition (HD)). The RET buffer should be large enough to account for the round trip delay in the network; typically, a few hundred milliseconds is sufficient.
In an IES or VPRN service, up to 16 IP addresses can be assigned to a video interface.
The video policy within the multicast information policy defines the characteristics for the how the RET server should respond to NACKs received on an IP address. The different characteristics defined in a RET server ‟profile” are for each channel type (PIP, SD and HD):
enable/disable for the RET server (that is, whether requests should be serviced or dropped)
the RET rate (as a percentage of the nominal channel rate)
Typically, RET replies are sent below line rate because most dropped packets occur in the last mile and sending RET replies at a high rate may compound any last mile drop issues.
The IP address(es) of the RET server are defined in the unicast service instance, whereas the UDP port for the RET server is defined in the ‟default” bundle in the multicast information policy. The same UDP port is used for all RET server IP addresses that use the particular multicast information policy.
The ISA RET server supports the network model where there are separate service instances for unicast and multicast traffic that are cross-connected and multicast replicated downstream in the network. If there are separate multicast and unicast service instances, the unicast and multicast services must use the same multicast information policy.
FCC server
The ISA FCC server is supported within an IES or VPRN service context as applicable to the platform. VPRN services are not supported on the 7450 ESS.
Whether the FCC server is active for a specific multicast channel is defined in the multicast information policy where channels are defined. The channel configuration for the FCC server within the policy is an explicit enable/disable of the local FCC server (that is, whether the channel should be buffered) and a channel type PIP, SD or HD. When FCC is enabled, three (3) GOPs are stored in the buffer. The channel also defines an optional FCC tuning parameter called the FCC Minimum Duration which is used by the FCC server to determine which GOP to start the FCC unicast session. If there are too few frames of the current GOP stored in the FCC server buffer (based on number of milliseconds of buffering), the FCC server starts the FCC session from the previous GOP.
In an IES or VPRN service, up to 16 IP addresses can be assigned to a video interface.
The Video Policy within the multicast information policy defines the characteristics for the how the FCC server should respond to FCC requests received on an IP address. The different characteristics defined in an FCC server ‟profile” are for each channel type (PIP, SD and HD):
enable/disable for the FCC server (for example, should the requests be serviced or dropped)
the FCC mode (burst, dent or hybrid)
the burst rate (as a percentage above the nominal channel rate) for PIP, SD and HD channel types
the multicast handover rate (as a percentage of the nominal channel rate) used by the server after it has signaled the client to join the main multicast channel
Different FCC rates are allowed for each of the channel types because the channel types have different nominal bandwidths. For example, the last mile may only be able to reliably send a 25% burst (above nominal) for HD whereas the equivalent bit rate for SD is a 75% burst. The profiles are designed to provide flexibility.
The IP address of the FCC server is defined in the unicast service instance, whereas the UDP port for the FCC server is defined in the ‟default” bundle in the multicast information policy. The same UDP port is used for all FCC server IP addresses that use the particular multicast information policy.
The ISA FCC server supports the network model where there are separate service instances for unicast and multicast traffic that are cross-connected and multicast replicated downstream in the network. If there are separate multicast and unicast service instances, the unicast and multicast services must use the same multicast information policy.
Logging and accounting for RET and FCC
Statistics and accounting is available for:
RET server sessions stats
FCC session stats
RET and FCC server concurrency
Even though the previous sections discussed the RET server and FCC server as separate entities, the ISA can support RET and FCC servers at the same service at the same time. Therefore, the configuration commands and operational commands for the services are intermingled. If both the RET server and FCC server are enabled for a specific channel, a single buffer is used for caching of the channel.
A maximum bandwidth limit for all server requests can be defined for a specific ‟subscriber” which is equated with the source IP address. Before an ISA server processes a request, the ISA calculates the bandwidth to the subscriber required, and drops the request if the subscriber bandwidth limit is exceeded.
The ISA services RET and FCC requests on a first in, first out (FIFO) basis. Before servicing any request, the ISA calculates whether its egress bandwidth can handle the request. If there is insufficient egress bandwidth to handle the service request, the request is dropped. Near the ISA’s egress limits, RET requests generally continue to be serviced whereas FCC requests are dropped because RET sessions are generally a fairly small percentage of the nominal rate and FCC sessions are slightly below to above the nominal channel rate.
Prerequisites and restrictions
This section summarizes some key prerequisites and restrictions for the RET client, RET server and FCC server:
Both RET and FCC require RTP as the transport stream protocol.
FCC requires the Nokia 5910 VSA Re-Wrapper.
FCC requires an implementation of the Nokia 5910 STB Client.
The multicast information policies must be the same on multicast and unicast services which are cross connected downstream.
Up to 16 IP addresses can be configured for a Layer 3 service video interface (IES or VPRN) with each supporting a distinct profile.
There can be a maximum of 32 IP addresses across all Layer 3 service video interfaces per chassis.
Separate timers for FCC and RET
For each fast channel change, a new RTCP session is initialized, whereas for retransmission, the same RTCP session is always reused, with the same source and destination ports. The RTCP session duration is based on a timeout configuration, and a separate timeout parameter is available for FCC and RET under config>mcast-mgmt>mcast-info-policy>video-policy>video-interface, namely the fcc-session-timeout and ret-session-timeout parameters. As the FCC RTCP session timeout is generally shorter than the RET session timeout, the recommendation is to configure the FCC RTCP session timeout to a lower timeout value, accounting for the time required to complete a fast channel change and complete the multicast handoff. This strategy frees up RTCP sessions for other subscribers and improves efficiency.
Peak bandwidth and sessions per ISA
The CLI command show isa video-group video-group-id displays the peak egress bandwidth and sessions per ISA. Each peak value is also marked with a timestamp.
There are configurable watermarks for bandwidth and session consumption. The watermarks generate SNMP traps or log events when the ISA has reached the bandwidth or session thresholds. The egress bandwidth and session watermarks are configurable for FCC and RET separately, and also for FCC and RET together. The SNMP trap or log event is generated as the configured watermark is exceeded and is cleared if it falls below 10% of the watermark. For example, if the maximum egress rate is 10 Gb/s and the watermark is set at 90%, the alarm is generated when the egress rate exceeds 9 Gb/s (90% of 10 Gb/s) and the alarm is cleared if the egress rate falls below 10% at 8.1 Gb/s (10% of 9 Gb/s = 0.9 Gb/s, and 9 Gb/s - 0.9 Gb/s = 8.1 Gb/s).
Video support on ESA
Video is supported on ESA:
FCC/RET application
VQM and perfect stream are not supported at this time.
Only SR-7/12/12e/7s/14s are supported at this time. For SR-s system, CPM-s must be used.
ISA and ESM must not be used in the same video group.
CDN for Live TV
Traditionally, IPTV is delivered over a broadband network and subscribers require IPTV STB to receive multicast content. Both the STB and its IP gateway must support IP multicast and IGMP. Because native IGMP cannot route beyond the first IP hop, subscriber reach is often restricted.
CDN (Content Delivery Network) for Live TV further extends the FCC feature. To enable CDN for Live TV, use the following CLI:
in the classic CLI
config>mcast-mgmt-mcast-info-plcy>video-policy>video-if extended-unicast
in the MD-CLI
configure multicast-management multicast-info-policy video-policy video-interface extended-unicast
Channel requests are triggered by an RTCP request. IPTV content is unicast to each individual subscriber using RTP over IP UDP, which:
eliminates the need to have both IP multicast support and IGMP support on end user devices
only requires subscribers to have IP connectivity. IPTV content is routed Over The Top (OTT) to individual subscribers.
supports all FCC, RET, and CDN for Live TV on the same ISA/ESA. Therefore, the ISA/ESA that supports FCC/RET for broadband IPTV multicast can be reused for CDN for Live TV.
allows OTT subscribers to use the same STB and software as the traditional broadband multicast IPTV subscribers. STB can be programmed to automatically use RTCP messages instead of IGMP, if IGMP requests are non-responsive. This allows for unified STB deployment regardless of the end subscriber type.
delivers video content using UDP with steady bit rate, which does not require network dimensioning for TCP burstiness or buffering
allows CDN for Live TV subscribers to use the FCC and RET function. CDN for Live TV uses RTCP control messages to retrieve IPTV content.
Delayed IGMP join for FCC
The FCC solution requires the STB to switch from unicast to multicast after the fast channel change completes. The STB uses IGMP to switch to multicast. In some cases, the multicast process is delayed. Delay may occur because of IGMP processing delay, authentication delay, or network delay. The extended-unicast command, which is used for CDN for Live TV, delays the IGMP for up to 5 minutes. Nokia recommends enabling this command only in implementations where multicast delivery is delayed beyond 1.5 seconds. By default, extended unicast is disabled to ensure the optimal bandwidth for unicast to multicast handover.
Configuring video service components with CLI
This section provides information to configure RET/FCC using the command line interface.
Video services overview
The main entities of video configurations are:
video group
multicast information policy
a video policy to configure video interface properties
multicast bundles and channels to associate bundles/channels with video groups
within a service, configuring video interfaces and their associations with video groups
Video services configuration elements shows various configuration elements and how they are associated by configuration.
A video interface within a service can have multiple IP address, and their association with the video interfaces within the video policy are based on IP addresses. Support for multiple video interface IP addresses for a specific video interface allows video characteristics (burst rate, retransmission format, and so on) for the channels associated with the video interface to be based on the IP address on which the request is received.
Both the bundle/channel configuration and the video interface configuration within the service are associated with a specific video group. If the request is received on a video interface for a channel not serviced by the video group associated with the video interface, the request is invalid and is dropped. Video services configuration elements displays an example of this is a request for mc-range2 received on IP1, IP2 or IP3. A request for mc-range2 would only be valid on IP4.
As with other multicast information policies, the bundle name default is a special bundle and is reserved for setting of default values. If a video parameter is not explicitly set in a bundle/channel, the value set in the default bundle is used.
Configuring an ISA module
The ISA hardware has an MDA form factor and is provisioned in the same manner as other MDAs in the config>card>mda>mda-type context.
Use the following commands to configure an ISA module:
Classic CLI commands
configure card slot-number mda mda-slot mda-type mda-type
MD-CLI commands
configure card slot-number mda mda-slot mda-type mda-type
The following output displays an ISA configuration example:
Classic CLI commands
*A:Dut-C>config>card# info
----------------------------------------------
card-type iom4-e-b
mda 1
mda-type isa2-bb
exit
mda 2
mda-type isa2-bb
exit
----------------------------------------------
*A:Dut-C>config>card#
MD-CLI commands
(gl)[/configure card 9]
A:admin@Dut-E# info
card-type iom4-e-b
mda 1 {
mda-type isa2-aa
}
mda 2 {
mda-type isa2-aa
}
fp 1 {
}
Configuring a video group
When used for video services, ISA-MSes are logically grouped into video groups that pool the ISA buffering and processing resources into a single logical entity.
Use the following CLI syntax to configure a video group:
config
isa
video-group video-group-id [create]
description description-string
primary mda-id
[no] shutdown
The example shown below shows video-group 1 with a single ISA configured in slot 2/MDA 1.
*A:Dut-C>config>isa# info
===============================================================================
video-group 1 create
description "Video Group 1"
primary 7/2
no shutdown
exit
===============================================================================
*A:Dut-C>config>isa#
Within the video group configuration, there are specific video application commands to enable features. These commands are described in the configuration examples for the application. Depending on the video application, more than one primary ISA-MS is allowed increasing the egress capacity of the video group.
ISA-MS in a single video group cannot be on the same IOM. An IOM can accommodate two ISA-MS modules provided that the ISA-MS are members of different video groups.
Configuring a video SAP and video interface in a service
Video features in a VPRN service require the creation of a video SAP and a video interface. A video SAP is similar to other SAPs in the system in that QoS and filter policies can be associated with the SAP on ingress (traffic leaving the ISA and ingressing the system) and egress (traffic leaving system and entering the ISA).
The video SAP is associated with a video group. Channels are also associated with a video group which is what establishes the link between what channels can be referenced through the video SAP. The multicast information policy associated with the service is where the channel to video group association is defined.
A single VPRN service can be used to support all video applications. However, It is possible to use 2 different VPRNs for a FCC/RET service; one VPRN is configured with a FCC/RET server to process FCC/RET requests, and a second VPRN is configured to support only the buffering of the multicast video content. In this case, within the FCC/RET server VPRN, the multicast service of the VPRN (service ID) must be specified.
Another parameter defined for a channel in the multicast information policy that is important for video services is the administrative bandwidth defined for the channel. Many video applications use the bandwidth to determine if sufficient ISA egress bandwidth exists to service or drop a service request.
The following output displays an example video interface configuration.
A:IPTV-SR7>config>service>ies# info
----------------------------------------------
video-interface "video-100" create
video-sap 4
exit
address 10.1.1.254/8
address 192.168.0.254/8
address 192.168.1.254/24
adi
channel 192.168.5.228 source 192.168.9.10 channel-name "228"
scte35-action drop
zone-channel 192.168.5.228 source 192.168.100.1 adi-channel-name
"228-1"
exit
scte30
ad-server 10.200.14.2
local-address control 10.1.1.2 data 10.1.1.3
exit
exit
----------------------------------------------
A:IPTV-SR7>config>service>ies#
Basic multicast information policy configuration
Multicast information policies are used by the video applications to define multicast channel attributes and video policies which contains application-specific configuration for a video interface IP address.
It is within the multicast information policy bundles, channels and source-overrides that a video group is assigned to a channel. The video group association is inherited from the more general construct unless it is explicitly disabled.
The administrative bandwidth for channels at the bundle, channel or source-override level is also defined in the multicast information policy. Video applications use the administrative bandwidth here when a channel rate estimate is needed.
A video policy is defined within the multicast information policy for a specific video interface IP address. The IP address for the video policy is the key value that associates it with a specific video interface IP address within a service associated with overall multicast information policy.
See the 7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide for CLI command descriptions and syntax usage information to configure multicast info policies.
The following example displays a multicast info policy configuration:
A:IPTV-SR7>config>mcast-mgmt># info
----------------------------------------------
multicast-info-policy "ies100" create
bundle "5.6.140" create
admin-bw 8000
video
video-group 1
local-rt-server
rt-buffer-size 3000
exit
channel "10.5.6.140" "10.5.6.140" create
exit
exit
bundle "default" create
exit
bundle "5.6.241-5.6.243" create
admin-bw 12000
video
video-group 1
rt-buffer-size 4000
exit
channel "10.5.6.241" "10.5.6.243" create
exit
exit
exit
----------------------------------------------
A:IPTV-SR7>config>router#
Sample configurations
The following output displays configurations of VQM with packet selection.
*A:SR-7/Dut-C>config>mcast-mgmt># info
----------------------------------------------
multicast-info-policy "vqm" create
bundle "ixia" create
channel "10.5.5.6" "10.5.5.7" create
admin-bw 20000
video
video-group 4
rt-buffer-size 1000
analyzer
alarms
cc-error
pat-repetition tnc 400 qos 600 poa 700
pat-syntax
pid-pmt-unref
pmt-repetition tnc 2300 qos 2500 poa 2700
pmt-syntax
vid-pid-absent 5000
non-vid-pid-absent 5000
pcr-repetition tnc 400 qos 600 poa 700
scte-35
tei-set
ts-sync-loss
exit
exit
stream-selection source1 192.168.2.1 intf1 "ineo-ingress1"
source2 192.168.2.1 intf2 "ineo-ingress2"
exit
source-override "192.168.2.1" create
exit
exit
exit
bundle "default" create
exit
exit
----------------------------------------------
*A:SR-7/Dut-C>config>service# info
----------------------------------------------
customer 1 create
description "Default customer"
exit
ies 300 customer 1 vpn 300 create
description "Default Ies description for service id 300"
video-interface "video-300" create
video-sap 4
exit
address 10.20.255.254/16
channel 10.5.5.6 source 192.168.2.1 channel-name "Ineoquest-1"
zone-channel 10.5.5.6 source 10.20.0.1 adi-channel-name "Ineoquest-
1-1"
exit
adi
exit
no shutdown
exit
service-name "XYZ Ies 300"
no shutdown
exit
----------------------------------------------
*A:SR-7/Dut-C>config>service#
*A:SR-7/Dut-C>config>router# info
----------------------------------------------
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
interface "ineo-ingress1"
address 10.200.16.1/24
port 3/2/12
ingress
filter ip 100
exit
exit
interface "ineo-ingress2"
address 10.200.17.1/24
port 5/1/1
ingress
filter ip 200
exit
exit
interface "ixia-egress"
address 10.200.15.1/24
port 3/2/15
exit
interface "system"
address 10.20.3.1/32
exit
ecmp 2
multicast-info-policy "vqm"
static-route 192.168.2.1/32
next-hop 10.200.16.2
no shutdown
exit
next-hop 10.200.17.2
no shutdown
exit
exit
#--------------------------------------------------
echo "IGMP Configuration"
#--------------------------------------------------
igmp
interface "video-300-D"
static
group 10.5.5.6
source 192.168.2.1
exit
exit
exit
interface "video-300-D2"
static
group 10.5.5.6
source 192.168.2.1
exit
exit
exit
interface "ixia-egress"
static
group 10.5.5.6
source 10.20.0.1
exit
exit
exit
exit
#--------------------------------------------------
echo "PIM Configuration"
#--------------------------------------------------
pim
rpf-table rtable-m
interface "video-300"
exit
interface "ineo-ingress1"
multicast-senders always
exit
interface "ineo-ingress2"
multicast-senders always
exit
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
exit
----------------------------------------------
*A:SR-7/Dut-C>config>router#
*A:SR-7/Dut-C>config>isa# info
----------------------------------------------
video-group 4 create
analyzer
stream-selection
primary 3/1
no shutdown
exit
----------------------------------------------
*A:SR-7/Dut-C>config>isa#
The following output displays configurations of VQM without packet selection.
----------------------------------------------
*A:SR-7/Dut-C>config>service# info
----------------------------------------------
customer 1 create
description "Default customer"
exit
ies 300 customer 1 vpn 300 create
description "Default Ies description for service id 300"
interface "linux-ingress" create
address 10.10.33.228/24
sap 3/2/17 create
description "sap-300-10.10.33.228"
exit
exit
interface "linux-egress" create
address 10.10.34.228/24
sap 3/2/7 create
description "sap-300-10.10.34.228"
exit
exit
video-interface "video-300" create
video-sap 2
exit
address 10.20.13.1/24
channel 10.5.5.6 source 192.168.2.1 channel-name "A2-SP3"
zone-channel 10.5.5.6 source 10.20.13.2 adi-channel-name "A2-SP3-1"
exit
adi
exit
no shutdown
exit
service-name "XYZ Ies 300"
no shutdown
exit
----------------------------------------------
*A:SR-7/Dut-C>config>service# /configure router
*A:SR-7/Dut-C>config>router# info
----------------------------------------------
#--------------------------------------------------
echo "IP Configuration"
#--------------------------------------------------
interface "system"
address 10.20.1.1/32
exit
multicast-info-policy "A-server"
#--------------------------------------------------
echo "Static Route Configuration"
#--------------------------------------------------
static-route 128.251.33.0/24
next-hop 10.10.33.229
no shutdown
exit
static-route 192.168.2.0/24
next-hop 10.10.33.229
no shutdown
exit
exit
#--------------------------------------------------
echo "IGMP Configuration"
#--------------------------------------------------
igmp
interface "video-300-D"
static
group 10.5.5.6
source 192.168.2.1
exit
exit
exit
interface "linux-egress"
static
group 10.5.5.6
source 10.20.13.2
exit
exit
exit
exit
#--------------------------------------------------
echo "PIM Configuration"
#--------------------------------------------------
pim
interface "linux-ingress"
hello-interval 0
multicast-senders always
exit
interface "linux-egress"
hello-interval 0
exit
apply-to all
rp
static
exit
bsr-candidate
shutdown
exit
rp-candidate
shutdown
exit
exit
exit
----------------------------------------------
*A:SR-7/Dut-C>config>router# /configure isa
*A:SR-7/Dut-C>config>isa# info
----------------------------------------------
video-group 2 create
analyzer
primary 2/1
no shutdown
exit
----------------------------------------------
*A:SR-7/Dut-C>config>isa# /configure mcast-management
*A:SR-7/Dut-C>config>mcast-mgmt># info
----------------------------------------------
multicast-info-policy "A-server" create
bundle "LiveTv" create
channel "10.5.6.243" "10.5.6.243" create
admin-bw 3000
video
video-group 2
rt-buffer-size 1000
exit
exit
channel "10.5.5.6" "10.5.5.6" create
admin-bw 5000
video
video-group 2
rt-buffer-size 1000
analyzer
alarms
cc-error
pat-repetition tnc 200 qos 400 poa 600
pat-syntax
pid-pmt-unref
pmt-repetition
pmt-syntax
vid-pid-absent 1000
non-vid-pid-absent 1000
pcr-repetition tnc 200 qos 400 poa 600
scte-35
tei-set
ts-sync-loss
report-alarm severity tnc
exit
exit
exit
source-override "192.168.33.37" create
exit
exit
exit
bundle "default" create
exit
bundle "mp2ts-ads" create
channel "10.4.5.1" "10.4.5.254" create
admin-bw 5000
video
video-group 2
rt-buffer-size 1000
exit
exit
exit
exit
----------------------------------------------
*A:SR-7/Dut-C>config>mcast-mgmt>#
Configuring RET/FCC video components with CLI
This section provides information to configure RET/FCC using the command line interface.
Configuring RET/FCC video features in the CLI
The following sections provide configuration examples for the RET client, RET server and FCC server.
Configuring the RET server
This section provides an example configuration for the RET server. The configuration example has the following assumptions:
a single ISA-MS in slot 2/1 in video group 1
-
a single channel 192.0.2.1 within multicast bundle ‟b1” with an administrative bandwidth of 2700 kb/s defined in multicast-info-policy policy-name
a retransmission buffer for the channel set to 300 milliseconds
RET rate is 5% of nominal
-
local RET server address is 10.3.3.3 and destination port is UDP 4096
The first step in the configuration is to configure video group 1 enabling the RET server and the ISA-MS hardware.
config>isa
video-group video-group-id [create]
local-rt-server
no shutdown
*A:ALA-48config>isa# info
----------------------------------------------
video-group 1 create
local-rt-server
primary 2/1
no shutdown
exit
----------------------------------------------
*A:ALA-48config>isa#
*A:ALA-48config>card 2>mda 1# info
----------------------------------------------
mda-type isa-ms
----------------------------------------------
*A:ALA-48config>card>mda#
The local-rt-server command in the above output enables the local RET server on the video group.
The channel parameters for 192.0.2.1 are configured in multicast-info-policy policy-name. The channel configuration includes the administrative bandwidth and the channel’s association with video group 1.
*A:ALA-48config>mcast-mgmt>mcast-info-plcy# info
----------------------------------------------
bundle "default" create
local-rt-port 4096
exit
bundle "b1" create
admin-bw 2700
video
video-group 1
local-rt-server
rt-buffer-size 300
exit
channel "192.0.2.1" "192.0.2.1" create
exit
exit
video-policy
video-interface 10.3.3.3 create
rt-rate 5
hd
local-rt-server
exit
sd
local-rt-server
exit
pip
local-rt-server
exit
exit
exit
----------------------------------------------
*A:ALA-48config>mcast-mgmt>mcast-info-plcy#
The local-rt-port command in the bundle ‟default” defines the destination UDP port used to reach the local RET server on the service where the multicast information policy is applied. The RET server port can only be defined in the bundle ‟default” and applies for all bundles in the policy. If no value is specified, the default is used.
In the bundle ‟b1” the local-rt-server command enables the RET server for all channels in the bundle, and the rt-buffer-size rt-buffer-size command sets the retransmission buffer for all channels in the bundle to 300 milliseconds.
In the video policy above, the local-rt-server commands for the video interface 10.3.3.3 enables the RET server on that interface for all channel types ‟hd” (High Definition), ‟sd” (Standard Definition) and ‟pip” (Picture-in-Picture). The rt-rate rt-burst-percentage command in the policy indicates that the retransmission rate is 5% of the nominal rate for all channel types; individual rates can be defined if needed.
For the RET server in an IES or VPRN, these commands within the service instance perform the following tasks to complete the RET server configuration:
-
Associate the service with multicast-info-policy policy-name.
-
Create the video interface ‟vi” and assign IP address 10.3.3.3.
-
Create video SAP and associate it with video group 1.
-
Create a static IGMP join on video-interface ‟vi” for the channel 192.0.2.1.
*A:ALA-48config>service>ies# info
----------------------------------------------
video-interface "vi" create
video-sap 1
exit
address 10.3.3.3/32
no shutdown
exit
multicast-info-policy policy-name
pim
interface "vi"
exit
exit
igmp
interface "vi"
static
group 192.0.2.1
starg
exit
exit
exit
----------------------------------------------
*A:ALA-48config>service>ies#
The services available on the video interface address 10.3.3.3 are defined in the video policy in which the RET server was enabled.
Configuring the FCC server
This section provides an example configuration for the FCC server. The configuration example has the following assumptions:
a single ISA-MS in slot 2/1 in video group 1
a single channel 192.0.2.1 within multicast bundle ‟b1” with an administrative bandwidth of 8000 kb/s defined in multicast-info-policy policy-name.
FCC mode is burst with a rate 130% of nominal for HD, 200% for SD, and disabled for PIP
local FCC server address is 10.3.3.3 and destination port is UDP 4098
The first step in the configuration is to configure video group 1 enabling the FCC server and the ISA-MS hardware.
config>isa
video-group video-group-id [create]
fcc-server
no shutdown
*A:ALA-48config>isa# info
----------------------------------------------
video-group 1 create
fcc-server
primary 2/1
no shutdown
exit
----------------------------------------------
*A:ALA-48config>isa#
*A:ALA-48config>card>mda# info
----------------------------------------------
mda-type isa-ms
----------------------------------------------
*A:ALA-48config>card>mda#
The fcc-server command in the above output enables the FCC server on the video group.
The channel parameters for 192.0.2.1 are configured in multicast-info-policy policy-name. The channel configuration includes the administrative bandwidth and the channel’s association with video group 1.
*A:ALA-48configmcast-mgmtmcast-info-plcy# info
----------------------------------------------
bundle "default" create
local-fcc-port 4098
exit
bundle "b1" create
admin-bw 8000
video
video-group 1
fcc-server
fcc-channel-type hd
exit
channel "192.0.2.1" "192.0.2.1" create
exit
exit
video-policy
video-interface 10.3.3.3 create
rt-rate 5
hd
fcc-server mode burst
fcc-burst 30
exit
sd
fcc-server mode burst
fcc-burst 100
exit
pip
no fcc-server
exit
exit
exit
----------------------------------------------
*A:ALA-48configmcast-mgmtmcast-info-plcy#
The local-fcc-port command in the bundle ‟default” defines the destination UDP port used to reach the FCC server on the service where the multicast information policy is applied. The FCC server port can only be defined in the bundle ‟default” and applies for all bundles in the policy. If no value is specified, the default is used.
In the bundle ‟b1”, the fcc-server command enables the FCC server for all channels in the bundle, and the fcc-channel-type hd command sets the channel type for all channels in the bundle to ‟hd” (High Definition).
In the video policy context above, the fcc-server commands for the video interface 10.3.3.3 enables the FCC server on that interface for all channel types ‟hd” (High Definition), ‟sd” (Standard Definition) whereas the no fcc-server command disables the FCC for ‟pip” (Picture-in-Picture) channels on the video interface. The fcc-burst command in the policy indicates that the burst rate over the nominal rate for the channel type; HD at 130% (30% over nominal) and SD at 200% (100% over nominal).
For the FCC server in an IES or VPRN, the following commands within the service instance perform the following tasks to complete the FCC server configuration:
-
Associate the service with multicast-info-policy policy-name.
-
Create the video interface ‟vi” and assign IP address 10.3.3.3.
-
Create video SAP and associate it with video group 1.
-
Create a static IGMP join on video-interface ‟vi” for the channel 192.0.2.1.
*A:ALA-49configserviceies# info
----------------------------------------------
video-interface "vi" create
video-sap 1
exit
address 10.4.4.4/32
no shutdown
exit
----------------------------------------------
*A:ALA-49configserviceies#
*A:ALA-48configrouter# info
----------------------------------------------
...
multicast-info-policy policy-name
pim
interface "vi"
exit
exit
igmp
interface "vi"
static
group 192.0.2.1
starg
exit
exit
exit
----------------------------------------------
*A:ALA-48configrouter#
The services available on the video interface address 10.3.3.3 are defined in the video policy in which the FCC server was enabled.
Logging and accounting collection for video statistics
The following output displays a configuration example used in logging and accounting for video.
*A:SR-7/Dut-C>config>log# info
----------------------------------------------
file-id 1
location cf3:
exit
accounting-policy 1
shutdown
record video
collection-interval 5
to file 1
exit
...
----------------------------------------------
*A:SR-7/Dut-C>config>log#
Use the following CLI to enable logging and accounting to a service to collect stats for that particular service.
Example:
*A:SR-7/Dut-C>config>service>ies# video-interface "vi" accounting-policy 1
*A:SR-7/Dut-C>config>service>ies# info
video-interface "vi" create
accounting-policy "1"
exit
Starting stats collection can be enabled by executing a no shutdown command on the accounting policy. This starts the recording of stats and the stats are written in an act-collect directory and a shutdown command on the accounting policy moves the recorded file to act directory.