RINA Tutorial presented at the 3rd meeting of the ETSI ISG NGP, showing basic RINA structure and mechanisms, as well as a "toy" example of a mobile network with RINA
RINA enables seamless network renumbering without impacting existing flows. In RINA, each application and node has a unique name that is independent of location. Flows are identified by application names rather than IP addresses. This allows RINA networks to renumber nodes and change addresses without affecting ongoing communications. Experimental results show that RINA renumbering has almost no impact on throughput and no packet loss. RINA makes network renumbering fully automated and minimizes downtime.
RINA Distributed Mobility Management over WiFiARCFIRE ICT
- The document discusses trends in converged networks like mobile edge computing, network slicing, and distributed mobility management.
- It provides an overview of the Recursive Internet Architecture (RINA) model and how it can address issues like distributed applications, virtualization, slicing, and seamless mobility.
- The document describes a demo of RINA principles on a testbed network, including user enrollment, handover between access points, and communicating with servers while mobile.
Advanced network experiments in FED4FIREARCFIRE ICT
1) The document discusses past and present experiments on the Fed4FIRE testbed for advanced network experiments, including experiments on carrier-grade SDN, network resilience, quality of service differentiation, and clean-slate networking approaches like RINA.
2) It describes experiments testing restoration and protection in SDN networks, quality of service differentiation across multiple autonomous systems, and validation of RINA concepts like recursive networking, shim-based virtual machine networking, and programmability.
3) It introduces the ARCFIRE project which aims to enable large-scale experimentation with RINA on Fed4FIRE+ through innovations like seamless node renumbering and the RUMBA experiment management framework.
The document discusses using the RINA networking model to enhance the Project Clearwater IMS core. It describes prototyping HTTP and SIP traffic over RINA, and potential benefits like built-in fault tolerance, mobility, and multi-tenancy support. Future work could explore running additional protocols like Diameter or a service mesh over RINA. An interposer approach is also outlined to enable legacy applications to use RINA transparently.
This talk discusses RINA a bit more in-depth, taking the audience through several use cases and discussing results showcasing RINA benefits published in a number of conferences and journals. The talk includes a demo of application discovery and distributed mobility management in RINA networks.
The document discusses the flaws in the current network architecture. It describes how the architecture lacks structure, with protocols designed independently without commonality. This has led to protocol proliferation. The architecture also has issues with naming, addressing, multi-homing, and mobility due to using IP addresses as the sole identifier. The application programming interface further limits adoption of new protocols and provides no way to request quality of service parameters. Overall, the current architecture has problems in its structure, protocols, naming/addressing, service model, and lacks considerations for security and management.
RINA is a Recursive InterNetwork Architecture that uses a single consistent layering model and API. ARCFIRE aims to demonstrate the benefits of RINA technology at large scale using the FIRE+ experimental infrastructure. Over 100 nodes and 10s-100s of DIFs will be used in a week long experiment examining DDoS attacks, multi-layer management, and heterogeneous access networks. Results will provide compelling cases for RINA deployment by converging operators, application developers, and end users.
RINA Tutorial presented at the 3rd meeting of the ETSI ISG NGP, showing basic RINA structure and mechanisms, as well as a "toy" example of a mobile network with RINA
RINA enables seamless network renumbering without impacting existing flows. In RINA, each application and node has a unique name that is independent of location. Flows are identified by application names rather than IP addresses. This allows RINA networks to renumber nodes and change addresses without affecting ongoing communications. Experimental results show that RINA renumbering has almost no impact on throughput and no packet loss. RINA makes network renumbering fully automated and minimizes downtime.
RINA Distributed Mobility Management over WiFiARCFIRE ICT
- The document discusses trends in converged networks like mobile edge computing, network slicing, and distributed mobility management.
- It provides an overview of the Recursive Internet Architecture (RINA) model and how it can address issues like distributed applications, virtualization, slicing, and seamless mobility.
- The document describes a demo of RINA principles on a testbed network, including user enrollment, handover between access points, and communicating with servers while mobile.
Advanced network experiments in FED4FIREARCFIRE ICT
1) The document discusses past and present experiments on the Fed4FIRE testbed for advanced network experiments, including experiments on carrier-grade SDN, network resilience, quality of service differentiation, and clean-slate networking approaches like RINA.
2) It describes experiments testing restoration and protection in SDN networks, quality of service differentiation across multiple autonomous systems, and validation of RINA concepts like recursive networking, shim-based virtual machine networking, and programmability.
3) It introduces the ARCFIRE project which aims to enable large-scale experimentation with RINA on Fed4FIRE+ through innovations like seamless node renumbering and the RUMBA experiment management framework.
The document discusses using the RINA networking model to enhance the Project Clearwater IMS core. It describes prototyping HTTP and SIP traffic over RINA, and potential benefits like built-in fault tolerance, mobility, and multi-tenancy support. Future work could explore running additional protocols like Diameter or a service mesh over RINA. An interposer approach is also outlined to enable legacy applications to use RINA transparently.
This talk discusses RINA a bit more in-depth, taking the audience through several use cases and discussing results showcasing RINA benefits published in a number of conferences and journals. The talk includes a demo of application discovery and distributed mobility management in RINA networks.
The document discusses the flaws in the current network architecture. It describes how the architecture lacks structure, with protocols designed independently without commonality. This has led to protocol proliferation. The architecture also has issues with naming, addressing, multi-homing, and mobility due to using IP addresses as the sole identifier. The application programming interface further limits adoption of new protocols and provides no way to request quality of service parameters. Overall, the current architecture has problems in its structure, protocols, naming/addressing, service model, and lacks considerations for security and management.
RINA is a Recursive InterNetwork Architecture that uses a single consistent layering model and API. ARCFIRE aims to demonstrate the benefits of RINA technology at large scale using the FIRE+ experimental infrastructure. Over 100 nodes and 10s-100s of DIFs will be used in a week long experiment examining DDoS attacks, multi-layer management, and heterogeneous access networks. Results will provide compelling cases for RINA deployment by converging operators, application developers, and end users.
RINA research results - NGP forum - SDN World Congress 2017ARCFIRE ICT
RINA is a radically simple network architecture that takes an inter-process communication (IPC) approach. The key aspects of RINA are:
1) It uses a single type of layer called a Distributed IPC Facility (DIF) that can repeat as many times as needed. Each layer provides the same service of communication flows between application instances.
2) Layers isolate different scopes and allocate resources (e.g. bandwidth) to competing flows in a programmable way.
3) Experimental results show RINA can solve problems like congestion control and seamless renumbering more easily than IP networks. It also simplifies network management.
Rina converged network operator - etsi workshopARCFIRE ICT
1. The document discusses a converged network vision that supports any access media and application using a common network infrastructure with a single architecture, management system, and user database.
2. It questions whether all-IP networks are fit for this purpose, as the IP protocol suite was not designed for generality and scalability.
3. The document introduces RINA as a better approach, describing its unified model of networking as inter-process communication, consistent layered architecture, and support for naming, addressing, mobility, security, and management.
The document provides an overview of network architecture and proposes a new architecture called RINA. It discusses flaws in the current Internet architecture, including its layered structure, protocol design, naming and addressing scheme, and application programming interface. The document then outlines key aspects of the proposed RINA architecture, including using Distributed IPC Facilities (DIFs) to provide inter-process communication services across different scopes, a consistent layered structure based on allocating IPC resources, a unified framework for data transfer and layer management protocols, and a naming scheme that supports mobility and multi-homing without special protocols.
The document discusses network architecture and proposes improvements to current approaches. It suggests treating layers as units that provide interprocess communication over different scopes. Each layer would provide a single type of service and the number of layers is not fixed. It also proposes having a single unified data transfer protocol framework and layer management protocol across all layers to reduce complexity. This would help standardization bodies design complete network protocols more easily.
Rumba is a Python framework that enables large-scale experimentation with the Recursive InterNetwork Architecture (RINA). It provides plugins that interface with different testbeds and prototypes. The document shows an example script that defines nodes and DIFs using the Rumba and rlite prototypes, runs the experiment on a JFed testbed, and starts a rinaperf client-server performance test between two nodes.
1) The ARCFIRE project is experimentally validating the benefits of RINA technology through large-scale experiments on the FIRE+ testbed involving over 100 nodes across multiple distributed information fields (DIFs).
2) In RINA, application names uniquely identify applications, addresses are location-dependent synonyms used for locating applications within a DIF, and other identifiers like port-ids and connection endpoint IDs are used to identify communication endpoints.
3) RINA's naming and addressing approach simplifies multi-homing and mobility by assigning addresses to nodes instead of interfaces, avoiding the need for special protocols.
The hague rina-workshop-mobility-eduardICT PRISTINE
1) The ARCFIRE project is experimentally validating the benefits of RINA technology through large-scale experiments on the FIRE+ testbed involving over 100 nodes across multiple distributed information fields (DIFs).
2) In RINA, application names uniquely identify applications, addresses are location-dependent synonyms used for locating applications within a DIF, and other identifiers like port-ids and connection endpoint IDs are used to identify communication endpoints.
3) RINA's naming and addressing model simplifies multi-homing and mobility by assigning addresses to nodes instead of interfaces, avoiding the need for special protocols and allowing mobility to be treated as dynamic multi-homing with expected failures.
Distributed mobility management and application discoveryARCFIRE ICT
This document summarizes the results of Experiment 5 of the ARCFIRE project. The experiment demonstrated distributed mobility management (DMM) in RINA by allowing a mobile host to soft handover between different wireless access points while maintaining service continuity. It also showed application discovery across different DIFs as the mobile host moved. Finally, it demonstrated multi-access support by allowing the mobile host to connect to different physical networks and access applications hosted in different DIFs and locations as it moved. The key findings were that RINA's layered structure allows for mobility and multi-homing without specialized protocols or tunnels, and that service continuity is preserved during handovers despite some increase in packet loss and delay.
The document discusses Internet of Things (IoT) networks and routing protocol RPL. It provides an agenda for covering open standards, IEEE and IETF work on low-power lossy networks (LLNs) and 6LoWPAN, concepts of RPL including DODAG, instances, objective functions and messages. It also discusses putting the pieces together including backbone routers and data packet flows. The goal is to reconsider basic Internet structures and expectations to support trillions of constrained devices connecting in IoT applications.
3 hours course on IEEE and IETF protocols introducing the 6TiSCH architecture and the RPL routing protocol. Course given at telecom Bretagne on Feb 12th 2014
Overview of SCTP (Stream Control Transmission Protocol)Peter R. Egli
Overview of SCTP (Stream Control Transmission Protocol), outlining the main features and capabilities of SCTP.
SCTP is a transport protocol that overcomes many of the shortcomings of TCP, namely head-of-line blocking and stream-oriented transmission.
SCTP supports multiple streams within a connection and preserves boundaries of application messages thus greatly simplifying communication.
Additionally, SCTP supports multi-homing which increases availability in applications with high reliability demands.
SCTP inherits much of the congestion, flow and error control mechanisms of TCP.
SCTP has its roots in telecom carrier networks for use in transitional voice over IP scenarios.
However, SCTP is generic so that it is applicable in many enterprise applications as well.
RINA provides a recursive, layered approach to networking where each layer, called a Distributed IPC Facility (DIF), has the same basic functions but with different scopes and policies. Congestion control in RINA is implemented in a distributed manner across DIF layers through the Error and Flow Control Protocol (EFCP). EFCP consists of the Data Transfer Protocol (DTP) and optional Data Transfer Control Protocol (DTCP) which coordinate through a shared state vector to provide reliable data transfer, flow control, and congestion management without the scalability issues faced by TCP in the Internet.
The document summarizes the goals, methodology, and results of experiments with the RINA architecture on the FIRE testbed. The goals were to explore the RINA QoS model in practice, experiment with scheduling policies to differentially allocate loss and delay, and demonstrate RINA for IP VPN scenarios. Experiments on a single DIF showed differentiation of QoS classes, but IP VPN performance was impacted by buffers. Larger experiments on multiple DIFs also showed QoS differentiation, but with higher than expected latency likely due to the prototype implementation.
This document summarizes an approach called RINA (Recursive InterNetwork Architecture) for simplifying multi-layer network management. RINA proposes a common, repeating structure across layers with only two protocols - one for data transfer and one for layer management. This significantly reduces the complexity of management models compared to the IP protocol suite, which has unique protocols at each layer. A case study shows how RINA could simplify network management in a large-scale data center network by reducing the number of required addresses, forwarding entities, and management protocols. The consistent structure of RINA opens the door to increased network automation by making management models simpler and more standardized.
This document discusses experiments conducted using the Contiki operating system and RPL routing protocol in wireless sensor networks. It describes setting up networks with different numbers of relay and client nodes. Experiments were run with sensor nodes sending data at various frequencies to measure network performance over time periods ranging from a day to multiple days. Results on packet loss are presented. Further work is proposed to conduct more extensive RPL testing under additional configurations and add sensor nodes to track object movement.
The document describes an SDK to exploit the programmability of RINA. RINA is a networking architecture based on the theory that networking is inter-process communication. The SDK aims to provide programmable functions at each layer through consistent APIs. It discusses design decisions around using Linux, a user/kernel split, programming languages, and threading models. The goal is to separate mechanism from policy to simplify network structure and support new requirements through re-usable policies across layers.
The document discusses the fringe of the Internet, which includes low power lossy networks (LLNs) connected by radio links. It describes characteristics of LLNs like highly constrained devices, small frame sizes, and energy efficiency requirements. The routing protocol for LLNs needs to be adapted to these types of links. The document outlines different approaches for connecting LLNs to the Internet, including mesh under, route over, and overlay models. It introduces RPL as an IETF routing protocol designed for routing over radio in LLNs.
IRATI: an open source RINA implementation for Linux/OSICT PRISTINE
This document provides an overview of IRATI, an open source implementation of RINA for Linux/OS. It discusses the goals of being tightly integrated with the OS, supporting existing applications, and experimentation. The high-level design uses a Linux kernel with user-space daemons. Implementation status provides details on various IPCP components and policies. Experimental activities describe designing RINA networks and interoperating with legacy technologies. Open source initiatives discuss the IRATI GitHub organization and planned contributions from projects like PRISTINE and IRINA.
Overview of SCTP (Stream Control Transmission Protocol)Peter R. Egli
Overview of SCTP (Stream Control Transmission Protocol), outlining the main features and capabilities of SCTP.
SCTP is a transport protocol that overcomes many of the shortcomings of TCP, namely head-of-line blocking and stream-oriented transmission.
SCTP supports multiple streams within a connection and preserves boundaries of application messages thus greatly simplifying communication.
Additionally, SCTP supports multi-homing which increases availability in applications with high reliability demands.
SCTP inherits much of the congestion, flow and error control mechanisms of TCP.
SCTP has its roots in telecom carrier networks for use in transitional voice over IP scenarios.
However, SCTP is generic so that it is applicable in many enterprise applications as well.
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things” b...gogo6
gogo6 IPv6 Video Series. Event, presentation and speaker details below:
EVENT
gogoNET LIVE! 4: IPv6 & The Internet of Things. http://gogonetlive.com
November 12 – 14, 201, Silicon Valley, California
Agenda: http://gogonetlive.com/gogonetlive4-agenda.asp
PRESENTATION
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things”
Abstract: http://www.gogo6.com/profiles/blogs/scaling-the-web-to-billions-of-nodes-towards-the-ipv6-internet-of
Presentation video: http://www.gogo6.com/video/scaling-the-web-to-billions-of-nodes-by-carsten-bormann-at-gogone
Interview video: http://www.gogo6.com/video/interview-with-carsten-bormann-at-gogonet-live-4-ipv6-iot-confere
SPEAKER
Carsten Bormann - Universität Bremen TZI & IETF WG Chair
Bio/Profile: http://www.gogo6.com/profile/CarstenBormann
MORE
Learn more about IPv6 on the gogoNET social network and our online training courses
http://www.gogo6.com/main
Get free IPv6 connectivity with Freenet6
http://www.gogo6.com/Freenet6
Subscribe to the gogo6 IPv6 Channel on YouTube
http://www.youtube.com/subscription_center?add_user=gogo6videos
Follow gogo6 on Twitter
http://twitter.com/gogo6inc
Like gogo6 on Facebook
http://www.facebook.com/pages/IPv6-products-community-and-services-gogo6/161626696777
Overview of VPN protocols.
VPNs (Virtual Private Networks) are often viewed from the perspective of security with the goal of providing authentication and confidentiality.
However, the primary purpose of VPNs is to connect 2 topologically separated private networks over a public network (typically the Internet).
VPNs basically hook a network logically into another network so that both appear as one private local network.
Security is a possible add-on to VPNs. In many cases it makes perfectly sense to secure the VPNs communication over the unsecure public network.
VPN protocols typically employ a tunnel where data packets of the local network are encapsulated in an outer protocol for transmission over the public network.
The most important VPN protocols are IPSec, PPTP and L2TP. In recent years SSL/TLS based VPNs such as OpenVPN have gained widespread adoption.
RINA research results - NGP forum - SDN World Congress 2017ARCFIRE ICT
RINA is a radically simple network architecture that takes an inter-process communication (IPC) approach. The key aspects of RINA are:
1) It uses a single type of layer called a Distributed IPC Facility (DIF) that can repeat as many times as needed. Each layer provides the same service of communication flows between application instances.
2) Layers isolate different scopes and allocate resources (e.g. bandwidth) to competing flows in a programmable way.
3) Experimental results show RINA can solve problems like congestion control and seamless renumbering more easily than IP networks. It also simplifies network management.
Rina converged network operator - etsi workshopARCFIRE ICT
1. The document discusses a converged network vision that supports any access media and application using a common network infrastructure with a single architecture, management system, and user database.
2. It questions whether all-IP networks are fit for this purpose, as the IP protocol suite was not designed for generality and scalability.
3. The document introduces RINA as a better approach, describing its unified model of networking as inter-process communication, consistent layered architecture, and support for naming, addressing, mobility, security, and management.
The document provides an overview of network architecture and proposes a new architecture called RINA. It discusses flaws in the current Internet architecture, including its layered structure, protocol design, naming and addressing scheme, and application programming interface. The document then outlines key aspects of the proposed RINA architecture, including using Distributed IPC Facilities (DIFs) to provide inter-process communication services across different scopes, a consistent layered structure based on allocating IPC resources, a unified framework for data transfer and layer management protocols, and a naming scheme that supports mobility and multi-homing without special protocols.
The document discusses network architecture and proposes improvements to current approaches. It suggests treating layers as units that provide interprocess communication over different scopes. Each layer would provide a single type of service and the number of layers is not fixed. It also proposes having a single unified data transfer protocol framework and layer management protocol across all layers to reduce complexity. This would help standardization bodies design complete network protocols more easily.
Rumba is a Python framework that enables large-scale experimentation with the Recursive InterNetwork Architecture (RINA). It provides plugins that interface with different testbeds and prototypes. The document shows an example script that defines nodes and DIFs using the Rumba and rlite prototypes, runs the experiment on a JFed testbed, and starts a rinaperf client-server performance test between two nodes.
1) The ARCFIRE project is experimentally validating the benefits of RINA technology through large-scale experiments on the FIRE+ testbed involving over 100 nodes across multiple distributed information fields (DIFs).
2) In RINA, application names uniquely identify applications, addresses are location-dependent synonyms used for locating applications within a DIF, and other identifiers like port-ids and connection endpoint IDs are used to identify communication endpoints.
3) RINA's naming and addressing approach simplifies multi-homing and mobility by assigning addresses to nodes instead of interfaces, avoiding the need for special protocols.
The hague rina-workshop-mobility-eduardICT PRISTINE
1) The ARCFIRE project is experimentally validating the benefits of RINA technology through large-scale experiments on the FIRE+ testbed involving over 100 nodes across multiple distributed information fields (DIFs).
2) In RINA, application names uniquely identify applications, addresses are location-dependent synonyms used for locating applications within a DIF, and other identifiers like port-ids and connection endpoint IDs are used to identify communication endpoints.
3) RINA's naming and addressing model simplifies multi-homing and mobility by assigning addresses to nodes instead of interfaces, avoiding the need for special protocols and allowing mobility to be treated as dynamic multi-homing with expected failures.
Distributed mobility management and application discoveryARCFIRE ICT
This document summarizes the results of Experiment 5 of the ARCFIRE project. The experiment demonstrated distributed mobility management (DMM) in RINA by allowing a mobile host to soft handover between different wireless access points while maintaining service continuity. It also showed application discovery across different DIFs as the mobile host moved. Finally, it demonstrated multi-access support by allowing the mobile host to connect to different physical networks and access applications hosted in different DIFs and locations as it moved. The key findings were that RINA's layered structure allows for mobility and multi-homing without specialized protocols or tunnels, and that service continuity is preserved during handovers despite some increase in packet loss and delay.
The document discusses Internet of Things (IoT) networks and routing protocol RPL. It provides an agenda for covering open standards, IEEE and IETF work on low-power lossy networks (LLNs) and 6LoWPAN, concepts of RPL including DODAG, instances, objective functions and messages. It also discusses putting the pieces together including backbone routers and data packet flows. The goal is to reconsider basic Internet structures and expectations to support trillions of constrained devices connecting in IoT applications.
3 hours course on IEEE and IETF protocols introducing the 6TiSCH architecture and the RPL routing protocol. Course given at telecom Bretagne on Feb 12th 2014
Overview of SCTP (Stream Control Transmission Protocol)Peter R. Egli
Overview of SCTP (Stream Control Transmission Protocol), outlining the main features and capabilities of SCTP.
SCTP is a transport protocol that overcomes many of the shortcomings of TCP, namely head-of-line blocking and stream-oriented transmission.
SCTP supports multiple streams within a connection and preserves boundaries of application messages thus greatly simplifying communication.
Additionally, SCTP supports multi-homing which increases availability in applications with high reliability demands.
SCTP inherits much of the congestion, flow and error control mechanisms of TCP.
SCTP has its roots in telecom carrier networks for use in transitional voice over IP scenarios.
However, SCTP is generic so that it is applicable in many enterprise applications as well.
RINA provides a recursive, layered approach to networking where each layer, called a Distributed IPC Facility (DIF), has the same basic functions but with different scopes and policies. Congestion control in RINA is implemented in a distributed manner across DIF layers through the Error and Flow Control Protocol (EFCP). EFCP consists of the Data Transfer Protocol (DTP) and optional Data Transfer Control Protocol (DTCP) which coordinate through a shared state vector to provide reliable data transfer, flow control, and congestion management without the scalability issues faced by TCP in the Internet.
The document summarizes the goals, methodology, and results of experiments with the RINA architecture on the FIRE testbed. The goals were to explore the RINA QoS model in practice, experiment with scheduling policies to differentially allocate loss and delay, and demonstrate RINA for IP VPN scenarios. Experiments on a single DIF showed differentiation of QoS classes, but IP VPN performance was impacted by buffers. Larger experiments on multiple DIFs also showed QoS differentiation, but with higher than expected latency likely due to the prototype implementation.
This document summarizes an approach called RINA (Recursive InterNetwork Architecture) for simplifying multi-layer network management. RINA proposes a common, repeating structure across layers with only two protocols - one for data transfer and one for layer management. This significantly reduces the complexity of management models compared to the IP protocol suite, which has unique protocols at each layer. A case study shows how RINA could simplify network management in a large-scale data center network by reducing the number of required addresses, forwarding entities, and management protocols. The consistent structure of RINA opens the door to increased network automation by making management models simpler and more standardized.
This document discusses experiments conducted using the Contiki operating system and RPL routing protocol in wireless sensor networks. It describes setting up networks with different numbers of relay and client nodes. Experiments were run with sensor nodes sending data at various frequencies to measure network performance over time periods ranging from a day to multiple days. Results on packet loss are presented. Further work is proposed to conduct more extensive RPL testing under additional configurations and add sensor nodes to track object movement.
The document describes an SDK to exploit the programmability of RINA. RINA is a networking architecture based on the theory that networking is inter-process communication. The SDK aims to provide programmable functions at each layer through consistent APIs. It discusses design decisions around using Linux, a user/kernel split, programming languages, and threading models. The goal is to separate mechanism from policy to simplify network structure and support new requirements through re-usable policies across layers.
The document discusses the fringe of the Internet, which includes low power lossy networks (LLNs) connected by radio links. It describes characteristics of LLNs like highly constrained devices, small frame sizes, and energy efficiency requirements. The routing protocol for LLNs needs to be adapted to these types of links. The document outlines different approaches for connecting LLNs to the Internet, including mesh under, route over, and overlay models. It introduces RPL as an IETF routing protocol designed for routing over radio in LLNs.
IRATI: an open source RINA implementation for Linux/OSICT PRISTINE
This document provides an overview of IRATI, an open source implementation of RINA for Linux/OS. It discusses the goals of being tightly integrated with the OS, supporting existing applications, and experimentation. The high-level design uses a Linux kernel with user-space daemons. Implementation status provides details on various IPCP components and policies. Experimental activities describe designing RINA networks and interoperating with legacy technologies. Open source initiatives discuss the IRATI GitHub organization and planned contributions from projects like PRISTINE and IRINA.
Overview of SCTP (Stream Control Transmission Protocol)Peter R. Egli
Overview of SCTP (Stream Control Transmission Protocol), outlining the main features and capabilities of SCTP.
SCTP is a transport protocol that overcomes many of the shortcomings of TCP, namely head-of-line blocking and stream-oriented transmission.
SCTP supports multiple streams within a connection and preserves boundaries of application messages thus greatly simplifying communication.
Additionally, SCTP supports multi-homing which increases availability in applications with high reliability demands.
SCTP inherits much of the congestion, flow and error control mechanisms of TCP.
SCTP has its roots in telecom carrier networks for use in transitional voice over IP scenarios.
However, SCTP is generic so that it is applicable in many enterprise applications as well.
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things” b...gogo6
gogo6 IPv6 Video Series. Event, presentation and speaker details below:
EVENT
gogoNET LIVE! 4: IPv6 & The Internet of Things. http://gogonetlive.com
November 12 – 14, 201, Silicon Valley, California
Agenda: http://gogonetlive.com/gogonetlive4-agenda.asp
PRESENTATION
Scaling the Web to Billions of Nodes: Towards the IPv6 “Internet of Things”
Abstract: http://www.gogo6.com/profiles/blogs/scaling-the-web-to-billions-of-nodes-towards-the-ipv6-internet-of
Presentation video: http://www.gogo6.com/video/scaling-the-web-to-billions-of-nodes-by-carsten-bormann-at-gogone
Interview video: http://www.gogo6.com/video/interview-with-carsten-bormann-at-gogonet-live-4-ipv6-iot-confere
SPEAKER
Carsten Bormann - Universität Bremen TZI & IETF WG Chair
Bio/Profile: http://www.gogo6.com/profile/CarstenBormann
MORE
Learn more about IPv6 on the gogoNET social network and our online training courses
http://www.gogo6.com/main
Get free IPv6 connectivity with Freenet6
http://www.gogo6.com/Freenet6
Subscribe to the gogo6 IPv6 Channel on YouTube
http://www.youtube.com/subscription_center?add_user=gogo6videos
Follow gogo6 on Twitter
http://twitter.com/gogo6inc
Like gogo6 on Facebook
http://www.facebook.com/pages/IPv6-products-community-and-services-gogo6/161626696777
Overview of VPN protocols.
VPNs (Virtual Private Networks) are often viewed from the perspective of security with the goal of providing authentication and confidentiality.
However, the primary purpose of VPNs is to connect 2 topologically separated private networks over a public network (typically the Internet).
VPNs basically hook a network logically into another network so that both appear as one private local network.
Security is a possible add-on to VPNs. In many cases it makes perfectly sense to secure the VPNs communication over the unsecure public network.
VPN protocols typically employ a tunnel where data packets of the local network are encapsulated in an outer protocol for transmission over the public network.
The most important VPN protocols are IPSec, PPTP and L2TP. In recent years SSL/TLS based VPNs such as OpenVPN have gained widespread adoption.
The document provides an overview of TCP/IP, including its origins, standards groups, models, protocols, and analysis. Key points covered include TCP/IP's design goals of withstanding disruption and enabling interoperability, the transition from IPv4 to IPv6 to address limited addresses, and how protocol analyzers work to capture and decode network packets for troubleshooting.
The document discusses making networking stacks more extensible through the use of eBPF programs. It describes how eBPF can be used to program IPv6 segment routing, make TCP more customizable through hooks in the stack, and allow routing protocols to be extended through plugins. Examples are given of using eBPF to add monitoring to TCP and implement flexible filtering in BGP. The performance impact of eBPF programs is shown to be minimal compared to native code implementations.
Colt has gained experience implementing SDN and NFV technologies including:
1) A SDN overlay for network virtualization in their data centers.
2) A modular managed service platform with SDN automation of the WAN.
3) A pre-NFV virtualized L3 CPE solution. Upcoming projects include an NFV proof of concept evaluating virtualized L3 CPE, load balancers, and route reflectors. The document also outlines potential use cases for SDN and NFV in mobile backhaul networks.
Data Plane Evolution: Towards Openness and FlexibilityAPNIC
This document discusses data plane evolutions and future implementations. It summarizes a presentation on network virtualization overlays (NVO3) and encapsulation considerations. Programmable silicon that is field upgradable could simplify deployment of future encapsulations. The P4 programming language also aims to accelerate programmability and wider feature deployment in a target independent way. Overall, future data plane implementations require openness, flexibility, and careful consideration to avoid overly complex architectures.
This section provides background on VoIP applications and their components. It discusses how VoIP works by transmitting voice packets over IP networks, unlike traditional PSTN which uses circuit switching. The two main VoIP protocols are H.323 and SIP, which provide call control and setup. UDP is typically used instead of TCP for transmitting VoIP due to its lower overhead and lack of error checking, which is tolerable for voice transmission. IPv4 and IPv6 can both be used to transmit VoIP, with IPv6 having a larger header size.
The document describes two experiments conducted using the OPNET simulation tool. Experiment 1 involves simulating a TCP network using different congestion control mechanisms and analyzing OSPF routing. Experiment 2 compares the bus and star network topologies by creating networks with each in OPNET and collecting statistics on traffic and delay. The objectives are to get familiar with OPNET, study TCP algorithms, simulate OSPF routing, and understand the pros and cons of different topologies. Tasks for each experiment are described in detail, including how to set up the simulations, configure nodes and links, select statistics, and run the simulations.
Irati goals and achievements - 3rd RINA WorkshopEleni Trouva
The IRATI project had the objectives of advancing the state of the art of RINA by developing a prototype implementation on Linux and evaluating its performance compared to TCP/IP. The project developed a modular RINA implementation in C++ across userspace and kernelspace with programmable IPCPs. Experimental results showed the implementation could achieve line-rate performance and evaluations explored factors like credit allocation and retransmission policies. The project also worked to refine RINA specifications and increase awareness of RINA through dissemination and discussing its standardization.
This document provides an introduction to Sigtran, which is a working group that defined an architecture and protocols for transporting real-time signaling data like SS7 over IP networks. It describes the key components of the Sigtran architecture, including the new SCTP transport protocol and user adaptation layers that allow protocols like SS7 and ISDN to be carried over SCTP in a way that addresses limitations of TCP. The document outlines problems with using TCP and explains how features of SCTP like multi-streaming help make it better suited for transporting signaling messages.
Fronthaul technologies kwang_submit_to_slideshareKwangkoog Lee
5G Fronthaul Technologies (Especially, this document specifies the e-CPRI technology, because many telcos are now considering the eCPRI for the next fronthaul.)
This document proposes using Locator/ID Separation Protocol (LISP) to simplify routing in networks that use IPsec VPN devices (IVDs). LISP separates endpoint identifiers from routing locators, allowing more efficient routing between secure routers connected via IVDs without needing full-mesh generic routing encapsulation (GRE) tunnels. LISP uses IP/UDP encapsulation that works seamlessly over IVDs, and limits the number of IP prefixes IVDs must store to simplify operations. The document compares LISP to the current GRE tunnel approach and outlines how LISP's separation of identifiers and locators can improve routing scalability and mobility in IVD networks.
IP QoS signaling in the IETF:Past, Present and FutureJohn Loughney
The document summarizes the past, present, and future work of the IETF related to QoS signaling. It describes the early work on RSVP and IntServ in the late 1990s. It then outlines the various working groups formed to develop differentiated services, resource allocation protocols, policy frameworks, and sub-IP technologies. Finally, it discusses the Next Steps in Signaling working group, which aims to standardize a new IP signaling protocol to simplify and generalize RSVP signaling, along with its goals and deliverables.
A Comparative Analysis of Additional Overhead Imposed by Internet Protocol Se...ijceronline
IPSec, an Internet layer three (3)-security protocol suite is often characterising with introducing an additional space and processing overhead when implemented on a network for secured communication using either internet protocol version 4 or 6; IPv4 or IPv6. The use of Internet protocol security (IPSec) on IPv4 is an alternative that offers solutions and addresses the security vulnerabilities in network layer of the open system interconnect (OSI) and transmission control protocol/internet protocol (TCP/IP) protocol stack. In IPv6, IPSec is one among many other features added to the earlier Internet protocol to enhance efficiency and security. This paper, set as its objective to reports on the impact of processing and space overhead introduced by IPSec on both IPv4 and IPv6 in relation to packet end-to-end delay based on different IPSec transformations with different authentication and encryption algorithms deployed in different scenarios simulated using NS2. The experiment result reveals that the cost of IPSec added overhead is relatively small when smaller packet sizes are involved for both protocols in comparison with large packet sizes that were IPSec protected with the same configuration as the smaller packet, unless in the cases whereby the packet was very large which has to be fragmented. This paper can therefore, serve as a guide for network administrators to trade up between processing cost and larger address space specifically for transmission involving larger IP packets
The Impact of Software-based Virtual Network in the Public CloudChunghan Lee
Today’s cloud network consists of sophisticated virtual
networks, and a virtual switch is a key element of these
networks. Although there is tremendous interest in measuring
cloud network performance, little is known about the impact
of software-based virtual network on latency. In this paper, we
conduct the impact of virtual network on latency in the public
cloud based on OpenStack. We measured the throughput of VMs
and simultaneously captured their packets on hosts. We analyzed
the traces by using well-known metrics, such as throughput and
RTT, and investigated the abrupt fluctuation of latency called as
‘the burstiness of latency’. We quantitatively clarify the impact of
software-based virtual network on latency. In our public cloud,
the latency is approximately 35.2% of RTT and 10% of burstiness
mainly contributes to the increased RTT. The total latency was
increased by the receiving side regardless of data and ACK
paths. Our analysis results, discussions, and implications can
not only help cloud researchers and developers design the next
generation of software-based virtual network but can also help
cloud operators improve the performance of virtual network.
IETF building block in the LwM2M Ecosystem (IoT World 2017 Workshop)Open Mobile Alliance
This presentation is delivered by Hannes Tschofening, ARM and Co-chair of IETF ACE & OAuth WGs.
IETF has developed a Constrained Application Protocol (CoAP) which is designed to easily translate to HTTP for simplified integration with the web. It is intended for use in resource constrained internet devices. OMA LwM2M uses CoAP as a transport mechanism. In this presentation, our speaker from IETF will provide you with an introduction to CoAP:
● What is CoAP
● How CoAP works
● What other IETF standards are used by LwM2M
● What is next for IETF in this space
This document evaluates the performance of Linux bridge compared to a Cisco switch and Linux router. It finds that Linux bridge has satisfactory performance when system occupancy is below 56%, with latency and throughput comparable to a Cisco switch. Performance remains acceptable up to 85% occupancy. Latency and throughput of Linux bridge and router are also found to be similar. The results suggest Linux bridge is suitable for applications with WAN links below 10M and for education. Benchmark testing was done following RFC-2544 to measure frame loss, throughput and latency.
Multi-operator "IPC" VPN Slices: Applying RINA to Overlay NetworkingARCFIRE ICT
This document discusses the concept of "IPC VPN slices" which provide distributed inter-process communication (IPC) between applications using the Recursive Internet Network Architecture (RINA). It describes how IPC VPN slices can be implemented across single and multiple domains/operators using RINA's distributed IPC facility (DIF) as an overlay. The objective is to provide an autonomous IPC VPN overlay and separation of concerns between the VPN and underlying L2 VPN fabric, as well as service continuity as endpoints attach across different access networks. It also shows how slice orchestration in this architecture provides recursive abstraction between different administrative domains.
Large-scale Experimentation with Network Abstraction for Network Configuratio...ARCFIRE ICT
This experiment tested the scalability and performance of a distributed management system (DMS) using RINA abstractions to manage 24 different network configurations of varying sizes running on 6 machines. The key results were that the DMS was able to manage all 24 networks using a single management strategy with high levels of automation (over 90%). The strategy was able to scale efficiently to networks with over 400,000 nodes and complete management tasks over 10 times faster than networks without using RINA abstractions. This provides evidence that applying RINA simplifies network management and improves performance and scalability.
Design Considerations for RINA Congestion Control over WiFi LinksARCFIRE ICT
The document discusses design considerations for congestion control over WiFi links using the RINA framework. It begins with background on how traditional Internet congestion control assumptions break down over wireless networks. Measurements of WiFi DCF behavior show it can behave predictably. A machine learning approach is proposed to predict attainable rates. Localized congestion control loops in RINA or with PEPs could rely directly on predicted rates, improving performance over TCP. Benefits include optimized performance over WiFi links, including in wireless mesh networks.
One of the Ways How to Make RIB DistributedARCFIRE ICT
The document discusses using the RAFT consensus algorithm to distribute the Routing Information Base (RIB) in a fault-tolerant way. RAFT is chosen because it is an understandable version of Paxos that is easy to implement and suitable for RINA environments. The key aspects of RAFT covered are leader election based on timer expiration, log replication from the leader to followers, and how client requests would be handled within the RINA approach. A demonstration topology with 4 RAFT nodes and 1 client is proposed to test the implementation.
Unifying WiFi and VLANs with the RINA modelARCFIRE ICT
This document proposes a unified model called WiLAN to characterize VLANs and Wi-Fi networks through the RINA model. It maps VLAN and Wi-Fi standards into aspects of the RINA model to create a unified representation. The key aspects of the WiLAN model include distinct "media DIFs" for wired and wireless networks, with one or more "common DIFs" operating over the media DIFs. This provides a simplified representation and potential improvements over current standards by reducing header overhead and improving security by removing MAC addresses from frames.
First Contact: Can Switching to RINA save the Internet?ARCFIRE ICT
RINA aims to provide advantages over the current Internet by optimizing all phases of communication. The study evaluates RINA's performance compared to TCP in a one-ISP scenario. It finds that RINA reduces preparation time compared to DHCP and DNS in the Internet, and improves efficiency for subsequent connections by reusing existing flows. RINA shows potential to combine benefits of TCP extensions like Fast Open. Future work includes optimizing RINA proxies and investigating a full transition from the Internet to RINA.
Experimenting with Real Application-specific QoS Guarantees in a Large-scale ...ARCFIRE ICT
This document reports on an experiment conducted using a 37-node RINA network emulated on the Virtual Wall experimentation facility. The experiment evaluated RINA's ability to provide quality of service guarantees through the QTA-Mux policy. Synthetic traffic flows mimicking different applications were injected under varying load conditions. Results showed that with QTA-Mux configured at both core and metro DIFs, adequate QoS differentiation was achieved even under high congestion. However, with QTA-Mux only at the core DIF, QoS was lost at the metro DIF. A high-definition video streaming demonstration also showed near-perfect quality of experience when the video flows received a gold QoS cube
This document summarizes how the Recursive InterNetwork Architecture (RINA) approach simplifies multi-layer network management compared to the traditional IP approach. RINA uses a single, consistent layer type and management protocol (CDAP) across all layers, reducing complexity compared to IP which has unique layer types and protocols. This common structure in RINA simplifies management models and enables greater automation of multi-layer networks. The document provides examples comparing IP and RINA models for data center fabric management and tenant network management.
The document discusses a RINA experiment evaluating mobility management in RINA networks. The experiment involved a mobile host moving between different wireless subnets and accessing applications over multiple distributed information field (DIF) layers. Mobility was managed through routing updates and designing the DIF layers to accommodate the scale and rate of change of mobile terminals. The experiment validated that RINA can support mobility without special protocols by leveraging its complete naming and addressing scheme.
The document discusses security in the Recursive InterNetwork Architecture (RINA) model. It argues that RINA is inherently more secure than the current Internet architecture due to its design principles. Specifically, it notes that in RINA:
1) A Distributed Information Field (DIF) acts as a "securable container" that isolates applications and provides built-in authentication of members.
2) Attacks like port scanning are much more difficult due to decoupling of port allocation and connection synchronization.
3) Common Internet protocols like IPsec are unnecessary because RINA provides security at lower layers through authentication and integrity protection of data.
4) RINA requires significantly fewer total protocols and security mechanisms than
This document discusses distributed application facilities (DAFs) and their relationship to distributed interprocess communication facilities (DIFs) in the RINA architecture. Some key points:
- DAFs consist of distributed application processes (DAPs) that cooperate to perform distributed functions. DAFs are similar to DIFs but operate at the application layer rather than the network layer.
- DAFs use underlying DIFs for communication between members but can span multiple DIFs. Managing this inter-DIF communication is one role of the DAP's IPC management component.
- DAF management is performed by local DAF management tasks that coordinate with their peers. A DAF manager may oversee
This document discusses name space management in the Recursive InterNetwork Architecture (RINA). It describes how name space management distribution management systems (NSM-DMSs) can manage application name spaces that span multiple DIFs. NSM-DMSs allow applications to discover other applications across DIF boundaries. They authenticate applications, manage policies for updating name space data, and help determine which DIFs are needed between applications. For large systems, some NSM-DAPs contain only local information while others aggregate information. Queries are forwarded between these to discover applications. Creation of supporting DIFs may also be needed between source and destination applications. The document compares this application discovery approach to the current DNS system and discusses
This document discusses principles of naming and addressing in computing systems and for interprocess communication (IPC) specifically. It covers topics like name spaces, naming operations, types of names, resolving names, naming in IPC, and principles of naming and addressing. The key points are that names indicate what an object is, addresses indicate where an object is located for forwarding purposes, and names and addresses should be assigned and structured appropriately for their intended scopes and uses.
This document discusses the history of addressing and routing in computer networks. It traces the development of the ARPANET addressing system and how its limitations led to problems as networks grew in size and complexity. The document argues that the IP protocol does not fully implement the necessary separation of addressing spaces, leading to ongoing issues around scaling, multihoming, and routing table growth. It examines various proposed solutions and frameworks over the decades to address these problems, ultimately concluding that any approach based on separating locators and identifiers will not solve the fundamental issues.
This document provides an introduction to the RINA architecture. It discusses key concepts in RINA including separating mechanism and policy, the structure of protocols, implications of Richard Watson's work on distributed synchronization, and resolving the connection-oriented vs. connectionless debate. The document argues that in RINA, there is only one application protocol and one data transfer protocol, in contrast to models like OSI and TCP/IP that define multiple protocols at each layer.
This document discusses the evolution of computer networking and the layered model. It describes early packet switching networks in the 1960s and 1970s like CYCLADES which introduced a layered architecture. There was debate between the INWG 39 and 61 proposals for an international transport protocol. By 1976 a synthesis called INWG 96 was approved, though TCP/IP was still developed separately. Significantly, all the early proposals included addressing at multiple layers of scope, unlike the later Internet architecture of TCP, IP, and data link layers.
Rumba is a Python framework for automating large-scale recursive internet experiments on testbeds like GENI and FIRE+. It allows users to define virtual network topologies with nodes and distributed interprocess communication facilities (DIFs) representing network links. Rumba provides plugins that interface with different testbeds and emulation platforms. It also includes tools like Storyboard for scheduling experiments and collecting results.
Rumba is a Python framework that allows users to write Python scripts to define RINA networks and run scripted experiments. First, Rumba, creates a physical network on one of the selected testbed. If needed, Rumba can do an installation of the RINA prototype on the testbed machines. The RINA network is then bootstrapped on the available nodes. Finally, the experiment can be swapped out of the testbed.
This talk introduces the main concepts to be able to understand RINA, explains its key principles and introduces the architectural problems it addresses.
Decentralized Justice in Gaming and EsportsFederico Ast
Discover how Kleros is transforming the landscape of dispute resolution in the gaming and eSports industry through the power of decentralized justice.
This presentation, delivered by Federico Ast, CEO of Kleros, explores the innovative application of blockchain technology, crowdsourcing, and incentivized mechanisms to create fair and efficient arbitration processes.
Key Highlights:
- Introduction to Decentralized Justice: Learn about the foundational principles of Kleros and how it combines blockchain with crowdsourcing to develop a novel justice system.
- Challenges in Traditional Arbitration: Understand the limitations of conventional arbitration methods, such as high costs and long resolution times, particularly for small claims in the gaming sector.
- How Kleros Works: A step-by-step guide on the functioning of Kleros, from the initiation of a smart contract to the final decision by a jury of peers.
- Case Studies in eSports: Explore real-world scenarios where Kleros has been applied to resolve disputes in eSports, including issues like cheating, governance, player behavior, and contractual disagreements.
- Practical Implementation: Detailed walkthroughs of how disputes are handled in eSports tournaments, emphasizing speed, cost-efficiency, and fairness.
- Enhanced Transparency: The role of blockchain in providing an immutable and transparent record of proceedings, ensuring trust in the resolution process.
- Future Prospects: The potential expansion of decentralized justice mechanisms across various sectors within the gaming industry.
For more information, visit kleros.io or follow Federico Ast and Kleros on social media:
• Twitter: @federicoast
• Twitter: @kleros_io
Honeypots Unveiled: Proactive Defense Tactics for Cyber Security, Phoenix Sum...APNIC
Adli Wahid, Senior Internet Security Specialist at APNIC, delivered a presentation titled 'Honeypots Unveiled: Proactive Defense Tactics for Cyber Security' at the Phoenix Summit held in Dhaka, Bangladesh from 23 to 24 May 2024.
Securing BGP: Operational Strategies and Best Practices for Network Defenders...APNIC
Md. Zobair Khan,
Network Analyst and Technical Trainer at APNIC, presented 'Securing BGP: Operational Strategies and Best Practices for Network Defenders' at the Phoenix Summit held in Dhaka, Bangladesh from 23 to 24 May 2024.
KubeCon & CloudNative Con 2024 Artificial Intelligent
Generic network architecture discussion
1. GENERIC NETWORK ARCHITECTURE (WI9)
RINA PRINCIPLES, RESEARCH RESULTS, DEMOS
Eduard Grasa, Fundació i2CAT
ETSI NGP#8 September 7th 2017
2. 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
5. 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
8. 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
9. 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
10. Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
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
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP DIFPtP DIFPtP DIFPtP DIF
PtP
DIF
PtP
DIF
PtP
DIF
13
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
Metro DIF Metro DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP DIFPtP DIFPtP DIFPtP DIF
PtP
DIF
PtP
DIF
PtP
DIF
Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
14
12. 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
Metro DIF Metro DIFCore DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP DIFPtP DIFPtP DIFPtP DIF
PtP
DIF
PtP
DIF
PtP
DIF
Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
15
13. 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
Provider VPN Service DIF
Metro DIF Metro DIFCore DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP DIFPtP DIFPtP DIFPtP DIF
PtP
DIF
PtP
DIF
PtP
DIF
Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
16
14. 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
Green Customer VPN DIF
Provider VPN Service DIF
Metro DIF Metro DIFCore DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP DIFPtP DIFPtP DIFPtP DIF
PtP
DIF
PtP
DIF
PtP
DIF
Recursive, generic layer structure (I)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
17
15. 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)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
18
Bridging
16. 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
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
EPS bearerEPS bearer
LTE-Uu
S1-U S5/S8
MAC
L1
SGi
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
Recursive, generic layer structure (II)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
19
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
Mobile Operator
Transport DIF
Mobile Operator
Transport DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
Recursive, generic layer structure (II)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
20
Bridging
18. 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
Multi-access
radio DIF
Mobile Operator
Transport DIF
Mobile Operator
Transport DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
Recursive, generic layer structure (II)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
21
Bridging
19. 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
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
Recursive, generic layer structure (II)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
22
Bridging
20. 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
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
Recursive, generic layer structure (II)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
23
Bridging
21. 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)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
24
22. 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 PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
Recursive, generic layer structure (III)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
25
23. 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 PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
DC Fabric DIF
Recursive, generic layer structure (III)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
26
24. 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 PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
PtP
DIF
DC Fabric DIF
Tenant DIF
Recursive, generic layer structure (III)
(see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu)
27
26. 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
27. 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
28. 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
29. 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
30. 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
31. 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
32. 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
33. 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
34. 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
35. 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
36. 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
39. 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
40. 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
42. 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
43. 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
44. 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
45. 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
46. 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
47. 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
48. 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
49. 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
50. 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
51. 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
52. 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
54. 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
55. 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
56. 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
57. 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
59. 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
60. 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
62. 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
63. 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
. . .
64. 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
Layers are resource allocators, provide IPC services over a certain scope, they all have the same functions
Green Customer DIF: The VPN service for the user
Provider VPN Service DIF: Manages all of the network resources allocated to VPN services.
Metro DIF: Manages resources allocated to metropolitan network. Aggregates customer traffic into core PoPs
Core DIF: Provides connectivity and performance between Core POPs.
Green Customer DIF: The VPN service for the user
Provider VPN Service DIF: Manages all of the network resources allocated to VPN services.
Metro DIF: Manages resources allocated to metropolitan network. Aggregates customer traffic into core PoPs
Core DIF: Provides connectivity and performance between Core POPs.
Green Customer DIF: The VPN service for the user
Provider VPN Service DIF: Manages all of the network resources allocated to VPN services.
Metro DIF: Manages resources allocated to metropolitan network. Aggregates customer traffic into core PoPs
Core DIF: Provides connectivity and performance between Core POPs.
Green Customer DIF: The VPN service for the user
Provider VPN Service DIF: Manages all of the network resources allocated to VPN services.
Metro DIF: Manages resources allocated to metropolitan network. Aggregates customer traffic into core PoPs
Core DIF: Provides connectivity and performance between Core POPs.
Green Customer DIF: The VPN service for the user
Provider VPN Service DIF: Manages all of the network resources allocated to VPN services.
Metro DIF: Manages resources allocated to metropolitan network. Aggregates customer traffic into core PoPs
Core DIF: Provides connectivity and performance between Core POPs.
Green Customer DIF: The VPN service for the user
Provider VPN Service DIF: Manages all of the network resources allocated to VPN services.
Metro DIF: Manages resources allocated to metropolitan network. Aggregates customer traffic into core PoPs
Core DIF: Provides connectivity and performance between Core POPs.
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 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 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 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 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 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).
* Link state routing within each serving area
* Size of each DIF limited by # of mobile devices and speed of mobility (so that routing has time to converge) -> No problem, we can use multiple DIFs to structure the mobile network