RE: [EFM] RE: OAM functionals
Francois
Surely this is an implementation issue.
There is no IP or VoIP in the raw CPE demarcation unit spec. that I have in
mind.
I agree that in cases where the EFM interface is integrated into a bigger
system then the IP stack can be shared between the management applications
specific to the EFM interface, and those of the rest of the box, so long as
_all_ of the box is owned by the SP. Leaving aside the issue of OAM in-band
or side-band for a moment, I don't think sharing an IP stack between SP OAM
functions and enterprise OAM functions would be acceptable to the SP.
BTW - Howard - I have subscribed to the OAM and P2P reflectors, just
awaiting authorisation. I guess you have about a 1000 of these to check :-).
Best regards
Bob
> -----Original Message-----
> From: Francois Menard [mailto:fmenard@xxxxxxxxxxxxxxx]
> Sent: 27 September 2001 14:28
> To: 'Faye Ly'; 'Harry Hvostov'; bob.barrett@xxxxxxxxxxxxxxx; 'Romascanu,
> Dan (Dan)'; 'Roy Bynum'; ah_smith@xxxxxxxxxxx
> Cc: 'stds-802-3-efm'
> Subject: RE: [EFM] RE: OAM functionals
>
>
> Those whom are worried that the cost of a IP stack may be too high,
> there is a very good chance that an EFM CPE device will need to include
> an IP stack for the purpose of SIP signalling and RTP G.711 audio
> encoding (i.e. VoIP gateway).
>
> -=Francois=-
>
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org] On Behalf Of Faye Ly
> Sent: September 26, 2001 4:18 PM
> To: Harry Hvostov; bob.barrett@xxxxxxxxxxxxxxx; Romascanu, Dan (Dan);
> Roy Bynum; ah_smith@xxxxxxxxxxx
> Cc: stds-802-3-efm
> Subject: RE: [EFM] RE: OAM functionals
>
>
>
> Harry,
>
> Regarding 1, OSS may or may not communicate directly with
> OLT via CORBA/TL1/SNMP. A lot of time it is through the
> EMS. (Element Manager System). The whole discussion on
> this subject, I believe, is out of scope for this working group. (I
> don't mind private email discussion though ...)
>
> Regarding 2, Yes, you are right, SNMP can be used for
> management of the CPE's. SNMP/UDP/IP encapsulated in
> Ether frames is one and SNMP directly over something such
> as LLC is another possibility. This does require SNMP
> agent plus full IP stack supports on each CPE. SNMP also doesn't
> provide any mechanism to throttle the management traffic in case of 1)
> system startup 2) network operator error 3) mal designed NMS/OSS/EMS and
> so on. Diffserv
> might be used to ensure QOS based on SNMP port, but this
> requires even more sophisicated software on CPE. I think
> we are trying to maintain the cost of the CPE low.
>
> Your thoughts?
>
> -faye
>
> -----Original Message-----
> From: Harry Hvostov [mailto:HHvostov@xxxxxxxxxxxx]
> Sent: Wednesday, September 26, 2001 11:57 AM
> To: Faye Ly; bob.barrett@xxxxxxxxxxxxxxx; Romascanu, Dan (Dan); Roy
> Bynum; ah_smith@xxxxxxxxxxx
> Cc: stds-802-3-efm
> Subject: RE: [EFM] RE: OAM functionals
>
>
> Gents,
>
> 1. SP's use OSS systems such as available from Portal S/W, Micromuse and
> others. These are typically distributed applications based on CORBA or
> similar distributed protocols. All this is resolved at the application
> layer.
>
> 2. SNMP is again an application protocol. Hence transport of SNMP
> messages can be done as payload of Ethernet frames - in band. That is
> the method of choice today for cable access.
>
> Harry
>
> -----Original Message-----
> From: Faye Ly [mailto:faye@xxxxxxxxxx]
> Sent: Wednesday, September 26, 2001 10:58 AM
> To: bob.barrett@xxxxxxxxxxxxxxx; Romascanu, Dan (Dan); Roy Bynum;
> ah_smith@xxxxxxxxxxx
> Cc: stds-802-3-efm
> Subject: RE: [EFM] RE: OAM functionals
>
>
>
> Bob,
>
> It seems like we are coming into a conclusion that:
> An OAM mechanism is required to remotely manage the
> CPEs. This mechanism is dedicated for OAM to ensure
> centralized management model (That is, from EMS to OLT
> and thus OLT to all CPE's. We are only interested in
> the segment between OLT and CPE's). The most important
> reason for needing a centralized management model is
> to "avoid truck roll". The network operator from a
> centralized NOC should be able to remotely manage the
> OLT and CPE's.
>
> If I interpreted your email correctly. You are suggesting
> that as long as we have a mechanism, whatever OAM traffic
> that is transported over the mechanism is up to the vendors?
> I think the danger of this is that we might be taking away
> SP's choices on OLT and CPE vendors. But if we say that whatever OAM
> traffic that is transported over the mechanism is out of scope of
> 802.3ah, I totally agree.
>
> -faye
>
> -----Original Message-----
> From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxx]
> Sent: Wednesday, September 26, 2001 10:19 AM
> To: Romascanu, Dan (Dan); Roy Bynum; Faye Ly; ah_smith@xxxxxxxxxxx
> Cc: stds-802-3-efm
> Subject: RE: [EFM] RE: OAM functionals
>
>
> A lot of the detailed management functions are product and vendor
> specific.
>
> The EFM standard should cater only for the basic management functions
> for test and possibly port enable/disable, but some would argue that one
> is product specific and a step too far.
>
> The EFM standard should provide the vendor with a channel down which to
> run their own management application in whatever protocol they choose be
> it UDP with SNMP or something proprietary. The vendors that talk to
> their customers (and some vendors even listen to the replies) will
> probably do better than those that don't :-).
>
> Bob Barrett
>
> > -----Original Message-----
> > From: owner-stds-802-3-efm@majordomo.ieee.org
> > [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of
> Romascanu,
> > Dan (Dan)
> > Sent: 26 September 2001 11:48
> > To: Roy Bynum; Faye Ly; ah_smith@xxxxxxxxxxx
> > Cc: stds-802-3-efm
> > Subject: RE: [EFM] RE: OAM functionals
> >
> >
> >
> > Roy,
> >
> > I am trying to make a slightly different point, or ask a different
> > question. I am actually with you on the issue of insertion of control
> > plane messages in the traffic stream, but...
> > >
> > > To a certain extent, you are right. In some ways you are wrong.
> > >
> > > Upper layer applications can provide a very rich texture of
> > > management and provisioning messaging. The question would be
> > > whether this messaging would
> > > require insertion into the customer revenue traffic stream.
> > > This works for
> > > low margin services such as the Internet. It does not work
> > > for high margin
> > > services such as "Private Line".
> > >
> > > There are a lot of vendors that are trying to redefine "Private
> > > Line". The sad truth is that it is the customer of the service
> > > providers that define
> > > what "Private Line" is. At present, and in the foreseeable future,
> > > "Private Line" is a private, secure, fixed bandwidth
> > > facility, that is not
> > > shared with other "customers". "Private Line" has the
> > > service provider
> > > management out side of the customer's revenue traffic.
> > >
> > >
> >
> > Note that you did not use the word Ethernet even once!
> >
> > My point is that the chassis management issues need to be part of a
> > layer of management that is not Ethernet (or other data layer)
> specific.
> > What needs to be defined is the information model for a control plane
> > (which is not lower layer specific) and than mappings to the specific
> > layers. I sympathize with the need and I understand the requirement,
> but
> > I am not sure that the first part is within our charter. Maybe there
> are
> > other standard groups dealing with this. I am not sure that this group
>
> > is well prepared to deal with chassis management or facilities alarms,
>
> > and I am wondering if you as a service provider would not prefer one
> > single interface to present such information, for all the data layer
> > technologies that run the services that you sell.
> >
> > It might be that
> > Regards,
> >
> > Dan
>