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
   It seems to me the MAC interface could be very similar to XGMII except it would deliver 40 data octets and 40 control bits (representing either MAC frame data or idle) per 3.2ns clock cycle rather than 4. If you wanted to scale down the data-rate you would just slow down the clock. The real challenge in implementing the MAC will be doing the CRC calculation in the required time-frame.

From: John DAmbrosia [mailto:jdambrosia@xxxxxxxxxxxxxxxxxxx]
Sent: 18 August 2006 01:02
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] channelized vs non-channelized B-MAC


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:










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


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.


-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


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