SlideShare a Scribd company logo

5 mngmt idd130115jd

•
•
A
ARCFIRE ICT

This document discusses name space management in the Recursive InterNetwork Architecture (RINA). It describes how name space management distribution management systems (NSM-DMSs) can manage application name spaces that span multiple DIFs. NSM-DMSs allow applications to discover other applications across DIF boundaries. They authenticate applications, manage policies for updating name space data, and help determine which DIFs are needed between applications. For large systems, some NSM-DAPs contain only local information while others aggregate information. Queries are forwarded between these to discover applications. Creation of supporting DIFs may also be needed between source and destination applications. The document compares this application discovery approach to the current DNS system and discusses

Related slideshows

Coolie @ call
Coolie @ callCoolie @ call
Coolie @ call
 
Distributed dbms (ddbms)
Distributed dbms (ddbms)Distributed dbms (ddbms)
Distributed dbms (ddbms)
 
Why a Data Services Marketplace is Critical for a Successful Data-Driven Ente...
Why a Data Services Marketplace is Critical for a Successful Data-Driven Ente...Why a Data Services Marketplace is Critical for a Successful Data-Driven Ente...
Why a Data Services Marketplace is Critical for a Successful Data-Driven Ente...
 
1 of 16
Download to read offline
The Pouzin Society © John Day, 2013 1 Rights Reserved DAFs and Management in RINA IRATI Workshop Barcelona, Spain John Day and Eleni Trouva
The Pouzin Society © John Day, 2013 2 Rights Reserved Name Space Management DMSs
The Pouzin Society © John Day, 2013 3 Rights Reserved Name Space Management (NSM) •  The IPC Model posits a function that allows the Application Name Space to have a greater scope than any one DIF. –  Which we have called the Inter-DIF Directory (for lack of a better term) –  Entity associated with the IPC Management in DAPs may query what applications are available in a system. –  This forms a graph where the nodes are NSM-DAPs and the arcs are DIFs DIFs NSM-DAPs
The Pouzin Society © John Day, 2013 4 Rights Reserved NSM-DSMs •  Considering this a Name Space Management DMS reveals the functions: –  Authenticate applications that are allowed to query the NSM-DMS –  Authenticate and authorize entities that are allowed to update or modify the NSM-DMS. –  Implement the policies for updating and replicating data to meet load and reliability requirements, including creating forwarding tables. –  Check credentials of a request to determine requestor has access to the requested DAF and if so, return a list of DIFs and supporting DIFs. –  Manage the name space, determine who gets assigned what. –  Manage the creation of a common DIF between the requesting and requested DAPs.
The Pouzin Society © John Day, 2013 5 Rights Reserved NSM-DSMs •  For an environment of significant size, we can expect that information on available applications will be organized to shorten search time. –  Hence some NSM-DAPs will contain only local information: –  While others will be repositories for aggregate information: •  The repositories might be organized by a hierarchy, DHTs, the Dewey Decimal System, etc. –  This implies two kinds of forwarding tables: •  Find the next repository, either aggregate or local. •  Forward among NSM-DAPs to get to those repositories. NSM-DAF (top and side views) DIFs
The Pouzin Society © John Day, 2013 6 Rights Reserved NSM-DSMs •  Clearly there is a potential scaling problem here, if we are not careful. •  For large systems, a management system (either an OS-DMS or NM- DMS) will be responsible for access control domains. –  These DMSs will be authorized to update or modify information aggregated with a NSM-DMS, will provide the local NSM-DAP, and participate in creating or joining new DIFs. –  Everything else will be a NSM-client only, i.e. can only submit queries. •  May not be considered a member of the NSM-DAF or a lesser member. •  For small systems, it degenerates into the DAF structure. OS or NM-DMS NSM-DMS Processing System Updates Queries
The Pouzin Society © John Day, 2013 7 Rights Reserved Discovery of the application     Forwarding of the request between the peer IDDs until the destination application is found or the pre-defined termination condition is met host H2 router R2 router R3 host H1 web server application B web browser application A router R4 router R1 host H4 Layer 6 router R5 host H3 ... Layer 1 Layer 3 Layer 2 Layer 4 Layer 5 IDD DAF web server application C 7
The Pouzin Society © John Day, 2013 8 Rights Reserved IDD Information •  Naming / synonyms •  Neighbor Table •  Search Table •  Directory Search Table Application Process Name List of Peer IDDs Application Process Names Naming Information IDD Application Process Name synomyms (optional) Neighbor Table Peer IDD Application Process Name List of Peers IDDs Application Process Names Directory Application Process { Name, Access Control Information } List of supporting DIFs { Name, Access Control Information, supported QoS } 8
The Pouzin Society © John Day, 2013 9 Rights Reserved What does the IDD request look like? •  A CDAP Read Request for an IDD-Record IDD-Request requested-Application-Process-Naming-Information requesting-Application-Process-Access Control Information, QoS parameters •  The CDAP Read Request can be encapsulated in an A-Unit-Data A-Unit-Data destination’s IDD DAP name source’s IDD DAP name termination condition (e.g. hop count) CDAP-PDU 9
The Pouzin Society © John Day, 2013 10 Rights Reserved How is it forwarded? 10 CDAP-PDU Requested-Application-Process-Naming-Info Requesting-Application-Process-Access Control Info QoS parameters A-Data-Unit Destination’s IDD DAP name Source’s IDD DAP name Termination condition CDAP-PDU
The Pouzin Society © John Day, 2013 11 Rights Reserved How is it forwarded? •  From any DAP to the other you forward A-Data-Units •  In the first, the last and all the red DAPs you process the CDAP PDU •  Only in the destination IDD DAP (last one) you do a CDAP Read for an IDD-Record NSM-DAPs DIFs Source Destination
The Pouzin Society © John Day, 2013 12 Rights Reserved Discovery of the application   •  Confirmation that the requested application is available in the destination system and authorization check that the requesting application has the rights to access it host H2 router R2 router R3 host H1 web server application B web browser application A router R4 router R1 host H4 Layer 6 router R5 host H3 ... Layer 1 Layer 3 Layer 2 Layer 4 Layer 5 IDD DAF web server application C 12
The Pouzin Society © John Day, 2013 13 Rights Reserved Creation of the supporting DIF   A DIF supporting the communication between the two user applications has to be found   This either involves creating a new DIF from scratch or expanding (joining) an existing one so that it spans from the source to the destination system host H2 router R2 router R3 host H1 web server application B web browser application A router R4 router R1 host H4 Layer 6 router R5 host H3 ... Layer 1 Layer 3 Layer 2 Layer 4 Layer 5 IDD DAF web server application C 13
The Pouzin Society © John Day, 2013 14 Rights Reserved Implications •  There is no application discovery mechanism in the Internet today, just pointers to where to search next as it happens with DNS •  Applications do not have to be in the same layer to discover each other, especially not on the same one layer as with IP •  Elimination of the need for layers with large address spaces –  In other words there’s no need for a global address space •  No need for a single application namespace. Name spaces can be tailored to environments. •  Greater security by having multiple application namespaces and by better compartmentalization without impairing reachability 14
The Pouzin Society © John Day, 2013 15 Rights Reserved Another Interesting Pattern •  Notice that the pattern exhibited by the NSM-DSM of: –  Look up among distributed data bases (NSM-repositories) followed by determining a path (of DIFs). •  Has precisely the same structure as the Flow Allocator: –  Look up among distributed data bases (Directory) followed by determining a path of relays (Routing). •  The first involves multiple DIFs •  The second involves multiple IPC Processes. •  There may be another collapse here.
The Pouzin Society © John Day, 2013 16 Rights Reserved Questions?

More Related Content

5 mngmt idd130115jd

  • 1. The Pouzin Society © John Day, 2013 1 Rights Reserved DAFs and Management in RINA IRATI Workshop Barcelona, Spain John Day and Eleni Trouva
  • 2. The Pouzin Society © John Day, 2013 2 Rights Reserved Name Space Management DMSs
  • 3. The Pouzin Society © John Day, 2013 3 Rights Reserved Name Space Management (NSM) •  The IPC Model posits a function that allows the Application Name Space to have a greater scope than any one DIF. –  Which we have called the Inter-DIF Directory (for lack of a better term) –  Entity associated with the IPC Management in DAPs may query what applications are available in a system. –  This forms a graph where the nodes are NSM-DAPs and the arcs are DIFs DIFs NSM-DAPs
  • 4. The Pouzin Society © John Day, 2013 4 Rights Reserved NSM-DSMs •  Considering this a Name Space Management DMS reveals the functions: –  Authenticate applications that are allowed to query the NSM-DMS –  Authenticate and authorize entities that are allowed to update or modify the NSM-DMS. –  Implement the policies for updating and replicating data to meet load and reliability requirements, including creating forwarding tables. –  Check credentials of a request to determine requestor has access to the requested DAF and if so, return a list of DIFs and supporting DIFs. –  Manage the name space, determine who gets assigned what. –  Manage the creation of a common DIF between the requesting and requested DAPs.
  • 5. The Pouzin Society © John Day, 2013 5 Rights Reserved NSM-DSMs •  For an environment of significant size, we can expect that information on available applications will be organized to shorten search time. –  Hence some NSM-DAPs will contain only local information: –  While others will be repositories for aggregate information: •  The repositories might be organized by a hierarchy, DHTs, the Dewey Decimal System, etc. –  This implies two kinds of forwarding tables: •  Find the next repository, either aggregate or local. •  Forward among NSM-DAPs to get to those repositories. NSM-DAF (top and side views) DIFs
  • 6. The Pouzin Society © John Day, 2013 6 Rights Reserved NSM-DSMs •  Clearly there is a potential scaling problem here, if we are not careful. •  For large systems, a management system (either an OS-DMS or NM- DMS) will be responsible for access control domains. –  These DMSs will be authorized to update or modify information aggregated with a NSM-DMS, will provide the local NSM-DAP, and participate in creating or joining new DIFs. –  Everything else will be a NSM-client only, i.e. can only submit queries. •  May not be considered a member of the NSM-DAF or a lesser member. •  For small systems, it degenerates into the DAF structure. OS or NM-DMS NSM-DMS Processing System Updates Queries
  • 7. The Pouzin Society © John Day, 2013 7 Rights Reserved Discovery of the application     Forwarding of the request between the peer IDDs until the destination application is found or the pre-defined termination condition is met host H2 router R2 router R3 host H1 web server application B web browser application A router R4 router R1 host H4 Layer 6 router R5 host H3 ... Layer 1 Layer 3 Layer 2 Layer 4 Layer 5 IDD DAF web server application C 7
  • 8. The Pouzin Society © John Day, 2013 8 Rights Reserved IDD Information •  Naming / synonyms •  Neighbor Table •  Search Table •  Directory Search Table Application Process Name List of Peer IDDs Application Process Names Naming Information IDD Application Process Name synomyms (optional) Neighbor Table Peer IDD Application Process Name List of Peers IDDs Application Process Names Directory Application Process { Name, Access Control Information } List of supporting DIFs { Name, Access Control Information, supported QoS } 8
  • 9. The Pouzin Society © John Day, 2013 9 Rights Reserved What does the IDD request look like? •  A CDAP Read Request for an IDD-Record IDD-Request requested-Application-Process-Naming-Information requesting-Application-Process-Access Control Information, QoS parameters •  The CDAP Read Request can be encapsulated in an A-Unit-Data A-Unit-Data destination’s IDD DAP name source’s IDD DAP name termination condition (e.g. hop count) CDAP-PDU 9
  • 10. The Pouzin Society © John Day, 2013 10 Rights Reserved How is it forwarded? 10 CDAP-PDU Requested-Application-Process-Naming-Info Requesting-Application-Process-Access Control Info QoS parameters A-Data-Unit Destination’s IDD DAP name Source’s IDD DAP name Termination condition CDAP-PDU
  • 11. The Pouzin Society © John Day, 2013 11 Rights Reserved How is it forwarded? •  From any DAP to the other you forward A-Data-Units •  In the first, the last and all the red DAPs you process the CDAP PDU •  Only in the destination IDD DAP (last one) you do a CDAP Read for an IDD-Record NSM-DAPs DIFs Source Destination
  • 12. The Pouzin Society © John Day, 2013 12 Rights Reserved Discovery of the application   •  Confirmation that the requested application is available in the destination system and authorization check that the requesting application has the rights to access it host H2 router R2 router R3 host H1 web server application B web browser application A router R4 router R1 host H4 Layer 6 router R5 host H3 ... Layer 1 Layer 3 Layer 2 Layer 4 Layer 5 IDD DAF web server application C 12
  • 13. The Pouzin Society © John Day, 2013 13 Rights Reserved Creation of the supporting DIF   A DIF supporting the communication between the two user applications has to be found   This either involves creating a new DIF from scratch or expanding (joining) an existing one so that it spans from the source to the destination system host H2 router R2 router R3 host H1 web server application B web browser application A router R4 router R1 host H4 Layer 6 router R5 host H3 ... Layer 1 Layer 3 Layer 2 Layer 4 Layer 5 IDD DAF web server application C 13
  • 14. The Pouzin Society © John Day, 2013 14 Rights Reserved Implications •  There is no application discovery mechanism in the Internet today, just pointers to where to search next as it happens with DNS •  Applications do not have to be in the same layer to discover each other, especially not on the same one layer as with IP •  Elimination of the need for layers with large address spaces –  In other words there’s no need for a global address space •  No need for a single application namespace. Name spaces can be tailored to environments. •  Greater security by having multiple application namespaces and by better compartmentalization without impairing reachability 14
  • 15. The Pouzin Society © John Day, 2013 15 Rights Reserved Another Interesting Pattern •  Notice that the pattern exhibited by the NSM-DSM of: –  Look up among distributed data bases (NSM-repositories) followed by determining a path (of DIFs). •  Has precisely the same structure as the Flow Allocator: –  Look up among distributed data bases (Directory) followed by determining a path of relays (Routing). •  The first involves multiple DIFs •  The second involves multiple IPC Processes. •  There may be another collapse here.
  • 16. The Pouzin Society © John Day, 2013 16 Rights Reserved Questions?