RE: [EFM] OAM loop back / echo server function
At 12:58 05/09/2001 -0700, you wrote:
>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?
David -
All the standards we are dealing with are voluntary, and therefore
optional. No-one has to implement 802.3, 802.2, ... etc. if they don't want to.
>Is it
>possible you are instead thinking of the MAC Control sublayer, which sits
>underneath LLC architecturally, and IS optional?
No.
>Or maybe you are thinking
>of an Ethernet-II (i.e. "TYPE interpretation" frames only)implementation,
>which doesn't recognize LLC?
I am thinking of (a) implementations that make use of "Type interpretation"
frames only, or (possibly rare these days, but not impossible) (b)
implementations that make use of "Length interpretation" frames only.
>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.
802.3 specifies support for both type and length interpretation in order
for it to cater for whatever is chosen to sit on top of it. Whether you
choose to make use of LLC over 802.3, or use protocol identification based
on Ethertypes, or some of each, is not 802.3's concern - it can handle all
3 possibilities.
>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?
The particular reason is that there is no point in mandating the
implementation of something that is not needed in a given situation. If all
you are doing is running IP, the presence of 802.2 in your implementation
is kinda superfluous.
>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.
The 802 family contains many foundations, some of which are solid and some
of which are showing signs of deterioration to a greater or lesser degree,
I guess...
Regards,
Tony
>
>-----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