rina sdn-2016 mobility

Naming, addressing, mobility in RINA


Eduard Grasa, FP7 PRISTINESDN World Congress 2016, The Hague, October 2016

Naming, addressing, mobility in RINA 2

What is H2020 ARCFIRE doing?

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


4

Implications for multi-homing


G

A

B

C E

D

F

H

1

26

5

8

3 14

1817 16

15

19

21

13

209

11

10

12

4

7

22

G

A

B

C E

D

F

H1

2

3

1

2

1

3

4

123

12

3

1 2

3

1

1

22

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)


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

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

• Each application can use the DIF that 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

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


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)

9

Demo: renumbering in a single DIF

MADLIS

DUB

LON

PAR

BRU

AMS

LUX

BERN

ROM

VAL

LJU

ATH

NIC

ANKSOF

BUCBUDZAG

VIE

BER PRA

COP

OSLOSTO

TALRIGA

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

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


Thanks for your attention!http://ict-arcfire.eu

http://pouzinsociety.org

12

http://ict-arcfire.eu/

http://pouzinsociety.org/