Naming

1
Naming

• EDIFY Research
• 02/11/05
• Vinay Goel

2
DTNRG Approach

• K. Fall, A Delay Tolerant Network Architecture
  for Challenged Internets, Proceedings of
  SIGCOMM, August 2003

3
Name Tuples

• Name tuples are identifiers for objects
• Used for routing of DTN messages
• DTN name tuples are assigned to each end point
  and each router half.
• A DTN gateway spanning two regions consists
  logically of two halves.

4
Structure of the tuple

• Region Name, Entity Name
• First portion is the region name
• Second portion identifies a name resolvable
  within the specified region and need not be
  unique outside the region

5
Region Name

• Globally unique
• Hierarchically structured
• Topological significance
• Interpreted by DTN forwarders to find the path(s)
  to one or more DTN gateways

6
Region Names

• Populated into DTN forwarding tables
• Statically (by a network administrator)
• Or by one or more dynamic DTN-layer routing
  protocols (centrally computed for example)
• The hierarchical structure
• provides the ability to reduce the size of DTN
  forwarding tables.
• Allows for additional flexibility due to
  variable-length substrings allowed between the
  hierarchy delimiters

7

• Note Region names need not necessarily be
  resolved to any form of address or resolved in a
  distributed hierarchy as DNS names

8
Entity Name

• Second portion of the name tuple
• Identifies a name resolvable within the specified
  region
• Need not be unique outside the region
• May be of arbitrary structure
• May contain special indications resolvable in the
  origin or destination regions

9
Example tuple - case of Internet

• internet.icann.int, http//www.ietf.org/oview.ht
  ml
• This tuple would refer to the Internet region,
  along with an Internet-specific local identifier
  (in this case, a URI)

10
Name resolution

• As a message transits across collection of
  regions, only its region identifier is used for
  routing.
• Upon reaching the edge of the destination region,
• entity name information is locally interpreted
• translated if necessary into a protocol-standard
  name (or address) appropriate to the containing
  region.

11
Late Binding

• Any reasonable naming scheme can be easily
  accommodated
• not imposing any particular fixed structure on
  the second portion of a tuple
• Differs from the DNS-style Internet naming and
  addressing which requires
• one or more DNS transactions to complete prior to
  the start of an Internet end-to-end conversation.
  

12
The tuple structure

• Could imply more than two indirect lookups to
  ultimately determine an endpoint
• one in order to resolve the region identifier to
  a valid local next-hop,
• and a second lookup to resolve the
  region-specific data to a valid next-hop or
  aggregate set address within the specified
  region.
• Importantly such queries should be local to a
  router (given a reasonable DTN routing protocol)
  and not require a complete end-to-end name
  resolution transaction

13
EDIFY Approach

• Previously suggested naming convention
• Useful for stationary delay tolerant n/w
  scenarios
• May not be able to deal with ad-hoc mobile
  networks that battlefield networks often face
• New naming convention required
• Deals with network mobility and network
  partitions

14
Flexible Naming Convention

• Allows for
• role-based addressing
• multiple namespaces
• Provides layered resolution of address and
  routing information

15
Hierarchical naming
16
Details

• Four groups
• Three belong to US-DoD
• One is a NATO squad team
• Platoon member (User host-1093) currently with
  US-DoD.Navy.Battalion5
• given a visiting identifier (US-DoD.Navy.Batallion
  5.Visitor5)
• Squad team members each have
• Original identity
• Temporary identify from the squad team

17
Groups

• Provide the concept of groups instead of regions
• Each group member has a group identifier (GID)
• Each device within a group has its own personal
  identifier (PID)
• Any device within the group can be identified by
  the tuple (GID, PID)

18
Naming groups

• Hierarchical naming technique
• But generalize naming to permit multiple,
  different naming hierarchies
• Allows incorporation of information from multiple
  naming systems
• Provides the ability to incorporate routing
  preferences or requirements

19
Naming ad-hoc groups

• Ad-hoc group adopts a different group identifier
  (TGID - Temporary Group ID)
• Members assume two identifiers
• the original (GID,PID)
• (TGID, PID)
• The former is used for communication with the
  original group member while the latter is used
  for communication with the ad-hoc group member

20
Canonical names

• Every user (or device) can have a canonical,
  universally unique name
• Fixed name
• name remains fixed even when a node moves from
  one group to another
• Such naming suggests
• creation of supporting devices to resolve a
  canonical name to its last known set of
  non-canonical naming tuples
• an individual node might represent more than one
  entity(person), each with a canonical ID and
  routable naming tuples

21
Thanks