3.3 FIFu: Enabling Future Internet Interoperability
3.3.2 Intelligence layer
The intelligence layer controls and supports the FIXP operation. It is composed by the Future Internet Controllers, which hold two sources of knowledge: (i) a list of the FIXPs deployed throughout the Internet; and (ii) a repository of mappings between identifiers of resources in different architectures used by FIXPs to convert messages between protocol stacks. Following this approach, the FIFu framework aims at leveraging a more flexible and faster approach to accommodate new network architectures and how they are interconnected without requiring to manually configure each FIXP.
The FICs control, assist and synchronize the operation of the adaptation layer. Their tasks include resource monitoring and configuration of the architecture protocol endpoints supported by each FIXP. To achieve their goal, the FICs are able to discover the capabilities of the underlying FIXPs (such as their hardware specifications - e.g., CPU, memory, network interfaces, etc), the currently supported network architectures/protocols, to which network architecture(s) they are connected to and to obtain statistics about the traffic being converted. This information can be acquired using two strategies: (i) by polling each FIXP periodically; and (ii) by subscribing a set of events (and/or pre-configuring thresholds) on the FIXP which, whenever they occurred (and/or are crossed), generates a notification towards the FICs.
For example, the FIC can configure the underlying FIXPs to periodically notify about the bandwidth usage on each polling period or to trigger a notification whenever the CPU or memory usage crosses a given threshold. This information can then be leveraged to (re)configure the FIXPs, optimizing their operation and allowing a dynamic adaptation of the network according to its current conditions, as well as to augment the capabilities of the FIXP with the understanding of new protocols by installing new architecture protocol endpoints.
FICs also act as a hierarchical distributed mapping resolution system, managing the identifiers of the resources on each network architecture. As such, they are responsible for creating, storing, managing and maintaining the mappings between resource identifiers on different network architectures, while providing a resolution service to retrieve the mapping related information whenever requested.
The logical hierarchical organization of the FICs, regarding their operation as a mapping resolution system, is divided into three levels, as depicted in Figure 3.6:
1. Root level: is the highest level of the resolution system, being queried to obtain the network architecture level FIC;
2. Network Architecture level: creates and maintains foreign URIs belonging to the scope of network architecture they are responsible for and manages their distribution across the URI level FICs; and
3. URI level: the lowest level, used for storing the mappings between URIs on different network architectures.
Nevertheless, information of the different levels can be cached and distributed across different FICs, easing its scalability, load-balancing and redundancy.
Root FI Network Architecture 1 (e.g. IP) FI Network Architecture 2 (e.g. NDN) FI Network Architecture n ... Root Level Network Architecture Level URI Level ... ... ...
Figure 3.6: FIC (mapping system) logical topology
Even though the resource provider can preemptively register mappings for its resources, foreign URIs can be automatically generated by the FIC and mapped to its correspondent URI on the original network whenever needed. Upon the reception of resolution requests for a given URI, if a mapping does not exist, the correspondent Network Architecture level FIC responsible for the foreign architecture (which resolution request was made) generates the URI to be used in the foreign architecture. The generated URI is then delivered to the requester and stored in the appropriate URI level FICs.
FIXPs (or other FICs) can then resolve foreign URIs into their original form and vice versa. This resolution can be either iterative or recursive in a similar way to DNS operation modes. In iterative queries, if the FIC does not have the required information, it replies with a referral to another FIC that may have the information. In turn, in recursive queries, the FIC replies with the requested mapping or an error message. Therefore, if the FIC does not have the required mapping information, it recursively requests other FICs until it gets the desired information or until the query fails.
Figure 3.7 presents the signaling used by the FIXP to resolve foreign URIs into their original form and vice versa.
For requesting the resolution of a given foreign URI into its original form, the FIXP requests the resolution of the foreign URI towards its local FIC (message 1 in
3.3. FIFu: Enabling Future Internet Interoperability 57
Figure 3.7: Resolving URIs inside FIFu framework
Figure 3.7), which, in turn, requests the resolution towards the Network Architecture level FIC (message 2 in Figure 3.7). If the Network Architecture level FIC is not known, the request is forwarded towards a Root level FIC that will then return the referral to it. In this case, the Network Architecture level FIC is selected based on the scheme of the foreign URI. The Network Architecture level FIC returns a referral to the URI level FIC where the mapping is stored (message 3 in Figure 3.7) and, subsequently, the local FIC requests the resolution towards it (message 4 in Figure 3.7). Finally, the URI level FIC replies with the original URI (message 5 in Figure 3.7), which is then delivered to the FIXP (message 6 in Figure 3.7).
For requesting the mapping of a given URI on a specific network architecture, the FIXP can request its resolution using the same procedure as described above but, in this case, also identifying the target architecture.