Content in Intel Communities

SDN Use Case: Network Service Deployment

webadmin@intel.com — Mon, 03 Jun 2013 16:44:37 GMT

It can be argued that there’s never been a time when innovation was needed more in data center networks.

The increased reliance on information served up from cloud or enterprise data centers has made it vital to bring new security, performance management, privacy, traffic segregation, service-level agreement and revenue generation applications to the network.

Software-defined networking (SDN) and the Intel® Open Network Platform (ONP) help to open the network to this innovation, which brings us to the last in a series of blog posts about SDN use cases. This one focuses on the way this new network paradigm helps to simplify network application / service deployment.

SDN’s primary innovation is that it separates a network’s control plane from its data plane in order to centralize packet processing in a software controller. That makes it easier to deploy network-wide policies or services because the controller has a comprehensive perspective on data flows, including congestion information, QoS, security etcetera.

Logically, the SDN controller sits above the infrastructure layer, but below an application layer with standardized APIs that allow easy integration of business applications.

Thus, applications that used to require standalone hardware and could only see the traffic passing through them, can now be run on a server and can manage an entire network using information available from the controller.

It's the disaggregation of the network into these logical layers that makes this possible. Intel has taken that concept one step further with its Open Network Platform announcement, which opens up key elements at each layer so that any OEM can leverage this infrastructure in the development of an SDN application. Take a look at www.intel.com/onp to get more information about ONP.

Applications bring added user features to a network, but also impact the manageability and performance of the network. SDN lays the foundation for companies like Intel to open up the network for this innovation.

Interop 2013: In Las Vegas, SDN is Not the Center of the Universe

webadmin@intel.com — Mon, 03 Jun 2013 16:13:07 GMT

In recent months, I’ve been to several events where software-defined networking has been the main topic of discussion. Now that I think about it, all of those events have been in the Silicon Valley, the epicenter of SDN.

Recently, I left that bubble to go to Interop in Las Vegas - and I’m finding that SDN is a big deal but it’s not the only thing going on in networking.

Of course, I talked about SDN because I’m focused that way. But the overall show was about all of the topics that networking managers are concerned with like application intelligence, staffing, cloud vendor selection and how to kill Spanning Tree. In fact, my recent search of the Interop site for the acronym SDN turned up only 19 references.

Why is this important? While there is a huge amount of fire behind SDN in certain circles, the market at large has only a passing acquaintance with the technology. I felt that Interop was a great opportunity for me to educate the wider audience on the benefits of the technology.

I took advantage of that opportunity by giving an overview of SDN technology and why it’s important and then discussing the Intel solution in a bit more detail. This includes top-of-rack switch reference design called the Open Network Platform, the software elements and open APIs we have for OEMs dubbed Open Network Software and finally the Intel Ethernet Switch FM6000 series, the low-latency 10G/40G switch IC that is at the heart of the entire solution.

With this solution, we want to unleash the power of SDN for data center networking. One key step is education and that’s why the presentation at Interop was important.

Intel® 82574L Gigabit Ethernet Controller Statement

webadmin@intel.com — Fri, 08 Feb 2013 02:41:02 GMT

Recently there were a few stories published, based on a blog post by an end-user, suggesting specific network packets may cause the Intel® 82574L Gigabit Ethernet Controller to become unresponsive until corrected by a full platform power cycle.

Intel was made aware of this issue in September 2012 by the blogs author. Intel worked with the author as well as the original motherboard manufacturer to investigate and determine root cause. Intel root caused the issue to the specific vendor’s mother board design where an incorrect EEPROM image was programmed during manufacturing. We communicated the findings and recommended corrections to the motherboard manufacturer.

It is Intel’s belief that this is an implementation issue isolated to a specific manufacturer, not a design problem with the Intel 82574L Gigabit Ethernet controller. Intel has not observed this issue with any implementations which follow Intel’s published design guidelines. Intel recommends contacting your motherboard manufacturer if you have continued concerns or questions whether your products are impacted.

Update from IDF Beijing: The Value of SDN With 1.3B Potential Users

webadmin@intel.com — Tue, 23 Apr 2013 18:48:20 GMT

The Intel® Development Forum in Beijing took place two weeks ago and the interest in my two SDN-related presentations was very high.

My poster chat drew about 40 or so people who stopped by in groups of 6-8 to hear the high-level overview to the Intel SDN story. The attendance more than doubled for my conference session, where I went a bit deeper into Intel’s new data center and telecom network transformation initiative – giving a preview of the three product announcements made at the Open Networking Summit.

One challenge that is unique to China is scaling new web services for a potential market of 1.3 billion people – almost four times that of the U.S. There were a lot of questions on this topic from top service providers, which I took to indicate that scaling is very important.

The other difference I noticed is that with less of a legacy network infrastructure than in the U.S., Chinese network managers are very open to trying new things to get the scalability and performance they need to deliver great service levels.

One key element of my presentation was a deep dive into why new networking platforms, like ONP introduced at ONS, are so necessary to advance the state of the art of SDN, and to providing ease of scaling in these high performance data centers.

As the server virtualization trend expanded into network virtualization, building high-performance, low-latency networks became much more complex for enterprises and data center operators. New IP protocols like TRILL helped, but maintaining server/network coherency became very labor intensive.

To network managers dealing with this challenge, the SDN promise of separating the network control plan into a central network controller architecture was an immediate solution to a nagging problem. And, first-generation networking products delivered on this promise by layering SDN onto existing switches.

But the promise of SDN is much bigger than that; it’s nothing short of opening networks to a wave of innovation around new software functionality along with additional network cost-per-bit reductions. That’s the total story that ONP delivers on.

The potential of SDN for network innovation mirrors the transition from proprietary mini computer to the PC, which spawned countless innovations thanks to its combination of standard processors and operating systems and value-added applications.

In the network version of this story, enterprises evolve from vertically integrated networking platforms that are closed and slow to innovate, to a more open system with standardized switch silicon that has an open API to the control plane (or control planes for specialized applications). These control planes then communicate through another API with apps running on a virtual server.

This means that a network that had to be architected around special appliances to do packet inspection or provide security can now have those applications running on a high-performance server. The global controller will know what packets need to be processed by that application and will direct them to the application before forwarding them to their destination.

This architecture breaks down many of the barriers to entry in this market. For new players, all they need are their software skills to develop their application. They can sell it into any network that supports the open API – regardless of the manufacturer. On the other side of the coin, an existing software company can use standard hardware to easily develop its own complete solution, speeding time to market.

For every company that needs to scale quickly and keep network costs and complexity low – especially in fast growing economies like China – this is really good news.

ONS Recap: “Changing the Way We Think And Act”

webadmin@intel.com — Fri, 19 Apr 2013 01:34:59 GMT

“An inflection point is an event that changes the way we think and act.”

With this quote from Andy Grove in her keynote speech, Rose Schooler, VP of Intel Architecture Group and GM of Intel's Communications and Storage Infrastructure Group, launched the next phase of Intel’s SDN-based data center and telecom network transformation initiative at the Open Networking Summit this week.

The speech capped a great show for me and for the Intel Communications and Storage Infrastructure Group. Our goal going into the event was to help the industry see how to get the full value out of the open networking paradigm shift.

In just under an hour, Rose accomplished that by providing an overview of our datacenter and telecom network strategies, introduced three new products and let partner VMWare and customer Verizon demonstrate how they are using products from Intel.

Here’s a summary of the key products that were launched at the show (you can read more in our press release):

Intel® Open Network Platform Switch Reference Design: You’ve read about “Seacliff Trail” in this blog before. What’s new is a tight integration with Wind River Open Network Software and a customizable software stack using Wind River Linux. Seacliff Trail is now the ideal reference design for OEMs, offering a combination of customizable software and fast, low latency merchant silicon for next-generation SDN data center networking systems.

Intel® Data Plane Development Kit Accelerated Open vSwitch: With this project, Intel wants to help Open vSwitch developers speed up performance of small packets. The bulk of the packets in virtual machine networking applications are 64 Kbytes, and with the accelerated Open vSwitch we’re able to boost small-packet port-to-port performance by 10 times and accelerate virtual machine-to-virtual machine performance by five times.

Intel® Open Network Platform Server Reference Design: This innovative virtual network server reference design called “Sunrise Trail” will allow OEMs to create virtual appliances on standard Intel-architecture servers. The reference design combines the DPDK Open vSwitch, support for SDN and NFV standards along with the Intel® Xeon® processor, Intel 82599 Ethernet Controller and Intel Communications Chipset 89xx series. More to come on this new reference design as the first alpha units are due later this year.

Rose closed her speech with another Andy Grove maxim about inflection points – that they reflect a change in customer’s values and preferences.

As you can see from these significant new products, Intel is moving fast to be in a good position to address these customer value and preference changes.

Intel’s SDN Vision on Display at Open Networking Summit 2013

webadmin@intel.com — Tue, 16 Apr 2013 17:52:26 GMT

Last year Intel® participated in its first demonstration of software-defined networking (SDN) at the Open Network Summit. This year we’re coming back to the show with an expanded SDN product strategy and a new Open Networking Platform that will open up the entire SDN value chain for data centers.

The show opened yesterday in the Santa Clara Convention Center with a full day of tutorials and then an evening reception amongst the exhibits. The program starts today and runs through Wednesday.

Last year, we said that the SDN revolution “starts at the switch.” This year, we’re bringing together the other elements of an SDN solution that will enable customers to dramatically boost the fabric performance in virtualized data center environments.

Starting on Monday, I’ll be staffing the booth at the show to demonstrate our SDN solution. In addition, our Seacliff Trail 48-port 10GE top-of-rack switch will be in a multivendor demonstration of NEC’s Programmable Flow Controller.

On Wednesday, Rose Schooler, Vice President of the Intel Architecture Group and General Manager of the Communications and Storage Infrastructure Group, will make a keynote presentation that will cover key aspects of our Open Network Platform. She will announce some new components of the platform and talk about the customer need it meets.

If you are not going to the show, but would like to hear Rose speak, you can watch the live webcast of her presentation.

The world of open networking moves fast. The progress we’ve shown since ONS 2012 shows that Intel is keeping pace. Check back for more blog updates later this week.

SDN Use Cases: Virtual Network Appliances

webadmin@intel.com — Wed, 10 Apr 2013 16:09:45 GMT

We started our blog series on software defined networking (SDN) use cases by looking at how SDN might enable network virtualization (http://communities.intel.com/community/wired/blog/2013/03/01/sdn-use-cases-network-virtualization). We continue on a somewhat similar application by looking at SDN and virtual network appliances.

Many networks utilize specialized appliances, such as firewalls, load balancers, WAN accelerators and others, to provide specialized network packet processing and functionality.

Many of these are now being turned into virtual appliances. The term “virtual appliance” was coined to describe a self-contained virtual machine powered by an operating system that had a pre-configured application on top.

In the enterprise data center, one of the challenges of the virtual network appliance is that it often needs to be in the data path – either before the router, in the case of a firewall, or before a server, in the case of a load balancer.

SDN replaces IP routing functionality on each switch with a network controller that can see all data and resources on the network and directs data flows. With this global view, it can redirect data packets to virtual network appliances directly. In essence, it creates a data path for each data flow in order to direct it to the right virtual appliance.

This is also important in cloud applications where multi-tenant virtual servers may need dramatically different resources and where virtual data paths complicate the sharing of virtual appliances.

The network flow flexibility that SDN brings to datacenter and cloud networks makes virtual network appliances an even more viable and cost-effective way to deliver the network processing needed for secure and high-performance networks.

Intel® 82574 Gigabit Ethernet Controller Design Success Tips

webadmin@intel.com — Wed, 13 Feb 2013 23:09:34 GMT

For those that are manufacturing their own Intel® 82574 Gigabit Ethernet Controller based hardware implementations, a key step in creating a valid configuration is selecting the correct image based on the size of the EEPROM and desired functionality. If the device will attached to a BMC via SMBus or NC-SI, a 32Kb EEPROM (or greater) must be used. If not, the No-Management image should be used. Note in table 25 in the 82574 datasheet outlines minimum sizes for those two features sets. If for some reason you want to use the Management image on a system without a BMC, make sure the design has the NC-SI/SMBus pins properly dealt with. Putting a Management image (which requires size 32Kb EEPROM) in a No-Management size EEPROM (<32Kb EEPROM size) is not a supported configuration and will cause the 82574 to have non-deterministic and/or erratic behavior. It’s like going past the end of an array, you end up in the weeds and who knows what data is now being pointed to. Data that will be used because it thinks it’s okay. Just to put these sizes into context, a 1Kb EEPROM is just 64 words. An image that small you can tell by just looking at a dump of it. 1Kb fits onto a small screen, a 32Kb image will go on for a page or three.

All an OEM has to do is use the correct image (No-Management/Management) or use the correct size EEPROM to have a valid and supported configuration. Unless the management functionality is required, the Non-management image should be used.

Here is table from the datasheet for easy reference. Here is the datasheet (http://www.intel.com/content/www/us/en/ethernet-controllers/82574l-gbe-controller-datasheet.html?wapkw=82574+datasheet). Remember the datasheet is always right, the blog is always wrong if they disagree.

You can tell if it is a management image or not by looking at Word 0x0F in the EEPROM. Here is another snippet from the datasheet:

Now be careful, the EEPROM is dumped in Linux in BYTEs and the manuals are WORDS. So in Linux the 0x0010 line, the last two bytes make the word 0x0F, with byte swapping, the last byte of the0x0010 line is the high byte of the word. This is a non-management image:

Here is a management image:

Yes, I have put a LOT of NICs in my poor system. Your eth number will vary.

So the question to ask is 1) what size is the EEPROM attached to my 82574? Then 2) What image is in it? If the first answer is 32Kb or bigger, the second is not required. If the first is <32Kb then the second is in play. The HW vendor should know how to tell them apart.

As always thanks for using Intel Ethernet.

Preview of My SDN Poster Chat at IDF Beijing

webadmin@intel.com — Tue, 02 Apr 2013 18:26:20 GMT

Later this week, I’ll board a 13-hour flight from Los Angeles to Beijing to take part in the Intel® Developer Forum on April 10-11.

If you are going to the event and are interested in what Intel is doing in the data center and connected systems market, I recommend that you first go hear our General Manager Diane Bryant give her keynote talk about the future of our business, on April 10 between 9 and 11:00am.

Then, you can hear me talk at two times during the conference: at my Poster Chat on April 10 at 2pm, and at my April 11 session presentation at 3:45pm (where I will pair up with Shashi Gowda of our Wind River Systems division).

In both talks, I’m going to be sharing how Intel sees the future of the software defined network (SDN) market and what product plans are in place to help OEMs participating in this market.

In this blog post, I’ll touch on my poster chat, and next week, I’ll provide an overview of the session presentation. If you’ve never been to a poster chat, it is exactly what the words say – I have created a large poster and I describe it and answer any questions that come up.

My poster for IDF Beijing covers the following topics:

The evolution from traditional IP networks to SDN networks and the advantages that come from that.
A description of the Intel Ethernet Switch FM6000 functionality. Here I will talk about how we get low latency and discuss our Seacliff Trail 48-port 10GB/40GB Ethernet switch reference design.
From there, I’ll go into a discussion of our software architecture that starts with APIs to open the FM6000 to SDN controllers, and contains the operating system and other software components necessary to fully implement SDN switching.
Then, I want to dig deeply into our FlexPipe frame forwarding architecture, which is built with advanced frame header processing that makes it flexible for an evolving standard like SDN.

It’s a lot to talk about in an hour, but I’m looking forward to providing a high-level overview that I can then explore further in my workshop. More on that next week.

Increase Your BMC Network Performance by Over 800%!

webadmin@intel.com — Fri, 29 Mar 2013 16:54:42 GMT

Increase Your BMC Network Performance by Over 800%!

Your friendly neighborhood manageability nerd here announcing my latest whitepaper.

The NC-SI (Network Controller Sideband Interface) is a connection between a Network Controller and a BMC. This DMTF defined interface is designed to provide 100Mbps full duplex connectivity to a BMC.

Over a year ago I began researching why I was having customers were complaining to me that the NC-SI performance under some circumstances was horrible, in most reports only a few megabits per second.

After literally hundreds of tests and countless hours of research and tweaking of different things, I began to understand what the problem was and how to go about providing a solution.
Figure 1 Network Performance Streaming to BMC

What I found was that the NC-SI interface worked exactly as it was supposed to, however the BMC itself needs to take into account that it is using NC-SI and that NC-SI does not have as much buffer space as the BMC itself has.

I tested with not only Intel Network Controllers, but also another well-known manufacturer of Network Controllers. The results were pretty much identical, very poor performance until I modified the BMC to be a bit more intelligent.

Making changes detailed in the whitepaper, average performance when streaming data to the BMC went from less than 8Mbps to nearly 65Mbps. The performance would be even better, however a BMC is not a super-powerful processor and it can’t yet handle 100MBps data rates.

All my research, conclusions and actual sample data is included within the whitepaper. I also provided an overview of what NC-SI is for the uninitiated.

I hope you find it of use. If you do please comment so we know if folks actually read these docs .

The paper is available here: https://www-ssl.intel.com/content/www/us/en/ethernet-controllers/nc-si-overview-and-performance-notes.html