Re: [EFM] OAM loop back / echo server function
Geoff,
I am glad to see some grounds for agreement and discussion here.
I personally do not like the MAC Control frame for the L2 "ping". I would
much rather see something that the head end can use to solicit a link level
status from the customer pop/demarc system at a level below the MAC. I
threw out the "MAC Control" frame idea just to get a discussion going and
to start to eliminate some of the "not so good" ideas. I hope that you are
not offended.
There should also be something that allows the demarc to be "enabled" at
the MAC level or "disabled" at the MAC level. This would be to prevent
"theft of services" for broadcast services to residential customers.
There could also be an auto discovery polling process below the MAC level
to discover the MAC address of the end systems. A mechanism that does not
impact P2P performance and can also be used for P2MP is what is needed here.
Thank you,
Roy Bynum
At 09:23 AM 9/5/01 -0700, Geoff Thompson wrote:
>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
>> >
>> >