RE: [EFM] RE: OAM functionals
Bob,
SNMPv3 includes strong authentication mechanisms to protect against
unauthorized access to the managed network element and its resources. This
is done to provide multiple selective access to the NE from a variety of
element management systems with various degrees of access authorization
(e.g. administrative, operator, and other views).
This type of security may well suffice, although it is not inconceivable to
have two TCP/IP stacks concurrently running on a single host.
Harry
-----Original Message-----
From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxx]
Sent: Thursday, September 27, 2001 8:26 AM
To: fmenard@xxxxxxxxxxxxxxx; 'Faye Ly'; 'Harry Hvostov'; 'Romascanu, Dan
(Dan)'; 'Roy Bynum'; ah_smith@xxxxxxxxxxx
Cc: 'stds-802-3-efm'
Subject: 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
>