1 / 19

RBridge Protocol Extensions and the Inner Q-tag Location

RBridge Protocol Extensions and the Inner Q-tag Location. Donald Eastlake 3rd Donald.Eastlake@motorola.com. Why RBridge Extensions?. Proof by Assumption: It is intuitively obvious that protocols need an extension facility… Proof by Tradition: All IETF Protocols have extensions…

race
Télécharger la présentation

RBridge Protocol Extensions and the Inner Q-tag Location

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RBridge ProtocolExtensions and the Inner Q-tag Location Donald Eastlake 3rd Donald.Eastlake@motorola.com RBridge Extensions

  2. 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… • … RBridge Extensions

  3. 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. RBridge Extensions

  4. Protocol Extension Methods • 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 • 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 RBridge Extensions

  5. Typical Protocol Extension Methods • 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. RBridge Extensions

  6. 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. RBridge Extensions

  7. 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. RBridge Extensions

  8. 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? RBridge Extensions

  9. 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. RBridge Extensions

  10. 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: • broadcast • any IP address derived multicast • 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 • the broadcast MAC address • the derived multicast MAC address • 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. RBridge Extensions

  11. 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. RBridge Extensions

  12. Where Does theRBridge 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 A B RBridge Extensions

  13. Where Does theInner 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 RBridge Extensions

  14. 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. RBridge Extensions

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

  16. 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. RBridge Extensions

  17. 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. RBridge Extensions

  18. Shim Format Suggestion Ingress RBridge V Hop Count M E Reserved • 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. Egress or tree-root RBridge Pri VLAN ID Extensions Size Extension Bits RBridge Extensions

  19. 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. RBridge Extensions

More Related