Subject: Re: PPP over Ethernet Phy

From: Earl McCoy <[email-masked]>
Date: Mon, 11 Mar 2002 15:02:23 -0600

Dennis:

Thanks for your interest and comments. Please see our responses below:

Dennis Ferguson wrote:

> I read this with some interest, but discovered I didn't understand
> the punch line.  For the benefit of the uneducated could you perhaps
> at least include a hint in the document about what a PPP frame is
supposed
> to look like when encapsulated directly on an Ethernet Physical Layer
> without the Ethernet MAC Layer?  For example, is the protocol packet
> preceded solely by the two-byte PPP protocol identifier, or are there
> other bytes at the front of the packet too?  Does the frame include an

> FCS, and if so is it a 16-bit or a 32-bit CRC, or what?  Are the bits
> in bytes put on the wire with the most significant or least
significant
> bit first?  Do frames still need to be padded out to a minimum of 64
> bytes?  It is kind of hard to guess this stuff, but it would be easy
to
> draw a few pictures.

We did not explicitly diagram a PPP frame when encapsulated in Ethernet
physical layer as we didn't (and don't) feel that necessary. The PPP
frame is exactly the usual PPP frame; with or without a FCS, of whatever
length,
with or without PPP header compression, MLPPP or just PPP. Nothing
concerning the
PPP frame proper (before encapsulation) is changed.

The bit order is Ethernets bit order, as all physical layer
encapsulation
aspects of Ethernet are unchanged, by definition.  Literally we propose
a
"fork lift upgrade" of PPP frame for Ethernet frame.  All PPP details
and
particulars are beside the point. All aspects of the MAC frame are gone,
but
the "medium dependent sublayer" of Ethernet remains as the PPP
encapsulation
method.

We did not mention "padding out" to Ethernet's 64-byte minimum frame
length, as we understand this is done "above" the Ethernet Medium
Dependent
Sublayer (hence is done before physical layer encapsulation), and so is
not an
explicit part of Ethernet encapsulation, and hence need not be mentioned
by us.

RFC1661 states this concerning padding:

"Padding
      On transmission, the Information field MAY be padded with an
      arbitrary number of octets up to the MRU.  It is the
      responsibility of each protocol to distinguish padding octets from

      real information."

Our thinking is that there is no need to mention PPP's padding
requirement either; it is "above" our encapsulation layer concern.

> If you are into describing things in terms of layers, then I think
> part of the confusion here is that PPP itself is only about half of
> a "layer 2" and always borrows the other half (framing procedures,
error
> detection and stuff like that) from something that works appropriately

> over the physical layer in question.  For example, "PPP over
SONET/SDH"
> isn't really "PPP over SONET/SDH", it is "PPP in Octet-Synchronous
HDLC
> U/I Frames over SONET/SDH", with the document incorporating what HDLC
> octet-synchronous HDLC U/I frames look like to make it easy for
> implementors.  Similarly, PPPoE is really "PPP in Ethernet MAC layer
> frames over Ethernet Physical Layers", and you can't just chuck out
> the MAC layer framing without fully specifying the framing procedures
> you are replacing it with, because there are no generic PPP framing
> procedures to replace it with.  You have to make them up.

We feel we did specify the framing method, namely both Ethernet
encapsulation methods. Your comment concerning "PPP over SONET/SDH" is
correct, that HDLC "framing" for idleness encoding and "octet stuffing"
for certain ASCII control character "escaping" is the essense of that
encapsulation.  Likewise, our point is that PPP be encapsulated just as
Ethernet is in its two full duplex manifestations, otherwise unchanged.
If we are not sufficiently clear on this point we must revise our
proposal.

> The question I'm really fascinated with, however, is why you want to
> do this at all?  I understand from this
>
>    This places the data service industry in a dilemma, namely wishing
>    the less costly physical interface of Ethernet layer 1, but not
>    actually needing or wanting Ethernet`s redundant layer 2 packet
>    switching capability, scaling problems, etc.
> [...]
>    Alternatively, and proposed here, is to retain Ethernet`s full
>    duplex point-to-point physical interface alternatives, but define
>    PPP encapsulation directly - leaving out the redundant MAC frame
and
>    hence all Ethernet Layer 2 functionality.  The authors believe this

>    is the best of both worlds, and consistent with the Internet`s
>    proven architectural principles.
>
> that what you want to accomplish is to remove Ethernet switches from
the
> links between routers, or routers and hosts, but I can't for the life
of
> me figure out why the goal of removing Ethernet switches is not fully
> accomplished by simply removing the Ethernet switches, wiring the
routers
> and hosts directly together instead?  Once the Ethernet switches are
> physically removed you no longer have a redundant layer 2 packet
switching
> capability, so replacing the Ethernet MAC-level framing in addition to

> that is unnecessary for this purpose.  What additional advantage are
> you trying to get by doing the latter?
>
> Enquiring minds want to know.
>
> Dennis Ferguson

The issue is not just the removal of Ethernet switches.  Rather the
issue is - as you state - the "wiring the routers and hosts directly
together" - with
what and why?  PPP over T1/T3/SONET via HDLC-like encapsulation is the
historic "non-Ethernet" way, but these interfaces are so expensive that
the
Ethernet pipe is much preferred.  Our point is that this expense is
unwarranted and unnecessary IF an Ethernet physical layer encapsulation
for
PPP is defined - our purpose exactly. PPPoE doesn't really help, as it
doesn't
remove the protocol redundancy and adds complexity and overhead.

However our proposed "PPP over Ethernet Layer 1" both removes the
Ethernet
switches while also removing the cost of historic T1/T3/SONET
interfaces, and
reduces protocol redundancy, complexity, and overhead in the bargin.

Let us know if this response does not address your comments.

Regards, Earl McCoy and John Sauer
--
Earl E. McCoy, PhD
Application Specialist
North American Solutions Center
Tellabs, Inc
630-798-3673 desk
630-452-8262 cellular
[email-masked]

============================================================
The information contained in this message may be privileged 
and confidential and protected from disclosure.  If the 
reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to 
the intended recipient, you are hereby notified that any 
reproduction, dissemination or distribution of this 
communication is strictly prohibited. If you have received 
this communication in error, please notify us immediately by 
replying to the message and deleting it from your computer.

Thank you.
Tellabs
============================================================