Re: NHRP v6 - hardware type / address type

[Grenville Armitage <[e-mail]>]

Bruce,

>>I think the way that NBMA address types are expressed in draft 06 is a step
>>backwards from what we had in draft 05 of the spec.

Since I argued for it during discussions with Andy and Jim I
probably should respond.

>>First, the ar$shtl and ar$sstl fields are described in terms of an ar$afn
>>field, but the ar$afn field is not described in the spec.  I'll assume
>>you meant to label the ar$hrd as ar$afn in the spec...

Yes.

The alignment of nhrp/ipmc control packet formats raised the issue
of what number space to use for the first 16 bits of the control
packet. IANA has two arguably relevant number spaces available:

	- 'Hardware type'
	- 'Address family'

Solving this issue involves noting that, in my opinion, there is
value in using this 16 bit field to identify both the type of
the media and the type of the addresses.

The address family explicitly identifies a single address type,
but really does not convey any indication of NBMA media type. On the
other hand, the hardware type number space explicitly identifies the
media type, which also identifies the address type(s) that one
is going to find inside the control packet.

>>It looks like the 06 spec tries to address this problem with a flag bit:
>>
>>>    The ar$shtl and ar$sstl fields are coded as follows:
>>> 
>>>                 7 6 5 4 3 2 1 0
>>>                +-+-+-+-+-+-+-+-+
>>>                |0|x|  length   |
>>>                +-+-+-+-+-+-+-+-+
>>>

The realisation that an NBMA technology such as ATM allowed two
address types led to the single flag bit you see in the ar$shtl field.
Physically it is detached from the ar$hrd field, but semantically
is it associated with the 'address type identification' role that
the ar$hrd value provides. Detaching it from the ar$hrd field is
required because not only does ATM allow two address types (NSAPA
and E.164), but it allows three combinations of address and subaddress
to represent an NBMA endpoint.

This mechanism generalises in the following way:

	- When you define an ar$hrd value to represent a new media,
	  you also note the one or two distinct address types allowed
	  on this media.

	- In any given instance of a nhrp message, the flag bit in
	  the ar$shtl field indentifies which of the two address
	  types the supplied address is.

	- If the media indicated by ar$hrd has only one address
	  type, flag is always 0.

Note that in first bullet point "distinct address types" means
addresses that do not contain internal means for distinguishing
between themselves. e.g. native E.164 addresses and NSAPA format
addresses are distinct, but the various subtypes of NSAPA are
(at this level of abstraction) considered identical.

>>>    The most significant bit is reserved and MUST be set to zero. The
>>>    second most significant bit (x) is a flag indicating whether the NBMA
>>>    address being referred to is in:
>>> 
>>>       - NSAP format (x = 0).
>>>       - Native E.164 format (x = 1).
>>> 
>>>    For NBMA technologies that use neither NSAP nor E.164 format
>>>    addresses, x = 0 SHALL be used to indicate the native form for the
>>>    particular NBMA technology.
>>
>>The above bit seems very ATM-centric, as it only addresses ATM address
>>formats.  ATM is not the only link layer which has more than 1 address type.

Yes, its wording could probably be improved, or at least benefit
from being prefaced by the generalised bullet points I gave above.
Then the above text would be introduced as "for example, when the
media type is ATM (indicated by ar$hrd = 0x13), the two address
types are NSAPA and native E.164 format. The flag is encoded
as follows..."

The key is that the existing hardware type number space be
more explicit in identifying the one (or two) addresses allowed.

>>Take for example frame-relay where your NBMA addresses may be either
>>E.164 or X.121. Using another bit to represent X.121 is NOT a solution,
>>there are too many potential address types to use a flag bit for each one.

Not required. Given that each ar$hrd value identifies a media
with one or two allowed address types, we clarify the existing
ar$hrd value for Frame Relay like so:

	ar$hrd = 0x15	 Frame Relay,  X.121 or E.164 addresses.

	       - X.121 format (x = 0).
	       - E.164 format (x = 1).

This augmented hardware/address type space seems like a much better
solution to me, and is consistent with the desires that originally
started the nhrp/ipmc convergence effort.

cheers,
gja
_________________________________________________________________________
Grenville Armitage                               [e-mail]
Bellcore, 445 South St.      http://gump.bellcore.com:8000/~gja/home.html
Morristown, NJ 07960 USA          (voice) [phone] {.. 2504 (fax)}