Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

3. RINA use cases, results, benefits

290 views

Published on

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.

Published in: Internet
  • Be the first to comment

3. RINA use cases, results, benefits

  1. 1. Large scale RINA Experimentation on FIRE + Use cases, results, benefits RINA Workshop @ Telefonica Eduard Grasa, Fundació i2CAT
  2. 2. STRUCTURE: LAYERING 2
  3. 3. 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 • 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. 3
  4. 4. • 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) 4
  5. 5. 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 5
  6. 6. • 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) 6
  7. 7. • 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) 7
  8. 8. • 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) 8
  9. 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 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) 9
  10. 10. • 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) 10 Bridging
  11. 11. • 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) 11
  12. 12. • 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) 12 Bridging
  13. 13. • 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) 13 Bridging
  14. 14. • 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) 14 Bridging
  15. 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 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) 15 Bridging
  16. 16. • 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) 16
  17. 17. • 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 DIFPtP DIFPtP DIF Recursive, generic layer structure (III) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 17
  18. 18. • 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 DIFPtP DIFPtP DIF DC Fabric DIF Recursive, generic layer structure (III) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 18
  19. 19. • 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 DIFPtP DIFPtP DIF DC Fabric DIF Tenant DIF Recursive, generic layer structure (III) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 19
  20. 20. PROTOCOLS WITHIN A GENERIC LAYER 20
  21. 21. Separation of mechanism from policy 21 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 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
  22. 22. 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 22
  23. 23. 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 23
  24. 24. 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_Control_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 … ” 24
  25. 25. 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) 25
  26. 26. 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 26
  27. 27. 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 27
  28. 28. NAMING, ADDRESSING, MOBILITY 28
  29. 29. 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). 29
  30. 30. 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 30
  31. 31. Flows and addresses 31
  32. 32. Multiple DIFs scenario, continuous renumbering • Service provider scenario – 41 nodes – Two MAN networks – 1 core network – 18 CPEs • Each CPE allocates 10 flows to other – 180 concurrent flows 32 Access Router PtP DIF CPE Edge Service Router Metro Edge Router Metro Edge Router Metro BB DIF Metro service DIF PtP DIF PtP DIF PtP DIF PtP DIF Metro P router PTP DIF Residential customer service DIF Host PtP DIF Public Internet or App-specific or VPN DIF Backbon e Router Backbon e router PtP DIF PtP DIF Backbone DIF Provider Edge Router Provider Edge Router PtP DIF Customer network Service Prov. 2Service Prov. 1 network Access Aggregation Service Edge Core Internet Edge Public Internet or App-specific or VPN DIF Home DIF Customer Premises Equipment Access Router MAN Access Router MAN Core Router Edge Services Router Backbone router
  33. 33. Results at the Virtual Wall (II) No packet loss 0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00 8.00 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97 100 103 106 109 112 115 118 121 124 127 130 133 136 139 142 145 148 151 154 157 160 163 166 169 172 175 178 Endtoenddelay(ms) Samples (individual flows) Mean of end-to-end delay for each flow (ms) No renumber Renumber 0.00 0.50 1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50 5.00 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67 70 73 76 79 82 85 88 91 94 97 100 103 106 109 112 115 118 121 124 127 130 133 136 139 142 145 148 151 154 157 160 163 166 169 172 175 178 Standarddeivaonofe2edelay(ms) Samples (inidividual flows) Standard devia on of end to end delay (ms) No renumber Renumber 33
  34. 34. 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) 34
  35. 35. Implications for mobility 1.2.1 1.2.2 1.2.3 1.2.51.2.4 1.1.1 1.1.2 Subnet1 (1.x.y) 2.2.1 2.2.2 2.2.3 2.2.52.2.4 2.1.1 2.1.2 Subnet2 (2.x.y) 0.1.0 0.2.0 2.0.11.0.1 35 (1) IPCP in MH @ 1.0.1 (2) IPCP in MH @ 1.0.1 @ 2.0.1 (3) IPCP in MH @ 2.0.1 1.0.1 2.0.1 IPCPs in Base Stations IPCPs in Base Stations IPCPs in edge routers IPCPs in core routers IPCPs in core routers
  36. 36. Mobile network with multiple layers Border Router Core DIF Under DIFs Border Router Under DIFs Border RouterBase StationMH Radio DIF 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 36
  37. 37. Example with 4 levels (where needed) Urban Sub-urban Urban UrbanDense Urban BS DIF District DIF LegendMetro DIF Regional DIF 37
  38. 38. Scenario: physical systems • Single service provider with small edge DC to host latency-critical or high- bandwidth services 38 Large-scale RINA Experimentation on FIRE+ 14 UE 1 UE 2 AR 1 AR 2 AR 3 AR 4 AR 5 AR 6 ER 1 ER 2 CR 1 ISP 1 ISP 2 SRV 5 SRV 6 SRV 1 SRV 2 SRV 3 SRV 4 ToR 2 ToR 1 DC GW Small DC Service Provider net Data Center Gateway User Equipment Provider Access Router Edge Router Provider 1 Core Router ISP Router Server Top of Rack Router • Six access routers – WiFi Aps • 2 Edge routers • 1 Core router • 1 small DC – 1 DC GW – 2 TORs – 2 servers at each ToR • 2 Mobile Hosts (UEs) – 1 roaming, 1 static
  39. 39. Scenario: DIFs • Mobile network DIF: provides DMM and supports service DIFs • Internet DIF: provides access to apps available through servers at the Internet • Slice1 DIF: provides UE1 access to apps available through provider DC • Slice 2 DIF: provides UE2 access to apps available through provider DC 39 UE Access 1 Edge 1 Core 1 ISP1 Server6 Mobile network DIF Internet DIF DAF (rina-tgen or rina-echo-time) Shim DIF WiFi Shim DIF Eth Shim DIF Eth Shim DIF Eth Shim DIF Eth UE 2 A1 A4 A2 E1 C1 E2 Mobile Network DIF I1 UE C1 S1 S2I2 Internet DIF A3 A5 A6 DC UE Access 2 Edge 1 DC Gateway ToR 1 Server 1 Mobile network DIF Enterprise 1 VPN DIF DAF (Any demo app) Shim DIF WiFi Shim DIF Eth Shim DIF Eth Shim DIF Eth Shim DIF Eth S2 GW S4Enterprise 2 VPN DIF DC Fabric DIF S1 UE 1 GW S3Enterprise 1 VPN DIF UE 2 S2 S1 S3 S4 GW ToR 1 ToR 2
  40. 40. Application discovery (I) 40 Access 2 Edge 1 DC Gateway ToR 1 Server 1 Mobile network DIF Slice 1 DIF Shim DIF WiFi Shim DIF Eth Shim DIF Eth Shim DIF Eth Shim DIF Eth DC Fabric DIF A C UE App_name: rina-echo-time.server-aneto--
  41. 41. Application discovery (II) 41 UE Access 1 Edge 1 Core 1 ISP1 Server5 Mobile network DIF Internet DIF Shim DIF WiFi Shim DIF Eth Shim DIF Eth Shim DIF Eth Shim DIF Eth A B App_name: rina-echo-time.server-montblanc--
  42. 42. Application discovery (III) 42Large-scale RINA Experimentation on FIRE+ 20 App_name: rina-echo-time.server-ll-- Access 2 Edge 1 Shim DIF WiFi Shim DIF Eth A UE Mobile network DIF D
  43. 43. Some results on Mobility Management • “Mobility Management in RINA networks: experimental validation of architectural policies” – E. Grasa, L. Bergesio, M. Tarzan, D. Lopez, S. van der Meer, J. Day, L. Chitkushev – IEEE WCNC 2018, Barcelona – Paper not online yet – “This paper analyses what properties such schema needs to have, and discusses how Internet mobility solutions are missing parts of it. Then it looks at RINA, a network architecture with a complete naming scheme. Theoretical analysis backed up by experimental validation of the main properties for mobility support shows that managing mobility in RINA networks not only is simpler and easier to scale compared to the Internet situation, but also that no special protocols or mechanisms need to be added to RINA in order to support mobility.” 43
  44. 44. 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.” 44
  45. 45. 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_Programmable_Topological_R outing_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. “ 45
  46. 46. SECURITY 46
  47. 47. 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 4747 47
  48. 48. 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” 48
  49. 49. Separating port allocation from sync. Complete application naming • With app-names no need for well-known ports. Port-ids of local scope (not in protocol headers) • CEP-ids (in protocol headers) dynamically generated for each flow 49 IPCPP A App A Port-id read/ write 1 EFCP instance, cep-id 8736 IPCPP A App B Port-id read/ write 4 EFCP instance, cep-id 9123 Synchronization • Well-known ports used to identify app endpoints; statically assigned. @s exposed to apps. • Ports used also to identify TCP instances (in protocol headers). Attacker only needs to guess source port-id RINA TCP/IP IP@: 12 Port read/ write 12 TCP instance, port 12 IP @: 78 Port read/ write 78 TCP instance, port 78 TCP PM A TCP PM A
  50. 50. Scope as a native construct Recursion provides isolation • Size each DIF to the scope supported applications need – Only allow those that really need to connect to the apps • No need for extra tools to do that: scope is built-in – DIFs are securable containers, no need for firewalls 50 Internet (TCP/IP) RINA Default model Global connectivity Controlled connectivity Control scope via Firewalls, ACLs, VLANs, Virtual Private Networks, etc.. Scope native concept in architecture (DIF) Example: Provider’s network internal layers hidden from customers and other providers
  51. 51. 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” 51
  52. 52. Separation of mechanism from policy 52 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 Management • All layers have the same mechanisms and 2 protocols (EFCP for data transfer, CDAP for layer management), programmable via policies. • Don’t specify/implement security protocols, only security policies – Re-use common layer structure, re-use security policies across layers • This approach greatly simplifies the network structure, minimizing the cost of security and improving the security level – Complexity is the worst enemy of security (B. Schneier) Authentication Access control (layer mgmt operations) Access control (joining the DIF) Coordination of security functionsConfidentiality, Integrity Source: J. Small master thesis
  53. 53. 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_protecting_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 ” 53
  54. 54. NETWORK MANAGEMENT 54
  55. 55. 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 55 55
  56. 56. 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.” 56
  57. 57. Some results on network management • “Taming policy complexity: Model to Execution” – S. van der Meer, J. Keeney, L. Fallon – IEEE NOMS 2018 – Paper not online yet – “However, policy-based management as a standalone domain has never been evaluated in terms of which parts are variant / invariant, i.e. which parts of policy-based management can be domain-, model-, language-, use case-independent. In this paper, we introduce and define a formal universal policy model that does exactly that. The result is a model that can be used to design, implement, and deploy immutable policy infrastructure (engine and executor) being able to execute (virtually) any policy model.” 57
  58. 58. DEPLOYMENT / INTEROP 58
  59. 59. 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 59
  60. 60. RINA application API 60
  61. 61. Overlays: RINA over X via shim DIFs 61 ToR ToRFabric Spine FabricServer Server IPv4 or IPv6 (Fabric layer)VM VM Ethernet Ethernet Ethernet Ethernet Tenant DIF Ethernet UDP Ethernet Sh,. memSh,. mem Shim DIF HV Shim DIF HV Shim DIF UDP App B App A
  62. 62. IP over RINA • 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 62 DIF Shim DIF Eth Shim DIF Eth IP layer . . .
  63. 63. IP over RINA: provider-based IP VPNs 63 DIF Ethernet blue-pe2- rina_ip blue-pe1- rina_ip PE router 1 PE router 2 3 5 port-id port-id App name: <VPN id>-<node name>-RINA_IP- Process name Process instance Entity name P router 1 P router 2 Ethernet Ethernet Shim DIF Eth Shim DIF Eth Shim DIF Eth
  64. 64. Gateways (e.g. Transport layer gateways) 64
  65. 65. 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 65 4 65

×