RE: [EFM] RE: OAM functionals
Harry,
As a side note, ha, ha, ever hear of Sub Network Access Protocol. It was
an extension of the LLC type 1/2 header. It was a very old way of
isolating the management broadcast domain from the user broadcast domains. ;-)
Roy
At 03:34 PM 9/26/01 -0700, Harry Hvostov wrote:
>Faye,
>
>I think you are confusing where the the various communication
>mechanisms/protocols fit into the network management. Here is a brief
>exposition:
>
>1. Most modern EMS are distributed applications that use CORBA as the
>application communication mechanism for client/server communication. EMS's
>written in Java only could use RMI (remote method invocation) and/or EJB
>(enterprise Java Beans) mechanisms instead.
>
>2. SNMP is an application protocol that EMS components use to talk to
>network elements with SNMP agents. An EMS server may have a communication
>layer encapsulating SNMP protocol.
>
>3. UDP packets are transport layer (Layer 4) PDUs. So the proper
>encapsulation for SNMP messages on TCP/IP networks (note that SNMP is UDP/IP
>application protocol) is:
>
>SNMP ->UDP->IP->datalink protocol framing -> PHY
>
>What I have stated is that, since EFM = Ethernet, the natural choice of
>datalink protocol encapsulation for management messages is Ethernet frames.
>I have never seen SNMP messages (application layer!) directly encapsulated
>into LLC frames, but that could be an option.
>
>4. Application of QoS mechanisms such as DiffServ DSPC marking is
>straightforward.
>
>5. Most commercial EMS systems have sufficient application layer
>intelligence to throttle management traffic during network element system
>startup. This does not impact CPE equipment costs - aside from the normal
>SNMP agent support.
>
>Harry
>
>-----Original Message-----
>From: Faye Ly [mailto:faye@xxxxxxxxxx]
>Sent: Wednesday, September 26, 2001 1: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