Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] OAM developing......



Sanjeev,
 
Please see my response embedded in <FL> below.  (Also
I have deleted a few lines for ease of reading ...)
 
-faye

	At 06:29 PM 09/17/2001 -0700, Faye Ly wrote:
	>And I tend to agree with you that a dedicated OAM channel or
IPG
	>is needed (or both) to satisfy minimum remote CPE management
	>functionality.  Still an analysis on the OAM traffic is
necessary to
	>tell which traffic should go where? 
	
	From this continuing thread the following OAM traffic could be
thought of:
	
	1. NOC NMS to head-end.
	This is I guess being done (or could be) thru SNMP, TL1 etc...
	Does it concern EFM how it is done?

	<FL> No, it doesn't.  The agent (SNMP or TL1) on the head-end
needs

	to intercept all SNMP (for example) traffic before determine if
a proxy

	request needs to be sent to the CPE.  There are some master/sub
agent

	technologies (extensible agent in SNMPv3) could be useful but
that is

	out of the scope of IEEE 802.3ah.  We should probably keep the
conversation

	on this topic private.
	
	2. head-end to CPE
	Concerns EFM. And I guess is the object of
	the most of OAM discussion (or I guess so)?
	Can be done at layer 1 or layer 2. Mechanism is open.

	<FL> Yes, I believe people are proposing alternatives at the
coming EFM

	meeting.  Please checkout Hiroshi's OAM presentation.  I believe
there are

	objects that have to be transported in layer 1 and objects in
layer 2.  Things

	like 'upgrade' or 'backup' may very well go beyond layer 2 and
higher.
	
	3. NOC NMS to CPE
	Does it concern EFM?
	The head-end could translate it in step 2's format and
	direct on appropriate link and vice-versa. It keeps CPE
	design simple and adds complexity to head-end device.
	

	<FL> Yes, this is a very good issue.  Although so far I haven't
heard anybody

	talking about separate vendors for head-end and CPE.  But this
doesn't mean

	we don't need to consider it.  There are mutliple choices for
the design of the

	head-end (the proxy, in this case).  But again this is out of
the scope of 802.3ah.

	My guess on this topic is that we will determine some basic OAM
transport 

	functionality and let other forum (or each vendor on it's own!)
address the

	rest of the OAM issue.  

	
	4. NOC NMS to Subscriber
	As I guess you had pointed out earlier
	may not really conecern EFM.
	
	>Or is there a requirement for
	>other OAM mechanism?
	
	I guess a dedicated channel and/or ipg etc.. should do it.
	However, what layer OAM is done has its pros and cons.
	OAM done at layer 2 have layer 1 transparency, whereas
	if done at layer 1 gives added security to OAM operation,
	and may not take extra bw for OAM.

	<FL> NOC NMS to Subscriber network device?  Such as

	a router?  Or you actually meant the subscriber line as part

	of the CPE box?  NOC NMS is usually not in charge of the

	subscriber network behind the CPE (or before?)  But

	service activation on the subscriber line that is part of the

	CPE is certainly an issue we need to consider.  

	Thank you. 

	-faye
	
	

winmail.dat