RE: [EFM] OAM loop back / echo server function
Geoff -
I think you meant to say mandating 802.2....
Regards,
Tony
At 01:07 06/09/2001 -0700, you wrote:
>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