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@CISCO.COM>
Date: Thu, 31 Aug 2006 13:48:48
To:STDS-802-3-HSSG@listserv.ieee.org
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.