Compact forwarding : Uma abordagem probabil

1
Compact forwarding Uma abordagem probabilística
para o encaminhamento de pacotes em redes
orientadas a conteúdo

• Christian Esteve Rothenberg
• Exame de defesa de Doutorado, 15/12/2010
• Universidade Estadual de Campinas (Unicamp)

2
Agenda
Questions
3
Background and Motivation
- radical research -
What is needed?
What is possible?
information-centrism
PSIRP
DONA
content-centric networking
New ID spaces
TRIAD
ROFL
id-loc
CDN
clean-slate
DPI
P2P
overlays
IPv6
networking (r)evolution
middleboxes
NAT
patching
TCP/IP
Telephony
4
Content-oriented Networking Rethinking
fundamentals
?

• Send / Receive ? Publish / Subscribe
• Sender-driven ? Receiver-driven
• Host names ? Data names
• Host reachability ? Information scoping
• Channel security ? Self-certified metadata
• Unicast ? Multicast

5
Problem

• Data forwarding challenges of content-oriented
  networks
• Focus on data, not on end-points
• Re-think the packet forwarding plane
• What is a suitable forwarding substrate for
  content-centric networks departing from the
  host-centric paradigm of IP?
• Which are candidate features and enabling data
  structures?
• Main abstraction is a flat label
• Bit string representing any higher level
  information (e.g. content object, network link,
  multicast tree, endpoint ID).
• How to forward packets labeled with flat
  (location-independent, unstructured, random
  looking) identifiers?

6
Longest IP prefix vs. flat label matching
IPv4 Dec. 81.216.171.106
IPv4 Bin. 01010001 11011000 10101011 01101010
human
machine
Aggr.
IPv6 Hex. ca12b9fa655a00000000ac2fcceff0ab
IPv6 Bin. 11001010 00010010 10111001 11111010 11001010 01011010 00000000 00000000 10101100 00000000 00000000 00101111 11001100 11101111 11110000 10101011
256-bit flat label Hex. 08090A0B0D0E0F10121314151718191A1C1D1E1F21222324262728292B2C2D2E
256-bit flat label Bin. 11111010 11001010 01011010 00000000 00000000 10101100 00000000 00000000 10101100 00000000 00000000 00101111 11001100 11101111 11110000 10101011 11001010 00010010 10111001 11111010 01011010 00000000 00000000 10101100 11101111 11110000 10101011 11001010 00010010 10111001 11111010 11001010
flat ID forwarding is expensive _at_ wire speed
7
Scale by aggregation

• Global networks are able to scale by aggregating
  the address space so that state is needed only
  for each aggregate.
• Scalability principle also known as information
  hiding.
• Examples
• Public switched telephone number aggregation on
  geographical location
• Domain Name System (DNS) Zone aggregation of
  hierarchical names
• Hierarchical routing Aggregation of IP addresses
  on address blocks
• Problem
• Flat labels are not aggregatable
• How to provide efficient wire-speed forwarding on
  a large universe (e.g., 256-bit) of flat
  identifiers?
• A probabilistic approach
• Synthetic aggregation through suitable (lossy)
  compression methods applied to packet forwarding.
• Transform the packet forwarding into a set
  membership problem solved by probabilistic data
  structures (i.e., Bloom filter variations).

8
The role of Bloom and family

• Well-known probabilistic data structure
• Efficient data set aggregator
• False positive rate
• f (memory / elements)
• Suits wire-speed forwarding requirements
• Low (bounded) packet processing time (time to
  hash)
• Scarcity of high-speed memory
• Compact forwarding approach
• Forwarding as a set membership-problem solved by
  variations of the Bloom filter probabilistic data
  structure
• Relax algorithmic correctness trade state for
  over-deliveries (bandwidth efficiency)

Insert_element()
Check_element()
yes / no ?
9
A probabilistic approach to packet forwarding

• Compact forwarding as two extreme set
  membership-problems solved with probabilistic
  data structures (i.e., Bloom filters)

• SPSwitch Is packet label X in forwarding port P?
  
• State in the network
• Large Bloom filters maintained in forwarding
  tables

• iBFs Is outbound link A in packet header Z?
• State in the packet header
• Small in-packet Bloom filter representing a
  source route

10
Compact forwarding

• We can define compact forwarding as a study of
  the trade-offs of in-network and in-packet
  forwarding methods that guarantee the correct
  delivery of packets in function of forwarding
  efficiency.
• Definition 1 We say a forwarding method is
  compact if each forwarding table entry requires
  less than log(n)-bits per routable object in an
  n-dimension universe.
• Definition 2 We say a forwarding method is
  compact if the datagram header size is of fixed
  size with independence of the forwarding
  directives included.
• Notion of compactness
• Striving for minimal forwarding information base
• Forwarding methods based on probabilistic data
  structures(i.e. one-sided error prone Bloom
  filter inspired data structures)

11
4-dimensional solution space
Transport efficiency
Routing / forwarding information in packets(i.e.
packet header bits)
(Stretch,
(Stretch, Bandwidth)
packet routing
State in network elements(i.e. FIB bits)
Adaptation costs (e.g. signaling)
12
Contributions

• Principles
• Collection of generic and technical principles
  for scalable forwarding in content-oriented
  networks
• Algorithmic techniques
• Conception and application of algorithmic
  techniques to cope with the limitations of
  previous work in probabilistic data structures
  and deal with anomalies of probabilistic
  forwarding.
• Applications
• Validation of the compact forwarding methods in
  practical networking scenarios
• Internet-scale publish/subscribe networking
• Scalable cloud data center networking
• Inter-domain multicast

13
Principles

• Principle 1 Separate routing from forwarding
• Content-oriented routing protocols should be
  functionally separated from the forwarding
  elements. (Separation of concerns and
  evolvability)
• Sub-Principle A Generality The forwarding
  methods should be generic enough with regard to
  the identifiers
• Sub-Principle B Simplicity The forwarding
  methods should be based on simple per-packet
  primitives
• Principle 2 Allow a flexible operation point
• The forwarding system should enable the network
  architect/operator to find a sweet spot for a
  given networking scenario
• Principle 3 Multicast-friendliness
• The forwarding methods should provide native
  multicast capabilities
• Principle 4 Receiver-controlled data plane
  security
• The forwarding methods should be designed with
  security in mind, empowering the receiver with
  control over the delivered traffic

14
Compact forwarding Algorithmic techniques

• Compact forwarding as two extreme set
  membership-problems solved with probabilistic
  data structures (i.e., Bloom filters)

• SPSwitch Is packet label X in forwarding port P?
  
• State in the network
• Large Bloom filters maintained in forwarding
  tables

• iBFs Is outbound link A in packet header Z?
• State in the packet header
• Small in-packet Bloom filter representing a
  source route

15
In-network compact forwarding

• Bloom-filter-inspired
• Efficient data set aggregator
• Answers set membership questions (yes/no)
• No false negatives Inserted elements return
  always true
• False positive performance f (memory /
  elements)
• Does not depend on the nature (form, size) of the
  element
• Low (constant) processing time and low memory
  requirements per entry.
• Our first naïve p-bank Bloom-filter-based
  switching approach
• Bloom filter membership-problem

16
The SPSwitch switching engine
Is packet label X in forwarding port P?
17
Limitations of standard BFs

• a) lack of associated values
• b) expensive deletion
• c) no notion of time
• d) unbalanced usage of memory per outport

We need a more flexible (probabilistic) data
structure!
? d-left Fingerprint Compressed Filter
(FCF) recent results by Bonomi et al. (2006)
18
Statefull d-left FCF approach
19
Experimental results
Problem Still O(n) entries
20
Compact forwarding Algorithmic techniques

• Compact forwarding as two extreme set
  membership-problems solved with probabilistic
  data structures (i.e., Bloom filters)

• SPSwitch Is packet label X in forwarding port P?
  
• State in the network
• Large Bloom filters maintained in forwarding
  tables
• Limitations O(n) entries (compact few bits
  per element but state required per content
  object or per flow)

• iBFs Is outbound link A in packet header Z?
• State in the packet header
• Small in-packet Bloom filter representing a
  source route

21
In-packet Bloom filter compact forwarding

• State in the packet headers
• Each network link has an identity and (a series
  of) Link IDsBloomed LID 256 bit vector with
  just k5 bit positions set to one
• Forwarding on small, fixed size iBF representing
  a source route
• Formed by topology functions or collected on path
  (cf. IP switching)
• Basic operation
• Is outbound link A in packet header Z?
• Small forwarding tables
• Very fast switching (bitwise AND operations)

22
iBF forwarding Practical results

• Stateless multicast with 256-bit iBFs (2 x IPv6
  addresses)
• Enough for Internet-wide unicast and sparse
  multicast in typical WAN (35 links -gt approx. 20
  edge nodes)

Users
Zipf distribution of multicast traffic
Groups
stateless
stateful
23
Compact forwarding Algorithmic techniques

• Compact forwarding as two extreme set
  membership-problems solved with probabilistic
  data structures (i.e., Bloom filters)

• SPSwitch Is packet label X in forwarding port P?
  
• State in the network
• Large Bloom filters maintained in forwarding
  tables
• Limitations O(n) entries (compact few bits
  per element but state required per content
  object or per flow)

• iBFs Is outbound link A in packet header Z?
• State in the packet header
• Small in-packet Bloom filter representing a
  source route
• Limitations False positives (efficiency, loops,
  security)

24
iBF algorithmic extensions Power of choices

• Better forwarding efficiency with a simple trick
• Define d different Link ID Tags (LITs) instead of
  a single LID
• LIT has the same size as LID, and also k bits set
  to 1
• Route creation and packet forwarding
• Calculate d different candidate zFilters
• Select the best performing zFilter, based on some
  policy

25
iBF algorithmic extensions d Link ID Tags

• Performance gains (better false positive rates)
• better forwarding efficiency more links
• Functional gains Avoid system critical false
  positives (e.g., inter-domain links, low BW
  links, loops)

26
iBF algorithmic extensionsSecurity

• Shortcomings of plain iBF forwarding
• Replay attacks
• Computational attacks
• Traffic injection attack
• Goal Secure the data path and empower the
  receiver.
• Ensure (probabilistically) that hosts cannot send
  un-authorized traffic
• Solution (z-Formation) Dynamically compute LIT
  at line speed and bind it to
• path in-coming and out-going port
• time periodically changing keys (per node/group)
• flow packet identifier (e.g. IP 5-tuple /
  content id)

27
iBF algorithmic extensionsz-Formation (secure
iBFs)

• Form LITs algorithmically
• at packet handling time
• LIT(d) Z (I , K (t), In, Out, d)
• Secret periodic key K
• K(t) and K(t-1)
• Input port index
• Output port index
• Flow ID from the packet, e.g.
• Content ID
• IP addresses ports
• d from the packet header

28
iBF algorithmic extensionsself-routing
capabilities

• Secure iBF works both as a forwarding ID and a
  capability
• To send, a host needs to know or guess a valid
  iBF
• iBF become expirable and content-dependent

• z-Formation
• Traffic injection difficult (due to binding to
  incoming port)
• Very hard to construct one valid iBF without
  knowing keys along the path
• Correlation attacks limited to flow IDs
• Need a cryptographically good and fast Z
  implementation
• Allow the receiver to control the iBF renewal
  (feedback loop to the sender)

29
BF algorithmic extensionsCompactly removing
elements

• How to delete elements from the iBF?
• Requirements
• No false negatives upon element deletion.
• Fixed memory allocation (m bits).
• Low impact on the false positive rate (fpr),
• No previous work provides memory-efficient
  element deletions
• Counting Bloom ?lter designs extend 1-bit cells
  to c-bit counters i.e., cm .
• The d-left CBF requires about 2m.
• BF with variable-length signatures (VLF) are
  prone to false-negatives.
• Spectral Bloom ?lters, and an optimal Bloom
  ?lter replacement are complex and static
  unpractical solutions.

30
BF algorithmic extensionsThe deletable Bloom
filter (DlBF)

• Key idea Small bitmap to keep record of the bit
  regions where collisions happen.

31
BF algorithmic extensionsDlBF From theory to
practice

• How many elements can be removed in practice?

32
Applications

• Compact forwarding in practice

33
Publish/Subscribe Architecture RTFM Where iBFs
were born LIPSIN
rendezvous layer establishes contact
topology layer selects routes
forwarding layer delivers data
34
Data Center Networking
35
Some issues with conventional DC designs

• Networking constraints of traditional L2/L3
  hierarchical forwarding
• Fragmentation of resources (VLAN, subnetting)
• Limited server-to-server capacity (high
  oversubscription)
• Ethernet scalability (FIB size, STP, flooding,
  ARP broadcast)
• Low performance under cloud application traffic
  patterns
• Reliability 2 is a poor choice for redundancy at
  scale

36
iBF-based Data Center Networking

• Compactly represent a source route between ToRs
  using a Bloom filter
• Carry the 96-bit iBF in the source and
  destination MAC fields
• Stateless forwarding by querying next-hop
  switches in the iBF
• MAC re-writing at source and destination ToRs
  (per flow state reqs.)
• Benefits
• Large L2 domains, VM agility, app-specific
  load-balancing, resource-friendly...

37
Inter-Domain Multicast
38
Conclusions

• Summary of the contributions and future work

39
Conclusions

• Forwarding in content-oriented networks is
  challenging.
• This Thesis contributes to question the commonly
  held view that networking needs to be centred on
  endpoint (network interface) identifiers.
• The proposed compact forwarding methods explore a
  new avenue by relaxing the port forwarding
  function on arbitrary labels to tolerate extra
  outcomes - trading state for bandwidth
  efficiency.
• We have contributed to turn one-sided error data
  structures into practical forwarding components,
  paving the way for a correct, secure, and
  scalable content-oriented forwarding plane.

40
Contributions and Publications
41
Trabalhos Publicados Pelo Autor

• A. C. Esteve Rothenberg, F. Verdi and M.
  Magalhães. Towards a new generation of
  information-oriented internetworking
  architectures. In ACM CoNext, First Workshop on
  Re-Architecting the Internet (Re- Arch08), Dec.
  2008, Madrid, Spain.
• B. P. Jokela, A. Zahemszky, C. Esteve
  Rothenberg, S. Arianfar, and P. Nikander.
  LIPSIN Line Speed Publish/Subscribe
  Inter-Networkings. In ACM SIGCOMM09, Aug. 2009,
  Barcelona, Spain.
• C. A. Zahemszky, A. Császár, P. Nikander and C.
  Esteve Rothenberg. Exploring the Pub/Sub Routing
  Forwarding Space. In IEEE ICC, Workshop on the
  Network of The Future, Jun. 2009, Dresden,
  Germany.
• D. C. Esteve Rothenberg, P. Jokela, P.
  Nikander, M. Särela and J. Ylitalo. Self-routing
  Denial-of-Service Resistant Capabilities using
  In-packet Bloom Filters. In 5th European
  Conference on Computer Network Defense (EC2ND),
  Nov. 2009, Milan, Italy.
• 5. C. Esteve Rothenberg. Re-architecting the
  Cloud Data-Center Networks. In IEEE ComSoc
  Optical Networking Technical Committee (ONTC)
  Newsletter PRISM, Vol 1. No 2. March 2010.
• 6. F. L. Verdi, C. Esteve Rothenberg, R.
  Pasquini and M. F. Magalhães. Novas Arquiteturas
  de Data Center para Cloud Computing. Book
  Chapter, SBRC, Gramado, Brazil, May 2010
• E. C. Esteve Rothenberg, C. A. Macapuna, F.
  L. Verdi, M. F. Magalhães and A. Zahemszky. Data
  center networking with in-packet Bloom filters.
  In 28th Brazilian Symposium on Computer Networks
  (SBRC), Gramado, Brazil, May 2010.

42
Trabalhos Publicados Pelo Autor

• 8. A. Zahemszky, B. Gajic, C. Esteve Rothenberg,
  C. Reason, D. Trossen, D. Lagutin, J. Tuononen
  and K. Katsaros. Experimentally-driven research
  in publish/subscribe information-centric
  inter-networking. In Tridentcom 2010, May. 2010,
  Berlin, Germany.
• F. C. Esteve Rothenberg, C. A. Macapuna, F. L.
  Verdi and M. F. Magalhães. The Deletable Bloom
  Filter A new member of the Bloom family. In
  IEEE Communication Letters, June 2010.
• G. C. Esteve Rothenberg, C. A. Macapuna, F. L.
  Verdi, M. F. Magalhães and A. Wiesmaier.
  In-packet Bloom filters Design and networking
  applications. Accepted in Elsevier Computer
  Networks.
• M. Särela, C. Esteve Rothenberg, A. Zahemszky, J.
  Ött and P. Nikander. BloomCasting Security in
  Bloom ?lter based multicast. In Nordsec 2010,
  Oct. 2010, Espoo, Finland.
• M. Särela, C. Esteve Rothenberg, T. Aura, A.
  Zahemszky, J. Ött and P. Nikander. Forwarding
  Anomalies in Bloom Filter BasedMulticast.
  Accepted in IEEE Infocom 2011.
• 13. Carlos A. B. Macapuna, C. Esteve Rothenberg
  and M. F. Magalhães. "In-packet Bloom ?lter based
  data center networking with distributed OpenFlow
  controllers". In 2nd IEEE MENS 2010, Dec. 2010,
  Miami, Florida, USA
• 14. S. Tarkoma, C. Esteve Rothenberg and E.
  Lagerspetz. Theory and Practice of Probabilistic
  Filters for Distributed Systems. To appear in
  IEEE Communications Surveys and Tutorials..

43
Resultados de Propriedade Intelectual

• International Patent Application
  PCT/EP2008/063647, Patent Packet Forwarding in
  a Network, Applicant Ericsson AB, Publication
  number WO 2010/022799 (A1), Publication date
  2010-03-04, Date of Filing 2008-10-10,
  Inventors JOKELA, Petri, ESTEVE, Christian,
  KJÄLLMAN, Jimmy, NIKANDER, Pekka, RINTA-AHO,
  Teemu, YLITALO, Jukka,
• International Patent Application
  PCT/EP2009/062785, Patent Secure In-Packet
  Bloom ?lter applications, Applicant Ericsson
  AB, Date of Filing 2009-06-10, Inventors
  ESTEVE, Christian, JOKELA, Petri, NIKANDER,
  Pekka, SÄRELÄ, Mikko, YLITALO, Jukka.

44
Future work

• Active area of networking with iBFs
• GMPLS, mobility, inter-domain PURSUIT, optical
• Open questions E.g., DlBF dynamics (Keep doing
  insertion and deletions). Other compact and more
  flexible bitmaps?
• Explore more applications and networking
  scenarios
• SiBF Remove middlebox Bloomed Service IDs
  beyond VLB
• BloomCasting Remove AS edges (permutating
  DlBFs)
• CCN Relief the core from PIT entries with
  topology-carrying iBFs. SPSwitch engine for
  structured CCN names (e.g., a/b/c/d/hash) ?
• iBFs fault-carrying, multi-path, path
  information (e.g., measurements)
• Right balance between edge-, network- and packet
  state?
• Plus many broader architectural questions of
  content-oriented networks

45
Questions?
46
BACKUP
47
Compact forwarding in content-oriented networks

• Traditional Forwarding

• Compact Forwarding

• Scale by
• Structural aggregation(hierarchical IP)
• Timely information (e.g. Ethernet)
• Deterministic algorithms
• Forward on longest prefixes(e.g., Tree bitmap IP
  lookup)
• Exact lookup matches(e.g., MPLS, Ethernet)
• Focus on unicast
• Sender-oriented

• Scale by
• Synthetic aggregation (lossy compression)
• Trading state for over deliveries (flexible
  operation point)
• Moving (approximate) forwarding state to packets
• Probabilistic algorithms
• Trade correctness for space/time requirements
• Prone to one-sided errors (port-forwarding w/
  extra packet dups.)
• Focus on multicast
• Receiver-oriented

48
Principles in action
49
Observation

• Fundamentals of the Internet
• Collaboration
• Reflected in forwarding routing
• Cooperation
• Reflected in trust among participants
• Endpoint-centric services
• Mail, FTP, even Web
• Reflected in E2E principle

• Reality in the Internet
• Current economics favor senders
• Receivers are forced to carry the cost of
  unwanted traffic
• Phishing, spam, viruses
• There is no trust any more
• Information-centric services
• Do end-points really matter?
• Information retrieval through, e.g., CDNs, P2P

IP, full end-to-end reachability
IP with middleboxes significant decline in trust
Source EU FP7 PSIRP Project
50
SPSwitch forwarding engine
model implementation(FCF d-left hash Table)
Re-Arch08
Is packet label X in forwarding port P?
Problem Still O(n) entries
51
Practical fpr gains
52
False positive performance

• m bit array, k independent hash functions , n
  elements inserted
• Given m and a target capacity n, there is an
  optimal number of hash functions k ln2 m/n
• False positive rate depends solely on the ratio
  m/n
• fpr approx 0.61 m/n or approx 0.5 k
• Independently from the form/size of the elements

53
The revised main point of Bloom filters

• Whenever you have a set or list or function and
  space is an issue, an approximate representation,
  like a Bloom filter may be a useful alternative.
• Just be sure to consider the effects of the false
  positives!
• Ask the right question
• Is element x not in this set? No false negatives
• Is element x in this set? Handle low false
  positives
• M / n ratio determines false positive rate
• Elements can be potentially anything
• Node IDs, network paths, packets, domains,
  ontology trees, names, interfaces, signatures,
  etc.

54
Design Principles

• Separating Names from Locations
• IP for VM identification, pure L2 connectivity
• Source explicit routing with zero-overhead
• Stateless intermediate switching based on the iBF
• Direct network control and logically centralized
  directory
• Rack Managers install flows at ToRs and jointly
  maintain topology and server dir.
• Load balancing through path randomization
• Exploit path multiplicity to provide oblivious
  routing (i.e., traffic independent randomized
  packet routing) Valiant Load Balancing
• Unmodified end-points and plug play
• Legacy servers and applications are supported
  off-the-shelf.
• Auto-configuration of end-hosts and switches
  (Role Discovery Protocol)
• Design for failure
• Assume any component will fail (built-in
  fault-tolerance)

55
Traffic Efficiency Optimizations

• virtual links
• tunneling with tree/forest support
• created by topology layer when useful
• alternative link identifiers
• multiple identifier sets to choose from
• pick set with least false positives
• do-not-forward link identifiers
• included in forwarding identifiers
• requested downstream, created upstream

56
Security properties

• z-Filter works both as a forwarding ID and a
  capability
• To send, a host needs to know or guess a valid
  zFilter
• z-Formation
• Bound to the incoming and outgoing ports
• Traffic injection difficult (due to binding to
  incoming port)
• Very hard to construct one without knowing keys
  along the path
• Correlation attacks possible only for a given
  flow ID
• Bound to the packet stream (flow ID)
• Need a cryptographically good and fast Z algorithm

57
Injection attacks

• Assuming attacker knows a zFilter passing at h
  hops distance from attacker
• Left y-axis shows the probability of a single
  packet reaching target for various fill factors
• Right y-axis shows the average number of attempts
  for one successful injection with probability 0.5

58
Discussion

• Replay attacks limited to the key lifetime
• As zFilters are tied to periodically changing
  keys (K(t)), one per node, the capabilities
  become expirable
• Brute force attack Best attack strategy
• Assuming attack traffic of 1M pps (1Gbps / 1000
  bits pp) gt 40min to guess (with Pr0.5) one 5-hop
  working zFilter (which is only usable for single
  host)
• Re-keying time?
• Trade-off between minimizing duration of unwanted
  traffic vs. overhead of zFilter renewal e.g., 1
  min enough to complete transactional traffic
  protect short paths
• Attack detection and mitigation
• fpr increase triggers detection plus e.g.
  blacklist mechanism on FlowID

59
Challenges Approach

• Common challenge in data-oriented paradigms
• Take switching decisions
• at wire speed (Gbps)
• on a large universe (e.g., 256-bit hash values)
• of flat (non-aggregatable) identifiers
• A probabilistic approach
• Lets take advantage of the data-oriented
  paradigm
• Pub/sub inherently tolerates false positives
• Opportunistic caching

60
Secure iBF conclusions

• Can we deliver packets securely without
  addresses?
• z-Formation is a compact and secure source
  routing method
• Forwarding identifiers are
• small and efficient to compute
• Capability-like properties
• expirable,
• bound to packet flow,
• content/communication intention
• Stateless
• No need for per flow state
• Forwarding with zero FIB table lookups

61
Virtual links

• State in network nodes
• One-to-one, one-to-many, many-to-many,
  many-to-one forw. structures
• Supporting horizontal and/or hierarchical
  aggregation
• Less overdeliveries

62
RTFM Architecture

• Rendezvous Matches subscriptions to
  publications.
• Topology Creates and maintains delivery trees
  used for forwarding traffic.
• Forwarding Actual data delivery operations.
  (label switching and fast forwarding tables)
• Mediation Node-to-node link data transfer More
  (opportunistic caching, collaborative and
  network coding)
• Metadata and hash-based identifiers
• Identifiers space (approx.)
• 1015 rendezvous identifiers (256-bit RiD)
• 1010 scope identifiers (256-bit SiD)
• Forwarding identifies (256-bit FiD)

Särelä et al. 2008
63
Bloom filter fundamentals

• m bit array
• k independent hash functions
• Hash functions are Bloom Filters with k 1
• n elements inserted

Check_element() yes / no ?
Insert_element()
64
Forwarding Efficiency Optimizations

• virtual links
• tunneling with tree/forest support
• created by topology layer when useful
• alternative link identifiers
• multiple identifier sets to choose from
• pick set with least false positives
• do-not-forward link identifiers
• included in forwarding identifiers
• requested downstream, created upstream