Adaptation Layer

In document Interoperabilidade e mobilidade na internet do futuro (Page 76-79)

3.3 FIFu: Enabling Future Internet Interoperability

3.3.1 Adaptation Layer

The adaptation layer is composed by the Future Internet eXchange Points, intermedi- ary entities responsible for providing interoperability between different network archi- tectures, allowing the communication between endpoints deployed in different architec- tures. As such, the FIXPs, acting as gateways, emulate the communication endpoints of the original network architecture on the foreign architecture and vice versa, simul- taneously behaving as the destination and source of the messages (as represented in Figure 3.4).


NR C1 FI1-compatible messages FI2-compatible messages


NR' C1'

Figure 3.4: FIXP message conversion

As part of the adaptation process, FIXP entities receive messages from a given network architecture and convert them in order to be compatible with the destination architecture. As such, for each protocol, FIXPs are configured with information about the packet format and the semantic meaning of each packet field, allowing them to recognize and understand the existing protocols on each network architecture.

The provisioning of this information to the FIXP is conducted by the intelligence layer (i.e., the FIC), without requiring service disruptions or equipment replacement. For each supported protocol of each network architecture, the FIC deploys in the FIXP the running instance that will enable the latter to act as a source and destination endpoint in what concerns that protocol (i.e., the architecture protocol endpoint). Each architecture protocol endpoint is responsible for the following tasks:

❼ understanding the corresponding protocol/architecture;

❼ being able to receive, identify, process, create and send messages related with that protocol/architecture;

3.3. FIFu: Enabling Future Internet Interoperability 53 ❼ extract the content and related metadata (e.g., security level and QoS) from the

received message as well as to apply them to the created messages;

After configuring the FIXP with the architecture protocol endpoints, converting messages from one network architecture to another can be divided into three major operations: (i) address translation; (ii) signaling adaptation; and (iii) content adaptation. The processing workflow of incoming messages in the FIXP is presented in Figure 3.5.

Figure 3.5: FIXP message processing workflow

Whenever a new message is received, the FIXP inspects it, aiming to identify the L3 and above protocols (i.e., L3+ protocols) that compose the received message. Based on the protocols that compose the received message, it is redirected to the respective architecture protocol endpoint. In turn, since the architecture protocol endpoint emulates the destination endpoint of the received message, it verifies if the message needs to be converted and sent towards the destination architecture. If not, the message is handled internally according to the corresponding protocol stack. Otherwise, the URI

of the received message is computed (i.e., a unique identifier that comprehends all the spread resource identification information) and the associated payload and metadata extracted.

In the following step, the FIXP searches on its cache for a mapping related with the computed URI (i.e., URI[MsgOut]), which will then be used to generate the equivalent message in the destination architecture (i.e., MsgOut). If no mapping is found in the cache, the FIXP resolves the URI[MsgIn] with the FIC infrastructure in order to find its corresponding in the destination network architecture, being cached therein to avoid future resolutions. After discovering the destination network architecture and protocol to use (based on the scheme part of the URI[MsgOut]), the payload content is adapted if required. All this information (i.e., URI[MsgOut], the payload and metadata) is internally forwarded to the respective architecture protocol endpoint. The architecture protocol endpoint creates the protocol message using the URI[MsgOut], after which the payload is added and the metadata applied using the specific protocol procedures. Finally, the message is sent towards the destination network architecture.

In order to avoid the communication endpoint to be aware of any interoperability mechanism, and thus to fully achieve backwards-compatibility with existing applica- tions, contents may be required to be in compliance with the destination network architecture. An example of this need is the web browsing use case. Taking the exam- ple from Figure 3.2 and assuming that the client C1 is a web browser and the network resource NR is the homepage of a given website, the FIFu framework enables the web browser to fetch the homepage, which is deployed in a different network architecture. However, for the user to be able to continue navigating in the web page, URIs con- tained therein must be compatible and supported by both the user’s web browser and the network architecture (i.e., FI1). As such, if contents are not adapted to be in compliance with the destination architecture, subsequent requests for other resources in the web page may be discarded due to (i) the web browser or network stacks in the user device do not support the protocol required by the URIs; or (ii) the application and the device support the required protocol, but the network architecture to which it is connected does not. In both cases, the user is unable to continue navigating on that web page.

In this context, to avoid the need for resource replication explicitly for each network architecture, making the process transparent (or at least manageable) for the resource provider, the presented framework needs to be intrusive in the sense that the adaptation layer (i.e., the FIXPs) may need to change existing identifiers inside the payload of each message. As such, during message conversion, depending on the content type, the FIXP may inspect the message payload looking for resource identifiers (e.g., links in HTML pages) which are then replaced by compatible identifiers with the destination network

3.3. FIFu: Enabling Future Internet Interoperability 55 architecture if required.

In document Interoperabilidade e mobilidade na internet do futuro (Page 76-79)