RE: [EFM] OAM loop back / echo server function
David-
Mandating 802.3 doesn't make any more sense than mandating which protocols
would be supported under the EtherType. The customer gets to decide which
protocols he will make use of and which he will discard as gibberish.
Geoff
At 08:17 AM 9/6/01 +0100, Tony Jeffree wrote:
>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
>