[rbridge] ECN RE: TRILL Options

[James Carlson]

Eastlake III Donald-LDE008 writes:
> A few things:
> 
> Currently there are only two free bits in the TRILL Header.

That's a pretty good reason to be hesitant.  ;-}

> If the intent of the ECN feature is to affect host behavior, how is this
> communicated to the host?

Note that "hosts" in TRILL terminology are quite likely to be
"routers" in the network layer world.

In any event, I'd expect the encapsulating TRILL node to copy the ECN
bits (likely similar to RFC 3168, but perhaps requiring mapping for
non-IP protocols) into the TRILL header, and the decapsulating TRILL
node to apply those ECN bits to the encapsulated packet before
disgorging it onto the destination network.  You then have a record of
congestion encountered in the middle of the bridged network.

Systems that don't do ECN will generally ignore the bits (and will set
00 on transmit), and those that do it will do the Right Thing.  If the
TRILL network doesn't support ECN at all, then the bits get copied
from input to output unmolested -- meaning that congestion through the
larger network is still detected, but that congestion within the TRILL
network is invisible.

If the TRILL encapsulator doesn't do ECN, then the bits will be zero
on input, and the egress can ignore them on output.  If the egress
doesn't do ECN, then the inner packet will be left unchanged, again
meaning that ECN works but that the TRILL network is not visible.

Finally, if the carried protocol doesn't support ECN, or the ingress
RBridge doesn't know how the next level protocol deals with ECN, then
set the bits to zero on entry and thus do nothing on egress.

No "intent" needs to be communicated, as best I can tell.  It's a
best-effort signaling mechanism.

> If it uses bits either in the TRILL Header or
> in a TRILL Option, these are lost at the egress Rbridge. -- Although
> perhaps affecting Rbridge behavior could also be beneficial. And for IP
> frames, we could set bits in the IP header...

That's it exactly.  I think ECN is pretty much worthless otherwise;
it's an end-to-end exercise involving the transport layer, or it may
as well not be implemented at all.  ECN that's consumed by RBridges
alone doesn't make any sense to me.

> There is also the 802.1 Congestion Management effort perking along...

I'm afraid I don't know what they're doing.  :-<

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677