* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Cross Stratum Optimization
Survey
Document related concepts
Remote Desktop Services wikipedia , lookup
Computer network wikipedia , lookup
Distributed firewall wikipedia , lookup
Deep packet inspection wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Network tap wikipedia , lookup
Zero-configuration networking wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Peer-to-peer wikipedia , lookup
Transcript
Cross Stratum Optimization (CSO) Bar BOF November 2010 79th IETF @ Beijing, China 1 Agenda • • • • IETF CSO Effort Background (Young Lee, 5 min) NA-ARAM (Ning So, 15 min) NS Query (Young Lee, 15 min) Q & A (25 min) November 2010 79th IETF @ Beijing, China 2 IETF CSO Effort • CLO Bar BOF was held in Maastricht IETF meeting (78th) – 40 + attendants from carriers, vendors, academia and research institutes • • • • Created IETF mailing list: [email protected] Public Archive: http://www.ietf.org/mail-archive/web/cso CLO -> CSO (Name changes) CSO := {NS Query, NA-ARAM} Where NS Query = Network Stratum Query NA-ARAM = Network Aware Application Resource Assignment and Mobility • NS Query BOF Request didn’t go through the initial IESG approval – Need more clarification November 2010 79th IETF @ Beijing, China 3 Network Aware Application Resource Assignment and Mobility in Data Centers draft-so-network-aware-application-problem-01.txt Ning So (UTD) Dave McDysan (Verizon) Tae Yeon Kim (ETRI) Oscar Gonzalez de Dios (Telefonica) November 2010 Young Lee (Huawei) Greg Bernstein (Grotto) Kohei Shiomoto (NTT) 79th IETF @ Beijing, China 4 Problem Description • Many application services offered by Data Center make significant use of the underlying networks resources • The same application service can be offered by multiple geographically dispersed data centers. – allowing the application to be closer to the end-users to enhance service performance and user experience • Problem #1: The decision as which server/data center to select for an application request from endusers can negatively affect the quality of experience (QoE) of the users if not done correctly. November 2010 79th IETF @ Beijing, China 5 Problem Description (Cont’d) • VMs supporting the applications can be actively distributed within and/or between data centers. – Improve server utilization – Prevent service performance degradation during the peak usage time period, and during equipment failures. • Problem #2: When instantiating new VMs or migrating existing VMs across data centers, the underlying network loading conditions within a data center (LAN) or between data centers (MAN/WAN) need to be considered November 2010 79th IETF @ Beijing, China 6 Exemplary Cloud Data Center Global Load Balancer DC 1 1 2 3 End-User 1 CE 4 Access Network Application Servers CE 1 PE 1 Carrier Backbone Network PE PE 4 1 2 CE 2 PE 2 DC 2 PE 3 1 Access Network November 2010 PE CE 4 End-User 2 CE 3 2 DC 3 79th IETF @ Beijing, China 7 Current Server Selection Technology • The server selection for an application/VM is done by load-balancer. – The load balancer is aware of a certain level of server usage data and distributes the application requests based on that data. November 2010 79th IETF @ Beijing, China 8 Deficiencies of Current Server Selection Technology • The current load balancing technology is insufficient in providing an optimal decision across multiple VLANs and multiple Data Centers – No standard solution for the communication exchange among load balancers located in different Data Centers • load balancers from different vendors cannot communicate to each other – load balancers know little about the underlying network conditions • When migrating existing VMs/applications from one data center to another, the underlying network load condition in LAN/MAN/WAN can be constraining factors. – Load balancers know little about user condition November 2010 79th IETF @ Beijing, China 9 Optimized Server Selection Criteria • Factors need be considered in choosing the right server in the right data center for an application request or in instantiating new or migrating existing VMs/applications – – – – Server level load condition in a data center Intra data center network condition Carrier MAN/WAN network condition User Condition November 2010 79th IETF @ Beijing, China 10 Server Selection Criteria Details • Server level load condition – – – – – – – – VM supportability limitations CPU utilization Memory segmentation and consumption Application limitations e.g. max # of simultaneous instances of the application supportable Storage access speed (disk, RAM, etc.) Environment considerations such as server temperature, power load, and electrical cost at the time Operational and managerial considerations such as location of peer servers and storages VM to NIC switching in a virtual switch • Intra-DC network condition – Server NIC to Top of Rack (ToR) Switch – TOR switch to Layer 2 Switch - link and node level – Between L2 Switches and L2 switch to L2 core/gateway switch/router - link and node level – L2 gateway router to provider edge (PE) router - link and node level. November 2010 79th IETF @ Beijing, China 11 Server Selection Criteria Details • Carrier MAN/WAN network condition – – – – – – Type of networks and the technical capabilities of the networks Bandwidth capabilities and availability Latency Jitter packet loss other Network Performance Objective (NPO) as defined in section 5 of [ITU-T Y.1541] • User condition – User access capabilities and limitations (e.g., user terminal information such as codec for video application) – User location – Optional user preferences (for some application, user may be able to specify its preferences. For example, the preferred server location for Novembergaming). 2010 79th IETF @ Beijing, China 12 Requirements for Optimized NA-ARAM • End-users send requests to the Application Controller (global load balancer), which makes server assignment decision for the user application. – End-users may send the following • • • • • Required application: this may be a simple URL request Specific server identity or location. Additional security requirements Modified application specs. (for mobile users) Optional end-user terminal information • Inter DC communication: the application controller need to be aware – Server/Application Status from each of the Data Centers where the application servers are located – Intra-DC network conditions from each of the Data Centers where the application servers are located • Data Center-Network Stratum Communication – The details of how this can be accomplished are addressed in Network Stratum Query draft. November 2010 79th IETF @ Beijing, China 13 Thanks and Questions? November 2010 79th IETF @ Beijing, China 14 NQ Query draft-lee-network-stratum-query-problem-01.txt Young Lee (Huawei) Ning So (UTD) Tae Yeon Kim (ETRI) Oscar Gonzalez de Dios (Telefonica) November 2010 Dave McDysan (Verizon) Greg Bernstein (Grotto) Kohei Shiomoto (NTT) 79th IETF @ Beijing, China 15 Backgrounds • Most Internet Services are offered by the “servers” geographically spread. • Data Centers Networks have emerged as physical infrastructure for Content Delivery Networks and Cloud Computing. • Application services, e.g., data centers, make significant use of the underlying network services • Application services have access to little or no information about network services, e.g., available bandwidth, congestion level, etc. November 2010 79th IETF @ Beijing, China 16 Context of NS Query: Data Center Networks (DCN) (1) End-user to DC communication (request/reply) (2) Intra DC Communication GLB 1 2 (3) Inter DC Communication (exchange server performance data) 3 End-User 1 CE 4 Access Network DC 1 GR (4) DC-Carrier Communication PE 1 (NS Query) Application Resource (server) Carrier Backbone Network PE PE 4 GLB 1 2 GR DC 2 PE 2 PE 3 1 Access Network PE GR 2 GLB DC 3 CE 4 Direct Access (Corporate User) CE 4 End-User 2 November 2010 79th IETF @ Beijing, China 17 Cross-Stratum Application Stratum • • • Distributed Resources: Data Centers with servers, content, data sets, computing power, cache/mirror Uses Network Resources Different QoS requirements for each application Application Stratum NS Query Network Stratum • • • • Bandwidth, Connections, Links, Connection Processing (Creation, Deletion, Management) Admission Control, Resource Reservation Applications uses resources in IP, MPLS, and/or Optical Transport Networks, Layer 2 November 2010 79th IETF @ Beijing, China Network Stratum 18 Application Service Profiles Characteristics & QoS Requirement of application service from a network perspective: • • Location profile: locations of both the clients and the sources QoS profile: (i) Delay Tolerance Bound; (ii) Jitter Tolerance Bound; (iii) Packet Delivery Ratio Tolerance; (iv) Network Availability, etc. • • • Connectivity profile: (i) P-P; (ii) P-MP; (iii) MP-MP; (iv) Any Cast Directionality profile: (i) uni-directional; (ii) bi-directional Bandwidth profile: Maximum, average, and minimum bandwidth requirements for the connectivity, maximum burst rate, maximum burst duration, etc. • • • • Duration of service profile: service time of the application Network media profile: (i) optical only; (ii) no microwave, etc. Restoration profile: (i) Reroute required; (ii) do not re-route, etc. Security profile: (i) dedicated end-to-end VPN-like resource allocation; (ii) dedicated physical resource allocation Currently, network is not informed of the nature of the application there is no good way convey theChina application service profile to November --2010 79th to IETF @ Beijing, network stratum 19 Carrier MAN/WAN network condition • Type of networks and the technical capabilities of the networks; • Bandwidth capabilities and availability; • latency; • jitter; • packet loss; • And other Network Performance Objective (NPO) as defined in section 5 of [ITU-T Y.1541]. November 2010 79th IETF @ Beijing, China 20 CSO NS Query Architecture End-User Interfaces Global Load Balancer Intra DC Resource Application Control Gateway Inter DC Gateway Remote Data Centers Interfaces NS Query (First Step) Network Control Gateway IPPM NS Query (Second Step) TED BGP-RIB IGP-RIB November 2010 LSDB 79th IETF @ Beijing, China 21 Two-stage Query • A Vertical Query – First Stage: A vertical query from an application entity (i.e., the Application Control Gateway (ACG) in Data Center) to an entity representing the network (i.e., the Network Control Gateway (NCG)) for highly summarized and abstracted network related information for a particular point in network; and • A Horizontal Query – Second Stage: Internal "horizontal query" at the network layer along with summarization and abstraction of the network information in a form that preserves network confidentiality and significantly reduces the amount of information that needs to be transferred. – The raw information needed to perform this summarization/abstraction is defined in existing and emerging network management standards and protocols (SNMP, Netflow, sFlow, IPPM, IGP, RIB, etc...). – NS Query would not necessarily standardize how this "internal horizontal queries" and summarization would be performed but would illustrate how such processes can be accomplished via standards, emerging standards or common commercial practices. November 2010 79th IETF @ Beijing, China 22 NS Query Example • For a particular point in networks, the NS Query can ask the following network load data in a summarized/abstract form: – b/w availability (this case the minimum b/w requirement should be provided) – latency – jitter – packet loss • Note that this can be asked in a different way. For example, the query can simply ask: – Can you give me if you can route x amount of b/w (from server to enduser) within y ms of latency? – Can you give me if you can route x amount of b/w (from server to enduser) with no packet loss? November 2010 79th IETF @ Beijing, China 23 Thanks! November 2010 79th IETF @ Beijing, China 24