RE: [RPRWG] Gandalf - question on Framing
My understanding is that it has been done to help intermediate equpments
like muxers, terminators. Such equipments should not have to go deep in
packet as they are real fast and slim chips doing the job. I am not trying
to justify it one way or other.
Regards,
Devendra Tripathi
CoVisible Solutions Inc.
(formerly VidyaWeb, Inc)
Pune, India
Tel: +91-20-433-1362
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Pankaj K Jha
> Sent: Saturday, December 01, 2001 7:03 AM
> To: Martin Green
> Cc: stds-802-17@xxxxxxxx
> Subject: 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
>
>