NHRP v6 - hardware type / address type

[Dave Katz <[e-mail]>]

The mistake of putting hardware type instead of address type into ARP
resulted in no end of ugliness when multimedia bridges came along (which
is why FDDI uses the "Ethernet" hardware type).  In retrospect, what should
have been defined was an "IEEE 802" address type used across all media;
this is in effect what the Ethernet hardware type has become.

It seems as though what's trying to be accomplished is a binding
between a subnetwork address and a network layer address; by
introducing the media type into the process it only makes multimedia
interworking below the network layer difficult (regardless of whether
or not I might think this is a good idea).

Pardon my ignorance, but it would be helpful for me if you would explain
why the media type is useful information in this case.

   Date: Wed, 29 Nov 1995 12:45:02 -0500
   From: Grenville Armitage <[e-mail]>
   Sender: [e-mail]
   Precedence: bulk
   X-Info: Submissions to [e-mail]
   X-Info: [Un]Subscribe requests to [e-mail]
   X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

   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)}