RE: [EFM] EFM - reasons I withdrew my material

["Jian Song" <jsong@xxxxxxxxxx>]

Title: RE: [EFM] EPON TDMA - Small timeslots/DBA

Bob,

 

You just asked a couple of excellent questions. Follows are my contributions to the discussion (E-PON specific though).

 

1) OAM:

 

The key question is the PHY compatibility with GbE. I would tend to think that the compatibility referred here is "backward compatibility", meaning that the NEW E-PON PHY can be used in a "degenerated' mode to support P2P as you suggested. E-PON will, inevitably, need different PHY.

 

Also E-PON will need different link (PHY) level OAM support, it is ONLY logical to provide "side-band" channels for this type of OAM. The link level OAM support is logically equivalent to "auto-negotiation" in the current GbE.

 

This function should potentially support PON relevant optical parameters, such as the length of preamble, guard time, even optical power levels. With this function, different grades of optics can be designed in to leverage greater availability and, hence, lower costs of such parts. The ranging process, specific to PON operation, can also be partially supported by this function.  

 

Unlike auto-negotiation, however, this channel could be implemented as repeated short time slots to provide continuous support for real-time OAMs, like ranging/tuning, PM, change of (BW) configuration, etc.  For non-real-time OAM&P, an in-band channel would be a better idea so system configurations, statistics, long history PMs, etc, can use existing technologies, such as SNMP.  

 

2) Native TDM support:

 

This is not really something that should be considered in 802.3, just my personal opinion. However, from the market pull from our carrier customers, TDM has been identified an essential services they intend to support for quite some time using any kind of PON.  Because of the proposed marriage between 802.3 MAC and TDM TC sublayer for E-PON, there may be a good chance to use this flexibility point  for individual equipment vendors to decide to support native TDM.

 

For strict E-PON operation, the TDM channel is disabled and the system should be fully compliant with the new standard. For TDM-enhanced operation, TDM traffic can go side by side with Ethernet packet.  Of cause, this is an extremely simplified description. There are a lot of technical challenges to actually design a system like that.

 

 

Regards,

 

Jian

 

Salira Systems

 

The contents of this e-mail do not represent the official view of Salira Optical Network Systems. Salira System is neither obligated nor committed to use any information detailed in this e-mail in their product design.

-----Original Message-----
From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxx]
Sent: Sunday, July 15, 2001 7:35 AM
To: stds-802-3-efm@ieee.org
Subject: [EFM] EFM - reasons I withdrew my material

Two reasons why I withdrew:

1) The material as submitted did not match the revised approach that I want to take to this topic.

2) Having re-read the minutes of the interim, and paid particular attention to the motion madness surrounding the issue of the OAM side band, I thought it better to await the outcome of that issue before raising my topic. 

If the EFM task force decides that there will be no change to the p2p PHY to enable side band OAM, then my suggestion of a 50M-100M uncommitted side band (in which vendors could implement what they wish e.g. pseudo isochronos circuits) is dead in the water. Even the smallest change to the PHY for OAM would mean new PHY chips in order to get the economies that we (the group) are always quoting as a justification for the economic feasibility. Furthermore, if the PHY were to be changed (and new PHY chips were required) then it would be very easy to add an uncommitted side band at the PHY level with a small gate count and very little cost.

Now, there is another way that this approach could find its way into EFM. If we look at the degenerate case of EPON i.e. a two node system, that is effectively p2p. I would envisage that it will be necessary to re-define the PHY for EPON, in order to support the contention mechanism without changing the MAC (if the MAC is inviolate and EFM can't do anything above it that only leaves the PHY doesn't it). Most EPON vendors are specifying systems that support both packet and TDM / circuit service points, one way or another.

My assertion is that it is much simpler to support circuits in side bands rather than as circuit emulations over packet with QoS. At the PHY it's a low gate count and a bounded delay issue, 'bits in equals bits out' with minimal buffering. At the MAC (or above) it is no longer a 'bits in equals bits out' issue. It becomes a T1/E1 frame into a packet issue, and by the way how many frames do we have to buffer to overcome the MAC latency and stat. muxing (even with tags). Probably 100 times as many gates required (not that I am an engineer you understand, but my engineers have implemented both a PHY approach and a MAC circuit emulation solution, and that is the information that I am getting back from them).

There is circuit support in the metro right now in the form of SONET/SDH infrastructure. If the carrier / service provider removes the circuits that carry data from this SONET/SDH infrastructure and puts them (the data services) onto a packet based metro using switches and routers (probably on a separate lambda), then the circuit capacity freed up on the current (paid for) SONET/SDH infrastructure can be used to generate additional revenue from circuits. The business case for putting circuits over packets in the metro is not as compelling for an ILEC as it is (was??) for a CLEC. Any comments from xLECs on this point would be welcomed.

Best regards

Bob

 

 

 

 

If the group decides  not  to change the 1GE p2p PHY to include an OAM side band then I have a reasonable chance by taking a position along the lines of 'if we are going to change the PHY then we may as well add some real value'. I need to talk with Tony Jeffree about the architectural implications of my proposal too, as again, there is no point in pitching it if 802.1 will rule it as being outside of the scope of 802.