Marcus,
My interpretation of the idea behind the
scalable MAC was related to the creation of a generic aggregation layer between
the MAC and the PCS that would allow the bonding of 1:N lanes. It was
then suggested that since it is 1:N lanes, the solution could be scaled to any
number of lanes between 1 and N with the intent of creating a MAC data rate
greater than 10 Gb/s. This is what was presented at the CFI.
I have been observing the conversation over
the past two days regarding the excess capacity that might exist in a scalable
solution and was waiting to see
- if the
conversation would gravitate towards an objective in line with the CFI
- further
discussion / definition of the scalable interface.
I am seeing further discussion about what
some may think are potential limitations of a scaleable MAC. That is of
relevance to this effort, but the proposal of a “channelized” MAC is
something that, as Geoff had said when discussing jumbo frames – “would
be an effort towards a goal that was not even mentioned in the Call For
Interest nor mentioned in the discussion leading up to the vote on forming the
Study Group.”
I would prefer the group focus on objectives that are
related to what was presented in the CFI:
Thanks!
John
From: Marcus Duelk [mailto:duelk@xxxxxxxxxx]
Sent: Thursday, August 17, 2006
5:59 PM
To:
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] channelized vs
non-channelized B-MAC
Hi Larry,
thanks for your feedback.
The purpose of my email was to raise the attention to these
two options for implementing the MAC. I agree that traditional
802.3 MACs only work on one logical interface. If this tradition
should be maintained then it means a decision for a scalable but
non-channelized MAC.
I have the feeling that in this case the whole initial idea of a scalable
MAC is somewhat less useful. No matter what, the MAC will have
a certain throughput (N*10G), same goes for any integrated N*10G
PMD device, so even on day one you will have to pay for the maximum
service rate N*10G for optics and electronics, even if you start with
a lower service rate that you gradually increase up to N. What would
be the benefits ? I see some benefits if you have multiple 10G PMDs
that you control with one N*10G MAC. In this case, your start-up
costs would only cover the electronics, and you would pay for the optics
as needed.
Don't know whether that was the idea of the scalable MAC ...
Marcus
Larry Rubin wrote:
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.
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
--
___________________________
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