[rbridge] TRILL Header Format
Eastlake III Donald-LDE008
Donald.Eastlake at motorola.com
Mon May 7 10:36:18 PDT 2007
I agree, although it is trivially easier to calculate the offset if the
VLAN tag information is in the TRILL Header.
I never claimed the current design wouldn't work or can't be
implemented. It just seems to me that saving 2 bytes on every frame and
speeding up cut through switching by moving the VLAN tag information at
least 14 bytes earlier in the frame are more important.
Donald
-----Original Message-----
From: J. R. Rivers [mailto:jrrivers at nuovasystems.com]
Sent: Monday, May 07, 2007 11:51 AM
To: Eastlake III Donald-LDE008; Joe Touch
Cc: Rbridge at postel.org
Subject: RE: [rbridge] TRILL Header Format
In all fairness, the VLAN tag is at an easily calculated offset with
either proposal.
> -----Original Message-----
> From: rbridge-bounces at postel.org
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III
> Donald-LDE008
> Sent: Tuesday, May 01, 2007 7:43 PM
> To: Joe Touch
> Cc: Rbridge at postel.org
> Subject: Re: [rbridge] TRILL Header Format
>
> Hi Joe,
>
> I see it as exactly the other way.
>
> Most commonly, the VLAN ID is associated with a native frame only
> because of the port it is received on, although it is
> certainly possible
> for an end station to include one. Thus, in the most common
> case, it is
> the current design which requires the ingress Rbridge to insert a Q/S
> tag inside the encapsulated frame, thus modifying it, and
> similarly most
> commonly requires the egress Rbridge to remove that tag from
> inside the
> encapsulated frame, although their can be configurations where it is
> retained.
>
> Thus, Solution 2 would generally require *less* modification of
> encapsulated frames at ingress and egress than would Solution 1.
>
> The above is in answer to your point on 'modification' since I believe
> Solution 2 results in less modification. I'm not sure I
> understand your
> "parsing and debugging" point. For every Rbridge other than
> the ingress
> Rbridge, for every frame the Rbridge has to (a) find the TRILL Header
> and (b) find the VLAN tag. It seems to me to make the parsing job
> simpler to put the VLAN tag information at a fixed location
> in the TRILL
> Header.
>
> Donald
>
> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Tuesday, May 01, 2007 5:33 PM
> To: Eastlake III Donald-LDE008
> Cc: Dinesh G Dutt; Silvano Gai; Rbridge at postel.org
> Subject: Re: [rbridge] TRILL Header Format
>
> Eastlake III Donald-LDE008 wrote:
> > Hi,
> >
> > I agree with Dinesh's comment and would also like to say that my
> > personal preference is for Solution 2. I just don't feel there are
> > enough reserved bit available for future use in the minimal
> Solution 1
> > and since, in the general case, every Rbridge has to look
> at the VLAN
> > ID, putting it in a fixed place nearer the beginning of the
> frame, as
> > done in Solution 2, seems like a good idea.
>
> I agree in spirit, but don't agree that the inner frame should be
> modified during processing; this just complicates parsing and
> debugging,
> and increases the potential for implementation errors.
>
> IMO, the VLAN tags should be copied, not moved.
>
> Joe
>
> > Thanks,
> > Donald
> >
> > -----Original Message-----
> > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
> On
> > Behalf Of Dinesh G Dutt
> > Sent: Monday, April 30, 2007 3:19 PM
> > To: Silvano Gai
> > Cc: Rbridge at postel.org
> > Subject: Re: [rbridge] TRILL Header Format
> >
> > Two small corrections. In the second format, we really
> don't need any
> > indication of .1Q/.1S. The tag that is to be added at the
> egress port
> > maybe different from the tag that we received at the
> ingress port and
> is
> >
> > part of the port logic. For example, the frame may have
> come in with a
>
> > .1Q tag and may go out a port that accepts no tagging at all.
> >
> > Given that we don't need to carry any indication of .1Q/.1S in the
> TRILL
> >
> > header, I suggest that we also define the field "Inner 802.1Q/S tag"
> to
> > be {VL (3b), DE (1b), VLAN (12b)} i.e. remove the CFI indicator and
> call
> >
> > it DE (drop eligibility). This way if RBridges along the way can
> choose
> > to set the DE bit in the inner header, instead of treating it as an
> > opaque field.
> >
> > Dinesh
> > Silvano Gai wrote:
> >> The purpose of the following message is to converge on the final
> >> structure of the TRILL header.
> >>
> >> The format proposed in:
> >>
> >
> http://www.ietf.org/internet-drafts/draft-ietf-trill-rbridge-p
rotocol-03
> >> .txt
> >> has been stable for a while. This message only describes the
> >> differences.
> >>
> >> At the last IETF Donald proposed to support a single
> extension header
> >> containing multiple extensions.
> >>
> >> After some discussion two solutions seem possible. Please express
> your
> >> preference by replying to this email.
> >>
> >> -- Silvano
> >>
> >>
> >> Solution 1
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | V
> |M|RSD|EH-length| Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Ingress RBridge Nickname | Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> Where:
> >> - RSD (2 bits) is reserved
> >> - EH-Length (5 bits) is the extension header length, expressed in
> > units
> >> of in 4 bytes words.
> >>
> >> If EH-length is zero there is no extension header;
> >> else, the extensions follow immediately after the Egress Rbridge
> >> Nickname field, and the total length of all the extensions is as
> >> indicated by the EH-length field, expressed in units of
> 4-byte words.
> >>
> >> This solution allows 128 bytes of extensions.
> >>
> >>
> >> Solution 2
> >> ==========
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | V |M|S| RSD | Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | RSD | EH-length | Inner IEEE 802.1Q/S tag
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Ingress RBridge Nickname | Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> This solution moves the Inner IEEE 802.1Q/S tag (VLAN-ID and
> Priority)
> >> into the TRILL header. The Inner 1Q/1S tag is no longer present in
> the
> >> inner frame.
> >>
> >> This simplifies the parsing for the core RBridges. On the
> other hand
> > the
> >> Ingress/Egress Rbridges need to do slightly more work.
> >>
> >> This has more reserved space. Since the inner 1Q/1S tag is removed
> > from
> >> the frame (4 bytes), it uses the same overall space of solution 1.
> >>
> >> The S bit indicates if the inner header was 1Q (S=0) or 1S (S=1).
> >>
> >> The EH-length is 8 bits, with a granularity of 2 bytes it allows up
> to
> >> 512 bytes of extensions.
> >>
> >> The Hop Count can grow to 8 bits.
> >>
> >>
> >> A word of caution
> >> =================
> >>
> >> Extensions are very appealing, but their practical deployment has
> been
> >> very limited. Often Router and Switches are not able to
> process in HW
> >> frames with extensions and they send them to SW.
> >>
> >>
> >> Example with Solution 1
> >> =======================
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Outer Destination MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Outer Destination MAC Address | Outer Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Outer Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Ethertype = IEEE 802.1Q | UP |C| Outer VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Ethertype = TRILL | V
> |M|RSD|EH-length| Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Ingress RBridge Nickname | Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Inner Destination MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Inner Destination MAC Address | InnerSource MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Inner Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Ethertype = IEEE 802.1Q | UP |C| Inner VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> |
> > |
> >> | Original Ethernet Payload
> > |
> >> |
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | New FCS
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> TRILL Encapsulation over Ethernet with Solution 1
> >>
> >>
> >>
> >>
> >> Example with Solution 2
> >> =======================
> >>
> >>
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Outer Destination MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Outer Destination MAC Address | Outer Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Outer Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Ethertype = IEEE 802.1Q | UP |C| Outer VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Ethertype = TRILL | V |M|S| RSD | Hop Count
> > |
> >>
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | RSD | EH-length | UP |C| Inner VID
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Ingress RBridge Nickname | Egress RBridge Nickname
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Inner Destination MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Inner Destination MAC Address | InnerSource MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | Inner Source MAC Address
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> |
> > |
> >> | Original Ethernet Payload
> > |
> >> |
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> | New FCS
> > |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >> TRILL Encapsulation over Ethernet with Solution 2
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> rbridge mailing list
> >> rbridge at postel.org
> >> http://mailman.postel.org/mailman/listinfo/rbridge
> >>
> >>
> >
>
> --
> ----------------------------------------
> Joe Touch
> Sr. Network Engineer, USAF TSAT Space Segment
More information about the rbridge
mailing list