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 detailed components overview and implementation discussion

2,000 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

RINA detailed components overview and implementation discussion

  1. 1. The Pouzin Society RINA Detailed Overview and Implementation Discussions RINA Workshop. Barcelona, January 22-24 2013 RINA Workshop
  2. 2. Overview The Pouzin Society• Distributed Applications – Naming, Flows, Application API – Common Application Connection Establishment and CDAP – SDU Protection• The DIF and the IPC Process – Block Diagram (Reference vs. Implementation Architecture) – RIB and RIB operations – Enrollment – Flow Allocation – Transport protocol: EFCP, DTP, DTCP – Relaying and Multiplexing: RMT – Routing and Forwarding – Resource Allocation• Shim DIF – Internet/IP/TCP/UDP use with RINA• IDD• Misc. topics: Network Mgt., Security, …• Demo storyboard • RINAband 2
  3. 3. The Pouzin SocietyDISTRIBUTED APPLICATIONSNaming, Flows and Application API 3
  4. 4. Distributed applications The Pouzin Society Application protocol Appl. Appl. Process Application connection Process A B 1 8 flow Local handle to a Local handle to a particular instance of aparticular instance of a Medium that enables applications to communicate communication communication• For A and B to communicate, they need: – A means to identify each other -> Application process naming – A medium that provides a communication service ->Flows – A way to indicate the communication medium that they want resources to be allocated for a particular communication to take place, with certain quality requirements ->Communication medium API – A shared domain of discourse ->Objects – Optionally verify who are they talking to (authenticate), negotiate what protocol is going to be used to carry the data they will exchange, and what concrete encoding is to be used ->Application connection – A method to carry their discourse (objects)->Application protocol 4
  5. 5. Distributed applications in the Internet The Pouzin Society Many: App name not HTTP, SMTP, FTP, Telnet, RTP, SNMP, App name not existing, use IP SSH, XMPP, … existing, use IP address or Application connection (not a generic address or Domain name mechanism, partially provided through Domain name different protocols) 1 8 TCP connection or UDP flowWell known port (the Well-known port, the handle is no longer local handle is no longer Medium that enables applications to communicate local)• For A and B to communicate, they need: – Application process naming: No names for applications, IP addresses and ports is all what we have (URLs are pathnames to the applications) – Flows: Only 2 types; TCP (some variants) or UDP, each of them with fixed characteristics – Communication medium API:Need to know to what PoA and port an application is attached to in order to allocate a flow, no means to express desired properties of the flow – Objects: Vary depending on the application protocol used – Application connection: Applications have to know in advance which application protocol is going to be used; authentication is done through separate protocols. – Application protocol: Many protocols and encodings, tailored to different purposes 5
  6. 6. Distributed applications in RINA The Pouzin Society CDAP Application Application Application connection (generic names names mechanism, different authentication policies) 8 8 Flows can have different QoS characteristics 0Local handle (portId) Local handle (portId) Medium that enables applications to communicate• For A and B to communicate, they need: – Application process naming: Complete application naming theory, no communication medium internal addresses are exposed to apps. – Flows: Flows can have a myriad of characteristics, tailored to different application requirements. – Communication medium API:Request allocation of flows to other applications by name; request desired properties for each flow – Objects: Each application decides on their contents and encoding – Application connection: Generic application connection establishment procedure, where different authentication policies can be plugged in – Application protocol: A single application protocol that can have multiple encodings: CDAP 6
  7. 7. RINA API The Pouzin Society• The RINA API needs to be different in many ways from conventional Internet operations (usually “sockets”) – Application flows connect named Applications, not addresses/ports – RINA takes responsibility for locating the destination of a flow request, whereas current practice is to use macro-for-the-address mapping (e.g., DNS) and then use the absolute address returned plus a “known port” • RINA Applications are “registered” in order to be found by their name – Applications can be reached at multiple points (AE’s, more later) – Applications can reject a request for a flow before it is created and then authenticate the requestor before establishing a connection – RINA allows a flexible specification of the requested quality/properties of a flow – RINA transport occurs in application-defined units (“Service Data Units” or SDUs) vs. a stream of unstructured bytes that force applications to do their own delimiting into meaningful units• Current API’s don’t provide access to the full set of RINA benefits – Though it is not strictly necessary to have a common cross-system API for RINA, it would still be a Good Thing to have, as sockets was for IP 7
  8. 8. Naming – Points to Remember The Pouzin Society• The Internet does not name applications – The Internet doesn’t really name nodes/applications – everything addressable is accessed using “absolute addresses” (IP addresses, ports) to reach it – DNS is a name-to-number mapping, but applications contact other applications using the absolute addresses returned • There is no virtual addressing (NAT is arguably a step toward it, but interacts in complex ways with DNS)• RINA is different – Applications are named • There can be multiple simultaneous executing instances of an application, so they must be distinguished. The “application instance” is an integral part of the application name. • An application may contain multiple “Application Entities” (next slide) – Applications do not know “addresses” of each other, only names 8
  9. 9. Application naming The Pouzin Society • The Application Process Model – Application Process Name: the name of the app Application – Application Process Instance: to differentiate specific instances of the same app – Application Entity Name: part of the application Application concerned with communication. Associated to a subset Entity Application Entity of all the existing application objects – Application Entity Instance: refers to a particular instantiation of an application entity (that is a particular instance of a communication associated to a concrete Gmail Server instantiation of an application protocol and a set of application instance 2 objects) DRDA AE Instance 1Browser Application Instance 1 Gmail Server Application TCP connection DRDA AE HTTP AE HTTP AE Instance 1 Private Network Instance 2 Instance 9 Instance 1 DRDA AE DB Server TCP connection DRDA AE Public Internet Instance 1 TCP connection application HTTP AE Instance 4 instance 1 TCP connection Instance 2 HTTP AE Instance 4 Gmail app Instance 1 9
  10. 10. Flows The Pouzin Society• Instantiation of a communication service between applications – A flow is locally identified by an app through the use of a port-id – Flows transport well defined units of application data (SDUs, Service Data Units)• A flow has some externally visible properties: – Bandwidth related • Average bandwidth • Average SDU bandwidth • Peak BW duration • Peak SDU BW duration – Undetected Bit Error Rate – Partial Delivery of SDUs allowed? – In order delivery of SDUs required? – Maximum allowable gap between SDUs? – Maximum delay – Maximum jitter 10
  11. 11. The IPC API The Pouzin Society• Presents the service provided by a DIF: a communication flow between applications, with certain quality attributes.• 6 operations: • portId_allocateFlow(destAppName, List<QoSParams>) • void _write(portId, sdu) • sdu_read(portId) • void _deallocate(portId) • void _registerApp(appName, List<difName>) • void _unregisterApp(appName, List<difName>)• QoSParams are defined in a technology-agnostic way • Bandwidth-related, delay, jitter, in-order-delivery, loss rates, …• Aid to adoption: faux sockets API. • Presents the sockets API to the applications, but internally maps the calls to the IPC API • Current applications can be deployed in RINA networks untouched, but won’t enjoy all RINA features 11
  12. 12. IPC API Implementationi2CAT/TSSG Prototype: General design The Pouzin Society• Design goal: Portability to multiple Operating Systems (take advantage of Java) Java Application Local TCP IPC Manager connections Socket Native IPC s API RINA Proces API s1 IPC RINA App Library Proces s2• The RINA Library is part of the application, and provides both a Sockets and a Native RINA API (can be part of the same library or create two packages).• The IPC Manager is the point of entry to the “RINA stack” running on the computer. It hosts the IPC processes, manages its lifecycle (creation, deletion) and acts as a broker between the RINA library and the IPC Processes.• Local TCP connections are the means of communication between Apps (running the RINA Library) and the IPC Manager.• Use of blocking I/O: one thread per each TCP connection 12
  13. 13. IPC API Implementation i2CAT/TSSG Prototype: behavior of a “client” RINA application The Pouzin Society RINA App IPC Manager LibraryFlow Allocation Open a new socket Send CDAP M_CREATE Message with an FlowService object Map App Name to DIF, find IPC Process that is member of the Send CDAP M_CREATE_R Message with the FlowService object DIF, invoke allocateFlowData transfer Send delimited SDU (byte[]) to deliver data Cause the IPC process to transfer Keep data in buffer Send delimited SDU[] to deliver data the data over the flow until read by the app, or notify appFlow Deallocation Close socket (on Close socket Cause the IPC Process to response message unallocate the flow or timer) Close socket Received delete flow request 13
  14. 14. IPC API Implementation i2CAT/TSSG Prototype: behavior of a “server” RINA application (I) The Pouzin Society RINA App IPC Manager LibraryApp registration Start a new Server Socket at port X. Listen for incoming Open a new socket requests Update IDD table and related flow allocator directorie(s). RegisterApp Send CDAP M_START Message with a AppRegistration object contains Source App naming info, optional list of DIF names and socket number Send CDAP M_START_R Message (success or not, reason)Flow allocation Incoming Flow allocation(for each new incomingflow request) Open a new socket to port X request, if destination app is registered, open a new socketStart a new thread for Send CDAP M_CREATE Message with a FlowService objectthe flow. Decide ifaccept connection Send CDAP M_CREATE_R Message with the FlowService object Cause the IPC process to send the allocate response back 14
  15. 15. IPC API Implementation i2CAT/TSSG Prototype: behavior of a “server” RINA application (II) The Pouzin Society RINA App IPC Manager LibraryData transfer Delimited SDU to write data (byte[]) Keep data in buffer Cause the IPC process to transfer until read by the Delimited SDU to read data (byte[]) the data over the flow app, or notify appFlow Deallocation Incoming Flow deallocation socket closed request, Socket close Cause the IPC process to send the Close socket, stop deallocate response back threadApp unregistration Close socket Update IDD table and related IPC On timer or directly: Process directorie(s) close socket, close Close socket serversocket On timer, if not already closed, close socket 15
  16. 16. The Pouzin SocietyDISTRIBUTED APPLICATIONSCommon Application Establishment Phase and CDAP 16
  17. 17. CACEP Common Application Connection Establishment Phase The Pouzin Society  Once application processes have a communication flow between them, they have to set up an application connectionbefore being able to exchange any further information.  The application connection allows the two communicating apps to:  Exchange naming information with its apposite, optionally authenticating it  Agree on an application protocol and/or syntax version for the application data exchange phase1) 2) M_CONNECT 2 Appl. (srcName, destName, credentials, proto, syntax Appl. Appl. Optional messages exchanging authentication Appl. Process version) Process Process information Process A 1 B A B N 2 2 2 2 flow flow DIF DIF3) 4) M_CONNECT_R (result, reason, options) Appl. Appl. Appl. Application data transfer phase, processes Appl. N+1 Process Process Process exchange data using an application protocol Process A B A B 2 2 2 2 flow flow DIF DIF
  18. 18. CDAP The Pouzin Society• The Common Distributed Application Protocol (CDAP) is the application protocol used by IPC Processes to exchange shared state (IPC Processes are Application Processes)• It is also recommended for all RINA applications to use for exchanging shared state (when anything but an amorphous flow of bytes is needed), legacy aps can use whatever they want to use• The CDAP Specification defines the complete set of operations and messages, as well as their fields – Connection establishment (Connect, Disconnect, authentication) – Object operations: create, delete, read, write, start, stop• The set of objects and meaning of operations is not dictated by CDAP proper – that is an application concern – IPC Processes are applications, and manipulate a set of objects, but none of them are dictated by CDAP• Messages can be encoded in any agreed-upon way – As long as the applications agree, e.g., via CACEP exchange – We currently use GPB, have experimented with JSON 18
  19. 19. CDAP operates on objects The Pouzin Society• All objects CDAP operates on have the following attributes: – ObjectClass • Class (data type and representation) of an object – ObjectName • A identifier of an object, unique within the objects of the same class – ObjectInstance • An alias of objectClass + objectName, uniquely identifies an object – ObjectValue • The actual value of the object, encoded as desired by the application• All CDAP operations can be applied two modifiers: scope/filter; which enables CDAP operations to affect multiple objects that form a hierarchy with a single message: – Scope: An integer indicating how many levels below the selected object the operation has to be applied. – Filter: A predicate function that evaluates if the operation should be applied to each individual object within the scope. 19
  20. 20. CDAP, AEs and the OIB/RIB The Pouzin Society• All the objects an Application Process knows about are locally “stored” in the Object Information Base/Resource Information Base. – The RIB may be an actual database, or just a logical representation of all the information known by an application process.• In RINA there’s only a single application protocol: CDAP. Then why are there different AEs? – Each AE is able to operate on a subset of the RIB Application Process 2 Application Process 3 Application Process 1 AE type 1 CDAP AE type 1 AE type 2 CDAP AE type 2 Instance 1 Instance 1 Instance 1 Instance 1 OIB/RIB OIB/RIB OIB/RIB 20
  21. 21. CDAP Implementation The Pouzin Society• CDAP messages comprise a sequence of 1 or more fields – The one always-present field is the message type• Each field has an identifying name or numeric tag (depending on encoding), and a value• The field names or tag values (for GPB encoding), value types, and presence/absence of particular fields in CDAP messages of each type is defined in the CDAP Specification• One supported type for an object value is an embedded message, not understood by CDAP itself, but transported unchanged to the apposite – The message declarations for IPC Process object values are not part of CDAP, but part of the IPC Process Object Dictionary definition. Other applications define their own object types 21
  22. 22. CDAP Implementation (cont.) The Pouzin Society• For Google Protocol Buffers (GPB) syntax, a freely-available compiler can produce code in several languages to construct a valid CDAP message and to access the fields of one: https://developers.google.com/protocol-buffers/ – .proto files describe the field values and types – GPB is being used because of its simplicity, compact representation, support (Google uses it heavily), a freely- available high-quality tool, a simple definition language, and general acceptance by the developer community – XML, ASN.1, JSON, or other representations would also work as a concrete syntax to encode CDAP messages• i2CAT’s implementation uses Java code produced by the Google protoc GPB compiler• TRIA’s implementation uses a table-driven parser/generator that also accepts/generates JSON 22
  23. 23. Example Message Definition The Pouzin Societymessage qosCube_t{//a QoS cube specification required uint32 qosId= 1;//Identifies the QoS cubeoptional string name = 2;// A human-readable name for the QoS cube optional uint64 averageBandwidth= 3;//in bytes/s, a value of 0 indicates dont care optional uint64 averageSDUBandwidth= 4;//in bytes/s, a value of 0 indicates dont care optional uint32 peakBandwidthDuration= 5;//in ms, a value of 0 indicates dont care optional uint32 peakSDUBandwidthDuration= 6;//in ms, a value of 0 indicates dont care optional doubleundetectedBitErrorRate= 7;//a value of 0 indicates don`t care optional boolpartialDelivery= 8;//indicates if partial delivery of SDUs is allowed or not optional bool order = 9;//indicates if SDUs have to be delivered in order optional int32 maxAllowableGapSdu= 10;//indicates the maximum gap allowed in SDUs, a gap ofN SDUs is considered the same as all SDUs delivered. A value of -1 indicates Any optional uint32 delay = 11;//in milliseconds, indicates the maximum delay allowed in this flow. Avalue of 0 indicates dont care optional uint32 jitter = 12;//in milliseconds, indicates indicates the maximum jitter allowed in thisflow. A value of 0 indicates dont care} 23
  24. 24. The Pouzin SocietyDISTRIBUTED APPLICATIONSSDU Protection 24
  25. 25. SDU Protection The Pouzin Society• Applications may have different levels of trust in the communication mediums they use – Need for a way to protect the SDUs they send through the flows App A App B SDUs 1 2 flow Medium that enables applications to communicate • SDU Protection module protects outgoing SDUs App A and unprotects incoming SDUs Unprotected • Can perform the following functions SDUs (configurable through policies) • Encryption (Integrity and confidentiality) outbound SDUs inbound SDUs SDU Protection module • Compression Protected SDUs • Error detection (CRCs, FECs) 1 flow • Time To Live 25
  26. 26. The Pouzin SocietyIPC PROCESSBlock diagram, architecture reference vs. implementation 26
  27. 27. Levels of Abstraction(Abstraction is Invariance) The Pouzin Society Reference Model Invariant Service Definitions Decreasing Levels of Protocols Abstraction Procedure Variable s Policies Implementation
  28. 28. IPC Process The Pouzin Society• The IPC Process is an entity that provides IPC services for applications running on the same system – It is an application, and uses RINA application operations to do everything it does – It may or may not be an “OS Process” – There is no set model for how to implement it, and there can be very different implementations – based on OS, scale, and many other concerns – In some implementations, it will become part of the OS, just as IP networking is now – In some implementations, it will operate as “middleware”, atop the OS and its normal networking layer• All IPC Processes do similar things – WHAT they do is described in the Reference Architecture, but there are many feasible Implementation Architectures for HOW those functions get done. We’ll examine a few today 28
  29. 29. Block Diagram (Reference Arch.) The Pouzin Society• You’ve seen the RINA Reference Architecture (RA) partitioning of the IPC Process – This describes the basic mechanisms and what they communicate among themselves to perform the total functionality ascribed to an IPC Process• Implementers use the RA as a guide to create an Implementation Architecture – Driven by their particular requirements, implementation target, and end-use • Language, use of OS features, flow of control approach, etc., can all be different – but they all need to implement the RA – Modules may be different, but ALL RA functions will be present in a complete implementation, and will communicate with the same functions as they do in the RA – There can also be multiple different implementations of the same Implementation Architecture (e.g., ports to different OS’s) 29
  30. 30. Block Diagram (Reference Arch.) The Pouzin SocietyApplication Specific Tasks System (Host) System System Appl. (Host) Mgmt Other Mgt. Tasks Appl. (Router) Process Agemt Process IPC Mgt. Tasks DIF IPC IPC IPC IPC Multipl Resource Process Process Process exing Mgmt Mgt. Agemt Mgmt SDU Agemt Inter DIF DIF DIF Protecti IPC IPC Directory IPC IPC on Process Process Process Process IPC API Data Transfer Data Transfer Control Layer Management SDU Delimiting Transmission Transmission Transmission CACEP Enrollment Control State Vector Control State Vector Control RIB State Vector Data Transfer Data Transfer Daemon Authentication Flow Allocation Data Transfer Retransmission Retransmission Retransmission Control Control Control Relaying and CDAP Resource Allocation Multiplexing Flow Control RIB Parser/Generator Flow Control Flow Control Forwarding Table SDU Protection Generator (Routing) Increasing timescale (functions performed less often) and complexity 30
  31. 31. The Pouzin SocietyTRIA IMPLEMENTATION 31
  32. 32. Overall Goals and Approach The Pouzin Society• Provide a framework to test and debug the new protocols – Use a single-threaded state machine model to simplify locking and increase repeatability – Operate entirely at user (application) level for easier debugging• Anticipate the desire to move some portions (which ones were as yet unknown) into the OS kernel eventually – Coded in C – Memory/buffering/time-management operations similar to those available inside the UNIX/Linux OS• Anticipate future porting to multiple targets – Use standard POSIX/UNIX capabilities common on all or most platforms, avoid extensions that impair portability – Test on MacOS (Mach-based UNIX) and Linux – Test on large and small systems (Intel and ARM-based) 32
  33. 33. Major Parts of the Implementation The Pouzin Society• Infrastructure – Main program, select (event) loop, state machine framework, file management, non-blocking I/O, delimiting, pseudo-files (internal IPC, Shim DIF), memory and message pools, timers, startup/shutdown, configuration parsing, logging and debug utilities, GPB and JSON utilities• CDAP – Table-driven CDAP msg. parse/build, connection state machine• RIB – Node allocation, lookup, RIB Daemon operations on nodes – Object Manager mechanism for operations on objects• IPC Process – Per-DIF management (RIB Daemon, enrollment, startup), FA, FAI, DTP/DTCP, Network Management client interface, Shim DIF, routing, IPC Process-specific Object Managers• RINA native API Library• Tests, including RINABAND 33
  34. 34. High-Level Block Diagram The Pouzin Society UNIX/Linux IDD Application NetMgr App. User Application Processes RINA API RINA API RINA API Authentication Database UNIX/Linux NetMgr Agent/ Per-DIF Manager Process Directory Server Flow Allocator Flow Al. Instances RIB Data Base EFCP Instances Routing RMT Computation (N-1)DIF Flows SHIM DIF RINA API Logger Device Driver file (N-1) FAI socket IPCMGR Process I/O Device RINA DIF 34
  35. 35. The Pouzin SocietyI2CAT/TSSG IMPLEMENTATION 35
  36. 36. Overall Goals and Approach The Pouzin Society• Provide an open source initial RINA implementation that can be used for education and quick prototyping – as well as to exercise and improve the RINA specs. – Easy to develop, OS-independent language: Java – Code structured to be modular and extendable: Use OSGi as a component framework (Eclipse Virgo Implementation) – Portable to different operating systems: only use Java OS-dependent features available in most OSs (sockets)• Enable to setup relatively complex scenarios with few hardware resources – Use the TINOS protocol experimentation framework –developed by TSSG- in order to be able to emulate multiple “hardware” within the same Java process.• i2CAT/TSSG’s RINA implementation is part of the TINOS project, as one of the “protocol stacks” available. – Reuse of TINOS compile/build infrastructure – Maximize synergies between both projects: single development community (hosted at github) – Integration with TINOS will be easier (not done yet) 36
  37. 37. Major Parts of the Implementation The Pouzin Society• Infrastructure – VIRGO OSGi core (handles the lifecycle of the different components – bundles in OSGi parlance), single thread pool, blocking I/O, configuration parsing (JSON library), sockets, Google Guava library (Java has no unsigned types, thanks!), Google Java GPB implementation, Java timers, delimiting, object encoding/decoding• IPC Manager – RINA-side of the IPC API, IPC Process Lifecycle Management, will host management agent and IDD (not implemented yet), console service (local administration)• “Normal IPC Process” – RIB, RIB Daemon, CDAP Parser/generator, Enrollment task, Flow Allocator, Resource Allocator, EFCP, RMT, SDU Protection• Shim IPC Process for IP Layers – Setup and management of TCP and UDP flows as per the shim DIF spec• RINA Application Library – Native RINA API and faux sockets API• Test applications – RINABand, Echo server & client, simple chat application 37
  38. 38. General design (I) The Pouzin Society Server Application 1 OS Process Client Application 1 (Java VM RINA Lib RINA Lib instantiation) For the registration, Local local TCP connection administration For each flow, local TCP to port 32771 Listen for local TCP connections at connection to port 32771 port X (dynamically assigned) Listen for local TCP For each flow to service application 1, local connections at port Listen for local TCP TCP connection to port X 32766 connections at port 32771 IPC Manager Application Console Service IPC Process Lifecycle Service Management (“IRM”) IDD OS Process (Java VM IPC Service IPC instantiation) Normal IPC Process Service Components NOTE: Could be multiple“systems” within the same Shim IPC Process Delimiter Encoder CDAP Session Manager for IP Java VM once fully integrated with TINOS GPB parser Resource Enrollment Task Allocator Flow RIB Daemon Allocator EFCP Flow Allocator RMT SDU Virgo OSGi Kernel Protection Flows to/from other Listen for TCP shim IPC Processes connections and UDP datagrams at IPa:portb 38
  39. 39. General design (II) The Pouzin Society 39
  40. 40. Why TINOS?Larger experimentation scenarios with less infrastructure The Pouzin Society DIF Shim DIF Shim DIF IP (Jnode) IP (Jnode) Data Link Data Link Data Link Data Link Data Link Java Virtual Machine Java Virtual Machine • With TINOS multiple nodes can be created within the same Java JVM, with different network connectivity with each other and other JVMs (TINOS uses adapted IP stack from JNode and XMPP for this) DIF Shim DIF Shim DIF Java Virtual IP (Jnode) IP (Jnode) Machine Data Link Data Link Data Link Data Link Data Link Java Virtual Machine 40
  41. 41. The Pouzin SocietyALTERNATIVE IMPLEMENTATIONSSome Implementation Architectures with Interesting Properties 41
  42. 42. RINA in the OS Kernel The Pouzin Society• Make RINA a “native” networking API – New/Extended OS system calls provide full RINA capability – Move (at least) DTP/DTCP into the OS kernel for speed App IPC App Process-Application Space OS Kernel New/Extended OS API Calls DTP/DTCP Flow State Forwarding RMT Table “Network Device” Might be a Shim DIF Network Device 1 Network Device 2 or a RINA DIF 42
  43. 43. RINA Split Between H/W and S/W The Pouzin Society• RINA RMT/DTP performed in hardware – Software still does DTCP and remainder of IPC Process fn’s – Transiting PDUs need not be processed by software App IPC App Process- Application Space OS Kernel New/Extended OS API Calls DTCP Flow State DTPHardware/Firmware Forwarding RMT Table Network Interface 1 Network Interface 2 43
  44. 44. The Pouzin SocietyIPC PROCESS (CONTINUED)RIB and RIB operations 44
  45. 45. RIB and RIB Operations The Pouzin Society• The Resource Information Base (RIB) is a virtual object database – Each AE projects a view over the underlying objects – The RIB holds the shared state of the communication instances between applications• The IPC Processes communicate by exchanging operations on RIB objects – The only operations are: create, delete, read, write, start, and stop – These operations cause objects to perform appropriate actions (defined in an object dictionary) – There is a particular tree of RIB objects defined for IPC Process use (any other application can define its own tree) 45
  46. 46. A Few Thoughts on the RIB Daemon The Pouzin Society• A generalization of Event Management and Routing Update – Elsewhere (circa 1988) I said Event Management is the hypothalamus of network management and looks like this: To Other Management Applications Add/Delete Subscription Filter control Subscription Service Subscript Def File Logging Rcv Events
  47. 47. A Few Thoughts on the RIB Daemon The Pouzin Society• Generalizing routing update adds a capability for managing periodic and/or event driven a data distribution and replication strategy. To Other Management Applications Add/Delete Subscription Filter control Subscription Service Subscript Def File Replication Optimizer Logging Rcv Does this imply Events an opportunity Write for a journaling Subscriptions RIB for some data?
  48. 48. A Few Thoughts on the RIB Daemon The Pouzin Society• So re-arranging and re-labeling for our current problem. Add/Delete To Requesting Tasks Subscriptions From Tasks EventReads and Writes to an Subscriptions Subscript Subscriptionactual store or to other Def Servicetasks or task data File Writestructures, e.g. DT-state Subscriptionsvector. Logging CDAP An opportunity Processing Replication for a journaling Optimizer RIB for some data? Incoming CDAP PDUSs
  49. 49. RIB Implementation The Pouzin Society• Our protocol exchanges refer to objects by name and/or object-id (a number) – We haven’t started using object-id’s yet, but the intent was to make the protocol exchanges more compact – We will standardize the object names/id’s that need to be the same for consistent RINA implementations through PSOC• The RIB appears as a tree-structured database with objects at its leaf nodes. Leaves are named with the full absolute pathname from the root to the leaf.• We operate on an object by sending the operation and the operand object’s name/id (and a value, if appropriate) – The reference model has a “RIB Daemon” that performs the operation; in practice, this may be subsumed into other entities 49
  50. 50. Naming conventions for IPC Processes The Pouzin Society• Application names: – Can be whatever, probably would be useful to give some kind of indication of its physical location (to facilitate management, for no other purposes).• Application instances: – Not used in principle, since in normal operation there should be no need to connect to a concrete instance of an application process (default to 1).• Two Application Entities: – Management AE: Flows established to/from here are used to establish application connections to neighboring IPC Processes and exchange layer management information using CDAP. – Data Transfer AE: Flows established to/from here are used by the RMT to transport “data transfer SDUs”. 50
  51. 51. Current tree of objects The Pouzin Society /daf/management/operationalstatus /daf/management/naming /daf/management/naming/applicationprocessname /daf/management /daf/management/naming/address /daf/management/naming/whatevercastnames /daf /daf/management/neighbors/ /dif/ipc/datatransfer /dif/ipc/datatransfer/constants /dif/ipc /dif /dif/management/flowallocator /dif/management/flowallocator/qoscubes /dif/management /dif/management/flowallocator/directoryforwardingtableentries /dif/resourceallocation /dif/resourceallocation/flowallocator /dif/resourceallocation/flowallocator/flow s /dif/resourceallocation/nminus1flowmanager /dif/resourceallocation/nminus1flowmanager/nminus1flows /dif/resourceallocation/pduforwardingtable 51
  52. 52. The Pouzin SocietyIPC PROCESSEnrollment 52
  53. 53. Enrollment The Pouzin Society• Enrollment is the process by which an IPC Process communicates with another IPC Process to join a DIF – And acquires enough information to start operating as a member of the DIF – After enrollment, the newly-enrolled IPC Process is able to create and accept flows between it and other IPC Processes in the DIF• Enrollment on the Internet – For TCP/IP mostly inexistent or by ad-hoc/manual means (DHCP provides a bit of the required functionality) – In IEEE 802.11 the procedure for joining a network is almost identical to what RINA predicts. The BSSID is a DIF-name. – Similarly, there is enrollment in 802.1q (VLANs). – Done independently, confirmation of the theory. 53
  54. 54. Start at the BeginningJoining a DIF The Pouzin Society IPC Process A wants to join IPC Process B is a member of a DIF beta DIF of which B is a member. DIF Management DIF Management Establish conn authenticate Initialization information (N-1)-DIF• A Wants to join DIF beta of which B is a member. First it needs to establish communication with beta. So A’s DIF Management task using DIF A’s IPC Manager (not shown) does an allocate(beta, as good QoS as it can get).The name beta is a whatevercast name for the set containing the addresses of all members of beta that the rule returns the address of an IPC Process with a common (N-1)-DIF. The whatevernme is resolved by the (N-1)-DIF.• The Allocate creates a flow between A and B. They exchange CDAP connect requests, followed by whatever authentication is required to establish an application connection between A and B. Actually between A and beta. B is acting as an agent or representative for beta.• Then A and B exchange initialization information. Primarily B is telling A what its DIF internal name (address) is and populating A’s RIB with the current information on the DIF. We will come back to this. 54
  55. 55. A is now a member of beta The Pouzin Society IPC Management RIB Daemon IPC Management RIB Daemon A B Application Connection (N-1)-DIF• There is now an application connection between the IPC management components of A and B. – All connections between members of a DAF are managed by their IPC management component. – Any management component can send on the flows managed by IPC. – All incoming PDUs are delivered to the RIB Daemon. – The RIB Daemon is a subscription service, essentially a generalization of both routing update and event management. When any CDAP PDU arrives, it is logged and distributed to the tasks that have subscribed to be notified. – The Flow Allocator subscribes to Create/Delete Flow Req. (The Flow Allocator will update the RIB after processing the request.) 55
  56. 56. Enrollment Exchange The Pouzin Society• There are several enrollment situations that IPC Processes encounter when connecting, for example: – An IPC Process that is not enrolled connects to an IPC Process that is not enrolled in a DIF – the two form a DIF – An IPC Process that is not enrolled connects to an IPC Process that is already enrolled in a DIF – it joins the DIF – An IPC Process that is enrolled makes a connection to a neighbor that is enrolled – they now have a new route for flows• An IPC Process can be in either role, as initiator or target• The information exchanged in some cases can be reduced to minimize enrollment time 56
  57. 57. Enrollment Procedure I The Pouzin Society• When the New Member receives the M_Connect Response, the New Member copies Current_Address to Saved_Address, it sends – M_StartEnrollment(address, Address_expiration_time, other data about New Member)• /* The New Member is telling the Existing Member what it knows. Primarily this is derived from the address (NULL or not), and the expiration life-time of the address if non-NULL. Since addresses are generally assigned for hours or minutes, tight time synchronization is not required. (Even for DIFs with fast turnover, fairly long assignment times are still prudent.)*/• The Member sends – M_Start_REnrollment(address (potentially different), Application Process Name, Current_Address, Address_Expiration).
  58. 58. Enrollment Procedure II The Pouzin Society• Using the information, provided by the New Member, the Existing Member sends – M_Create (zero or more) to initialize the Static and Near Static information required. When finished and the New Member has sent all necessary – M_Create_Rs• The Existing Member sends a – M_Stop Enrollment (Immediate:Boolean)• The New Member may Read any additional information not provided by the Existing Member. – M_Read (zero or more) – M_Stop_R Enrollment• If the Immediate Boolean is True, the New Member is free to transition to the Operational state.• If the Boolean Immediate is False, then the New Member can not transition to the Operational state until an M_Start Operation is received.
  59. 59. Enrollment Procedure III The Pouzin Society• The New Member is free to Read any information not provided by the Existing Member. Once these are completed, the Existing Member sends: – M_Start Operation• The New Member sends – M_Start_R Operation• Invoke RIB Update of dynamic information which will cause others to send data to the New Member.
  60. 60. Example Message Sequence Skipping Application connection setup (CACEP) The Pouzin Society • One IPC process is a member of a DIF, another one is not Joining Member IPC Process IPC Process M_START (Enrollment_Info_object{address=null}) 1 The joining IPC Process has no 2 address, not a member of the DIF. M_START_R (ok, Enrollment_Info_object{address=25}) Assign a valid address and reply Got a positive response and 3 an address. Wait for STOP Send DIF static info (whatevercast4 Enrollment response, RIB 4 names, data transfer Daemon processes the M_CREATE (DIF_info1) constants, qos cubes, supported M_CREATE messages policy sets) and dynamic info 5 (neighbours, directory forwarding … table entries) through a series of M_CREATE (DIF_infoN) M_CREATE messages 5 Check if I got enough data to Once all the information is sent, start. If more info is required 6 send stop enrollment request send M_READ requests on (informing the enrollee has to specific objects (not the M_STOP (Enrollment{allowed_to_start_early=true}) wait for START operation request) case). I’m Enrolled! and wait for response Now, if I have a DIF in 78 common with one or more of the neighbors (I’m M_STOP_R (ok) multihomed) I could enroll with them as well (next slide) 9 10 Got STOP response. He’s enrolled! Ignore if started earlier, or M_START (operationalStatus)12 Send M_START message (no start now (consider enrolled 11 answer required) now) 60
  61. 61. Example Message Sequence Skipping Application connection setup (CACEP) The Pouzin Society • Both IPC Processes are members of the same DIF Joining Member IPC Process IPC Process also a member M_START (Enrollment_Info_object{address=25}) 1 The joining IPC Process has a valid 2 address, he is a member of the M_START_R (ok, Enrollment_Info_object{address=25}) DIF. Reply Got a positive response and 3 my address is still valid. Send DIFs dynamic info only4 Wait for M_STOP 4 (neighbours, directory forwarding enrollment request, RIB M_CREATE (DIF_info1) table entries) through a series of Daemon processes the M_CREATE messages M_CREATE messages 5 … M_CREATE (DIF_infoN) 5 Once all the information is 6 sent, send stop enrollment Check if I got enough data to request M_STOP (Enrollment{allowed_to_start_early=true}) start. If more info is required send M_READ requests on 78 specific objects (not the case). The member I’ve talked to is now my M_STOP_R (ok) neighbor! 9 Ignore if started earlier, or M_START (operationalStatus) 10 Got STOP response. He’s my12 start now (consider enrolled 11 neighbor! Send start message, no now) response required 61
  62. 62. The Pouzin SocietyIPC PROCESSFlow Allocation 62
  63. 63. Flow Allocator The Pouzin Society Allocate(Dest-Appl-Name, QoS parameters) Flow Allocator Dir Local Forwarding Dir Cache Table• When Application Process generates an Allocate request, the Flow Allocator creates a flow allocator instance to manage each new flow.• The Instance is responsible for managing the flow and deallocating the ports – DTP/DTCP instances are deleted automatically after 2MPL with no traffic,• When it is given an Allocate Request it does the following: 63
  64. 64. Details of the Allocation Data Flow: I The Pouzin Society Allocate(dest-appl, desired_flow_properties) Appl-names Next Place Create Flow(dest-appl, stuff) FAI Directory Subscribe Forwarding Create/delete Table Flow objects EFCP RIB Daemon IPC/RMT• Upon initialization, the FA subscribes to create/delete flow objects.• The FAI is handed an allocate request. After determining that it is well formed it must find the destination application.• It consults the Directory Forwarding Table (dotted arrow). The table maps the dest-appl in the request to a “Next Place” to look for it (IPC Process @)• That points to either a nearest neighbor management flow (if it is multihomed there will be more than one) or a connection allocated that does not go to a nearest neighbor, but uses the data transfer AE. This connection was created by the management task and is available to all tasks within the IPC Process. 64
  65. 65. Details of the Allocation Data Flow: II The Pouzin Society Appl-names Next Place FA Create Flow(dest-appl, stuff) RIB Directory Daemon Forwarding Table EFCP Create Flow(dest-appl, stuff) IPC/RMT• When a Create Flow Request arrives, the RIB Daemon forwards it to the FAI for inspection.• If the FA determines that dest-appl is not here, then it consults the Directory forwarding table as before to determine where to send it next.• If dest-appl is here, then . . . 65
  66. 66. Details of the Allocation Data Flow: III The Pouzin Society Allocate Dest Allocate Indicate Appl Confirm Read/Write Appl-names Next Place Create Flow Resp FAI RIB Directory Daemon Forwarding Table EFCP Create Flow Req(dest-appl, stuff) IPC/RMT• When the Create Flow Req arrives it is passed to the Flow Allocator.• The Flow Allocator looks it up in the table and determines that dest-appl is here. It determines whether or not the requestor has access to dest-appl.If it does,• then dest-appl is instantiated if necessary, and given an allocate indicate.• It responds with an allocate confirm, if positive then data transfer can commence.• In either case or earlier of access was denied, a Create Flow Resp is sent back with the appropriate response. 66
  67. 67. Implementation of the Flow AllocatorApplication registration and DirectoryForwardingTable The Pouzin Society• DirectoryForwardingTable maps ApNames to the @ of IPC processes where they are currently registered. – Updated by local application registration events (through IPC API) – Updated by remote application registration events (through remote CDAP messages processed by the RIB Daemon) – Updated by timers (to discard stale entries)• Distributed database, several strategies for implementation (the larger the DIF, the more complex it becomes) – Compromise between load of messages to update the database vs. the timeliness of the data in each DB – Fully replicated vs. partially replicated• Current implementation: simple, only for small DIFs. – Fully replicated Database (all the IPC Processes know about all the registered applications in the DIF) – Each time a local application registers/unregister, the FA sends CDAP M_CREATE message to all its nearest neighbors – Each time a new mapping is learned (from a remote update), if the value of that mapping changed, the FA sends CDAP M_CREATE message to all its nearest neighbors – except for the one that notified the update - 67
  68. 68. Implementation of the Flow Allocator i2CAT: Management of flows and Interaction with EFCP The Pouzin Society Appl. Appl. Process ProcessAllocate allocation_requested(srcApName)Response(result) Allocate Request (destAPName, QoS Params) 1 allocation_response( 9 5 6 result) Map request into M_CREATE(Flow object) IPC Process 2 Check access IPC Process policies, see if is feasible. 3 Search dest app. at the 4 control and Flow policies to see if Flow directory. Allocator Allocator flow is feasible 8 Create DTP/DTCP M_CREATE_R(Flow object) 7 Create 2 Create FAI 2 4 Create FAI instance DTP/DTCP instance FAI DTP/D DTP/D FAI TCP DIF TCP • When the flow has been established, 1 incoming and 1 outgoing queue are allocated at the layer boundary by the FAI • Also, a new EFCP StateVector for the connection (1 per flow right now) is instantiated at the DataTransferAE; as well as 2 queues for queuing PDUs to/from the RMT 68
  69. 69. The Pouzin SocietyIPC PROCESSTransport protocol: EFCP 69
  70. 70. EFCP: Error and Flow Control Protocol The Pouzin Society Data State Vector Transfe Data Transfer r Protocol Control• Based on delta-t with mechanism and policy separated. – Naturally cleaves into Data Transfer and Data Transfer Control • Data Transfer consists of tightly bound mechanisms – Roughly similar to IP+UDP • Data Transfer Control, if present, consists of loosely bound mechanisms. – Flow control and retransmission (ack) control• One or more instances per flow; policies driven by the QoS parameters. – The Flow Allocator translates the QoS parameters into suitable policies. – In parallel, might be used for things like p2p [sic] do. – Used serially, avoids the need for a separate security connection as in IPsec.• Comes in several syntactic flavors based on the length of (address, connection-endpoint-id and sequence number) • Addresses: 8, 16, 32, 64, 128, variable. • CEP-id: 8, 16, 32, 64 • Sequence: 4, 8, 16, 32, 64 70
  71. 71. EFCP: separation of port allocation fromsynchronization The Pouzin Society Port- id Port Allocation (FA dialogue, IPC Connection Process Endpoint management) Synchronization (EFCP state machines, data transfer) Connection• Separatingportallocationfromsynchronization–unlike TCP- has interestingsecurityimplications– more onthislater.• Port Allocationstateiscreated/deletedbasedonexplicitrequests • Local applicationsthroughthe IPC API (allocate/deallocateflows) • Remote CREATE/DELETE Flowrequestsfromother IPC Processes• Synchronizationstateisrefreshedevery time a DTP/DTCP packetissent/received • If no packetisreceivedafter a certainamountof time stateisdiscarded 71
  72. 72. Intro to Delta-TTimer-based connection management The Pouzin Society• All connections exist all the time, the protocol just needs to keep caches of the state for those that have carried traffic recently – When a PDU is received for a certain connectionId, the state of the connection is refreshed – After a certain amount of time with no traffic, the state is discarded• What amount of time with no traffic is necessary to be able to safely discard the send/receive state and ensure that: – No packets from a previous connection are accepted in a new connection – The receiving side doesn’t close until it has received all the retransmissions of the sending site and can unambiguously respond to them – A sending side must not close until it has received an Ack for all its transmitted data or allowed time for an Ack of its final retransmission to return before reporting a giveup failure. 72
  73. 73. Intro to Delta-T (II) Timer-based connection management The Pouzin Society • MPL: Max time to traverse a network Sender Receiver • A: Max time the receiver will wait before sending an acknowledge MPL • R: Max time a sender will keep A retransmitting a packet • deltaT = MPL + A + R R • Watson showed that send state can be safely discarded after a period of 3deltaT with no traffic, and receive state can be discarded after a period of 2deltaT with no traffic• No SYNs are FYNs are necessary (compared to TCP) -> simpler, more robust• Implication of Watson’s results: • If MPL cannot be bound, then there is no wayto have a reliable data transport, therefore it cannot be IPC 73
  74. 74. Data Transfer Protocol (DTP) The Pouzin Society • Notice that the flow is a InboundQ straight shot, very little Delimit SDU processing and if there is anything to do, it is moved to Sequencing/ Fragment/ the side. The most complex Strip Concatenate thing DTP does is Delimiting reassembly and ordering.Reassmb/SeqQ Reassembly/ Sequence/ Separation Address CRC • If there is a DTCP instance ClsdWinQ for this flow: – If the flow control window closes, PDUs are shunted to the flow controlQ. RexmsnQ – If the flow does retransmission, a DTCP copy of the PDU is put on the PDUs rexmsnQ. RMT CRC • These PDUs are now DTCP ’ s responsibility to send when appropriate. 74

×