1 / 11

Base Protocol Document: Possible -05 to -06 Changes

This document outlines potential changes to the Base Protocol future version (v2), including updates to pseudo-code, elimination of the TRILL Header "M" bit, transitioning from Q-tag to S-tag for Inner VLAN tags, and new approaches for zero-configuration alternative tree roots. The proposed adjustments aim to improve scalability, simplify protocols, and enhance error message handling. Detailed technical explanations for these changes are provided to ensure clarity and rigor in the updated draft, enhancing the overall functionality and efficiency of the network protocol.

kagami
Télécharger la présentation

Base Protocol Document: Possible -05 to -06 Changes

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. Base Protocol Document:Possible -05 to -06 Changes Donald Eastlake 3rd +1-508-786-7754 Donald.Eastlake@motorola.com Base Protocol Future (v2)

  2. Potential Changes in -06 • Update the Pseudo-Code to correspond to the rest of the -05 draft and other changes adopted. • Other possible changes: • Eliminate the TRILL Header “M” (Multi-destination) bit. • Change inner VLAN tag to an S-tag. • Zero configuration alternative tree roots. • “Error” Messages. Base Protocol Future (v2)

  3. Update the Pseudo-Code • The pseudo-code is essentially unchanged from -04 to -05 while the text was changed as described in another presentation. • Update pseudo-code to correspond to the text. • Update pseudo-code to incorporate other changes. • Make pseudo-code more detailed and rigorous. Base Protocol Future (v2)

  4. Eliminate the “M” Bit • Currently the “M” or “multi-destination” bit in the TRILL Header means that the “egress RBridge nickname” field is actually the root of the distribution tree. • This is logically unnecessary: • M = 0 only for known unicast and core IS-IS frames. • M = 1 for all other frames Base Protocol Future (v2)

  5. Eliminate the “M” Bit (cont.) • Core IS-IS frames are identified by an inner DA of All-Rbridges with no inner VLAN tag. Thus you can always tell if something is a core IS-IS frame without the M bit. • Unicast is identified by a unicast inner DA. The only question is how to tell known unicast from unknown unicast. Base Protocol Future (v2)

  6. Eliminate the “M” Bit (cont.) • TRILL Header field V = 0, according to protocol draft -05, indicates core IS-IS, known unicast, or unanalyzed IP based multicast.V = 1 indicates per VLAN IS-IS, broadcast, unknown unicast, or IP based multicast that should be pruned on VLAN only. • So • (V = 0) and (core IS-IS or inner DA unicast)=> M = 0 • Otherwise M = 1 Base Protocol Future (v2)

  7. Inner VLAN tag -> S-Tag • The current protocol specification requires that the inner VLAN tag be a Q-Tag (official a “C-Tag” now). S-Tag is more expressive for QoS. • Only 1 bit different between Q and S tags: “Canonical Format Indicator” for Q-tags, “Drop Eligible Indicator” for S-tags. Current spec says CFI = 0 in inner tag. • Inner VLAN tag is only seen by TRILL knowledgeable devices. • Inner Tag priority and VLAN ID typically constructed at ingress RBridge. Suggest using S-Tag so the DEI would be available. Base Protocol Future (v2)

  8. Zero Configuration Alternative Trees • Improve scalability by decreasing the number of trees for zero configuration campuses. • Example conservative rule: • If there are one or more adjacent Rbridges with RequestTree set that are of higher order (have more IS-IS adjacencies) and none that are of a lower order, it is RECOMMENDED that an Rbridge • list one or more of such higher order Rbridges as ones it might use as a distribution tree root, • clear its RequestTree flag, and • use only such listed Rbridges as tree roots for multi-destination frames it encapsulates. Base Protocol Future (v2)

  9. Zero Configuration Alternative Trees (cont.) (x) = Order X Rbridge B (2) Rbridge A (1) Rbridge D (2) Rbridge C (4) Rbridge G (1) Rbridge E (2) Rbridge F (2) Base Protocol Future (v2)

  10. “Error” Messages • Possible reasons: • “Known” unicast arrives at destination with unknown inner DA. • Frame (other than core IS-IS) has unknown egress nickname in header. • Distribution tree root is known nickname but that RBridge does not have RequestTree bit set. • Hop Count exhausted. • Illegal field value (nickname, VLAN ID, …). • Etcetera Base Protocol Future (v2)

  11. “Error” Messages (cont.) • All/Some optional to generate? • Sent with lower priority than “erroneous” frame • What to do about “error” in lowest priority frame? • In this case, send with same priority or not at all… • How to encode/transport? • In most cases could unicast to the ingress RBridge with a special inner DA Base Protocol Future (v2)

More Related