Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Lecture 5: Slides
Document related concepts
Transcript
1 T-110.6120 Publish/Subscribe Internetworking Helsinki University of Technology, Spring 2010 Lecture 5: Overview of the PSIRP architecture by Arto Karila Slides based on the PSIRP project review slides presented in Brussels on March 3, 2009 and deliverable D2.3: Architecture Definition, Component Descriptions, and Requirements 2 Introduction • Project objectives • Consortium • Working method • Development process 3 Project Objectives The key objectives of the PSIRP project are: 1. Define and develop a new inter-networking architecture based on the publish/subscribe (pub/sub) paradigm 2. Develop a reference implementation of the core of the new architecture 3. Analyse and measure the communications efficiency of new paradigm by quantitative parameters 4. Evaluate qualitative parameters of the new architecture with focus on security and business incentives and models 5. Develop migration and deployment strategies Other aspects: • Follow the clean-slate design approach – take nothing for granted • Consider migration, e.g., via overlay solution • Emphasize security and socio-economics • Publish the results, including source code, as much and as widely as possible • Engage with Future Internet community, e.g., cooperate with FIRE (Onelab2) to test on large scale 4 Consortium • The consortium was formed by people that shared a common vision and wanted to work together towards it • The partners of PSIRP are: 1. Helsinki University of Technology – Helsinki Institute for Information Technology (TKK-HIIT, FI) 2. RWTH Aachen University (RWTH Aachen, DE) 3. British Telecommunications Plc (BT, GB) 4. Oy L M Ericsson Ab (LMF, FI) 5. Nokia Siemens Networks Finland Oy (NSNF, FI) 6. Institute for Parallel Processing of the Bulgarian Academy of Science (IPP-BAS, BG), 7. Athens University of Economics and Business (AUEB, GR), 8. Ericsson Magyarorszag Kommunikacios Rendszerek K.F.T. (HU) 5 Working Method • Iterative working method – Define a pub/sub-based inter-networking architecture – Implement and validate the architecture – Revise the architecture and its implementation • Work packages and tasks are allocated to teams that are formed spontaneously, across organizational boundaries – The purpose is to release creativity in a team consisting of people of different companies and nationalities The approach has proven its strength and it will be continued in the proposed Pursuit project 6 Development Process Requirements Initial Planning Analysis & Design Planning Implementation Deployment Evaluation Testing 7 Technical Overview • Are the fundamentals still valid? • Observation: It’s all about information • Hypothesis: Increased information requires information-centric network approaches • Approach: Clean-slate with late binding • Design methodology • Main design principles • Information centrism is key • Information concepts • Grouping information networks • Information structures 8 Are the Fundamentals Still Valid? Fundamentals of the Internet • Collaboration – Reflected in forwarding and routing • Cooperation – Reflected in trust among participants • Endpoint-centric services – (mail, FTP, even web) – Reflected in E2E principle IP, full end-to-end reachability Reality in the Internet Today • Phishing, spam, viruses – There is no trust any more! • Current economics favor senders – Receivers are forced to carry the cost of unwanted traffic vs. • Information-centric services – Do endpoints really matter? – Endpoint-centric services move towards information retrieval through, e.g., CDNs IP with middle boxes & significant decline in trust in the Internet 9 Observation: It's All About Information Internet Today: • In 2006, the amount of digital information created was 1.288 X 10^18 bits • 99% of Internet traffic is information dissemination & retrieval (Van Jacobson) • HTTP proxying, CDNs, video streaming, … • Akamai’s CDN accounts for 15% of traffic • Between 2001 and 2010, information will increase 1million times from 1 petabyte (10^15) to 1 zettabyte (10^21) • Social networking is information-centric • Most solutions exist in silos • overlays over IP map information networks onto endpoint networks Internet Tomorrow: • Proliferation of dissemination & retrieval services, e.g., • context-aware services & sensors • aggregated news delivery • augmented real life • Personal information tenfold in the next ten years (IBM, 2008) • Increase of personalized video services • e.g., YouTube, BBC iPlayer • Vision recognized by different initiatives & individuals • Internet of Things, Van Jacobson, D. Reed • Lack of interworking of silo solutions will slow innovation and development speed 10 Hypothesis: Increased Information Requires Information-centric Network Approaches Application developers care about information concepts – Creation of information topologies of various kinds -> Endpoint-centric networking structures are inadequate – Topological network changes too slow in timescale – Topological network boundaries too restrictive – Topological network boundaries often not aligned with information topologies – Overlaying possible but restricted in (developer) scalability -> If it is all about information, why not route on information? 11 Approach Clean-slate design… • Question ALL fundamentals • Challenge our thinking • Take nothing for granted, including industry structures • Clear vision …with late binding (to reality) • Consider migration and evolvability in separate work items – How to get our design into real deployments, e.g., overlay vs. IP replacement? • Even consider necessary evolution of industry (& regulatory) structures – How do industries need to evolve in certain scenarios? 12 Design Methodology SoA VISION Add/Remove Add/Remove Goals Constraints Derive Principles Question Observe Design Patterns & Considerations Map Components Remove • Combine bottom-up and top-down – Implementation matters but rationalization is necessary • Adaptive design is crucial – Information-centrism is expected to help for areas like metadata & policy • Aligns well with cyclebased project approach – Creates micro-cycles of question/remove Specify Choice Choice Choice Implement Instance Deploy & evaluate Deployment 13 Main Design Principles • Information is multi-hierarchically organised – Information semantics are constructed as directed acyclic graphs (DAGs) • Information scoping Information Hierarchies Information reachability/ scoping – Mechanisms are provided that allow for limiting reachability of information to parties • Scoped information neutrality – Within each information scope, data is only delivered based on a given (rendezvous) identifier. Communication Model • The architecture is receiver-driven – No entity shall be delivered data unless it has agreed to receive those beforehand. 14 Information Centrism is Key • Data: Mail Data: Picture Governance policy Governance policy Scope Company A Scope Family • Scope Friends Governance policy • • Spouse Father Friend Colleague Information is everything and everything is information – Bootstrap other concepts, e.g., identity, policy, …, Scopes build information networks Policy is metadata – So is scope! Producers and consumers need no internetwork-level addressing! 15 Information Concepts • Information – Smallest something • Information collections – Sets of semantically similar information • Information networks – Sets of information under some common governance • Information producer – Entity publishing information to a particular network • Information consumer – Entity subscribing to information in a particular network 16 Grouping Information Networks 17 Information Structures SId22 SId SId 2 SId1 RId1 Private Information networks SIdSId alg 2 Information networks alg RId Information collections RId22 RId RId 2 Information items 18 Architecture • • • • • • • • • • High-level architecture Architecture process Architectural entities Identifiers Algorithmic identifiers Architectural processes Architecture overview Components Application considerations Conclusions 19 Node Architecture High-Level Architecture : Rendezvous point : Inter-domain topology formation : Topology management : Forwarding node Apps pub pub pub sub Fragmentation Service Model Rendezvous Topology ITF ITF Network Architecture RP ITF TM FN Caching Helper … RP RP Rendezvous Network Error Ctrl Forwarding TM TM Forwarding Network TM FN Forwarding Network Forwarding Network TM Forwarding Network 20 Architecture Process • The aim of the architecture work is to produce coherent design for a publish/subscribe internetwork – Principles, framework, components, internetworking – Networks of information – Using pub/sub in all parts of the protocol suite • The architecture work is iterative – Interaction with implementation and validation workpackages • Encompasses both clean-slate and incremental overlay-based solutions • In practice work is done in a number of architecture teams with participants from different 21 work packages Architectural Entities • Information items – Any data that can be labelled with an identifier – Items can have different identifiers depending on the level of abstraction • Application identifier, rendezvous identifier, forwarding identifier • Algorithmic identifiers • Information networks (or scopes) – Information items grouped into a network of information under a scope – Scopes can be interpreted at various levels of abstraction • Information subscribers and publishers • Domains – Administrative network areas that can be connected using interdomain forwarding architecture 22 Identifiers Publish / Subscribe Metadata (source is implementation-dependent) Data Includes... Application Identifiers (AId) Includes... Scope Identifiers (SId) Associated with... Resolved to... Rendezvous Identifiers (RId) Resolved to... Forwarding Identifiers (FId) Define... Network Transit Paths 23 Architectural processes • Rendezvous – The process of resolving higher level identifiers to lower level identifiers within a given scope. – Three simple cases: link-local, intra-domain, inter-domain • Topology management and formation – Management of data delivery topologies and forwarding graphs • Forwarding – Data delivery within a single administrative domain or across multiple domains. – Temporal forwarding identifiers for each publisher and subscriber are derived via the rendezvous and topology management processes – Various routing and forwarding protocols can be used, for example a new protocol replacing IP or IP-based 25 overlays Architectural processes • Helper functions – Extensions to core functionality of the network architecture, such as management and transport • Network attachment – Discovery of network attachment points and network configuration 26 Architecture Overview AS Rendezvous Subscribe Forwarding node Subscriber Topology Forwarding node AS Topology Forwarding edge nodes Data Forwarding AS Rendezvous Topology Forwarding node Publish Forwarding node Create delivery path Configure Forwarding path Publisher 27 Component Wheel • The network architecture is based on a modular and extensible core called the PSIRP Component Wheel • Components may be decoupled in space, time, and context – Layerless protocol suite • Typical components include rendezvous, forwarding, helper functions, and caching. • Applications may insert or request new components to the wheel at runtime. • The components are attached to the local blackboard – Shared components, publications, state – Pub/sub is used to signal changes to blackboard state 28 Component Wheel 29 Compare w/ Haggle Architecture [Sco2006] J. Scott, P. Hui, J. Crowcroft, C. Diot, Haggle: A Networking Architecture Designed Around Mobile Users, IFIP WONS 2006, Les Menuires, France, 2006 30 Component Wheel Interactions Subscriber Blackboard Caching Routing and forwarding Low-level Link Register and subscribe notifications Register and subscribe notifications Subscribe Notify first component in plan Component done, no cache hit Notify second component in plan Access memory object Forward subscription Publication Insert publication as memory object Notify componen in plant Notify that has been added to cache Notify subscriber 31 Service Model and API We have considered four different classes of network services: 1. A low-level page model that exposes network forwarding and rendezvous/topology formation functions • Basic building block on top of raw forwarding API – Pages and no error or congestion control • Listen(FiD), Forward(FiD, meta-data, data) • Mapping of information items to FiD • Pub/sub API towards higher levels 2. A mid-level memory object model • Memory pages are mapped to publications 3. A mid-level channel model 4. Various high-level service models including shared state and document models 32 APIs Higher-level APIs Channel API Memory Object API Low-level page API 33 Rendezvous • Many faces of rendezvous – Link-local, inter-domain, information services, communal services, … • The main requirements for this functionality are: – Scalability to Internet-like networks and data space sizes – Efficiency of operation, measured in signalling overhead and overall latency – Deployability • The network is defined in terms of domains and their interconnections – Interconnections between domains include upstream, transit, downstream – Rendezvous networks are units of deployment for the PSIRP rendezvous functionality. The rendezvous networks are formed by rendezvous nodes (RNs), organized as a BGP-like inter-domain hierarchy 34 Rendezvous Networks RNA RNC RP RNB RNC10 RNB10 RNC100 RNB100 Sub N N Interconnection overlay RP RNX NX Pub Rendezvous point Rendezvous network Sub Subscriber Rendezvous node Pub Publisher Rendezvous signaling End node 36 Intra- and Inter-Domain Operation • Forwarding is configured by the rendezvous system with the help of the topology management function • Key challenge is scalability • Intra-domain forwarding – Initial work on Bloom-filter based forwarding mechanism indicates that they are useful for sizes up to metropolitan area networks – FiDs identify partial distribution graphs – Minimal state in the routers • Inter-domain forwarding – Solution must take performance and policy requirements into account – Initial work on DHT-based overlay and understanding implications for inter-domain routing 37 – Inter-domain topology function Security and Packet Level Authentication (PLA) • Direct and indirect cryptographic association using identifiers and rendezvous – Public keys and one-way hash values – Algorithmic identifiers • Packet Level Authentication (PLA) is one candidate protocol for securing PSIRP network functions – We assume that per packet public key cryptography operations are feasible in Internet's scale because of new digital signature algorithms and advances in semiconductor technology – PLA is a novel solution for protecting the network infrastructure against various attacks (e.g., DoS) by providing availability – Each packet has a signature (ECC) – Good analogy for PLA is a paper currency: anyone can verify the authenticity of the bill by using built-in security measures like watermark and hologram, there is no need to contact the bank that has issued the bill – The network should be able to fulfill its basic goal: to deliver valid packets of valid users in reliable and timely manner in all situations38 Prototype Implementation Legacy Apps PSIRP Apps Sockets API Emulator Apps PSIRP Library API Libraries Upper layers (possibly Python) PSIRP Kernel API Lower layers (C/C++) Kernel Packet Level Authentication (PLA) Ethernet Wi-Fi IP GMPLS 39 Application Considerations • Application programming interfaces – Inherently information centric – 1-to-1 message stream • Similar to TCP/IP socket API – 1-to-N bidirectional connection • Similar to UDP over IP multicast – 1-to-N document distribution • Similar to CDN and P2P protocols • Examples – WWW functionality – BitTorrent-like content distribution 40 Example: Scoping in CS-comms. Using a scope to initiate client-server-like communications 41 Example: Invitation in CS-comms. Using an invitation to initiate client-server-like communications 42 Example: Adding a Node to Tree Simplified signaling for adding a node to a concast-like tree 43 Example: Interactions in the component wheel Interactions in the component wheel 44 zFilter Forwarding Tables 45 Link ID Tag (LIT) Generation 46 LIT Router Model 47 Multicast-Assisted Mobility 48 Conclusions We have outlined an information centric network architecture • Publish and subscribe are the basic primitives making multicast the norm • Decoupling in space and time • Receiver driven (subscriber has control) • Rendezvous as the primitive to connect publishers and subscribers across domains on multiple levels – Mapping to forwarding structures • Scoping of data into manageable sets • Architecture work is iterative • Implementation and evaluation are on-going activities 49
