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