| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Dave, There is no maximum constraint on the number of 100G PMD lanes to enable break-out from 400G. The constraint is that the number of 400G lanes N = 4 * M, where M is the number of 100G lanes. You gave an example of N = 4 and M = 1.
A third example is 400G made up of 8 x 50G lanes, which can be cleanly broken out into 4x 100G with N = 8 and M = 2, requiring 100G based on 2 x 50G lanes. Chris From: Chalupsky, David [mailto:david.chalupsky@xxxxxxxxx] 10GBASE-SR and 40GBASE-SR4 PMDs are not precisely compatible, but close enough that it is possible for a manufacturer to design a product that is compliant to 10GBASE-SR when configured for 10G mode, and 40GBASE-SR4 when configured for 40G mode. So I don’t think we need PMD specs that are identical at the different operating modes… just similar. An extreme example is the BASE-T family. The 10/100/1000/10GBASE-T specs look completely incompatible, but one can design a product to support & be compliant to more than one speed. That autonegotiation feature sure helps set the mode so the user doesn’t have to… but there is no breakout there, so I digress… Going down the thread aways – I appreciate Jeff Maki’s comment on PSM4. If we were forward thinking in .3bm, and had breakouts in mind, we would have given less credit to PSM4 and more credit to ANY PMD that operates on a single lane. That would give the opportunity to go parallel for 400G and support breakout to 100G. But an interesting dilemma for breakouts is: Are we trying to support breakout between THIS generation and the NEXT generation… or THIS generation and the LAST generation? If it’s the NEXT gen then .3bm needed to have a single lane 100G solution that could go parallel for 400G. If it’s the LAST gen then .3bm would have had the debate about a 25G MAC rate so that 4x25G could break out. For 400G do you want 4x100G to break out to 100G, or provide 400G on one lane so that it can go parallel for 1600G? It looks very difficult to do this every generation without proliferating more MAC data rates. More of a leap frog. dlc From: Brad Booth [mailto:bbooth@xxxxxxxx] Mark, Correct. The rate of the PMDs are compatible, and the PCS/PMA are built upon compatible coding schemes and data rates. What doesn't exist is compliance at the PMD, and 802.3 is a compliance specifications; hence why we have PICS. For example, if we use 10GBASE-SR PMDs with 40GBASE-SR4 MAC/PCS/PMA, then it is my understanding we have a 40GBASE-SR4 compliant part. The reverse is not true if we use the PMD specified for 40GBASE-SR4 for 10GBASE-SR even if the MAC/PCS/PMA is compliant. That's why I believe "compatibility" or "appropriate support" is more important in the PCS/PMA than in the PMD, especially given the limited number of 40G and 100G PMDs that exist between 100m and 10km. Thanks, Brad
Brad, Note that for the 40G-4x10G breakout PMD that is very successful today, the 40GbE PCS and the 10GbE PCS are not compatible, both are based on 64b/66b, but for 40GbE there is the MLD layer and even some of the 64b/66b rules are changed. What makes it successful is the compatible PMD technology (with the same lane rates, not a compatible PCS). The PCS does not need to be compatible to enable this breakout mode. Also I would think that a 4x10GbE breakout of a QSFP would have been very successful on its own even if 40GbE was not compatible due to the density gains that it provides. Thanks, Mark From: Brad Booth [mailto:bbooth@xxxxxxxx] Tom, I agree that if there is a proposal that offers this functionality to the task force (with or without the objective), then it is likely to receive very strong support. Another good point that was made is the area of the market most likely to use this is the data center where we are witnessing use of 40G breakout to 4x10G today. We should note though 40GBASE-SR4 is only 100m/150m OM3/4; whereas, 10GBASE-SR is 300m/400m. PMDs designed to meet only the 40GBASE-SR4 specification will not meet the requirement for 10GBASE-SR; therefore, a "non-standard" port type was created based on the compliance requirements of 10GBASE-SR applied to 40G. If we look at the existing 40G and 100G optical PMDs being considered for data centers today, we have the following list: * 40GBASE-SR4 (100m on OM3, 150m on OM4) * 40GBASE-LR4 (10km on SMF) * 100GBASE-SR10 (100m on OM3, 150m on OM4) * 100GBASE-SR4 (70m on OM3, 100m on OM4) * 100GBASE-LR4 (10km on SMF) At this point in time, the above list would appear to be the only PMDs that may be supported? So what is "appropriate support"? Is it a MAC/PCS/PMA functionality as exists with 40G-4x10G today? Or is there any requirement on PMD? The MAC is specified at 40G and 100G in a bit serial fashion; therefore, it is unlikely that .3bs task force would need to do anything to support the existing MAC specifications. Assuming the task force doesn't want to modify the 40G or 100G PMD list, this would leave the task force with only having to consider modifications to the PCS/PMA Maybe the objective needs to be something like: Provide appropriate PCS/PMA support for breakout functionality to 40 and/or 100G. Thanks, On Thu, Oct 17, 2013 at 1:23 PM, Tom Palkert <tpalkert@xxxxxxxx> wrote: I like the wording and tend to support Mr. Dudek. The term “appropriate support for breakout” seems generic enough that it will not force us down the path of 40G SR compliance while at the same time it should force us to address the issue in any proposals that are made. In response to Brad’s thoughtful comments I would like to think that a proposal that shows full backwards compatibility to an existing 40G or 100G variant at zero additional technical risk, zero additional cost etc to the 400G proposal would get strong support. The other extreme would be a high power, high risk, high relative cost proposal with no backwards compatibility that would not receive support. If anyone has proposed wording that is better I would like to hear something. Tom From: Brad Booth [mailto:bbooth@xxxxxxxx] John, While I understand the intent of this objective (and agree implementation of this functionality would be good to have), I'm not sure how the task force satisfies this objective. To provide breakout functionality such as 40G operating as 4x10G, the device operating in 40G mode complies with the 40G standard and when the device operates in 4x10G mode, does each 10G portion comply with the 10G standard? As an example, 40GBASE-SR4 has a different reach requirement than a 4x10GBASE-SR. Which reach requirement is required for compliance? This is strictly an implementation decision. There is nothing within the 40G specification or the 10G specification that implies any requirement for 40G to breakout to 4x10G, which permits some flexibility in implementations. Considering there are already 40G MAC/PHY and 100G MAC/PHY drafts or specifications in 802.3, how does a 400G MAC/PHY standard create compliance with those specifications? Does the "provide appropriate support" give the task force the ability to create new 40G MAC/PHY or 100G MAC/PHY specifications that are derivatives of the 400G MAC/PHY specifications? For example, if the 400G SG has a 2 km SMF objective, does that mean that to provide appropriate support for breakout that there would be the ability to create a 100G 2km SMF PMD? Implementation of breakout functionality is a great way to provide a migration path and I believe the TF should take that into consideration when selecting PHY proposals; I'm just not sure how the study group defines it as objective the TF can show has been met. Your thoughts/feedback on this would be greatly appreciated. Thanks, Brad On Wed, Oct 16, 2013 at 6:15 AM, John D'Ambrosia <John_DAmbrosia@xxxxxxxx> wrote: All, Per our call last week, what are the thoughts on the wording of this as a proposed objective – Provide appropriate support for breakout functionality to 40G and / or 100G There was some concern about potential impact or unintended consequences that people wanted to see this wording to discuss further. Regards, John No virus found in this message. |