Mobile Ad hoc Networks for JDA Overview of TBRPF

1
Mobile Ad hoc Networks for JDAOverview of TBRPF

• SRI International
• 333 Ravenswood AvenueMenlo Park, CA 94025
• Richard Ogier, ogier_at_erg.sri.com

2
JDA Requirements

• Low bandwidth
• Very low overhead (control traffic)
• Low latency (lt sec)
• Low-speed mobile nodes (troops and semi-mobile
  vehicles)
• Frequent topology changes and link failures due
  to mobility, buildings, interference/jamming,
  terrain, etc.
• detection of new neighbors and lost neighbors
  (link failures)
• rerouting around link failures
• 200 Nodes
• Applications
• Situational awareness (maps, images, text
  messages)
• Email, text and voice
• QoS and security required
• Devices PDAs or small notebook PCs

3
Overview of Activities in Wireless Networks

• Extensive research in routing and multicast
  protocols
• Long-term involvement in DARPAs Packet Radio
  Program
• Ground and airborne packet radio networks
• DARPA/CECOM Survivable Adaptive Networks (SURAN)
• System Engineering and Integration for DARPAs
  Global Mobile Information Systems (GloMo) program
• GloMo Advanced Secure Wireless Networks (ASWIN)
  project - Low overhead secure key distribution
  mechanisms
• DARPA SUO Enabling Technologies program -
  Developed an efficient and survivable routing
  protocol (Topology Broadcast with Reverse Path
  forwarding, TBRPF)
• MobileIP and IPv6/v4 compatible addressing
• Wireless networking experiments with unmanned
  helicopters and ground robots under Office of
  Naval Research UCAV program

4
First Mobile Wireless Packet Network22 November
1977
5
DoD Sponsorship of TBRPF

• Initial development of TBRPF concepts under DARPA
  SUO Enabling Technology Program and ASEO/CECOM
  supported TBRPFs initial implementation
• SRI funded Linux and Windows development, as well
  as latest version of TBRPF-PT and enhancements
• Undergoing evaluation at Army CECOM Protocol
  Investigation for the Next Generation (PING) Lab
  (Free BSD and Linux versions)
• Emphasis on mobility group collaborative
  communications
• Component of Army CECOMs wireless IPv6 research
  initiative
• Actively pursuing standardization within IETF
  MANET with support from ASEO/CECOM

6
SRIs Implementation Experience

• SRI has over 30 years experience in the research
  and development of mobile packet radio networks.
• TBRPF has been tested extensively in mobile
  networks of helicopters, ground robots, and
  hand-held nodes.
• Our TBRPF implementations use IEEE 802.11
• Extensive simulation experience with OPNET and
  ns-2.

7
Commercial Sponsorship

• SRI licensed technology and performed software
  development for SpeedCom Wireless NASDAQ SPWC
  of Bradenton, Florida USA
• Wireless bridge router for 2.4GHz unlicensed
  spectrum
• 9000 series product using TBRPF was launched in
  June 2002

PacketHop (SRIs trade name for TBRPF) is a
routing technology that allows point to
multipoint network nodes to use each other as
relay points when there is no direct LOS to a
central node. We believe this technology is the
only one of its kind and will help SpeedCom carve
out a defensible position in the wireless access
space over the long term. Kaufman Bros. Market
Analysis
8
Overview of TBRPF

• TBRPF (Topology Broadcast Based on Reverse-Path
  Forwarding) is a proactive, link-state routing
  protocol.
• Submitted to IETF MANET working group, where it
  has been improved based on feedback from the
  group.
• TBRPF-FT (Full Topology)
• Each node is provided with the state of every
  link in the network.
• Useful for sparse topologies and when full
  topology information is useful, e.g., for QoS
  routing.
• TBRPF-PT (Partial Topology)
• Each node is provided with only enough
  information to compute min-hop paths to all other
  nodes.
• Useful for dense topologies and for very large
  networks.

9
TBRPF Modules

• TBRPF is divided into the following modules
• Neighbor discovery
• Performs the detection of new and lost neighbors.
• Topology discovery and routing
• Provides sufficient topology and link-state
  information to each node to allow the selection
  of shortest paths and alternate paths to each
  destination.
• Forwards packets based on topology information.

10
TBRPF Neighbor Discovery

• TBRPF neighbor discovery is modular - performs
  only neighbor discovery. Thus, TBRPF neighbor
  discovery can be used alone or with another
  routing protocol.
• TBRPF neighbor discovery uses differential Hello
  messages that report only changes in neighbor
  states, resulting in much smaller Hellos than
  other protocols such as OSPF (which use full
  Hellos).
• Smaller Hellos can be sent more frequently,
  resulting in faster detection of new and lost
  neighbors.
• When a neighbor changes state, its ID is included
  in at most NBR_HOLD_COUNT (e.g., 3) consecutive
  HELLOs, in one of three lists
• NEIGHBOR REQUEST, NEIGHBOR REPLY, NEIGHBOR LOST
• Main idea The neighbor will either hear about
  the state change, or will miss NBR_HOLD_COUNT
  consecutive HELLOs and declare the link LOST.

11
Example of neighbor discovery
A
B
HELLO
1-WAY
NEIGHBOR REQUEST
1-WAY
2-WAY
NEIGHBOR REPLY
2-WAY
2-WAY
12
TBRPF Neighbor Discovery (cont.)

• Hysteresis NBR_ACQUIRE_COUNT (e.g., 2) of the
  last NBR_ACQUIRE_WINDOW (e.g., 3) HELLOs must be
  received from a new neighbor before accepting it.
• Hysteresis can be tuned to acquire a new neighbor
  more quickly (and to detect the loss of a
  neighbor more quickly) if the neighbor is moving
  in the opposite direction. (E.g., set
  NBR_ACQUIRE_COUNT 1.)
• A link failure (loss of a neighbor) is detected
  if NBR_HOLD_COUNT (e.g., 3) Hellos are missed or
  if no Hello is received for NBR_HOLD_TIME.
• Link-layer detection of link failures (provided
  by 802.11) can be used for faster detection of
  lost neighbors.

13
TBRPF Neighbor Discovery (cont.)

• Requirements met
• Low message overhead (roughly 80 lower than full
  Hellos for 100 neighbors)
• Scalable (can support more neighbors, roughly
  1000 for 802.11a)
• Fast neighbor acquisition can vary from
  HELLO_INTERVAL (typically 0.25 to 1 second) to a
  few times HELLO_INTERVAL, depending on hysteresis
  parameters.
• Fast detection of link failures (lost neighbors)
  can range from a few msec with link-layer
  detection, to a few Hello intervals.
• Future work
• Include geolocation and velocity information in
  Hellos.
• Use power control to limit number of neighbors
  (does not require any change to neighbor
  discovery protocol).
• Experiment to determine best choice for
  hysteresis parameters.

14
TBRPF Topology Discovery

• Each node maintains a routing graph, which is
  flexible as shown below. TBRPF minimizes routing
  overhead by having each node report only part of
  its routing graph to neighbors, in periodic and
  differential updates.
• A nodes routing graph can consist of any the
  following
• the nodes source tree, providing a shortest path
  to each destination (minimum topology)
• a biconnected subgraph, providing two disjoint
  paths to each destination for improved robustness
• the full topology (all network links).
• This flexibility allows additional topology
  information to be reported to increase robustness
  when sufficient bandwidth exists.
• A mixture is possible the routing graph can
  consist of full topology up to K hops, and only
  shortest paths beyond K hops.

15
TBRPF Topology Discovery (cont.)

• TBRPF allows link metrics to be included in
  topology updates, to allow the computation of
  higher-quality paths than can be obtained by
  simply computing min-hop paths. For example,
  metrics can be based on signal strength,
  stability, reliability, bandwidth, delay, power,
  etc. Link metrics can be used to provide QoS
  routing.
• In TBRPF, each node can have multiple interfaces
  (e.g., can use multiple IEEE 802.11 cards), where
  each interface can be wireless or wired. TBRPF
  also supports associated hosts and network
  prefixes, which allows communication with
  external networks.
• TBRPF has been extended to provide efficient
  flooding (or network-wide broadcast) of packets
  to all nodes of a connected ad-hoc network, and
  to provide efficient multicasting of packets to
  subsets of nodes.
• TBRPF has been shown in simulations to support a
  200 nodes with a 2 Mbps channel. Using
  hierarchical routing, TBRPF can support several
  thousand nodes.

16
TBRPF Topology Discovery (cont.)

• Each node computes its source tree T (or more
  generally, its routing graph) using a variation
  of Dijkstras algorithm, which also updates the
  topology graph TG (consisting of believable
  links)
• A link (u,v) is believable (is in TG) only if it
  is reported by the next hop p(u) on the shortest
  path to node u.
• Each node i reports, in periodic and differential
  updates, its reportable subgraph, which includes
  its links to neighbors, and includes link (u,v)
  of its routing graph iff node i determines that
  node i is the next hop of some neighbor to reach
  the neighbor p(u).
• As a result, each node reports only a relatively
  small part of its routing graph.
• To accomplish this, each node computes the
  min-hop paths from each neighbor to each other
  neighbor. When there are multiple min-hop paths,
  tie is broken using node ID.

17
Example illustrating TBRPF (minimum topology)
9
Node 2 selects itself as parent for sources 7, 3,
11.
6
7
8
5
4
2
3
1
As a result, node 2 reports its entire routing
graph, while nodes 6 and 10 report only a small
part of their routing graphs.
13
12
10
11
15
14
Node 2s reportable subtree
Node 6s reportable subtree
Node 10s reportable subtree
18
Example illustrating TBRPF (minimum topology)
Link (12, 15) breaks, so node 2 adds link (14,
15) to its routing graph.
9
6
7
8
5
4
2
3
1
13
Node 2 reports this change to its reportable
subgraph to all neighbors in a Topology Update
message.
12
10
11
BREAK
15
14
Node 2s reportable subtree
Add (14, 15) reported by node 2.
Node 6s reportable subtree
Node 10s reportable subtree
19
Example illustrating TBRPF (minimum topology)
9
The path computed by node 1 to node 5 is shown in
red.
6
7
8
5
4
2
3
1
13
12
Node 1 forwards packets with dest 5 to node 2.
10
11
15
14
Node 2s reportable subtree
Node 6s reportable subtree
Node 10s reportable subtree
20
Example illustrating TBRPF (minimum topology)
9
Link (1,2) breaks. Node 1 immediately reroutes
thru node 6
6
7
8
5
4
2
3
1
BREAK
13
12
10
and sends a New Parent msg, adding node 6 as
parent for source 3.
11
15
14
Node 2s reportable subtree
Node 6s reportable subtree
Node 10s reportable subtree
21
Example illustrating TBRPF (minimum topology)
9
Nodes 6 and 10 add links to their reportable
subgraphs.
6
7
8
5
4
2
3
1
BREAK
13
12
10
Node 2 no longer reports these links, after node
3 deletes node 2 as parent.
11
15
14
Node 2s reportable subtree
Node 6s reportable subtree
Node 10s reportable subtree
22
Example illustrating TBRPF (full topology)
9
Nodes 6 and 10 add links to their reportable
subgraphs.
6
7
8
5
4
2
3
1
BREAK
13
12
10
Node 2 no longer reports these links, after node
3 deletes node 2 as parent.
11
15
14
Node 2s reportable subgraph
Node 6s reportable subgraph
Node 10s reportable subgraph
23
Periodic Updates vs. Reliable Updates

• The latest version of TBRPF (described in the
  Internet-Draft) uses periodic topology updates
  (e..g, every 5 sec), which is the most efficient
  method when the topology changes frequently.
• The original version of TBRPF (full topology)
  uses reliable, event-triggered updates instead of
  periodic updates, which is more efficient when
  the topology does not change frequently.
• Both versions of TBRPF are currently implemented.
• For networks with very low bandwidth radios that
  do not have frequent topology changes, it may be
  best to modify TBRPF-PT to use reliable topology
  updates.

24
TBRPF Topology Discovery (concluded)

• Requirements met
• Low message overhead (control traffic)
• Low end-to-end delay
• Scalable
• Fast response to topology changes
• Future work
• Modify protocols and parameters for very low
  bandwidth radios (use reliable updates).
• Will add relay priority - nodes with high value
  are more likely to relay packets.
• Will add authentication to TBRPF packets.
• Routing when no path currently exists to the
  destination A node can forward packets to one
  or more neighbors that can carry the packets
  until they move to a position that provides a
  route to the destination.

25
TBRPF Flooding Mechanism

• Used for best-effort flooding (or network-wide
  broadcast) of packets to all nodes of a connected
  ad-hoc network.
• Uses information computed by TBRPF to achieve
  greater efficiency than full (classical)
  flooding.
• A duplicate cache is maintained so that a node
  does not forward the same packet more than once.
• A non-duplicate packet is forwarded only if the
  source IP address of the packet belongs to the
  set RN of reportable nodes computed by TBRPF.
• If a packet is to be forwarded, it is transmitted
  on all interfaces, with the following exception
  if the packet was received on an interface that
  is NOT an ad-hoc interface, then the packet need
  not be transmitted on that interface.

26
SRI IP Status Pending Patents

• MOBILE AD HOC EXTENSIONS FOR THE INTERNET by
  Ogier et al.
• A SYSTEM AND METHOD FOR DISSEMINATING TOPOLOGY
  AND LINK-STATEINFORMATION TO ROUTING NODES IN A
  MOBILE AD HOC NETWORK by Ogier
• 3) A REDUCED-OVERHEAD PROTOCOL FOR DISCOVERING
  NEW NEIGHBOR NODES ANDDETECTING THE LOSS OF
  EXISTING NEIGHBOR NODES IN A NETWORK by Ogier
• AN IPv6-IPv4 COMPATIBILITY AGGREGATABLE GLOBAL
  UNICAST ADDRESS FORMATFOR INCREMENTAL DEPLOYMENT
  OF IPv6 NODES WITHIN IPv4 NETWORKS by Templin
  (also called ISATAP - has been submitted to IETF
  for standardization). 
• A PER HOP BEHAVIOR FOR DIFFERENTIATED SERVICES IN
  MOBILE AD HOCWIRELESS NETWORKS by Sastry et al.
• SCHEDULING MECHANISMS FOR USE IN MOBILE AD HOC
  WIRELESS NETWORKS FORACHIEVING A DIFFERENTIATED
  SERVICES PER-HOP BEHAVIOR by Ogier et al.
• AN EFFICIENT LINK-STATE PROTOCOL FOR MOBILE
  WIRELESS NETWORKS by Ogier
• A LOW-OVERHEAD NEIGHBOR DISCOVERY PROTOCOL FOR
  MOBILE AD HOC NETWORKS by Ogier

27
IETF MANET Standardization

• Two types of MANET routing protocols
• On-demand
• discovers a route only when needed, by flooding
  route-request messages throughout the network
• Proactive
• proactively maintains routes to all destinations
• Possible downselect to 1 On Demand and 1
  Proactive protocol for RFC expected early 2003
• Final standardization expected in 2004

28
Advantages of Proactive vs. On-demand

• Proactive routing has been shown to be more
  efficient (in terms of bandwidth utilization and
  power consumption) than on-demand routing when
• A large percentage of nodes are traffic sources
• The traffic destinations change frequently (short
  sessions)
• Proactive routing incurs smaller end-to-end delay
  (latency) since routes are ready when needed
  (on-demand protocols incur delays to discover new
  routes)
• Proactive protocols find shorter routes
  (simulations show that paths found by AODV are
  10-20 longer than those found by TBRPF)
• Proactive protocols have faster rerouting around
  link failures, since proactive protocols maintain
  at least one optimal path to each destination at
  all times and alternate routes are always
  maintained.
• QoS routing can be accomplished with proactive
  protocols by advertising multiple link metrics.

29
Simulation Results
30
Protocols Simulated

• AODV - for ns-2.1b8a
• Available from http//www.cs.ucsb.edu/eroyer/aodv
  .html
• TBRPF - for ns-2.1b8 (compliant with version 04
  draft)
• Available from http//www.erg.sri.com/projects/tbr
  pf/sourcecode.html
• Uses same C module as our Linux implementation.
• OLSR - for ns-2.1b7 (compliant with version 03
  draft)
• Available from http//hipercom.inria.fr/olsr/
• Bug affecting packet size was fixed.
• In all protocols, link-layer failure notification
  was NOT used, and packets could not be retrieved
  from the link layer (interface queue).
• ARP was bypassed for both TBRPF and OLSR, since
  MAC addresses can be obtained from received
  routing packets.

31
Simulation Model

• ns-2 version 2.1b8
• WaveLAN IEEE 802.11 MAC with rate 2Mb/s and range
  250m
• 100 nodes
• Two area sizes 670m x 670m and 1500m x 300m
• Mobility model Random waypoint model with 0
  pause time and maximum speed 20 m/s.
• 20 simultaneous CBR traffic streams
• Source and destination of each stream are
  selected randomly
• Duration of each stream is 30 seconds
• Size of each data packet is 512 bytes
• Packet generation rate per stream is increased
  from 2 to 8 packets/s
• Each simulation was run for 500 simulated seconds.

32
Performance Measures

• The following measures were plotted for
  increasing packet generation rates
• percent of data packets delivered
• average end-to-end delay
• total routing control traffic in kbytes,
  including IP/MAC headers (divide by 500 to get
  kbytes/sec).
• normalized path length (average ratio of actual
  hops to minimum hops)

33
Simulation comparison of TBRPF, OLSR, and
AODV100 nodes, 20 sources, 670x670 area, max
speed 20mps
DELAY
PERCENT DELIVERED
ROUTING LOAD
PATH LENGTH
34
Simulation comparison of TBRPF, OLSR, and
AODV100 nodes, 20 sources, 1500x300 area, max
speed 20mps
DELAY
PERCENT DELIVERED
ROUTING LOAD
PATH LENGTH
35
Simulation comparison of TBRPF, OLSR, and
AODV100 nodes, 20 sources, 670x670 area, no
mobility
DELAY
PERCENT DELIVERED
ROUTING LOAD
PATH LENGTH
36
Simulation comparison of TBRPF, OLSR, and
AODV100 nodes, 20 sources, 1500x300 area, no
mobility
DELAY
PERCENT DELIVERED
ROUTING LOAD
PATH LENGTH
37
Summary of simulation results

• In every scenario, TBRPF achieved a higher
  delivery percentage (up to 15 higher) than OLSR.
  TBRPF also achieved a higher delivery percentage
  (up to 15 higher) than AODV in all scenarios
  with no mobility, and in all scenarios using the
  square (670x670) area with the lower packet rates
  (2 and 4 packets/s). For the long rectangular
  (1500x300) area, AODV achieved a higher delivery
  percentage (up to 5 higher) than TBRPF.
• In every scenario, TBRPF generated less routing
  control traffic than the other protocols up to
  60 less than OLSR and up to 48 less than AODV.
  This is despite the fact that TBRPF sends HELLOs
  twice as frequently as OLSR.
• In every scenario, TBRPF used the shortest paths
  (except nearly shortest in some cases with the
  higher packet rates). In every scenario, AODV
  used paths that were 12-20 longer on average
  than TBRPF.
• TBRPF usually had the best or nearly best delay.

38
Remarks

• This study did not use link-layer notification.
  It is important to also compare the protocols
  with link-layer notification, since this allows
  one to achieve a delivery fraction close to 100.
  
• A comparison of TBRPF with AODV using link-layer
  notification follows.
• Although control traffic is not a
  quality-of-service measure, a routing protocol
  that generates less control traffic and uses
  shorter paths
• uses less energy,
• is more likely to scale to a larger number of
  nodes,
• is more likely to perform well in lower bandwidth
  radios such as those used by the military.

39
Simulation results for TBRPF and AODV With link
layer failure notification
40
Protocols Simulated

• AODV - CMU Monarch extensions, 12/07/2000.
• With link-layer failure notification
• Without local repair
• TBRPF - version 04 (current). Same code used for
  implementation was interfaced to ns-2 using our
  API.
• With link-layer failure notification
• Packets with no route are buffered for up to 5
  seconds.
• ARP was not used, since MAC addresses can be
  obtained from received routing packets.

41
Simulation Model

• ns-2 with CMU Monarch extensions
• WaveLAN IEEE 802.11 MAC with rate 2Mb/s and range
  250m
• 100 nodes
• Two area sizes 670m x 670m and 1500m x 300m
• Mobility model Random waypoint model with 0
  pause time and maximum speed 20 m/s.
• 40 CBR sources each source changed its
  destination randomly every 30 s.
• The following measures were plotted for
  increasing packet generation rates
• percent of packets delivered
• average end-to-end delay
• routing load in kbytes, including IP/MAC headers.
• path length (average hops, or ratio to optimal
  when available)

42
Simulation comparison of TBRPF and AODV100
nodes, 40 sources, 670x670 area, max speed 20mps
DELAY
PERCENT DELIVERED
Delay for AODV is based on fewer packets.
ROUTING LOAD
PATH LENGTH
43
Simulation comparison of TBRPF and AODV100
nodes, 40 sources, 1500x300 area, max speed 20mps
DELAY
PERCENT DELIVERED
ROUTING LOAD
PATH LENGTH
44
Summary of simulation results

• TBRPF consistently achieved close to 100
  delivery fraction when the network was not
  congested.
• Congestion occurred with approx. 3 packets/source
  at 40 CBR sources
• TBRPF consistently outperformed AODV, and had a
  significantly (about 10) higher delivery
  fraction for the 1500x300 area for 100 nodes.
• TBRPF consistently used the shortest paths,
  typically 10-15 shorter than for AODV.
• In every scenario, TBRPF generated less routing
  control traffic than AODV (up to 70 less).

45
Concluding Remarks about TBRPF

• TBRPF is a mature ad hoc network protocol,
  extensively tested both in the laboratory and in
  the field
• Simulations show that TBRPF is the best
  performing and most efficient of the routing
  protocols being considered by IETF MANET Working
  Group.
• TBRPF is integrated with ISATAP, MobileIPv6, and
  multicasting and is thus a fully functioning
  system with Internet connectivity not just a
  stand alone ad hoc network protocol
• TBRPF currently works with 802.11 but can work
  with other radios as well.
• Additional work on extensions in the areas such
  as QoS-based routing and fault-tolerant routing
  is currently underway

46
Other Technologies for JDA Mobile Wireless
Networks

• Multicasting
• Security
• QoS
• Power management

47
Multicast Extensions to TBRPF

• Based on DVMRP (Distance Vector Multicast Routing
  Protocol), since this is the most natural way to
  extend TBRPF to multicast routing.
• The main idea of DVMRP is that the first packet
  sent from a source to a multicast group is
  broadcast to all routers on the broadcast tree
  rooted at the source, and then
• routers that do not wish to receive packets for
  that group send PRUNE messages to remove
  themselves from the tree.
• pruned routers that wish to join the group send
  GRAFT messages to add themselves to the tree.
• The DV part of DVMRP computes the parents and
  children for each source, which are already
  computed by TBRPF. We therefore omitted this
  part of DVMRP, resulting in a considerable
  savings in control traffic.
• In addition, modifications were made to DVMRP to
  reduce the number of control messages sent in
  response to topology changes.

48
Multicast Extensions to TBRPF (cont.)

• These variables are updated in response to
  topology changes, group membership changes,
  routing changes, the reception of NEW PARENT,
  CANCEL PARENT, PRUNE, and GRAFT messages, and the
  reception of unwanted multicast packets.
• In addition, prune states expire after some time,
  to avoid maintaining state for (source, group)
  pairs that have been inactive for a long time.
• Messages sent (in addition to those already sent
  by TBRPF)
• PRUNE(source, group, prune_life) message Sent to
  the parent to prune the local router from the
  multicast tree for (source, group).
• GRAFT(source, group) message Sent to the parent
  to add the local router to the multicast tree for
  (source, group).

49
Example of TBRPF Multicast
G
G
NEW PARENT
PRUNE
GRAFT
Source

• A received multicast packet for the pair (source,
  group) is forwarded if
• The packet is not a duplicate (as determined by
  unique packet identifier)
• The router is not pruned from the multicast
  tree for (source, group)
• The router is not a leaf of the multicast tree
  for (source,group)

50
Rules for Sending PRUNEs and GRAFTs

• Node i sends a PRUNE message for (source, group)
  to p_i(source) when
• node i receives a multicast packet for (source,
  group), and is a leaf of the multicast tree for
  (source, group), and is not a member of group, or
• node i receives a PRUNE message for (source,
  group) from a child in children_i(source) and has
  no remaining unpruned children (becomes a leaf),
  and is not a member of group.
• Node i sends a GRAFT message for (source, group)
  to p_i(source) when
• the local host at node i joins group and node i
  is pruned for (source, group), or
• node i receives a GRAFT message for (source,
  group) from a child, and is pruned for (source,
  group), or
• node i receives a NEW PARENT message (from a new
  child), and is pruned for (source, group).
• In an enhancement, a GRAFT is not sent if the
  new child is pruned for (source, group) when it
  sent the NEW PARENT message.

51
EnclavesSecure Group Communications
52
Context

• Wired and Wireless LANs and WANs will be
  pervasively deployed
• Communications IS the killer
• Ad-hoc, dynamic, networks and group
  collaboration, messaging, file-sharing, internet
• Teens are fastest growing users of Nextel IDEN
  (push-to-talk) service
• P2P provides interesting capabilities, but
  high-value and private information will not be
  send over P2P networks unless security and
  privacy are provided
• Need to provide Virtual Private Networks over P2P
  networks of the future
• Very large dynamic ad-hoc networks
• Many overlapping small, medium, and large VPNs
• Provide for both centrally managed and
  distributed security admin and policies
• Standard security technology is not sufficient
• Best practice today wireless today (Strong
  authentication, VPN and IDS) requires highly
  trained staff
• Wireless even more vulnerable then wired

53
SRIs Current Enclaves

• Lightweight, Software-Based Virtual Private
  Networks
• Middleware for building secure groupware
  applications
• Support collaboration between users
• Provides means to construct and maintain a secure
  multicast channel between group members
• Protocols to authenticate and accept new members
• Crypto for secrecy and integrity of communication
• Group and key management services
• Intrusion-Tolerant Architecture
• Byzantine fault-tolerant coordination protocols
• Verifiable secret sharing
• No single point of failure
• Group management performed by N distributed
  leaders
• Tolerates failures

54
New! Dynamic Enclaves (under development)

• Scalable
• Robust
• Ad-hoc
• Dynamic
• Security for Useres, Devices, Services and
  Transactions
• Drag and drop security