Re: [RPRWG] CRC check in each node?
Nader,
Please see my comments below.
Thanks.
Necdet
Nader Vijeh wrote:
> One of the challenges we have in 802.17 is emulation of the "broadcast
> media", which is the basic assumption for most if not all of the 802 MACs.
> The act of "destination stripping" complicates this as the receive function
> of 802 MACs is not the same as packet removal. 802.3,5, 11 ,etc. all perform
> receive function without removing the packet. In other ring MACs (e.g.
> 802.5), the source MAC removes the packet with the assumption that all other
> MACs have "seen" the packet.
>
> The challenge is to perform destination stripping without performing
> bridging (switching) function, as that will be outside the scope of the
> 802.17.
We have passed an objective passed stating "The MAC shall support destination
removal for unicast packets during normal operation." , hence 802.17 MAC shall
perform destination stripping for unicast packets. The "emulation of the
'broadcast media' " though can be handled using multicast which does not require
destination stripping. One way to implement bridging without violating the
destination stripping objective is to use broadcast for learning and to use
unicast with encapsulation for the delivery of the bridged packets. There will
be a presentation on this in the July meeting.
>
>
> We can specify functions such as CRC checks and may be manipulating the CRC
> filed or a bit in the header to indicate a bad packet, etc, as a MAC
> function. Specifying packets to be discarded or re-ordered or otherwise
> "received" and "re-transmitted", is harder to do in the context of an 802
> MAC. In other words, specific implementations may wish to buffer packets in
> transit or not, without making that a requirement in the standard.
I don't understand why it is difficult to specify packets to be discarded. We
may want to make it optional to drop or not to drop packets with CRC errors,
however, we should determine a default behavior for this decisions.
We should definitely specify packets to be "received" (i.e., unicast) and
"received and copied to transit path" (i.e., multi-cast) in the standards. In
fact
we have already decided on the first one (unicast) and implied for the second
one (multicast) by passing objectives relating to them in the prior meetings.
I agree with you with respect to transit path implementation not being part of
the standard if we can show that this would not cause any inter-operability
problems.
>
>
> As for "fairness", if there is an "active" control mechanism, as covered by
> multiple proposals, it is possible to regulate access to media without the
> need to perform packet switching at each node (station). After all, it is
> the main objective of the WG to devise a Media Access Protocol and not a
> packet switching technology.
Can you please elaborate on what you mean with switching? I agree that transit
packets should not go to the switch fabric and switched back.
>
>
> The option to receive (drop) all packets and then re-queue them above the
> MAC and then re-transmit them, is an option when the MAC is operating in
> "promiscuous" mode.
>
Can you please explain why this is needed?
>
> Nader
>
> -----Original Message-----
> From: igorz [mailto:igorz@xxxxxxxxxx]
> Sent: Tuesday, June 26, 2001 8:36 AM
> To: Nader Vijeh; ieee 802.17 list
> Subject: RE: [RPRWG] CRC check in each node?
>
> Nader,
>
> the actual MAC operation is very "straight forward". There are 2 possible
> destinations for the packets entering MAC from the ring - back to the ring
> and to the drop port (3 - if you'll count a bit bucket). There are at least
> 3 operations required in order to chose one of them:
>
> 1. Physical reception of the packet's bits into ingress buffer
> 2. Key fields lookup in order to determine packet's destination
> 3. Validation of the packet's integrity by checking the CRC etc.
>
> In my mind the above operations constitute the packet reception. TP, on the
> other hand, is highly implementation dependent. It can be ingress connected
> directly to egress, it can be routed through the higher layers etc. In any
> case, if the fair access to the ring is an objective then the transit
> traffic of a specific class will have to be scheduled for the transmission
> taking into account the add traffic of the same class. This assumes one (at
> least logical) queue for both.
>
> I also have another question - which "802 MAC" you are referring to? There
> are several (quite different) possibilities.
>
> Igor
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Nader Vijeh
> Sent: Monday, June 25, 2001 7:30 PM
> To: ieee 802.17 list
> Subject: RE: [RPRWG] CRC check in each node?
>
> The transit path (TP) is "logically" separate from the "receive" path in the
> MAC. That is, packets in "transit" are not actually "received" by the MAC.
> Therefore, discarding packets in transit or re-queuing and re-ordering them
> would not fit well with the 802 MAC model.
>
> As for the promiscuous mode, you are correct that address recognition part
> of the MAC operates independently of the CRC function.
>
> -----Original Message-----
> From: igorz [mailto:igorz@xxxxxxxxxx]
> Sent: Friday, June 22, 2001 1:23 PM
> To: Nader Vijeh; ieee 802.17 list
> Subject: RE: [RPRWG] CRC check in each node?
>
> Nader,
>
> what do you mean by "...MAC is not actually "receiving" packets in
> transit."?
>
> Also "promiscuous" mode has nothing to do with checking the CRC.
>
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Nader Vijeh
> Sent: Friday, June 22, 2001 3:25 PM
> To: ieee 802.17 list
> Subject: RE: [RPRWG] CRC check in each node?
>
> I agree with Harry on not discarding packets with bad CRC. Not only carriers
> will not like this, but it also goes against the fact that MAC is not
> actually "receiving" packets in transit. Packet discard due to CRC error is
> defined as part of the "receive function" in the 802 MACs.
>
> To answer Mike's question on Ethernet MACs, they all have a "promiscuous"
> mode that allows them to receive all packets on the media, this mode is
> normally used in bridges, allowing the bridge to make the decision on
> forwarding.
> -----Original Message-----
> From: Harry Peng [mailto:hpeng@xxxxxxxxxxxxxxxxxx]
> Sent: Friday, June 22, 2001 10:03 AM
> To: ieee 802.17 list
> Subject: RE: [RPRWG] CRC check in each node?
>
> Ray, Mike, Raj, Angela:
>
> There are two issues here:
> 1) If there is only one CRC that covers the ring header (DA) and the
> payload, then you don't
> known if the error occurred in the header (un-routable packet) or in the
> payload.
> If the TTL is also covered by the CRC then the only way TTL can remove
> packet
> is because the DA is unknown to all the stations on the ring. This TTL is
> rather useless.
> all error packets must be discarded.
> This violate the Transparent Lan Service model. Error packet is delivered
> to the
> customer for SLA reasons. Any packet discarded will have to be able to be
> validate
> at the receive end. Keeping statistics on the ring becomes a big scaling
> problem.
> This also prevents any of you out there who want to do transparent
> mapping.
>
> 2) in the cut through mode, error packet are delivered to its destination
> which may
> decide to discard or not and keep stats accordingly.
> In cut-through the header will have to processed for source removal,
> destination strip,
> and TTL processing.
> In either case, Adding a ring header error checking can be used to
> validate the correctly
> of the header. If the packet is routable, forward it.
> For store and forward mode, you can check if the packet CRC is correct
> and discard the packet depending on the
> configuration of the MAC and the service the box is offering.
> Recommendation:
> Header error checking is valuable, there is an error floor rate for any
> transmission medium.
> For all possible services that the ring can offer, and for RPR to be
> payload agnostic then it shall not drop any error packet. Unless a header
> error is detected.
> Un-routable packet is a given, there is not much one can do but to
> discard it!
> Remove un-routable packet so it does not circulate on the ring forever.
>
> Regards,
> Harry
>
> -----Original Message-----
> From: Ray Zeisz [mailto:Zeisz@xxxxxxxx]
> Sent: Friday, June 22, 2001 7:23 AM
> To: 'Mike Takefman'; Raj Sharma
> Cc: 'Angela T. Faber'; ieee 802.17 list
> Subject: RE: [RPRWG] CRC check in each node?
>
> There are plenty of Ethernet switches that operate in (gasp!) cut-through
> mode. These switches propagate CRC errored frames because they switch from
> one port to another after only receiving the MAC header. The original
> Ethernet switch (Kalpana) operated this way...and received a lot of
> criticism. From my perspective, it appears that most of the Ethernet switch
> industry is moving away from this and not propagating CRC errors. This is
> largely due to the fact that the industry is moving away from shared bus
> architectures.
> Today, most Ethernet MACs and Network Processors have control bits that
> allow you to selectively receive or discard packets that are CRC errored,
> too long or runt (too short).
> I believe that Raj mentioned some services that require errored packets to
> be delivered at the Orlando meeting. Maybe he could tell us more about
> these and what the errored packets provide to the end station.
>
> FYI: IBM has a patent for adaptively running in cut-through or
> store-and-forward based on the bit error ratio over a period of time, on a
> per link basis.
> Ray Zeisz
> LVL7 Systems
> http://www.LVL7.com
> (919) 865-2735
>
> -----Original Message-----
> From: Mike Takefman [mailto:tak@xxxxxxxxx]
> Sent: Thursday, June 21, 2001 9:05 PM
> To: Raj Sharma
> Cc: 'Angela T. Faber'; ieee 802.17 list
> Subject: Re: [RPRWG] CRC check in each node?
>
> Raj,
> It is not clear to me that the ttl has to be within the packet, and
> protected by the crc. There are successful implementations that
> have the ttl protected outside of the packet. There are advantages
> to doing this in terms of the complexity of the implementation.
> I do come down on the camp of removing the packet from the ring
> once there is corruption. There is no reason to waste BW with
> a packet that will be dropped once it is received.
> I would be interested to know if there are any Ethernet MAC/
> Switch chips sets that do not drop CRC errored packets
> when received or any that do it selectively. I would be interested
> in understanding the mechanism for differentiating drop behaviour
> to understand if it belongs in the transit path.
> cheers,
> mike
>
> Raj Sharma wrote:
> > Angela,
> >
> > This is an intesting question and is sort of the tip of an iceberg
> > (pardon the cliché - I feel the answer to this question is loaded)
> >
> > There are fundamentally 2 issues here. Misrouting of packets due
> > to errors and corruption of the payload.
> >
> > IMHO, packets whose headers are corrupted must be discarded
> > in order to prevent misrouting. The question is whether the misrouting
> > prevention is limited between RPR MACs or to the ultimate destination
> > entity connected to a RPR MAC. I am assuming that a RPR MAC has
> > multiple clients.
> >
> > Certain services require persistent delivery of frames. Such services
> > will make their won decision on what to do with corrupted frames.
> > For these services it may require that corrupted frames be still delivered
> > to the specific MAC client.
> >
> > Now, it maybe of significant value in debugging networks and from
> > an operational perspective to know over which span on the ring the
> > frame got corrupted. Hence CRC recomputation at every node may
> > have some value from an operational perspective. Also, since the TTL
> > field is part of the frame CRC recomputation cannot be avoided at least
> for
> > the header.
> >
> > raj
> >
> >
> >
> > -----Original Message-----
> > From: Angela T. Faber [mailto:afaber@xxxxxxxxxxxxx]
> > Sent: Thursday, June 21, 2001 12:44 PM
> > To: ieee 802.17 list
> > Subject: [RPRWG] CRC check in each node?
> >
> > Folks
> >
> > One question regarding CRC check: are we assuming CRC will be checked
> at every node (as the frame is
> > forwarded) or it will be checked only at the destination/source node?
> > My initial thought on this is that, if we don't do it at every node,
> than how do we remove the frame from ring if the
> > source and destination addresses are corrupted? On the other hand I
> assume that if every node checks it, more
> > time is spent with forwarding it....
> >
> > Any insights are welcomed.
> > Thanks!
> >
> > Angela
> >
begin:vcard
n:Uzun;Necdet
tel;fax:408 325 1699
tel;work:408 325 1602
x-mozilla-html:TRUE
url:www.AuroraNetics.com
version:2.1
email;internet:nuzun@xxxxxxxxxxxxxxxx
adr;quoted-printable:;;211 River Oaks Pkw, Suite B=0D=0A;San Jose;CA;95134;
fn:Necdet Uzun
end:vcard