Research initiatives to redesign the Internet are popping up all around the globe. Some claim that the Internet must be redesigned from the information point of view. This approach goes under the banner of information-centrism. In the other hand, other initiatives claim that the design must be centered on the services, i.e. the service-centrism or the Internet of services. And there are also those focusing on decoupling host identifiers from locators to improve mobility support. Which is the right path to follow? We contend that none of them alone, but instead, to integrate synergistically them all. We call this approach the Internet of information and services.

1. Internet of Information and Services
(IoIS)
Antônio Marcos Alberti, Rodrigo Carneiro Brandão, Agostinho
Manuel Vaz, Bruno Magalhães Martins
Instituto Nacional de Telecomunicações - Inatel
510 João de Camargo, Santa Rita do Sapucaí, Minas Gerais, Brazil
alberti@inatel.br
http://antonioalberti.blogspot.com

2. Outline
• Contextualization
• Design Principles and Choices
• Architectural Components
• Highlighting the Architecture by an Example
• Related Work
• Conclusion

3. Contextualization (1/2)
• Research initiatives to redesign the Internet are popping up all
around the globe.
• Some initiatives focus on information exchanging, a.k.a.
information- or content-centric design, e.g. content-centric
networks like NetInf, CCN, PSIRP, NDN.
• Others, focus on service orchestration, a.k.a. service-centric
design, e.g. everything-as-a-service or Internet of Services (IoS)
approaches, like SOA4ALL, CASCADAS, S-Cube.
• And, there are those concerned with mobility and multihoming
support, a.k.a. ID/Loc splitting approaches like MOFI.

4. Contextualization (2/2)
• Is there a the right path to follow?
• Argument: Why not to integrate them all?
• We call this approach the Internet of Information and Services
(IoIS).
• The IoIS paradigm is already being employed on a broad
architecture called NovaGenesis.
• This paper proposes a conceptual architecture based on this idea.

5. Design Principles and Choices (1/2)
• Identification of architectural residents
• Relate legible and self-certifying names
• Dynamic compose-ability and hierarchical modularity
• Resolve indirections generically and recursively
• Use publish/subscribe paradigm
• Accommodate search and discovery
• Cover social relationships among entities

6. Design Principles and Choices (2/2)
• Accommodate the growth on interactivity
• Design for built-in security, privacy, and trust
• Accommodate neutrality, openness, diversity, flexibility, and
extendability of services and applications

7. Architectural Components (1/2)
• HTS (Hash Table System): A set of processes that stores name-
based bindings among entities.
• GIRS (Generic Indirection Resolution System): A process used
to decide the most appropriate Hash Table to store some name-
based binding.
• PSS (Publish/Subscribe System): It does the rendezvous between
publisher and subscriber.
• OBS (Orchestration Broker System): It helps simple services to
search, discover, negotiate, and contract service partners.

8. Architectural Components (2/2)
• RS (Reputation System): It is responsible to determine entities
reputation based on the feedbacks received from partners in
established SLAs.
• DS (Domain System): It is aimed to actively represents all the
systems in a domain.
• SDS (Search and Discovery System): It performs recursive
subscriptions to the PSS and filters results according to
semantics and context.

9. Highlighting the Architecture by an Example
Semantics
Broker to
rich search and
Service Service Active domain store ID-based
discovery
instance discovery andGIRS selects the
representation bindings.
(3) The GIRS selects the
(7) The (5) The SDS subscribe the names
Storage of ID- SLA (2) The PSS The PSS the bindings
(6) forwards
appropriate HTS, which storesthe
appropriate HTS, which gets
based bindings. establishment. forwardsdomain GIRS “Message”, “Service”, and
to the to Secure pub/sub of
GIRS. Service
the binding.
related binding. ID-based bindings “Message Service”.
Storage of ID- reputation
based bindings. management
3, 7 2, 6 5
G
H H O H P S
Service D Service I R
T T B T S D
1 S 2 R S
S S S S S S
S
8
4
1
Op. System Operating System Operating System
Hash Table (8) The SDS 2 publishes the bindings:
(1) Service receives the bindings and
(9) The SDS answersthe SDS
(4) The Service 1 asks the Service 1 with
ID Other IDs about a “Message Service”. 9 filtersDescriptorrelated to the word
Host the one
< ID, Software >, < ID,”Message” >,
the Service 2 <ID, Descriptor> binding. < ID,”Service” >, < ID,”Message Service” >ID.
“Message”. It subscribes the Service 2
ID Information Object
Continuing:
The Service 1 publishes an SLA.
Host
The Service 2 subscribes the SLA. Hardware
The Service 2 publishes it again with its
ID, accepting the agreement.

10. Related Work (1/2)
• Only three closely related works have been considered:
• Expressive Internet architecture (XIA).
• Scalable and adaptive Internet solutions (SAIL), which includes
network of information (NetInf).
• Component-ware for autonomic situation-aware communications,
and dynamically adaptable services (CASCADAS).

11. Related Work (2/2)
Aspect IoIS XIA NetInf CASCADAS
Bindings among legible Self-certified names
Similar feature, but right
and self-certified and legible Does not provide
Naming now limited to hosts,
names for any entity information as explicit mechanisms.
services, and content.
and content. metadata.
Transportation of
Supports traceability
ID-based traceability correct content from Does not provide
Traceability of content
to all residents. the right service, at the explicit mechanisms.
ownership.
right host.
Pub/sub. Self-certifying Pub/sub. Self- Social control for self-
Security Self-certifying IDs.
IDs. certifying IDs. preservation.
Based on published Specific pub/sub
Search and Published names and
Discovery ontology and Similar feature. protocol for service
metadata.
descriptors. search and discovery.
Autonomic self-
Distributed (per se) or Does not cover explicit Autonomic life-cycle
Compose- management of
ability centralized (via OBS) service orchestration management of
services is supported
orchestration. mechanisms. services.
by 4WARD INM.

12. Conclusion
• Our proposal cohesively integrates information- and service-
centric approaches, ID/Loc splitting, pub/sub paradigm, search and
discovery, besides other ingredients, in an unique architecture.
• Compared to the related work, IoIS addresses:
• Naming and traceability issues not covered in CASCADAS.
• Dynamic ID-based orchestration and life-cycling management that
is missing on XIA.
• Integrated information and services life-cycling capabilities.

13. 감사합니다!
Thank you!
Obrigado!
Antônio Marcos Alberti
Instituto Nacional de Telecomunicações - Inatel
510 João de Camargo, Santa Rita do Sapucaí, Minas Gerais, Brazil
alberti@inatel.br
http://antonioalberti.blogspot.com