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

Re: [HSSG] Bit rates and rate matching


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.

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).