[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

Intarea Working Group                                       V. Deshpande
Intended status: Experimental
Expires: December, 2018                                     June 4, 2018

                    IP address space reclassification

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or
   IETF Contributions published or made publicly available
   before November 10, 2008. The person(s) controlling the
   copyright in some of this material may not have granted
   the IETF Trust the right to allow modifications of such
   material outside the IETF Standards Process.  Without
   obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be
   modified outside the IETF Standards Process, and derivative
   works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or
   to translate it into languages other than English.

   Internet-Drafts are working documents of the Internet
   Engineering Task Force (IETF), its areas, and its working
   groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be

Deshpande            Expires December 4, 2018                   [Page 1]

Internet-Draft       IP address reclassification           December 2017

   accessed at http://www.ietf.org/shadow.html

   This Internet-Draft will expire on December 4, 2018.

Copyright Notice

   Copyright (c) 2018 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.


   This draft describes an AI based TCP-IP model. By understanding how
   the Network is evolving from a Wireless and Software perspective
   the limitations of current Internet Architecture are identified and
   the corrections needed for the Big Data bottleneck present in
   current Internet Architecture are described further. This draft
   explains about the implicit life cycle between the Cloud, Network
   and Internet.
   An important conclusion is drawn that the Network cannot be
   declassified from the Cloud.
   Based on the evolution of the Virtualized Datacenter within the
   Cloud architecture framework and the implicit fact that the Network
   also needs to grow and scale towards the Cloud another important
   conclusion that the whole Topological address space which is the
   current IP address space (IP as well as IPv6) needs to be
   reclassified or divided into a physical (or logical) address space
   and a new Virtual address space. The Virtual address space is a
   Centralized Control plane which only processes routing information.
   A future Internet architecture for resolving the Big Data bottleneck
   which introduces a Virtual address space at specific Intersection
   points such as Inter-AS, CsC and IXP (Internet Exchange Points) is

Deshpande            Expires December 4, 2018                   [Page 2]

Internet-Draft       IP address reclassification           December 2017

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. AI Based TCP IP Model and the Big Data Bottleneck . . . . .  5
  2.1. Impact on EPN (Evolved Programmable Networks) . . . . .  6
3. IP address space reclassification . . . . . . . . . . . . .  7
4. Reasons for reclassifying the IP address space   . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . .  10
  8.1. Normative References . . . . . . . . . . . . . . . . .  10
  8.2. Informative References . . . . . . . . . . . . . . . .  10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10

1. Introduction
   o    An AI based TCP IP model describes how Big Data is centered at
        the Internet and Transport layers of TCP-IP.  The Big Data
        bottleneck is present in the Internet due to inherent routing
        challenges such as redistribution, convergence, etc.
   o    The Big Data bottleneck lies between different Autonomous
        Systems. Due to the implicit life cycle between a Network,
        Internet and the Cloud which is time bound and unidirectional,
        the Network also needs to grow and scale to the Cloud to reap
        the benefits of Cloud such as Datacenter virtualization,
        scaling and high availability.
   o    For such scaling to occur from both ends a Virtual address
        space is needed in between. The limitations brought about by
        the present classification of IP address space into public,
        private and the almost mandatory usage of NAT in the Internet
        and Cloud architecture leads to suggest that translating or
        mapping of the IP address into another Virtual address space
        cannot be avoided.

Deshpande            Expires December 4, 2018                   [Page 3]

Internet-Draft       IP address reclassification           December 2017

|           |Process to Process     |           |
|Application|Applied on IoT         |Application|
|           |(Cognitive,Symbolic)   |           |
|           |Traditional top-down AI|           |
|           |Host to Host           |           |
|           |Applied to IoT as well |           |
|Transport  |as underlying Hardware |Transport  |
|           |Could be both Top-down |           |
|           |and bottoms-up AI      |           |
|           |Internet               |           |
|           |Underlying hardware    |           |
|Internet   |Machine learning       |Internet   |
|           |(Neural Networks)      |           |
|           |Bottoms-up AI          |           |
|           |Link                   |           |
|           |Underlying hardware    |           |
|Link       |Machine learning       |Link       |
|           |(learnt from IoT       |           |
|           | or Sensors)           |           |
|           |Bottoms-up AI          |           |
Figure 1: TCP IP Layers from an IoT perspective

+--------+    +---------+   +---------+
|        |    |         |   |         |
|Internet+----> Network +--->  Cloud  |
|        |    |         |   |         |
+---^----+    +---------+   +----+----+
    |                            |
Figure 2: Implicit Life cycle (Time bound and unidirectional)

Deshpande            Expires December 4, 2018                   [Page 4]

Internet-Draft       IP address reclassification           December 2017

+-------------+    +----------+    +-------------+
| Centralized +----> Big Data +----> Distributed |
| Control     <----+          <----+ Forwarding  |
+---^--+------+    +----------+    +----^--+-----+
    |  |                                |  |
    |  +--------------------------------+  |
Figure 3: Implicit Life cycle with Centralized Control and
          Distributed Forwarding

2. AI Based TCP IP Model and the Big Data Bottleneck
   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
   clarified. An AI based Top-Down and Bottoms-Up approach is applied
   to the TCP-IP Layers.
   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 evolves first and then the Program control.
   From the AI based TCP-IP model and analysis of digital data this
   duality is centered 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 reached.
2.1. 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 or software. As the Network is

Deshpande            Expires December 4, 2018                   [Page 5]

Internet-Draft       IP address reclassification           December 2017

   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 the Big Data bottleneck occurs at the Inter-AS and CSC
   (Carrier supporting Carrier) level. 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.
   From a high-level programming perspective, the data type is a
   program construct while the control flow is a type of program
   execution (in a Machine).
   From a low-level programming 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.
   The bottleneck described above is in fact also a Big Data bottleneck.
   The implication is that Big data traffic issue between AS in the
   Internet can only be resolved by a separate routing control plane as
   that is where the data traffic is found.

Deshpande            Expires December 4, 2018                   [Page 6]

Internet-Draft       IP address reclassification           December 2017

3. IP address space reclassification
   Based on a topological consideration, IP address space needs to be
   divided into two address spaces. The present physical (or logical)
   address space and a new Virtual address space. The IP address space
   collectively is a Topological space.
   As each AS is a separate routing instance. The Big data bottleneck
   issues presents itself in the current internet architecture in the
   form of BGP convergence, repetition through redistribution of
   routes, Inability to diversify the routes (Diversity pre-coding).
   One major drawback is that the Network cannot be de-classified
   from the Cloud architecture.
   Hence the IP address space needs to be further classified as a
   physical address space and Virtual address space.
   The present Internet architecture while being considered as
   hierarchical is in fact a multi-plane architecture (each AS being
   a coherent routing instance is in fact a routing plane in itself).
   The interconnections between the AS are the intersection points of
   these separate planes.
   To integrate these planes a separate control plane which connects
   with the multiple physical planes at the intersection points is
   The essential routing information at these intersection points is
   present in the BGP Next hop.
   Hence the BGP Next hop (mostly a Next Hop which shares EBGP routes)
   needs to be virtualized. The BGP Next hop from the physical space is
   mapped to a Virtual IP from the virtual address space.
   The Virtual space is only a control plane and cannot transfer data.
   In other words, the virtual address space can only contain routing
   information. However, it provides the greatest flexibility to the
   Internet as a route can be picked up from one isolated point in the
   topological space and placed at another point.
   The Virtual address space while being a Centralized Control plane
   can also show distributing routing capabilities as essentially the
   Virtual plane is introduced at various intersection points
   throughout the Internet. The Virtual address pace may in turn
   contain Autonomous Systems.

Deshpande            Expires December 4, 2018                   [Page 7]

Internet-Draft       IP address reclassification           December 2017

   A property of the finite space is that a connected route is also
   path connected. In other words, a route from the physical address
   space can get added to the virtual IP address space at multiple
   Virtual Next hops at various intersection points.
   This allows the feasible routes to be recomputed in the Virtual
   routing control plane.
   By connecting the Internet and the Network to the Cloud
   Infrastructure through this Virtual address space the benefits of
   the Cloud Infrastructure such as Scaling, Datacenter virtualization
   and high availability can be transferred to the present Internet
   architecture. For this to occur the Virtual address space also needs
   to have intersection points that map to the Cloud environment.
   The various hybrid cloud environments of various vendors are
   effectively additional routing planes that get mapped into this
   Virtual address space.  This ensures an effective decoupling of the
   current Internet architecture and the Cloud Infrastructure.
   All the routing information from an AS is transferred through the
   BGP Next hop to the Virtual address space. Please note that the
   Virtual BGP Next hop, while being a virtual IP in the Virtual
   address space is not actually being used for load balancing as no
   data is transferred. A topology table is built from the static
   snapshots of the routing information received from the different
   BGP Next hops in the different AS in the physical address space.
   Each snapshot can be converted into a Routing Dataset and ML
   algorithms can be applied. This is the low-level perspective as
   described in the AI based TCP IP model. This topology table is
   remapped into a Topological space by programmatically fitting in
   a routing algorithm. This routing algorithm forms the high-level
   perspective as described in the AI based TCP IP model. The presence
   of a single route at various intersection points in the virtual
   address space suggests that each intersection point has in fact a
   segment of the route. Hence this is a form of segment-based
   routing. Where a single route may merge and unmerge from a TCP
   protocol perspective.
   This would help in dynamically re-routing or merging a broken
   route from any AS to any AS from where the route is reachable.
   A merger table which contains the routes which have been changed
   is created in the Virtual address space. A mechanism is needed to
   identify the merged routes in the physical address space as well.
   This may require TCP header modification.

Deshpande            Expires December 4, 2018                   [Page 8]

Internet-Draft       IP address reclassification           December 2017

4. Reasons for reclassifying the IP address space
   o   Resolve the BGP related challenges such as Convergence,
       Redistribution, Inherent routing problems within an AS.
   o   The Network cannot be de-classified from the cloud. The
       Network needs to grow and scale towards the Cloud.
   o   Facilitate true automation for the SDN.
   o   A characteristic of Wireless networks is diversity pre-coding.
       Divergence or Diversity is the opposite of Convergence.
       Convergence mathematically is a path integral.  Firstly,
       a centralized Virtual plane would facilitate a pre-coded
       centralized topological address space programmatically. This
       would solve the convergence problem in the present Internet
       architecture by providing the ability to diverge routes at
       separate isolated points between any AS in the Internet.
   o   Due to the address space reclassification, the network
       management and security of this Virtual address space is also
       isolated completely from the physical network. The Virtual
       address space can have its own network diagnostic tools like
       the ping and traceroute.
   o   The Virtual Address space can effectively integrate the Cloud
       Infrastructure and the Virtualized Datacenter with the physical
       address space.
   o   The Virtual address space provides vast flexibility and can be
       modelled as an ideal Topological space.
   o   The Virtual address space is essentially a parallel data
       pipeline for the whole Internet as it virtually merges a single
       route and, in the process, provides an alternate route through
       two isolated points in different routing planes in the physical
5. Security Considerations
   A more robust security model can be built around the Virtual
   address space.
6. IANA Considerations
   This document describes the need for IP address space

Deshpande            Expires December 4, 2018                   [Page 9]

Internet-Draft       IP address reclassification           December 2017

7. Conclusions
   The IP address space (both IP and IPv6) needs to be reclassified as
   a Physical address space and a Virtual address space. The mapping
   between these two occurs at the BGP Next hop. Together these two
   address spaces provide the ability to build an ideal Topological
   space for the Internet which can then run on an automated
   distributed SDN.
8. References
8.1. Normative References
   [RFC793]      "Transmission Control Protocol", RFC 793,
   September 1981.
   [RFC4271] Y. Rekhter, S. Hares and T. Li, "A Border Gateway
   Protocol 4 (BGP-4)", RFC 4271, January 2006.
   [RFC4274]     D. Meyer and K. Patel, "BGP-4 Protocol
   Analysis", RFC 4274, January 2006.
   [RFC7868]     G. Savage, J. Ng, S. Moore, D. Slice,
    P. Paluch, R. White, "Cisco's Enhanced Interior Gateway Routing
    Protocol (EIGRP)", RFC 7868, January 2006.

8.2. Informative References
   Daniel Fischer, David Basin and Thomas Engel
   Topology Dynamics and Routing for Predictable Mobile
9. Acknowledgments
   This document was prepared using 2-Word-v2.0.template.dot.

   Copyright (c) 2018 IETF Trust and the persons identified as
   authors of the code. All rights reserved Redistribution and
   use in source and binary forms, with or without modification,
   is permitted pursuant to, and subject to the license terms
   contained in, the Simplified BSD License set forth in Section
   4.c of the IETF Trust's Legal Provisions Relating to IETF
   Documents (http://trustee.ietf.org/license-info).

   Author's Address
   Vineet Deshpande
   Flat no. B-303, Peninsula Pinnacles,
   Adigara Kalahalli, Sarjapur-Attibel,
   Bangalore 562125

   Phone: 91 7259600661
   Email: vineetdeshpande@yahoo.com

Deshpande            Expires December 4, 2018                   [Page 10]

Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/