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.

Generic network architecture discussion

141 views

Published on

DIscussion of RINA principles, research results, implementations and demos. Presented at ETSI ISG NGP meeting # 8

Published in: Internet
  • Be the first to comment

  • Be the first to like this

Generic network architecture discussion

  1. 1. GENERIC NETWORK ARCHITECTURE (WI9) RINA PRINCIPLES, RESEARCH RESULTS, DEMOS Eduard Grasa, Fundació i2CAT ETSI NGP#8 September 7th 2017
  2. 2. What is our goal? It is not about IP vs. non-IP protocols, problems are deeper! As much invariants as possible in the architecture, so that we can minimize the number of protocols and maximize their commonality Architecture: patterns, invariants, building blocks, methods Protocols Today: • Architecture has too little patterns/commonality, and they are a bit broken • Too many protocols, too little commonality Architecture: patterns, invariants, building blocks, methods What we want: • Architecture provides as much invariants as possible • Few protocols, sharing lots of commonality Protocols 2
  3. 3. Work Item 9: table of contents (I) 6
  4. 4. Work Item 9: table of contents (II) 7
  5. 5. NGP Generic Protocol Model Case(Generic Protocol Architecture) Network Equipment Compute Entity Network Entity 4 Port P Po(3) Point of Attachment Protocol Layer Physical Link Web Client Application 8
  6. 6. NGP Generic Protocol Model: Generic IPC network entity 2 5 3 4 Generic IPC Network Entity Generic IPC Network Entity 8 9 N(Generic data transfer protocol) 7859 Relaying & Multiplexing PDU protection PDU protection PDU protection PDU protection SDU delimiting SDU delimiting N(Unified layer management protocol) 5 4 RIB Daemon Flow Allocator Namespace Manager Resource Allocator Security Manager Generic IPC Network Entity (AP name, Address(es)) 25 12 SDU delimiting 9
  7. 7. STRUCTURE: LAYERING 10
  8. 8. RINA macro-structure (layers) Single type of layer, consistent API, programmable policies Host Border router Interior Router DIF DIF DIF Border router DIF DIF DIF (Distributed IPC Facility) Host App A App B Consistent API through Layers (DIFs) are distributed applications that provide IPC services to higher layers (which may be DIFs or other forms of distributed applications) Layers are resource allocators: they manage the layer resources (memory in buffers, scheduling capacity, bandwidth) and provide them to competing flows. 11
  9. 9. RINA recursive layering structure cleans up and generalizes the current protocol stack. Example 1: PBB-VPLS (Virtual Private LAN Service) • Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs Recursive, generic layer structure (I) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 12
  10. 10. Recursive, generic layer structure (I) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) RINA recursive layering structure cleans up and generalizes the current protocol stack. Example 1: PBB-VPLS (Virtual Private LAN Service) • Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF 13
  11. 11. RINA recursive layering structure cleans up and generalizes the current protocol stack. Example 1: PBB-VPLS (Virtual Private LAN Service) • Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs Metro DIF Metro DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF Recursive, generic layer structure (I) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 14
  12. 12. RINA recursive layering structure cleans up and generalizes the current protocol stack. Example 1: PBB-VPLS (Virtual Private LAN Service) • Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs Metro DIF Metro DIFCore DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF Recursive, generic layer structure (I) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 15
  13. 13. RINA recursive layering structure cleans up and generalizes the current protocol stack. Example 1: PBB-VPLS (Virtual Private LAN Service) • Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs Provider VPN Service DIF Metro DIF Metro DIFCore DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF Recursive, generic layer structure (I) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 16
  14. 14. RINA recursive layering structure cleans up and generalizes the current protocol stack. Example 1: PBB-VPLS (Virtual Private LAN Service) • Uses MAC-in-MAC encapsulation to isolate provider’s core from customers addresses and VLANs Green Customer VPN DIF Provider VPN Service DIF Metro DIF Metro DIFCore DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIFPtP DIFPtP DIFPtP DIF PtP DIF PtP DIF PtP DIF Recursive, generic layer structure (I) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 17
  15. 15. Example 2: LTE (Long Term Evolution) • Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network. IP (e.g. Internet) TCP or UDP PDCP GTP-U GTP-U RLC MAC L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1UE eNodeB S-GW P-GW EPS bearerEPS bearer LTE-Uu S1-U S5/S8 MAC L1 SGi Recursive, generic layer structure (II) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 18 Bridging
  16. 16. Example 2: LTE (Long Term Evolution) • Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network. IP (e.g. Internet) TCP or UDP PDCP GTP-U Bridging GTP-U RLC MAC L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1UE eNodeB S-GW P-GW EPS bearerEPS bearer LTE-Uu S1-U S5/S8 MAC L1 SGi PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF Recursive, generic layer structure (II) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 19
  17. 17. Example 2: LTE (Long Term Evolution) • Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network. IP (e.g. Internet) TCP or UDP PDCP GTP-U GTP-U RLC MAC L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1UE eNodeB S-GW P-GW EPS bearerEPS bearer LTE-Uu S1-U S5/S8 MAC L1 SGi Mobile Operator Transport DIF Mobile Operator Transport DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF Recursive, generic layer structure (II) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 20 Bridging
  18. 18. Example 2: LTE (Long Term Evolution) • Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network. IP (e.g. Internet) TCP or UDP PDCP GTP-U GTP-U RLC MAC L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1UE eNodeB S-GW P-GW EPS bearerEPS bearer LTE-Uu S1-U S5/S8 MAC L1 SGi Multi-access radio DIF Mobile Operator Transport DIF Mobile Operator Transport DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF Recursive, generic layer structure (II) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 21 Bridging
  19. 19. Example 2: LTE (Long Term Evolution) • Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network. IP (e.g. Internet) TCP or UDP PDCP GTP-U GTP-U RLC MAC L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1UE eNodeB S-GW P-GW EPS bearerEPS bearer LTE-Uu S1-U S5/S8 MAC L1 SGi Mobile Access Network Top Level DIF Multi-access radio DIF Mobile Operator Transport DIF Mobile Operator Transport DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF Recursive, generic layer structure (II) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 22 Bridging
  20. 20. Example 2: LTE (Long Term Evolution) • Uses PDCP, GTP to transport user’s IP payload, and also relies on internal IP network. IP (e.g. Internet) TCP or UDP PDCP GTP-U GTP-U RLC MAC L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1 UDP IP (LTE transport) MAC MAC. . . L1 . . . L1UE eNodeB S-GW P-GW EPS bearerEPS bearer LTE-Uu S1-U S5/S8 MAC L1 SGi Public Internet DIF (or user VPN DIF, or app-specific DIF, …) Mobile Access Network Top Level DIF Multi-access radio DIF Mobile Operator Transport DIF Mobile Operator Transport DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF Recursive, generic layer structure (II) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 23 Bridging
  21. 21. Example 3: Data Center Network with NVO3 • Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to support multi-tenancy Recursion provides a cleaner, simpler solution than virtualization • Repeat the same building block, with the same interface. ToR ToRFabric Spine Fabric Server ServerIPv4 or IPv6 (Fabric layer) UDPVM VM Ethernet Ethernet Ethernet Ethernet VXLAN802.1Q802.3 802.1Q IPv4 or IPv6 (tenant overlay) TCP or UDP or SCTP, … (transport layer) 802.3 bridging Recursive, generic layer structure (III) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 24
  22. 22. Example 3: Data Center Network with NVO3 • Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to support multi-tenancy Recursion provides a cleaner, simpler solution than virtualization • Repeat the same building block, with the same interface. ToR ToRFabric Spine Fabric Server ServerIPv4 or IPv6 (Fabric layer) UDPVM VM Ethernet Ethernet Ethernet Ethernet VXLAN802.1Q802.3 802.1Q IPv4 or IPv6 (tenant overlay) TCP or UDP or SCTP, … (transport layer) 802.3 bridging PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF Recursive, generic layer structure (III) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 25
  23. 23. Example 3: Data Center Network with NVO3 • Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to support multi-tenancy Recursion provides a cleaner, simpler solution than virtualization • Repeat the same building block, with the same interface. ToR ToRFabric Spine Fabric Server ServerIPv4 or IPv6 (Fabric layer) UDPVM VM Ethernet Ethernet Ethernet Ethernet VXLAN802.1Q802.3 802.1Q IPv4 or IPv6 (tenant overlay) TCP or UDP or SCTP, … (transport layer) 802.3 bridging PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF DC Fabric DIF Recursive, generic layer structure (III) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 26
  24. 24. Example 3: Data Center Network with NVO3 • Network Virtualization Over Layer 3, uses overlay virtual networks on top of the DCN’s fabric layer 3 to support multi-tenancy Recursion provides a cleaner, simpler solution than virtualization • Repeat the same building block, with the same interface. ToR ToRFabric Spine Fabric Server ServerIPv4 or IPv6 (Fabric layer) UDPVM VM Ethernet Ethernet Ethernet Ethernet VXLAN802.1Q802.3 802.1Q IPv4 or IPv6 (tenant overlay) TCP or UDP or SCTP, … (transport layer) 802.3 bridging PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF PtP DIF DC Fabric DIF Tenant DIF Recursive, generic layer structure (III) (see ARCFIRE deliverable D2.2 for detailed examples http://ict-arcfire.eu) 27
  25. 25. PROTOCOLS WITHIN A GENERIC LAYER 28
  26. 26. Separation of mechanism from policy 29 IPC API Data Transfer Data Transfer Control Layer Management SDU Delimiting Data Transfer Relaying and Multiplexing SDU Protection Retransmission Control Flow Control RIB Daemon RIB CDAP Parser/Generator CACEP Enrollment Flow Allocation Resource Allocation Routing Authentication StateVector StateVector StateVector Data TransferData Transfer Retransmission Control Retransmission Control Flow Control Flow Control Namespace Management Security Management All layers have the same mechanisms and 2 protocols (EFCP for data transfer, CDAP for layer management), programmable via policies. • All data transfer and layer management functions are programmable! Don’t specify/implement protocols, only policies • Re-use common layer structure, re-use policies across layers This approach greatly simplifies the network structure, minimizing the management overhead and the cost of supporting new requirements, new physical media or new applications EFCP
  27. 27. Error and Flow Control Protocol (EFCP) One of the main results discussed in Patterns in Network Architecture (PNA), later formalised in RINA. • PNA/RINA only proof this is possible and show a way of arriving to the result. If others propose simpler frameworks with the same capabilities we should definitely go for them. By separating data transfer protocol elements between mechanism (invariant) and policy (variant), it is possible to specify a data transfer protocol framework from which multiple data transfer protocols can be generated by • Choosing a concrete syntax (length of PCI fields) • Plugging in the right policies See EFCP specification for an example of such protocol framework 30
  28. 28. EFCP (II) 1 common data transfer PDU • Abstract syntax: (presence/absence and length of fields varies • E.g.: point to point links -> no need for addresses • 1 application only per IPCP -> no need for cep-ids (e.g. some IoT protocols) A few control PDUs (Ack, ack & flow ctrl, etc.) Policy plug-in points to customize for different environments and application requirements • Flow control (window/rate-based), retransmission control, congestion control 31
  29. 29. E.g. Results on congestion control (I) “Congestion control in the Recursive Internetwork Architecture” • P. Teymoori, M. Welzl, S. Gjessing, E. Grasa, R. Riggio, K. Rausch, D. Siracussa • IEEE ICC 2016 • https://www.researchgate.net/publication/301657524_Congestion_C ontrol_in_the_Recursive_InterNetworking_Architecture_RINA • “… we have shown that congestion control in RINA “naturally” exhibits properties of various improvements that have been made to (or at least proposed for) the Internet, without inheriting the problems that come from imposing these mechanisms on an architecture that was not made for them … ” 32
  30. 30. Results on congestion control (II) RINA can solve the Internet c. c. problems by: • Breaking up the control loop in shorter ones • Controlling flow aggregates inside the network and • Enabling the deployment of arbitrary controllers per DIF Follow up: OCARINA project (lead by U of Oslo)33
  31. 31. DIF API register / unregister (app name) • Associate applications to DIFs allocate_flow(dest_app_name, QoS attributes) • Allocate a flow to a destination app name (may name a group of apps), with a certain QoS (reliable delivery, in order delivery, bounds on delay/jitter, minimum capacity, etc.) read/write (port_id) deallocate_flow(port_id) • Free up resources associated to the flow 34
  32. 32. Dynamic negotiation of cep-ids and policies per flow Application calls “allocate” • Provides dest. app name and flow requirements IPCP(source) selects EFCP policies and computes source cep-id, sends message to IPCP (dest) IPCP (dest) does access control check, selects EFCP policies and computes dest cep-id Today • applications have to select the protocol explicitly • static (well-known) ports as cep-ids • No app names, addresses exposed to apps 35
  33. 33. Example of unified layer management infrastructure: RINA 36 Resource Information Base (RIB): Schema that defines the external representation of the set of objects that model the state of the IPCP (object names, attributes, relationships, allowed CDAP operations and their effects) Common Distributed Application Protocol (CDAP): Application protocol that allows two applications to operate on the objects of each other’s RIB. Provides 6 operations (create/delete/read/write/start/stop). RIB Daemon: Entity that processes incoming CDAP messages (delegating RIB operations to layer mgmt tasks) and generates outgoing CDAP messages from layer management tasks’ requests
  34. 34. Benefits of unified layer management framework Only need one common layer management protocol for all layers, which allows layer management functions to remotely operate on objects (which model the function’s externally visible state) Only need one common distributed memory/database manager for layer management functions • With pluggable replication policies (on demand, event-based, periodic, etc..) Layer management functions just need to specify an object schema, and the behaviour when the common protocol operations are invoked on the objects This is a huge reduction in network complexity, coming from a world were every single layer management/control plane function has one or more standalone protocols, independently designed (ICMP, RSVP, OSPF, RIP, BGP, IS-IS, ARP, DNS, etc..) 37
  35. 35. Overview of IRATI and its SDK C/C++ based RINA implementation for Linux Normal IPC Process (Layer Management) User space IRATI RINA implementation Kernel Kernel IPC Manager Normal IPC Process (Data Transfer/Control) Shim IPCP over 802.1Q IPCP Daemon (Layer Mgmt) IPC Manager Daemon Normal IPCP (Data Transfer) SHIM IPCP App zoom in zoom in zoom in Normal IPCP (Data transfer) Error and Flow Control Protocol Relaying and Multiplexing Task SDU Protection SDK support RTT policy Txctrl policy ECN policy . . . SDK support Forwar policy Schedu policy MaxQ policy Monit policy SDK support TTL policy CRC policy Encryp policy Normal IPCP (Layer Mgmt) RIB & RIB Daemon librina Resource allocation Flow allocation Enrollment Namespace Management Security Management Routing SDK support Auth. policy Acc.ctrl policy Coord policy SDK support Address assign Directory replica Address validat SDK support New flow policy SDK support PFTgen policy Pushbak notify Enroll. sequence SDK support Routing policyIPC Manager librina Manag ement Agent IPCM logic Network Manager (NMS DAF) SDK supportRIB & RIB Daemon Shim IPCP Shim IPCP 38
  36. 36. 39 Remote terminal: Standard laptop, Windows 7 with Ubuntu in Virtualbox Demo host (server): Server with vanilla Debian running RINA network RINA network: X nodes, depending On experiment RINA node (guest): Qemu image run in X KVMs with full RINA Linux kernel static physical PtP connection multiple SSH links public Internet KVM virtualisation Linux links & bridges Demonstrator
  37. 37. Demo scenario 40
  38. 38. NAMING, ADDRESSING, MOBILITY 41
  39. 39. Naming & addressing Application names: Assigned to applications. Location independent. Uniquely identify application within an application namespace. In general name a set (can have a single member). Addresses: Location-dependent synonym of an App name. Facilitates locating the app within a certain context (e.g. IPCPs in a DIF). Its scope is restricted to the DIF. Port-ids: Identifies one end of a flow within a system (local identifier), only id shared with user.** Connection endpoint ids (cep-ids): Identify the EFCP instances that are the endpoints of a connection. QoS-id: Identifies the QoS cube to which the EFCP PDUs belong (PDUs belonging to the same QoS-id receive receive a consistent treatment through the DIF). 42
  40. 40. Implications for multi-homing G A B C E D F H 1 2 6 5 8 3 14 18 17 16 15 19 21 13 20 9 11 10 12 4 7 2 2 G A B C E D F H 1 2 3 1 2 1 3 4 1 2 3 1 2 3 1 2 3 1 1 2 2 2 Addressing the node instead of the interface: 3-4x time next- hop/forwarding table reduction! No need for special protocols to support multi-homing Addresses assigned to interfaces Addresses assigned to nodes 43
  41. 41. Flows and addresses 44
  42. 42. Renumbering demo (single DIF) 30 node network, Single DIF over Ethernet All nodes in the DIF change addresses every 30-60s 60 flows running over the DIF, no flow disruption, no data loss IRATI RINA implementation 45
  43. 43. Experimental results No packet loss during renumbering events Almost no penalty in throughput Penalty in delay for the worst case scenario 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 VPN 1: s14 - s24 VPN2 : s18 - s28 VPN3: s31 - s41 VPN4: s35 -s45 rina-echo-meflowsbetweennodes Applica on RTT (ms) vs. renumbering frequency Every [30, 60] s Every [60, 120] s Every [120, 240] s No renumbering 0 10 20 30 40 50 60 70 80 90 100 VPN 1: s14 - s24 VPN2 : s18 - s28 VPN3: s31 - s41 VPN4: s35 -s45 rina-tgenflowsbetweennodes Applica on goodput (Mbps) vs. renumbering frequency Every [30, 60] s Every [60, 120] s Every [120, 240] s No renumbering • Results in the worst case scenario (constanly renumbering network) • Renumbering can be done live 46
  44. 44. Implications With a proper naming and addressing structure in place, life network renumbering can be done • without impacting existing flows • without the need of extra protocols or mechanisms • in a fully automated way (minimize opex and network downtime) Use cases • Network consolidation (e.g. acquisition of other networks) • Update network addressing scheme to optimize routing (e.g. due to changes in network topology) • Better support for mobility (change address of moving nodes if they attach to different subnets) 47
  45. 45. Implications for mobility Mobility is just dynamic multi-homing with expected failures No need for tunnels -> handovers trigger routing updates Addresses are just temporary synonyms -> IPCP name is stable BS 1.2.1 BS 1.2.2 BS 1.2.3 BS 1.2.5 BS 1.2.4 S-GW 1.1.1 S-GW 1.1.2 Serving Area 1 BS 2.2.1 BS 2.2.2 BS 2.2.3 BS 2.2.5 BS 2.2.4 S-GW 2.1.1 S-GW 2.1.2 Serving Area 2 P-GW 0.1.0 P-GW 0.2.0 UE 1.0.1 UE 1.0.1 UE 2.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 UE 1.0.1 2.0.1 Example: Mobility within a single DIF 48
  46. 46. Mobile network with multiple layers Border Router Core DIF Under DIFs Border Router Under DIFs Border Router Interior Router (Base Station) Host (Mobile) BD DIF (radio) Under DIFs District DIF Metro DIF Regional DIF Public Internet DIF Application-specific DIF Mobile Infrastructure NetworkCustomer Terminal … … … Under DIFs Operator core Create as many DIFs as needed depending on density of mobile devices and speed of mobility in different parts of the mobile network Each application can use the DIF that provides enough scope and QoS for its communication needs -> not restricted to the “top ones” All layers have the same structure and protocols, implementations can be highly optimized; overhead of adding new layers is minimal 49
  47. 47. Example with 4 levels (where needed) Urban Sub-urban Urban UrbanDense Urban BS DIF District DIF LegendMetro DIF Regional DIF 4 levels of DIFs may not be needed everywhere (e.g. suburban, not enough density to require a district DIF). If more levels needed to scale can be added anywhere in the network 50
  48. 48. DMM over WiFi demo: physical systems Wifi (ssid irati) AP1 Wifi (ssid pristine) AP2 Wifi (ssid arcfire) AP3 Wifi (ssid irina) AP4 Wifi (ssid rinaisense) AP5 Wifi (ssid ocarina) AP6 LaptopUE Raspberry Pi 3B VLAN 10 VLAN 20 VLAN 30 VLAN 40 VLAN 50 VLAN 60 10 20 30 40 50 60 Edge 1 Edge 2 Edge 3 Edge 4 100 110 200 210 Core 1 Core 2 ISP 1 ISP 2 Server 1 Server 2 120 220 300 310 320 VLAN-Aware Eth. Switch Mobile net 1 Mobile net 2 Laptop running Demonstrator (Blue boxes are QEMU/KVM VMs) 51
  49. 49. DMM demo: DIFs UE AP 1 Edge 1 Core ISP1 Server1 Mobile network DIF Internet DIF DAF (rina-tgen or rina-echo-time) Shim DIF Eth Shim DIF Eth Shim DIF Eth Shim DIF Eth Shim DIF Eth UE A1 A3 A2 E1 C1 E2 Mobile Network DIF I1 UE C1 S1 S2I2 Internet DIF C2 52
  50. 50. Storyboard: Handover UE starts moving towards Access2, at some point it allocates a flow to Access2 (UE is multihomed) UE continues moving further away from Access 1, flow to it is deallocated. When UE is closer to A3, it allocates a flow to it. All of this happens in the mobile network DIF without impacting higher DIF flows. UE A1 A3 A2 C1 GW C2 Mobile Network DIF UE A1 A3 C1 GW C2 Mobile Network DIF A2 UE A1 C1 GW C2 Mobile Network DIF A2 A3 53
  51. 51. Some results on cost of mobility “On supporting mobility and multi-homing in Recursive Internet Architectures” • V. Ishakian, J. Akinwuni, F. Esposito, I. Matta • Computer Communications, 2012, Vol. 35, Issue 13 • http://www.cs.bu.edu/fac/matta/Papers/RINA-ComCom2012.pdf • “In this paper, we present a specification of the process of ROuting in Recursive Architectures (RORA). We also perform an average-case cost analysis to compare the multihoming / mobility support of RINA, against that of other approaches such as LISP and Mobile-IP. Extensive experimental results confirm the premise that the RINA architecture and its RORA routing approach are inherently better suited for supporting mobility and multihoming.” 54
  52. 52. Results on topological addressing in large- scale DCs “Benefits of topological routing policies in RINA-enabled large-scale DataCentres” • S. Leon, J. Perello, D. Careglio, E. Grasa, D. Lopez, P. Aranda • IEEE Globecom 2016 • https://www.researchgate.net/publication/309782103_Benefits_of_Pr ogrammable_Topological_Routing_Policies_in_RINA-Enabled_Large- Scale_Datacenters • “… we propose rule-based topological routing and forwarding policies tailored to the characteristics of publicly available Google’s and Facebook’s DCNs… Numerical results show that the scalability of our proposal depends on the number of concurrent failures in the DCN rather than its size (e.g., number of nodes/links), dramatically reducing the total amount of routing and forwarding information to be stored at nodes. “ 55
  53. 53. SECURITY 56
  54. 54. Security: DIFs are securable containers Secure layers instead of protocols, expose less to apps, scope Allocating a flow to destination application Access control Sending/receiving SDUs through N-1 DIF Confidentiality, integrity N DIF N-1 DIF IPC Process IPC Process IPC Process IPC Process Joining a DIF authentication, access control Sending/receiving SDUs through N-1 DIF Confidentiality, integrity Allocating a flow to destination application Access control IPC Process Appl. Process DIF Operation Logging/Auditing DIF Operation Logging/Auditing RINA IP protocol suite Consistent security model, enforced by each layer via pluggable policies Each protocol has its own security model/functions (IPsec, TLS, BGPsec, DNSsec, etc.) Scope as a native construct: controlled connectivity by default Single scope (global), connectivity to everyone by default. Scope via ad-hoc means: firewalls, ACLs, VLANs, VPNs, etc. Complete naming and addressing, separation of synchronization from port allocation 5757 57
  55. 55. Results on security (I) “Assessing the security of a clean-slate Internet architecture” • G. Bodappati, I. Matta, J. Day, L. Chitkushev • IEEE International Conference on Network Protocols • http://www.cs.bu.edu/techreports/pdf/2009-021-clean-slate-internet- security.pdf • “In this paper, we show how, without the aid of cryptographic techniques, the bare-bones architecture of RINA can resist most of the security attacks faced by TCP/IP. We also show how hard it is for an intruder to compromise RINA. Then, we show how RINA inherently supports security policies in a more manageable, on-demand basis” 58
  56. 56. Results on security (II) “Patterns in network security: an analysis of the architectural complexity in securing RINA networks ” • J. Small • Master thesis • http://rina.tssg.org/docs/js-002.7-patterns_in_network_security.pdf • “Based on the evidence presented, RINA seems to be able to deliver on security requirements with substantially less complexity in terms of number of protocols, required number of flows, and especially the required number of distinct mechanisms, compared to the Internet protocol suite” 59
  57. 57. Results on security (III) “From protecting protocols to protecting layers: designing, implementing and experimenting with security policies in RINA ” • E. Grasa, O. Rysavy, O. Lichtner, H. Asgari, J. Day, L. Chitkushev. • IEEE ICC 2016 • https://www.researchgate.net/publication/304625404_From_protecti ng_protocols_to_layers_Designing_implementing_and_experimenting _with_security_policies_in_RINA • “In this paper we explore the security properties of the Recursive InterNetwork Architecture, analyzing the principles that make RINA networks inherently more secure than TCP/IP-based ones. We perform the specification, implementation and experimental evaluation of the first authentication and SDU protection policies for RINA networks. RINA's approach to securing layers instead of protocols increases the security of networks, while reducing the complexity and cost of providing security ”60
  58. 58. NETWORK MANAGEMENT 61
  59. 59. Network management Commonality is the key to effective network management From managing a set of layers, each with its own protocols, concepts and definitions … … to managing a common, repeating structure of two protocols and different policies Commonality and consistency in RINA greatly simplifies management models, opening the door to increased automation in multi-layer networks • Reduce opex, network downtime, speed-up network service delivery, reduce components that need to be standardised 62
  60. 60. Some results on network management “Simplifying multi-layer network management with RINA” • S. van der Meer, B. Gaston, E. Grasa, M. Crotty, M. A. Puente • TEERNA Networking Conference • https://tnc16.geant.org/core/presentation/667 • “This paper performs a comparative analysis in the complexity of managing an IP-based and a RINA-based large-scale multi-tenant data centre networks. Configuration management is the main target of the analysis although some hints on performance and security management are also provided. The analysis shows that the commonality built into the RINA architecture and the single type of recursive layer with a uniform API greatly reduces the complexity of the models the Network Management System (NMS) uses to understand the state of the managed network.” 63
  61. 61. DEPLOYMENT / INTEROP 64
  62. 62. Deployment New technology but incremental deployment RINA can be deployed incrementally where it has the right incentives, and interoperate with current technologies (IP, Ethernet, MPLS, etc.) • Over IP (just like any overlay such as VXLAN, NVGRE, GTP-U, etc.) • Below IP (just like any underlay such as MPLS or MAC-in-MAC) • Next to IP (gateways/protocol translation such as IPv6) IP Network RINA Provider RINA Network Sockets ApplicationsRINA supported Applications IP or Ethernet or MPLS, etc 65
  63. 63. IP over RINA demo IP over RINA over Ethernet Potential use cases • IP VPNs • SD-WAN (distributed enterprise, DC interconnect) • Metro and/or core network capable of multiple QoS and support for multiple tranports • DC fabric 66 DIF Shim DIF Eth Shim DIF Eth IP layer . . .
  64. 64. Research, open source, specs Current research projects • FP7 PRISTINE (2014-2016) http://ict-pristine-eu • H2020 ARCFIRE (2016-2017) http://ict-arcfire.eu • Norwegian project OCARINA(2016-2021) • BU RINA team http://csr.bu.edu/rina Open source implementations • IRATI (Linux OS, C/C++, kernel components, policy framework, RINA over X http://github.com/irati/stack • RINASim (RINA simulator, OMNeT++) https://rinasim.omnetpp.org/ • ProtoRINA (Java, RINA over UDP) https://github.com/ProtoRINA/users/wiki • rlite (Linux OS, C/C++, kernel components, minimize footprint) https://github.com/vmaffione/rlite RINA specifications • Pouzin Society (experimental specs) http://pouzinsociety.org • ISO SC6 WG7 (active in two projects: Future Network – Architectures, Future Network Protocols) 1 2 3 4 1 2 3 1 2 67 4
  65. 65. THANKS FOR YOUR ATTENTION!

×