Re: [RPRWG] Gandalf - question on Framing
Pankaj, RPRWGers,
I write this email as an individual member of the WG with almost 4 years
of technical expertise in RPR systems design, development, deployment
and support.
Please allow me to step into the discussion.
SRP Frame Design:
-----------------
I will present some rational around the design of the SRP frame. This
is material that has already been presented to the group, but there
are people who were likely not at those meetings. Please allow me to
repeat them here.
SRP was designed to transport packets in a resilient packet ring.
Some people claim that it was designed to transport IP only,
while it is a convenient straw man to attack, it is not accurate.
Consider the requirement to bridge 802.3 frames (which are
the most common frames we are going to see in a wired
environment). The SRP frame takes the 802.3 frame and
preprends the ring specific information without modifying the
802.3 frame.
This is a standard design principle for MACs, and entirely consistent
with layered design practices. Layered design is considered
both elegant and a best practice. We were creating a new MAC
layer not a new LLC interface or an ethernet client. There was never
a requirement to hack a solution together with off the shelf
silicon or try to ride on the coat-tails of an existing standard.
Aside from the elegance of layering, this has the advantage of
mantaining the 802.3 frame intact complete with FCS. Given the
position of the TTL field outside of the FCS, it insures that
the FCS does not have to be recalculated ever. Neither hop
by hop nor by the bridge. This provides the greatest robustness
against error introduced within the system.
A good question is whether having DA as the first field of the
packet is sacrosanct within 802. I have checked 802.5, 802.11,
802.15 (could not access 802.16).
None of the frame formats for these standards (5,11,15) start with DA.
They all start with fields that are unique to their intended
media or network topology. Layering strikes again.
Gandalf Frame Design:
---------------------
Firstly, yes, Gandalf grew out of SRP, and that's actually a good
thing in my opinion, but hey I am biased :)
SRP is not the only successful pre-standard RPR MAC that has a
ring header frame structure. The fact that the two leading pre-standard
RPR implementations went in this direction is a strong indicator
that this is the correct way to go.
The departure from SRP is the HEC that protects the header.
This has two effects that many people see as desirable.
1) Gandalf is not backwards compatible to SRP, which some
people in the committee see as a minumum requirement. That
is a good conversation to have in a bar, ask me where Xerox
is today in the Ethernet space!
2) The address fields are now protected, and packets with
bad data but good address can transition an RPR ring.
Disgression: Note that once a packet with good HEC but bad
FCS hits a bridge it has to be dropped. 802.1D specifies
that a packet with bad FCS cannot be forwarded.(6.3.5 of
802.1D 1999). Therefore this HEC while useful in a single
ring, does not allow rings of rings to be built and
transport TDM, or TDM bridging into an Ethernet Mesh network
unless we change 802.1D.
USefulness of the HEC:
----------------------
One can argue about the actual usefulness of the HEC to
protect the DA/SA. But as Gandalf *bridges* all but one
of the major contentious issues, the Gandalf group decided to add
the HEC rather than debate the issue. That is not to
say that there were not some people involved with Gandalf
who thought the HEC was a good feature. Not everyone
did, but they were willing to go along with it for the
good of convergence.
For the fun of it, I will debate it now. This is really
more of a thought experiment then anything else.
Assume for the moment that we are trying to transport
a DS-1. Depending on the efficiently you want to achieve
you might pack from 1 to 16 DS-1s in a packet. Allowing
for some overhead per packet (including a sequence
number) you get the following approximate packet sizes (in bits)
# of DS-1s Size
1 416
4 992
16 3296
Fiber links have error rates in the range of 1E-15 to 1E-12
at the begining of life dropping over time. A SONET link is
speced to have an error rate of better than 1E-10 worst case.
In reality, customers get cranky if it is worse than 1E-12.
So if a bit error occurs and kills the entire packet
then the packet is dropped and the box reconstructing the
TDM stream sees a bit error rate that is "size" times larger.
So the bit error rate degrades by 2 to 3 orders of magnitude.
But this still leaves the system with a bit error rate far better
than a copper DS-1. I believe the acceptable limit for BER in
a DS-1 circuit is somewhere in the 1E-3 to 1E-6 range
and so we meet that limit.
Now, this can be mitigated somewhat by doing any of the following
1) The box repeats the last good DS0 sample.
2) Play some tricks with trans-coding the samples to minimize
the number of bits changed (on average) from sample to sample.
So the bit error rate can be protected to some degree. Some people
feel passionately about the need for this feature and Gandalf
supports it.
SRP Test Sets:
--------------
SRP test sets exist today from a number of vendors. The changes
that Gandalf makes to the SRP frame can be easily accomodated
by changes to the firmware of the testset. Therefore, I would
not be concerned over the availability of testsets for Gandalf.
Pseudo Ethernet Frame Design:
-----------------------------
Some people might make the argument that maintaining a packet
with DA at the front will make it possible to use Ethernet
test sets right out of the box.
The Alladin Proposal's frame format is somewhat like the
Ethernet frame, with the change that the FCS is not calculated
over the entire frame but just the payload. And a HEC protecting
the front of the packet.
So what happens when an Alladin packet hits a test set? FCS
error on EVERY packet since the test set will have calculated
the FCS from DA to the end of packet. As we cannot determine the real
error rate on a link, it is less than useful as a test set.
How useful is it to capture packets? Somewhat, but not enough
without new software.
Once we are changing software, it is just as easy to make the
testset understanda Gandalf.
For the testset to be truely useful, it must properly
interpret the packet. That includes calculating the
HEC and the FCS.
The REAL advantage of the pseudo ethernet frame is that it
allows people to use off the shelf ethernet MACs/PHYs
and hook an FPGA between them and put together a system
by turning off the FCS check in the MAC, and placing the
Ethernet MAC into promiscuous mode.
While this is great for the first generation, it is
not what is going to drive silicon design for RPR.
The ethernet MAC will not be "improved" or modified for
the benefit of .17, we have to own our MAC.
Besides, once you turn off address recognition and
FCS checking what is the MAC doing aside from
frame deliniation and adding the preamble and
IPG?
Ethernet Frame Design:
----------------------
Consider if the RPR frame is exactly the Ethernet frame with the RPR
details placed after a TYPE field and the FCS covering exactly
what the Ethernet FCS covers. If so, we violate our 5 critera
and should recind our PAR or dot3 would do it for us. This
is because it violates the uniqueness requirement. It also
pushes us into 802.1 territory, since these techiques could
be applicable to all MACs, since a new type was defined.
Every meeting I am up there reminding people that 802.3 had
serious concerns about our group intruding into their
space. Use of the Ethernet frame is absolutely un-acceptable
in my technical and politcal opinion.
The good news is no one is pushing that option any more. But
some people were pushing for a long time.
Summary and Conclusions:
------------------------
Having DA as the first field in a packet does not
occur in most 802 frame formats, there is nothing
special about it. At least three 802 frame formats
put their interesting stuff in front of the DA/SA.
As such there is precedent for doing it the Gandalf way.
I will check for 802.16 and let people know.
New software for test-sets are required unless we
adopt exactly the Ethernet or SRP frame format.
Does anyone believe that the leveraging / availablity
of test sets is the most important decision criteria for
.17? If so, then the only possible outcome is to
adopt the SRP frame format and drop the HEC concept
altogether because the use of the ethernet frame
will get us into trouble with 802.3.
I look forward to the reponses this will generate,
at least the reflector will be hopping for a change :)
I apologize to everyone for being so long winded.
cheers,
mike
Pankaj K Jha wrote:
>
> Devendra, that's _definitely_ not the reason. The difference is only about 16
> bytes, and forcing a path away from Ethernet must have some other very sound
> reason. Intermediate equipments definitely won't even work with the proposed
> scheme.
>
> Pretty soon the RPR standard document will be in front of entire industry and we
> need to answer to all people, so we need to be convinced we're taking an
> approach that makes sense.
>
> I am looking forward to a response from Gandalf editors or SRP authors. I'm sure
> they have a solid reason for doing so and preserving the packet format that was
> done about 3 years ago; all of us need a good education on it.
>
> Regards,
> Pankaj
>
> Devendra Tripathi wrote:
>
> > 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
> > >
> > >
--
Michael Takefman tak@xxxxxxxxx
Manager of Engineering, Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-254-3399 fax: 613-254-4867