Customisable Identifiers

1
Customisable Identifiers

• Manolis Sifalakis
• mjs_at_comp.lancs.ac.uk

2
Abstract

• In this presentation the idea of generating
  customised identifiers is promoted. Whether the
  identifiers are used to identify nodes, code
  modules, or other functional elements, the
  identifier space used can be optimised to include
  semantics that will assist and better the routing
  and network processing within the design space.
  In this presentation we consider one possible way
  of integrating the wanted semantics in the
  identifiers.
• One example where this is partly realised is IPv6
  address format where the site local part of the
  address is left to the address space owner to
  customise, whilst the TLD and SLD semantics
  remain "hard coded" in it. Algebraic operations
  like the one proposed here can be used to
  intcorporate site specific semantics. Then, these
  semantics (be it device type, geo location, link
  type, etc) can be easily taken into account by
  custom intra-site routing/forwarding algorithms
  to optimise their performance.

3
Overview

• Properties of a potentially Autonomic Network
• Customisability is of key importance for
  Autonomic Networks
• Lessons and realisations from the Internet
  experience
• That we may want to keep in mind when designing
  Aut. Networks.
• Need for an Identifier Abstraction Framework (?)
• The S-Identifier framework Idea
• Example case study
• Applications
• 2DO List

4
Properties of an Autonomic network

• Autonomic as a living being or a control system
  that can recover from instability ?
• Self-configurability
• From zero initial state (bootstrap)
• Driven by policies/heuristics/high level goals
• Capacity for Adaptability
• Flexible/extensible/open design to adapt or
  extend functionality
• Reactiveness
• Sense/measure-gtreact cycle, based on
  built-in/learned knowledge
• Customisability
• Modify its operational semantics and properties
• To always satisfy the goals and policies of its
  design space
• Self-management
• Act in response to external conditions/policies/in
  ternal state and customise the self, w/o human
  intervention

5
Autonomic Nets f (Customisability)

• At the network layer customise
• Identifier semantics
• Location semantics
• Topology
• Routing/forwarding functions
• What drives customisability
• Physical environment, mission, app/service
  requirements, policies
• Examples (how can these aspects be optimised)
• A wired structured IP network
• An mobile adhoc flat addressed IP-less network
• A set of ICs on a PCI Express network
• A structured fixed low-power sensor network

6
Lessons learned so far

• Addressing and the address space structure
  influence the routing topology
• in structured networks
• Proximity in the address space does not always
  imply routing/path proximity
• however it often does in the case for
  hierarchical address spaces
• Locality is important when mapping one address
  space on another
• to avoid unnecessary traffic and routing overhead
• Uniform/universal identifiers are good for
• abstracting from underlying technology
  dependencies
• providing a common abstraction for all overlying
  functions/apps

7
More lessons learned

• However, universal does not mean global. Global
  identifiers are no good
• Rigid, non adaptive
• A change/modification can take years/decades to
  employ
• Hard to (re-)define or change an allocation
  strategy
• Think of classfull allocation versus CIDR and
  hierarchical versus flat allocation
• Often Inefficient
• Think of the number of bits required/wasted in
  IPv6 to make it global so as to accommodate
  different semantics (TLD hierarchy, flat link
  layer addresses)
• Hard to tailor its semantics to
  problem/environment/function requirements
• Semantics determine the algorithms for routing
  etc.
• Different problems have different semantics.
• Global semantics sacrifice efficiency/effectivenes
  s of the routing and other functions to be generic

8
Key points so far

• Customisability
• Universal Not Global Identifiers
• Different Semantics expressed in Identifiers
• That in turn allow to optimise network
  functionalities

9
An Identifier Abstraction Framework

• Help abstract applications and services from the
  routing infrastructure semantics
• Not isolate though (we dont want to restrict
  interactions)
• Below any custom routing/switching technology
  provides a network transport
• Universal identifiers
• Not Global identifiers!
• Just namespaces
• And locally scoped IDs
• Customisable semantics

10
Not yet another network transport

• It is not IP
• Yes, universal but NOT global
• However, includes namespace scoping
• It is not another overlay system
• Does NOT impose routing/forwarding semantics
• But, common identifier space over any overlay
  (structured or not) system

11
The idea

• An internetwork comprises by a set of custom
  routing infras (compartments, turfs, clusters,
  domains)
• Network transport, topology, structure,
  connectivity patterns
• Within each domain IDs are generated by algebraic
  functions that combine various amortisable
  semantics S(emantic)-functions
• Interdomain semantics ? Intradomain semantics
• Interdomain AS-num, physical coordinates,
  subnet, device type,
• Intradomain hash key, LL address, IP address,
• Addressing across domains uses namespace
  specifiers (as in C)
• Again routing is left undefined at this level
• Dynamic binding principles can attach a
  specific forwarding or packet processing function
  within a domain or across domains
• Seen before in IPv6 but not quite the same
  (address scopes, opt hdrs)
• The semantics (even the intradomain ones) are
  fixed
• IPv6 defines global functions for routing.

12
Start simple case study

• Include locality semantics
• (S-function) S (x) a ? N(x) ? (1 - a) ?
  H(x), 0 a 1
• x network transport address N(x) Normalizing
  function
• a amortizing coefficient H(x) Randomizing
  function
• ? mul/add/concat/etc
• Advantages
• Universal identifier space for any overlay system
• Apps always perceive the same interface for
  addressing and identifying nodes or clusters of
  nodes
• Controls locality and removes dependency from p2p
  adhoc mechanisms, and potentially small-worldiness

13
How does it work ?

• S-IDs map to transport addresses N(x)
• S-IDs map to other semantics H(x)
• location, domain info, AS-num, transport type
• Amortising coefficient a regulates the effects
  of the two contradicting factors
• Identifiers can identify nodes or groups of nodes

14
S-IDs Example

• IPv4 network transport, ? arithmetic addition,
  H(x) returns a random number from an IP address,
  N(x) masks IP address to its /28 netmask.

• x-axis continuous block of IP addresses

15
S-IDs Example Varying a
a ??nx? px (1-p) n-x (Binomial cumulative
function)
16
S-IDs Example Varying a
a x/n ?e-?x (Exponential function)
17
S-IDs Example Varying a
a 1-(2/s(?2p)) e-(x-µ)2 / 2s2 (Inv. Gaussian
based function)
18
Effects

• Per-domain customisation of locality
• Responsibility offloaded from the routing system
  (overlay, p2p or other protocol)
• Can improve proximity estimation in structured
  overlays w/o requiring landmarks, additional
  signalling traffic or long convergence periods
• Promotes per-domain selection of custom data
  transport
• Independence of network transport identifiers
• In case of structured transport ID-spaces may
  influence Small World effect
• In a way that maps to the network topology
  (unlike most overlay systems currently)

19
Application in SAND

• Directory service for discovering active
  resources
• Scalable, Customisable, Distributed, Dynamic
• Why
• What can the network do for me (my flow) ?
• Enable/better the e3e service provisioning
• What can I do for the network ?
• Virtualise my network role/identity integrate
  new functions
• Support the self-association process
• Leverage the formation of autonomic topologies
• Where
• Along a data path
• Along-side a data path
• Within a neighbourhood

20
SAND Client Interface

• Along the data path
• FindResources ((L1, L2, L3), FilterSpec(EEJava))
• Along all possible data paths between endnodes
• FindResources ((L1, , L3), FilterSpec(EEJava))
• Along side the data path
• FindResources ((L1, , L3), FilterSpec(EEJava
  DistHop5))
• Within a network neighborhood
• FindResources ((L1), FilterSpec(FunctionMIPv6
  HA))
• FindResources ((L1), FilterSpec(FunctionMIPv6
  HA))

21
Breaking down the problem
ltPgt
Resource Discovery
ltFilterSpecgt
SAND Arch.
Resource Specification (WHAT)
Directory Layer
S-ID Abstraction Layer
Location Specification (WHERE)
22
Other applications

• Aspect of customisation in p2p systems
• Unified addressing/interfacing between
  heterogeneous networks
• Imagine an IP node communicating with an IC on a
  PCI express board
• Improve routing resilience (?)
• Promote small worlds

23
Current 2Do List

• Effect on locality (routing and traffic overhead)
• Pastry
• Compare with previous work on locality
• Impact on the small-world effect
• Generate some topologies
• Use pastry or other overlay systems with S-IDs
• Measure using Watt-Strogatzs(1) metrics the
  impact on overlay topology creation
• (1) D. J. Watts, S. H. Strogatz, "Collective
  dynamics of 'small-world' networks", Nature 393,
  1998

24
Thanks for the patience