Re: IP namespace

[Anders Karlsson <[e-mail]>]

Christian Huitema writes:
>This is in fact a case where you would like to use "longest match"
>searches, i.e.  select all possible entries in the database where
>attribute X contains the "firs t bits" (yes, I said BIT, not octet) of
>the target Y, then select the "longest X" and continue the search.
>Similar searches would be absolutely needed for NSAP resolution.

I have been playing around with the directory as a tool for
registering NSAP's.  With NSAP's I don't think there is the same need
for a "longest match" search. The reason for this is that NSAP's (at
least those we deal with) have a lot of "natural" points for delegation.
	
Example:
This NSAP ...
47002300000006000001000041460100000001
... can be split up in its diffrent parts and put into directory like this:

Back-translation root:
@c=SE@o=Chalmers@cn=back-translation   -- folowed by ...
@bt=nsap			       -- with attributes ...
	btBits=8
	registrationAuthority=Joint ISO/CCITT
	description=AFI
@bt=47
	btBits=16
	registrationAuthority=ISO
	description=IDI
@bt=0023
	btBits=32
	registrationAuthority=Nordunet
	description=8 bit Version + 24 bit Administrative Authority
@bt=00000006
	btBits=32
	registrationAuthority=SUNET
	description=16 bit reserved + 16 bit routing domain
@bt=00000100
	btBits=16
	registrationAuthority=Chalmers Networking Group
	description=Area
@bt=0041
	btBits=48
	registrationAuthority=Chalmers Networking Group
	description=Open system identification number
@bt=460100000001
	description=Chalmers NIC

This way our NSAP could be resolved with 7 read-operations that
descend through the DIT.  An other feature with not having the
"longest match search" approach is that the descended path could be
localy cached in a client to speedup future lookups.

Anders Karlsson
Chalmers Networking Group