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

internet-drafts@ietf.org Mon, 13 June 2016 01:19 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-deshpande-intarea-ai-based-tcpip-00.txt
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160613011933.5492.36832.idtracker@ietfa.amsl.com>
Date: Sun, 12 Jun 2016 18:19:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/i-d-announce/aerhoHzeqfz4OVTQViopi5jAeYY>
Reply-To: internet-drafts@ietf.org

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)

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/

I-D Action: draft-deshpande-intarea-ai-based-tcpi… internet-drafts