Aucun titre de diapositive

1
IP MULTICAST OPTIMISATION BASED ON GEOGRAPHICAL
LOCATION
Patrice GUIVARCH Centre délectronique de
larmement (Celar) patrice.guivarch_at_dga.defense.go
uv.fr
2
Introduction 1/2

• Context
• Theatre of operations, Disaster (e.g. cyclone,
  earthquake)
• No networks infrastructures are no more usable
  for different reasons damaged, overloaded
• Operational communications among deployed forces
  on the scene or on the theatre of operations rely
  on Mobile Ad-hoc NETwork (MANET)

3
Introduction 2/2

• Unicast traffic is bandwidth consumer and
  inappropriate for distribution of alarms to
  inform the members of a specific
  Community-of-Interest (CoI)
• Using multicast technologies permit to quickly
  inform a CoI while limiting the bandwidth
  consumption
• The approach proposed will permit to send a
  multicast flow to recipients belonging to a same
  CoI deployed within a given geographical area.
  This distribution based on geographical location
  is commonly referred to as geographical broadcast
  (geocast).

4
Main assumptions

• The geocast region is circumscribed to a circle.
  As a result, the scope of the multicast
  distribution can be given by a unique value, the
  radius of the circle.
• All the mobile nodes on the field continuously
  know their location (longitude, latitude, and
  altitude).
• Given by Global Navigation Satellites Systems
  (e.g. GPS, Galileo)
• Estimated using methods of determining relative
  positions
• A multicast routing protocol is running on the
  theatre and, as a result, in the potential
  geocast regions
• Between headquarters and the theatre, usually,
  only a unicast routing is available.

5
Case A the multicast source is within the
geocast region

• The originator of the multicast flow wants to
  share information with some CoI members located
  within a given distance to him.
• The distance (scope) is set by the source

6
Case B the multicast source is outside the
geocast region

• The source is not within the geocast region.
• At least, a unicast routing is supposed to run
  between the target area and the source.
• The main issue consists in appointing one CoI
  member located close to the centre of the geocast
  area, and sending to it the multicast flow
  through the unicast network.

7
Location of the Geocast Information

• Trend in military networks
• End to end IP encryption
• Protected Core Network concept
• The location information can not be managed by
  the application layer. This information must be
  carried by the IP layer.
• Focus on IPv6 protocol

8
Location of the Geocast Information

• In the IPv6 header, several fields could
  participate to circumscribe multicast flows by
  carrying the information of distance to the
  source, the location of nodes or both. These
  fields are
• The hop limit
• The scope field in multicast address
• The flow label
• The header extensions

9
Location of the Geocast InformationIPv6
Candidate fields

• The hop limit
• Based on the hop count regardless of the real
  distance between group members
• The flow label
• Used to uniquely identify specified network
  flows. This capability will be used to improve
  end to end connectivity and quality of service
• The header extensions
• Used to carry fields
• for special purposes (e.g. source routing,
  security)
• only processed when appropriate
• New extension headers could be defined to meet
  the needs of new services or new requirements

10
Location of the Geocast InformationIPv6
Candidate fields

• The scope field in multicast address
• 16 values available
• Pre-defined values
• 1, 2, 4, 5, 8, and E are respectively
  allocated to Interface-Local, Link-Local,
  Admin-Local, Site-Local, Organization-Local,
  Global scopes.
• 0 and F are reserved
• The 8 remaining values are available for
  administrators to define additional multicast
  scopes.

11
Case A

• The multicast packet is forged by the source
• The source adds to the packet the new hop-by-hop
  header extension including its own position and
  the radius of the desired scope
• Each multicast router receiving a packet with
  geomul extension must compute the distance from
  the source and compare it to the radius. Then it
  has to determine whether the packet must be
  discarded or forwarded.

12
Case AThe Scope Thickness

• The scope thickness variable expands the geocast
  region with an appropriate coefficient to include
  CoI-member nodes near the scope border and which
  are able to forward data to the desired nodes.

13
New hop-by-hop header

• The scope thickness variable consists in a
  percentage of the initial scope
• The Datum field has been designed to ensure a
  good interpretation of the coordinates by the
  destination. (e.g. 0 default, 1 ED50,
  2 WGS84).

14
Case B

• The source forges a multicast packet with the new
  hop-by-hop option and encapsulates it in a
  unicast tunnel
• The main issue consists in the determination of
  the destination address of the tunnel, i.e. the
  address of the nearest node to the centre of the
  geocast region.
• Different solutions can be imagined and
  particularly those based on Domain Name System
  (DNS).

15
Implementation and Way forward

• Basic Implementation
• Case A
• New header extension
• Case B
• Unicast encapsulation based on a well-known
  relay in the geocast region
• Open issues
• Use of a location manager (DNS)
• Synergy with geocast routing protocols
• Impact on security