This talk introduces the main concepts to be able to understand RINA, explains its key principles and introduces the architectural problems it addresses.
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.
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.
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 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.
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.
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 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.
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.
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.
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.
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 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.
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.
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 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.
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.
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.
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.
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.
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.
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
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.
The hageu rina-workshop-security-peterICT PRISTINE
RINA provides a framework to securely manage connectivity and network association. It protects layers instead of individual protocols, and addresses are contained within securable Distributed Interface Functions (DIFs). DIFs can replace firewalls and enable centralized policy-based authentication, authorization, and access control. RINA separates security mechanisms from policies, uses a common layer structure across layers, and minimizes complexity to improve security. It also provides a new access control architecture and key management system to securely manage network functions even if systems are compromised.
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.
This document discusses a proof-of-concept implementation of a RINA interior router using P4. The goals are to increase RINA credibility by providing a high-performance router implementation at a reasonable cost, and to understand limitations of current network programmability approaches. The implementation targets the BMv2 P4 software switch, demonstrating basic interior router functions for EFCP packets. Future work includes implementing the design on hardware and evaluating the feasibility of a border router.
EU-Taiwan Workshop on 5G Research, PRISTINE introductionICT PRISTINE
The PRISTINE project aims to explore programmability in RINA (Recursive Internet Architectures) through developing a RINA software development kit. It will demonstrate RINA's applicability and benefits in three use cases - datacenters, distributed clouds, and carrier networks. The project is building a RINA simulator and working towards commoditizing networking equipment through standardized programmability APIs, with the goals of increasing flexibility, automation, and innovation while reducing costs.
RINA detailed components overview and implementation discussionEleni Trouva
The document discusses RINA and provides details on several key concepts:
1) Distributed applications in RINA use application naming, flows between applications can have different QoS characteristics, and there is a common application connection establishment phase.
2) The IPC process and API provide a communication service between applications using flows. The API supports operations like flow allocation and data transfer.
3) CDAP is the recommended application protocol for RINA applications to exchange shared state and establish connections. It defines messages and operations for managing objects.
The hague rina-workshop-interop-deployment_vincenzoICT PRISTINE
This document discusses interoperability between RINA and the Internet and approaches for porting existing network applications to RINA. It describes three solutions for deploying RINA together with the Internet: using RINA as an overlay network, as a substrate, or with RINA/TCP gateways. It also proposes a POSIX-like API for RINA to help port applications and demonstrates porting SSH and web servers to RINA with small code changes.
Update on IRATI technical work after month 6Eleni Trouva
This document provides an update on technical work in IRATI after month 6, including a description of use cases for integration testing and cloud/network integration, refinement of RINA specifications like the shim DIF over Ethernet and forwarding table generator, and an overview of the high-level software architecture and mapping of RINA concepts to the IRATI implementation. It outlines components like application processes, the IPC process daemon, IPC manager daemon, and supporting libraries.
Experimental evaluation of a RINA prototype - GC 2014Eleni Trouva
The document summarizes an experimental evaluation of a Recursive InterNetwork Architecture (RINA) prototype. It describes the basic concepts of RINA including its layered architecture and use of Distributed I/P Control (DIPC) processes. It then provides details on the implementation of the IRATI RINA prototype on Linux, including its use of shim DIF and IPC processes to test applications across different hosts and network topologies. Extra information is also provided on an upcoming RINA workshop and accessing the IRATI prototype code.
This document provides an overview of Rlite, an open source light implementation of the RINA networking model for Linux. Rlite includes both user-space and kernel-space components. The kernel-space implementation provides basic RINA functionality like flow allocation and data transfer. The user-space components include libraries, daemons, and tools to administer the RINA stack. Rlite aims to provide a minimal but stable baseline RINA implementation for developing future RINA products and applications.
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.
RINA overview and ongoing research in EC-funded projects, ISO SC6 WG7Eleni Trouva
The document discusses investigating RINA as an alternative to TCP/IP. It describes some of the challenges faced by current network architectures, including complexity, security issues, and lack of quality of service support. It then provides an introduction to the Recursive Internet Architecture (RINA) and describes some prototypes that have been developed, including FP7 projects to further advance RINA research.
RINA essentials, PISA Internet Festival 2015ICT PRISTINE
1) The document discusses the evolution from the TCP/IP networking model to the Recursive InterNetwork Architecture (RINA) model.
2) RINA addresses architectural flaws in TCP/IP like layered modularity and a lack of built-in security. It also simplifies addressing and eliminates the need for middleboxes.
3) RINA features a single type of layer with a consistent application programming interface, two core protocols, and programmable functions to provide inter-process communication as a distributed application.
TCP/IP is the standard communication protocol on the internet. It is comprised of several layers including application, transport, internet, and link layers. The transport layer includes TCP and UDP which provide connection-oriented and connectionless data transmission respectively. TCP ensures reliable data delivery through features like connections, acknowledgments, and flow control. IPv6 is the latest version of the Internet Protocol which addresses the shortcomings of IPv4 like limited address space. IPv6 features include a larger 128-bit address space, simplified header format, built-in security, and autoconfiguration capabilities.
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.
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.
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.
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.
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
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.
The hageu rina-workshop-security-peterICT PRISTINE
RINA provides a framework to securely manage connectivity and network association. It protects layers instead of individual protocols, and addresses are contained within securable Distributed Interface Functions (DIFs). DIFs can replace firewalls and enable centralized policy-based authentication, authorization, and access control. RINA separates security mechanisms from policies, uses a common layer structure across layers, and minimizes complexity to improve security. It also provides a new access control architecture and key management system to securely manage network functions even if systems are compromised.
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.
This document discusses a proof-of-concept implementation of a RINA interior router using P4. The goals are to increase RINA credibility by providing a high-performance router implementation at a reasonable cost, and to understand limitations of current network programmability approaches. The implementation targets the BMv2 P4 software switch, demonstrating basic interior router functions for EFCP packets. Future work includes implementing the design on hardware and evaluating the feasibility of a border router.
EU-Taiwan Workshop on 5G Research, PRISTINE introductionICT PRISTINE
The PRISTINE project aims to explore programmability in RINA (Recursive Internet Architectures) through developing a RINA software development kit. It will demonstrate RINA's applicability and benefits in three use cases - datacenters, distributed clouds, and carrier networks. The project is building a RINA simulator and working towards commoditizing networking equipment through standardized programmability APIs, with the goals of increasing flexibility, automation, and innovation while reducing costs.
RINA detailed components overview and implementation discussionEleni Trouva
The document discusses RINA and provides details on several key concepts:
1) Distributed applications in RINA use application naming, flows between applications can have different QoS characteristics, and there is a common application connection establishment phase.
2) The IPC process and API provide a communication service between applications using flows. The API supports operations like flow allocation and data transfer.
3) CDAP is the recommended application protocol for RINA applications to exchange shared state and establish connections. It defines messages and operations for managing objects.
The hague rina-workshop-interop-deployment_vincenzoICT PRISTINE
This document discusses interoperability between RINA and the Internet and approaches for porting existing network applications to RINA. It describes three solutions for deploying RINA together with the Internet: using RINA as an overlay network, as a substrate, or with RINA/TCP gateways. It also proposes a POSIX-like API for RINA to help port applications and demonstrates porting SSH and web servers to RINA with small code changes.
Update on IRATI technical work after month 6Eleni Trouva
This document provides an update on technical work in IRATI after month 6, including a description of use cases for integration testing and cloud/network integration, refinement of RINA specifications like the shim DIF over Ethernet and forwarding table generator, and an overview of the high-level software architecture and mapping of RINA concepts to the IRATI implementation. It outlines components like application processes, the IPC process daemon, IPC manager daemon, and supporting libraries.
Experimental evaluation of a RINA prototype - GC 2014Eleni Trouva
The document summarizes an experimental evaluation of a Recursive InterNetwork Architecture (RINA) prototype. It describes the basic concepts of RINA including its layered architecture and use of Distributed I/P Control (DIPC) processes. It then provides details on the implementation of the IRATI RINA prototype on Linux, including its use of shim DIF and IPC processes to test applications across different hosts and network topologies. Extra information is also provided on an upcoming RINA workshop and accessing the IRATI prototype code.
This document provides an overview of Rlite, an open source light implementation of the RINA networking model for Linux. Rlite includes both user-space and kernel-space components. The kernel-space implementation provides basic RINA functionality like flow allocation and data transfer. The user-space components include libraries, daemons, and tools to administer the RINA stack. Rlite aims to provide a minimal but stable baseline RINA implementation for developing future RINA products and applications.
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.
RINA overview and ongoing research in EC-funded projects, ISO SC6 WG7Eleni Trouva
The document discusses investigating RINA as an alternative to TCP/IP. It describes some of the challenges faced by current network architectures, including complexity, security issues, and lack of quality of service support. It then provides an introduction to the Recursive Internet Architecture (RINA) and describes some prototypes that have been developed, including FP7 projects to further advance RINA research.
RINA essentials, PISA Internet Festival 2015ICT PRISTINE
1) The document discusses the evolution from the TCP/IP networking model to the Recursive InterNetwork Architecture (RINA) model.
2) RINA addresses architectural flaws in TCP/IP like layered modularity and a lack of built-in security. It also simplifies addressing and eliminates the need for middleboxes.
3) RINA features a single type of layer with a consistent application programming interface, two core protocols, and programmable functions to provide inter-process communication as a distributed application.
TCP/IP is the standard communication protocol on the internet. It is comprised of several layers including application, transport, internet, and link layers. The transport layer includes TCP and UDP which provide connection-oriented and connectionless data transmission respectively. TCP ensures reliable data delivery through features like connections, acknowledgments, and flow control. IPv6 is the latest version of the Internet Protocol which addresses the shortcomings of IPv4 like limited address space. IPv6 features include a larger 128-bit address space, simplified header format, built-in security, and autoconfiguration capabilities.
The document introduces RINA (Recursive Internet Architecture), a new networking architecture that aims to address structural problems with the OSI reference model. RINA defines a single type of layer that repeats as needed, providing the same inter-process communication (IPC) service between applications. It separates mechanisms from policies to simplify management. RINA allows for incremental deployment alongside existing technologies and is being researched through open source projects and standardization efforts.
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.
The document summarizes security policies in the Recursive InterNetwork Architecture (RINA). It discusses how RINA protects layers instead of protocols by applying consistent security models across all layers. It also describes how RINA separates mechanism from policy, allowing security functions to be programmed via policies instead of implementing specific security protocols. The document outlines experiments with authentication and encrypted packet policies using the IRATI open source RINA implementation.
RINA: Update on research and prototyping activities. Global Future Internet W...Eleni Trouva
The document provides an update on RINA research and prototyping activities. It begins with introducing some perspectives on RINA including that the goal is to build better computer networks, RINA learns from past networking research, and there are no predefined design goals. It then provides an overview of the RINA architecture including that it uses a recursive layering approach and Distributed IPC Facilities (DIFs). The document discusses benefits of a Java prototype implemented over IP including providing internetwork layers, separating applications from infrastructure, and enabling next-generation VPNs. It also describes the Inter-DIF Directory which allows for application discovery and creation of supporting DIFs.
This slide deck covers Networking Fundamentals, Various Penetration testing standards, OWASP TOP 10 Vulnerabilities of Web Application and the Lab Setup required for Penetration testing.
This document discusses managing multi-layer networks and the challenges of closing the control loop in autonomic networks. It proposes using the Recursive InterNetwork Architecture (RINA) model, which provides a common structure and set of protocols across layers to simplify network management. RINA could reduce costs and downtime compared to the Internet Protocol (IP) model with its many isolated protocols for each layer. The document provides examples of how data center networks and service provider networks could be modeled and managed using RINA.
- Apache Thrift is a cross-language services framework that allows for the easy definition of data types and remote procedure calls (RPCs).
- It uses an interface definition language (IDL) to define data types and services, and generates code in various languages to implement clients and servers.
- Apache Thrift supports a wide range of languages and transports, making it useful for building high-performance, scalable distributed applications and microservices.
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.
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.
The document provides an overview of commands and techniques used to verify connectivity and acquire device information in a small network. It describes using ping and traceroute to test connectivity between devices and troubleshoot connectivity issues. It also explains using the ipconfig command on Windows and ifconfig/ip commands on Linux to view a host's IP configuration, and introduces commands like show ip interface brief for viewing IP information on routers.
This document discusses network management and its key components of fault management, configuration management, accounting management, performance management, and security management. It provides details on fault management, configuration management, and performance management. Fault management detects, isolates, and resolves problems to minimize downtime. Configuration management maintains information about network components. Performance management measures network utilization to regulate users and ensure service level agreements are met. It also discusses the TCP/IP protocol model and its layers including physical network, data link, internet, transport, and application layers.
The document discusses various protocols at the network layer of the TCP/IP model, including ICMP, IGMP, ARP, and RARP.
ICMP is a control protocol used for network administration and management. It carries network status information such as issues, congestion, and host accessibility. IGMP is used to manage Internet Protocol multicast group memberships. ARP resolves IPv4 addresses to MAC addresses to allow communication between network applications and the datalink layer. RARP is a reverse address resolution protocol that allows a client to request its IPv4 address from the network when it only knows its MAC address.
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.
The document provides an overview of the OSI model and TCP/IP protocols. It describes the seven layers of the OSI model from the physical layer to the application layer and their functions. It also explains the four layers of the TCP/IP model and some of the common protocols used in each layer such as IP, TCP, UDP, HTTP, FTP etc. Additionally, it summarizes the Address Resolution Protocol (ARP), which maps IP addresses to MAC addresses when a host needs to deliver a packet on a local network.
The document provides an overview of the OSI model and TCP/IP protocols. It describes the seven layers of the OSI model from the physical layer to the application layer. It then explains the five layers of the TCP/IP model and how encapsulation works. The document also covers topics such as addressing, fragmentation, segmentation, and IP addressing and subnetting.
This document provides an overview of building and maintaining a small network. It discusses:
1) The key devices used in small networks, including routers, switches, servers and end devices. It emphasizes the importance of planning network designs and IP addressing schemes.
2) Common applications and protocols used in small networks, such as HTTP, SMTP, FTP and DHCP. It also discusses voice/video applications and protocols like RTP.
3) How small networks can scale to larger networks over time. It stresses the importance of network documentation, device inventory, budgeting, and traffic analysis when planning for growth.
This document discusses Internet of Things (IoT) networking standards that enable IoT devices to connect using IPv6. It covers protocols like 6LoWPAN that allow IPv6 to be used over low-power wireless networks, as well as standards for routing (RPL), security (DTLS, CoAP), and device management (LWM2M, SUIT). It also mentions low-power wide area network technologies (LPWANs) and the Thread mesh networking standard that are important for connecting many IoT devices using IPv6.
This document discusses middleware classification and architecture. It covers the following key components of middleware:
1. The communication link, which is typically TCP/IP or SNA.
2. The middleware protocol, also called the wire protocol, which defines the message format and state transitions.
3. The API, which can be object-oriented, operations-based, or language-based. APIs may block or not block the processing thread.
It then discusses Microsoft's DNA and Java EE architectures, which both utilize web servers, transactional middleware engines, and services like messaging and directories. Both architectures partition applications into presentation, business logic, and data tiers, though DNA uses COM and Java EE uses Java
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
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.
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 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.
Gen Z and the marketplaces - let's translate their needsLaura Szabó
The product workshop focused on exploring the requirements of Generation Z in relation to marketplace dynamics. We delved into their specific needs, examined the specifics in their shopping preferences, and analyzed their preferred methods for accessing information and making purchases within a marketplace. Through the study of real-life cases , we tried to gain valuable insights into enhancing the marketplace experience for Generation Z.
The workshop was held on the DMA Conference in Vienna June 2024.
Ready to Unlock the Power of Blockchain!Toptal Tech
Imagine a world where data flows freely, yet remains secure. A world where trust is built into the fabric of every transaction. This is the promise of blockchain, a revolutionary technology poised to reshape our digital landscape.
Toptal Tech is at the forefront of this innovation, connecting you with the brightest minds in blockchain development. Together, we can unlock the potential of this transformative technology, building a future of transparency, security, and endless possibilities.
Understanding User Behavior with Google Analytics.pdfSEO Article Boost
Unlocking the full potential of Google Analytics is crucial for understanding and optimizing your website’s performance. This guide dives deep into the essential aspects of Google Analytics, from analyzing traffic sources to understanding user demographics and tracking user engagement.
Traffic Sources Analysis:
Discover where your website traffic originates. By examining the Acquisition section, you can identify whether visitors come from organic search, paid campaigns, direct visits, social media, or referral links. This knowledge helps in refining marketing strategies and optimizing resource allocation.
User Demographics Insights:
Gain a comprehensive view of your audience by exploring demographic data in the Audience section. Understand age, gender, and interests to tailor your marketing strategies effectively. Leverage this information to create personalized content and improve user engagement and conversion rates.
Tracking User Engagement:
Learn how to measure user interaction with your site through key metrics like bounce rate, average session duration, and pages per session. Enhance user experience by analyzing engagement metrics and implementing strategies to keep visitors engaged.
Conversion Rate Optimization:
Understand the importance of conversion rates and how to track them using Google Analytics. Set up Goals, analyze conversion funnels, segment your audience, and employ A/B testing to optimize your website for higher conversions. Utilize ecommerce tracking and multi-channel funnels for a detailed view of your sales performance and marketing channel contributions.
Custom Reports and Dashboards:
Create custom reports and dashboards to visualize and interpret data relevant to your business goals. Use advanced filters, segments, and visualization options to gain deeper insights. Incorporate custom dimensions and metrics for tailored data analysis. Integrate external data sources to enrich your analytics and make well-informed decisions.
This guide is designed to help you harness the power of Google Analytics for making data-driven decisions that enhance website performance and achieve your digital marketing objectives. Whether you are looking to improve SEO, refine your social media strategy, or boost conversion rates, understanding and utilizing Google Analytics is essential for your success.
Discover the benefits of outsourcing SEO to Indiadavidjhones387
"Discover the benefits of outsourcing SEO to India! From cost-effective services and expert professionals to round-the-clock work advantages, learn how your business can achieve digital success with Indian SEO solutions.
Instagram has become one of the most popular social media platforms, allowing people to share photos, videos, and stories with their followers. Sometimes, though, you might want to view someone's story without them knowing.
3. So.. What do we want?
• As much invariants as possible in the architecture, so that we can minimize the
number of protocols and maximize their commonality
3
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
commonalityProtocols
4. Application API: IPC services
• Application names are location independent (the network locates the apps); addresses internal to
the network
• Application provides service requirements for their flows (loss, delay, etc.), the network chooses
the right protocols to provide them
4
Host Host
App
A
App
B
App A
IPC API
OS
IPC
1. Register/Unregister App
2. Allocate/Deallocate flows
3. Write data (SDUs) to flows
4. Read data (SDUs) from flows
The network locates the destination application (directory), and configures
protocols for each flow
“The network” provides communication flows
5. What is the nework?
• Provides IPC services, but what is it? Some hints:
– Executes in computers running operating systems (PCs, laptops, routers, sensors,
smartphones, tables, switches, etc.)
– Has instances distributed through many machines, exchanging information and collaborating
– Just like… the web, Skype, email, etc.
• Therefore the network is just a distributed application specialised to
provide IPC
– We’ll call this application a DIF (Distributed IPC Facility)
5
Host
DIF
Host
App
A
App
B
RouterRouter
6. Structure: layering (I)
• But a single DIF for all applications and all machines in the world/universe is not
very scalable ...
– We need to isolate scopes (link, network, Internet, VPN, etc.)
• Multiple DIFs, providing IPC services to each other!
– After all a DIF is just a distributed application, right?
6
Host
Border router Interior Router
DIF
DIF DIF
Border router
DIF
DIF
DIF
Host
App
A
App
B
Consistent API
through layers
7. Layering, a better pattern (II)
• Single type of layer, providing an IPC Service that repeats as many times as
needed by the network designer
• A layer is a resource allocator that provides an manages the IPC service over a
given scope (link, network, Internet, VPN, etc.). A layer allocates resources
(memory in buffers, scheduling capacity, bandwidth) to competing flows.
Host Router Router Border
Router
Router Router HostBorder
Router
Network 2
SNAC
SNDC
SNIC
Application
DIF DIF DIF DIF DIF DIFDIF
DIF DIF
DIF
7
Network 1
8. Let’s go to our to-do list
• We have improved
– Structure
– Protocol design
– Naming and addressing scheme
– Service model / Application API
– Security
– Network management
• Still work to do, let’s move on!
8
9. What protocols inside a DIF?
• A DIF is a distributed application, how can we organise its functions?
– Remember: data transfer, data transfer control, layer management
• But we want to limit the variability in protocols to the minimum: apply
separation of mechanism and policy
– Mechanism are the parts in a protocol that are fixed (e.g. an acknowledgement ACK)
– Policy is the part of the protocol that can change (e.g. when to send an ACK is policy)
• Each DIF has different requirements, so we cannot have the same protocols in
all of them, but can we abstract invariances so that we end up with:
– 1 protocol (framework) for data transfer?
– 1 protocol (framework) for layer management?
9
10. EFCP: Error and Flow Control Protocol
• 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 header fields)
– Plugging in the right policies (for flow control, retx. control, congestion contol)
10
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 ControlRetransmission Control
Flow Control
Flow Control
Namespace Management Security ManagementEFCP
App A
IPC API
IPC
Process
11. Unified layer management
11
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
12. 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..)
12
13. Let’s go to our to-do list
• We have improved
– Structure
– Protocol design
– Naming and addressing scheme
– Service model / Application API
– Security
– Network management
• Still work to do, let’s move on!
13
14. Naming and addressing, mobility, routing
No need for special protocols
14
Name Indicates Property RINA IP
Application name What Location independent Yes No
Node address Where Location dependent, route
independent
Yes No
Point of Attachment How to get there Route dependent Yes Yes (twice: IP,
MAC)
15. Implications for multi-homing
15
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 routing/forwarding table reduction!
• No need for special protocols to support multi-
homing
Addresses assigned to interfaces (like in IP) Addresses assigned to nodes (like in RINA)
16. Security: DIFs are securable containers
Secure layers instead of protocols, expose less to apps, scope
16
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
No application names, addresses exposed to applications, well-
known ports
17. Network management
Commonality is the key to effective network management
17
• 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
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
RINA Introduction
18. Let’s go to our to-do list
• We have improved
– Structure
– Protocol design
– Naming and addressing scheme
– Service model / Application API
– Security
– Network management
• And made Homer happy!
18
19. Summing up.. RINA is not a protocol!
19
• Network architecture resulting from a fundamental theory of computer networking
• Networking is InterProcess Communication (IPC) and only IPC. Unifies networking and
distributed computing: the network is a distributed application that provides IPC
• There is a single type of layer with programmable functions, that repeats as many times as
needed by the network designers (DIF!)
• All layers provide the same service: instances or communication (flows) to two or more
application instances, with certain characteristics (delay, loss, in-order-delivery, etc)
• There are only 3 types of systems: hosts, interior and border routers. No middleboxes (firewalls,
NATs, etc) are needed
• Deploy it over, under and next to current networking technologies
1
2
3
4
5
6
20. AND HOW DO YOU PRETEND TO DEPLOY
THIS STUFF?
5
20
21. Incremental deployment
• IPv6 brings very small improvements to IPv4, but requires a clean slate
deployment (not compatible to IPv4)
• 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
21
Editor's Notes
Number and scope of layers is not decided by architecture but by the network designer: use the best number for each building
Invariant structure with respect to the type of network being designed: the repeating building block with a consistent service interface (IPC) helps network designers to bound structural complexity
We still face the problem of what is the internal structure of such a generic IPC layer? How many protocols? How do they look like? Are there invariants we can extract to further simplify and streamline the process of network design?
Reduce the number of data transfer protocols to a few (maybe 10 or so?), all sharing the same abstract syntax and the same mechanisms
Much easier to specify, implement and debug
Networks become much easier to understand, manage and troubleshoot -> cheaper to operate and more reliable
Innovation becomes much easier -> don’t need to design and implement full-fledged protocols, just new policies
E.g. almost all TCP variants are just a little change in the congestion control policy
We can share some work done on PRISTINE to understand what it means to specify/develop this data transfer policies
Number and scope of layers is not decided by architecture but by the network designer: use the best number for each building
Invariant structure with respect to the type of network being designed: the repeating building block with a consistent service interface (IPC) helps network designers to bound structural complexity
We still face the problem of what is the internal structure of such a generic IPC layer? How many protocols? How do they look like? Are there invariants we can extract to further simplify and streamline the process of network design?
Number and scope of layers is not decided by architecture but by the network designer: use the best number for each building
Invariant structure with respect to the type of network being designed: the repeating building block with a consistent service interface (IPC) helps network designers to bound structural complexity
We still face the problem of what is the internal structure of such a generic IPC layer? How many protocols? How do they look like? Are there invariants we can extract to further simplify and streamline the process of network design?