Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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


Thanks for pointing out this work in 802. I think it is creative and

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.

Menachem Abraham
Columbus Advisors

-----Original Message-----
From: Hugh Barrass <hbarrass@xxxxxxxxx>
Date:         Thu, 31 Aug 2006 13:48:48 
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).