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

In favor of OC-192c

Here is some discussion about the major points in favor of the OC-192c

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
5. SONET out of band management is more secure than in band packet
  -- 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%.