Intarea Working Group V. Deshpande Internet-Draft Intended status: Experimental Expires: December, 2018 June 4, 2018 IP address space reclassification draft-deshpande-intarea-ipaddress-reclassification-00.txt 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 http://www.ietf.org/ietf/1id-abstracts.txt 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. Abstract 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 described. 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 needed. 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 network. 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 reclassification 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 India Phone: 91 7259600661 Email: vineetdeshpande@yahoo.com Deshpande Expires December 4, 2018 [Page 10]