Technical Kick off meeting Grosuplje September 22-23 2008

1. Networking for Communications Challenged Communities: Architecture, Test Beds and Innovative AlliancesGrant Agreement: 223994 Technical Kick off meetingGrosuplje September 22-23 2008 System Architecture Elwyn Davies elwynd@folly.org.uk www.folly.org.uk

2. Agenda Terminology N4C Architectural Scenario Node Type Taxonomy Application Taxonomy and Issues Node System Partition Sub-systems Beyond the Node Review Criteria for WP2 Architectural Issues www.n4c.eu

3. Terminology Round Trip Bound (RTB) Maximum time for a network round trip Legacy Internet (LI) The 'core' connected part of today's Internet Environment with low elasticity on RTB Communication Challenged Realm (CCR) Area that needs DTN or some other technique Environment with high elasticity on RTB Enclave Area with CCR that can use LI techniques locally but is not connected to LI core with low latency links www.n4c.eu

4. N4CScenario LegacyEnclave Coordination ofgateways Enclave in DTN region Communication within DTN DTN-DTN communication Communication between DTNand Legacy Key Region with 'traditional' connectivity Gateway Region with only DTN connectivity DTN/Legacy Node in DTN DTN/Legacy Node in Legacy Legacy only Node Communication path Node mobility excursion Coordination functionality DTN region 2 Mobility of nodes enclave <-> DTN DTN region 1 Mobility of nodes legacy<-> DTN Legacy Internet www.n4c.eu

5. Kinds of Node(aka Node Taxononomy) Pure Legacy Nodes 'Standard' Internet machine maybe with adapted applications running in 'compatibility mode' DTN Only Nodes Sensor group leaders and static DTN 'routers' Chameleon Nodes mobile, capable of running in both CCRs and LI Gateway Nodes Generally static nodes linking CCR and LI Ability of DTN nodes to provide bundle 'custody' May be a significant extra categorization www.n4c.eu

6. Application Taxonomy Store and Forward Paradigm e.g., email, maybe peer-to-peer applications Client-Server Paradigm Request-response mechanism, e.g., WWW Unidirectional Real Time Stream Paradigm e.g., time-shifted TV programme Interactive Real Time Stream Paradigm e.g.. Skype www.n4c.eu

7. Application Issues Many current applications rely on running in low elasticity RTB environment (i.e., LI) Adapting applications requires Technical solution for DTN working User Expectation Management (different UI?) Some applications are never going to work especially Interactive Real Time Streams www.n4c.eu

8. Node Sub-system Partition www.n4c.eu

9. Gateway Coordination Address mapping Bundle to packet & packet to bundle conversion Inter-gateway coordination to manage arrival of the same data at multiple gateways (especially on the CCR side) Needs a protocol. Redirection of sessions/bundles/packets that need to be injected into a different CCR through another gateway or in to the same CCR via a more appropriate gateway. www.n4c.eu

10. Address Management Nodes in CCRs don't have benefit of DNS need more permanent cache of mappings Cache management DTNmail has rudimentary cache BUT update scheme is not robust Identifier/Locator Issue (discussion point!) Unique Node Identfier Multiple locators (for Chameleon Nodes) One for LI One for each CCR where it is a 'member' www.n4c.eu

11. Routing:within CCR + to/from LI Separate session on Routing... so just an outline PRoPHET implementation improvements and tuning possibly extensions for (loosely) scheduled 'opportunities' Experiments with alternative schemes? Integration with Gateway Coordination www.n4c.eu

12. Node Management Must be able to manage nodes remotely and locally Must be able to monitor nodes (ditto) Must be able to install updated modules over the DTN Must be able to install alternative functionality in place of current modules Must not overload the DTN network with logging www.n4c.eu

13. Review CriteriaInfrastructure must provide... Forwarding of DTN bundles as specified in [RFC5050] Support for DTN transport protocols, including at least LTP, between adjacent nodes Routing mechanisms suitable for directing DTN bundles through the CCR Gateway mechanisms to mediate inter-realm communications between the core LI and CCR DTN regions to mediate inter-realm communications between CCR DTN regions and CCR enclaves using LI protocols manage linkages between realms where multiple gateways are provisioned. Manage configuration and addressing of nodes providing DTN functionality, and the mapping of addresses between the LI and DTN forms where necessary Manage mobility of chameleon nodes moving from LI realms to DTN realms and vice versa Support for authentication of nodes and messages in the DTN environment Support for encryption of messages passing through the DTN environment Logging and monitoring of the infrastructure Mechanisms for secure distribution and installation of new components over the DTN infrastructure www.n4c.eu

14. Architectural Issues What is the nature of a CCR? Seamless Mobility Transport Integration Addressing Schemes, Mappings & Caching Clock Synchronization www.n4c.eu

15. The Nature of an (N4C) CCR Topology vs Geography LI primarily defined by topology (stretched by wireless) "Do I have an IP(v4) address?" (membership token) "Can I get a connection?" But what about CCRs? "Doh! It's a (geographical) region, stupid!"* OK, but: what defines membership? .... What if members meet outside the 'region'? How many CCRs are there? * D.T.N. Simpson, 2002 www.n4c.eu

16. AddressingIdentifiers and Locators? Nodes need a unique identifier BUT are multiple 'locators' needed to 'find' a node either in the LI or one of many CCRs? does this tie up with CCR 'membership'? is it easier to control delivery predictabilities in a CCR based on a separate locator space? is it easier to control replication/looping with separate locators? How to manage robust distribution and caching of identifiers, locator mappings and associations with particular CCRs in a DTN environment? and to manage the linkage of users to nodes? www.n4c.eu

17. Seamless Mobility - 1 A User Perception.... implies requirements on applications need to manage user expectations Coping with different transport paradigms Alternatives (may be best to offer both!): Hide the differences in transport layer Is this desirable? ... possible always? Let the application know and handle the differences but aim for maximum commonality of interface www.n4c.eu

18. Seamless Mobility - 2 How does a node/application know 'where' it is? Differentiating between Wi-Fi in DTN and LI? Does node need to know its 'current' CCR? How does it 'join' a new CCR? How to handle connectivity from LI with a node in a CCR? Gateways provide an 'anchor' in the LI Comparisons with SIP registration/Session Border Controllers (arrggggh!) Mobile IP(v6) home agents www.n4c.eu

19. Transport Integration Can/Should Bundle Protocol be integrated into transport layer? How to offer an (extended) socket interface for all DTN transports? Would it be better to use LTP for bundle exchange at opportunistic encounters? Might imply LTPBundleLTP layering! www.n4c.eu

20. Clock Synchronization Bundle Protocol relies on reasonably accurate wall clock time in all nodes This may be a problem for nodes that need to run for long periods with little external contact Can requirement be removed? www.n4c.eu