Re: [RPRWG] Gandalf - question on Framing
Thanks a lot, Martin. I feel if the framing is similar to that of an Ethernet
then any test equipment with existing MAC will be easily able to grab the frame
and analyze contents. Test equipments can easily work off of any Ethertype value
such as IP, ARP/RARP, VLAN, IPX, AppleTalk, DECnet, ... and analyze packets
without any problems or modifications. The rfc1700 has a list of these
Ethertypes, and IEEE has a standard form for applying for additional Ethertypes.
I don't know why RPR would like to break this - the RPR header can also be just
like any of these other protocols. Note that Ethertype is not just for L3 PID,
it is also for other shims such as 802.1Q, MPLS, etc.
You didn't write what the _benefit_ of the SRP approach is, and what the _harm_
is in _not_ doing the way SRP is doing. I'd appreciate your help on this. To
date, any one that I've spoken to didn't have an answer and couldn't tell me why
it was done that way - except that it was done in SRP and the practice has
perpetuated now to a standards draft proposal. A description of reasoning behind
this would help all of us understand this better.
Grabbing on to CRC fields is not hard - the hard part is forcing vendors to use
special MACs for monitoring RPR packets when there is no need. Even if they must
go to a new MAC, there is no benefit they have in this unusual prefix of header
bytes.
If you could refer me to some pointers to papers that describe these benefits of
doing this non-typical framing that would be great. Would you happen to know of
some reading material on the advantages of this approach?
Thanks in advance for any pointers,
Best regards,
Pankaj
Martin Green wrote:
> Pankaj,
>
> The use of same physcial layer will be of the most benefit to test vendors.
>
> I'm not sure of what level of equipment you describe, but most vendors will
> have the flexibility to deal with new/different packet structures. They need
> this ability for such activities as error generation/detection (i.e., CRC,
> alignment, illegal frame size, frame capture). They do not use an off the
> shelf Ethernet MAC. To be of any use, they will have to interpret the bits
> of the RPR frame anyway (especially the header bits). The position of the DA
> will not make their job any easier.
>
> Regards,
> Martin
>
> Pankaj K Jha wrote:
>
> > Question for Gandalf editors:
> >
> > I would like some understanding on benefits and rationale behind putting
> > RPR header bytes in _front_ of Ethernet DA/SA fields in the Gandalf
> > proposal. If an RPR header is put in using an Ethertype life would be
> > much simpler, and we'd be able to use existing systems to test/monitor
> > RPR packets. I don't know why header bytes are put in this way in the
> > Gandalf proposal. For sure, a different MAC doesn't have to have an
> > unusual format unless there was some benefit in doing so.
> >
> > Since the header scheme is essentially the SRP scheme, could the Gandalf
> > editors consult original authors about the intent of doing so and then
> > reply.
> >
> > Being able to look at RI, TTL, etc. very early ahead of MAC addresses
> > isn't a valid reason since we're only talking about difference of a few
> > bytes.
> >
> > In general, I'd like RPR WGers to start discussing different elements in
> > different proposals so we can make informed choices on different issues
> > at the January meeting.
> >
> > Regards,
> > Pankaj