Point to Point Ethernet

A few time already I've wished for a fully standardized and vendor
interoperable way of doing a true point to point ethernet link.

It would work just like an old leased line or synchronous serial
interface and completely do away with ARP, MAC addresses and all
that stuff. Obviously no switches in between would be allowed.
Each side would run in "promiscuous mode" where every ethernet
frame is received and passed up to the network stack (just like
on a serial link). Since MAC addresses are useless they can be
scrapped and only the ethertype field remains. This increases
the effective MTU by 12 bytes.

The framing overhead goes away and the packet can directly be
directly placed on the wire without taking a detour through L3->L2
lookup and encapsulation step.

More importantly one can specify the just the outgoing interface
again instead of the next hop:

  ip route 10.0.0.0 255.0.0.0 g0/1

Do you think this is useful? Maybe vendors will hear me/us.

We're halfway there (OK, a bit less, they've messed up OSPF) with the
unnumbered VLAN interfaces.

http://wiki.nil.com/Unnumbered_Ethernet_VLAN_interfaces

What's missing is the removal of MAC layer header, but that would require
modifications to the NIC chipsets (= expensive).

Ivan

http://www.ioshints.info/about
http://blog.ioshints.info/

> Do you think this is useful? Maybe vendors will
hear me/us.
>
> --
> Andre

We also need functional remote loop testing, of the "remote hands guy plugs in a loopback plug" or "I send remote-triggered loop" type.

David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com

Andre,

Some thoughts on this:

1. What's the point of increasing the max MTU from 9000 to 9012? If we
want a higher MTU, why not just ask for one in the next standard?

2. Why do we need to save 12 bytes per packet by eliminating the MAC
address? Why not just get the next larger ethernet size?

3. Could we be better served by using RFC1918 addresses that we define
as link-local and asking the router vendors to support a "link local"
config option that causes it to use the address from loopback0 for any
communications it initiates over that interface instead of using the
interface IP address? In other words, if your loop0 is 199.33.224.1
and your g0/0 is 10.3.2.1/30 the link-local option would cause the
router to send any host-unreachable messages out g0/0 from
199.33.225.1 instead of 10.3.2.1. Likewise, pings and snmp traps would
originate from 199.33.224.1. Only packets to 10.3.2.2 would originate
from 10.3.2.1.

Such a software-only change would be less expensive to implement than
custom ethernet hardware and it would be applicable on all interface
types, not just ethernet. And of course we already have tools to
prevent such link-local addresses from entering the routing protocol.

At a software level, we could also declare a specific remote address
as the point-to-point destination so that we could use the interface
name as shorthand elsewhere in the config if that proves desirable.

4. L3->L2 lookup is a pretty negligible cost. It's cached for a good
long while. And you already have tools to hardcode it if so desired.
With Ciscos at least, you can even hardcode addresses to
ffff.ffff.ffff though this causes some unexpected behavior.

Regards,
Bill

There are lots of great little cable testers that can "loop" an Ethernet
link or even blink the switchport (this one is copper only):
http://www.jdsu.com/products/communications-test-measurement/products/a-z-pr
oduct-list/lanscaper.html

The remote-triggered is harder, but there are a number of switches I have
seen that have some form of line testing built in, so that might be close to
a decent solution. One example is the "Integrated Cable Test" and Optical
Transceiver Diagnostics in the Dell PowerConnect switches.

  -Scott

To me the only reason for this would be to lessen overhead on small packets. Also, afaik standard payload MTU is 1500 for ethernet, anything else is vendor extension, outside the standard.

Ethernet overhead compared to HDLC is pretty big...

Visit the Accedian website to learn about Ethernet demarcation and related
standards. They market me heavily (and it apparently works).

Frank

1. What's the point of increasing the max MTU from 9000 to 9012? If we want a higher MTU, why not just ask for one in the next standard?

From what I have been told, IEEE 802 refuses to make a Jumbo frame standard, for backwards compatibility reasons.

Joe St Sauver's jumbo frame site :

http://darkwing.uoregon.edu/~joe/jumbo-clean-gear.html

shows what a mess this is. There isn't a standard now, and if you "ask for one in the next standard" you may be in for a long wait.

To me the only reason for this would be to lessen overhead on small packets. Also, afaik standard payload MTU is 1500 for ethernet, anything else is vendor extension, outside the standard.

Ethernet overhead compared to HDLC is pretty big...

--
Mikael Abrahamsson email: swmike@swm.pp.se

Regards
Marshall
AmericaFree.TV

> 1. What's the point of increasing the max MTU from 9000 to 9012? If we
> want a higher MTU, why not just ask for one in the next standard?

To me the only reason for this would be to lessen overhead on small
packets. Also, afaik standard payload MTU is 1500 for ethernet, anything
else is vendor extension, outside the standard.

Ethernet overhead compared to HDLC is pretty big...

Also, there would be small point in getting rid of the normal Ethernet
headers if you still needed to use the standard Ethernet preamble and
inter frame gap (a total of 20 bytes). These were really only needed for
10 Mbps Ethernet.

I find it highly unlikely that such a change would be accepted - also I
don't really see the big point.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

My first thought was that there's really no use ripping the guts out of a
protocol whose core mechanisms are aimed at dealing with the complexities of
operating on a shared medium only to use it in an environment in which none
of those complexities exist.

But, if interfaces would be made to support both Ethernet II and some new
Addressless Ethernet (or some other moniker) frames, the additional costs,
real or administrative, wouldn't be outstanding.

You might want to first try proving that reducing the Ethernet frame overhead
by 2/3 and, in turn, reducing the average frame size by 12 / [average frame
size] percent is worthwhile. Or try making the frame overhead reduction
argument only a small piece of the larger argument for getting rid of
multi-access cruft in point-to-point environments. But good luck pushing the
principle argument of making things "as simple as possible but no simpler"
without good technical and (hence) business cases.

Stephen Kratzer
Network Engineer
CTI Networks, Inc.

1. What's the point of increasing the max MTU from 9000 to 9012? If we
want a higher MTU, why not just ask for one in the next standard?

To me the only reason for this would be to lessen overhead on small
packets.

Mikael,

At the cost of low-volume production run hardware which is A. much
more expensive (because of the low volume), B. restricted to a few
supported routers and C. less thoroughly tested. I don't see how you
come out ahead in that calculation.

Also, afaik standard payload MTU is 1500 for ethernet, anything
else is vendor extension, outside the standard.

From what I have been told, IEEE 802 refuses to make a Jumbo frame standard,
for backwards compatibility reasons.

Marshall,

My understanding is that 9000 is a standard for GigE and up but for
compatibility with earlier ethernets it's not the default. You have to
explicitly configure it and you must configure it the same on every
host and switch within the broadcast zone. For a point to point link,
this should be trivial.

Or am I mistaken?

I gather from your list that not everything which supports gige also
supports jumbo frames but that most things do.

Regards,
Bill Herrin

My understanding is that 9000 is a standard for GigE and up but for
compatibility with earlier ethernets it's not the default.

Your understanding is wrong. The only IEEE standard is 1500 bytes.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

Steinar,

I 'spose I could have consulted wikipedia and gotten the answer:

"The IEEE 802 standards committee does not recognize jumbo frames, as
doing so would remove interoperability with other 802 protocols,
including 802.5 Token Ring and 802.11 Wireless LAN. The use of 9,000
bytes as preferred size for jumbo frames arose from discussions within
the Joint Engineering Team of Internet2 and the U.S. federal
government networks. Their recommendation has been adopted by all
other national research and education networks. In order to meet this
mandatory purchasing criterion, manufacturers have in turn adopted
9,000 bytes as the conventional jumbo frame size."

So 9000 for gige and up is a convention, not a standard. My bad.

Regards,
Bill Herrin

At the cost of low-volume production run hardware which is A. much more expensive (because of the low volume), B. restricted to a few supported routers and C. less thoroughly tested. I don't see how you come out ahead in that calculation.

The only way to do it would be to make this a standard in the next evolution of Ethernet, perhaps 400GE. I don't see this happening though.

But the only REASON to do it, would be to lessen overhead for small packets. I don't see how you can not see this.

My understanding is that 9000 is a standard for GigE and up but for compatibility with earlier ethernets it's not the default. You have to explicitly configure it and you must configure it the same on every host and switch within the broadcast zone. For a point to point link, this should be trivial.

No, IEEE says only 1500 payload MTU. This was discussed in 40GE and 100GE, and IEEE left the framesize the same way it's always been.

I gather from your list that not everything which supports gige also supports jumbo frames but that most things do.

Yes, but that doesn't make it standard. It makes it common.

Speaking from a personal interest, has the Point-to-Point Protocol
stopped being useful?

After all, PPP over Sonet/SDH was specifically designed for just this case.

Once upon a time, it worked well for intra-site connections, as originally
specified in RFC1619:

   PPP encapsulation over high speed private point-to-point links, such as
   intra-campus single-mode fiber which may already be installed and unused.

It was only after others crammed stuff in to make it work on inferior
quality long distance links that it became more expensive and complicated.

Still, it has all the testing and link configuration mentioned. And very
low overhead. And works on copper wiring, too....

Speaking from a personal interest, has the Point-to-Point Protocol
stopped being useful?

After all, PPP over Sonet/SDH was specifically designed for just this case.

Absolutely, and it still works great for that purpose.

However, given a provider backbone with Ethernet being the underlying
technology, I don't see why anybody would want to use PPP on top of
Ethernet instead of just plain Ethernet. After all we're *not* talking
about DSL or dialup here, there's no need to authenticate users etc.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

... completely do away with ARP, MAC addresses and all
that stuff.

Removing "all that stuff" means it's no longer ethernet.

Do you think this is useful? Maybe vendors will hear me/us.

No. I do not.

Ethernet is not a point-to-point technology. It is a multi-point (broadcast, bus, etc.) technology with DECADES of optimization and adoption. No one has gotten IEEE to adopt a larger frame size, and you want to drop *fundamental* elements of ethernet?!?

--Ricky

I think the latest suggestion was to do away with the mechanisms, not change the frame format. It's like when you take a /30, run isis/ospf over it and tell the routing protocol it's a point to point link so it doesn't have to create a node for the "multi access network" that really isn't there.

Same way here, putting the ethernet link in "p2p" mode would mean it wouldnt do arp anymore, didn't care about source or destination MACs, it just installed static ARP entry for other end and sent out packets, other end would be in promisc mode and accept anything.

I don't see much gain from this though, and it's another way things can be configured wrong and cause havoc if you connect this interface to a LAN.

They sort of did a few decades back, created HDLC (5 bytes minimum)
and PPP (6 bytes minimum) for P2P links. I think you're at risk of
over-thinking this problem working in reverse from ethernet to
something slightly-less-than-ethernet.

Further, if we want to get truly sizable improvement from 'ethernet
like p2p paradigm' we can *drop the damn IFG and preample.*

http://sd.wareonearth.com/~phil/net/overhead/

Best case, you blow 12 bytes on IFG in gig, 20 bytes on fast-e/slow-e.
No matter how you slice it, it's not getting better than what we've
already got (i.e. p2p link prots).

Though, I do somewhat relate to your disgust and general sentiments.
In 2009 I have cheap asics that can recover clock from line code alone
and we're not doing CSMA/CD, so what's the freaking point of IFG and
preamble? ./rhetorical (see lanhy vs. wanphy)

-Tk

if it does away with MAC addresses, in what sense is it an Ethernet link?

I'll go with EPON or a variety of those. Not sure what messing with the Mac frame actually buys.