[Int-area] FW: New Version Notification for draft-deshpande-intarea-ai-based-tcpip-00.txt

["Vineet Deshpande (vindeshp)" <[e-mail]>]

Hello,

Request review and comments. Please refer PDF for more clear diagrams.
Apologies for the format issues.


Thanks & Regards,

Vineet Deshpande
ENGINEER.NETWORK CONSULTING

[e-mail]
Phone: [phone]


Cisco.com <http://www.cisco.com>

 Think before you print.
This
 email may contain confidential and privileged material for the sole use
 of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient
(or authorized to receive for the recipient), please contact the sender
by reply email and delete all copies of this message.
Please click here 
<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for
Company Registration Information.





On 13/06/16, 6:49 AM, "[e-mail]"
<[e-mail]> wrote:

>
>A new version of I-D, draft-deshpande-intarea-ai-based-tcpip-00.txt
>has been successfully submitted by Vineet Deshpande and posted to the
>IETF repository.
>
>Name:		draft-deshpande-intarea-ai-based-tcpip
>Revision:	00
>Title:		Intelligent Automation of Cloud and Network through AI Based
>TCP-IP Model
>Document date:	2016-06-12
>Group:		Individual Submission
>Pages:		10
>URL:            
>https://www.ietf.org/internet-drafts/draft-deshpande-intarea-ai-based-tcpi
>p-00.txt
>Status:         
>https://datatracker.ietf.org/doc/draft-deshpande-intarea-ai-based-tcpip/
>Htmlized:       
>https://tools.ietf.org/html/draft-deshpande-intarea-ai-based-tcpip-00
>
>
>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.
>
>
>
>                  
>        
>
>
>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.
>
>The IETF Secretariat
>