Naming, addressing, mobility in RINA

Naming, addressing, mobility in RINA

Eduard Grasa, FP7 PRISTINE

SDN World Congress 2016, The Hague, October 2016

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

Naming & addressing in one slide

Application names: Assigned to applications. Location independent. Uniquely identify applicationwithin 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 certaincontext (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-idreceive receive a consistent treatment through the DIF).

Naming, addressing, mobility in RINA3

Implications for multi-homing

Naming, addressing, mobility in RINA4

G

A

B

CE

D

F

H

1

26

5

8

3 14

18

17 16

15

19

21

13

209

11

10

12

4

7

2

2

G

A

B

CE

D

F

H1

2

3

1

2

1

3

4

1

2

3

12

3

1 2

3

1

1

2

2

2

• Addressing the node instead of theinterface: 3-4x timerouting/forwarding table reduction!

• No need for special protocols tosupport multi-homing

Addresses assigned to interfaces (like in IP) Addresses assigned to nodes (like in RINA)

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

BS1.2.1

BS1.2.2

BS1.2.3

BS1.2.5

BS1.2.4

S-GW1.1.1

S-GW1.1.2

Serving

Area 1

BS2.2.1

BS2.2.2

BS2.2.3

BS2.2.5

BS2.2.4

S-GW2.1.1

S-GW2.1.2

Serving

Area 2

P-GW0.1.0

P-GW0.2.0

UE1.0.1

UE1.0.1

UE2.0.1

UE1.0.1

UE1.0.1

UE1.0.1

UE1.0.1

UE1.0.1

UE1.0.1

UE1.0.1

UE1.0.12.0.1 Example: Mobility within

a single DIF

Mobile network with multiple layers

BorderRouter

Core DIF

Under DIFs

BorderRouter

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 devicesand speed of mobility in different parts of the mobile network

• Each application can use the DIF it provides enough scope and QoS forits communication needs -> not restricted to the “top ones”

• All layers have the same structure and protocols, implementations can behighly optimized; overhead of adding new layers is minimal

Example with 4 levels (where needed)

Urban Sub-urban Urban UrbanDense Urban

BS DIF District DIFLegend

Metro DIF Regional DIF

• 4 levels of DIFs may not be needed everywhere (e.g. suburban, notenough density to require a district DIF).

• If more levels needed to scale can be added anywhere in the network

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 anabstraction of the network connectivity graph as they move (to minimizesize of forwarding tables in the DIF)

Naming, addressing, mobility in RINA 8

Demo: renumbering in a single DIF

9

MADLIS

DUB

LON

PAR

BRU

AMS

LUX

BERN

ROM

VAL

LJU

ATH

NIC

ANKSOF

BUCBUDZAG

VIE

BER PRA

COP

OSLO

STOTAL

RIGA

VILWAR

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

• 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 IPCPaddresses -> if IPCP addresses change, just issue a directory update

• E.g. current demo DIF uses a directory policy that replicates the directoryacross all IPCPs in the DIF (equivalent to distribution of link-state routinginfo). Many other policies are possible and adequate for differentenvironments (e.g. ARP-like, DNS-like, DHT-like, etc..)

How does this work? Nothing special (I)

PtP DIF

IPCPMAD

IPCPLIS

IPCPMOSDIF “Renumber”

Client 1

Server1

IPCP BER

PtP DIF PtP DIF

IPCP BERN

PtP DIF

• 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)

Naming, addressing, mobility in RINA

Thanks for your attention!

http://ict-arcfire.eu

http://pouzinsociety.org

12