The IP over ATM Mailing List Archive by date

[Grenville Armitage <gja@thumper.bellcore.com>]

>>Grenville Armitage writes:
>>+--------
>>|The description of ar$pro would now read:
>>|
>>|      0x0000 to 0x00FF  Protocols defined by the equivalent NPLIDs.
>>|      0x0100 to 0x03FF  Reserved for future use by the IETF.
>>|      0x0400 to 0x05FF  Designated for use by the ATM Forum.
>>|      0x0600 to 0xFFFF  Protocols defined by the equivalent Ethertypes.
>>|
>>|(based on the observations that valid Ethertypes are never smaller
>>|than 0x600, and NPLIDs never larger than 0xFF.)
>>+---------
>>One interesting case is where the NLPID = 80.  This means (see RFC 1490
>>for example) that a 5 byte LLC/SNAP value follows.  Where would I put
>>this ?
>>
>>In the data plane, the LLC/SNAP could clearly be part of the "Extended
>>Layer 3 packet" shown in Section 5.5.
>>
>>But it isn't clear to me where the LLC/SNAP would go in the control plane,
>>i.e. in a MARS packet.
>>
>>Did I miss 5 bytes somewhere ?

My initial reaction was that the above table only encompasses
NPLIDs that identify a protocol, rather than NLPIDs that really
mean "there are more protocol bytes to follow".

But I think you've inadvertently hit on an 'almost standard' way
of including SNAP based protocol IDs. People may remember a few weeks
ago I said that the existing MARS message format could carry SNAP
fields as a TLV, with ar$pro = 0x400 being interpreted as the flag
saying "go look in the TLV list". Of course, 0x400 was a rather arbitrary
value.

However, the denser ar$pro space listed above allows us to use
ar$pro = 0x80 as the flag. This use is conceptually similar to
its meaning in the NPLID space (provided one loosens the sense
of "the SNAP field follows" to be less literal, and change it
too, e.g., "the SNAP field follows as the first TLV in the TLV list").

I think the goal for ip-atm is to not preclude identifying protocols that
MPOA might need, while keeping packet o/head nice and tight for the
pure IP case. I think James' observation re ar$pro = 0x80
leads us to a neat way of achieving this.

cheers,
gja