Internet Working Group Vineet Deshpande Internet-Draft Cisco Systems Intended status: Experimental June 12, 2016 Expires: December 5, 2016 Intelligent Automation of Cloud and Network through AI Based TCP-IP Model draft-deshpande-intarea-ai-based-tcpip-00 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 12, 2016. Copyright Notice Copyright (c) 2016 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. Abstract This draft describes an AI based TCP-IP model. This draft describes how Networks are evolving from Wireless Networks and Programming. This draft describes how Big Data bottlenecks are present in current Networks. This draft describes Network and Cloud Orchestrated Reflectors for resolving the Big Data bottleneck at Inter-AS and CSC (Carrier Supporting Carrier) level. This draft proposes a Context Mapping Language for E2E context-awareness and M2M communication. This draft proposes Path diversity in Wired Networks as it evolves from Wireless Networks. Path diversity through Cloud Orchestrated Reflectors can be implemented through the Wireless concepts of Rx Diversity, Tx Diversity and MIMO (Multi-Input, Multi-Output) This draft is more of a fundamental concept that identifies how the Network is evolving. This draft explains about the implicit life cycle, which is also somewhat mathematical as it involves one-to-many and many-to-one function mapping between Cloud and Network reflectors. Then it relates the many cloud reflectors together throug Wireless network technologies like Tx, Rx diversity and MIMO. This draft explains how this can be implemented in Wired networks through Cloud software, path diversity, spatial multiplexing and Diversity precoding. Introduction This draft: 1.Identifies the Big data, Digital Data bottleneck in present Network. 2.Identifies that Networks are evolving from Wireless Networks as well as Programming. 3. Provides a resolution to the Data bottleneck problem by evolving the present Wired Networks and Cloud architectures to incorporate features from Wireless networks and Programming. This draft begins at a very basic level where it identifies the problem in the M2M communication. John Backus (Inventor of FORTRAN or Formula Translation) describes the Von Neumann bottleneck as an Intellectual bottleneck. This Intellectual bottleneck also affects the TCP-IP model or the Networking layers. There is a static nature to the TCP-IP model. If an AI approach is chosen to understand the TCP-IP layers the problem in M2M communication can be further classified. The problem is that there is a duality between the state machine and the program control. However, the state machine is like a point value or a basic computational element. This point value links the state machine to Wireless Networks through Mass-Energy equivalence. Thus the state machine comes first and then the Program control. From the AI based TCP-IP model and analysis of digital data it can be seen that this duality is centred between the Internet and the Transport layers. The Digital Data or Big Data is the central point around which we are building a network architecture, therefore a design model somewhat different from SDN or TCP-IP can be arrived at. This is described through the diagrams in this draft: 1. Implicit Lifecycle with Big Data in Centralised Control plane and Distributed forwarding 2. Implicit Lifecycle between Network, Cloud and the Internet (aka Network of Networks). Impact on EPN (Evolved Programmable Networks): Having arrived at these models we can understand how the Network is not just evolving from Programming but is evolving from the M2M bottleneck or M2M duality. This duality has Digital data or Big data as the central point. This digital data can be considered as an infinitesimal mass value or a finite state element. Considering the implicit lifecycle and the mass-energy equivalence we can arrive at the conclusion that Networks are also evolving firstly from Wireless Networks and then from Programming. As the Network is evolving from both Wireless Networking as well as Software Programming we can thus find out more about the inter-working of the Cloud (more of a software based and Wireless concept) and the Network (Hardware based and both a Wired, Wireless concept). The digital or Big data is the central connecting point so it cannot be declassified from both the Cloud and the Network. Based on this analysis it can be seen that the Big Data bottleneck occurs at the Inter-AS and CSC(Carrier supporting Carrier) level. A Network grows as we add more physical hosts. A Network will keep growing and scaling. Thus we can predict from Wireless Network architecture and Programming how the present Network needs to evolve (grow and scale) to merge with the Cloud Architecture. Through new features described in my draft such as Cloud Orchestrated Reflectors, Network Orchestrated Reflectors, Context Mapping, Path diversity (as evolved from Wireless concepts such as Tx Diversity, Rx diversity and MIMO) the Big data or Digital data bottleneck problem in present Networks can be resolved. Description: The goal is to build a Seamless cloud infrastructure which allows any CE to be seamlessly connected to the Internet (or SP). The Infrastructure would combine high speed core (data center) architecture with the Service provider and also to the end user. The Seamless cloud does not have the drawbacks of the hybrid cloud division that breaks down the Cloud into a public and a private cloud infrastructure. The Seamless Cloud infrastructure can provide an alternate way of building the CSC (Carrier Supporting Carrier) framework which is the present SP backbone design. A Distributed Intelligence system is more suited for the hierarchical layered system that defines the Network. A centralized control plane for the entire network may have vulnerabilities and also greatly increases the complexity. A distributed system is more practical considering the Routing/Switching infrastructure and Network layers that we have. From an AI perspective this would be a bottoms-up approach rather than a top-down approach. Please see below diagram of the TCP/IP model from this AI perspective.It is important to understand that the AI in a Network or a Cloud is centered around the Internet and Transport Layer while still needing a Top-down approach from the Application layer and a bottoms-up approach from the Link layer. The Cisco proprietary parameter appropriately named as "weight" in the BGP protocol is suggestive of the fact that the Intelligence in a Network needs to be centered around the Network and Transport Layers. Also the term "Weighted" appears in QoS as "Weighted Fair Queueing". TCP/IP Layers from an AI/IoT perspective (AI Based TCP-IP Model) ________________________________________________________________ Application | Process to Process | Application | | Applied on IoT | | |(Cognitive,Symbolic) | | | Traditional top-down AI | | ____________|_______________________________|___________________| Transport | Host to Host | Transport | | Applied on IoT as well | | | as underlying hardware | | | Could be both top-down AI as | | | well as bottoms-up AI | | ____________|_______________________________|___________________| Internet | Internet | Internet | | Underlying hardware | | | Machine Learning(Neural | | | networks) | | | Bottoms up AI | | ____________|_______________________________|___________________| Link | Link | Link | | Underlying hardware | | | Machine Learning(Learnt from | | | IoT or Sensors) | | | Bottoms up AI | | ____________|_______________________________|___________________| AI based FSM with IntelligentFlow in contrast to OpenFlow needs to be developed to build an AI based Network Infrastructure. This FSM can form a sort of Shadow Router that tracks and defines the Network from a bottoms-up approach. The underlying hardware approach can assist in fast switching the data as in Shortest path bridging. Basically TCP is stateful, IP is stateless and BGP is stateful. IntelligentFlow: Scaling the Data Flow If an AI based FSM can somehow be sandboxed and moved between devices (or hosts) then IntelligentFlow may be possible with the bottoms up and top down AI approach. From a programming point of view, a combination of high level and low level programming is needed by which we can Sandbox the AI based FSM between hosts. This calls for introducing an IntelligentStack as opposed to an Openstack within the data flow of the AI Based TCP/IP model. This IntelligentStack could work in tangent with the Elastic Compute Cloud of Openstack by providing more traction over the Internet. The AI based FSM Sandbox can optimize the traffic flows by acting as Intermediary in the Data flow model. The Sandbox can scale up or reverse-scale the flows. This could solve the BGP slow convergence and divergence problems. AI is like the logic behind a thought process. A Combinatorial logic is needed to combine the low level and high level languages. This combination can develop into a very basic type of M2M Intelligence which is essential for IoT. From a high level programming perspective, the data type is a program construct and the control flow is a type of program execution (in a Machine). From a low level perspective, the AI based FSM can do the reverse which is to program the data flow by sending the control plane information(to a Machine). In other words, there is a duality in the M2M architecture through the State Machine and the Program Control. This maybe the only way to tackle the Von Neumann Bottleneck: The Von Neumann bottleneck was described by John Backus in his 1977 ACM Turing Award lecture. According to Backus: Surely there must be a less primitive way of making big changes in the store than by pushing vast numbers of words back and forth through the von Neumann bottleneck. Not only is this tube a literal bottleneck for the data traffic of a problem, but, more importantly, it is an intellectual bottleneck that has kept us tied to word-at-a-time thinking instead of encouraging us to think in terms of the larger conceptual units of the task at hand. Thus programming is basically planning and detailing the enormous traffic of words through the Von Neumann bottleneck, and much of that traffic concerns not significant data itself, but where to find it.[22][23] This is contrast to the duality in the Cloud that is implied in the Intercloud Architecture. Hence according to me the Seamless Cloud can incorporate the M2M architecture via the Network that cannot be declassified from the Cloud. The Combinatorial logic behind the above categorization of a Machine (M2M) is that the binary or digital data is not completely defined and can be divided into low level machine learning based data (letters or numbers presented to Machine for reading) and high level Top down AI based data (checks inputs of letters or numbers against a description). The binary data gets more well defined (turing complete?) when put into a finite state machine. When binary data is put into a state machine it adds value and thus weight into the machine. This is where BGP, TCP, IP protocols come into the picture through the weight parameter and the CBWFQ in QoS. This is where we need to find the data based on the Von Neumann bottleneck. If this M2M Intelligence can be developed Robots can identify Objects and take actions through Proximity Sensors. Robots can focus on near Objects, identify them and take actions. A great boost for IoT. From a bio-technology perspective the network is akin to a nervous system controlled by a centralized Neural network. However, both distributed and centralized intelligence may be required considering the hierarchical distributed layers in the legacy network data flow model where both a bottoms-up and top-down AI model is required. Neural networks have a concept called Convergence and Divergence. In Networking the focus is mostly on convergence through routing protocols. However, a divergent approach is also needed in order to meet the AI/IoT based TCP/IP model requirement. As described above I have defined an AI Based TCP-IP model. Through that model I explained the significance of the "weight" parameter. This allows us to define an Intelligent Automation for Autonomous system through Cloud and Network orchestration. There can be alternate ways of approaching Inter-AS and CSC. The weight parameter is localized in an AS. With this being introduced in Segment routing it allows dynamic scaling of such parameters. Thus an AS can grow or shrink. Or a Private AS can be dynamically generated. A public AS can scale, grow or shrink. In essence this means adding more value and functions into AS numbers through algorithms which can dynamically alter the Autonomous systems without impacting the network in any way. Autonomous systems could be further classified into Temporary and Permanent Autonomous Systems. This could serve as the mapping between Cloud and network resources because the network cannot be declassified from the cloud. This mapping can form an interface between Network computing and Cloud computing. This is rather like finding a number within a number. This algorithm could involve randomly changing numbers. Making numbers big or small. However, one-to-many is not the same as many-to-one. Quantum computing with Qubits and Shor Algorithm could implement such an algorithm. The efficiency of Shor's algorithm is due to the efficiency of the quantum Fourier transform, and modular exponentiation by repeated squarings. These concepts of an Automated AS can be of significance in the IoT scenario where IoT devices can pe present anywhere and everywhere. IoT technologies like Smart Grid, Smart Transportation,Smart Cities require a more robust and intelligent M2M communication. This is rather oddly somewhat like APIPA in Windows but now at the Autonomous System level. The M2M interface between Cloud and Network can be further defined based on the concept of finding a number within a number. There is an element of time in-variance in the network while there is an element of time variance in the Cloud. This means that the network convergence system needs to act as a Network Orchestrated Reflector based on the ASN (Autonomous System number) while the Cloud needs to act as Cloud Orchestrated Reflector based on the Cloud platform ASN (Autonomous System number). This defines the interface between the two which in turn defines the mapping between Cloud and Network. Thus Fast Computing in the Cloud compensates for the slow computation in the Network. The Network orchestrated reflector and Cloud orchestrated reflector defined above are similar to the Route reflector but include ASN and other relevant features. The loop or life cycle between the Network and Cloud reflectors can be closed through the Segment routing and "weight" parameter There may not really be a need for Quantum computing as of now to implement these concepts. There is an Implicit Life cycle and need for Seamless Cloud Infrastructure as indicated by the diagrams below: Diagram 1: Implicit Life cycle (time bound) as the Network cannot be declassified from the Cloud (one way) |-----> Internet -----> Network -----> Cloud Computing -----| | | | | |-----------------------------------------------------------| | Diagram 2: Implicit life cycle with Centralised Controller and distributed forwarding |-----> Centralised <-----> Big Data <-----> Distributed <--| | Controller Forwarding | | | |-----------------------------------------------------------| Diagram 3: Need for Seamless Cloud infrastructure |---> Hybrid <---> Seamless Cloud <---> Virtual private <---| | Cloud Cloud | | | |------> Public Cloud <-----------> Private Cloud <---------| Big Data analysis for TCP-IP: 1. Big Data analysis in terms of Artificial Intelligence, Digital footprint, Programming and Quality. Not only in terms of Volume 2. Big Data is the central intelligence that sits between the control plane and the forwarding plane. 3. Big Data can be considered as a centralized intelligence around which we are trying to put our concepts together. Big data is centered around IP, BGP and TCP. 4. Big Data in terms of volume (content) drags us down to the link layer. Concepts such as MPLS, switching take us away from Big Data. 5. Big Data is both a centralized intelligence and a bottleneck. A Distributed intelligence approach is also thus mandated. 6. Intelligent automation in the Cloud through Big Data (Hadoop, MapReduce) needs to interface with the Network at the Internet and Transport layers. What is the proof for Scale and manageability of these concepts ? Big Data is centered around TCP, IP and BGP layers. This is the forwarding path information in IGP via IBGP as well as EBGP. The interconnect between EBGP and IBGP is through Autonomous s ystems (ASN). The slow convergence problem is in BGP and in IBGP. This convergence issue is uncorrelated and exponential. However, this affects EBGP scenarios and overall Internet stability and scalability. This scale problem can only be solved by options which take into consideration path diversity and matching for LPM (Longest Prefix Match) between Autonomous systems. The number of unique Autonomous networks has grown to 47000 in mid-2014. Inter-AS options and CSC are big data bottlenecks. The present Inter-AS options consider solutions such as inter-VRF, ASBR with MP-BGP,etc. As these consider the routes and prefixes, they do not really solve the scale problem. Thus we need to look for alternate ways to approach this problem. Manipulating AS numbers, Cloud and network orchestrated Reflectors, HRR is required. Segment routing with parameters (eg: weight introduced into Segment routing) which can manipulate BGP AS path, communities are thus required. I use the word Cloud orchestrated Reflectors and Network orchestrated Reflectors as the problem needs to be abstracted from the Internet Architecture in order to avoid manageability issues in the present and in the future. Based on the diagram involving the Cloud, Internet and Network which is an implicit life cycle I believe that this is the only option to scale the Internet in the future. This is taking into consideration the limitations right now in BGP convergence, Inter-AS and Cloud computing. As this is a limitation issue even if the manageability is not feasible as of now it would still have to be considered in the future. The implicit life cycle proves that the Internet needs to be changed at the core as well and not just at the edges. Cloud orchestrated reflectors are also important as the Internet continues to scale with the Cloud and SDN. Big data as defined in Hadoop through MapReduce suggests that the interface between Cloud and Network is also important. New BGP AF/SAF options do not really solve this scalability problem: IP6 IP-VPN BGP Flow Specification Pseudo Wires L2VPN 2547 Multicast VPNs The scalability problem needs to be solved taking into consideration the fact that the network cannot be declassified from the Cloud. Hence The IP Packet need to be classified through a new AF/SAF which could likely involve BGP, ASN, segment routing and path diversity, etc. Alternate ways to approach inter-AS is needed as the traditional methods are traffic (big data) bottlenecks. This draft proposes the following: Cloud and Network Orchestrated Reflectors to route the Multi-service, multi-tenant data between Cloud and Network. Limitations of the Cloud and Network can only be resolved through: 1. IP Packet 2. Segment routing (weight parameter, load balancing, distributed computing, QoS, etc) 3. New AS numbers (having Cloud and Network orchestrated reflectors in a reserved, private or a public AS) 4. Cloud and Network orchestrated Reflectors 5. New BGP AF/SAF having Segment routing 6. New Inter-AS options considering Segment Routing, distributed intelligence, Path diversity, LPM (longest prefix match) Benefits: 1. Inter-AS options are based on inter-VRF, MPLS VPN and ASBRs which re-distribute routes. Re-distributing repeats the routes. Segment routing with RR is a better option. MPLS takes the Big data away from Internet layer and towards Link layer. 2. Segment routing needs to focus on Big Data, routing for Path diversity, LPM (Longest prefix match), QoS and Multi-service Mutli-tenant offerings. 3. The benefits with Segment routing are that it can avoid redistribution and rely on path diversity, distributed intelligence, distributed computing, etc through the interworking of Cloud and Network. 4. Benefits for Multi-service Multi-tenancy is greater scale, redundancy, distributed computing, distributed intelligence, Improved exchange and transit points for Services. These benefits outweigh the present Inter-AS options which are a big data bottleneck. Context Maps in BGP, Segment Routing and SDN Controllers. The traditional route maps in BGP can match for routes, BGP PA, communities. However for distributed intelligence and SDN Controllers the Service providers need to be more context-aware. Segment routing can act as a Centralized Controller in the SDN framework. However BGP, Segment routing does not support or cannot differentiate between different contexts (virtual, cloud, network) or services such as Network services , Web services (WSDL), Cloud services(REST API). A context map can map and act as an interface between the Cloud services, Network services and Web services. The concept of Path diversity is analogous to the concept of Transmit diversity and Receiver diversity in Wireless networks. The concept of Cloud reflectors is thus analogous to the concept of reflection in Wireless networks. Therefore it should be theoretically possible to implement features like MIMO (Multi-input Multi-output) and Tx, Rx diversity in Wired networks through COR and context mapping. MIMO concepts such as Spatial Multiplexing and Diversity Precoding can be implemented through Cloud Orchestrated Reflectors. This would also indirectly resolve the problem of sub-optimal routing that occurs through Route reflectors. Context maps or Context Mapping Language (CML) are the next evolutionary step in Cloud-fog-Computing: Route map-> Policy map -> Context map RPL --> CML This mapping between Cloud and Network is rather like an M2M interface therefore the Context Maps or CML needs to be in both BGP as well as in the SDN Controller or Cloud. ODL learns the Customer network through the NOR and transfers the topology to the COR transparently. COR is just a contextual representation of the NOR. There is a one-to-many mapping between NOR and COR. For one NOR or ODL we can have multiple COR. This is the most efficient way of Cloud and Network inter-working. Context maps can give us E2E context awareness for Smart cities, Smart grid, etc. Diagram 4: Cloud and Network Orchestrated Reflectors with Centralised Controller |--- COR ___|____________ NOR ----|_SDN_Controller_| | |--- COR Security From a Security perspective the AI based bottoms-up/Top-down approach can help develop an Internet Map or a Cloud Map from this Seamless Cloud which can be further developed to form an Intelligent Secure network which is a Security-aware, Zone-aware Seamless Cloud. The Seamless cloud can dynamically identify and mitigate security vulnerabilities. Personalized Secure clouds can become a reality. Security boundaries and perimeters for the Cloud can be more clearly identified. A Distributed Intelligence system is more suited for the hierarchical layered system that defines a Network. A centralized control plane for the entire network may have vulnerabilities and also greatly increases the complexity. A distributed system is more practical considering the Routing/Switching infrastructure and Network layers that we have. From an AI perspective my draft would be a bottoms-up approach rather than a top-down approach. The Network needs to grow (and scale) towards the Cloud and not just the other way round. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Author Address Vineet Deshpande Mail Stop BGL16/1 Cessna Business Park, Kadubeesanahalli Varthur Hobli, Sarjapur Marathalli ORR BANGALORE, KARNATAKA 560 103 INDIA Phone: +91 80 4429 1223 Email: vindeshp@cisco.com