MPLS multicast mission ready
Packet-switched network technology ready for large-scale mission-critical network scale broadcasts, Juniper engineer enthuses
With some engineering, large-scale data feeds can be routed over
Multi Label Protocol Switching (MPLS) networks with such
reliability that they could be used for mission-critical tasks,
according to Juniper distinguished systems engineer Julian
Lucek.
If such an approach works as promised, federal agencies could
forgo using expensive dedicated circuit costs to carry
mission-critical data feeds, Lucek said.
At the MPLS conference, being held this week in Washington,
Lucek presented a few ways to route streams of data traffic through
a MPLS network in such a manner that if the flow of data was
interrupted, an identical backup feed could be tapped in a few
hundred milliseconds.
In his presentation, Lucek noted that Juniper had seen an
interest from its customers in what he calls highly reliable
point-to-multipoint data transfer (P2MP) over MPLS.
Media companies, such as cable companies, are interested in the
technology as a way to stream television shows at reduced cost. The
application could be used for other instances where an organization
needs to run highly-reliable data feeds.
As an example, air traffic control systems could use this
approach for feeds from radars, Lucek said. Data streams from a
radar could be sent, or multicast, to dozens of airports
simultaneously.
"This is something you wouldn't consider doing in an [Internet
Protocol] multicast because these signals are mission critical, and
you couldn't have signals being lost in the middle of the network,"
Lucek later told GCN.
Traditionally, an organization might contract an ATM, Frame
Relay or some other dedicated circuit connection to run such
mission critical data feeds. MPLS is an attractive alternative to
dedicated circuits due to the fact that, as a packet-based
technology, it can run on a much less expensive shared Internet
Protocol-based network. MPLS, an overlay technology, offers
features that plain IP does not have, such as the ability to
reserve bandwidth and the ability to set up dedicated routes
through a network.
However, until recently MPLS wasn't designed to carry multicast
traffic. To multicast on a MPLS network, a service provider would
have to use the Internet Protocol's own multicast protocols, which
would be difficult to set up and could not offer the same guarantee
that, should a node would go down, the data feed would still be
restored in a short time.
Key to Lucek's new approach is a set of protocols that Juniper
labeled Next Generation Multicast Virtual Private Network (NG-VPN),
which are based specifications set forth by Internet Engineering TaskForce RFC 4834.
NG-VPN separates the control plane -- which is used to manage
the routes the data takes through the network--from the data plane,
which is the conduit the data itself travel upon.
Before NG-VPN, "there was no control plane mechanism for
building multicast streams," explained Rahul Aggarwal, a
distinguished Juniper engineer, who also presented at the
conference. NG-VPN provides what Aggarwal calls "a dynamic control
plane." Such a control plane is needed so that network operators
could easily add or drop users of a data feed.
A separate control plane also ensures that, say, when a link
goes down, that an alternative path could be found in a few hundred
milliseconds.
Lucek sketched out two scenarios in which highly-reliable
multicast streams could be set up, using a dynamic control
plane.
In the first approach, called Live-Live, two copies of the data
feed are sent through different routes of the network to the end
device, which picks one of the two feeds to use. If that feed goes
down, the second feed is swapped in.
In the second approach, called Live-Standby, the second feed is
only sent to the router at the edge of the network. If the main
feed fails, the end device will tap the standby feed.
Live-Live provides a shorter downtime than Live-Standby, though
it uses more network bandwidth, because two identical feeds are
being streamed to the end-device.
Lucek noted that after various configurations are made to the
network, the feed could be recovered in about 181 milliseconds with
the Live-Live feed, or about 300 milliseconds in the Live-Standby
feed, assuming in both cases that the failure at the network takes
place at the furthest point from the end-device.
In both approaches, any interruptions in service would be barely
noticeable, Lucek said. For example, in a video feed a
300-millisecond interruption would appear as a momentary pause.
Lucek noted that an organization would want to weigh the trade-offs
between downtime and network use to determine which approach to
use.