Re: future assignments of PPP protocol id's.

Drew Daniel Perkins <perkins+@cmu.edu> Sun, 18 April 1993 06:29 UTC

Resent-Message-Id: <kfoCq9C00WArNR4rMN@andrew.cmu.edu>
Resent-Date: Sun, 18 Apr 1993 01:56:25 -0400
Resent-From: Drew Daniel Perkins <perkins+@cmu.edu>
Resent-To: ietf-ppp@ucdavis.edu
Message-Id: <sfoCpIi00WAr5R4qNP@andrew.cmu.edu>
Date: Sun, 18 Apr 1993 01:55:32 -0400
Sender: ietf-archive-request@cmu.edu
From: Drew Daniel Perkins <perkins+@cmu.edu>
To: Keith Sklower <sklower@vangogh.cs.berkeley.edu>
Subject: Re: future assignments of PPP protocol id's.
In-Reply-To: <199304152149.OAA25222@vangogh.CS.Berkeley.EDU>
References: <199304152149.OAA25222@vangogh.CS.Berkeley.EDU>

Keith Sklower <sklower@vangogh.cs.berkeley.edu> writes:
> [This begs the numerous PPP protocol id's
> less then 600 hex for the protocols themselves
> which you wouldn't want to use in ethernet packets
> because they might get taken for 802.3 lengths, and
> there are already common other numbers for them,
> like 800 for IP packets as an ethertype].
> 
> I also asked Drew Perkins why it was that PPP
> protocol id's had an even first byte and an odd
> second byte. He said that was so they could be used
> as an HDLC two-byte address, but in fact this
> was something that was a hedge against a future
> day where it might be useful, and wasn't currently
> an absolute requirement; if there was a really good
> reason to give it up, current implementations
> of PPP wouldn't choke.  I'm not saying there is
> any good reason to give it up right now!
> 
> (If they were used as an HDLC address, you would
> need to follow them with a UI, which is currently
> not being done).

Keith, we somehow miscommunicated.  I did NOT say that we wanted to
use protocol ids as addresses.  What I did try to say is the following:
1.  We wanted to have two octet addresses for high-speed links where
    processing speed was an important criteria and alignment issues
    might exist.
2.  We wanted to have one octet addresses for all important
    network-layer protocols when used with low-speed links where
    latency was an important criteria and alignment issues didn't exist.
3.  We realized that extensible protocol numbers would solve our
    problem.
4.  We realized that CCITT had an existing methodology for implementing
    extensible fields, namely using the least-significant bit, and
    this was already in use by the HDLC address field (which we were
    supporting).
5.  Therefore, it made sense to use the same methodology for our
    protocol fields as we used for our HDLC address fields.

You also mentioned that changing this now would not break any
implementations.  This is definitely NOT true; it cannot now be changed.

Drew Perkins
-----------------------------------------------------------------
					email: perkins+@cmu.edu
4015 Holiday Park Drive			voice: (412) 325-1785
Murrysville, PA 15668			fax:   (412) 325-1344

Re: future assignments of PPP protocol id's. Drew Daniel Perkins