Re: [EFM] EFM - reasons I withdrew my material
Bob,
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
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.