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
> >>>>
> >>>
> >>
> >
>
>
>