PSIRP Architectural Components Part 2 Walter Wong NomadicLab & HIIT Outline Forwarding Mechanism Bloom-filters zFilters Link Identity Tables (LITs) Topology Management & Formation Network Attachment Background IP forwarding Default Free Zone (DFZ) Router GW GW Routing Table Src: Dst: Src: Dst: IP packet Router David Bob IP packet IP forwarding IP address Hierarchical topologic semantic (reflects some location in the network) Forwarding Longest prefix matching Route aggregation Default route towards the Internet Core Bidirectional (reverse path is easily computed) Drawback Identification and location entangled Forwarding in PSIRP Major challenges there is no IP end-point in PSIRP Fid has no topological information, but cryptographic semantics No default forwarding layer for packets Unidirectional No route aggregation Benefit Forwarding based on content identifiers instead of location Data is identified in the network level Forwarding Design Goals Efficient Low latency and high bandwidth Line speed Secure: protection against DDoS capabilities Multicast support Content-centric naming Path splitting Slow path (routing, policies, security, topology management) Fast path (forwarding path) Intra-domain Forwarding Characteristics Links have identifiers (Link IDs) Source routing mechanism Install forwarding state on demand (traffic aggregation) Topology Manager Constructs Bloom filter-based forwarding identifiers Bloom Filters Theory Probabilistic data structure Aggregates a set of information Allows for membership tests Given one key, is it in the bloom filter? Drawback False positives Bloom Filters Construction Bloom Filter Vector Hash 1 Hash 2 Alice Bloom Filters Construction Bloom Filter Vector Hash 1 Hash 2 Bob Bloom Filter Membership Test Bloom Filter Vector Hash 1 Hash 2 Bob Bob is in the Bloom Filter! Bloom Filter Membership Test Bloom Filter Vector Hash 1 Hash 2 Clark Clark is not in the Bloom Filter! Check whether Clark is in the Bloom Filter Bloom Filter False Positives Bloom Filter Vector (contains Alice and Bob) Hash 1 Hash 2 David David is in the Bloom Filter, but he wasnt previously added! False positive! Check whether David is in the Bloom Filter False Positives Math False positive rate: Fp = (0,6185)^ m/n k = (m/n)ln2 m = bits in the data structure n = number of keys in the data structure k = number of different hash functions False Positive Rate False positive rate vs. # of keys Bloom Filter Summary Probabilistic data structure False positives Never false negatives Trade-off between storage and false positives Efficient membership queries Hash functions Line speed Flat Identifiers Routing How to route flat identifiers in the network? Bloom filters? General idea Add the network interfaces where packets must pass through in the Bloom filter Forwarding nodes check which network interfaces are included in the Bloom filter Forwarding Header Construction Each link in PSIRP has an identifier Link identifier (LID) Unidirectional Topology system Conceptual delivery tree Retrieve all links where the data must pass through Forwarding tree Data Forwarding Default case Source-routing based approach Encode all link Ids into a Bloom filter in the packet header Check which output interface has LIds included in the Bloom filter zFilter In-packet Bloom-filter Used to take the forwarding decision zFilter Construction InterfaceLink ID Inter InterfaceLink ID Inter Inter Inter InterfaceLink ID Inter Inter InterfaceLink ID Inter Inter InterfaceLink ID Inter zFilter zFilter zFilter OR Publication 1 zFilter Construction InterfaceLink ID Inter InterfaceLink ID Inter Inter Inter InterfaceLink ID Inter Inter InterfaceLink ID Inter Inter InterfaceLink ID Inter zFilter zFilter zFilter OR Publication 1 zFilter Construction InterfaceLink ID Inter InterfaceLink ID Inter Inter Inter InterfaceLink ID Inter Inter InterfaceLink ID Inter Inter InterfaceLink ID Inter zFilter zFilter zFilter OR Publication 1 Data Forwarding Default case Source-routing based approach Encode all link Ids into a Bloom filter placed in the packet header Check which output interface has LIds included in the Bloom filter zFilter In-packet Bloom-filter Used to take the forwarding decision zFilter Forwarding InterfaceLink ID Inter InterfaceLink ID Inter Inter Inter InterfaceLink ID Inter Inter Interfac e Link ID Inter Inter InterfaceLink ID Inter zFilter zFilter zFilter & zFilter OK! 1 zFilter Forwarding InterfaceLink ID Inter InterfaceLink ID Inter Inter Inter InterfaceLink ID Inter Inter Interfac e Link ID Inter Inter InterfaceLink ID Inter zFilter zFilter zFilter & zFilter OK! 1 zFilter Forwarding InterfaceLink ID Inter InterfaceLink ID Inter Inter Inter InterfaceLink ID Inter Inter Interfac e Link ID Inter Inter InterfaceLink ID Inter zFilter zFilter zFilter & zFilter OK! 1 zFilter Forwarding InterfaceLink ID Inter InterfaceLink ID Inter Inter Inter InterfaceLink ID Inter Inter Interfac e Link ID Inter Inter InterfaceLink ID Inter zFilter zFilter zFilter & zFilter NOK! 1 zFilter Forwarding InterfaceLink ID Inter InterfaceLink ID Inter Inter Inter InterfaceLink ID Inter Inter Interfac e Link ID Inter Inter InterfaceLink ID Inter zFilter zFilter zFilter & zFilter OK! 1 zFilter Forwarding InterfaceLink ID Inter InterfaceLink ID Inter Inter Inter InterfaceLink ID Inter Inter Interfac e Link ID Inter Inter InterfaceLink ID Inter zFilter zFilter zFilter & zFilter OK! 1 zFilter Summary Efficient flat identifier routing Currrent zFilter = 256 bits Link IDs are added in the zFilter (OR operation) Verification requires one comparison (AND operation) Drawback Possible false positive Wrong forwarding path Link Identity Tags (LITs) Solution to reduce false positives Each link has d distinct LITs Allows for constructing zFilters with higher number of zeros Topology Manager has more options to construct the zFilter for the same path Link Identity Tags zFilter dLIT dLIT LIT LIT D= OR Link Identity Tags zFilter dLIT dLIT LIT LIT D= OR D= Link Identity Tags zFilter dLIT dLIT LIT LIT D= OR D= D= Link Identity Tags zFilter dLIT dLIT LIT LIT D= OR D= D= D= = 3 = 6 zFilter Features Multicast Include all link Ids in the zFilter FId 21 FId 13 FId 12 FId 51 FId 32 FId 31 FId 22 FId 11 FId 41 zFilter Features Virtual Links Link aggregation, similar to tunneling model Solution to dense multicast trees Virtual links require state in the routers FId 11 FId 12 FId 21 FId 22 FId 31 FId 32 FId VL-01 FId VL-02 Fast Recovery Backup virtual link Separate virtual backup path pre-configured for each physical link ID No need to change the packets Use activation message, informing the backup route to activate the path Second approach Pre-computed zFilter, add the d value to represent the new path Loop Prevention First approach Select BF with lowest false-positive percentage LIT approach Second approach Cache packets for small period to detect loops Third approach TTL Topology Management/Formation Goal: path creation/computation/management between data sources and sinks Assumptions Publishers & subscribers dont know each others location Topology Manager (TM) Node interested in receiving physical information about the network Creates/Manages forwarding paths Computes the path from the publishers to the subscribers Returns the zFilter Topology Manager (TM) One or more TM per domain Work simultaneously or in anycast way Nodes Local bootstrapping with HELLO messages Collect local connectivity with link quality and forwarding capabilities Publish local connectivity information to the TM TM Reconstructs the overall forwarding level topology in the network Topology Management Intra-domain Topology Management Local network topology generation Intra-domain forwarding structures management Computes network states Updates forwarding information Inter-domain Topology Management Topology formation in the domain level Between administrative domains Configuring and maintaining inter-domain topology based on policies Intra-domain Forwarding & zFilters zFilter requirement Knowledge of the individual links composing the forwarding path LIDs list generated based on the Sid and Rid Domain-specific end-points for data delivery Builds a forwarding graph between end-points Intra-domain TM Identifying possible virtual trees (constantly used paths) Traffic pattern evaluation for virtual tree creation Lifetime and tree management (state in the router) Inter-domain Topology Formation (ITF) Helps building the forwarding information Based on policies set by operators and users Manages edge routers between domains Protection against policy violations Protect domain internals Motivation ITF PSIRP network vision Divided in autonomous systems or domains Controlled by different and competing organizations Similar to the current Internet Domain level connectivity Defined by the relationships between organizations Customers needs Similar to BGP policies Motivation Inter-domain Routing Approximately ~10 tier-1 operators Relationships Customer-provider Peer-peer Sibling-sibling Tier-1operators Peer with each other and dont buy traffic from other operators Monopoly Inter-domain Topology Formation Goals Stores forwarding information among domains Builds forwarding paths based on operators policies Glue together Internet domains Inter-domain Topology Formation Connect multiple intra-domain Topology Managers Communication between local topology formation and inter-domain topology formation Offline route computation Faster approach Path construction between publishers and subscribers through different domains ITF Design Requirements Flexible control of the routing policies Packets with different Rids should have different routing policies High granularity Customers should be able to define per-Rid policies Multi-homing and partial data transit support Operators are able to hide their internal topology Inter-domain Topology Formation ITF Information Gathering Prior to publications RVS inform status of subscribers regarding Sid/Rids Depends on granularity of information in the RVS Forward network identifier ITF has to know a list of network identifiers to connect publishers to subscribers Landmark identifier Some landmark close to the subscriber knows how to deliver publications Forwarding tree identifier Construct partial distribution trees in anticipation of publications ITF Pub/sub approach benefits ITF components can subscribe to route changes There is no need to sequentially notify each domain Multicast support in pub/sub Simultaneous delivery to all ITF through common scope Avoids route flapping (convergence problem) Avoids propagation problems (when to stop) Fault tolerance & Multipath routing Benefits Spread network load Can switch between paths and establish new ones Fault tolerance Security against eavesdropping Some problems TCP ordering Solution Single path for delay sensitive applications No guarantee that there will be path separation if they share the same forwarding domains Network Attachment Discovery of attachment points Information on compatibility, identity, services, policies, etc Initial attachment parameters Bootstrapping procedure Node authentication Identity verification Access rights Configuration information retrieval Setting up identifiers (Fid, Sid, Rid) for communication Security parameters negotiation Network Attachment Communication approaches Information advertisement in the link layer Publish solicitations Nodes can answer with parameters Requirement Default identifiers for initial communication Common scope Scope where advertisements are published Questions? Comments? Thanks!