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

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


I have been unable to find any minutes from the July meeting.  I do not remember a motion that would specifically exclude a "side band" or other "in band" to signal, but "out of band" to customer traffic type of OAM channel in P2P.  As a service provider, without that functionality, this would not be able to support a subscription service network and thus would fail to meet the primary objective of the SG/TF.

Thank you,
Roy Bynum

At 03:35 PM 7/15/01 +0100, Bob Barrett wrote:

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






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.