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 5 IANA Considerations 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]