[EFM] Re: OAM - To side-band or not to side-band
Roy-
Rummaging through old mail. I don't think I saw this one in
September.
At 05:37 PM 9/26/01 -0500, Roy Bynum wrote:
Tony,
Again, I think you may not be understanding what I am talking
about.
Actually, according to Geoff Thompson, there is no such thing as a
"full duplex repeater".
That is true within Ethernet Standards
A hub is not a repeater, it is a half duplex
bridge.
What!!??
That is a new one on me! I certainly do not agree.
A hub is:
1) An
undefined term within 802.3 outside of the context of 1 Mbps StarLANs
(clause 12)
2) A
commonly used commercial term for an 802.3 repeater and its included
MAUs/PHYs/PMDs
A repeater is not a bridge.
A bridge is a packet store and forward device that separates collision
domains, can accommodate speed changes beyond mere differences within a
single speed clock tolerance and support full-duplex links.
A repeater (802.3 def'n) is a bit level regenerate and reclock device
that does not support full-duplex or speed changes. It does not separate
collision domains. It does participate in collision/contention
resolution.
A switch is a full duplex
"bridge". Both have 802.1
functionality.
A "Hub" has no 802.1 functionality. All of the 802 pieces in a
hub appear in 802.3.
What I am referring does not have any 802.1 or
802.2 functionality. It has no visibility into the revenue data
traffic stream. It can not get access to the revenue traffic data
stream to put upper level application management traffic such as SNMP
into the revenue traffic data stream in either direction.
Thank you,
Roy Bynum
At 07:47 PM 9/26/01 +0100, Tony Jeffree wrote:
Roy -
Managed Ethernet repeaters (more commonly known as hubs these days) have
been around for some while, and they use MAC frames to carry their (SNMP)
management exchanges. I would therefore hesitate to use that particular
argument either for or against the use of a side-band for OAM.
Having said that, in networks with repeaters there may be distinct
advantages in *not* using such a side-band for OAM - for example, where
it is the device the other side of the repeater that you want to manage.
Unless, of course, you start putting some form of addressing into this
PHY-based side channel, which rapidly starts to look like you're
replicating MAC functionality in the PHY, which begins to look like a
waste of time & effort.
As to T1 and T3, there's no doubt that some of the EFM participants
(myself for one) are not intimately acquainted with the management
entrails of these technologies, and with the thinking behind why they are
that way. I'm sure that some of that information may be useful in
informing what we do in EFM. However, I'm equally sure that
re-inventing T1 or T3, giving it a bit-rate that is a power of 10, &
then badging it "Ethernet", would be a total waste of our
time. After all, if you continue to do what you have always done,
you inevitably end up with what you have always had.
Regards,
Tony
At 11:31 26/09/2001 -0500, Roy Bynum wrote:
There are a lot of other reasons to have the
OAM ou-of-band to the MAC traffic, such as being able to support OAM on
an intelligent "transparent" full duplex repeater in the
future. When this group took on the task of adding subscription
network support for edge access infrastructure into Ethernet, they took
on applying most all of the functionality that is being used today.
There is a long history of why the functionality for these types of
services is what it is. How many of the EFM Task Force people have
looked at how the OAM overhead of T1 or T3 framing works today? How
many of the EFM Task Force people have looked into why the OAM overhead
of T1 or T3 framing works the way that it
does?