Re: [HSSG] Bit rates and rate matching
Please note that 802.3ar rate limiting is not yet part
of IEEE Std 802.3. The project has undergone significant
change in recent months, including substantial revisions
to the PAR, 5 Criteria, and objectives, as well as the
draft itself. The revised PAR, 5 Criteria, and objectives
have not yet been approved by the 802.3 working group,
and the draft has not yet undergone a working group ballot.
At the last plenary session in July, there was considerable
debate regarding the future of this project, with no clear
consensus as to how to proceed, other than a decision to
postpone action on the project until the November plenary.
In my opinion, it would be premature to incorporate 802.3ar
into the architecture for higher speed operation.
There are other architectural models that do not rely on
802.3ar, and that allow the MAC to operate at any desired
rate. Rather than get into these in an email thread, I
believe that this is a good subject for presentations and
discussion in the study group and subsequent task force.
Howard Frazier
Broadcom Corporation
-----Original Message-----
From: Menachem Abraham [mailto:mabraham@xxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, August 30, 2006 5:00 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] Bit rates and rate matching
Hugh,
Thanks for pointing out this work in 802. I think it is creative and
useful.
Based on some specific customer experience from the past, I am concerned
that some of the perfection oriented end users / carrier labs which
evaluate long haul transport products will view performance at less than
802.3 wire speed / min IPG, as a flaw of the transport products.
Let's hope these customers will be a little more flexible if 802 says it
is legit.
Regards,
Menachem
Menachem Abraham
Columbus Advisors
-----Original Message-----
From: Hugh Barrass <hbarrass@xxxxxxxxx>
Date: Thu, 31 Aug 2006 13:48:48
To:STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: [HSSG] Bit rates and rate matching
John and speed-freaks,
I've seen a few reflector mails on the topic of specific bit rates for
the higher speed Ethernet definitions. In particular, some people have
asked that the IEEE consider matching the bit rates to other standards
for the benefit of compatible services. I've also seen a few posts
regarding the use (or otherwise) of FEC for the higher speed links -
particularly for long haul or backbone links.
I would like the folk involved in this group to take a look at the rate
control mechanisms defined for 802.3ar. This defines an IPG stretch
mechanism similar to the one defined for 802.3ae for WAN compatibility
but generalized to accommodate arbitrary rate mismatches. The goal of
this mechanism is to allow a single speed at the MAC and the MAC-PHY
interface to connect through a device that has a lower rate constriction
while keeping the buffering requirements to less than one maximum frame.
If such a mechanism were adopted it would cater for 10G payload rate to
connect through OC192, 4 x 10G to connect through OC768 as well as other
possible scenarios, such as 100G connecting through 80G OTN links. In
addition it allows for MACs developed for non-FEC LAN links to
accommodate long haul modules (or repeaters) that add FEC overhead -
without needing to know in advance the nature of the FEC added. It can
also allow link security appliances to add encryption and security
overheads without the source device needing to understand the details of
the security encapsulation.
When 802.1 reviewed this approach, particularly in conjunction with
their Two Port MAC Relay (802.1aj) specification they thought that it
was the best and most general solution to the problem of TPMR devices
that have any form of asymmetry of link rate. Although it was commented
that support for LLDP-MED in addition could allow seamless installation
and operation of these systems.
If anyone requires details of the 802.3ar proposals or project status,
feel free to contact myself or Kevin Daines (chair of the Task Force).
Hugh.