IP address space reclassification
draft-deshpande-intarea-ipaddress-reclassification-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Vineet Deshpande | ||
| Last updated | 2018-10-08 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-deshpande-intarea-ipaddress-reclassification-03
Intarea Working Group V. Deshpande
Internet-Draft
Intended status: Experimental
Expires: April, 2019 Oct 08, 2018
IP address space reclassification
draft-deshpande-intarea-ipaddress-reclassification-03.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 April 08, 2019 [Page 1]
Internet-Draft IP address reclassification April 2019
accessed at http://www.ietf.org/shadow.html
This Internet-Draft will expire on March, 2019.
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 proposes IP address reclassification. By understanding
how the Network is evolving from wireless technologies and comparing
with an abstract mathematical topological space model, changes such
as addition of a Virtual address space and Virtual BGP neighborship
are proposed.
The limitations of current Internet Architecture are identified and
the corrections needed for the traffic bottleneck present in the
current Internet Architecture are described further.
The interdependence of IPv6 ULA addressing scheme, multipath and
multipath TCP with the virtual neighborship and the virtual address
space are explored.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Mathematical premise for the electromagnetic equivalent . . 3
3. Design considerations for the Internet architecture . . . . . 3
4. Complexities in analyzing the Internet as a topological space . 4
4.1 Complexity of Computation . . . . . . . . . . . . . . . . . . 4
4.2 Complexity of Algorithms . . . . . . . . . . . . . . . . . . . 4
4.3 Complexity of Connectedness . . . . . . . . . . . . . . . . . 4
4.4 The Problem of Observability . . . . . . . . . . . . . . . . 5
5. Internet architecture based on the design considerations . . . 5
6. IPv6 address assignment for the Virtual address space . . . . . 9
7. Glossary of terms and definitions . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . . 12
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
Deshpande Expires April 08, 2019 [Page 2]
Internet-Draft IP address reclassification April 2019
1. Introduction
This draft proposes IPv6 address re-classification. An attempt is
made to identify the significant traffic bottlenecks in the
Internet. IPv6 address space is re-classified by adding a new virtual
address space which facilitated a highly parallelized traffic control
system to resolve the traffic bottleneck problems.
By assuming a mathematical premise of a finite topological space
with interior, exterior and closure an attempt is made to
retain the open system interconnection characteristic of the
Internet in the virtual address space through virtual BGP
neighborship. Multipath and Multipath TCP connections are also
recognized as being suitable for implementing the virtual BGP
neighborship. The IPv6 ULA addressing scheme is recognized as being
well suited for address assignment in the virtual address space.
A more detailed architecture is beyond scope as of now however an
attempt is made to spell out the design guidelines. A glossary at
the end contains the meaning of terms and definitions used in this
draft.
2. The Mathematical premise for the electromagnetic equivalent
The electromagnetic phenomenon observed in a waveguide is that the
wave propagation can be restricted to one dimension through total
internal reflection. At the critical angle the wave is split into
two or more waves. This is the principle behind multipath
propagation and also the basis for MIMO technology. Mathematically
this is similar to the path connectedness in a finite topological
space. The MIMO routing principles are thus applicable to wired
networks. MIMO is equivalent to Multipath. Therefore as MIMO routing
is cluster by cluster, multipath routing in wired networks is also
restricted to occur through clusters rather than between nodes.
3. Design considerations for the Internet architecture
Rather than viewing Computer communication as Host to Host as in
the traditional OSI and TCP models the computational and algorithmic
complexity of a network can be better understood by taking a step
back and viewing the communication as Machine to Machine.
On applying the principles of the Von Neumann bottleneck the
significant traffic can be identified as transit traffic between
ISPs and peer to peer traffic between ISPs. In other words the
Inter-AS traffic and the CsC traffic.
Deshpande Expires April 08, 2019 [Page 3]
Internet-Draft IP address reclassification April 2019
4. Complexities in analyzing the Internet as a topological space
4.1 Complexity of Computation
4.1.1 A local computation may not yield a global routing table which
can resolve global routing problems.
4.1.2 OSPF computation is evenly spread through the area or the core
AS.
4.2 Complexity of Algorithms
4.2.1 OSPF is based on Heap sort which is a maximally efficient
priority queue based on the heap data structure
4.2.2 OSPF redistribution repeats the advertisement of routes. A
classful boundary exists between areas as OSPF reoriginates
summary routes at an ABR
4.2.3 The above constraints bring about restrictions on
redistribution,re-routing, multipath routing due to the classful
queuing and addressing limits.
4.2.4 BGP selects and inserts certain routes (path selection
attributes) and merges routes. Therefore BGP can be considered as
having characteristics of selection, insertion sorts as well as
merge sort.
4.3 Complexity of Connectedness
4.3.1 Path connectedness in a finite space acts as a limitation
for multipath routing. Thus multipath routing in wired networks
need to evolve from MIMO routing.
4.3.2 A Tree is a (Un)Directed Acyclic Graph (DAG).
4.3.3 A Polytree (sort of a tree on top of a tree) is a DAG whose
underlying undirected graph is a tree (Refer Figure 3).
4.3.4 In order to design the Internet architecture the acyclic
aspects of a Tree structure must be considered.
4.3.5 DAG traversal can be performed in-order, pre-order,
post-order and in-level.
4.3.6 The IBGP full mesh is similar to a strongly connected
component in a DAG.
4.3.7 Critical path analysis is needed to enhance the Internet
architecture.
4.3.8 Features such as Transitive reduction and Critical path
Analysis should resolve the Internet routing, congestion and
convergence challenges.
Deshpande Expires April 08, 2019 [Page 4]
Internet-Draft IP address reclassification April 2019
4.4 The Problem of Observability
The above complexities of Computation, algorithms and connectedness
are bounded by an AS. Thus all must be concurrently observed at
multiple provider edge points on an AS to serve any purpose from a
control plane perspective.
Observability can be more clearly understood through the concept
of a virtual state that is assumed to be occurring in Virtual BGP.
This is similar to the BGP modes Read-only, Calculating best path,
and Read and Write.
+--------------+ +--------------+
| | | |
| Readable | | Observable |
| +-------> |
| | | |
+------^-------+ +------+-------+
| |
| |
+------+-------+ +------v-------+
| | | |
| Writable | | Functionable |
| <-------+ |
| | | |
+--------------+ +--------------+
Figure 1: Observability
5. Internet architecture based on the design considerations
The significant traffic is controlled by BGP and Route
reflectors. The flow of this significant traffic traverses a
hierarchical tree structure through various tiers of the service
provider network. Therefore it can be inferred that the traffic is
flowing in top-down(north-south manner). In order to introduce
parallelism (east-west traffic) for this significant traffic,
Multipath TCP, dynamic path recalculation and re-routing by virtual
redistribution(transit reduction) through RR clusters are feasible
techniques. These techniques can be implemented within an AS. But
due to the problem of Observability the analytical data needed for
these techniques is present at the provider edges of the AS. Due to
this point presence at various edges of an AS and the classful queue
and algorithmic boundaries as described previously, a control plane
in a separate address space is needed. The complex plane
characteristics of the topological space indicates that the new
address space needs to be a virtual address space.
Deshpande Expires April 08, 2019 [Page 5]
Internet-Draft IP address reclassification April 2019
The virtual address space can facilitate pre-ordering of flows,
pre-establishment of connections and pre-originating of routes. The
virtual address space can also pre-classify QoS for the significant
traffic.
There is an implicit redundancy between distributed firewalls.
This suggests that virtual redistribution is feasible. Virtual
redistribution is a pre-origination and re-origination of a route as
usually happens on an Area Border Router in OSPF. However in the
IBGP Core the pre-origination and re-origination must occur at a
Route Reflector through clusters. However the reorigination is for
a route or a set of routes already present in the routing table to
follow an alternate feasible path.
+--------------+-----------------+--------------+
| | | |
| | | |
| Process | Application | Process |
| | | |
| | | |
+-----------------------------------------------+
| | | |
| | | |
| Host | Transport | Host |
| | | |
| | | |
+-----------------------------------------------+
| | | |
| | | |
| Node and | Internet | Node and |
| Cluster | | Cluster |
| | | |
+-----------------------------------------------+
| | | |
| | | |
| Media | Link | Media |
| | | |
| | | |
+--------------+-----------------+--------------+
Figure 2:
TCP/IP Model with different communication functions at each layer
Deshpande Expires April 08, 2019 [Page 6]
Internet-Draft IP address reclassification April 2019
However a major challenge exists at the boundary of the AS due to
closure property. There exists a boundary value problem or in other
words the boundary between EBGP and IBGP needs to be analyzed as a
closed set. Therefore a unique mapping is needed at each point that
connects to the Virtual address space at the AS boundary. As the
critical network information is at the boundary of the AS the
virtual address space needs to connect to each AS boundary on at
the most 2 to 3 points for each AS. The Data folds onto itself at
the AS boundary.
+--------------------------------------------------------------------+
| +--------------------------------------------------------+ |
| | Global Segment Controller (AS or Domain) | |
| +--------------------------------------------------------+ |
| |
| Virtual Address Space |
| +-------------------------+ +---------------------------+ |
| |Global Segment Controller| |Global Segment Controller | |
| +-------------------------+ +---------------------------+ |
| +-----------------+ +-------------------+ +-------------------+ |
| | Local Segment | | Local Segment | | Local Segment | |
| | Controller | | Controller | | Controller | |
| +-----------------+ +-------------------+ +-------------------+ |
+--------------------------------------------------------------------+
| | | Virtual BGP neighbor-| |
| | | ship IPv6 ULA links | |
+------+ | | | with Multipath TCP | |
|PoP +-v-----------+ | | +-----------------v-----+ |
+------+ Tier 2 N/W | | | ^ | |
+------+ +-------------+ Tier 1 N/W | |
|PoP +------+------+ | | | | |
+------+ | | | +------------+----------+ |
| | | | |
| | +---v----+ +-------v----------+ |
+----------> | ^ | |
| | IXP +-----+ Tier 2 ISP <---+
| +--------+ +------------------+
+-----v----------+ +-------v----------+
+--+ Tier 3 ISP +-----> Tier 3 ISP +--+
| +----------------+ +------------------+ |
+---------------v-----------------------------------------------v----+
| Internet Users |
+--------------------------------------------------------------------+
Figure 3: Internet architecture with Virtual address space
Deshpande Expires April 08, 2019 [Page 7]
Internet-Draft IP address reclassification April 2019
Thus by introducing virtual neighborship via virtual EBGP
neighborship between local and global controllers and virtual IBGP
neighborship within local and global controllers in the virtual
address space the Internet can still retain its Open system
characteristics. This circuvemtion of the closure property is by
k-nearest neighbor algorithm. The local and global controllers are
tightly coupled with the nearest neighbors as identified through the
routing data set and loosely coupled with farthest neighbors. In
this manner the Open system interconnection characteristic of the
Internet is retained. By incorporating a local and global controller
label in every IPv6 packet a routing data set can be computed at the
Controllers which can dynamically detect which controllers are
loosely coupled and which controllers are tightly coupled. The local
and global controllers pairing and virtual EBGP neighborship
segregates the virtual address space facilitating proper
administrative control by different service providers.
The virtual address space should only be utilized on a best effort
basis for transit stability and peer to peer stability. Critical path
analysis is mandatory. The virtual address space can facilitate a
highly parallelized redundant traffic control system.
Implementation of the virtual neighborship through EBGP would
require another address family. For convenience it can be called
as Virtual address family. As the Virtual address space facilitates
a highly parallelized traffic control system, Virtual neighborship
needs redundancy between each node. This capability can be
implemented through Multipath TCP, and BGP Multihop.
+---------------------------------------------+
| Virtual address space |
| +-------------+ +--------------+ |
| | | | | |
| | Global | | Global | |
| | Controller | Loosely | Controller | |
| | | Coupled | | |
| | <------------> | |
| | Virtual | Coupling | Virtual | |
| | IBGP | depends on | IBGP | |
| | | K-NN | | |
| +-----^-------+ +-------^------+ |
| | Virtual EBGP | |
| | Neighborship | |
| | | |
| +-----v-------+ +-------v------+ |
| | | | | |
| | Virtual | | Virtual | |
| | IBGP | Tightly | IBGP | |
| | | Coupled | | |
| | <------------> | |
| | Local | | Local | |
| | Controller | | Controller | |
| | | | | |
| +-------------+ +--------------+ |
+---------------------------------------------+
Figure 4: Virtual BGP Neighborship in the Virtual address space
Deshpande Expires April 08, 2019 [Page 8]
Internet-Draft IP address reclassification April 2019
6. IPv6 address assignment for the Virtual address space
The IPv6 ULA address blocks match the requirements of the Virtual
address space perfectly except that the address requirement is not
for sites but within AS and between Service provider networks.
fc00::/8 address block can be assigned for virtual EBGP sessions
between Controllers as the block was also intended for global
allocation.
fd00::/8 address block can be assigned for virtual IBGP sessions
within a Controller as the upper half (fd00::/8) is used for
"probabilistically unique" addresses in which the /8 prefix is
combined with a 40-bit locally generated pseudorandom number to
obtain a /48 private prefix. The way addresses in fd00::/8 are
chosen, means that there is only a negligible chance that two AS
that wish to merge or communicate with each other, will have
conflicting ULA addresses.
Additionally a local and global controller label must be present
in every IPv6 packet a routing data set can be computed at the
Controllers which can dynamically detect which controllers are
loosely coupled and which controllers are tightly coupled.
+--------------+--------------------+----------------------+
| | | Segment Controller |
| Version | Traffic class | Label (Local and |
| | | Global) |
+--------------+---------+----------+--------+-------------+
| | | |
| Payload length | Next header | Hop limit |
| | | |
+------------------------+-------------------+-------------+
| |
| Source Address |
| |
| |
+----------------------------------------------------------+
| |
| |
| Destination Address |
| |
+----------------------------------------------------------+
Figure 5:
IPv6 with Local and Global Controller label replacing the Flow
label
Deshpande Expires April 08, 2019 [Page 9]
Internet-Draft IP address reclassification April 2019
7. Glossary of terms and definitions:
Node: A redistribution point having one or more Network interface
cards with addresses.
Host: A Computer is a node connected to a Computer network and
assigned a network address.
Abstract Machine: An abstract model of Computation used for
analyzing the complexity of algorithms.
MIMO Routing: Routing a cluster by cluster in each hop, where the
number of nodes is larger or equal to one.
Path Connected space: A path connected space is a stronger notion
of connectedness. Every path connected space is connected. In a
finite connected space a connected space is the same as path
connected space.
Transitive reduction: a transitive reduction of a directed graph D
is another directed graph with the same vertices and as few edges
as possible, such that if there is a (directed) path from vertex v
to vertex w in D, then there is also such a path in the reduction.
The Von Neumann bottleneck(as described by John 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 word through the Von Neumann bottleneck, and much of that traffic
concerns not significant data itself, but where to find it.
Deshpande Expires April 08, 2019 [Page 10]
Internet-Draft IP address reclassification April 2019
8. Security Considerations
A more robust security model can be built around the Virtual
address space.
9. IANA Considerations
This document describes the need for IP address space
reclassification
10. Conclusions
The IPv6 address space reclassification into a Physical address
space and a Virtual address space is proposed. The mapping between
these two occurs at the BGP AS Boundary. Together these two address
spaces provide the ability to build an ideal Topological space for
the Internet which facilitates a highly parallelized redundant
traffic control system.
11. References
11.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.
[RFC3513] R. Hinden, S. Deering,
"Internet Protocol Version 6 (IPv6) Addressing Architecture",
RFC 3513, April 2003.
[RFC6182] A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar,
"Architectural Guidelines for Multipath TCP Development", RFC 6182,
March 2011.
[RFC4864] G. Van De Velde, T. Hain, R. Droms, B. Carpenter,
E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
Deshpande Expires April 08, 2019 [Page 11]
Internet-Draft IP address reclassification April 2019
11.2. Informative References
Daniel Fischer, David Basin and Thomas Engel
Topology Dynamics and Routing for Predictable Mobile
SETL for Internet Data processing by David Bacon
https://cs.nyu.edu/bacon/phd-thesis/diss.pdf
12. 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 April 08, 2019 [Page 12]
Internet-Draft IP address reclassification April 2019