In favor of OC-192c
Here is some discussion about the major points in favor of the OC-192c
approach.
1. Leverage OC-192c components.
-- The expectation in 802.3 is that the volume of
802.3 equipment would be enough for CUSTOMIZING
designs for new standards to be justified.
In the recent past (within the vesting time of
many 802.3 participants) not just new designs, but
entire companies have been succesfully targeted to
new ethernet standards.
2. Leverage OC-192c repeaters to get to longer distances.
-- The entire question of connecting ethernet across "non-native"
media has been addressed in 802.1 remote bridges. Anyone
may choose to bridge MAC frames across different media
at different speeds. Congestion and flow control issues
have been addressed in that context.
-- See discussion about point 3 below on repeater managment.
3. Using OC-192c would bring the benefit of SONET OAM&P
-- The LAN and data packet world has working management systems.
Extending those approaches along with the packet media
would be more natural than embracing a second management
infrastructure. I think that it's been shown that such
an extension need not be viewed as an unreasonably expensive
endeavor, especially to support repeater chains.
Data network management infrastructures already support
everything other than these repeater chains.
4. Not using OC-192c would leave ethernet disconnected from the
world as a set of islands in a sea of higher volume components.
-- See discussion about Point 1 above. Ethernet has been extremely
as a set of LAN islands in the sea of communications.
-- See discussion about point 2 above. The protocol used on the
"non-native" links for remote bridges can be standardized
for interoperability, but need not be defined in the base 802.3
standard.
5. SONET out of band management is more secure than in band packet
management
-- No reason to assume that someone with access to the signal to tap
has no access to parse the standard frame format.
In the packet world, 802.10, VPNs and encryption are more typically
used for security concerns
There is another issue with choosing OC-192c technology first and
driving the goals with that choice.
Once the signalling rate is chosen to fit in the OC-192c payload,
trying to get the 10Gb/s throughput would require a new signalling format
with a signficant departure from the other 802.3 formats.
Having a length at the beginning of the packet (which is what it
would take) should be discussed with this technology choice, not
left as a forced decision made unwittingly.
Delving into the details about how a HOLD function might
be implemented between the MAC/PLS/PHY/PMD layers seem premature.
As pointed out earlier, thinking about the OC-192c span as a
remote bridge span is one approach. Another previous comment
that with most PMD/PHY implementations sourcing the clock from
the PMD, slight variation in the clock need not cause any disruption
of the MAC itself, particularly in a full duplex link. In such
a link (no CS, no MA, no CD) the remaining interesting timer
seems to be for the IPG, and this can be defined at the nominal
throughput rate's bit time, allowing the actual signalling rate to
deviate the required 5%.