Re: Long distance links
Jonathan,
From a WAN prospective, I am trying to simplify things, not complicate them.
For some reason, I have been unable to communicate that using existing 802.3
frames over a WAN version of 10GbE is NOT SONET/SDH. I am not recommending
"Ethernet mapping into SONET". I am not recommending full "SONET" overhead
processing. I am not recommending "Digital Wrapper" for 10GbE. I am not
recommending any change to the 802.3 frames. I am not recommending any change
to asynchronous transfer nature of 802.3 frames that exists in current full
duplex "Ethernet". I am not recommending something that will cost more than
anything else that will satisfy the current objectives.
I started building LANs with Ethernet almost twenty years ago. About nine years
ago, with a whole lot of effort and support costs, I worked with a LAN that had
an up time of 99.9%. When I went to work on it, it had an up time of less than
75%. I used data from RMON systems to show the network utilization and
requirement for improvements to the network physical infrastructure. I was
given the money needed to improve the network and to provide the performance
needed by the users. The cost of the LAN equipment was minor compared to the
support costs to provide that performance. There was someone available at all
hours to dispatch to any location within the building that was having problems.
LAN support has gotten better with the advent of twisted pair and data
switching.
My working with the telecommunications industry, which currently owns the "WAN"
transport, has taught me something about long term support of transport
services. Just as my experience with the LAN, the cost of the physical
infrastructure equipment is often minor compared to the support costs. The
telecommunications industry has gone to great lengths to reduce the cost of
supporting high bandwidth systems. The single largest support cost was that of
having large numbers of highly qualified people. The second largest cost was
having large numbers of highly qualified people always traveling from site to
site. The next largest largest cost has come to be the network management
systems that have been put in place in order to have a support structure that
does not require the large numbers of highly qualified people or that they
constantly travel from site to site. Also in order to have a service that does
not require large numbers of highly qualified people, protocols were developed
that allowed remote support of the services provided to customers. ALL of the
WAN transport level protocols contain out of band network management
functionality. I am not writing about the non native data protocols such as PPP
or HDLC. I am talking about the native transport signaling protocols such as
D0, D1, D3, and SONET/SDH.
In order for 10000BaseXX 802.3 (10GbE) to be a native WAN transport protocol, it
must incorporate a certain amount of out of band support functionality. At
present the options for that are a "Digital Wrapper", imbedded encoded signaling
similar to what is used for D0/D1, and a scaled down subset of what is used for
SONET/SDH. The "Digital Wrapper" was proposed by specific vendor at OIF. The
"Digital Wrapper" puts an out of band header at the beginning of every data
frame. Each "Wrapper" would contain the same information that would be in a
"SONET/SDH" like overhead. At first this may seem acceptable, until you realize
that it requires additional processing of each data frame, and changes the
nature of the frame by the attachment of the "Wrapper". The imbedded encoded
signaling can provide some amount of a binary information stream. This is used
for single ended local loop services at low bandwidths; providing only remote
status functionality. Bit error rates are calculated outside of the signaling
protocol. It does not provide for interface to interface data path
identification, a content label, any kind of growth potential, or potential
fault management. Both the "Digital Wrapper" and high bandwidth out of band
encoded signaling have not gone through full technology development yet. Both
would require all new equipment in the transport services facilities, increasing
the cost for WAN services over what they are today. Both would require whole
new training and support services dedicated to them, increasing the cost of the
single most expensive part of a network, qualified people.
A subset of "SONET/SDH" functions would use the same signaling as SONET, but not
the same signaling overhead processing. The "Line" and "Section" signaling
overhead processing that exists with SONET/SDH are not necessary for 10GbE. It
would insert the 802.3 frames asynchronously into the data stream similar to how
GbE inserts the frames into a Fibre Channel stream. It would add only 4%
signaling overhead instead of 25% used for Fibre Channel's 8B/10B. It would
leverage the existing SONET/SDH transport technology and services, preventing
additional costs to providing native data WAN transport services. Most of all,
it would prevent the need for whole new training and support systems, preventing
the increase of cost at the most expensive part of a data network.
As to whether HSSG wants to standardize a native WAN/MAN signaling form of 802.3
is between market pull and conservative traditionalism. A WAN/MAN signaled PHY
of 802.3 will have a part in a multi-trillion dollar market. A conservative LAN
only signaled PHY of 802.3 will have a part in a multi-million, perhaps billion
dollar market. Which do you think the marketing organizations of the equipment
vendors and service providers would prefer it to be? As perhaps to only person
in this group to represent a major customer market segment, I would prefer to
have WAN/MAN signaled PHY than to not have it.
Thank you,
Roy Bynum
MCI WorldCom
Jonathan Thatcher wrote:
> Rich,
>
> It is certainly true that our current objectives do not support developing a
> standard supporting Ethernet over SONET. Neither is there an anti-objective
> directing us to not look at support of Ethernet over SONET. Had the later
> been true, I would have called all discussion out-of-order (like was done
> with jumbo frames).
>
> As you suggest, the basis for the discussion is to resolve the issue of
> 10.0000 vs 9.58464 Gb/s. If germane to this decision is a decision on
> whether or not to support Ethernet over SONET, then let us make it. To make
> that decision, we must understand the pro's and con's. As best as I can tell
> the pro is simple: we can directly ship packets over the WAN infrastructure.
> The con's are those things that complicate Ethernet; things that require
> changes to Ethernet; things that add cost to Ethernet.
>
> My interest in a clear, concise list of requirements is that it will focus
> the discussion, provide a less ambiguous backdrop for making decisions, and
> allow the group to progress more rapidly. The process is one we have all
> used many times: 1. write down the list of requirements; 2. prioritize the
> list; 3. identify alternatives; 4. evaluate the cost/benefit; 5. make a
> decision; 6. execute. 7. Iterate as necessary, research as necessary.
>
> The onus of the first step is on the proponents of the idea.
>
> jonathan
>