[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
Neil,
I think Pat Thaler's reply helps to straighten out this confusion, but let me
try, also.
There is a *lot* of confusion about the words "end-to-end", and about "transport layers".
There are lots of ends in this picture, and there are layers and there are layers.
An 802.1Q VLAN bridge, and by extension, a P802.1ad provider bridge, does NOT supply a
"transport layer" in the same sense as IP-over-Ethernet or Ethernet-over-IP. This is
because, at the data forwarding layers, VLAN tags are best though of as extensions to
the address space, not as additional protocol layers. If you want to call it a
"transport layer", feel free! But don't assume that VLANs are equivalent to other
"transport layers". Data integrity, specifically, is different in bridges.
Routers provide "best effort" not only in frame delivery, but in data integrity. There
is no upper limit specified for the probability of delivery of a packet with undetected
errors. IP's response, if you demand a particular level of data integrity, is that
your application must supply its own checksum.
Bridges, however, are not routers!
Bridges *do* guarantee a level of service. They manage to do this by guaranteeing the
quality of each bridge, and by *demanding* the quality of each link. Non-VLAN bridges,
VLAN bridges, and Provider Bridges all make that guarantee to their users using this
method. The Customers of a Provider Bridge service are not an "802.1Q application"
over an "802.1ad transport layer". They are, in the 802.1 model, just endstations
attached to a bridge. The Customers' data is just as well protected as an enterprise
bridges' endstations, as long as the model is maintained. Adding an additional CRC
to end-to-end service, where the ends are Customers attached to 802.1ad Provider
Bridges, is therefore pointless. Changing that model is as silly as turning the model
for routing upside down.
When a Pseudowire is used to connect two bridges, the "end-to-end" is now just those
two bridges. Those bridges are using that PW as an Ethernet to carry their traffic.
The bridges demand that every wire be as reliable as an Ethernet. That's the PW CRC
issue.
-- Norm
neil.2.harrison@bt.com wrote:
Norm....As per our discussion today face-face. I don't really see what the problem is here. The client layer network should not care about the server layer network (and vice versa)....we need this layer independence for lots of reasons. An ethernet traffic unit has a FCS. This should simply be transported transparently in the payload area of whatever the server layer is....and the server layer should use its own (OAM) 'integrity mechanisms' irrespective of the client. Problems arise when people start doing things like client layer compression and thus forming inter-layer dependencies.
Further, as we agreed today and as I posted on an earlier mail to this thread, the ethernet FCS is a CRC that can be linerarly updated for adaptation function changes (eg VLAN ID change) on each link-connection (as provided by some server layer trail technology) whilst preserving its end-end intergrity check of the rest of the ethernet traffic unit between its trail termination points.
regards, Neil
-----Original Message-----
From: Norman Finn [mailto:nfinn@cisco.com]
Sent: 18 November 2003 08:56
To: mark seery
Cc: stds-802-1@ieee.org; pwe3@ietf.org
Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
Mark,
You say below,
> but a PW will be running over a physical media itself
already, possibly
> even SONET.............
Exactly! Here, the trail gets a bit murky. If I'm in total
control, and the PW
is running over known Ethernet links, then I can get away
without the CRC in the
PW. I have no problem whatsoever with the current definition
of PWs without CRC.
But, if I don't have tight control over the physical media
over which the PW runs,
then I really need a CRC on the PW for the bridge to be able
to trust the "wire"
and thus provide the same level of data integrity that
bridges offer over physical
Ethernets. So, I claim that bridges need a CRC option on PWs.
-- Norm
mark seery wrote:
Norman Finn wrote:
<snip>
In other words, routers pass about $0.93 of the data
integrity buck to
bridges,
and bridges pass about $0.75 of that to the data links.
The buck has
to stop
somewhere, and the data link is where it stops. The PW
has to take
the same
hit as the physical media.
-- Norm
but a PW will be running over a physical media itself
already, possibly
even SONET.............
mark
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3