1 / 10

RBridge Protocol Extensions Proposal

RBridge Protocol Extensions Proposal. Donald Eastlake 3rd Donald.Eastlake@motorola.com Acknoledgements: Erik Nordmark erik.nordmark@sun.com , Radia Perlman radia.perlman@sun.com. Why RBridge Extensions?. Proof by Assumption:

delbertc
Télécharger la présentation

RBridge Protocol Extensions Proposal

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 Proposal Donald Eastlake 3rd Donald.Eastlake@motorola.com Acknoledgements: Erik Nordmark erik.nordmark@sun.com, Radia Perlman radia.perlman@sun.com TRILL 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… • … • To support following possible extensions to RBridge: • LIDs (Local IDs) if there isn’t consensus to put them into the fixed shim • Security, such as Rbridge end to end authentication • The most interesting extensions: those we haven’t thought of yet TRILL Extensions

  3. Typical Protocol Extension • Add some option bits to the protocol header and/or use Type-Length-Value encoded trailer fields that all implementations would have to be able to parse. • Do some sort of end-to-end negotiation to determine what versions of what options are supported. TRILL Extensions

  4. RBridge Extensions 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-option type or length needed (unless variable length), as data only be included if destination understands it and its inclusion is indicated in the shim. Extension data appears in flag bit order. TRILL Extensions

  5. 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 Other Fields… 0 1 1 1 0 0 0 0 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 Ingress Egress Extensions Data TRILL Extensions

  6. Inclusion and Distribution • 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 suppot that extension. TRILL Extensions

  7. Limitations and Advantages • Limitations • Generally restricted to extensions between end RBridges. • Relable 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. TRILL Extensions

  8. Shim Format Suggestion • Assumes 18 bit RBridge nicknames • K = Known unicast frame if 1, multicast/broadcast/unknown if 0. • A, B, C, D = spare reserved bits. • E = Extensions size and bits octets present. RBridges that do not support any extensions do not need to understand this bit. • Extension size is there only so that intervening devices can always snoop beyond the shim in RBridge frames. Such devices need to understand the E bit and Extensions Size field. Ingree RBridge nickname ABCDE Hop Count K Egress or tree-root RBridge Extensions Size Extension Bits TRILL Extensions

  9. Specific Unicast Example: LIDs • Note: This is not meant to assert that there should or should not be LIDs or that they should or should not be an extension. It is just an example. • Allocate one bit in the per RBridge IS-IS TLV to indicate LIDs are supported. • Allocate one bit in the RBridge shim to indicate LIDS are present. • When bit is on, a 16 bit ingress LID and 16 bit egress LID are appended to the shim. • LID extension would only be used when both source and destination RBridges support it. TRILL Extensions

  10. Documentation Suggestion • RBridge protocol specification would include only the extension framework • Each extension is documented in a separate document, requires an IETF Review for approval TRILL Extensions

More Related