Cadastre-se agora para um orçamento mais personalizado!

NOTÍCIAS QUENTES

Bringing Segment Routing and IPv6 together

Aug, 30, 2016 Hi-network.com

You may be pretty familiar with Segment Routing and I bet you're likely tying it to MPLS as the industry at large has been mainly focused on driving awareness and adoption of MPLS Segment Routing.

But did you know Segment Routing could work in a native IPv6 environment? Sounds interesting to you?

Let's first go back to some IPv6 basics.

IPv6 packet header has been designed from its inception to offer flexibility by augmenting the IPv6 header with a set of instructions, called "Extension Header". There are six different types of Extension Header as per RFC 2460:

    • Hop-by-Hop Options
    • Routing
    • Fragment
    • Destination Options
    • Authentication
    • Encapsulating Security Payload

Each of these Extension Headers have been defined for specific purposes. The one of interest here is the Routing Header.

What is this Routing Header all about?

RFC 2460 gives the following definition: "The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination." It looks pretty similar to Segment Routing's intent ... That's exactly why a new type of Routing Header has been defined, called the Segment Routing Header (SRH) in this IETF draft. If you are interested in getting a deeper understanding of SRH, just read the IETF draft previously mentioned. Otherwise, keep in mind SRH contains a list of Segments that defines the network path. Segments are mere IPv6 addresses.

At this stage, some questions may pop up in your head ...

  • Does each node in my IPv6 network need to understand SRH?

The answer is NO! Only the nodes in the Segment Identifier (SID) list through which the traffic must strictly pass need to support SR-IPv6.

  • Is SR-IPv6 supported in Hardware?

The answer is YES! As an example, it is supported on ASR 9K, ASR 1K and cBR8. For further details, contact your Cisco sales representative.

  • Is it supported as a virtualized router?

Yes. Cisco CSR1000v and FD.IO

  • Do I also get advanced features as in MPLS SR?

You liked Disjoint Traffic Engineering service, you liked BGP Egress Peering Engineering, you liked TI-LFA (Automated 50ms protection) ... The good news is you get them all with SR-IPv6!

But what about any noteworthy Use Cases?

There are actually many but I would like to outline one as I believe it should be of interest to many Service Providers. Let me start with this "provocative" question -Should Service Providers keep on relying upon Multicast to deliver Linear TV? If I would have asked this question 10 years ago, the answer would have undoubtedly been: YES! And for an obvious reason ... No other efficient and cost-effective solution was available at that time to deliver IPTV services to customers. 10 years later ... It would be a mistake not to consider any alternative solution! But what has really changed in the meantime?

Well, a couple of things actually.

  • First and foremost, broadband customers consume TV services differently. Linear TV remains, of course, very important for many consumers but more and more video is being consumed on-demand. Isn't Netflix's worldwide success exemplifying this change?
  • IPv6 has finally crossed the chasm from early market to mainstream market. Cisco Visual Networking Index (VNI) estimates that globally, IPv6 traffic will grow 16-fold from 2015 to 2020, a compound annual growth rate of 74%.
  • Finally, Segment Routing has made its way from lab demonstrations to real live implementations in major Service Providers' networks.

What does this all mean?

The proportion of Linear TV traffic to overall IP traffic is decreasing year over year. Consequently, the balance between the complexity inherent to Multicast protocols (states in the network) and the cost benefits (bandwidth savings) is broken!

SR-IPv6 enables a new paradigm! Get rid of multicast in the core of your network and maintain it where it makes the most sense -in the Access network.

See some details about this Use Case below:

The video server is unicasting linear TV content to each and every Access Node (be it a DSLAM, an OLT or a CMTS). There's absolutely no use of IPv6 Multicast in the core of the network.

From an IPv6 standpoint, packets streamed by the server have a unicast destination -the first segment on the path to the Access Node to which the video is unicasted -with the Segment Routing Extension Header containing the remaining segments and the multicast destination address. Once the video traffic hits the Access Node, it is treated as normal multicast traffic. That could seem rather simple but this is the unique combination of IPv6 and Segment Routing that makes this Use Case possible!

Service providers -particularly those that are far-along in their IPv6 deployments -are actively exploring the potential of IPv6 Segment Routing. Comcast was the first major ISP to deploy dual-stack IPv4/IPv6 connectivity throughout its network, and has discussed the potential for Segment Routing. Added Comcast Vice President of Network Strategy John Leddy: "We've only begun to scratch the surface of IPv6 as a tool for building smarter, more programmable networks. We're excited about the potential of IPv6 segment routing and working on several trials observe how it performs."

I find it eye-opening as this positions IPv6 as a programmable infrastructure well beyond the traditional -you're running out of IPv4 addresses, switch to IPv6 -mantra. This is the first blog from a series of blogs dedicated to IPv6 and Segment Routing. The upcoming ones will go deeper into the technology and the use cases as we've only scratched the surface here.

In the meantime, stay tuned and feel free to share on your preferred social media channels. Additional content you can get access to:

  • Yvette Kanouff's keynote at Cisco Live US 2016
  • Demo at Tech Field Day

tag-icon Tags quentes : IPv6 segment routing

Copyright © 2014-2024 Hi-Network.com | HAILIAN TECHNOLOGY CO., LIMITED | All Rights Reserved.
Our company's operations and information are independent of the manufacturers' positions, nor a part of any listed trademarks company.