Juniper announces closing of 128 Technology acquisition

[vc_row][vc_column][vc_column_text css=”.vc_custom_1526496394874{margin-bottom: 0px !important;}”]IP networks exist to connect service consumers to service providers. This consumer/provider relationship manifests itself everywhere in our computing lives: it could be you reading the morning news or catching up on social media to see what your friends have been having for dinner; it can be your computer performing its nightly backup, the security camera mounted outside your office streaming video to a DVR, or your smartwatch fetching the forecast from a weather service.

What all these services have in common is the network that the service requests and service responses (i.e., content) travel on. But that’s generally where the similarities between services end. It’s the differences that make these services interesting, from a networking science perspective: some, such as streaming audio and video, are said to be “real time” and sensitive to the here and now. For example, congestion or loss causes video “artifacts” and audio that sounds robotic. Other services (such as the nightly backup) are time-insensitive, but business critical. And still others, such as the weather forecast on your smartwatch or your friend’s killer app[etizer photo], can be delivered in what we call a “best effort” fashion — great if it gets there in a timely manner, but okay if it gets a little delayed.

These differences in service delivery can make or break applications. While you wouldn’t want your smartwatch update to contend with your video surveillance recording for network resources, on home networks this contention generally goes unnoticed. But talk to an IT administrator at any large enterprise, and they’ll tell you about their doomsday scenario, when a campus full of Windows machines all started downloading updates at 9:05am on Patch Tuesday just as their CEO was dialing into a videoconference with the Board of Directors.

When we set out to build a next-generation routing platform at 128 Technology, we kept these ideas in the forefront and decided to create a service-oriented data model. (A data model refers to the way data is structured in a system, and how subsystems of data relate to one another.) Unlike traditional networking equipment, where administrators configure things “bottoms-up” — starting with the interface speeds and feeds, laying routes into the different interfaces, classifying and marking traffic — a service-oriented approach works in a “top down” way. On a 128T router, administrators define the services that their network will carry (such as video conferencing, backup systems, corporate intranet), and then define properties for those services — things such as high-throughput data for backup systems, real-time streaming for video conferencing, best effort for non-business critical web browsing, etc. Administrators can also define tolerances for their service for network impairments such as packet loss, latency, and jitter. A link with a lot of jitter (which is the variance in arrival time between packets in a session) will be a killer for a VoIP telephone call — resulting in that robotic audio — but perfectly fine for a bulk database backup.

Once the administrator has defined the services and their properties, the 128T Networking Platform (128T) proactively measures the different links for latency, jitter, and loss, and chooses the most appropriate path for a given session based on its properties and the real-time conditions of the network(s) that the 128T is participating in. While administrators are free to coerce specific traffic onto specific paths using the 128T data model, by defining the service’s requirements the 128T will make a route decision on demand for each session it processes. I.e., the 128T will know when a link is “full” of voice traffic, and use the next best path that meets the quality requirements when another call comes in. Or when the link used for bulk data transfer is no longer capable for delivering information reliably to the data warehouse and another path should be used.

We at 128 Technology feel like if services are why your network was built, then services should be how you describe your network’s configuration.

[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][mk_button dimension=”flat” corner_style=”rounded” size=”medium” url=”” target=”_blank” align=”center”]Watch the demo: Deploying services with the 128T conductor[/mk_button][/vc_column][/vc_row]

Subscribe to our newsletter

Get the latest posts delivered right to your inbox

Reader Interactions

Leave a Reply

Your email address will not be published. Required fields are marked *