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 motivation, introduction and IRATI goals. IEEE ANTS 2012

1,559 views

Published on

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

RINA motivation, introduction and IRATI goals. IEEE ANTS 2012

  1. 1. Research topics on theRecursive InterNetworkArchitectureDimitri Staessensdimitri.staessens@intec.ugent.beSander Vrijderssander.vrijders@intec.ugent.bewww.ibcn.intec.ugent.beInternet Based CommunicationNetworks and Services (IBCN)Department of InformationTechnology (INTEC)Ghent University - iMinds24/04/2013 1The EU Project IRATIIEEE ANTS 2012, Dec. 16-19, Bangalore
  2. 2. Patterns in Network Architectures All credits for this talkgo to John Day224/04/2013
  3. 3. Presentation index Background, concepts and problems Back to basics: What is networking? Introducing RINA Research: the IRATI project (2013-2015)24/04/2013 3
  4. 4. The current architecture ARPANET / CYCLADES First effort Architectural flaws (as we will see later)24/04/2013 4
  5. 5. What is a Network Layer?24/04/2013 5PHYSICALDATALINKNETWORKTRANSPORTSESSIONPRESENTATIONAPPLICATION“A layer is a collection of subsystems of the same rank”“Subsystems are the intersection of a system and a layer”OSI reference model ISO 7498-1
  6. 6. A layer disappeared24/04/2013 6Internetwork layerNetwork layerDatalink layerTransport layerNetwork layerPhysical layerDatalink layer INWG 96 (1972-76)(Int‟l Packet Network WG)
  7. 7. The current architecture Modularity Function per layer Not an internetwork724/04/2013
  8. 8. One problem with the current TCP/IPsplit Retransmission: TCP Fragmentation: IP If a packet gets fragmented in a router Chances are a fragment gets lost towards the next hop IP needs to reassemble the fragments in the next hop andwaits for 1 MPL (5 seconds) BUT TCP times out in the order of RTT-> retransmit IP fragments the packet, chances are a fragment gets lost Now the next hop has 2 incomplete IP packets!  TCP and IP should be aware of each other24/04/2013 8
  9. 9. Multihoming and mobility Failure Load balancing Complexity924/04/2013
  10. 10. Why is multihoming complex?24/04/2013 10
  11. 11. Protocol Mechanism  Policy Mechanism: static, does not change attaching CRC / checking CRC with PCI ACK Policy: occurs in pairs (sending / receiving) When to attach CRC / polynomial function Sending policy attaches the CRC in header Receiving policy computes CRC on packet When to send ACK, how long to wait for ACK Tightly coupled  Loosely coupled Tight No feedback mechanisms Typically associated with (SDU) data transfer Policy set by sender Loose Feedback mechanisms No data transfer Policy set by receiver24/04/2013 11
  12. 12. Relations between (protocol) statemachines Association No shared state ~UDP Flow Some shared state, but no Feedback Request – response (2-way handshake) Connection Shared state, feedback (3-way handshake) ~TCP Binding Very tightly coupled shared state ~shared memory24/04/2013 12
  13. 13. Data Transfer Mechanisms Delimiting: indicate start/end of PDU External: flag sequence (e.g. Ethernet) Internal: “length” field (e.g. IP) Initial state synchronization Association: Local binding of client/server protocolmachine Flow:+ request/response (two-way handshake) Connection: +3-way handshake Timer based (delta-t, Watson 1981) MPL, Retransmission, ACK time24/04/2013 13
  14. 14. Delta-t (Richard Watson, 1980) Developed at L.Livermore labs, unique approach. Assumes all connections exist all the time. keep caches of state on ones with recent activity Watson proves that the conditions for distributedsynchronization are met if and only if 3 timers arebounded: Maximum Packet Lifetime (Infinite -> Remote storage) Maximum number of Retries Maximum time before Ack That no explicit state synchronization, i.e. hard state, isnecessary. SYNs, FINs are unnecessary IOW, all properly designed data transfer protocols are soft-state. 1981:Watson shows that TCP has all three timers andmore.24/04/2013 14
  15. 15. Data Transfer Mechanisms (2) Policy selection Addressing Identify source / destination of the PDUs Flow or Connection ID (if multiple associations between two hosts) Relaying and Multiplexing Next hop Different flows on same interface Ordering24/04/2013 15
  16. 16. Data Transfer Mechanisms (3) Fragmentation/Reassembly Large SDU in smaller PDU‟s Combining/Separation Small SDUs into larger PDU‟s Data Corruption (CRC/FEC) Lost/Duplicate detection Flow control (i.e. don‟t swamp receiver) Retransmission Control (Acks) Compression Authentication24/04/2013 16
  17. 17. Data Transfer Mechanisms (4) Access-control Prevent unauthorized use of a resource Integrity (encryption) Prevent unauthorized insertion/deletion of PDU‟s Confidentiality (encryption) Nonrepudiation (no denial of having participated) Activity (Keepalive)24/04/2013 17
  18. 18. Phases of Operation Enrollment Creates, maintains distributes and deletes theinformation required to create instances ofcommunication IP: Manual configuration or DHCP Establishment of synchronization Creates, maintains distributes and deletes theinformation required to support the functions of datatransfer Data Transfer Phase Actual transfer of data.24/04/2013 18
  19. 19. Naming and Addressing (Shoch 1978,Saltzer 1982, RFC1493) Names – what? – Location Independent Adresses – where? – Location Dependent Routes – how to get there? - Route Dependent Saltzer: Four things need to be named Services and users (Applications) Location independent naming Nodes Points of Attachment Routes (set of nodes)24/04/2013 19
  20. 20. Naming and Addressing (2) Bindings between these names A service may run at one or more than one nodes andmay need to move between nodes without losing itsidentity (application roaming) A given node may be connected to one or morenetwork attachment points (multihoming) and mayneed to move from one attachment point to anotherwithout losing its identity as a node (mobility) A given pair of attachment points may be connectedby one or more paths, and those paths may need tochange with time without affecting the identity of theattachment points. (resiliency)24/04/2013 20
  21. 21. Saltzer‟s Network View Application names map to Node Addresses Node Addresses map to PoA addresses Routes are sequences of PoA Addresses24/04/2013 21
  22. 22. But Saltzer missed a case There can be more than one path to the next hop Must route on the Node addresses, not the point ofattachments  COMPLETE ADDRESSING SCHEME24/04/2013 22RouteDirectoryPath
  23. 23. Apply this to the `net24/04/2013 23 Most of the addressing architecture is missing! No Node, Application names DNs are Synonyms for IP addresses The PoA is named twice! URL‟s are pathnames and location dependent
  24. 24. Presentation index Background and concepts Back to basics: What is networking? Introducing RINA Research24/04/2013 25
  25. 25. What is networking? Single system: Interprocess communication(IPC)24/04/2013 26IPC FacilityApplication ProcessApplication Protocol MachinesPort IDs
  26. 26. Steps24/04/2013 271. The APM from A invokes an Allocaterequest specifying B: allocate(B, my-port, properties)2. IPC Facility assigns a port ID, ifrequest is well formed and it hasenough resources to handle the request3. IPC uses „search rules‟ to find B. IPCwill check if A is allowed to haveaccess to B. (B may be instantiated)4. B is notified of request and assignedport-id b5. If B responds positively , IPC notifies A.6. A may send PDUs to B by callingsend(a,buf), B receives by usingreceive(b, rcv_buffer)7. Afterwards they de-allocate theirresources.IPC FacilityAPAPMsPort IDs
  27. 27. Communication between two systems24/04/2013 28Driver DriverApplication ProcessApplication Protocol MachinesIPC FacilityBIGGER NAMESPACE!application name has to be unambiguous on both systems
  28. 28. Communication between two systems24/04/2013 29Driver DriverIAP IAPApplication ProcessApplication Protocol MachinesPort IDs
  29. 29. IPC Access Protocol (IAP) Simple Request/Response Protocol IAP-Req(Dest-Appl-name, Src-Appl-name, QoSparams, Src-Capability) IAP-Resp(Dest-Appl-name, Src-Appl-name, QoSparams, result) How do we know when to use it? If the application isn‟t here, it must be there! But we have a problem. How do we get it there? We need a protocol for sending the data We need Error and Flow control24/04/2013 30
  30. 30. EFCP Bad things can happen to messages in transit. Protection against lost or corrupted messages Receiver must be able to tell sender, it is goingtoo fast. Flow Control We have lost our means of synchronization: No common test and set means shared memory canno longer be used Must create shared state between two systems. Anexplicit synchronization mechanism is required. We need an Error and Flow Control protocol24/04/2013 31
  31. 31. Communication between two systems24/04/2013 32Driver DriverIPCMgtIAPEFCPIPCMgtIAPEFCPApplication ProcessApplication Protocol MachinesPort IDsEFCP EFCPEFCP EFCP
  32. 32. Three new concepts An Application Name Space that spans both systems. (not reallynew) Should be location-independent in general so that applications can move. A Protocol to carry Application Names and access control info Applications need to know with whom they are talking IPC must know what Application is being requested to be able to find it. For now, if the requested Application isn‟t local, it must in the othersystem. A Protocol that provides the IPC Mechanism and does Errorand Flow Control. To maintain shared state about the communication, i.e. synchronization To detect errors and ensure order To provide flow control Resource allocation can be handled for now by either end refusingservice.24/04/2013 33
  33. 33. Multiple Instances of IPC New Concept: a multiplexing application tomanage the single resource, the physical media. need to be fast, its functionality should be minimized,i.e. just the scheduling of messages to send. To provide QoS, we use the EFCP andscheduling by the Mux. To do resource allocation, we will just let theother side refuse if it can‟t satisfy the request. Application naming gets a bit more complicatedthan just multiple application-names. Must allow multiple instances of the same process24/04/2013 34
  34. 34. Communication with N systems24/04/2013 35
  35. 35. Communication with N systems24/04/2013 36IPCMgtIAPDirRIEPMuxMuxMuxDriver DriverDriverEFCP
  36. 36. Communication with N systems Relaying function is necessary24/04/2013 37
  37. 37. Resulting structure:recurring functions of different scope24/04/2013 38MuxEFCPEFCP EFCPEFCP EFCP EFCPMuxEFCPEFCPUser applicationsRelaying app
  38. 38. Presentation index Shortcomings of the current architecture. Back to basics: What is networking? Introducing RINA Research24/04/2013 39
  39. 39. EFCP: Error and Flow Control Protocol DTP Fragmentation Reassembly Sequencing Concatenation Separation DTCP Transmission control Retransmission control Flow control Loosely coupled by a state vector Based on Delta-t24/04/2013 40
  40. 40. What‟s inside an IPC process24/04/2013 41
  41. 41. Number of layers At least two layers required for networking Upper bound? Internetworking, VPN, P2P, virtualization… Security Smaller Scopes Private networks become the norm24/04/2013 42
  42. 42. Presentation index Shortcomings of the current architecture. Back to basics: What is networking? Introducing RINA Research: the IRATI project (2013-2015)24/04/2013 44
  43. 43. Future Research Since 2008 Draft RINA model and core spec. by Pouzin society Software implementation (DIF over IP) IRATI 2013-2015 will Research and implement RINA prototypes for thekernel of a UNIX-like Operating System and JunOS,through the usage of the JunOS SDK. Develop policies adequate to comply with the IRATIuse cases, focused around the dynamic creation ofDIFs in order to support cloud services acrossmultiple datacentres.24/04/2013 45
  44. 44. DIF over Ethernet Currently DIFs over IP wrap the IP layer with the IPC Process Interface map the names of IPC Processes of the layer above to IPaddresses in the IP layer and create TCP and/or UDP flows based on the QoS requested bythe upper layer application proces24/04/2013 46
  45. 45. Resources John Day “Patterns in Network Architecture” http://www.pouzinsociety.org/ http://www.irati.eu RINA workshop 21-24 Jan 2012, BCN, ES24/04/2013 47
  46. 46. Questions ?Sander Vrijderssander.vrijders@intec.ugent.beDimitri Staessensdimitri.staessens@intec.ugent.bewww.ibcn.intec.ugent.beInternet Based CommunicationNetworks and Services (IBCN)Department of InformationTechnology (INTEC)Ghent University - iMinds24/04/2013 48

×