RE: [EFM] RE: OAM functionals
Roy -
Again, a touch of research into 802 standards and terminology might help
you to understand that the SNAP is nothing to do with isolating
management/user broadcast domains. See chapter 10 of the 2001 rev
of IEEE Standard 802, which is significantly entitled:
"Protocol discrimination
above the MAC sublayer: Subnetwork Access Protocol (SNAP) and Ethernet
types". No doubt the title will give you a better clue as
to what SNAP is really about (please note the use of the present tense
here also).
Regards,
Tony
At 17:58 26/09/2001 -0500, Roy Bynum wrote:
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