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.

RINA: Update on research and prototyping activities. Global Future Internet Week 2012

1,434 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

RINA: Update on research and prototyping activities. Global Future Internet Week 2012

  1. 1. RINA: Update on Research andPrototyping ActivitiesGlobal Future Internet SummitSeptember 14th, 2012Eduard GrasaResearch Manager @ DANAFundació i2CAT
  2. 2. Before we start… our perspective What is the “Future Internet”? We don’t know, we’re just interested in building better computer networksand finding out the correct ways of doing so. Is RINA “clean slate”? We’re retaking the direction of computer network research in the mid-70s,continuing where INWG left off, and learning from the success and mistakesof 40+ years of computer networking. If we were starting with “noassumptions” we would not be learning from the past (“Those who don’t knowhistory are destined to repeat it”) What are the design goals of RINA? No design goals, we just look at solving the problem of computer networkingand try to maximize the invariances and minimize the discontinuities. All theresults and insights have emerged from listening to the problem. Do you have all the answers? No way! We’re just beginning to explore the properties of a new paradigm*that simplifies computer networking by orders of magnitude. Do you want tojoin us?2* Not so new to be honest, initial computer network research (CYCLADES, INWG) was headed in this
  3. 3. Outline Quick Introduction to RINA Java prototype over IP Inter DIF Directory RINA Security Assessment FP7 IRATI Project: Kernel prototype overEthernet3
  4. 4. RINA Architecture4• A structure of recursive layersthat provide IPC (InterProcess Communication)services to applications ontop• There’s a single type of layerthat repeats as many timesas required by the networkdesigner• Separation of mechanismfrom policy• All layers have the same functions, with different scope and range.– Not all instances of layers may need all functions, but don’t need more.• A Layer is a Distributed Application that performs and manages IPC.– A Distributed IPC Facility (DIF)• This yields a theory and an architecture that scales indefinitely,– i.e. any bounds imposed are not a property of the architecture itself.© John Day, All Rights Reserved, 2011
  5. 5. Naming and addressing in RINA All application processes(including IPC processes) have aname that uniquely identifiesthem within the applicationprocess namespace. In order to facilitate its operationwithin a DIF, each IPC processwithin a DIF gets a synonym thatmay have be structured tofacilitate its use within the DIF(i.e. an address).5 The scope of an address is the DIF, addresses are not visible outside of the DIF. The Flow Allocator function of the DIF finds the DIF IPC Process through which adestination Application process can be accessed. Because the architecture is recursive, applications, nodes and PoAs are relative For a given DIF of rank N, the IPC Process is a node, the process at the layer N+1is an application and the process at the layer N-1 is a Point of Attachment.1 2 3 41 2 1 2 3 1 21 21 2DIF ADIF BDIF CDIF DDIF E DIF F
  6. 6. RINA vs. the current Internet Architecture: Current: 5/7? layers, layers “2.5”, layer violations, “overlays”, “virtual networks”,“middleboxes” (NATs, firewalls, application-layer gateways) Getting complex!Unforeseen interactions RINA: Repeating structure, DIF (one type of layer, repeat as needed) Naming, addressing and routing: Current: No independent application names, no node names, just PoA names,routing on PoAs (no wonder why multi-homing and mobility is hard to support) RINA: Complete naming & addressing, routing on the node; support for multi-homing and mobility without special protocols. No need for global addressspace. Congestion control: Current: Put in TCP, the worst place it could be, since it maximizes the delay andvariance of the control loop (makes the system chaotic: self-similar traffic) RINA: Each layer can perform congestion control, confining the effects ofcongestion to that layer. The delay and variance of control loops can bebound. 6
  7. 7. RINA vs. the current Internet Scalability: Current: Limited due to the fixed number of layers in the architecture RINA: Recursion provides a divide and conquer approach, the way to scalability Security: Current: No systematic approach to security, secure each protocol or add boxes inbetween to improve security (firewalls). RINA: Strong design tells you where security functions go in the architecture (seelater in the presentation). DIFs are securable containers. Quality of Service: Current: Best effort is the dogma, “network neutrality” RINA: Each DIF is free to provide the QoS classes it wants, using different policies forresource allocation, routing and data transfer Management: Current: Complex, reflecting the complexity in the architecture and the highnumber of protocols. RINA: The commonality in the structure simplifies management by orders ofmagnitude, 7
  8. 8. Outline Quick Introduction to RINA Java prototype over IP Inter DIF Directory RINA Security Assessment FP7 IRATI Project: Kernel prototype overEthernet8
  9. 9. RINA Adoption strategy Start as an overlay to IP, validate technology, work on initialconcepts, develop DIF machinery. Useful by itself: internetwork layer(s), decouple application from infrastructure,improved application API, support for multi-homing and mobility.9IPEthernetPhysical MediaApplicationsTodayTCP or UDPIPEthernetPhysical MediaApplicationsCurrent PrototypeTCP or UDPDIFDIF…EthernetPhysical MediaApplicationsDIFDIF…IPPhysical MediaApplicationsTCP or UDPDIFDIF…Physical MediaApplicationsDIFDIF…End goal
  10. 10. RINA over IP benefits: Internetworklayer(s) What if application A wants to communicate with Application C? It cannot do it, unless you start deploying middleboxes like NATs, application-layer gateways,… The architecture doesn’t accommodate internetworking!10Data Link Data Link Data Link Data Link Data LinkIPIP Layer A (Public Internet)IPIP Layer B (EnterpriseNetwork)TCPAppl. A Appl. BData Link Data Link Data Link Data Link Data LinkIPIP Layer A (Public Internet)IPIP Layer B (EnterpriseNetwork)Shim DIFAppl. A Appl. B Appl. CShim DIFDIFTCPAppl. C
  11. 11. RINA over IP benefits: Separateapplications from infrastructure There is no separate application namespace, but synonyms thatstand for an IP address and a TCP/UDP port number: A path to an application. This makes anything but client/server hard to achieve, e.g. mobility In RINA application names are independent of the layers below(DIFs) Application names can be structured in a way that makes sense forthe application The application name doesn’t contain the semantics of where theapplication is in the network (i.e. what is its point of attachment to thelayer below) 11 http://pouzinsociety.orgSynonym of aninterface of a hostPort (Endpoint of TCPconnection):80
  12. 12. RINA over IP benefits: Nextgeneration VPN DIFs are customizable VPNs that can span multiple IP layers. Each DIF has its own addressing scheme, security mechanisms (authentication,authorization), routing strategy, resource allocation strategy (support fordifferent levels of QoS), flow control strategy, data transfer/data transfercontrol, … Processes (and not systems) are members of the DIFs (different processes canaccess different DIFs in each system). Processes may not have access to thewhole range of DIFs available on their system DIFs open the door to VPNs optimized for certain applications12Data Link Data Link Data Link Data Link Data LinkIPIP Layer A (Public Internet)IPIP Layer B (EnterpriseNetwork)Shim DIFAppl. A Appl. B Appl. CShim DIFDIF
  13. 13. Architectural modelDIFSystem (Host)IPCProcessIPCProcessMgmtAgemtSystem(Router)IPCProcessIPCProcessIPCProcessMgmtAgemtSystem(Host)IPCProcessIPCProcessMgmtAgemtAppl.ProcessDIF DIFAppl.ProcessIPC APIData Transfer Data Transfer Control Layer ManagementSDU DelimitingData TransferRelaying andMultiplexingSDU ProtectionTransmissionControlRetransmissionControlFlow ControlRIBDaemonRIBRIB CDAPParser/GeneratorCACEP EnrollmentFlow AllocationResourceAllocationForwarding TableGeneratorAuthenticationStateVectorStateVectorStateVectorData TransferData TransferTransmissionControlTransmissionControlRetransmissionControlRetransmissionControlFlow ControlFlow Control13IPCResourceMgt.Inter DIFDirectorySDUProtectionMultiplexingIPC Mgt. TasksOther Mgt. TasksApplication SpecificTasksIncreasing timescale (functions performed less often) and complexity
  14. 14. The Shim DIF14Public Internet Private IPnetwork“Shim IPCProcess”“Shim IPCProcess”IPCProcess“Shim IPCProcess”IPCProcessIPCProcess“Shim IPCProcess”Shim DIFShim DIFDIFAppl.ProcessAppl.ProcessUDP flow UDP flowTCPflow(s)TCPflow(s) The “shim IPC Process” for IP layers is not a “real IPC Process”. It justpresents an IP layer as if it was a regular DIF. Wraps the IP layer with the DIF interface. Maps the names of the IPC Processes of the layer above to IP addresses in theIP layer. Creates TCP and/or UDP flows based on the QoS requested by an “allocaterequest”.
  15. 15. Implementation platform Implemented as part of the TINOS framework (a networkprotocol experimentation framework) https://github.com/PouzinSociety/tinos Implemented in Java, using the OSGi technology (OSGicontainer provided by Eclipse Virgo) OSGi is a component model that facilitates building modular Javaapplications Developed on Mac OS X and Linux Debian, but should be multi-platform (support all the platforms that Eclipse Virgo supports) Found some OS resource allocation issues with Mac OS X Not yet fully integrated with TINOS (once it is, it will be possible toinstantiate several “systems” within a single Java process, usingXMPP as the underlying “physical substrate”)15
  16. 16. Java Virtual MachineWhy using TINOS instead of raw Java?To facilitate experimentation: bigger scenarios without adding more hardwareIP (Jnode)Data Link Data Link Data LinkShim DIFData Link Data LinkIP (Jnode)Shim DIFDIFJava Virtual MachineIP (Jnode)Data Link Data Link Data LinkShim DIFData Link Data LinkIP (Jnode)Shim DIFDIFJava Virtual MachineData LinkIP (OS stack)Shim DIFJava VirtualMachineData LinkIP (JNode)Shim DIFPublicInternetDataLinkIP(OSstack)ShimDIFDIFXMPP networkLAN With TINOS multiple nodes can be created withinthe same Java JVM, with different networkconnectivity with each other and other JVMs(TINOS uses adapted IP stack from JNode andXMPP for this)
  17. 17. Current status & some conclusions Since all the layers have the same mechanisms with different policies,implementation becomes much simpler than today’s protocolsuite(therefore more effort can be devoted to making it more robust andefficient) Also no need to distinguish between ‘physical’ or ‘virtual’ networking protocols: it’s all IPC. Customization & innovation in networking becomes much easier Just focus on the area you’re interested in and change the relevant policies for yours (NOTE:Today “changing the policies” in the prototype means modifying the code, sincedeveloping a pluggable policy framework is out of the scope of the initial prototype) Interoperability with existing networking technologies is not an issue Just wrap the XX layer as a shim DIF, and there you go 17IPC APIData Transfer Data Transfer Control Layer ManagementSDU DelimitingData TransferRelaying andMultiplexingSDU ProtectionTransmissionControlRetransmissionControlFlow ControlRIBDaemonRIBRIB CDAPParser/GeneratorCACE EnrollmentFlow AllocationResourceAllocationForwarding TableGeneratorAuthenticationStateVectorStateVectorStateVectorData TransferData TransferTransmissionControlTransmissionControlRetransmissionControlRetransmissionControlFlow ControlFlow Control
  18. 18. Outline Quick Introduction to RINA Java prototype over IP Inter DIF Directory RINA Security Assessment FP7 IRATI Project: Kernel prototype overEthernet18
  19. 19. What’s a layer? Although the term “layer” has been extensively used innetworking, the concept itself has not been clearly defined. In its origin layers were adopted from its use in operating systems.But in operating systems, using layers is a choice, whereas usinglayers in networks is a necessity because of the distributedshared state of different scopes The necessary and sufficient condition for a layer is distributedshared state of different scope. Therefore we can describe a layer as the collection ofapplication processes that share state.PhysicalData LinkNetworkTransportApplicationHost or End SystemRouterLessScopeMoreScope19
  20. 20. Application discovery involves also layerdiscoveryhost H2router R2 router R3host H1Layer 1web serverapplicationBwebbrowserapplicationArouter R4router R1host H4Layer 3Layer 2Layer 4Layer 6Layer 5router R5host H3web serverapplicationC20
  21. 21. The InterDIF Directory (IDD) A distributed application, Distributed Application Facility (DAF) asit’s called in RINA, which is a collection of two or morecooperating application processes in one or more processingsystems, which exchange information using IPC and maintainshared state The IDD DAF maintains a distributed database that keepsmappings of application names to list of supporting layers The IDD is responsible for two main distinct functions:a) Discovery of the applicationb) Creation of the supporting DIF21
  22. 22. A) Discovery of the application (I) IDD-Request Destination IDD Name, Source IDD Name, Requested ApplicationProcess Name, Access Control Information, Quality of Service,Termination Condition Forwarding of the request between the peer IDDs until thedestination application is found or the pre-defined terminationcondition is methost H2router R2 router R3host H1web serverapplicationBwebbrowserapplicationArouter R4router R1host H4Layer 6router R5host H3...Layer 1Layer 3Layer 2Layer 4Layer 5IDD DAFweb serverapplicationC22
  23. 23. A) Discovery of the application (II) Confirmation that the requested application is executing inthe destination system and authorization check that therequesting application has the rights to access ithost H2router R2 router R3host H1web serverapplicationBwebbrowserapplicationArouter R4router R1host H4Layer 6router R5host H3...Layer 1Layer 3Layer 2Layer 4Layer 5IDD DAFweb serverapplicationC23
  24. 24. B) Creation of the supporting DIF A DIF supporting the communication between the two userapplications has to be found This either involves creating a new DIF from scratch orexpanding (joining) an existing one so that it spans from thesource to the destination systemhost H2router R2 router R3host H1web serverapplicationBwebbrowserapplicationArouter R4router R1host H4Layer 6router R5host H3...Layer 1Layer 3Layer 2Layer 4Layer 5IDD DAFweb serverapplicationC24
  25. 25. Current status Ph.D. thesis ongoing Defined the IDD Framework. Current research is focused inapplication discovery; looking at different policies to performthe IDD search, the replication of the directory information,and compare them in terms of: Time to discover the requested application Average number of messages generated on the IDD DAF per search Average number of hops needed to locate the destination application Time to distribute directory updates, and average number of messagesgenerated by directory update Java simulator of the IDD is being implemented. After resultshave been tested in the simulator, the IDD framework andsome selected policies will be ported to the prototypes25
  26. 26. Outline Quick Introduction to RINA Java prototype over IP Inter DIF Directory RINA Security Assessment FP7 IRATI Project: Kernel prototype overEthernet26
  27. 27.  Benefits of having an architecture instead of a protocol suite: thearchitecture tells you where security related functions are placed. Instead of thinking protocol security, think security of the architecture: nomore ‘each protocol has its own security’, ‘add another protocol forsecurity’ or ‘add another box that does security’Allocating a flow todestination applicationAccess controlSending/receiving PDUsthrough N-1 DIFConfidentiality, integrityPlacement of security related functions27N DIFN-1 DIFIPCProcessIPCProcessIPCProcessIPCProcess Joining a DIFauthentication,access controlSending/receiving PDUsthrough N-1 DIFConfidentiality, integrityAllocating a flow todestination applicationAccess controlIPCProcessAppl.ProcessAccess control(DIF members)Confidentiality, integrityAuthenticationAccess control(Flow allocations to apps)DIF OperationLoggingDIF OperationLogging
  28. 28. DIFs are securable containers Master thesis on RINA security assessment (results to bepublished) Possible attacks to a DIF Information required to perform these attacks Mitigation measures against these attacks Comparison to the current Internet Concludes that DIFs are securable containers if properstandard security tools are used (authentication, accesscontrol, confidentiality, integrity and strong auditing) Securable = A structure used to hold or transport something that can bemade to be not subject to threat Again, with a proper structure in place, achieving bettersecurity in networks is much simpler and cost-effective thanin the current situation28
  29. 29. Outline Quick Introduction to RINA Java prototype over IP Inter DIF Directory RINA Security Assessment FP7 IRATI Project: Kernel prototype overEthernet29
  30. 30.  What? Main goal To advance the state of the art of RINA towards an architecture reference model andspecifications that are closer to enable implementations deployable in productionscenarios. The design and implementation of a RINA prototype on top of Ethernet willenable the experimentation and evaluation of RINA in comparison to TCP/IP. Who? 4 partners How? Requested 870.000 € funding to the EC to perform 5 activities WP1: Project management WP2: Architecture, Use cases and Requirements WP3: Software Design and Implementation WP4: Deployment into OFELIA testbed, Experimentation and Validation WP5: Dissemination, Standardisation and ExploitationProject at a glanceNextworksInteroutei2CATIBBT
  31. 31. Thanks for your attention!You can contact me ateduard.grasa@i2cat.netMore information about RINA at http://rina.tssg.org,http://pouzinsociety.org, http://csr.bu.edu/rinaMore information about the prototype athttps://github.com/PouzinSociety/tinos/wiki/RINA-PrototypeMore information about IRATI athttp://irati.eu

×