Subject: Re: ipNetToMediaPhysAddress

From: Paul Koning <[email-masked]>
Date: Wed, 19 Nov 1997 09:31:47 -0500

>>>>> "kennethw" == kennethw  <[email-masked]> writes:

 >> The question is: what does one find in the ipNetToMediaPhysAddress
 >> object?  The obvious answer is an ATM address, but there are two
 >> issues: (1) it can be either an AESA (20 byte NSAP format address)
 >> or an E.164 address, and (2) there can be a subaddress along with
 >> the address.

 >> Some vague memory suggests one would concatenate address and
 >> subaddress (potentially yielding a 40 byte value) but that is
 >> still not enough to answer point (1).

 kennethw> I disagree. Take a look at the textual convention that is
 kennethw> used to define this object:

 kennethw> IpoaAtmAddr ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x" STATUS
 kennethw> current DESCRIPTION "The ATM address used by the network
 kennethw> entity.  The address type can be determined by the OCTET
 kennethw> STRING size. IpoaAtmAddr can be comprised of both an ATM
 kennethw> Address and a subaddress. The ATM Address portion is
 kennethw> required and must be first in the OCTET STRING.

 kennethw> An implementation must use BCD encoding to represent a
 kennethw> E.164 address as a MIB object."  SYNTAX OCTET STRING
 kennethw> (SIZE(0..40))

 kennethw> Clearly subaddress follow address if present and the size
 kennethw> of the octet string determines what's present.

 kennethw> Back in March there were numerous notes on the ion mailing
 kennethw> list discussing this object. It was agreed that the size of
 kennethw> the octet string would determine its content:

 kennethw> Structure Octets Type - 0 no address 1 20 NSAP 2 8 E.164
 kennethw> encoded in BCD format 2 15 E.164 encoded in native format 3
 kennethw> 28 BCD encode E.164 + NSAP sub-addr 3 35 native E.164 +
 kennethw> NSAP sub-addr" - 40 NSAP + NSAP sub-addr

 kennethw> This was also discussed in the ATOMMIB working group. The
 kennethw> agreement was that the atm2tc internet-draft's AtmAddr
 kennethw> would be updated to handle up to 40 octets. I just checked
 kennethw> the September version and it still doesn't:

 kennethw> AtmAddr ::= TEXTUAL-CONVENTION DISPLAY-HINT "1x" STATUS
 kennethw> current DESCRIPTION "The ATM address used by the network
 kennethw> entity.  The address types are: no address (0 octets),
 kennethw> E.164 (8 octets), and NSAP (20 octets).  Note: The E.164
 kennethw> address is encoded in BCD format."  SYNTAX OCTET STRING
 kennethw> (SIZE(0º8º20)

Ok, so the problem is that I was looking at AtmAddr (since the
NetToMedia table doesn't use IpoaAtmAddr) and that definition is
obsolete.  I'll just use what it says for IpoaAtmAddr then.

Also, what does "E.164 encoded in native format" mean?  The only
native format I know of for E.164 is BCD encoding.  Is the 15-byte
encoding supposed to be one digit per byte?  Bizarre.  If so, is that
ascii digits or binary digits?  It has to be stated somewhere around
here (since I don't think it's anywhere else).

Incidentally, I'm having trouble coming up with words strong enough to
express my opinion about this particular encoding technique.

 kennethw> At this time I prefer to see if I can add some comments to
 kennethw> the description clause of the IpoaAtmAddr and forget about
 kennethw> attempting to import AtmAddr as part of the review process.

Sounds ok.  I guess we can push on the NetToMedia issue in the Atom
MIB discussion rather than the Ipoa MIB discussion.

Thanks Ken.

	paul

---

From: Albert Manfredi <[email-masked]>
Date: Wed, 19 Nov 1997 10:11:36 -0500

Paul Koning wrote:

[ ... ]

> here (since I don't think it's anywhere else).

I had the same question, but vague memory of previous arguments
tells me it's indeed ASCII-encoded telephone numbers.

> express my opinion about this particular encoding technique.

ASCII is the rage these days. Did you know that the standard for the
encoding of GPS (Global Positioning System) data for commercial
receivers is ASCII? Talk about _weird_. Latitude and longitude in
ASCII strings, including ASCII decimal point. The standard is called
NMEA 0183, in case you're wondering.

Bert
[email-masked]

---

From: Dan Grossman <[email-masked]>
Date: Wed, 19 Nov 1997 13:49:11 -0500

> tells me it's indeed ASCII-encoded telephone numbers.
Yes, it's ASCII.  This goes back to ISDN, and some ancient issues involving 
stimulus signalling from very dumb ISDN phones, as well as interworking 
between ISDN and telephony.   Not what we'd necessarily do today, but then 
again, the world is full of things we'd all do differently if we could rip out 
all the old equipement and start again.

> NMEA 0183, in case you're wondering.
Not quite. NMEA 0183 is for communication between shipboard instruments.  For 
example, if I bought an autopilot for my sailboat, the GPS would send 
cross-track error information to the autopilot using an ASCII character 
string. My wind instrument sends direction and speed information to my speed 
indicator using NMEA 0183 so it can compute speed to windward (VMG) from speed 
through the water. NMEA 0183 is as old as the hills, and predecessor standards 
(NMEA 0180, NMEA 0182) predate GPS by about a decade.  Electrically, they're 
EIA-232, so it's pretty easy to hook a laptop to your instruments and play 
neat games with navigational charts and boat performance software.  The GPS 
system itself sends ephemeris and system availability data from the satellites 
to recievers as, I believe, structured binary.

But of course, we're off topic.

Dan