1) The ARCFIRE project is experimentally validating the benefits of RINA technology through large-scale experiments on the FIRE+ testbed involving over 100 nodes across multiple distributed information fields (DIFs). 2) In RINA, application names uniquely identify applications, addresses are location-dependent synonyms used for locating applications within a DIF, and other identifiers like port-ids and connection endpoint IDs are used to identify communication endpoints. 3) RINA's naming and addressing model simplifies multi-homing and mobility by assigning addresses to nodes instead of interfaces, avoiding the need for special protocols and allowing mobility to be treated as dynamic multi-homing with expected failures.

1. Naming, addressing, mobility in RINA
Naming, addressing, mobility in RINA
Eduard Grasa, FP7 PRISTINE
SDN World Congress 2016, The Hague, October 2016

2. What is H2020 ARCFIRE doing?
Naming, addressing, mobility in RINA 2
Experimentally validate the real benefits of the
RINA technology,
leveraging the FIRE+ experimental infrastructure,
making compelling business cases that motivate
for its deployment and adoption
100+ nodes 10s - 100s of DIFs 1 week long exp.
DDoS attacks Multi-layer Mgmt Heterogen. access Polyservice networks
Experimental facilities RINA tooling for FIRE+ Procedures for RINA exp.
Converged operators Application developers End Users

3. Naming & addressing in one slide
Application names: Assigned to applications. Location independent. Uniquely identify application
within an application namespace. In general name a set (can have a single member).
Addresses: Location-dependent synonym of an App name. Facilitates locating the app within a certain
context (e.g. IPCPs in a DIF). Its scope is restricted to the DIF.
Port-ids: Identifies one end of a flow within a system (local identifier), only id shared with user.**
Connection endpoint ids (cep-ids): Identify the EFCP instances that are the endpoints of a connection.
QoS-id: Identifies the QoS cube to which the EFCP PDUs belong (PDUs belonging to the same QoS-id
receive receive a consistent treatment through the DIF).
Naming, addressing, mobility in RINA
3

4. Implications for multi-homing
Naming, addressing, mobility in RINA
4
G
A
B
C
E
D
F
H
1
2
6
5
8
3 14
18
17 16
15
19
21
13
20
9
11
10
12
4
7
2
2
G
A
B
C
E
D
F
H
1
2
3
1
2
1
3
4
1
2
3
1
2
3
1 2
3
1
1
2
2
2
• Addressing the node instead of the
interface: 3-4x time
routing/forwarding table reduction!
• No need for special protocols to
support multi-homing
Addresses assigned to interfaces (like in IP) Addresses assigned to nodes (like in RINA)

5. Implications for mobility
• Mobility is just dynamic multi-homing with expected failures
• No need for tunnels -> handovers trigger routing updates
• Addresses are just temporary synonyms -> IPCP name is stable
Naming, addressing, mobility in RINA 5
BS
1.2.1
BS
1.2.2
BS
1.2.3
BS
1.2.5
BS
1.2.4
S-GW
1.1.1
S-GW
1.1.2
Serving
Area 1
BS
2.2.1
BS
2.2.2
BS
2.2.3
BS
2.2.5
BS
2.2.4
S-GW
2.1.1
S-GW
2.1.2
Serving
Area 2
P-GW
0.1.0
P-GW
0.2.0
UE
1.0.1
UE
1.0.1
UE
2.0.1
UE
1.0.1
UE
1.0.1
UE
1.0.1
UE
1.0.1
UE
1.0.1
UE
1.0.1
UE
1.0.1
UE
1.0.1
2.0.1
Example: Mobility within
a single DIF

6. Mobile network with multiple layers
Border
Router
Core DIF
Under DIFs
Border
Router
Under DIFs
Border
Router
Interior Router
(Base Station)
Host
(Mobile)
BD DIF
(radio)
Under
DIFs
District DIF
Metro DIF
Regional DIF
Public Internet DIF
Application-specific DIF
Mobile Infrastructure NetworkCustomer Terminal
…
…
…
Under DIFs
Operator core
• Create as many DIFs as needed depending on density of mobile devices
and speed of mobility in different parts of the mobile network
• Each application can use the DIF it provides enough scope and QoS for
its communication needs -> not restricted to the “top ones”
• All layers have the same structure and protocols, implementations can be
highly optimized; overhead of adding new layers is minimal

7. Example with 4 levels (where needed)
Urban Sub-urban Urban UrbanDense Urban
BS DIF District DIF
LegendMetro DIF Regional DIF
• 4 levels of DIFs may not be needed everywhere (e.g. suburban, not
enough density to require a district DIF).
• If more levels needed to scale can be added anywhere in the network

8. Renumbering demo
• Goal: show an example of a use case enabled by a complete naming
and addressing architecture
• Since addresses are just temporary synonyms assigned to the node in
the layer (IPCP), renumbering is no problem (can be done live,
without impacting existing flows or new ones)
• Applications:
– Change addressing policy/scheme as network grows
– Consolidate two different addressing policies after merge
– Mobility: Keep addresses of IPCPs in mobile nodes aligned to an
abstraction of the network connectivity graph as they move (to minimize
size of forwarding tables in the DIF)
Naming, addressing, mobility in RINA 8

9. Demo: renumbering in a single DIF
9
MADLIS
DUB
LON
PAR
BRU
AMS
LUX
BER
N
ROM
VAL
LJU
ATH
NIC
ANK
SOF
BUCBUD
ZAG
VIE
BER PRA
COP
OSLO
STO
TAL
RIGA
VIL
WAR
MOS
N-flows
N-1 flows
• IPCPs change addresses randomly (change period uniformly distributed 30-60s)
• 4 flows (allocated by echo application), between:
– Lisbon-Riga / Dublin-Ankara / Valletta-Oslo / Brussels-Nicosia
• Show that address change is not noticed by applications using the DIF:
– Existing flows continue operating; new flows can be allocated

10. • Addresses are internal to the DIF, upper layers (applications or other DIFs)
never get to see them -> flow allocation is based on application names
• Each DIF has an internal directory to map application names to IPCP
addresses -> if IPCP addresses change, just issue a directory update
• E.g. current demo DIF uses a directory policy that replicates the directory
across all IPCPs in the DIF (equivalent to distribution of link-state routing
info). Many other policies are possible and adequate for different
environments (e.g. ARP-like, DNS-like, DHT-like, etc..)
How does this work? Nothing special (I)
PtP DIF
IPCP
MAD
IPCP
LIS
IPCP
MOSDIF “Renumber”
Client
1
Server
1
IPCP
BER
PtP DIF PtP DIF
IPCP
BERN
PtP DIF

11. • When an IPCP changes addresses, it needs to distribute the new address
through the routing system, so that other IPCPs will know how to forward
traffic to it, but still doesn’t deprecate the old address. Details on how to do it
depend on the routing policy used in the DIF.
– E.g. for link-state routing, the IPCP just advertises new LSAs with its new address
• After a while all IPCPs in the DIF will know how to forward traffic to the new
address. Then the IPCP can start using it. How? Just start using the new
address as the source address in all EFCP PDUs
– EFCP receivers in other IPCPs will notice the change and start using the new address
as the destination address of EFCP PDUs
• After a while all IPCPs in the DIF are using the new address, so the IPCP can let
the old address die. To do that, it just advertises the old address as
deprecated via the routing system.
– E.g. for link-sate routing, the IPCP advertises the LSAs with the old address as
deprecated (expired), so that the other IPCPs will remove it from their databases
How does this work? Nothing special (II)

12. Naming, addressing, mobility in RINA
Thanks for your attention!
http://ict-arcfire.eu
http://pouzinsociety.org
12