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

Re: [EFM] OAM - Faye's seven points


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?
>At 22:12 20/09/2001 -0500, you wrote:
>>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