The IP Over NBMA (ION) Archive

["James V. Luciani" <luciani@BayNetworks.com>]

Genville,

> Jim (and world),
> 
> I've had a number of private emails in the last few months from
> implementors wondering about the common LLC/SNAP codepoint that
> MARS and NHRP use, so I figure we need some minor clarifying
> words in nhrp-09. I've suggested substitute 'plug in' text.
Only one question?  Seems that 25% of all questions are around LLC/SNAP
code points :-)

> 
These are reasonable, clarifying comments as were those from Eric Grey
a while ago.  Sorry Eric, I unicasted a reply to you saying the same
but did not send it to the list (reply-all seems broken :-)).

> _________________________________________________________________________
> 
> Section 5, 4th paragraph:
> 
>    NHRP packets are encapsulated using the native formats used on the
>    particular NBMA network over which NHRP is carried.  For example,
>    SMDS networks always use LLC/SNAP encapsulation at the NBMA layer,
>    and an NHRP packet is preceded by the following LLC/SNAP
>    encapsulation:
> 
>    [0xAA-AA-03] [0x00-00-5E] [0x00-03]
> 
>    The first three octets are LLC, indicating that SNAP follows.  The
>    SNAP OUI portion is the IANA's OUI, and the SNAP PID portion
>    identifies NHRP (see [4]).
> 
> replace with:
> 
>    NHRP packets are actually members of a wider class of address mapping
>    and management protocols being developed by the IETF. A specific
>    encapsulation, based on the native formats used on the particular NBMA
>    network over which NHRP is carried, indicates the generic IETF mapping
>    and management protocol. For example, SMDS networks always use
>    LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet is
>    preceded by the following LLC/SNAP encapsulation:
> 
>    [0xAA-AA-03] [0x00-00-5E] [0x00-03]
> 
>    The first three octets are LLC, indicating that SNAP follows.  The
>    SNAP OUI portion is the IANA's OUI, and the SNAP PID portion
>    identifies the mapping and management protocol. A field in the
>    Fixed Header following the encapsulation indicates that it is NHRP.
> 
> ________________________________________________________________________
> 
> Section 5.1:
> 
>    ar$op.version
>      This field is set to 0x01 for NHRP version 1.
> 
> replace with (codepoint space modified from draft-ietf-ipatm-ipmc-12):
> 
>    ar$op.version
>       This field indicates what version of generic address mapping
>       and management protocol is represented by this message.
> 
>          0               MARS protocol [11].
>          1               NHRP as defined in this document.
>          0x02 - 0xEF     Reserved for future use by the IETF.
>          0xF0 - 0xFE     Allocated for use by the ATM Forum.
>          0xFF            Experimental/Local use.
> _________________________________________________________________________
> 
> Section 5.1:
> 
>    ar$op.type
>      This is the NHRP packet type: NHRP Resolution Request(1), NHRP
>      Resolution Reply(2), NHRP Registration Request(3), NHRP
>      Registration Reply(4), NHRP Purge Request(5), NHRP Purge Reply(6),
>      or NHRP Error Indication(7).  Use of NHRP packet Types in the range
>      128 to 255 are reserved for research or use in other protocol
>      development and will be administered by IANA.
> 
> replace with:
> 
>    ar$op.type
>      When ar$op.version == 1, this is the NHRP packet type:
>      NHRP Resolution Request(1), NHRP Resolution Reply(2),
>      NHRP Registration Request(3), NHRP Registration Reply(4),
>      NHRP Purge Request(5), NHRP Purge Reply(6), or NHRP Error
>      Indication(7).  Use of NHRP packet Types in the range
>      128 to 255 are reserved for research or use in other protocol
>      development and will be administered by IANA.
> _________________________________________________________________________
> 
> Section 5.3:
> 
> (this is just a suggestion, which I also used in ipmc-12, because
> it allows use of TLVs by non-IETF organisations or researchers without
> having them bother ION or IANA.)
> 
>    Type
>      The extension type code (see below).  The extension type is not
>      qualified by the Compulsory bit, but is orthogonal to it.
> 
> replace with:
> 
>    Type
>      The extension type code (see below).  The extension type is not
>      qualified by the Compulsory bit, but is orthogonal to it.
>      The TLV type space is subdivided to encourage use outside
>      the IETF:
> 
>       0                       Null TLV.
>       0x0001 - 0x0FFF         Reserved for the IETF.
>       0x1000 - 0x11FF         Allocated to the ATM Forum.
>       0x1200 - 0x37FF         Reserved for the IETF.
>       0x3800 - 0x3FFF         Experimental use.
> _________________________________________________________________________
> References:
> 
> Add (to support the changes Section 5.1) :
> 
>   [11]  G. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM
>    Networks.", Bellcore, INTERNET DRAFT, draft-ietf-ipatm-ipmc-12.txt,
>    February 1996.
> 
> (this will have an RFC number in the next few weeks, so we can edit
> it then.)
> _________________________________________________________________________
> 
> 
> cheers,
> gja
> 
--JIm