RE: [EFM] OAM developing Geoff's observation.
Sanjeev,
That is a very good point. Among all the questions you raised, I think
"What are the services?" is the most interesting one. Obviously a
private leased line differs a lot from a 'teenage chat room connection'?
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? Or is there a requirement for
other OAM mechanism? Thanks.
-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
>>>>
>>>
>>
>
winmail.dat