RE: [EFM] OAM loop back / echo server function
David -
Certainly, the LLC Test mechanism is already defined. However, the problem
is not one of test origination being optional or mandatory, or even one of
how vendors respond to optionals in standards. The real problem here is
that LLC as a whole is not mandatory. Hence, you cannot rely on an 802.3
device *either* being able to originate *or* respond to a LLC Test frame.
Regards,
Tony
At 17:25 04/09/2001 -0700, Horne, David M wrote:
>Geoff, Roy, and all, please see my message from Friday on this loopback/ping
>topic: http://grouper.ieee.org/groups/802/3/efm/public/email/msg00449.html
>
>It is an already-solved problem, via 802.2 LLC TEST PDUs. Testing LLC-to-LLC
>connectivity is the very reason for the TEST PDU's existence. Responding to
>incoming TEST Command PDUs is mandatory for every Class of LLC client. So
>our Ethernet forefathers already provide the solution...sort of. It is just
>not used much because only the ability to reply is mandatory. The ability to
>send is optional. Most any requirement that is optional is synonymous to
>MUST NOT implement :o). So the capability just lies in waiting. It is
>arguable whether it is of value in an enterprise network, since every
>powered NIC is bound to a full TCP/IP stack. This may not be the case for
>EFM. There may be no requirement for support at and above the Network layer
>in the EFM ONU, or it may just be a subset, e.g. no TCP. Depends on overall
>system partitioning and management functional partitioning.
>
>The other topics in my message were: BER testing, interleaved time slot
>cycles, and extension of LLC XID in lieu of new MAC Control types. I'd
>appreciate any comments on these proposals since they each seem to address a
>yet-unsolved problem, and all are within the scope of the EFM charter I
>believe.
>
>
>
>
>-----Original Message-----
>From: Roy Bynum [mailto:roy.bynum@xxxxxxxx]
>Sent: Tuesday, September 04, 2001 4:06 PM
>To: Geoff Thompson
>Cc: stds-802-3-efm@ieee.org
>Subject: Re: [EFM] OAM loop back / echo server function
>
>
>
>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.
>
>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
>
>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