[rbridge] FTag
Silvano Gai
sgai at nuovasystems.com
Wed Oct 18 09:04:01 PDT 2006
Eric,
Let me depict you what happens when you insert one MPLS label, ore a 1Q
option or a 1S option
Original:
+--------------------------------+
| DA |
+----------------+---------------+
| DA | SA |
+----------------+---------------+
| SA |
+--------------------------------+
| Ethertype | Payload |
+--------------------------------+
| |
| ........... |
Original + Opt (where Opt can be MPLS, 1Q or 1S)
+--------------------------------+
| DA |
+----------------+---------------+
| DA | SA |
+----------------+---------------+
| SA |
+--------------------------------+
| Ethertype | Opt |
+--------------------------------+
| opt | Payload |
+--------------------------------+
| |
| ........... |
The HW that perform the insertion/removal does not need to realign the
payload that is in its buffer.
Now Let's consider the encapsulation/decapsulation function by looking
at the Original frame + TRILL header (as proposed by the current draft)
+--------------------------------+
| Outer DA |
+----------------+---------------+
| Outer DA | Outer SA |
+----------------+---------------+
| Outer SA |
+--------------------------------+
|Ethertype=TRILL | Trill Shim |
+--------------------------------+
| Trill Shim | ???????? |
+--------------------------------+
| DA |
+----------------+---------------+
| DA | SA |
+----------------+---------------+
| SA |
+--------------------------------+
| Ethertype | Payload |
+--------------------------------+
| |
| ........... |
If you don't have the 16 bits indicated by ???????, the hardware will
need to realign the inner frame. The frame is not on the wire. The frame
sits in the packet buffer and the memory bandwidth of the packet buffer
is today the MOST important consideration in port ASIC design.
More inline
> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> Sent: Wednesday, October 18, 2006 4:57 AM
> To: Silvano Gai
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] FTag
>
> Silvano,
>
> Let me answer your points in order, leaving out irrelevant issues:
>
> <Your Point> N*32 is correct, when including Ethernet options/shims
> (e.g. .1Q or .1S). This is hardware friendly, because
> alignment doesn't change going from one header to
another.
>
> There are a few different "Ethernet" encapsulations, once we start to
> include Ethernet options and the shims associated with those options.
>
> First, and I believe most important, the "shim" we are talking about
> (in TRILL) is not an Ethernet option (or associated shim). It's a
> "shim" as a separate "layer." Otherwise, it would be inappropriate
> for us to do this work here (in TRILL, as part of the IETF).
>From the above picture it should be clear that you should consider the
TRILL header as a whole, and the TRILL header as only one form of
Ethernet encapsulation.
>
> Second, "Ethernet" headers do not all align the same.
>
Agreed, but that is not my concern, My concern is to not change their
alignment due to the insertion/removal of the TRILL header.
> Currently, we are talking about having a single Ethertype defined to
> distinguish inter-RBridge traffic from other types of Ethernet frames.
> If your implementation produces 32-bit aligned Ethernet frames, using
> 802.1Q, then it will similarly produce 32-bit aligned frames - prior
> to considering the TRILL shim - using the new Ethertype.
>
> We are not proposing a change in any Ethernet frame/header format.
Neither do I.
>
> The reference to 802.1Q is slightly disingenuous, because 802.1Q
> effectively displaces the existing Ethertype by 32 bits. 802.1Q
> "shims" include the Ethertype, because they replace the original
> one with 0x8100 and have to include the original in the "shim."
>
> I assume that a similar observation could be made about 802.1S.
Yes and a similar observation can be made for MPLS, but all these three
do not change the alignment of the fields that follow.
>
> In TRILL, we are not replacing the original Ethertype, we are adding
> a new encapsulation. The original Ethertype stays in the original
> - re-encapsulated, or tunneled - Ethernet frame. Therefore, there's
> no reason to consider the Ethertype to be part of the TRILL shim.
As I told before you need to consider the whole TRILL header, i.e.
6 bytes of DA
6 bytes of SA
2 bytes of Ethertype
4 bytes of shim
----------------------
18 bytes
Which is 2 bytes short of N*32, i.e. it is not HW friendly.
For this reason I propose that Ethertype + shim should be N*32 to be HW
friendly.
>
> <Your Point> TRILL should adopt this model for its shim header - the
> Ethertype should be included as part of computing "shim"
> size.
>
> In TRILL, we are not replacing the original Ethertype, we are adding
> a new encapsulation. The original Ethertype stays in the original
> - re-encapsulated, or tunneled - Ethernet frame. Therefore, there's
> no reason to consider the Ethertype to be part of the TRILL shim.
>
> <Your Point> TRILL should optimize the Ethernet case that will cover
99%
> of TRILL applications.
>
> Coverage is slightly more complete than that. Considering all of the
> layer 2 encapsulations that currently come under an Ethernet umbrella,
> TRILL applications are 100% included.
>
> I think we are essentially in agreement on this point.
>
> <Your Point> TRILL bridges will be implemented mainly in hardware and
> the encapsulation and decapsulation functions need to be
> HW friendly.
>
> Okay. I was not making any other point - except to say that alignment
> is usually a software concern, especially in initial design.
>
> Let me be blunt, alignment does not factor into initial hardware
design,
> but is an issue with hardware re-use complexity. Bits on a wire are
not
> "aligned" - you simply collect them as they arrive, serially.
I agree that bits on the wire are not aligned, but you need to buffer
the incoming frame (or at least part of it) until you have enough fields
to perform your lookup and decide what to do with the frame. From that
point on the frame is not on the wire, it is in the packet buffer and
alignment is crucial at the performance we are talking about.
I hope this time I made my point more clear
-- Silvano
>
> And, in any case, the "alignment issue" is moot, unless you assume
that
> we need to add an _additional_ Ethertype and I am not including that
in
> my size computation.
>
> We do not need the additional Ethertype, consequently, we do not have
to
> account for it.
>
> --
> Eric
>
> --> -----Original Message-----
> --> From: Silvano Gai [mailto:sgai at nuovasystems.com]
> --> Sent: Wednesday, October 18, 2006 12:05 AM
> --> To: Gray, Eric; Caitlin Bestler
> --> Cc: rbridge at postel.org
> --> Subject: RE: [rbridge] FTag
> -->
> -->
> --> Eric,
> -->
> --> I beg to differ.
> -->
> --> N*32 is correct, if you include the 16 bits of Ethertype.
> -->
> --> With all the respect for wikipedia, I prefer a reference to IEEE
> 802.1Q
> --> and IEEE 802.1D in which the Ethertype is considered part of the
> options/shims.
> -->
> --> This is what happens for options like .1Q or .1S (16 bit of
Ethertype
> +
> --> 16 bits of options).
> -->
> --> This is hardware friendly, since inserting or removing the shim
does
> not
> --> change the 32 bit alignment of what follows.
> -->
> --> IMHO TRILL should adopt a shim header that is N*32 including the
> --> Ethertype = TRILL or 16 + M*32 excluding the Ethertype.
> -->
> --> I don't buy that, to be layer 2 independent, we need to not
optimize
> the
> --> Ethernet case that will cover 99% of TRILL applications.
> -->
> --> I also don't buy any software implementation arguments: TRILL
bridges
> --> will be implemented mainly in hardware and the encapsulation and
> --> decapsulation functions need to be HW friendly.
> -->
> --> -- Silvano
> -->
> -->
> --> > -----Original Message-----
> --> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
> --> > Sent: Tuesday, October 17, 2006 9:48 AM
> --> > To: Silvano Gai; Gray, Eric; Caitlin Bestler
> --> > Cc: rbridge at postel.org
> --> > Subject: RE: [rbridge] FTag
> ---[SNIP]---
More information about the rbridge
mailing list