RE: [RPRWG] Gandalf - question on Framing
Hi Mike,
Encapsulation is simple and good idea. The only negative side, I see is
that, it will open the gate for addressing at this layer and then we will
have to standardize that. Eventually we will come with another big header
which will encapsulate very likely (as you say), the Ethernet packet. So we
will have RPR->Ethernet->IP->TCP.
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 Mike Takefman
> Sent: Monday, December 03, 2001 8:20 PM
> To: Pankaj K Jha; stds-802-17@xxxxxxxx
> Subject: 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
>