Re: [EFM] OAM - Faye's seven points
Tony,
It all depends on where the additional "traffic" is inserted and how you do
or do not compensate for the additional "traffic". This will dictate how
you can compensate for that additional signal bandwidth and how efficient
the compensation can be. Let us look at some of these.
A. Let us look at using the existing GbE PCS and insert "frames" at the MAC
control sublayer.
1. Without compensation, the "frames" will contend with the revenue traffic
and ultimately reduce the supportable bandwidth that can be provisioned for
revenue. Unless the revenue bandwidth is deliberately reduced, the
"frames" must wait for idle time between revenue traffic, which could be a
problem during service "busy hours". The "frames" management
communications will also be asynchronous, not having any type of fixed time
domain or delivery schedule, because of the variable frame sizes of the
revenue traffic that it must be inserted between. This will make
performance management somewhat unpredictable. Because the "frames" are at
a MAC sublayer, interaction with other 802.x functions may or may not be an
issue and may or may not effect the service model that can be delivered by
the vendors. This would work with the Cu and P2P PMDs, but may present
some issues with the P2MP PMDs. Support for an intelligent full duplex
regenerator/repeater may be problematic.
2. The additional overhead of the management "frames" can be compensated
for by reducing the revenue bandwidth to something below 1.0 Gbps and
inserting idles to provide "space" for the "frames". This could use a
mechanism similar to what was done for 10GbE. The "frames" would still
have asynchronous management communications, but could have a minimum
communications rate. The performance management will still be somewhat
unpredictable. The issue of interaction with other 802.x functions is
still an issue. The PMD support and issues remain the same. Support for
an intelligent regenerator/repeater is still questionable.
B. Let us look at modifying the existing GbE PCS along with inserting
"frames" at the MAC control sublayer.
The bit rate of the existing GbE PCS and the PMDs can be increased to
compensate for the additional bandwidth of the management "frames". This
will maintain the revenue bandwidth. Additional idles would be inserted to
compensate for the difference between the MAC Client transfer rate and the
PCS transfer rate. The idle insertion would have to be in blocks of idles
large enough to provide "space" for the management "frames". In some
implementations this might tend to require a small "delay FIFO" for the
revenue traffic to provide a large enough idle time. The management
"frames" would then replace the inserted idles in the additional
bandwidth. The "frames" would still have a somewhat asynchronous
management communications, but it would be a little more pre-determined
than in the previous examples. The customer revenue traffic might have
slightly higher latency variance because of the "delay FIFO" which might
effect certain high revenue applications such as interactive video. The
interaction with other 802.x functions is still an issue and may have an
effect on the services that can be delivered. The PMDs that can be
supported and the issues with them remain the same as above. Support for
an intelligent regenerator/repeater remains an issue.
C. Let us look at using the existing GbE PCS and add a management "side
band" sublayer below the GbE PCS.
The existing GbE PCS is maintained at the current transfer rate, which
would maintain the revenue rate. A sublayer is inserted between the GbE
PCS and the PMD, similar to what was done for the 10GbE WAN PHY. I will
call the new sublayer "Physical Link Service Overhead Coding Sublayer"
(PLSOCS). I am sure that someone can come up with a better name for
this. Only the bit rates of the PMDs will be increased to compensate for
the additional bandwidth. The overhead bandwidth can be inserted bit by bit
(this may cause problems with code detection, etc.) or as a PHY level "sync
frame" at fixed time intervals, similar to what was done for the 10GbE WAN
PHY. The "sync frame" will be data communications specific, not SONET
specific, although it could have some of the same functional
features. Since the additional bandwidth is below the PCS, none of the
revenue traffic is effected. The management communications has a
pre-determined delivery and a constant time domain for performance
measurement purposes. Because the "side band" is only in the PHY, then the
other MAC Layer issues become mute. Support for other 802.x functions are
now relative to the service model provided by the vendors equipment. There
are no limitations on the types of services that can be delivered by this
type of infrastructure at the edge. Also P2P and P2MP PMDs, and maybe even
CU PMDs,(depending on signal rate increase ratio) can be supported by this
type of OAM implementation, regardless of the MAC addresses or other upper
layer functions. Additional issues of secure OAM communication over P2MP
infrastructure are easier to deal with. "Virtual PHYs" can be created for
support of "Private Line" type services over P2MP infrastructure. Support
for management of an intelligent full duplex regenerator/repeater is available.
Thank you,
Roy Bynum
At 10:06 AM 9/21/01 +0100, Tony Jeffree wrote:
>Roy -
>
>Sounds to me like your statement contravenes the law of conservation of
>free lunches (which states that the quantity of free lunches in the
>universe is a constant, whose value is zero).
>
>If you can increase the bit signal rate to accommodate the OAM overhead,
>surely you can do this anyway, whether the OAM traffic has its own "side
>band" or not. Or am I missing something here?
>
>Regards,
>Tony
>
>At 22:12 20/09/2001 -0500, you wrote:
>
>>Matt,
>>
>>You forget, if the OAM is in the side band, the bit signal rate can be
>>increased to accommodate the additional bandwidth used by the OAM
>>overhead. If the OAM is at the MAC above the existing PCS, then the
>>bandwidth will have to be taken from the revenue traffic.
>>
>>Thank you,
>>Roy Bynum
>>
>>At 08:16 PM 9/20/01 -0400, Matt Squire wrote:
>>
>>
>>>Both OAM and data traffic travel over the same medium. No matter how we
>>>slice it, OAM traffic does reduce the bandwidth available to the user.
>>>One way to cap that effect is to use a dedicated side-band with a
>>>limited bandwidth. An alternate way to cap the effect is to
>>>police/shape the OAM traffic at a layer above. A third alternative is
>>>to use something like a slow protocol which is limited to 5 frames/sec.
>>>
>>>Roy Bynum wrote:
>>> >
>>> > Harry,
>>> >
>>> > I think that Faye is correct. If the OAM is "frame" based, then it will
>>> > share the same bandwidth with the customer traffic. Only if the OAM is
>>> > "side band" will it not share the same bandwidth as the customer traffic.
>>> >
>>> > Thank you,
>>> > Roy Bynum
>>> >
>>> > At 02:31 PM 9/20/01 -0700, Harry Hvostov wrote:
>>> >
>>> > >Faye,
>>> > >
>>> > >What I meant was that the OAM control frames would not be forwarded
>>> outside
>>> > >the ePON network.
>>> > >
>>> > >Harry
>