Virtualizing the Edge

Mar 18, 2013 by Prayson Pate

In a previous blog entry I discussed some of the technology enablers that led to the success of the cloud, and how they could be applied to other domains such as the metro edge portion of the network.  One key enabler is the use of virtualization and Virtual Machines (VMs) to build the infrastructure of the cloud, which leads to the question, “Can virtualization be applied to the metro edge of the network?” Before digging in further, let’s step back and understand some of the key points of virtualization: abstraction and separation/layering.

 

 

Abstraction - Hide the Differences That Don’t Matter, and Magnify the Differences That do Matter

According to Wikipedia, “Abstractions may be formed by reducing the information content of a concept or an observable phenomenon, typically to retain only information which is relevant for a particular purpose.” The metro edge part of the network is a zoo, with a plethora of spurious information that can only cause trouble, including:

  • Device vendor
  • Network uplink
  • User interface

Abstraction is useful because it can hide these irrelevant differences to make life easier for the service provider, so they can focus on the differences (AKA information) that do matter:

  • Available bandwidth
  • Underutilized resources
  • Physical adjacency

These aspects are important and relevant in that they can be used to optimize the delivery of services to the end user.

Separation and Layering - Centralize for Control and Economies of Scale, and Distribute for Cost, Scalability, and Resilience

Another key aspect of virtualization is the notion of layering to allow a well-defined interface, which can then be used to separate functions.  Separation lets us move functions to where they make the most sense.

Candidates for centralization include:

  • Control: Aspects that need global knowledge, such as path selection
  • Programmatic: Functions that may need to be programmed and pooled, such as security policies or performance data
  • Dynamic: Functions that are likely to change, such as packet handling for network functions like routing or VPNs

Functions that are best distributed include:

  • Resilience: Aspects that need to be protected, such as storage
  • Scalability: Functions that require resources proportional to size, such as flow-based packet handling
  • Cost: Features that are mostly static, such as basic layer 2 learning/flooding

The Metro Edge isn’t the Data Center

As opposed to the data center, there are limits to how the principles of virtualization can be applied to the metro edge of the network.

In particular, the data center has a number of characteristics that make it suitable for the principles of virtualization:

  • Homogeneous – all of the servers (X86, VmWare, Linux/Windows) and storage arrays are very similar, with few differences to hide
  • Geographically co-located – co-location makes VM mobility a reality
  • Bandwidth is very cheap – distributing compute and storage resources in a data center is easy when high bandwidth and low latency are the rule
 

In contrast, the metro edge of the network is different in all of these categories:

  • Heterogeneous – a wide array of equipment with different capabilities is deployed
  • Geographically dispersed – No assumption of adjacency can help with the optimal use of resources
  • Bandwidth is expensive – VM mobility over a 1 Mbps access link is not practical

Data Center

 

Metro Edge

So, What can we Virtualize?

The Metro Ethernet Forum has identified a simple case where virtualization would be beneficial and is within reach: the virtual NID (Network Interface Device) service, referred to as vNID service.

Today, when one service provider accesses a customer via Carrier Ethernet using the facilities of a second access provider, it is likely that both providers deploy a NID.  With the vNID service concept only the access provider would deploy a NID, and the end-to-end service provider would access aspects of the NID as if they had their own NID.  Doing so reduces the capital expense of deploying an Ethernet service without giving up the service assurance needed by the end user.

 

Other Blogs in this Series

About the Author

Prayson co-founded Overture and brings more than 24 years of experience developing software and hardware for networking products to the Company. He began his career in 1983 at FiberLAN, moved to Bell Northern Research (Nortel) and joined Larscom in 1992. He has extensive hardware/software design and management experience, and served as Director of Engineering at Larscom before co-founding Overture. Prayson is active in standards bodies such as the MEF and IETF, and he was chosen to be the co-editor of the pseudowire emulation edge-to-edge (PWE3) requirements and architecture documents (RFCs 3916 and 3985). Prayson holds a BS in electrical engineering and computer science from Duke University and an MS in electrical and computer engineering from North Carolina State University. He holds nine patents.
 
Follow Prayson on twitter: @praysonpate

Comments

Post new comment

The content of this field is kept private and will not be shown publicly.
By submitting this form, you accept the Mollom privacy policy.
To prevent automated spam submissions leave this field empty.