Subject: I-D Action: draft-deshpande-intarea-ai-based-tcpip-00.txt

From: [email-masked]
Date: Sun, 12 Jun 2016 18:19:33 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Intelligent Automation of Cloud and Network through AI Based TCP-IP Model
        Author          : Vineet Deshpande
	Filename        : draft-deshpande-intarea-ai-based-tcpip-00.txt
	Pages           : 10
	Date            : 2016-06-12

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-deshpande-intarea-ai-based-tcpip/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-deshpande-intarea-ai-based-tcpip-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/