Adapting our Internet to our usages
From IUCG - Internet Users Contributing Group
to be reviewed
Adapting our Internet to our own usages
The world's digital ecosystem (WDE) is made of all our interconnected processors. We, therefore, are its co-owners. As such, we may want to understand what the WDE must do to adapt to its own growth and how this affects the Internet which is one of its main networking tools.
The need for a model
The WDE involves three fundamental architectural planes. They can be associated to the exchanges of data (the binary flow), objects (ex. structured packets), and content (information). In order to support these exchanges as standardizers, engineers or users, we have progressively identified or accepted functional layers. Subsequently, we have built, implemented, or developed specialized technologies and applications including the
Internet technology (Internet Engineering Task Force - IETF) and the Web (World Wide Consortium - W3C)
In this process, we carried simplifications that are planes, layers and technologies violations: something was placed at a wrong location because it was easier, cheaper, and "it worked". However, violations do not scale; at some stage nothing is broken but what "worked" until now does not work any more. This phenomenon is why the Internet technology today faces several non scaling violations which must be fixed within the addressing, routing, convergence and governance areas.
There are two parallel traditional ways to investigate how to scale: analysis and experimentation. For example, NATs are an experimental input from the users about growth and address scarcity. The very slow deployments of IPv6 or ENUM, the disinterest in IDNs while Multilingualism is an international priority are other inputs. They are to be compared with the various analysis debated on the ways these three planes are/could be supported. The final result should be a more adapted way to usefully describe the central information (schemata) that shapes each relational model (net centricity) we could build upon in the aforementioned areas, within the diversity of the global communications continuity (multicentricity).
Inputs from the past and Influences from the present
The initial analysis/experimentation by Louis Pouzin (catenet doctrine supported by the French Cyclades network) led to a decentralized "network of NETWORKS" approach adopted by the American Department of Defense (DoD). Each network had its own addressing, routing and naming. Progressively, with Vint Cerf and Jon Postel, it became the "NETWORK of networks" with a unified centralized addressing, routing and naming documented by the IANA Internet central repository (Internet Assigned Names Authority). This turned out to be essential to the TCP/IP "convergence".
This sequence of events was documented in standards, propositions, and best practices (RFCs) published by the Internet Engineering Task Force (IETF) in order to "influence the way people design, use, and manage the Internet" (RFC 3935), thereby "influencing" us.
This RFC system supports end to end logic interoperability, atop of plug to plug electric interconnectivity. This works well as long as brain to brain semantic interintelligibility is to be serviced in a rudimentary manner and routing has no other constraint than to usually work. This was the case as the initial system implementation was based upon a default situation where plug, end and brain can be associated to the same and fixed location.
Other lessons from the past we should take into consideration come from the two previous worldwide used technologies for public services: Tymnet and OSI, and of their relations with other technologies such as radio, telephone, ethernet, fax, telex. In fact, we observed a technology ambition down grading while the WDE expanded. This allowed more and more people to interconnect at lower cost but also at lower quality of service (QoS) as we can observe it with spam, spoofing, phishing, etc.. Based on all the acquired experience, we can now return to more user-centric and service-oriented solutions to address virtuality, mobility, itinerary management, and multi-centricity demand by technologies interoperation and convergence, and the emergence of the semantic internet and metacommunications.
Virtuality, Mobility, Itinerary, Multicentricity
Virtuality can be described as brain roaming. It has been partly patched through virtual hosts, redirections, naming mnemonics, lack of authentication, NATs, English core internationalization, etc.
Mobility can be described as end roaming from plug to plug. It is a complex issue because, by essence, it is not fixed and local. Virtuality over Mobility becomes very complex.
"Complex" and "very complex" correspond to classes of architectural approaches (RFC 1958 and 3439), the last one not yet being documented by any RFC. More over, this increased complexity introduces new routing requirements we will discuss concerning itinerary management. The technology convergence throughout the WDE extends the problem to interoperability of the technologies: their multi-centricity (information on the network and its ability to connect and initiate and maintain dialogue based upon data obtained on a core to core basis, whatever the involved technologies).
All this information boils down to the observation and evaluation of the need for three universal orthogonal addressing systems supporting Fixity, Mobility and Virtuality. In turn, there is also a need for an inter/trans-technological routing computation (itinerary) and management supported by a common network computable ontology metastructure and its related tools.
The first question is the manner in which these addresses are to be documented. Secondly, how are they to be presented to routing? Thirdly, the routing architectures for which routing services must be determined finally, how will all this enter the semantic processing area.
Addressings
An address is a lasting or dynamic way to document a destination or an origin. There are two forms of addressing: the addressing from the point of view of the destination and from the point of view of the origin. In the Internet culture, the first form uses the term "addresses", and the second the term "names". One relates them through a “resolution process" (such as provided by a DDDS (Dynamic Delegation Discovery System) of which the domain name system (DNS) is an instenciation).
The Internet initial IPv4 addressing system was based upon the idea of Fixity with naming and routing being managed by fixed tables. This method works when plug, end, and brain are unique and stable at the same network location with a unique class of users. This is a default situation, where most of the architectural parameters are defaulted to one (one namespace, one addressing plan, one net centricity [by IANA], one language [English], etc. which permits calling it the "mono-Internet".
Network growth demanded that naming be managed more dynamically. Therefore, the initial Host.txt fixed table was replaced by the DNS. This event created a need for more addresses. Up to this point, HTTP.1.1, IPv6, and NATs, were conceived as different ways of extending the IPv4 addressing. They are designed to support neither mobile ends nor ubiquitous brains. IPv4 addresses initially were plug addresses used as host addresses extended through naming to virtual hosts. The initial assumption was that the size of the IPv6 address could support in a similar way the address of the plug (net) of the end (host) and of the brain/application (interface ID).
However, even if the IPv6 32 Hexas offer enough room, using them along the same practice as for the IPv4 namespace, in order to build a unique addressing namespace documented neither the decentralized end roaming (Mobility) nor the distributed brain/application roaming (Virtuality). This information is lacking in what addresses transmit to the routing function/service to establish the itinerary that the data flow must follow.
How to present the missing information to routing?
Presenting the missing information to routing will be achieved by presenting three relative, absolute or mixed orthogonal address segments for Fixity, Mobility and Virtuality conceived as three independent layers. These layers will correspond to Network, server, and user agent/application. The actual organization of the used formats will then depend on the topology of each case as well as the practical technology, availability, developments, and convergence capacities.
We see that "absolute Fixity + relative Fixity" (the default possibility to change of Host from time to time) works well in IPv6 but has difficulties to scale to total Mobility (such as for a Mobile phone). This observation means that "absolute plug Fixity + absolute end Mobility" is a general solution which respects the Fixity of the networks (operators) common to Tymnet, OSI (X.121) and the Internet, and matches the needs of mobiles (as mobile phone network support).
Virtuality can be addressed in the same manner by an absolute address (for example, a national SSN - social security number) when a unique brain/application is targeted or by a local relative addressing for standardized access grids (standardized registry and database direct access, plug and play, etc.). .
We then have the most common addresses made of the three orthogonal absolute network + absolute or relative host + absolute user or relative application. The final presentation may then be compressed or encrypted.
How to deliver that information to routing?
The worked out addressing (origin and destination) payload must then be delivered to the routing system in a way that simplifies the transition from IPv4 as much as possible
The common current case of a fixed virtual host (fixed plug, relative end, relative application addresses) can be supported by IPv4 + overlay. The local addressing data are tricked into the IPv4 header and are to be decoded by two interconnected "enhanced NATs" or "LAB" (local addressing boxes). By reference to a proposition of Jim Flemming (which also involved obscure administrative conventions), it can be referred to as IPv8. This solution is not optimum, but it is easy and free to implement. It is also conceptually consistent with the limited locator (the IPv4 address) and identifier (the overlay) the IETF considers introducing in its eventual proposition. It is likely that if no other solution is made appealing to users, this solution may deploy and quickly propagate.
In every other case, the 32 Hexas of the IPv6 vector seem sufficient. Adding another vector and its container in the protocol is a proven solution (ex. MPLS) proposed by some to still extend the addressing information payload. This solution would support extended granularities in the three areas of addressing.
Due to the existing work on IPv6, using a multiple orthogonal numbering plans structure as a part of the IPv6 numbering space (dedicating one of the /3 blocks) seems to be a first stable and reasonable possibility. Further to Pekka Savola (Google, 2004) we can call it "IPv11".
Application Area
There is information we have not covered yet. Virtuality is usually exercised within a given application framework. It defines the virtual conditions of an application. This is something which has been stably addressed with the "port" information. No one so far has challenged that solution, except NATs as a trick to build more local addresses. This need is addressed by the three kinds of solution we investigated.
Computing the itinerary
In the current Internet, data flow between two brains, two ends and two plugs along pre-computed and/or manually entered tables (addresses and names) de facto cannot be dynamically optimized. This limitation means that the involved brains, ends, and plugs cannot chose or direct the itinerary of the data, objects, content they exchange, or even if they know they will be tapped.
Alternative itineraries are in increasing demand for any cast, multi-homing, load balancing, security schemes, etc. The current routing services are similar to those of postal services. The current need is for something similar to air travel in which users can chose their itinerary according to cost, dates, stop-overs, etc. and operators can organize alliances and different kind of services: 1st and Business classes, special rates, tours... (what translates as "externets" - external network look-alikes within the network to support multi-tier Internet, relational spaces, etc.)
There are several ways to describe an itinerary and several places to compute it. The strength of the Internet comes from being a dumb system (easy to manage and interface) with smart ends.
However, actually, ends are both the edge of the network and the user agents (terminals, hosts). Over time, the dumb network has become increasingly smart, particularly in regards to routing. This intelligence should actually be located on the edge as Open Pluggable Edge Interfaces (OPES) [introduced by the IAB and the IETF] and networked in Open Network Extended Services (ONES). Computing itineraries at the user edges would better respect the Internet architecture and would help take user routing demands into account. It would simplify the organization of externets and support different types of quality of services (QoS) and security schemes for phone, pictures, telemetry, alerts, military, etc..
An ultimate approach could be to have DNS and itinerary management merged into a single robust supervisory function. This function would compute itineraries using data broadcasted by the network switchers and gateways, authentication and demands by the origins, requests and authorization by the destinations, alert services in case of DoS, network incident, or emergency situations. Such a system could be an extended DDDS (the DNS is a DDDS). It would resolve domain names into the proper itinerary for each specific connection, or deny it. DNS caching is a time proven solution: caching itineraries, as we cache addresses today, would reduce the computing load. A new itinerary computation would simply result from removing the itinerary from the cache.
Restoring the routing paradigm
One of major problems faced by the Internet architecture consists in the common tendency to perceive a network as links between nodes and to mainly consider nodes. The NIMROD project illustrates this. It proposed three major concepts: the clusters of routers, the adjencies as the bandwidth between two nodes, and the map as "a graph composed of nodes and adjencies. Properties of the nodes are contained in attributes associated with them. Adjencies have no attributes".
This proposition is excellent with one change: to intervert attributed from "nodes" to "adjencies". In assigning attributes to nodes one obtains a static map of the network. In documenting the "adjencies" one has a dynamic traffic map one can easily modulate. One can use the concept of virtual adjencies to dynamically document traffic load (the more an adjency is loaded; the lowest is its documented bandwidth). One can also easily control the reporting nodes: there is an error situation if the two nodes describe differently their common adjency.
Also, one easily understands that a cluster made of different routers and adjencies are complex objects to documents. Yet, the different links to a router are not dependant on the inner complexity of a cluster. The graphs of an adjency based map do not make any difference between a single node and a huge cluster. It simply ignores the internal adjencies of clusters. If you consider the adjency AD=AB+BC, the properties of AD will be the least favorable properties of AB and BC. This permits each end to build the maps of its externets depending on the different virtual adjencies they negotiated throughout the internetwork. It also permits clusters to freely micromanage their traffic flow in using local alternate routing, load balancing, virtual adjencies document changes, etc.
It is possible to create long haul virtual multi-services clusters interconnecting distant networks and services, only known from each end as one single adjency of their clients' externets.
Centres/Community of Interests and Relational Spaces
Humans and computers have a multitude of centres of interest (COI) that they can individually or commonly (communities of interest) activate through a great variety of exchanges types. The WDE is to support them through equivalent adapted forms of relational spaces such as national, linguistic, thematic, local, family, private, personal, etc., which are actually our own "networks in the network of networks".
Relational spaces must adapt to the diversity of their underlying infrastructures, technologies, governances, etc.: TLDs, mailing lists, externets, intranets, extranets, readerships, user classes, thematic interests groups, services, technologies, archives, etc. and any other existing, intended, or possible stable or dynamic exchanges between users and/or digital artefacts.
This calls for:
- an adapted addressing systems in chronology, cosmography, geography, topology, linguistic, metadata, sociology areas,
- data of common good: referential organized and updated along the addressing system above, for an equal opportunity and documenting of the WDE, the various relational spaces, the context of each relation, and the personal point of view.
- a semantic interoperating system ("netix") for our relational continuity and its interrelated extended services (services for the networking of the content) that people's brainware (common how-to belief) and machines' software can commonly utilize.
Multi-centricity
The Internet has its own core network information centre (NIC): the IANA. Without the IANA to store common parameters, documentation, and root information, there would not be any Internet. Managing the IANA is actually the Internet Governance, and controlling the IANA as we currently see an attempt is actually controlling the network and indirectly its users and their usages. This is the same for each relational space. Relational spaces are structured and documented by their own referential centre to support its internal inter-intelligibility, both internally and externally (in the case of interlinkable NICs).
Documenting net centricity through a universal multilateral (multilingual, multimodal, multi-technology, etc.) distributed referential system (MDRS) is a priority to permit the external interoperability of all these relational spaces. Such an MDRS must both document the necessary registry servers and their schemata. One possibility is to use the ISO 11179 metaregistry approach. However, ISO 11179 does not yet support multilingualism and decentralized networking. Decentralized networking implies that the same metadata may take on different data values, depending on the entity of each registry occurrence, real time and data pollution phenomenon, etc. well experienced with the DNS.
Net-centricity can be understood as the degree of pertinent usefulness of the description of a relational space by its own referential system. The multi-centricity will be understood as the degree of pertinent interoperability, starting with discovery and interconnectivity, within a group of relational spaces, or the entire WDE.
The achieved multi-centricity is therefore the measure of the digital convergence. It is the very basis for the semantic ecosystem, which is the next step as, we prepare through the semantic interoperability of the computable ontologies of the MDRS.
Making this system multilingual (all the languages supported as English is by the current internationalized approach) means that all the concepts that we may use to document or define real and virtual objects properties and relational spaces characteristics are to receive a universal ID number (uninum), independent from languages, but supported by each language.
Interlinks
The Grid of these IDs will then be directly used by Netix at a concept rather than at a semantic level. This way we will be able to reduce multilingual semantic interoperability to a simple address interoperability issue.
Syllodata are the syllogisms which associate data (minor premises) to their metadata (major premises) in an MDRS information metadata/data "cortege". Interlinks are the address of the value to use at the interlink location in these syllogism. Para data are the data qualifying information in an MDRS "cortege". The use of conditional interlinks in syllodata permits to support semantic navigation, hence intelligent networking.
The interlink address discovery process will be offered by the DNS, or better by supervisor DDDS discussed above. This means that the routing vector towards usually interlinked registry servers will be cached, calling for no computation nor external resolution.
An interesting idea could be to use corteges of interlinks to support itinerary computation, which would the become a simple itinerary discovery comparable to the semantic information discovery process of the MDRS? An analysis of a DDDS support of MDRS corteges would however call for environmental information to be accepted, and much deeper analysis and testing.
Conclusion
Subsequently, we would be able:
- to fully support and serve brain to brain extended inter-intelligibility services and
- not to use digital addresses, navigating the net, for example, like Japanese cities, perusing a book, using a graphic pattern recognition
