RE: [RPRWG] Gandalf - question on Framing
Pankaj,
Having the two control bytes in the front of the packet
is consistent with the layering approach. The MAC
addresses, type field, etc. should be formatted by the client.
The RPR control bytes are formatted by the MAC.
These bytes should reside at the front of the packet
for consistent layering. It may also be preferred
to add/strip these control bytes within the MAC.
In a transparent bridging model, the MAC addresses are not
of the attached 802.17 bridges, but of the
end stations themselves. This really breaks the
layering model, by having RPR control bytes stuck
in between the bytes from an end station.
The ethertype that you refer in general indicates the
network layer protocol. The examples that you mention,
802.1Q VLAN and MPLS are very special cases that do
not apply to the rationale for adding an RPR ethertype
for all RPR frames. Adding the 802.1Q VLAN ethertype as you probably
know, was a compromise in order to extend VLAN capability to 802 networks
without breaking the MAC and existing ethernet networks. Had they designed
the original ethernet frame to incorporate VLANs it would
not have had the additional two byte tag identifier to
distinguish between tagged/untagged frames. Similarly,
the MPLS is not a MAC protocol. The ethertype has
consistent layering in that it defines the payload
type between the two communicating MAC entities
that are tunneling MPLS through an ethernet network.
RPR is a MAC protocol, not a network layer protocol. Clearly the
frame formats between ethernet, token ring, FDDI,
etc. are all different because they are different MAC layer
protocols. The ethertype
in the RPR frame is consistent in that it should
indicate the network layer protocol, or tunneled protocol.
You should be able to tunnel ethernet, 802.1Q,
MPLS, through RPR. I don't think it makes sense to
tunnel RPR through an 802.1 bridged ethernet.
thanks,
bob
Robert Castellano
Jedai Broadband Networks
rc@xxxxxxxxx <mailto:rc@xxxxxxxxx>
(732) 758-9900 x236
-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Pankaj K Jha
Sent: Friday, November 30, 2001 8:33 PM
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