1. March 2007RBridge Extensions1 RBridge Protocol Extensions and the Inner Q-tag Location Donald Eastlake 3rd Donald.Eastlake@motorola.com

2. March 2007RBridge Extensions2 Why RBridge Extensions? Proof by Assumption: –It is intuitively obvious that protocols need an extension facility… Proof by Tradition: –All IETF Protocols have extensions… Proof by Aesthetics: –Extensible protocols are beautiful, nonextensible ones are ugly… Proof by Intimidation: –Any fool can see that protocols need an extension mechanism… …

3. March 2007RBridge Extensions3 Note: I do not mean to suggest that we should do detailed work on any particular Extension. However, if we want the capability to add extensions any time later, then we should to include a framework in the initial design.

4. March 2007RBridge Extensions4 Protocol Extension Methods 1.Ethertype or Version Number: –Advantages: Efficient – new version can be optimally designed For Ethertype: efficient dispatch –Disadvantages: Inflexible – only one dimension of change, falling back to lower version number is all you can do For Ethertype: may be hard to get multiple Ethertypes 2.Type-Length-Value encoded extension fields: –Advantages: Very flexible - can mix and match fields Can skip “non-critical” fields –Disadvantages: Less efficient due to type-length overhead All implementations would have to parse this format

5. March 2007RBridge Extensions5 Typical Protocol Extension Methods 3.Option bits in the protocol header –Advantage: Flexible - can mix and match fields –Disadvantages: A limited number of bits Implementations need to know field lengths for bits they have to pay attention to Hybrid combinations of TLV and options bits are possible.

6. March 2007RBridge Extensions6 Other Factors Variability tends to be inefficient to process no matter what. Regardless of how extensions are indicated, some way to find the inner frame data must be present so that boxes can delve deeper into the frame and implement policy based on deeper fields. –Implies that you must use TLVs or, if extensions bits are used, also provide an overall extension data length or the like.

7. March 2007RBridge Extensions7 How is TRILL Different? Most protocols do end-to-end negotiation to determine what versions of what extensions are supported. The biggest difference between the TRILL case and most protocols is the “Link State” distribution mechanism. Thus, every RBridge can easily know what extensions every other RBridge supports but distributing that information. –While a complicated extension might require some negotiation, you never need to do “negotiation” to find out if an extension itself is supported. Like some other protocols, but unlike others, TRILL is generally multi-hop; that is, there are generally intermediate RBridges.

8. March 2007RBridge Extensions8 Types of RBridge Extension Two types of Extensions: –End-to-end extensions: only the ingress and egress RBridges need to know about it LID extension (saves port look up at egress) IP optimization: drop inner MAC addresses for in- campus IP packet, except unknown unicast Security: ingress to egress authentication and/or confidentiality –Hop-by-hop: every RBridge along the path would need to know about it Record route extension?

9. March 2007RBridge Extensions9 End-to-End Example: LID Note: This is not meant to assert that there should or should not be LIDs or a LIDs extension. Only makes sense for unicast and when both ingress and egress RBridge are known to support it. LID = Local ID and maps to a port (or is a special value indicating port unknown). When this extension is used, a 16 bit ingress and egress LIDs are appended to the shim. Ingress LID is included to support automatic learning. Lookup at ingress RBridge can populate egress LID, thus saving a table lookup by MAC at the egress.

10. March 2007RBridge Extensions10 IP Optimization Note: This is not meant to assert that there should or should not be an IP optimization extension. This idea is taken from Radia’s initial conference paper. IP doesn’t really care much about MAC addresses. You can optimize out the inner MAC address for in campus traffic for: 1.broadcast 2.any IP address derived multicast 3.unicast IP where the egress RBridge is known Egress RBridge reconstitutes the MAC addresses by using the egress port for the source MAC and using 1.the broadcast MAC address 2.the derived multicast MAC address 3.the looked up ARP/ND cache MAC address Can’t optimize off campus traffic due to the need to remember which router it is being sent to.

11. March 2007RBridge Extensions11 Security Extension Note: This is not meant to assert that there should or should not be a Security extension. A Security Extension would encrypt and/or add a Message Authentication Code to frames on an RBridge to RBridge basis. Probably ingress RBridge to egress RBridge but even then it might be possible for security aware intermediate RBridges to check authenticity. In theory could also apply to multicast. This would be a complex extension requiring negotiation for key set up, etc.

12. March 2007RBridge Extensions12 Where Does the RBridge Extension Data Go? “A” is the obvious place but then the Q-Tag, which every RBridge must look at, is at a variable location and requires skipping over a variable amount of extension data at “A”. “B” is probably better, but this makes extension data harder to find, putting it inside the inner frame. Situation will get even more complex as 802.1 adds congestion, security, etc. tags to frames. Outer MAC Shim Inner MAC Inner Inner Data Addresses Addresess QTag AB

13. March 2007RBridge Extensions13 Where Does the Inner Q-Tag Go? So, why exactly are we inserting a Q-Tag into the inside of the inner frame on ingress? If Q-Tag data were moved into a fixed shim field: –The data would be in a fixed position and be earlier in the frame (important) –You would save the two bytes of Q-Tag Ethertype (unimportant) Outer MAC Shim Inner MAC Inner Inner Data Addresses Addresess QTag

14. March 2007RBridge Extensions14 Specific Extension Proposal Add reserved bits to announce supported options in the per-RBridge IS-IS flooded TLV element that announces nickname, etc... –No extra “negotiation” messages required in simple cases. Include reserved bits in the shim to indicate that extension data is appended. –Extension data only included for extensions present. –No per-extension type or length needed (unless variable length). Data will only be included if destination understands it and its inclusion is indicated in the shim. Append extension data to shim in flag bit order.

15. March 2007RBridge Extensions15 Generic Example RBridge1 announces that it supports extensions B, C, and D. Per-RBridge IS-IS element has: NicknameOther Fields… RBridge2 supports and wishes to use extensions B and D in a frame to RBridge 1. Shim has: 0 1 1 1 0 0 0 0 A B C D E F G H Extension Flags RBridge2Other, B&D flagsExt. B Data Ingress Egress Extensions Data Frame RBridge1Ext. D Data RBridge1: Inner

16. March 2007RBridge Extensions16 Inclusion and Distribution of End-to-End Extensions For known unicast RBridge frames –Only extensions supported by both ingress and egress are allowed. –Extensions may be ignored by intervening RBridges. For broadcast/multicast/unknown RBridge frames –Ingress RBridge can include any extension it understands. –RBridges must remove any extension not understood by the next hop RBridge before forwarding. –Thus broadcast/multicast/unknown distribution of extensions, even to egress RBridges that implement them, is unreliable unless all RBridges in the net support that extension.

17. March 2007RBridge Extensions17 Limits and Advantages of Proposal for End-to-End Ext. Limits –Generally restricted to extensions between end RBridges. –Reliable delivery only for known unicast unless every RBridge in the net understands the extension. Advantages –Zero code in RBridges that do not implement any extensions. –Zero end-to-end negotiation messages for simple extensions. –Compact extension data because type and length information not generally required.

18. March 2007RBridge Extensions18 Shim Format Suggestion V = Version, M = Multiple Destinations E = Extensions size and bits octets present. RBridges that do not support any extensions do not need to understand this bit. Extension size is so that intervening devices can snoop beyond the shim. Such devices need to understand the E bit and Extensions Size field. Extensions Size Extension Bits Ingress RBridge Egress or tree-root RBridge V Hop Count M E Reserved Pri VLAN ID

19. March 2007RBridge Extensions19 What I am Suggesting We Do Move the Q-tag data (priority and VLAN ID) to inside the shim. Include an extension framework in the RBridge protocol specification. Particular extensions would be specified in separate documents.