The IP Over NBMA (ION) Archive

[Maria Greene <greene@nexen.com>]

Hi, David.

>>>>> On Tue, 09 Jul 96 17:04:20 +1000, David Horton <horton@citr.com.au> said:

    > Is there a mapping defined that allows me to go from an
    > ATM address contained in an octet string (0|8|13|20 or 28?)
    > and a atmInterfaceAddressType defined for the ATM interface
    > to an NBMA address as used by NHRP

    > rfc1695.atmInterfaceAddressType   NHRP.address family number  Address length
    > private(1),                       --                          --
    > nsapE164(2),                      NSAP (3)                    20
    > nativeE164(3),                    E.164 (8)                   8
    > --                                E.164+NSAP subaddr          28 ?
    > other(4)                          --                          --

    > The NHRP-MIB has address and subaddress in accordance with NHRP.

    > Should IP-ATM have some support for subaddresses?

We discussed this at the atommib working group meeting in Monteal. I
suggested we change the AtmAddr T-C to add the "|28" to the SIZE
specification. In the current draft, the SIZE clause is (0|8|20),
which does not support a value that is an address prefix or that is a
"structure 3" E.164 address + NSAP subaddress. 

Having an address T-C that can hold the address and the subaddress
would mean we would only need one object, however, there was
disagreement over whether subaddressing is important. The way we left
it was that the T-C would not be capable of holding both and that
separate subaddress objects would have to be added to the IP-ATM MIB
(as was done in the NHRP MIB).

(I believe someone has suggested taking the subaddress field out of
the headers of the IP over ATM and NHRP packets. If that happens in
the protocols, we should track it in the MIBs but it's not a MIB
issue.)

Kaj, in the draft-ietf-atommib-atm1ng-mib-00.txt, the
atmInterfaceAdminAddress object uses the SYNTAX AtmAddress which I
believe should be AtmAddr. It also doesn't import it from anywhere.

    > Does it need to be explicitly stated how to map an NBMA/ATM address
    > into a ATMTC-MIB.AtmAddr ?
    > e.g. to define the use of ipNetToMediaPhysAddress in the IP-ATM MIB
    > or ifPhysAddress?

    > In the IP-ATM-MIB.ipAtmLisSubnet, does there need to be an attribute
    > that maps to the ar$hrd in RFC1577, or ar$afn in NHRP?
    > Should there be a reference to the rfc1695.atmInterface table
    > for the corresponding interface?

I'm not sure I understand what you mean by these last two
paragraphs. Could you elaborate?

    > Related types are NhrpIANAAddrFamily in NHRP-MIB and
    > atmInterfaceAddressType in AToMMIB (1695).

Yes, they are related. The first is a superset of the second. Is there
a problem with this? I could see generalizing nhrpIANAAddrFamily and
putting it in a more re-usable place, such as the IF-MIB. Right now
the ifPhysAddress object must be interpreted based on ifType, but for
some ifTypes, like atm, the ifPhysAddress could be one of several
formats. We could recommend that tables in media-specific MIBs that
extend the ifTable, such as atmInterfaceConfTable, use this T-C to
specify how to interpret ifPhysAddress. I think this would be an
object in addition to atmInterfaceAddressType (which could also use
this T-C) which specifies how to interpret atmInterfaceAdminAddress.

    > regards,
    > David

Maria

    >  David Horton
    >  Centre for Information Technology Research
    >  Level 2 South Tower, 339 Coronation Drive, Milton, Australia 4064

________________________________________________________________________
Maria N. Greene                                         greene@nexen.com
Ascom Nexion     289 Great Rd., Acton MA 01720 USA       +1 508 266-4570