Generic network architecture discussion

GENERIC NETWORK ARCHITECTURE (WI9)
RINA PRINCIPLES, RESEARCH RESULTS, DEMOS
Eduard Grasa, Fundació i2CAT
ETSI NGP#8 September 7th 2017

What is our goal?
It is not about IP vs. non-IP protocols, problems are deeper!
As much invariants as possible in the architecture, so that we
can minimize the number of protocols and maximize their
commonality
Architecture:
patterns, invariants, building
blocks, methods
Protocols
Today:
• Architecture has too little
patterns/commonality,
and they are a bit broken
• Too many protocols, too
little commonality
Architecture:
patterns, invariants, building
blocks, methods
What we want:
• Architecture provides as
much invariants as
possible
• Few protocols, sharing
lots of commonality
Protocols
2

Work Item 9: table of contents (I)
6

Work Item 9: table of contents (II)
7

NGP Generic Protocol Model
Case(Generic Protocol Architecture)
Network
Equipment
Compute
Entity
Network
Entity
4
Port
P
Po(3)
Point of
Attachment
Protocol
Layer
Physical Link
Web
Client
Application
8

NGP Generic Protocol Model: Generic IPC network entity
2 5 3 4
Generic IPC
Network Entity
Generic IPC
Network Entity
8 9
N(Generic data transfer protocol)
7859
Relaying &
Multiplexing
PDU
protection
PDU
protection
PDU
protection
PDU
protection
SDU
delimiting
SDU
delimiting
N(Unified layer management protocol)
5 4
RIB
Daemon
Flow
Allocator
Namespace
Manager
Resource
Allocator
Security
Manager
Generic IPC
Network Entity
(AP name,
Address(es))
25
12
SDU
delimiting
9

RINA macro-structure (layers)
Single type of layer, consistent API, programmable policies
Host
Border router Interior Router
DIF
DIF DIF
Border router
DIF
DIF
DIF (Distributed IPC Facility)
Host
App
A
App
B
Consistent
API
through
Layers (DIFs) are distributed applications that provide IPC services to
higher layers (which may be DIFs or other forms of distributed
applications)
Layers are resource allocators: they manage the layer resources (memory
in buffers, scheduling capacity, bandwidth) and provide them to
competing flows.
11

RINA recursive layering structure cleans up and generalizes the
current protocol stack.
Example 1: PBB-VPLS (Virtual Private LAN Service)
• Uses MAC-in-MAC encapsulation to isolate provider’s core from customers
addresses and VLANs
Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
12

addresses and VLANs
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP DIFPtP DIFPtP DIFPtP DIF
PtP
DIF
PtP
DIF
PtP
DIF
13

addresses and VLANs
Metro DIF Metro DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
14

addresses and VLANs
Metro DIF Metro DIFCore DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
15

addresses and VLANs
Provider VPN Service DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
16

addresses and VLANs
Green Customer VPN DIF
Provider VPN Service DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
17

Example 2: LTE (Long Term Evolution)
• Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP
network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Recursive, generic layer structure (II)
18
Bridging

network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U
Bridging
GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
19

network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Mobile Operator
Transport DIF
Mobile Operator
Transport DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
20
Bridging

network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Multi-access
radio DIF
Mobile Operator
Transport DIF
Mobile Operator
Transport DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
21
Bridging

network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Mobile Access Network Top Level DIF
Multi-access
radio DIF
Mobile Operator
Transport DIF
Mobile Operator
Transport DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
22
Bridging

network.
IP (e.g. Internet)
TCP or UDP
PDCP GTP-U GTP-U
RLC
MAC
L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1
UDP
IP (LTE transport)
MAC MAC. . .
L1 . . . L1UE
eNodeB S-GW P-GW
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
Public Internet DIF (or user VPN DIF, or app-specific DIF, …)
Mobile Access Network Top Level DIF
Multi-access
radio DIF
Mobile Operator
Transport DIF
Mobile Operator
Transport DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
23
Bridging

Example 3: Data Center Network with NVO3
• Network Virtualization Over Layer 3, uses overlay virtual networks on top of the
DCN’s fabric layer 3 to support multi-tenancy
Recursion provides a cleaner, simpler solution than virtualization
• Repeat the same building block, with the same interface.
ToR ToRFabric Spine Fabric
Server ServerIPv4 or IPv6 (Fabric layer)
UDPVM VM
Ethernet Ethernet Ethernet Ethernet
VXLAN802.1Q802.3 802.1Q
IPv4 or IPv6 (tenant overlay)
TCP or UDP or SCTP, … (transport layer)
802.3
bridging
Recursive, generic layer structure (III)
24

UDPVM VM
VXLAN802.1Q802.3 802.1Q
802.3
bridging PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
25

UDPVM VM
VXLAN802.1Q802.3 802.1Q
802.3
bridging PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
DC Fabric DIF
26

UDPVM VM
VXLAN802.1Q802.3 802.1Q
802.3
bridging PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
DC Fabric DIF
Tenant DIF
27

PROTOCOLS WITHIN A GENERIC LAYER
28

Separation of mechanism from policy
29
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
StateVector
StateVector
StateVector
Data TransferData Transfer
Retransmission
Control
Retransmission
Control
Flow Control
Flow Control
Namespace
Management
Security
Management
All layers have the same mechanisms and 2 protocols (EFCP for data transfer, CDAP
for layer management), programmable via policies.
• All data transfer and layer management functions are programmable!
Don’t specify/implement protocols, only policies
• Re-use common layer structure, re-use policies across layers
This approach greatly simplifies the network structure, minimizing the
management overhead and the cost of supporting new requirements, new
physical media or new applications
EFCP

Error and Flow Control Protocol (EFCP)
One of the main results discussed in Patterns in Network
Architecture (PNA), later formalised in RINA.
• PNA/RINA only proof this is possible and show a way of arriving to the
result. If others propose simpler frameworks with the same capabilities
we should definitely go for them.
By separating data transfer protocol elements between
mechanism (invariant) and policy (variant), it is possible to
specify a data transfer protocol framework from which multiple
data transfer protocols can be generated by
• Choosing a concrete syntax (length of PCI fields)
• Plugging in the right policies
See EFCP specification for an example of such protocol
framework
30

EFCP (II)
1 common data transfer PDU
• Abstract syntax: (presence/absence and length of fields varies
• E.g.: point to point links -> no need for addresses
• 1 application only per IPCP -> no need for cep-ids (e.g. some IoT protocols)
A few control PDUs (Ack, ack & flow ctrl, etc.)
Policy plug-in points to customize for different environments and
application requirements
• Flow control (window/rate-based), retransmission control, congestion
control
31

E.g. Results on congestion control (I)
“Congestion control in the Recursive Internetwork
Architecture”
• P. Teymoori, M. Welzl, S. Gjessing, E. Grasa, R. Riggio, K. Rausch, D.
Siracussa
• IEEE ICC 2016
• https://www.researchgate.net/publication/301657524_Congestion_C
ontrol_in_the_Recursive_InterNetworking_Architecture_RINA
• “… we have shown that congestion control in RINA “naturally” exhibits
properties of various improvements that have been made to (or at
least proposed for) the Internet, without inheriting the problems that
come from imposing these mechanisms on an architecture that was
not made for them … ”
32

Results on congestion control (II)
RINA can solve the Internet c. c. problems by:
• Breaking up the control loop in shorter ones
• Controlling flow aggregates inside the network and
• Enabling the deployment of arbitrary controllers per DIF
Follow up: OCARINA project (lead by U of Oslo)33

DIF API
register / unregister (app name)
• Associate applications to DIFs
allocate_flow(dest_app_name, QoS attributes)
• Allocate a flow to a destination app name (may name a group of apps),
with a certain QoS (reliable delivery, in order delivery, bounds on
delay/jitter, minimum capacity, etc.)
read/write (port_id)
deallocate_flow(port_id)
• Free up resources associated to the flow
34

Dynamic negotiation of cep-ids and policies
per flow
Application calls “allocate”
• Provides dest. app name and flow requirements
IPCP(source) selects EFCP policies and computes source cep-id, sends message
to IPCP (dest)
IPCP (dest) does access control check, selects EFCP policies and computes dest
cep-id
Today
• applications have to select the protocol explicitly
• static (well-known) ports as cep-ids
• No app names, addresses exposed to apps
35

Example of unified layer management
infrastructure: RINA
36
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

Benefits of unified layer management framework
Only need one common layer management protocol for all layers,
which allows layer management functions to remotely operate on
objects (which model the function’s externally visible state)
Only need one common distributed memory/database manager
for layer management functions
• With pluggable replication policies (on demand, event-based, periodic, etc..)
Layer management functions just need to specify an object
schema, and the behaviour when the common protocol operations
are invoked on the objects
This is a huge reduction in network complexity, coming from a
world were every single layer management/control plane function
has one or more standalone protocols, independently designed
(ICMP, RSVP, OSPF, RIP, BGP, IS-IS, ARP, DNS, etc..)
37

Overview of IRATI and its SDK
C/C++ based RINA implementation for Linux
Normal IPC Process
(Layer Management)
User space
IRATI RINA
implementation
Kernel
Kernel IPC Manager
Normal IPC Process
(Data
Transfer/Control)
Shim IPCP
over 802.1Q
IPCP Daemon
(Layer Mgmt)
IPC Manager
Daemon
Normal IPCP
(Data Transfer)
SHIM
IPCP
App
zoom in
zoom in
zoom in
Normal IPCP
(Data transfer)
Error and Flow
Control Protocol
Relaying and
Multiplexing Task
SDU Protection
SDK support
RTT
policy
Txctrl
policy
ECN
policy
. . .
SDK support
Forwar
policy
Schedu
policy
MaxQ
policy
Monit
policy
SDK support
TTL
policy
CRC
policy
Encryp
policy
Normal IPCP
(Layer Mgmt)
RIB &
RIB
Daemon
librina
Resource
allocation
Flow
allocation
Enrollment
Namespace
Management
Security
Management
Routing
SDK support
Auth.
policy
Acc.ctrl
policy
Coord
policy
SDK support
Address
assign
Directory
replica
Address
validat
SDK support
New flow
policy
SDK support
PFTgen
policy
Pushbak
notify
Enroll.
sequence
SDK support
Routing
policyIPC Manager
librina
Manag
ement
Agent
IPCM
logic
Network
Manager
(NMS DAF)
SDK supportRIB &
RIB
Daemon
Shim
IPCP
Shim
IPCP
38

39
Remote terminal:
Standard laptop,
Windows 7 with
Ubuntu in Virtualbox
Demo host (server):
Server with vanilla
Debian
running RINA network
RINA network:
X nodes,
depending
On experiment
RINA node (guest):
Qemu image run in X
KVMs
with full RINA Linux
kernel
static physical PtP
connection
multiple SSH links
public Internet
KVM
virtualisation
Linux links
& bridges
Demonstrator

NAMING, ADDRESSING, MOBILITY
41

Naming & 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).
42

Implications for multi-homing
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 next-
hop/forwarding table reduction!
No need for special protocols to support
multi-homing
Addresses assigned to interfaces Addresses assigned to nodes
43

Renumbering demo (single DIF)
30 node network, Single DIF over Ethernet
All nodes in the DIF change addresses every 30-60s
60 flows running over the DIF, no flow disruption, no data loss
IRATI RINA implementation
45

Experimental results
No packet loss during
renumbering events
Almost no penalty in
throughput
Penalty in delay for the worst
case scenario
0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45
VPN 1: s14 - s24
VPN2 : s18 - s28
VPN3: s31 - s41
VPN4: s35 -s45
rina-echo-meflowsbetweennodes
Applica on RTT (ms) vs. renumbering frequency
Every [30, 60] s
Every [60, 120] s
Every [120, 240] s
No renumbering
0 10 20 30 40 50 60 70 80 90 100
VPN 1: s14 - s24
VPN2 : s18 - s28
VPN3: s31 - s41
VPN4: s35 -s45
rina-tgenflowsbetweennodes
Applica on goodput (Mbps) vs. renumbering frequency
Every [30, 60] s
Every [60, 120] s
Every [120, 240] s
No renumbering
• Results in the worst case
scenario (constanly
renumbering network)
• Renumbering can be
done live
46

Implications
With a proper naming and addressing structure in place, life
network renumbering can be done
• without impacting existing flows
• without the need of extra protocols or mechanisms
• in a fully automated way (minimize opex and network downtime)
Use cases
• Network consolidation (e.g. acquisition of other networks)
• Update network addressing scheme to optimize routing (e.g. due to
changes in network topology)
• Better support for mobility (change address of moving nodes if they
attach to different subnets)
47

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

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

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
50

DMM over WiFi demo: physical systems
Wifi
(ssid irati)
AP1
Wifi
(ssid
pristine)
AP2
Wifi
(ssid arcfire)
AP3
Wifi
(ssid irina)
AP4
Wifi
(ssid
rinaisense)
AP5
Wifi
(ssid
ocarina)
AP6
LaptopUE
Raspberry Pi 3B
VLAN
10
VLAN
20
VLAN
30
VLAN
40
VLAN
50
VLAN
60
10
20
30
40
50
60
Edge 1
Edge 2
Edge 3
Edge 4
100
110
200
210
Core 1
Core 2
ISP 1
ISP 2
Server 1
Server 2
120
220
300
310
320
VLAN-Aware
Eth. Switch
Mobile net 1
Mobile net 2
Laptop running Demonstrator
(Blue boxes are QEMU/KVM VMs)
51

DMM demo: DIFs
UE AP 1 Edge 1 Core
ISP1 Server1
Mobile network DIF
Internet DIF
DAF (rina-tgen or rina-echo-time)
Shim DIF Eth Shim DIF Eth Shim DIF Eth
Shim DIF Eth Shim DIF Eth
UE
A1
A3
A2
E1
C1
E2
Mobile Network DIF
I1
UE
C1 S1
S2I2
Internet DIF
C2
52

Storyboard: Handover
UE starts moving towards Access2, at some point it allocates a
flow to Access2 (UE is multihomed)
UE continues moving further away from Access 1, flow to it is
deallocated. When UE is closer to A3, it allocates a flow to it.
All of this happens in the mobile network DIF without impacting
higher DIF flows.
UE
A1
A3
A2
C1
GW
C2
Mobile Network DIF
UE
A1
A3
C1
GW
C2
Mobile Network DIF
A2
UE
A1
C1
GW
C2
Mobile Network DIF
A2
A3
53

Some results on cost of mobility
“On supporting mobility and multi-homing in Recursive
Internet Architectures”
• V. Ishakian, J. Akinwuni, F. Esposito, I. Matta
• Computer Communications, 2012, Vol. 35, Issue 13
• http://www.cs.bu.edu/fac/matta/Papers/RINA-ComCom2012.pdf
• “In this paper, we present a specification of the process of ROuting in
Recursive Architectures (RORA). We also perform an average-case cost
analysis to compare the multihoming / mobility support of RINA,
against that of other approaches such as LISP and Mobile-IP. Extensive
experimental results confirm the premise that the RINA architecture
and its RORA routing approach are inherently better suited for
supporting mobility and multihoming.”
54

Results on topological addressing in large-
scale DCs
“Benefits of topological routing policies in RINA-enabled
large-scale DataCentres”
• S. Leon, J. Perello, D. Careglio, E. Grasa, D. Lopez, P. Aranda
• IEEE Globecom 2016
• https://www.researchgate.net/publication/309782103_Benefits_of_Pr
ogrammable_Topological_Routing_Policies_in_RINA-Enabled_Large-
Scale_Datacenters
• “… we propose rule-based topological routing and forwarding policies
tailored to the characteristics of publicly available Google’s and
Facebook’s DCNs… Numerical results show that the scalability of our
proposal depends on the number of concurrent failures in the DCN
rather than its size (e.g., number of nodes/links), dramatically reducing
the total amount of routing and forwarding information to be stored at
nodes. “
55

Security: DIFs are securable containers
Secure layers instead of protocols, expose less to apps, scope
Allocating a flow to
destination application
Access control
Sending/receiving SDUs
through N-1 DIF
Confidentiality, integrity
N DIF
N-1 DIF
IPC
Process
IPC
Process
IPC
Process
IPC
Process Joining a DIF
authentication, access
control
Sending/receiving SDUs
through N-1 DIF
Confidentiality, integrity
Allocating a flow to
destination application
Access control
IPC
Process
Appl.
Process
DIF Operation
Logging/Auditing
DIF Operation
Logging/Auditing
RINA IP protocol suite
Consistent security model, enforced by each
layer via pluggable policies
Each protocol has its own security
model/functions (IPsec, TLS, BGPsec,
DNSsec, etc.)
Scope as a native construct: controlled
connectivity by default
Single scope (global), connectivity to
everyone by default. Scope via ad-hoc
means: firewalls, ACLs, VLANs, VPNs, etc.
Complete naming and addressing,
separation of synchronization from port
allocation
5757
57

Results on security (I)
“Assessing the security of a clean-slate Internet architecture”
• G. Bodappati, I. Matta, J. Day, L. Chitkushev
• IEEE International Conference on Network Protocols
• http://www.cs.bu.edu/techreports/pdf/2009-021-clean-slate-internet-
security.pdf
• “In this paper, we show how, without the aid of cryptographic
techniques, the bare-bones architecture of RINA can resist most of the
security attacks faced by TCP/IP. We also show how hard it is for an
intruder to compromise RINA. Then, we show how RINA inherently
supports security policies in a more manageable, on-demand basis”
58

Results on security (II)
“Patterns in network security: an analysis of the
architectural complexity in securing RINA networks ”
• J. Small
• Master thesis
• http://rina.tssg.org/docs/js-002.7-patterns_in_network_security.pdf
• “Based on the evidence presented, RINA seems to be able to deliver on
security requirements with substantially less complexity in terms of
number of protocols, required number of flows, and especially the
required number of distinct mechanisms, compared to the Internet
protocol suite”
59

Results on security (III)
“From protecting protocols to protecting layers: designing,
implementing and experimenting with security policies in
RINA ”
• E. Grasa, O. Rysavy, O. Lichtner, H. Asgari, J. Day, L. Chitkushev.
• IEEE ICC 2016
• https://www.researchgate.net/publication/304625404_From_protecti
ng_protocols_to_layers_Designing_implementing_and_experimenting
_with_security_policies_in_RINA
• “In this paper we explore the security properties of the Recursive
InterNetwork Architecture, analyzing the principles that make RINA
networks inherently more secure than TCP/IP-based ones. We perform
the specification, implementation and experimental evaluation of the
first authentication and SDU protection policies for RINA networks.
RINA's approach to securing layers instead of protocols increases the
security of networks, while reducing the complexity and cost of
providing security ”60

Network management
Commonality is the key to effective network management
From managing a set of layers, each
with its own protocols, concepts and
definitions …
… to managing a common, repeating
structure of two protocols and different
policies
Commonality and consistency in RINA greatly simplifies management
models, opening the door to increased automation in multi-layer networks
• Reduce opex, network downtime, speed-up network service delivery, reduce components
that need to be standardised
62

Some results on network management
“Simplifying multi-layer network management with RINA”
• S. van der Meer, B. Gaston, E. Grasa, M. Crotty, M. A. Puente
• TEERNA Networking Conference
• https://tnc16.geant.org/core/presentation/667
• “This paper performs a comparative analysis in the complexity of
managing an IP-based and a RINA-based large-scale multi-tenant data
centre networks. Configuration management is the main target of the
analysis although some hints on performance and security
management are also provided. The analysis shows that the
commonality built into the RINA architecture and the single type of
recursive layer with a uniform API greatly reduces the complexity of
the models the Network Management System (NMS) uses to
understand the state of the managed network.”
63

Deployment
New technology but incremental deployment
RINA can be deployed incrementally where it has the right
incentives, and interoperate with current technologies (IP,
Ethernet, MPLS, etc.)
• Over IP (just like any overlay such as VXLAN, NVGRE, GTP-U, etc.)
• Below IP (just like any underlay such as MPLS or MAC-in-MAC)
• Next to IP (gateways/protocol translation such as IPv6)
IP Network
RINA Provider
RINA Network
Sockets ApplicationsRINA supported Applications
IP or Ethernet or MPLS, etc
65

IP over RINA demo
IP over RINA over Ethernet
Potential use cases
• IP VPNs
• SD-WAN (distributed enterprise, DC interconnect)
• Metro and/or core network capable of multiple QoS and support for
multiple tranports
• DC fabric
66
DIF
Shim DIF Eth Shim DIF Eth
IP layer
. . .

Research, open source, specs
Current research projects
• FP7 PRISTINE (2014-2016) http://ict-pristine-eu
• H2020 ARCFIRE (2016-2017) http://ict-arcfire.eu
• Norwegian project OCARINA(2016-2021)
• BU RINA team http://csr.bu.edu/rina
Open source implementations
• IRATI (Linux OS, C/C++, kernel components, policy framework, RINA over X
http://github.com/irati/stack
• RINASim (RINA simulator, OMNeT++) https://rinasim.omnetpp.org/
• ProtoRINA (Java, RINA over UDP) https://github.com/ProtoRINA/users/wiki
• rlite (Linux OS, C/C++, kernel components, minimize footprint)
https://github.com/vmaffione/rlite
RINA specifications
• Pouzin Society (experimental specs) http://pouzinsociety.org
• ISO SC6 WG7 (active in two projects: Future Network – Architectures, Future Network
Protocols)
1
2
3
4
1
2
3
1
2
67
4

Generic network architecture discussion

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Generic network architecture discussion

Semelhante a Generic network architecture discussion (20)

Mais de ARCFIRE ICT

Mais de ARCFIRE ICT (20)

Último

Último (20)

Generic network architecture discussion

Notas do Editor