RE: [EFM] Re: OAM Transport Proposal
Bob,
Actually OAMiF does provide and equivalent to an embedded overhead
channel. It is the 108 bytes of data in the frame payload. What goes
into that 108 bytes has not even begun to be defined. As part of that
on-going definition, a Management Control Channel can be defined. That MCC
will act as an inband version of an EOC, providing the same intermediate
system management that a standard EOC provides.
The fact that 802.3 does not define any functionality above the MAC client
interface limits what can and can not be in scope. Within the concept of
OAMiF however, provisions can be made that will allow other organizations
to standardize on the use of what 802.3 does provide. This will be the
case of the MCC/EOC, if it gets done.
Thank you,
Roy Bynum
At 04:57 AM 4/27/2002 +0100, Bob Barrett wrote:
>Sorry Roy, I can't follow the logic here.
>
> >Intermediate network elements are addressed/sub-addressed through the
> >protocol on the embedded overhead channel, not in the basic carrier
> >protocol.
>
>EFM OAM doesn't have an embedded overhead channel (I guess that's one of the
>points that you are trying to make).
>
>Your are correct that the management of intermediate network elements are
>out of scope for EFM OAM.
>
>However, what I don't get is that whilst you are normally very pro the real
>market need, (and management of intermediate network elements is a real
>market need), you are against it here.
>
>Is the message that you actually support it, and see the requirement as
>being met by the adoption of a proposal that includes an embedded overhead
>channel, and furthermore see the need for a change in the objectives of EFM
>OAM so that the subject is no longer out of scope. If that is the message
>then I would support it, but I would also suggest that we would be wasting
>our time to take it any further in EFM at this time, without active support
>from at least three major ILEC or IXC customers.
>
>Best regards
>
>Bob
>
>-----Original Message-----
>From: owner-stds-802-3-efm@majordomo.ieee.org
>[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Roy Bynum
>Sent: 25 April 2002 14:13
>To: bob.barrett@xxxxxxxxxxxxxxxxxx; mattsquire@xxxxxxx;
>stds-802-3-efm@ieee.org; sergiu@nbase-xyplex.com
>Subject: RE: [EFM] Re: OAM Transport Proposal
>
>
>
>Bob,
>
>Intermediate network elements are addressed/sub-addressed through the
>protocol on the embedded overhead channel, not in the basic carrier
>protocol. Look at the support for "repeaters" in the xDSL standards that
>ITU-T provided and have been put up on the EFM web page.
>
>EFM OAM, in providing the basic carrier protocol does not need to address
>the issue of addressing/sub-addressing "multiple "full duplex
>repeaters"". It is not a requirement that this Task Force needs to get
>even close to.
>
>By use of the PHY ID was to provide channelized facilities to support
>unbundled broad band leased circuit services. The MCC in the out of band
>OAM overhead provided the management channel for the intermediate network
>elements, just like what is done in the industry today.
>
>Thank you,
>Roy Bynum
>
>At 07:09 AM 4/25/2002 +0100, Bob Barrett wrote:
> >Roy
> >
> >There is a requirement to manage multiple "full duplex repeaters" and thus
>a
> >need for sub-addressing, hence the really useful nature of leveraging the
> >PHY ID from EPON for this purpose, either that or there would be a need for
> >sub-addressing of the OAMiF frame in some standard way.
> >
> >Best regards
> >
> >Bob
> >
> >-----Original Message-----
> >From: owner-stds-802-3-efm@majordomo.ieee.org
> >[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Roy Bynum
> >Sent: 25 April 2002 01:10
> >To: mattsquire@acm.org; stds-802-3-efm@ieee.org; sergiu@nbase-xyplex.com
> >Subject: RE: [EFM] Re: OAM Transport Proposal
> >
> >
> >
> >Matt,
> >
> >If item 3 is correct, then OAMiF can be used to manage "full duplex
> >repeaters" because of the ability to evaluate the contents of the OAM Frame
> >for the contents of the MCC. The MCC can be used as an embedded overhead
> >channel (EOC). That will allow MAC addressing of the repeater management
> >port through the EOC, or the use of HDLC, which is currently standard in
> >the industry.
> >
> >Thank you,
> >Roy Bynum
> >
> >At 05:54 PM 4/24/2002 -0400, Matt Squire wrote:
> >
> >
> > >We've had many threads on repeaters, media converters, regenerators, and
> > >the like throughout the evolution of this work. The following are my
> > >recollections as reported by others (Geoff, Tony, etc.). Pls correct
> > >anything I misrepresent.
> > >
> > >1) 802.3 defines half-duplex repeaters.
> > >2) 802.3 does not define full-duplex repeaters.
> > >3) What some people commonly refer to as full duplex repeaters are
> > >actually 2-port MAC frame forwarders (802.1D relays?).
> > >4) 802.3 does not define optical regenerators (ie protocol agnostic
> > >signal regeneration).
> > >5) 802.3 does not define media converters.
> > >
> > >Since using the preamble to carry signaling is intended as a full-duplex
> > >function only, I short-cut to the conclusion that preamble has no
> > >applicability to any repeater, regenerator, or media converter as
> > >defined by 802.3. Before we could figure out how to address this
> > >full-duplex repeater function that does not exist in 802.3, it would
> > >have to be properly defined. Thats all I was getting at.
> > >
> > >People are concerned, people are thinking about it, but it has been
> > >difficult to address because of the terminology confusion and our
> > >scope.
> > >
> > >- Matt
> > >
> > > >
> > > >Hi Matt and all,
> > > >
> > > >I will address only the issues related to 5) Regenerators and
> > > >converters.
> > > >First of all I want to assume that we consider all the 802.3
> > > >interfaces,
> > > >including 100 Mbps and GbE.
> > > >
> > > >802,3 defines the above entities. Look at 27. Repeater for 100
> > > >Mbps baseband
> > > >networks.
> > > >The devices that we address are two port full duplex repeaters.
> > > >Also 802.3ab makes extensive references to repeater implementations.
> > > >
> > > >And again, the moment that we defined any preamble based
> > > >capability - see
> > > >page 9
> > > >of the baseline presentation - we decided to make the
> > > >appropraite changes
> > > >for preamble
> > > >support.
> > > >
> > > >I also had some questions, regarding packet based functionality.
> > > >This functionality I assume is not fully contained in the new
> > > >MAC (like the
> > > >packet based
> > > >flow control functionality). It requires an external processing unit
> > > >(CPU+MAC, HW, or whatever).
> > > >What is the level of service in the case of a busy link (even
> > > >malfunctioning
> > > >due to a broadcast
> > > >storm, etc.)? Do we lose the management capacity for some time?
> > > >Wouldn't an out-of-band mechanism (like preamble) be valuable
> > > >in order to
> > > >provide even the
> > > >basic management information as defined in the suzuki proposal?
> > > >
> > > >I still think that the compromise should be a functional
> > > >compromise, that
> > > >provide the
> > > >best of the two worlds meaning that the capabilities
> > > >negotiations should
> > > >include four
> > > >options, and should be done also at the lowest level...
> > > >
> > > >Sergiu
> > > >
> > > >