The IP over ATM Mailing List Archive by date

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

I've updated my ipmc web site with two important documents - a summary
of the explicit changes that came out of the ipmc-07 Last Call,
and what I believe to be an acceptable synthesis of the long vs short
protocol ID debate. I'm still writing up a summary of the sourceID
debate.

The ipmc web page is at:

http://gump.bellcore.com:8000/~gja/i-drafts.html

Since the protocolID debate is still current, I've also appended
that document to this email.

cheers,
gja
_________________________________________________________________________
Grenville Armitage, Research Scientist,      MRE 2P-255, 445 South Street
Internetworking Research Group, Bellcore.      Morristown, NJ, 07960, USA
(email) gja@thumper.bellcore.com  (voice) +1 201 829 2635 {.. 2504 (fax)}
        (www) http://gump.bellcore.com:8000/~gja/home.html


PROTOCOL ID:

The issue of protocol ID size and interpretation has
implications for both the control plane (MARS messages)
and data plane (extended encapsulation for reflected
packet detection).

Carrying the protocolID in the data plane requires
us to deal with the desires to keep per-packet overhead
down.

Attempting to construct a spec that can be re-used by
MPOA with minimal fuss requires us to consider a larger
number space (or more creatively assigned number space)
than the original 16 bit ar$pro based on ethertypes.


As of Oct.12th, 1995 the following appears to be the
'state of the compromise':

        - Basic data plane o/head is 4 bytes (as per
          ipmc-06, ipmc-07) for IPv4, IPv6, and a number
          of other protocols.
        - A standard 'hook' is used to extend the data plane
          o/head when necessary (without affecting IP).
        - Control plane messages ar$pro field is fixed at
          8 bytes (not 6) rather than 2, with modified interpretation
          rules.


gja

-------------------------------------------------------------------

#1. CONTROL PLANE encoding:

References to ar$pro in the following form:

       ar$pro     16 bits  Protocol type

are Replaced by:

       ar$pro.type 16 bits  Protocol type
       ar$pro.snap 48 bits  Optional SNAP extension + 1 byte pad.

In section 4.3 the description of the ar$pro space becomes:

  The ar$pro.type field is a 16 bit unsigned integer representing the
  following number space:

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

  The NLPID value of 0x80 is used to indicate a SNAP encoded extension
  is being used to encode the protocol type. When ar$pro.type == 0x80
  the SNAP extension is encoded in the ar$pro.snap field. The contents
  of the ar$pro.snap field are left justified, with the last byte as
  padding to retain 32 bit alignment of following fields in the MARS
  message. This final byte is always zero on transmit, and ignored
  on receive. This is termed the 'long form' protocol ID.

  If ar$pro != 0x80 then the ar$pro.snap field MUST be zero on transmit
  and ignored on receive. The ar$pro.type field itself identifies
  the protocol being referred to. This is termed the 'short form'
  protocol ID.

  In all cases, where a protocol has an assigned number in the ar$pro.type
  space (excluding 0x80) the short form MUST be used when transmitting
  MARS messages. Additionally, where a protocol has valid short and long
  forms of identification, receivers MAY choose to recognise the long
  form.

-------------------------------------------------------------------

#2. DATA PLANE encoding: (NB - modulo the impact of the sourceID debate)

In ipmc-07 the extended Layer 3 packet is given as:

      [pkt$cmi][pkt$pro][Original Layer 3 packet]

with pkt$pro taken from the ar$pro space.

This is now modified as follows:

  For all cases where ar$pro.type != 0x80 the extended Layer 3 packet
  SHALL be:

      [pkt$cmi][pkt$pro][Original Layer 3 packet]
        2octet   2octet        N octet

  with pkt$pro taken from the ar$pro.type space.

  However, if pkt$pro == 0x80, the extended Layer 3 packet SHALL be further
  extended to carry an additional 5 byte SNAP field (with padding
  for 32 bit alignment). The format SHALL be:

      [pkt$cmi][0x00-80][5 octet SNAP][3 octet pad][Original Layer 3 packet]
        2octet   2octet                              N octet

  In all cases, where a protocol has an assigned number in the ar$pro.type
  space (excluding 0x80) the short form MUST be used on transmission.
  Additionally, where a protocol has valid short and long forms of
  identification, receivers MAY choose to recognise the long form.

In either case the initial LLC/SNAP codepoint indicating the existence
of a Layer 3 packet with extended encapsulation will be the same.
i.e.

      [0xAA-AA-03][0x00-00-5E][0x00-01][Extended Layer 3 packet]

-------------------------------------------------------------------