RE: [EFM] OAM loop back / echo server function
Tony--interesting comment...do you have a reference to an IEEE document you
can cite where it explicitly says support of LLC is optional for a
*compliant* 802.3 product, so I can understand how this is possible? Is it
possible you are instead thinking of the MAC Control sublayer, which sits
underneath LLC architecturally, and IS optional? Or maybe you are thinking
of an Ethernet-II (i.e. "TYPE interpretation" frames only)implementation,
which doesn't recognize LLC?
Support for "length interpretation" MAC frames has always been required of
compliant 802.3 implementations (in fact it was the only way, officially,
until type interpretation was added a few years back). Length interpretation
frames all contain LLC SAPs. Without an LLC client being implemented there
is a hole atop the data link layer for length interpretation 802.3 frames.
Though I would like to resolve this out of curiosity, is there any
particular reason for not making 802.2 a requirement, if it is in fact
optional? There are many capabilities in 802.2 that aren't used for
enterprise products. Most implement the minimal set of 802.2 requirements
(Class 1 LLC client). However, there are some interesting capabilities and
extensions in the optional features that might be valuable for an
application like EFM because of its stark difference from intra-enterprise
applications. If such things need development anyway, it seems senseless to
develop them from the ground up, if a solid foundation already exists within
the 802 family.
-----Original Message-----
From: Tony Jeffree [mailto:tony@xxxxxxxxxxxxx]
Sent: Wednesday, September 05, 2001 1:36 AM
To: Horne, David M
Cc: stds-802-3-efm@ieee.org
Subject: 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