DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
Irati goals and achievements - 3rd RINA Workshop
1. IRATI objectives, outcomes and lessons learned
The IRATI project: objectives, outcomes and
lessons learned
3rd international RINA Workshop.
Ghent. January 2015
Eduard Grasa (Fundació i2CAT) on behalf of the IRATI team
2. Quick facts about the project
IRATI objectives and outcomes 2
• What? Main goals
– To advance the state of the art of RINA towards an architecture
reference model and specifications that are closer to enable
implementations deployable in production scenarios.
– The design and implementation of a RINA prototype on top of Ethernet
will enable the experimentation and evaluation of RINA in comparison to
TCP/IP.
Budget
Total Cost 1.126.660 €
EC Contribution 870.000 €
Duration 2 years
Start Date 1st January 2013
External Advisory Board
Juniper Networks, ATOS,
Cisco Systems, TRIA Network Systems
5 activities:
WP1: Project management
WP2: Arch., Use cases and Req.
WP3: SW Design and Implementation
WP4: Deployment into OFELIA
WP5: Dissemination, Standardisation
and Exploitation
Who? 5 partners
From 2014
3. Main goals
• Linux/OS RINA implementation over Ethernet,
which can be a platform for research and future
RINA-based products
IRATI objectives, outcomes and lessons learned 3
1
• Experimental evaluation of the RINA
implementation and comparison with the TCP/IP
networking stack
2
• Advance the SotA of RINA specifications: work
out new ones, debug and enhance existing
ones
3
• Increase RINA awareness in sci/tech community
and contribute to the development of its
standardization strategy
4
5. • … but can also be the basis of RINA-based products
– Tightly integrated with the Operating System
– Capable of being optimized for high performance
– Enables future hardware offload of some functions
– Capable of seamlessly supporting existing applications
– IP over RINA
RINA implementation goals
• Build a platform that enables RINA experimentation …
– Flexible, adaptable (host, interior router, border router)
– Modular design
– Programmable
– RINA over X (Ethernet, TCP, UDP, USB, shared memory, etc.)
– Support for native RINA applications
IRATI objectives, outcomes and lessons learned 5
1
2
3
4
5
1
2
3
4
5
6. Some decisions and tradeoffs
IRATI objectives, outcomes and lessons learned 6
Decision Pros Cons
Linux/OS vs other
Operating systems
Adoption, Community, Stability,
Documentation, Support
Monolithic kernel (RINA/
IPC Model may be better
suited to micro-kernels)
User/kernel split
vs user-space only
IPC as a fundamental OS service,
access device drivers, hardware
offload, IP over RINA, performance
More complex
implementation and
debugging
C/C++
vs Java, Python, …
Native implementation
Portability, Skills to master
language (users)
Multiple user-space
daemons vs single one
Reliability, Isolation between IPCPs
and IPC Manager
Communication overhead,
more complex impl.
Soft-irqs/tasklets vs.
workqueues (kernel)
Minimize latency and context
switches of data going through the
“stack”
More complex kernel
locking and debugging
11. Comparison to TCP/IP
Not an excuse, but …
• What is a meaningful comparison today?
– Raw performance
– Stability/bugs
IRATI objectives, outcomes and lessons learned 11
Contributors Time Specs Deployed
RINA Prototype 8-10 (partial) 1.5 years Experimental IRATI
Linux networking stack 100s 20+ years Stable for years Millions of systems
– Structure/complexity of implementation
– Flexibility/adaptability of design
– Programmability of implementation
– Application interface
12. RSVP
Daemon
VPN
software
Structure and flexibility (RINA vs TCP/IP)
• RINA: As many IPCPs as you wish; single point of management of the
stack; configurable to be a router or a host; no protocols -> policies
• TCP/IP stack: TCP/UDP over IP over Ethernet (fixed configuration). If
routing or resource reservation external software has to be added; if
more layers VPN software has to be added; disperse config utils
IRATI objectives, outcomes and lessons learned 12
IPCP
(data transfer)
IPCP
(layer
mgmt)
Shim IPCP
IPC
Manager
App
KIPCM
App
Sockets
TCP/UDP
IP / Ethernet
Traffic control
Config. toolsRouting
Daemon
13. RSVP
Daemon
VPN
software
Programmability (RINA vs TCP/IP)
• RINA: Policies programmable in each IPCP: delimiting, EFCP syntax, flow
control, rtx. control, addressing, routing, resource allocation,
multipexing, authentication, authorization, TTL, encryption, CRC, etc.
• TCP/IP stack: Fixed syntax, protocols not programmable, have to
develop full new protocols to try new things (* with OF now you can
“program” the forwarding table)
IRATI objectives, outcomes and lessons learned 13
IPCP
(data transfer)
IPCP
(layer
mgmt)
Shim IPCP
IPC
Manager
App
KIPCM
App
Sockets
TCP/UDP
IP / Ethernet
Traffic control
Config. toolsRouting
Daemon
14. How to setup an experiment
Master the config file!
IRATI objectives, outcomes and lessons learned 14
Instantiation of IPCPs Shim DIF config
Normal DIF config, routing
Normal DIF config, EFCP
1 Login to the node
2 Edit config file
3 Start IPC Manager
15. Improving node configuration..
IRATI objectives, outcomes and lessons learned 15
• Today
• Manual editing of the config
files at each node -> time
consuming and error-prone
• Tomorrow (short-term)
• Standalone tool to generate
configuration files (PRISTINE)
• RINA Plugin Infrastructure (RPI)
Tooling (PRISTINE)
• Tomorrow (mid-term)
• RINA Configuration via
Network Management System
(PRISTINE)
16. Some early results
• Performance evaluation of the RINA implementation
– IEEE Globecom 2014. Achieves line-rate over GigE link.
• Deliverable D4.3 (to be published next few weeks)
– Influence of credit (constant policy) in throughput
– Effect of adding parallel flows on throughput
– Prototype CPU and memory resource utilization
– Study of retransmission control behavior at various loss rates
(immediate ACK policy vs. A-timer policy) with parallel flows
– Validation and performance evaluation of shim DIF over
TCP/UDP and shim DIF over Hypervisors
– Evaluation of SDU Protection policies (CRC and TTL)
– Study on interop requirements with TRIA Network Systems
prototype
IRATI objectives, outcomes and lessons learned 17
1
2
3
4
5
1
6
7
17. ADVANCE STATE OF THE ART
OF RINA SPECIFICATIONS
IRATI objectives, outcomes and lessons learned 18
3
18. • Source MAC @ (6 bytes)
– Source shim IPC Process address
• Destination MAC @ (6 bytes)
– Destination shim IPC Process address
• IEEE 802.1Q tag (2 bytes)
– DIF name
• Ethertype (2 bytes)
– 0x0D1F
19
Shim DIF over Ethernet
Ethernet II PCI Application data
• Minimum length: 42 bytes (46 if 802.1Q
not present)
• Maximum length: 1500 bytes
Shim DIF over 802.1Q
Use of the Ethernet frame
T-5 Alternatives to TCP/IP
19. Shim DIF over 802.1Q
Environment
Investigating RINA as an Alternative to TCP/IP 20
20. Shim DIF over TCP/UDP
• Wraps an IP network with the DIF IPC API
• Two QoS cubes possible: reliable and in-order-delivery of flows (TCP),
unreliable (UDP)
– More could be possible depending on the capabilities of the underlying IP
network
• IPCP name is mapped to an IP address and a port number
– Using proprietary procedures or leveraging DNS (via SRV records)
T-5 Alternatives to TCP/IP 21
IPCP
a.1
IPCP
b.1
Shim DIF over IP networks
IP layer
UDP Port:2524UDP Port:2524
Shim IPCP
X.1
Shim IPCP
Y.1
IP: 4.3.2.1 IP: 5.3.5.8
2 5
Flow
21. Shim DIF for HyperVisors
IRATI objectives, outcomes and lessons learned 22
• Allow a VM to communicate with its Main Environment (Host OS for type
2 HV or privileged VM for type 1 HVs), using shared memory
mechanisms
Type 2 HyperVisor
Type 1 HyperVisor
22. Link-state routing policy
IRATI objectives, outcomes and lessons learned 23
RIB Daemon
Resource
Allocator
PDU Forwarding Table Generator
Events
N-1 flow allocated
N-1 flow deallocated
N-1 flow down
N-1 flow up
Neighbor B invoked write
operation on object X
CDAP
Incoming CDAP messages
from neighbor IPC Processes
CDAP
Outgoing CDAP messages to
neighbor IPC Processes
Invoke write operation on
object X to neighbor A
Update
knowledge on N-
1 flow state
Propagate
knowledge on N-
1 flow state
Recompute
forwarding table
PDU Forwarding
Table
Relaying and
Multiplexing Task
Lookup PDU Forwarding
table to select output N-1
flow for each PDU
4321
N-1 Flows to nearest
neighbors
IPC Process
Enrollment
Task
Events
Enrollment completed
successfully
24. Some reactions to the RINA message
• Disseminating RINA can be challenging sometimes …
IRATI objectives, outcomes and lessons learned 25
Skepticism If it’s so nice, why it is not implemented yet?
Not mainstream? Don’t care
25. Some tips for disseminating RINA
• RINA is a new architecture, not a single point solution.
Position RINA as a better toolbox to allow
architects/designers to design better networks.
– Benefits of RINA are easier to understand when you take a
systems view.
• Explain relationship of RINA with hot topics such as
SDN, NFV, 5G, ICN
– In order to create initial interest and provide some context
• We need to work out specific use cases of how RINA
could be used in certain environments
– See IRINA NRENs and GEANT use case – to be published soon
IRATI objectives, outcomes and lessons learned 26
26. Standards: PSOC and ISO
• Need for a forum that is the authoritative source for
the RINA specifications and keeps them up to date
– Must be formed by people that is interested in moving RINA
forward and are experts in the topic -> cannot be established
SDOs (have their own agendas)
– PSOC talk later this afternoon by John Day
• ISO SC6 WG 7 (Future Networks)
– RINA presented last October, received with interest
– Opportunity to bring RINA as one of this group’s projects; very
long process but may be worth
– It may work to do the RINA standards within PSOC, take them
to ISO for approval and international recognition
IRATI objectives, outcomes and lessons learned 27
Ideal platform for networking research (you can isolate one change while keep all the other environment the same) -> more repeatability of tests
If you need to to more you’ll need to develop your own policies -> wait for PRISTINE’s SDK!
(Disclaimer: Other shim DIFs over Ethernet are possible: with no VLANs; using LLC; over carrier Ethernet; …)
A shim DIF over Ethernet maps to a VLAN
The DIF name is the VLAN name
The shim DIF only supports on class of service: unreliable
ARP can be used to map upper layer IPC Process names to shim DIF addresses (MAC addresses)
Only one application (a normal IPC Process) can be registered at each shim IPC Process
No way to differentiate between multiple flows from the same pair of shim IPC Processes
A shim DIF over Ethernet maps to a VLAN
The DIF name is the VLAN name
The shim DIF only supports on class of service: unreliable
ARP can be used to map upper layer IPC Process names to shim DIF addresses (MAC addresses)
Spans a single Ethernet segment