http://www.opendaylight.org/blogs/2015/05/how-comcast-using-opendaylight
By Chris Luke, Senior Principal Engineer, Comcast and OpenDaylight Advisory Group Member
Comcast joined the OpenDaylight Project today and we wanted to share how we've been using the OpenDaylight platform and how it fits into our long-term network direction.
We have been testing ODL since the project launched to see where it might fit in and have been impressed by the improvements in functionality and stability with each successive release. We have also been participating with our partner CableLabs on the OpenDaylight sub-project PacketCable PCMM, which aims to develop a southbound plugin for ODL that can manage service flows across Cable Modem Termination System (CMTS) devices.
I am also proud to have a chance to serve the community as a founding member of ODL's official advisory group, which I joined in January 2015. This group plays a critical role to gather and share feedback on how ODL is being used directly with the community. The advisory group is proving to be an effective way to connect with and learn from other OpenDaylight users, something that ultimately benefits the ODL project.
Network Direction
Like many service providers, Comcast is motivated to reduce the operational complexity of our networks. In the near-term this involves significant improvements to network automation under what we call our Programmable Network Platform. This framework outlines a stack of behaviors and abstraction layers that software uses to interact with the network.
Some of our key objectives are to simplify the handoffs from the OSS/BSS systems, empower engineers to rapidly develop and deploy new services and to improve the operational support model. It is our hope that by harmonizing on a common framework and useful abstractions, more application groups within the company will be able to make use of better intelligence and more easily interact with the network.
Longer term, we're working toward creating an architecture where the core of the network is not intimately involved in the operation of virtual networks.
To operate this we are looking at technologies such as segment routing and LISP. We're also working on virtualizing the role of the traditional provider edge (PE) and the customer premise device (CPE) into a fully overlay-driven system where those monikers may no longer make sense. What that ultimately looks like we don't know yet; what we do know is that the current complexity inherent in the components we use is undesirable and we must be careful to not simply trade one convoluted system for another equally but differently convoluted system.
When ODL was launched we were excited to see that the industry was moving to a supportable open source model for SDN. There were a growing number of proprietary SDN controllers at the time and that had service providers like us questioning the direction of the market and whether it made sense to us. We were pleased to see an open source platform come forward aiming to provide a neutral playing field with support for more than just OpenFlow. Today things appear to be headed in the right direction with over a dozen vendors with ODL-based solutions and an ecosystem being built around the platform.
Work in Progress
Several internal workflows use OpenDaylight in some way and there are more on the horizon. The examples here specifically highlight how we are using OpenDaylight and SDN techniques to build towards our long-term goals, but also show how we are integrating our existing deployed equipment.
Proof-of-Concept: Network Intelligence Abstraction. We have several applications that distribute large volumes of content across the network to our customers, including to set-top box platforms. These systems act like a CDN inside the network and like most commercial CDN providers are limited to empirical external observations of how the network behaves to determine from where to source content. While this works well, it could be made more efficient and could be made to work more responsively during disruptive network events if those applications had a mechanism to ask the network meaningful questions. Most application developers do not want to learn the intricacies of network engineering and thus we needed to determine an appropriate level of abstraction.
To achieve this we selected OpenDaylight and developed an SDN App that used ODL to interface with the network. The beauty of this mechanism is it allows the network to influence the decisions an application is making in real-time, but without adding any complexity to the forwarding plane of the network itself. For future work we will investigate several projects slated for inclusion in the Lithium ODL release, such as ALTO, Maple and others to see if they offer more of the functionality we're looking for in order to make the SDN App much less complex.
Proof-of-Concept: Overlay Edge Services. In keeping with the future direction of the network, where we use IPv6 as an underlay for all our services, we're investigating several techniques for doing this at the edge of the network. Currently two key approaches involve OpenDaylight.
We're investigating the use of LISP to build VPN meshes. We're working with the LISP modules that have been contributed to ODL to manage the endpoints in the VPN mesh; we're experimenting with whether those endpoints should be hosted virtually or if they should exist on the CPE, whether the CPEs build a mesh or deliver their packets to a cloud hosted node.
The second line of investigation involves using mostly-stateless GRE (also known as SoftGRE) tunnels to build endpoints that integrate with the legacy MPLS network. The tunnels from a PE-like device are signaled using BGP messages that are sent by OpenDaylight. ODL is then also used to make the determination, from network topology and network metrics, which PE-like device is used to host each tunnel. Lastly, because these are MPLS services, we may also use ODLs PCEP module to signal the LSPs between the PE devices.
Community
I recently presented a summary of some of the work we're doing with OpenDaylight at an Advisory Group meeting where many of the challenges I described appeared to ring true with several other members. Allowing users of the platform a venue to find common ground, without any vendor bias, and feed that back to the ODL development community is one of the most valuable parts of the Advisory Group. Comcast is excited to now formally join the project and we look forward to continued participation. I hope you'll join me and other Advisory Group members at the OpenDaylight Summit in July so we can continue to tackle these issues together.
If you'd like to participate in our user series, please contact pr@opendaylight.org or give us a shout-out using the #OpenSDN hashtag.
OpenDaylight is building a bridge to SDN for service providers and enterprises. Images of bridges from Environmental Services, Oregon Department of Transportation: Ross Island Bridge (1926), Marquam Bridge (1966).
-- via my feedly.com reader
No comments:
Post a Comment