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

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




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?

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.

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. 

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. 

Thanks,
Sanjeev

> 
>-faye
> 
>-----Original Message----- 
>From: Sanjeev Mahalawat 
>Sent: Mon 9/17/2001 3:13 PM 
>To: Faye Ly 
>Cc: stds-802-3-efm@ieee.org 
>Subject: RE: [EFM] OAM developing Geoff's observation.
>
>
>
>	Faye,
>	
>	At 11:49 AM 09/17/2001 -0700, Faye Ly wrote:
>	>PPP seemed to be a separate issue than OAM channels (or not)
>	>and I would suggest separating them as two topics.  One is
>determining
>	>where the subscriber termination point is and thus dictating
>where
>	>the 'subscriber service activation point' is.
>	
>	Agreed. And this would depend upon the network model.
>	And again, what really are the requiremnets, to choose the right
>protocol?
>	1. ISP and EFMSP network model?
>	2. What are the services?
>	3. Who provides what service without conflict?
>	4. Security.
>	5. Media independence.
>	6. More...
>	
>	Conventionally, the ethernet has been in a secure etherprise
>	network where evreybody is behind a firewall. The users are
>either
>	trusted (for each other) and if not than segregated with VLANs.
>	The IP services (IP address etc) is provided by DHCP and
>	mac addresses by ARP and so on.
>	
>	The EFM SP network is sort of equaivalent to the enterprise
>	network but the users are not trsuted (from each other).
>	There may not be enough VLANs to segregated each user
>	and each ISP in an EFM SP network.
>	
>	Though most of these are achevied by PPPoE or (PPPoX)
>	but is it necessary to stack too many protocol over each other?
>	There may be better ways but again the EFM SP requirement may
>dominate.
>	
>	
>	>The other is a pure OAM traffic transport mechanism
>determination.
>	>For this topic, I would vote for first analyzing different OAM
>traffic
>	>and figuring out their requirements.  Before deciding what is
>the
>	>best fitted mechanism or mechanismS.  Another thing that is not
>clear
>	>to me is that note that OAM request (SNMP, CORBA, TL1 ...) is
>orginated
>	>from the NOC, which is far away from EFM in most of the cases.
>We are
>	>talking about having the headend device somehow either
>translate or
>	>relay the traffic to the CPE, aren't we?
>	
>	What I was trying to suggest with the example that in addition
>to defect, protection
>	etc.. bits, there may be provided a DCC (data communication
>channel) that
>	be used to carry over any protocol over it for OAM purpose.
>	
>	Thanks,
>	Sanjeev
>	
>	>-faye   
>	>
>	>-----Original Message-----
>	>From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
>	>Sent: Monday, September 17, 2001 11:24 AM
>	>To: Faye Ly
>	>Cc: stds-802-3-efm@ieee.org
>	>Subject: RE: [EFM] OAM developing Geoff's observation.
>	>
>	>
>	>Faye,
>	>
>	>I am saying that EFM SPs must be equally involved and have
>	>a say in this that would bring about an OAM mechanism that
>would make
>	>sense for them to deploy it. Since, access is very cost
>sensitive
>	>and lots of disparate technologies have been developed,
>deployed
>	>and seems still there is not a good solution.
>	>
>	>Now, ethernet is coming to play in this arena with its
>simplicity and
>	>cost
>	>effectiveness ($/mbit) argument. But Ethernet does not have OAM
>	>functionality
>	>as is in the SONET/SDH networks. Since SPs do know how the OAM
>	>works it would be prudent to incorporate OAM in Etherent in
>most
>	>effiecient
>	>way that make sense to deploy it.
>	>
>	>Think about Ethernet everywhere! If OAM is develpoed that would
>work
>	>in access and metro etherenet seemelssly, wouldn't it make
>sense?
>	>Just as an example, if EFM develops SONET like channel, then I
>guess
>	>you could run any protocol over that channel as convenient
>(PPP,
>	>HDLC...),
>	>if wanted.
>	> 
>	>Thanks,
>	>Sanjeev
>	>
>	>At 10:36 AM 09/17/2001 -0700, Faye Ly wrote:
>	>>Sanjeev,
>	>>
>	>>Are you saying that we need the requirements from the carriers
>first
>	>>before
>	>>deciding on a (or multiple) mechanisms for transporting OAM&P
>traffic?
>	>>
>	>>-faye
>	>>
>	>>-----Original Message-----
>	>>From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
>	>>Sent: Saturday, September 15, 2001 11:41 AM
>	>>To: bob.barrett@xxxxxxxxxxxxxxx; Geoff Thompson;
>fkittred@xxxxxxx
>	>>Cc: stds-802-3-efm@ieee.org
>	>>Subject: RE: [EFM] OAM developing Geoff's observation.
>	>>
>	>>
>	>>
>	>>Hi Bob,
>	>>
>	>>I think following issues for OAM in EFM to decide in-band or
>side-band
>	>>OAM support.
>	>>
>	>>1. What needs to be done for OAM in 802.3ah? Influences
>in-band or
>	>>side-band decision?
>	>>
>	>>2. How OAM is done?
>	>>Since, 802.3ah has extension EFM (etherenet in first mile),
>with that
>	>>there seems to be two choices:
>	>>   a) Both layer 1 and layer 2 are Ethernet, or
>	>>   b) layer 1 does not have to be Ethernet, but layer 2 is
>Ethernet.
>	>>
>	>>In case a) there are further couple of choices:
>	>>i)  All the existing Ethernet PHYs and any new 802.3 PHY MUST
>be
>	>>supported.
>	>>ii) A new EFM phy will be developed and MUST be supported, and
>support
>	>>for any
>	>>    802.3 Ethernet PHY is optional.
>	>>
>	>>If only a) and ii) are the objectives then either in-band or
>side-band
>	>>can achieve the
>	>>objective with side-band (preamble/ipg) being more beneficial.
>If b)
>	>and
>	>>i) are objectives
>	>>then I am not sure there are many choices other than in-band.
>	>>
>	>>Now, if EFM Service Providers want side-band (preamble/ipg or
>any other
>	>>added SONET/SDH like)
>	>>solution (and hence a requirement) then objectives can be
>accordingly,
>	>>i.e. a) and ii) from above.
>	>>
>	>>But, if the method is not specified and left to open then I
>guess
>	>>everybody is open to non-interoperability.
>	>>
>	>>Thanks,
>	>>Sanjeev Mahalawat
>	>>
>	>>
>	>>At 01:36 PM 09/15/2001 +0100, Bob Barrett wrote:
>	>>>
>	>>>I'm late in on this thread, so there may be a similar comment
>further
>	>>up my
>	>>>in-box from somebody else.
>	>>>
>	>>>Geoff's observation is pretty fundamental:
>	>>>
>	>>>> My expectation is that the demarcation device will probably
>end
>	>>>> up with an IP address in order to support:
>	>>>>          SNMP for OA&M
>	>>>>          Firewall services for the subscriber
>	>>>>
>	>>>> (That issue is, of course, beyond our scope)
>	>>>
>	>>>The logical conclusion of this observation is that EFM should
>make the
>	>>OAM
>	>>>at layer two as simplistic as possible fulfilling only the
>basic
>	>>>requirements i.e. limited number of managed objects and
>limited echo
>	>>(L2
>	>>>ping) test. Vendors can then leverage ietf standards (note:
>the users
>	>>tends
>	>>>to like these) to implement ietf style 'standard' management
>	>functions.
>	>>>Isn't that what we all have in mind anyway :-).
>	>>>
>	>>>The open question then is will the service provider market
>accept
>	>>in-band
>	>>>management i.e. management IP frames mixed with user traffic,
>or is
>	>>there a
>	>>>real requirement for a side-band channel. If EFM does need to
>include
>	>a
>	>>side
>	>>>band channel then all that it needs to be is a communications
>channel
>	>>(bit
>	>>>stream), probably squeezed in the preamble or the IPG (we can
>debate
>	>>that
>	>>>choice for a while). Vendors can then implement either a
>standards
>	>>based
>	>>>method of comms over that channel or do there own thing.
>Personally I
>	>>would
>	>>>expect vendors to choose something like IP over PPP for this.
>	>>>
>	>>>I can wrap this all up in a presentation for the next meeting
>if
>	>>required.
>	>>>
>	>>>(Just seen Geoff's comment on this in response to Roy's
>thread; as a
>	>>vendor
>	>>>we will probably want to support both in-band and side-band,
>	>>standardised or
>	>>>not, but we would prefer a standard for side band as part of
>EFM).
>	>>>
>	>>>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 Geoff
>	>>>> Thompson
>	>>>> Sent: 04 September 2001 23:03
>	>>>> To: fkittred@xxxxxxx
>	>>>> Cc: stds-802-3-efm@ieee.org
>	>>>> Subject: Re: [EFM] OAM loop back / echo server function
>	>>>>
>	>>>>
>	>>>>
>	>>>> Fletcher-
>	>>>>
>	>>>> I don't think this is a stupid question.
>	>>>> I don't think we need an IP level PING
>	>>>> A L2 ping would do, perhaps even better, the demarc would
>look for
>	>>PING
>	>>>> type and then just swap SA & DA.
>	>>>> My expectation is that the demarcation device will need a
>MAC
>	>address
>	>>>> My expectation is that the demarcation device will probably
>end
>	>>>> up with an
>	>>>> IP address in order to support:
>	>>>>          SNMP for OA&M
>	>>>>          Firewall services for the subscriber
>	>>>>
>	>>>> (That issue is, of course, beyond our scope)
>	>>>>
>	>>>> Geoff
>	>>>>
>	>>>> At 03:47 PM 9/4/01 -0400, Fletcher E Kittredge wrote:
>	>>>> >On Fri, 31 Aug 2001 14:11:54 -0700  "Geoff Thompson"
>wrote:
>	>>>> > > As I have said before, I do believe that we will need a
>	>>>> demarcation device
>	>>>> > > that has the capability to host OA&M functions.
>	>>>> > > We have talked about "loop back" from this point in the
>network.
>	>>>> > > Let us forevermore make that "PING"
>	>>>> >
>	>>>> >Geoff;
>	>>>> >
>	>>>> >         Apologies if this is a stupid question, but does
>PING in
>	>>this
>	>>>> >context mean the utility that sends an IP ICMP ECHO
>REQUEST packet
>	>>and
>	>>>> >listens for an ECHO REPLY packet?  If so, am I correct in
>thinking
>	>>this
>	>>>> >means the demarcation device would require an IP address?
>	>>>> >
>	>>>> >thanks!
>	>>>> >fletcher
>	>>>>
>	>>>
>	>>
>	>
>	
>
>