Internet DRAFT - draft-gvenkat-sdn-dc-arch-arch
draft-gvenkat-sdn-dc-arch-arch
INTERNET-DRAFT G. Venkatasubramaniyan
Intended Status: INFORMATIONAL
Expires: 1, Jan 2013 1, June 2012
Problem Statement and Orthogonal control network for
managing data-centers draft-gvenkat-sdn-dc-arch-arch-00
Abstract
This draft describes a distributed Control Element for SDN
implementations. This document describes various complexities
associated with data-center management on adoption of new
technologies in data center networking. While Server vitalization,
cloud computing have very much increased the networking complexities
while OpenFlow/SDN gives a different perspective which could provide
solution. Network virtualisation is next thing in happening.
Traditional methods of managing each data-center element are
increasing management complexities. The key to reduce the management
complexity, and have automated infrastructure in very highly scaled
data center network is to have orthogonal management and control
network to the Data network. A distributed CE yet with a single
manager orchestrating the networks will give much needed intelligence
to OF controller.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
G. Venkatasubramaniyan Expires 2, Jan 2013 [Page 1]
INTERNET DRAFT draft-gvenkat-sdn-dc-arch-arch-00 3, June 2012
Copyright and License Notice
Copyright (c) <2012> IETF Trust and the persons identified as the
document authors. All rights reserved.
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Problem definition . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Server virtualization . . . . . . . . . . . . . . . . . . . 3
2.2 Cloud computing . . . . . . . . . . . . . . . . . . . . . . 4
2.3 SDN / OpenFlow . . . . . . . . . . . . . . . . . . . . . . . 4
2.5 Flattening of DC networks. . . . . . . . . . . . . . . . . . 5
2.4 Network Virtualization . . . . . . . . . . . . . . . . . . . 5
3 Unified data center architecture . . . . . . . . . . . . . . . . 6
3.1 comparison with Chassis based switches . . . . . . . . . . . 8
3.2 Comparison with ForCES . . . . . . . . . . . . . . . . . . . 8
3.3 Issues to consider . . . . . . . . . . . . . . . . . . . . . 8
3.3.1 External interface . . . . . . . . . . . . . . . . . . . 8
3.3.2 Algorithm consideration and scaling . . . . . . . . . . 8
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1 Normative References . . . . . . . . . . . . . . . . . . . 9
6.2 Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
G. Venkatasubramaniyan Expires 2, Jan 2013 [Page 2]
INTERNET DRAFT draft-gvenkat-sdn-dc-arch-arch-00 3, June 2012
1 Introduction
One of the major challenges in large enterprises is managing their
data centers. Evolving technologies had made managing more complex.
Following sections describes the problems and section 3 give a
possible architecture that would reduce the complexity
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2 Problem definition
2.1 Server virtualization
Server Virtualization provides an abstraction of all hardware
resource that System image interface with. Various technologies has
shaped the virtualization technology. Server virtualization allows
multiple instances of various OS/SI run simultaneously on a physical
server hardware. Hyper visor(VMM) is a software that enables multiple
VM share the physical infrastructure with HW assist. Hyper visors
implement Virtual Ethernet Bridges (VEB)/ virtual Switches. Each VM
contains at least one virtual NIC and which is associated with the
physical NIC by VEB. This kind of a virtual switch raises two kinds
of architectures.
1. Ethernet switching functionality with in the physical server with
following functionality of
a VM to VM switching happens internally with in the VEB and
forwarding from VM and/or Hyper visor to adjacent
L2 switch.
b. All of L2 functionality, VLAN. LAG/
c. Differs from traditional switches by not forwarding traffic
from adjacent L2 switch back to the adjacent switch
even through any other physical ports. Security policies
implemented in adjacent switches is not learned by the
virtual switch.
The problem with this kind of architecture is that the traffic
between the two VMs reside with in the physical server and require
additional control protocols for standard network policies - e.g.,
Security and QoS. [IEEE8021Qbg]. This standard also defines channels
for segregation of traffic.
2. The Hyper visor, instead of implementing its own virtual switch
G. Venkatasubramaniyan Expires 2, Jan 2013 [Page 3]
INTERNET DRAFT draft-gvenkat-sdn-dc-arch-arch-00 3, June 2012
cooperatively work for switching traffic with the adjacent L2 switch.
a. VM to VM switching happens through adjacent L2 switch
b. VM and / or Hyper-visor adjacent L2 switch
c. All of L2 functionality, VLAN. LAG/
d. Differs from traditional switches by not forwarding
traffic from adjacent L2 switch back to the adjacent
switch even through any other physical ports. Security
policies implemented in adjacent switches
[IEEE8021BR, 8021Qay].
The complexity in management of Networked VM requires more involved
protocol exchange because of the blur in the demarcation of network
and the computing resource. Really, a becoming of "Network is
computer".
2.2 Cloud computing
The goal of cloud computing is to enable IT organizations to achieve
a dramatic improvement in the cost effective, elastic provisioning of
IT services. Cloud computing is Service or Infrastructure made
available on and through Internet, on demand, which can scale on
demand and migrate when there is a need[GAUTAM-SHROFF]. These
features has transformed Cap-ex intensive Compute, network and
Storage resources into cost effective utility services.
These properties constraint the data center and imposes dynamic
configuration changes on the data center as the infrastructure usage
grows. Migrations need impose the address schema's to be retained.
Dynamic bringing up and closing of App's, dynamic provisioning of
storage and connecting, tearing or scaling of connections though WWW
makes configuration of NE in silos difficult. These requirement
requires to data center be configured and managed as one single
unified unit rather than the connected nodes of switches and nodes.
Present architecture visualizes data center not as whole one unit but
as component made out of individual switches, routers and servers.
This requires configuration of individual elements and this results
in the need of control protocols. Traditional method of configuration
would require Complex checkpoint, commit or rollback methodologies
for end-to-end provisioning in a data center.
2.3 SDN / OpenFlow
The traditional network element, viz., switches and routers can be
modularized to three major components based on the function they
perform.
G. Venkatasubramaniyan Expires 2, Jan 2013 [Page 4]
INTERNET DRAFT draft-gvenkat-sdn-dc-arch-arch-00 3, June 2012
ME - Management element. This module interact with management user
for configuration data of the network resources. These data might
under go changes due to control protocol rules and finally affects
the Forwarding decision of FE.e.g., System Priority.
CE- Control element, These influence the forwarding decisions of FE.
The major function are Neighbor discovery, Topology discovery, QoS
parameter negotiations and Flow control, etc. These traffic are not
use data but results of the algorithmic computation of these protocol
data facilitate the user data communication. Each NE has a CE which
generate control traffic. Each CE talk to the rest of the CEs or
directly connected CE through various protocols for arriving in
control data.
FE - Forwarding element. Based on the configuration and control
element learning, this element chooses the best path to forward the
traffic for the packet to reach the destination.
ForCES framework [RFC3656] and OpenFlow standards provides clear
separation of Forwarding (FE) and Controlling (CE) entities allowing
them to reside in different compute nodes in a network. This
separation resulted in definition of protocols [RFC5810], [OPENFLOW]
to configure forwarding tables in the Network element. But still
these advances does not allow the to be seen as a single unit for
provisioning.
OpenFlow defines (1) OpenFlow channel which carries the OpenFlow
protocol messages, (2) OpenFlow switch which implements the Flow
Tables and Action lists and (3) the controller. The OpenFlow channel
is independent and orthogonal to the Data network and is used to
configure the data flows. Since its is separate from the data
network, controller is devoid of the dynamics of the data network and
inhibits it in from dynamic control.
2.5 Flattening of DC networks.
A three-tier network architecture is the dominant structure in as the
standard design for DCs. The three tiers are access, Aggregation and
Core layers in the hierarchy. Access switches Top-of-Rack (ToR)
switches, or modular/End-of-Row (EoR) switches that connect servers
and IP/Ethernet based storage to aggregation switches. Traditionally,
DC are designed for higher North-South (client - server) traffic.
Virtualization disrupts these assumptions and requires the network be
flat. [
2.4 Network Virtualization
After Storage and Compute resource (server) virtualization, the need
G. Venkatasubramaniyan Expires 2, Jan 2013 [Page 5]
INTERNET DRAFT draft-gvenkat-sdn-dc-arch-arch-00 3, June 2012
for virtualizing of network is being felt[INET-VIR]. Though VLANS and
tunnels could be considers as virtual networks, the dynamics and
scale data-centers impose, requires fresh thinking[OVERLAY1,
OVERLAY2].
3 Unified data center architecture
Blade based unified "data-center in a box" solutions are available in
the market as off-the-rack products, but for the system integrators
who wish of build, there seems to be lack of standards to unify the
three essentials of data-center, storage. network and compute. These
three does not reside alone in data-center, usually requiring these
three resources or at-the-least two of them.
This document proposes an independent management and control network
which would be orthogonal to the data network. This type of
orthogonal network separate for control and configuration of data
network is not new. TMN architecture in Telecommunication network is
a similar kind of architecture. [TMN]
----------------------------------------------------------------
OF controller | Network controller | Network manager
---------------------------+-----------------------------------
+---+--+---------------+---------+---- + ----+
| | | |
| | | |
-----|-SW2*****************SW4-----|----------------
-----|--*--*--*------------------------*---*-*--|-*-----------
------|*----*-------*----------------*--------*---|---*-------
----*-|*---*------------*--------*------------*----|-----*-----
--*---|----*-----------------*------------------*----|------*----
SS1--|----*--------------*----*----------------*----|------SR6------
-------*-|---*------------*-----------*-----------*---|----*-----
---------*|--*-----------------------------*-------*--|---*------
-----------*|-*-------*------------------------*---*-|--*----------
-------------*|-*---*-------------------------------*|-*-------
--------------SW3*************************SW5-->>ISP>>---
--------------------------------------------------------------------
DATA NETWORK -PLANE
virtual switch in Server and storage communicate with
Network controller through the neighbor switch. All switches
are managed and controlled centrally through independent
network.
--------------------------------------------------------------------
G. Venkatasubramaniyan Expires 2, Jan 2013 [Page 6]
INTERNET DRAFT draft-gvenkat-sdn-dc-arch-arch-00 3, June 2012
The Control and Management Network (CMNw) is independent and
orthogonal to the data traffic. It would specifically carry the
control, management traffic and OF Messages. This would be a
carefully laid loop free, non Hierarchical would be in a private
address space. The management of individual NEs must happen through
SNMP/ NETCONF or standard CLI from centralized management module.
Provisioning of Server, network and Storage happen from centralized
manager application.
Control Plane functions that are that are processed in
switches/routers at superficially
1. Topology discovery
2. Event or notification of a state change to peer at the layer
of operation.
3. Exchange of parameters or configuration values
4. Handling of Un handled packets in FE
The following table gives various functions handled in control plane
and corresponding protocols in
Layer -2
S.No Function | Protocols
------+-------------------------------+------------------------------
1 Topology/path, | XSTP & VLAN , TRILL,
and neighbor | 802.1Qbp, 802.1ax,
discovery | LLDP/ 802.1AB
2 Parameter negotiations | LLDP
3 Signaling, Fault | 802.1Qbb, 802.1ag,
management | 802.1Qau,
4 ARP | ARP
------+--------------------------------+-----------------------------
Layer -3
S.No Function | Protocols
------+-------------------------------+------------------------------
1 Topology/path, | OSPF, IS-IS
and neighbor |
discovery |
2 Parameter negotiations | LLDP
3 Signaling, Fault | RSVP, ICMP,
management |
4 |
------+--------------------------------+-----------------------------
Some of the functions of present CE functions would become a non-
requirement by this control and management work. And Path/Topology
discovery become less intense as states and configurations become
G. Venkatasubramaniyan Expires 2, Jan 2013 [Page 7]
INTERNET DRAFT draft-gvenkat-sdn-dc-arch-arch-00 3, June 2012
globally available.
Path discovery is step process usually implemented as state machines,
involving port or link states or elections bases on priorities
assigned. Briefly, the present implementations work the following
way.
1. Exchange of protocol message between peer ports with
priorities, cost, etc identification, re computation
notification and confirming changes
2. Algorithmic computation of best paths, distribution trees.
For example, each node its own view of shortest paths
3. Program the FE's Forwarding tables, based on step 2.
In unified framework,
1. Link existence. Since port or node failure would be available
through Control Network, the protocol exchange would be less
intense.
2. Algorithmic computation of best paths for all pairs of
vertices [CORMEN, FLOYD]
3. Program all FE's Forwarding tables, based on step 2, which
would be OF messages. For L2 this would be distribution trees
for which protocols needs to be specified.
The traditional network element, viz., switches and routers can be
modularized to three major components based on the function they
perform.
3.1 comparison with Chassis based switches
3.2 Comparison with ForCES
3.3 Issues to consider
3.3.1 External interface
3.3.2 Algorithm consideration and scaling
G. Venkatasubramaniyan Expires 2, Jan 2013 [Page 8]
INTERNET DRAFT draft-gvenkat-sdn-dc-arch-arch-00 3, June 2012
4 Security Considerations
<Security considerations text>
5 IANA Considerations
<IANA considerations text>
6 References
6.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April
1 1995.
[TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925,
April 1 1996.
6.2 Informative References
[EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, April 1 2003.
[RFC5513] Farrel, A., "IANA Considerations for Three Letter
Acronyms", RFC 5513, April 1 2009.
[RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, April 1
2009.
[XEN] Xen and the art of virtualization, Proceeding SOSP '03
Proceedings of the nineteenth ACM symposium on Operating
systems principles Pages 164-177
[SMITH-NAIR]James E. Smith, Ravi Nair, "Virtual machines - versatile
platforms for systems and process,
[IEEE8021BR] IEEE 802.1BR Bridge port extension
http://www.ieee802.org/1/pages/802.1br.html
[IEEE8021bg] IEEE 802.1Qbg Edge Virtual Bridging
http://www.ieee802.org/1/pages/802.1bg.html
[8021Qay] IEEE 802.1Qay - Provider Backbone Bridge Traffic
G. Venkatasubramaniyan Expires 2, Jan 2013 [Page 9]
INTERNET DRAFT draft-gvenkat-sdn-dc-arch-arch-00 3, June 2012
Engineering, http://www.ieee802.org/1/pages/802.1ay.html
[GAUTAM-SHROFF] "Enterprise Cloud Computing: Technology,
Architecture, Applications", Gautam Shroff, Cambridge
University Press.
[I-D.nadeau-sdn-problem-statement] Nadeau, T., and P. Pan, " Software
Defined Network (SDN) Problem Statement", draft-nadeau-
sdn-problem-statement-00 (work in progress), September
2011.
[NET-VIR] "Network virtualization: a hypervisor for the Internet?"
Vol 50(1) Khan, A.; Zugenmaier, A. ; Jurca, D. ;
Kellerer, W. IEEE Communications Magazine
[FLATNW] Greg Scherer, 2012- Ethernet
Summit,http://www.ethernetsummit.com/English/Collaterals
/Proceedings/2012/20120222_Keynote4_Scherer.pdf
[OVERLAY1] M-K. Shin, K-H. Nam, J.Choi, Korea U., "Formally
Verifiable Networking Framework for SDN draft-shin-sdn-
formal-specification-00", draft-shin-sdn-formal-
specification-00 (work in progress), March 1, 2012
[OVERLAY2] M-K. Shin, K-H. Nam, J.Choi, Korea U., "Analysis of
Comparisons between OpenFlow and ForCES draft-wang-forces-
compare-openflow-forces-01.txt", draft-wang-forces-
compare-openflow-forces-01 (work in progress), March 11,
2012
[TMN] Telecommunications management network. PRINCIPLES FOR A
TELECOMMUNICATIONS. MANAGEMENT NETWORK. ITU-T
Recommendation M.3010, May 1996.
[CORMEN] Cormen, Thomas H.; Leiserson, Charles E., Rivest, Ronald L.
(1990). Introduction to Algorithms (1st ed.). MIT Press
and McGraw-Hill. ISBN 0-262-03141-8. Section 26.2, "The
Floyd-Warshall algorithm", pp. 558-565;
[FLOYD] Floyd, Robert W. (June 1962). "Algorithm 97: Shortest Path".
Communications of the ACM 5 (6): 345.
Authors' Addresses
G. Venkatasubramaniyan
EMail: g.venkatasubramaniyan@gmail.com
G. Venkatasubramaniyan Expires 2, Jan 2013 [Page 10]
INTERNET DRAFT draft-gvenkat-sdn-dc-arch-arch-00 3, June 2012
G. Venkatasubramaniyan Expires 2, Jan 2013 [Page 11]
