Re: [RPRWG] Gandalf - question on Framing
Devendra,
I am not sure I undersand your comment. With regard to
PRP->Ethernet->IP->TCP, there are already some companies
shipping product that does this in order to provide a
transparent LAN service. Some people refer to this as
encapsulating bridging. So yes it is going to happen.
I would not view this as negative since it provides a
useful service that customers want to deploy and pay for.
mike
Devendra Tripathi wrote:
>
> 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
> >
--
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