By Andrew Yourtchenko, Technical Leader, Network Operations Systems Technology Group
As any geek, I find it a lot of fun to get some hands with the new technology -- be it a new gadget, new product or a solution.
It’s not very often that I have a chance to play with a whole new protocol. EANTC (European Advanced Network Testing Center) interoperability testing gave me such a chance. The bulk of the work happened on EANTC premises in Germany this past February. The overall activity involved many representatives from various vendors making their devices talk to each other. The goal is to test the protocols in several areas, including MPLS, SDN, and IPv6, but the highlight for me was the testing of MAP (Mapping Address and Port) -- a new protocol to enable the sharing of IPv4 addresses by several customer premise devices without keeping the state at the service provider end.
This protocol is being developed by IETF, and has two flavours, the standards-track “MAP” which uses encapsulation to transmit the packets, otherwise known also as MAP, and the experimental track “MAP-T” -- which uses the address family translation in order to send packets, instead of the encapsulation. Read More »
Tags: asr 9000, asr9k, ipv4, IPv6, Service Provider
For me, even though I am mostly a hardware geek, one of the coolest parts of the Cisco ONE launch at CiscoLive was the introduction of onePK. We see onePK as an core enabling technology that will have some cool stuff down the road.
So, one of the more common questions I get is about the relationship between onePK and other technologies related to network programmability such as OpenFlow (OF). Many folks mistakenly view this as an either/or choice. To be honest, when I first heard about onePK, I thought it was OpenFlow on steroids too; however, I had some fine folks from NOSTG educate me on the difference between the two. They are, in fact, complementary and for many customer scenarios, we expect them to be used in concert. Take a look at the pic below, which shows how these technologies map against the multi-layer model we introduced with Cisco ONE:
As you can see, onePK gives developers comprehensive, granular programmatic access to Cisco infrastructure through a broad set of APIs. One the other hand, protocols such as OpenFlow concern themselves with communications and control amongst the different layers—in OpenFlow’s case, between the control plane and the forwarding plane. Some folks have referred to onePK as a “northbound” interface and protocols such as OpenFlow as “southbound” interfaces. While that might be helpful to understand the difference between the two technologies, I don’t think that this is a strictly accurate description. For one thing, developers can use onePK to directly interact with the hardware. Second, our support for other protocols such as OpenFlow is delivered through agents that are built using onePK.
That last part, about the agent support is actually pretty cool. We can create agents to provide support for whatever new protocols come down the pike by building them upon onePK. This allows flexibility and future-proofing while still maintaining a common underlying infrastructure for consistency and coherency.
For instance, we are delivering our experimental OF support by building it atop the onePK infrastructure. For customers this is a key point, they are not locked into a single approach—they can concurrently use native onePK access, protocol-based access, or traditional access (aka run in hybrid mode) as their needs dictate. Because we are building agents atop onePK, you don’t have to forgo any of the sophistication of the underlying infrastructure. For example, with the forthcoming agent for the ASR9K, we expect to have industry leading performance because of the level of integration between the OF agents and the underlying hardware made possible by onePK.
In closing, you can see how extensible our programmatic support is with the ability to use onePK natively or to support technologies and protocols as they are developed and released. This gives customers a remarkable level of flexibility, extensibility and risk mitigation.
Tags: ASIC, asr9k, ciscolive, netconf, onePK, OpenFlow, SDN
Data Center Connections using “nV edge”
The ASR 9000 product family has recently come out with a new feature called nV Edge (nV = Network Virtualization). This feature unifies the data center edge control, data and management planes. So, I’ll note a couple things here on this feature and then tell you why I think it has potential to be truly awesome.
My good friend Rabiul Hasan just wrote a proof of concept document just posted to Design Zone that provides the configuration and setup details. I encourage you to go check it out here.
Read More »
Tags: asr 9000, asr9k, Data Center Interconnect, DCI, nV, nV Edge, VPLS
The Global Certification Team is pleased to announce that we have achieved Common Criteria certification on the CRS 1-3 and the ASR 9K!
Link to the certification: http://www.niap-ccevs.org/st/vid10439/
Read More »
Tags: 9006, 9010, asr, asr9k, certification, Common, Common Criteria, criteria, crs1, crs1-3, CRS3, evaluation