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

Re: [EFM] OAM loop back / echo server function




[Date: 09/06/2001  From Seto]

Geoff,

Thanks for your comments.  

>I agree with this goal.
>I agree that it should not require IP.
>I don't think that means that it needs to be done in MAC Control (but I am 
>certainly open to discussion)

I agree whether we should do it in MAC control is something we 
should discuss.  ;-)

>This brings up the much uglier issue of discovery, also a topic that has 
>always been outside the scope of 802.3.
>If there is going to be a bridge or router at the demarc then there will 
>have to be a discovery process that effectively logs the MAC address into 
>the service provider's system. The service provider won't be able to 
>Ping/Echo the box until it knows the MAC address.

I disagree with your presumption that service provider need to 
know the MAC address of each demarc.  I'm thinking of a frame 
with 802.1 reserved DA like a 802.3x pause frame.  This frame 
should not be forwarded by a bridge.  This frame should be 
ignored by a MAC which does support this L2 ping.  This frame 
should be used only in P2P networks defined for EFM networks 
including P2P emulated EPON.  

Seto

>Seto-
>
>At 01:03 PM 9/5/01 +0900, Seto, Koichiro wrote:
>
>>[Date: 09/05/2001  From Seto]
>>
>>Geoff,
>>
>>I can think of one compelling reason for having L2 ping in MAC control 
>>which is that service providers do not need to configure unique IP address 
>>to each demarc box they would provide to their subscriber 
>>customers.  Better yet, a customer may be able to buy a 802.3ah EFM modem 
>>at RadioShack and the service provider can check the connectivity without 
>>the box being properly IP configured by the customer.
>
>I agree with this goal.
>I agree that it should not require IP.
>I don't think that means that it needs to be done in MAC Control (but I am 
>certainly open to discussion)
>
>
>>If we are talking about P2P configuration only, each demarc point may not 
>>need a unique MAC address provided we standardize one unique MAC control 
>>address and EtherType for L2 ping.  At least, service providers do not 
>>need to know each MAC address of each customer's demarc box.  (In this 
>>case EPON needs to be P2P emulated.)
>
>This brings up the much uglier issue of discovery, also a topic that has 
>always been outside the scope of 802.3.
>If there is going to be a bridge or router at the demarc then there will 
>have to be a discovery process that effectively logs the MAC address into 
>the service provider's system. The service provider won't be able to 
>Ping/Echo the box until it knows the MAC address.
>
>I would assume that it would be useful to have an upstream Ping/Echo in the 
>demarc. This one might be advantageous to have a response that comes from 
>the MAC Control sub-layer of the head-end MAC. This would protect the 
>service provider from denial-of-service attacks from a flood of 
>Pings/Echos. Presumably there would be a management object/attribute in the 
>head end that kept track at some level of the p/echo requests (i.e. their 
>SA and how many)
>
>
>>Sincerely,
>>Seto
>
>Geoff
>
>
>> >Roy-
>> >
>> >
>> >At 06:05 PM 9/4/01 -0500, Roy Bynum wrote:
>> >>Geoff,
>> >>
>> >>Would a MAC Control frame with a specific opcode  be usable as an L2
>> >>ping.  This would take the frame all the way to the MAC control layer,
>> >>through all of the PHY and RS.
>> >
>> >This function "could" be added to MAC control.
>> >It is not clear that there would be any special reason to do so.
>> >You would have to make a convincing case that there was some special
>> >advantage to doing this vs. using an existing, well known protocol.
>> >According to my file copy of RFC 1060 (very old version of Assigned
>> >Numbers) decimal 36864 (9000 Hex) packet type is assigned to Loopback.
>> >
>> >It is not clear to me that restricting the path of a Loopback/Echo/Ping to
>> >just the [MAC Control][MAC][RS][PHY][Medium][PHY][RS][MAC][MAC Control]
>> >would be any advantage. After all, the person machine that wants to do the
>> >test would have to open a communications path to the testing [MAC
>> >Control/OA&M] anyway.
>> >
>> >
>> >>There could also be a command within the OAM functionality that would
>> >>generate a special MAC Control frame that would have an opcode that would
>> >>specify a test pattern in the "parameters" field of the frame.  This could
>> >>potentially provide a very valuable remote trouble shooting tool for
>> >>service providers.
>> >>
>> >>Roy Bynum
>> >>WorldCom
>> >
>> >Geoff
>> >
>> >
>> >>At 03:02 PM 9/4/01 -0700, Geoff Thompson wrote:
>> >>
>> >>>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
>> >
>> >
>
>