Early history of the TRILL header
Posted by Kris Price | March 11, 2009 | No Comments
Stemming from my interest in why TRILL did not use MPLS, I have summarised the early history of the TRILL header. This can also be found in plain-text format here. There is still more to it, which I shall attempt to elaborate on later, but this covers the shift away from a MPLS.
An abridged history of the RBridge header
Written by Kris Price, 10 March 2009.
Note: Names and references have been excluded to prevent anyone being unwillingly associated with my interpretation of events. Naturally I have no visibility of meetings or private discussions. The details can be found by reading the TRILL mailing list archive of the period from October to December, 2006.
TRILL initially looked to use MPLS based encapsulation for RBridges, as described in draft-bryant-perlman-trill-pwe-encap-00. The approach created a global MPLS labelspace from which RBridges selected their nicknames. The MPLS header would only include egress RBridge, CoS, and TTL information. An RBridge would make additional forwarding decisions, for example to constrain delivery of a VLAN tagged frame to only those links on which that VLAN is active, by using the information in the encapsulated MAC header. This was a deviation from the general architecture of MPLS that such forwarding decisions are made at the edge by selecting the correct label switch path. The responsibility falling to the control-plane to set up the necessary label switched paths accordingly. Hence the amount of hardware re-use at the time may have been limited depending on whether this filtering became a strict requirement or an option that could be phased in as new hardware was developed. Because this type of filtering has unrelated benefits it may well find its way into many platforms anyway, and today some platforms may already have some of this capability for that reason.
A potential requirement for the inclusion of ingress RBridge information within the header was raised on the mailing list in October 2006. It was based on the need to possibly support 802.1au Congestion Notification, in which notifications must be returned to the end-station that sent the triggering frame. To do this, it was argued that an RBridge trying to send such a notification would need to know the ingress RBridge. It was suggested that the ingress RBridge could be identified by looking at the source MAC address in the encapsulated MAC header. One group felt it was inappropriate for a core RBridge to maintain all of the MAC reachability information, as would be required in order to do this lookup. Another group felt this was reasonable, as that is what core IEEE bridges to today. In the case where all of the MAC reachability information was not maintained, the approach of sending the notification over the multi-destination delivery tree (since it is then effectively an unknown destination frame) was rejected as having negative impacts.
Other fields were also proposed for inclusion in the header at this time, as described in draft-gai-perlman-trill-encap-00, but these were eventually ruled out, or incorporated in other ways. The resulting approach that was settled on was to include ingress and egress RBridge information. This was seen as more natural and flexible to future requirements. The option of continuing to use MPLS based encapsulation was raised, using a label stack, with the top label as per the original proposal, and the bottom label identifying the ingress RBridge. This appears to have received very little attention. I can only speculate that it was rejected out of a belief that MPLS based encapsulation brought little benefit, in which case a simplified 6-byte header versus an 8-byte header was more elegant.
The use of the encapsulation defined for 802.1ah Provider Backbone Bridges was raised at the IETF-67 meeting in November, 2006. At the time 802.1ah was on its way to becoming a standard, and the question was whether there were any synergies between it and RBridges that could be capitalised on. Subsequent discussions on the mailing list ultimately rejected the idea for a few reasons. There was a feeling that 802.1ah was targeted at the provider market and so unsuitable for the enterprise and data centre market, although it is unclear why this made it unsuitable. There was a larger concern that 802.1ah would require a partial move away from zero configuration, although this was never clearly detailed. The clearest arguments against the use of 802.1ah were the lack of a TTL in the header, and the lack of a next-hop address. It was suggested that a TTL could be accommodated in the header before the standard was finalised, but the lack of a next-hop address was unresolved. RBridges uses the outer MAC encapsulation to define the next-hop on each link, this allows load balancing to multiple next-hop RBridges across a shared link. It is unclear whether the benefits of this versus the benefits of a shared encapsulation were weighed.
When 802.1ah based encapsulation was proposed it was noted that by using a non-IEEE frame format TRILL would be assuming responsibility for implementing all of the features developed by IEEE.
Subsequent to this the header acquired the options fields to permit extensions, and it has resulted in the TRILL header seen today.
The end.
Comments
Leave a Reply
Latest: NZ FTTH Blog- Roads vs. FTTH 1 June 2009
- Point-to-point vs. PON 1 June 2009
- News Roundup 14 May 2009
- The Australian Estimate 14 May 2009
- HFC vs. PON 14 May 2009