[rbridge] FTag

[Gray, Eric]

Silvano,

	Ethertype is a field in the 802.3 header (see, for example, the
figure at:
http://en.wikipedia.org/wiki/Ethernet#Ethernet_frame_types_and_the_EtherType
_field).

	Assume that - when examining the SHIM header - the Ethernet header
has been
removed, retaining only the relevant "context" information required by a
specific
implementation.  Part of the "context" would be related to MAC DA (is it
mine?),
and Ethertype.  Related to (perhaps as a litteral, perhaps as a mapping),
not the
same as.

	For purposes of examining the SHIM, it is convenient to assume that
it is 
aligned as presented.  How it is actually aligned will be implementation
specific.

	Where alignment matters most is in software used to prepare data for
sending
or decode data on receipt.  In some cases, alignment can be important in
reducing
the complexity of hardware re-use.

--
Eric

--> -----Original Message-----
--> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
--> Sent: Tuesday, October 17, 2006 12:34 PM
--> To: Gray, Eric; Caitlin Bestler
--> Cc: rbridge at postel.org
--> Subject: RE: [rbridge] FTag
--> 
--> 
--> Eric,
--> 
--> Do you include in your computation the 16 bits of Ethertype = TRILL?
--> 
--> -- Silvano
--> 
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
--> > Sent: Monday, October 16, 2006 4:06 PM
--> > To: Silvano Gai; Gray, Eric; Caitlin Bestler
--> > Cc: rbridge at postel.org
--> > Subject: RE: [rbridge] FTag
--> > 
--> > Silvano,
--> > 
--> > 	The "encapsulated frame" alignment varies from layer to
--> > layer and is independent from layer to layer.  When the bits
--> > hit the wire (or glass), the alignment is not of a particular
--> > importance.  It is the process of "hand-off" between stack
--> > layers that might be relevant, depending on implementation.
--> > 
--> > 	It is problematic - at best - to attempt to include the
--> > next layer in the protocol stack in computing alignment, thus
--> > it is not a good idea to take into account bit-wise alignment
--> > of the MAC header when determining the "proper" alignment of
--> > the SHIM, or the "proper" alignment of the next MAC header.
--> > 
--> > 	Hence, if we want to have a 32-bit aligment of the SHIM
--> > header, the options are N*32 bits.
--> > 
--> > --
--> > Eric
--> > 
--> > --> -----Original Message-----
--> > --> From: Silvano Gai [mailto:sgai at nuovasystems.com]
--> > --> Sent: Monday, October 16, 2006 6:21 PM
--> > --> To: Gray, Eric; Caitlin Bestler
--> > --> Cc: rbridge at postel.org
--> > --> Subject: RE: [rbridge] FTag
--> > -->
--> > -->
--> > --> IMHO, since the encapsulated frame should be 32 bit
--> > --> aligned, the size of
--> > --> this option can be 16+n*32, without counting the Ethertype.
--> > --> I proposed
--> > --> n=2, i.e. 80 bits, the only other pragmatic alternative is
--> > --> n=1, i.e. 48
--> > --> bits.
--> > -->
--> > --> -- Silvano
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
--> > --> > Sent: Monday, October 16, 2006 9:29 AM
--> > --> > To: Gray, Eric; 'Caitlin Bestler'
--> > --> > Cc: 'rbridge at postel.org'; Silvano Gai
--> > --> > Subject: RE: [rbridge] FTag
--> > --> >
--> > --> > Oops - "they come in handy 32-bit packages" is the quote
--> > --> I meant to
--> > --> > include...
--> > --> >
--> > --> > --> -----Original Message-----
--> > --> > --> From: Gray, Eric
--> > --> > --> Sent: Monday, October 16, 2006 12:27 PM
--> > --> > --> To: Caitlin Bestler
--> > --> > --> Cc: rbridge at postel.org; Silvano Gai
--> > --> > --> Subject: RE: [rbridge] FTag
--> > --> > -->
--> > --> > --> Actually, it is the fact that "they in handy 32-bit
--> > --> packages" that
--> > --> > --> should mandate the level of need required to justify
--> > --> an extra bit.
--> > --> > -->
--> > --> > --> If inclusion of an extra bit means including 31
--> > --> additional bits,
--> > --> it
--> > --> > --> should be just a little bit harder to justify the extra
--> bit...
--> > --> > -->
--> > --> > --> --
--> > --> > --> Eric
--> > --> > -->
--> > --> > --> --> -----Original Message-----
--> > --> > --> --> From: rbridge-bounces at postel.org
--> > --> > --> --> [mailto:rbridge-bounces at postel.org] On 
--> Behalf Of Caitlin
--> > --> Bestler
--> > --> > --> --> Sent: Monday, October 16, 2006 12:09 PM
--> > --> > --> --> To: Silvano Gai; rbridge at postel.org
--> > --> > --> --> Subject: Re: [rbridge] FTag
--> > --> > --> -->
--> > --> > --> --> rbridge-bounces at postel.org wrote:
--> > --> > --> --> > Another important field proposed in:
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> http://www.ietf.org/internet-drafts/draft-gai-perlman-trill-en
--> > --> > --> --> > cap-00.txt
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> > Is the Ftag (see section 3).
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> > Is there any opposition to add this field?
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> >
--> > --> > --> --> > -- Silvano
--> > --> > --> -->
--> > --> > --> --> Despite the description, this is ultimately a
--> > --> Class of Service
--> > --> > --> --> field. Class of Service fields are always useful,
--> > --> the question
--> > --> > --> --> is whether they are useful enough. Each extra bit is
--> > --> > --> less useful,
--> > --> > --> --> and potentially costs a lot more.
--> > --> > --> -->
--> > --> > --> --> To justify increasing the shim header size I
--> > --> think a scenario
--> > --> > --> --> that would specifically require the extra 
--> classes would
--> be
--> > --> > --> --> useful -- or at least one that exhausts 
--> those available
--> > --> without
--> > --> > --> --> the extra field.
--> > --> > --> -->
--> > --> > --> --> Philosophically, I take the attitude that 
--> the bandwidth
--> > --> belongs
--> > --> > --> --> to the customer. I want a justification for each
--> > --> and every bit
--> > --> > --> --> I take out of it (although realistically I know
--> > --> that they come
--> > --> > --> --> in handy 32-bit packages).
--> > --> > --> -->
--> > --> > --> -->
--> > --> > --> -->
--> > --> > --> --> _______________________________________________
--> > --> > --> --> rbridge mailing list
--> > --> > --> --> rbridge at postel.org
--> > --> > --> --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > --> > --> -->
--> > --> > -->
--> > -->
-->