rina tutorial at etsi isg ngp#3

RINA TUTORIAL

Eduard Grasa on behalf of i2CAT, Waterford Institute of Technology, Boston University, Interoute, Telefonica27th July 2016

© ETSI 2014. All rights reserved

2

Goals

Discuss the structure of RINA (layers, components within a layer)

Disuss the main operational procedures of a RINA layer (data transfer, layer management)

Discuss how RINA can be applied to the design of a mobile network

© ETSI 2014. All rights reserved2

3

RINA structure


Host

Border router Interior Router

DIF

DIF DIF

Border router

DIFDIF

DIF (Distributed IPC Facility)

Host

App A

App B

Consistent API through

layers

IPC API

Data Transfer Data Transfer Control Layer Management

SDU Delimiting

Data Transfer

Relaying and Multiplexing

SDU Protection

Retransmission Control

Flow Control

RIB Daemon

RIB

CDAP Parser/Generator

CACEP

Enrollment

Flow Allocation

Resource Allocation

Routing

Authentication

State VectorState VectorState Vector

Data Transfer Data Transfer



Flow ControlFlow Control

Increasing timescale (functions performed less often) and complexity

Namespace Management

Security Management

4

Naming and addressing


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

5

Data transfer procedures


6

Layer management structure


Resource Information Base (RIB): Schema that defines the external representation of the set of objects that model the state of the IPCP (object names, attributes, relationships, allowed CDAP operations and their effects)

Common Distributed Application Protocol (CDAP): Application protocol that allows two applications to operate on the objects of each other’s RIB. Provides 6 operations (create/delete/read/write/start/stop).

RIB Daemon: Entity that processes incoming CDAP messages (delegating RIB operations to layer mgmt tasks) and generates outgoing CDAP messages from layer management tasks’ requests

7

Mobile network example

This is just an example to illustrate the main mechanics of how RINA can work in a mobile network environment -> it does not pretend to be a real design• Real design would exploit multiple layers

Assumptions• Similar structure to LTE networks, so that it is

easier to understand

• UE can only be actively connected to one** eNodeB at a time (seems to be a constraint of current mobile networks, right?)


8

Tutorial Example: RINA network similar to LTE

Voice Layer, Public Internet Layer, etc.. are layers allowing applications in the UE to communicate to other applications (equivalent to PDN)

Mobile network top-level Layer provides flows between the UEs and Packet Gateways (flows provided by this DIF equivalent to EPS bearer). Can perform mobile network-wide congestion control, routing, resource allocation, etc.

Multi-access Layer (radio). Radio DIF between the UE and eNodeB, responsible for radio resource allocation and to provide flows between UE and eNodeB supporting the mobile network top-level DIF (equivalent to RLC, MAC and PHY layers together).


Voice LayerPublic Internet Layer (or other)

Mobile network top-level Layer

Multi-access Layer (radio) Internal Layer

PtP Layer . . .UE

eNodeB S-GW P-GW

Op. Layer

PtP Layer

PtP Layer

Internal layer

PtP Layer . . . PtP Layer

8

9

Enrollment (UE attaches to the network)

Focus on the Mobile Network top level DIF


Multi-access Layer (radio)

eNodeBUE

IPCP IPCP

1. Allocate N-1 flow2. Establish application connection

(CACEP, includes authentication)1. M-CONNECT (UE to eNodeB)2. Authentication messages3. M_CONNECT_R (eNodeB to

UE)3. UE gets address and other

information required to operate on the DIF

4. RIB update (after enrollment)

Authentication = authentication, key agreement, setup of SDU Protection (encryption, message integrity)eNodeB could authenticate itself or delegate the procedure to another trusted IPCP or the Management System

10

UE enrolls to mobile network DIF without authentication, but only the MA in the UE is allowed to request the allocation of a flow, and only to the “NMS DAF” (which plays the equivalent role of the “control plane” in LTE)

MA at the UE allocates flow to the NMS DAF, and enrolls to the NMS DAF; which requires authentication and key agreement, and setup of SDU protection (at the MA and NMS-Auth processes)

After joining, other apps in the UE can allocate flows to destination applications

Example “LTE-style”


Multi-access Layer (radio)

eNodeBUE

IPCPIPCP

MME / Authenticating entity

IPCPMobile network DIF

MA NMS –Auth NMS DAF

11

Akamai DIF

Apps in the UE request flows to other apps (I)

UE has not joined any DIF providing access to “end applications”. A browser app in the UE requests a flow to the destination application http://portal.etsi.org, with flow characteristics X, Y, Z.

Request is processed by local IPC Manager, which asks DIF Allocator through what DIF is available the dest. Application

• DIF Allocator keeps a distributed map of application to DIF mappings (not enough time to cover details here)


Voice DIFPublic Internet DIF



PtP Layer . . .UE

Op. Layer

PtP Layer

PtP Layer

Internal layer


eNodeB S-GW P-GW

Browser

http://portal.etsi.org/

12

Akamai DIF

Apps in the UE request flows to other apps (I)

DIF Allocator resolves http://portal.etsi.org to the public Internet DIF. UE creates an IPCP, that requests an N-1 flow towards the “public Internet DIF” to the mobile network top level DIF.

Mobile network top level DIF resolves the “public Internet DIF” app name to the IPCP that is more convenient (public Internet DIF may be available from multiple P-GWs). Once the flow is allocated, IPCP at the UE proceeds to enroll with the DIF.

• Procedure is the same regardless what DIF the UE is joining (Akamai, voice, etc..)© ETSI 2014. All rights reserved

Voice DIFPublic Internet DIF



PtP Layer . . .UE

Op. Layer

PtP Layer

PtP Layer

Internal layer


eNodeB S-GW P-GW

Browser

IPCP

http://portal.etsi.org/

13

Apps in the UE request flows to other apps (II)

After enrollment the browser flow allocation request is processed by the public Internet DIF, and the flow allocated.

NOTE, this procedure can be tailored:• UE can be made to join the relevant DIFs / a default DIF after attachment to the

network (and not wait until an application makes a request)• Instead of using DIF allocator, user @ UE could configure what DIFs he would like

to join (similar to the APN settings today)© ETSI 2014. All rights reserved

Public Internet DIF



PtP Layer . . .UE

Op. Layer

PtP Layer

PtP Layer

Internal layer


eNodeB S-GW P-GW

Browser

14

Structure of the mobile network DIF(idealized example)


eNodeB eNodeB eNodeB eNodeBeNodeB

Tracking Area 1

Tracking Area 2

S-GW S-GWServing Area 1

eNodeB eNodeB eNodeB eNodeBeNodeB

Tracking Area 1

Tracking Area 2

S-GW S-GWServing Area 2

P-GW P-GW

UE

15

Forwarding at P-GW


P-GW is the destination of UL packets coming from UEs, so just send layer up

For DL packets: if UE’s address contains the serving area where the UE is located, and S-GW address contains service area it belongs to, P-GW just needs to store @ of neighbor S-GWs in its forwarding table, and forward to any S-GW in the serving area of the destination UE• If more than one S-GW possible, chose based on load, etc.

P-GW

S-GWS-GW

S-GWS-GW

16

Forwarding at S-GW


UL packets (dest @ is a P-GW): Just need to store the @ of neighbor P-GWs, and forward to them (1 hop)

For DL packets (dest @ is a UE): Keep next hop-addresses for all UEs in the serving area. Needs to be updated every time UE changes eNodeB; 2 approaches possible:• Autonomous/distributed (via e.g. link-state routing within the serving area) or• Centralized via the NMS DAF (MME recomputes the graph and modifies

forwarding rules in S-GWs)

P-GW

S-GW

P-GW

eNodeB eNodeB eNodeBeNodeB

17

Forwarding at eNodeB


UL packets (dest @ is a P-GW):• If attached to a single S-GW, forward there

• If attached to multiple, need entries in the forwarding table per P-GW (disseminated via link-state in the area, for example)

For DL packets (dest @ is a UE): • The UE is attached to this eNodeB, send to UE directly (single hop)• The UE is in a neighbor eNodeB (may be the case during handovers), during handover a

forwarding table entry will have been installed

S-GW

eNodeB

S-GW

UE UE UE

eNodeB

18

Forwarding at UE


UL packets (dest @ is a P-GW): Forward to eNodeB (next hop)

For DL packets (dest @ is a UE): Send layer up

eNodeB

UE

Large-scale RINA Experimentation on FIRE+

Routing/forwarding policy: Summing up

Assumptions (this is just an example routing policy to show how it can work, there can be others that are more effective):• UE @ and S-GW @ contains service area id.• S-GW and eNodeBs run Link state routing within service area

P-GWs just need to store forwarding rules for direct neighbors (S-GWs)

S-GWs need to store forwarding rules for i) P-GWs that are direct neighbors ii) All UEs within serving area

eNodeBs need to store forwarding rules for i) S-GWs that are direct neighbors (if more than one) ii) UEs that are attached to the eNodeB or neigbhor eNodeB during Handover; iii) P-GWs if eNodeB has more than one neighbor S-GW

UEs don’t need to store forwarding table entries. UE’s @ needs to change when it moves from one serving area to another (no issue in RINA, changing @s does not break active flows, see later)

19

20

Handover, what happens? (I)(within same serving area = no change of address)

Handover decision is done (via NMS?, source eNodeB?, UE?, cooperation between them?), destination eNodeB is selected

Source eNodeB starts buffering packets addressed to the UE (note: this would not be required if UE could be multi-homed to 2 enodeBs)

Source eNodeB modifies entry in forwarding table for the UE address, with next hop the destination eNodeB (sets Timer for expiration of this entry).

UE enrolls to destination eNodeB

Handover is done, destination eNodeB tells source eNodeB. Source eNodeB stops buffering packets to UE.

After a while the forwarding table entry for the UE in the source eNode B expires.


21

Handover, what happens? (II)(between serving areas = UE change of address)

Same as before except that UE gets new address when enrolling to destination eNodeB.

Dest eNodeB communicates the new address to the source eNodeB, which adds an extra fowarding table entry for the new UE address.

EFCP instances in UE start using new address in outgoing EFCP PDUs. P-GWs with EFCP flows with the UE start seeing the new UE address in incoming PDUs. EFCP instances start using the new address for outgoing EFCP PDUs (old address is no longer present in EFCP PDUs).

When timers expire source eNodeB removes forwarding table entries (this time there are two) and UE forgets old address.


22

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

…

…

…

In this example “e-mall” DIFs (providing access to applications) are available via the regional DIF, but could be available also through metro or district DIFs• Essentially, every border router can be a “mobility anchor”, no need to do anything special.

Under DIFs

Operator core

23

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

THANKS FOR YOUR ATTENTION!
