Presentation is loading. Please wait.

Presentation is loading. Please wait.

PSIRP Architectural Components Part 2 Walter Wong NomadicLab & HIIT 10.02.2010.

Similar presentations


Presentation on theme: "PSIRP Architectural Components Part 2 Walter Wong NomadicLab & HIIT 10.02.2010."— Presentation transcript:

1 PSIRP Architectural Components Part 2 Walter Wong NomadicLab & HIIT 10.02.2010

2 Outline Forwarding Mechanism ◦ Bloom-filters ◦ zFilters ◦ Link Identity Tables (LITs) Topology Management & Formation Network Attachment

3 Background – IP forwarding Default Free Zone (DFZ) Router 74.192.8.234 128.235.1.23 GW 74.1.23.21 74.192.8.234 128.235.1.23 GW 74.1.23.21 Routing Table Src: 200.201.192.11 Dst: 154.120.12.111 Src: 200.201.192.11 Dst: 154.120.12.111 IP packet Router David Bob IP packet

4 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

5 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

6 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)

7 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

8 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

9 Bloom Filters – Construction 0 0 0 0 0 0 0 0 0 0 0 0 Bloom Filter Vector Hash 1 Hash 2 Alice 1 1 1 1

10 Bloom Filters – Construction 0 0 0 0 0 0 0 0 0 0 0 0 Bloom Filter Vector Hash 1 Hash 2 Bob 1 1 1 1 1 1 1 1

11 Bloom Filter – Membership Test 0 0 0 0 0 0 0 0 0 0 0 0 Bloom Filter Vector Hash 1 Hash 2 Bob 1 1 1 1 1 1 1 1 Bob is in the Bloom Filter! 1 1 1 1

12 Bloom Filter – Membership Test 0 0 0 0 0 0 0 0 0 0 0 0 Bloom Filter Vector Hash 1 Hash 2 Clark 1 1 1 1 1 1 1 1 Clark is not in the Bloom Filter! Check whether Clark is in the Bloom Filter 1 1 1 1

13 Bloom Filter – False Positives 0 0 0 0 0 0 0 0 0 0 0 0 Bloom Filter Vector (contains Alice and Bob) 1 1 1 1 1 1 1 1 Hash 1 Hash 2 David David is in the Bloom Filter, but he wasn’t previously added! False positive! Check whether David is in the Bloom Filter 1 1 1 1

14 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

15 False Positive Rate False positive rate vs. # of keys

16 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

17 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

18 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

19 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

20 zFilter – Construction InterfaceLink ID Inter 100100000 InterfaceLink ID Inter 110100000 Inter 200000001 Inter 300100100 InterfaceLink ID Inter 111001000 Inter 201000000 InterfaceLink ID Inter 100000100 Inter 200001000 InterfaceLink ID Inter 100010000 1 1 1 2 2 2 3 zFilter00000000 zFilter00100000 zFilter00100000 OR Publication 1

21 zFilter – Construction InterfaceLink ID Inter 100100000 InterfaceLink ID Inter 110100000 Inter 200000001 Inter 300100100 InterfaceLink ID Inter 111001000 Inter 201000000 InterfaceLink ID Inter 100000100 Inter 200001000 InterfaceLink ID Inter 100010000 1 1 1 2 2 2 3 zFilter00100000 zFilter00000001 zFilter00100001 OR Publication 1

22 zFilter – Construction InterfaceLink ID Inter 100100000 InterfaceLink ID Inter 110100000 Inter 200000001 Inter 300100100 InterfaceLink ID Inter 111001000 Inter 201000000 InterfaceLink ID Inter 100000100 Inter 200001000 InterfaceLink ID Inter 100010000 1 1 1 2 2 2 3 zFilter00100001 zFilter00001000 zFilter00101001 OR Publication 1

23 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

24 zFilter – Forwarding InterfaceLink ID Inter 100100000 InterfaceLink ID Inter 110100000 Inter 200000001 Inter 300100100 InterfaceLink ID Inter 111001000 Inter 201000000 Interfac e Link ID Inter 100000100 Inter 200001000 InterfaceLink ID Inter 100010000 1 1 1 2 2 2 3 zFilter00111001 zFilter00100000 zFilter00100000 & zFilter00111001 OK! 1

25 zFilter – Forwarding InterfaceLink ID Inter 100100000 InterfaceLink ID Inter 110100000 Inter 200000001 Inter 300100100 InterfaceLink ID Inter 111001000 Inter 201000000 Interfac e Link ID Inter 100000100 Inter 200001000 InterfaceLink ID Inter 100010000 1 1 1 2 2 2 3 zFilter00111001 zFilter00100000 zFilter00100000 & zFilter00111001 OK! 1

26 zFilter – Forwarding InterfaceLink ID Inter 100100000 InterfaceLink ID Inter 110100000 Inter 200000001 Inter 300100100 InterfaceLink ID Inter 111001000 Inter 201000000 Interfac e Link ID Inter 100000100 Inter 200001000 InterfaceLink ID Inter 100010000 1 1 1 2 2 2 3 zFilter00111001 zFilter00000001 zFilter00000001 & zFilter00111001 OK! 1

27 zFilter – Forwarding InterfaceLink ID Inter 100100000 InterfaceLink ID Inter 110100000 Inter 200000001 Inter 300100100 InterfaceLink ID Inter 111001000 Inter 201000000 Interfac e Link ID Inter 100000100 Inter 200001000 InterfaceLink ID Inter 100010000 1 1 1 2 2 2 3 zFilter00111001 zFilter00100100 zFilter00100000 & zFilter00111001 NOK! 1

28 zFilter – Forwarding InterfaceLink ID Inter 100100000 InterfaceLink ID Inter 110100000 Inter 200000001 Inter 300100100 InterfaceLink ID Inter 111001000 Inter 201000000 Interfac e Link ID Inter 100000100 Inter 200001000 InterfaceLink ID Inter 100010000 1 1 1 2 2 2 3 zFilter00111001 zFilter00001000 zFilter00001000 & zFilter00111001 OK! 1

29 zFilter – Forwarding InterfaceLink ID Inter 100100000 InterfaceLink ID Inter 110100000 Inter 200000001 Inter 300100100 InterfaceLink ID Inter 111001000 Inter 201000000 Interfac e Link ID Inter 100000100 Inter 200001000 InterfaceLink ID Inter 100010000 1 1 1 2 2 2 3 zFilter00111001 zFilter00010000 zFilter00010000 & zFilter00111001 OK! 1

30 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

31 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

32 Link Identity Tags zFilter100110001 dLIT 000100000 100010000 211001000 301010011 dLIT 010001000 111000000 200011110 310011001 LIT00100000 LIT10001000 D=010101000 OR

33 Link Identity Tags zFilter100110001 dLIT 000100000 100010000 211001000 301010011 dLIT 010001000 111000000 200011110 310011001 LIT00010000 LIT11000000 D=111010000 OR D=010101000

34 Link Identity Tags zFilter100110001 dLIT 000100000 100010000 211001000 301010011 dLIT 010001000 111000000 200011110 310011001 LIT11001000 LIT00011110 D=211011110 OR D=111010000 D=010101000

35 Link Identity Tags zFilter100110001 dLIT 000100000 100010000 211001000 301010011 dLIT 010001000 111000000 200011110 310011001 LIT01010011 LIT10011001 D=311011011 OR D=111010000 D=010101000 D=211011110 = 3 = 6

36 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

37 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

38 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

39 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

40 Topology Management/Formation Goal: path creation/computation/management between data sources and sinks Assumptions ◦ Publishers & subscribers don’t know each other’s 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

41 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

42 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

43 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)

44 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

45 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

46 Motivation – Inter-domain Routing Approximately ~10 tier-1 operators Relationships ◦ Customer-provider ◦ Peer-peer ◦ Sibling-sibling Tier-1operators ◦ Peer with each other and don’t buy traffic from other operators ◦ Monopoly

47 Inter-domain Topology Formation Goals ◦ Stores forwarding information among domains ◦ Builds forwarding paths based on operator’s policies ◦ Glue together Internet domains

48 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

49 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

50 Inter-domain Topology Formation

51 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

52 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)

53 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

54 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

55 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

56 Questions? Comments? Thanks!


Download ppt "PSIRP Architectural Components Part 2 Walter Wong NomadicLab & HIIT 10.02.2010."

Similar presentations


Ads by Google