Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Understanding Inline Video Monitoring on MX Series Routers

Junos OS supports inline video monitoring using media delivery index (MDI) metrics.

Before you use the inline video monitoring feature, ensure that you understand the following terms:

  • media delivery index—MDI metrics facilitate identification of buffering needs for streaming media. Buffering must be adequate to compensate for packet jitter, measured by the MDI delay factor, and quality problems indicated by lost packets, measured by the MDI media loss rate (MLR). By performing measurements under varying load conditions, you can identify sources of significant jitter or packet loss and take appropriate action.

  • delay factor—Delay factor is the maximum observed time difference between the arrival of media data and the drain of media data. The expected drain rate is the nominal, constant traffic rate for constant bit rate streams or the computed traffic rate of variable rate media stream packet data.

    For typical stream rates of 1 megabit per second and higher, an interval of one second provides an adequate sample time. The delay factor indicates how long a data stream must be buffered (delayed) at its nominal bit rate to prevent packet loss.

    The delay factor suggests the minimum size of the buffer required at the next downstream node. As a stream progresses, the variation of the delay factor indicates packet bunching or packet gaps (jitter). Greater delay factor values also indicate that more network latency is needed to deliver a stream due to the need to pre-fill a receive buffer before beginning the drain to guarantee no underflow.

    When the nominal drain bit rate at a receiving node is known, the delay factor’s maximum indicates the size of buffer required to accommodate packet jitter.

  • Media rate variation (MRV)—This value is the difference between the expected packet rate and actual packet rate, expressed as a percentage of the expected packet rate.

  • Media loss rate (MLR)—This value is the number of media packets lost over a configurable time interval (interval-duration), where the flow packets carry streaming application information. A single IP packet can contain one or more streaming packets. For example, an IP packet typically contains seven 188-byte MPEG transport stream packets. In this case, a single IP packet loss results in seven lost packets counted (if those seven lost packets did not include null packets). Including out-of-order packets is important, because many consumer-type streaming devices do not attempt to reorder packets that are received out of order.

To configure the monitoring process, define criteria templates and apply them to the interfaces and flows you want to monitor. Monitoring templates include the following criteria:

  • Duration of each measurement cycle

  • Flow rate information used to establish expected flow rates

  • Threshold levels for delay factor, media rate variation, and media loss rate that trigger desired system log alerts

For each interface you want to monitor, you can define one or more filters to select IPv4 flows for monitoring. Flows are designated as input or output flows. Starting in Junos OS Release 17.2R1, you can identify IPv4-over-MPLS flows. Starting in Junos OS Release 17.4R1, you can identify IPv6 flows and IPv6-over MPLS flows. Starting in Junos OS Release 19.1R1, you can configure MX Series routers for inline video monitoring of uncompressed HD or 4K stream video (Payload Type 98 and 99). MDI functionality has been extended to video flows such as ST 2000-5 (RTP PT 98) and ST 2000-6 (RTP PT 99). These are non-MPEG video flows over IP/UDP/RTP and are constant bit-rate flows. The operator would specify proper IP addresses and UDP ports so that non-video flows over RTP will not go through MDI processing.

MPLS flows with more than three labels cannot be monitored.

IPv4 flows are uniquely identified by:

  • Destination IP address

  • Destination port

  • Source IP address

  • Source port

  • Direction

  • Interface index

  • Media type (RTP or MPEG)

IPv4-over-MPLS flows are uniquely identified by:

  • The top three MPLS labels

  • Destination IP address

  • Destination port

  • Source IP address

  • Source port

  • Direction

  • Interface index

  • Media type (RTP or MPEG)

IPv6 flows are uniquely identified by:

  • Destination IP address

  • Destination port

  • Source IP address

  • Source port

  • Direction

  • Interface index

  • Media type (RTP or MPEG)

IPv6-over-MPLS flows are uniquely identified by:

  • The top three MPLS labels

  • Destination IP address

  • Destination port

  • Source IP address

  • Source port

  • Direction

  • Interface index

  • Media type (RTP or MPEG)

Junos OS supports the definition of filters for up to 256 flows on an interface, which can consist of input flows, output flows, or a combination of input and output flows. These filters provide criteria for selecting flows for monitoring. If the selection criteria consist of lists of IP addresses or ports, you can exceed the maximum number of match conditions for flows. Video monitoring selects a widely variable number of flows based on flow filters.

The total number of destination IP addresses configured in a flow for an interface cannot exceed 32, and the total number of source IP addresses configured in a flow for an interface cannot exceed 32.

Inline video monitoring is not supported when you enable Next Gen Services on an MX Series router.

Inline video monitoring is available on MX Series 5G Universal Routing Platforms using only the following MPCs:

  • MPC1

  • MPC1E

  • MPC2

  • MPC2E

  • MPC2E-NG

  • MPC3E-NG

  • MPC-16XGE

  • MPC5E

  • MPC6E

  • MPC7E

  • MPC8E

  • MPC9E

  • MPC10E

  • MPC11E

Note:

Traffic throughput is reduced below the interface bandwidth when video monitoring is used with an MPC2E-NG or MPC3E-NG in the following scenario:

  • The input and output ports are on the same slot.

  • The input-flows is configured as inet and the output-flows is configured as mpls.

  • At least one flow has a traffic rate greater than 2 Gbps.

To avoid this reduced throughput, use input and output ports on different slots.

Starting in Junos OS Release 16.1R1, you can configure the number of flows that can be measured per Packet Forwarding Engine at a time, up to a value of 8192. The maximum configured number of flows that can be measured for each MPC model is shown in the second column of Table 1. The default number of flows that can be measured for each MPC model is shown in the third column of Table 1. In Junos OS Release 15.1 and earlier, you cannot configure the number of flows that can be measured.

When you do not define input or output flow filters for a monitored interface, all flows on the interface are subject to monitoring.

Table 1: MPC Flow Monitoring Capacity by Model

MPC Model

Maximum Configurable Number of Flows Monitored Simultaneously (Starting in Junos OS Release 16.1)

Default Number of Flows Monitored Simultaneously

MPC1

8000

1000

MPC1E

8000

1000

MPC2

16,000

2000

MPC2E

16,000

2000

MPC2E-NG

8000

1000

MPC3E-NG

8000

1000

MPC-16XGE

32,000

4000

MPC5E

40,000

5000

MPC6E

40,000

5000

MPC7E

40,000

5000

MPC8E

40,000

5000

MPC9E

40,000

5000

MPC10E

24,000 (starting in Junos OS Release 20.3R1)

3000

MPC11E

64,000 (starting in Junos OS Release 20.3R1)

8000

Note:

Junos OS measures both UDP flows (the default) and RTP flows. Junos OS differentiates media traffic over UDP or RTP by inspecting the first byte in the UDP payload. If the first byte of the UDP payload is 0x47 (MPEG2-TS sync byte), the traffic is treated as media traffic over UDP. Traffic is treated as media traffic over RTP if the version field is 2 and the payload type is 33 in the RTP header. When neither of these criteria are met, the packet is not considered for video monitoring.

Starting in Junos OS Release 15.1R1, MX Series routers support the inline video monitoring to measure media delivery index (MDI) metrics that can be accessed using the SNMP GET operation. Currently, inline MDI can generate only a system log when the computed value is not within the configured range. SNMP is primarily used to monitor alarms raised by the inline video monitoring feature. The alarms are monitored in the network management systems either to troubleshoot the problem or to diagnose degradation in video quality.

You use the video-monitoring statement at the [edit services] hierarchy level to specify monitoring criteria for two key indicators of video traffic problems: delay factor and media loss rate (MLR), and to apply these metrics to flows on designated interfaces.

Release History Table
Release
Description
19.3R2
Inline video monitoring is not supported when you enable Next Gen Services on an MX Series router.
19.1R1
Starting in Junos OS Release 19.1R1, you can configure MX Series routers for inline video monitoring of uncompressed HD or 4K stream video (Payload Type 98 and 99). MDI functionality has been extended to video flows such as ST 2000-5 (RTP PT 98) and ST 2000-6 (RTP PT 99). These are non-MPEG video flows over IP/UDP/RTP and are constant bit-rate flows. The operator would specify proper IP addresses and UDP ports so that non-video flows over RTP will not go through MDI processing.
17.4R1
Starting in Junos OS Release 17.4R1, you can identify IPv6 flows and IPv6-over MPLS flows.
17.2R1
Starting in Junos OS Release 17.2R1, you can identify IPv4-over-MPLS flows.
16.1R1
Starting in Junos OS Release 16.1R1, you can configure the number of flows that can be measured per Packet Forwarding Engine at a time, up to a value of 8192.
15.1R1
Starting in Junos OS Release 15.1R1, MX Series routers support the inline video monitoring to measure media delivery index (MDI) metrics that can be accessed using the SNMP GET operation. Currently, inline MDI can generate only a system log when the computed value is not within the configured range.