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

Re: [HSSG] channelized vs non-channelized B-MAC



Title: Message
I have a problem with the concept of a "channelized MAC". The 802.3 MAC is defined to operate on a single logical interface. The state machines operate on one packet at a time, and with the exception of the WIS data rate synchronizer, there are no storage buffers defined nor implied between the PHY and the MAC.
 
I have no problem with someone choosing to implement multiple MAC state machines, or a single MAC state machine operating on the far side of some arbitrated FIFOs whose inputs are multiple PHY channels. That sounds like a great product where the line costs greatly outweigh the silicon costs (traditionally telecom), but that should not cause increased costs in an environment where silicon costs outweigh line costs and bandwidth efficiency is not as paramount (traditionally data center).
 
Just a gentle reminder that we're attempting to define (the proposal for) a Standard here, not an architecture nor implementation.
 
-Larry Rubin
 
-----Original Message-----
From: Marcus Duelk [mailto:duelk@xxxxxxxxxx]
Sent: Thursday, August 17, 2006 9:05 AM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: [HSSG] channelized vs non-channelized B-MAC


Hi,

I was thinking a little more about that scalable "B-MAC"
that we have discussed here on the reflector over the past
days and I think that there are two main options:

1) Channelized B-MAC
The MAC has a total throughput of N*10 Gb/s
(for example N=4 or N=10) but is able to control
1..N logical interfaces with rates between N*10 Gb/s
and 10 Gb/s. The electrical interface of the MAC device
towards the network processor would have to be channelized,
for obvious reasons, for example SPI-6 or something similar.
As an example, a 100 Gb/s B-MAC could control two logical
40G ports and two 10G ports. That would mean that this B-MAC
would receive full packets on four ports at the same time. It would
require some buffering to reassemble the packets on the logical 40G ports,
which are constituted physically by four 10G ports across which bit or byte
striping is performed. The B-MAC would also require additional buffer
because it would send packets in either interleaved or non-interleaved mode
over that channelized interface to the NP. For a non-interleaved interface the
buffer size would be larger because the B-MAC would need to be able to
buffer N*jumbo packets per port. Furthermore, it would require a scheduler.
Basically, a channelized B-MAC would not only be a traditional MAC that
is controlling one logical interface but it would become sort sort of little
traffic manager / scheduler. This is an additional complexity that has to be considered.

2) Non-Channelized B-MAC
The MAC has a total throughput of N*10 Gb/s but is able to control
only one logical interface. The service rate on that interface can be anywhere
between 10 Gb/s and N*10 Gb/s. If a 100G B-MAC connects say to a 40G
B-MAC then the negotiated max. service rate is obviously 40G. The 100G B-MAC
would not be able to reuse any of the remaining 60G capacity. These would be
wasted, similarly probably to wasting 90 Mb/s of bandwidth when connecting a
100Base-T device to a 10Base-T device. Functionality and complexity of the MAC
would be more or less what we are used from MAC devices. Buffers would be needed
to compensate differential delay among lanes that belong to that one logical port. The
electrical interface of this type of B-MAC would be non-channelized, of course.

The benefits of the second approach might be lower because even on day one you would have to
pay for 100G MAC and a 100G PMD/PHY even if the max. service rate you need is only 40G,
for example. With the first approach, you would still be able to use 100% of the throughput of
your MAC/PMD devices in this example. In any case, these scalable MACs will allow vendors to
practically offer N*10G MAC and PMD devices with N being practically any number. This, as
Roger pointed out, may lead to a less distinct MAC/PMD standard and may fracture the overall
100G market even more.

Marcus
-- 
___________________________
Marcus Duelk
Bell Labs / Lucent Technologies
Data Optical Networks Research

Crawford Hill HOH R-237
791 Holmdel-Keyport Road
Holmdel, NJ 07733, USA
fon +1 (732) 888-7086
fax +1 (732) 888-7074