RBridge Protocol Extensions and the Inner Qtag Location

1
RBridge ProtocolExtensions and the Inner Q-tag
Location

• Donald Eastlake 3rd
• Donald.Eastlake_at_motorola.com

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

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

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.

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.

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.

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?

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.

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 Radias
  initial conference paper.
• IP doesnt 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
• Cant optimize off campus traffic due to the need
  to remember which router it is being sent to.

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.

12
Where Does theRBridge Extension Data Go?
Outer MAC Shim Inner MAC
Inner Inner Data Addresses
Addresess QTag
A
B

• 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.

13
Where Does theInner Q-Tag Go?
Outer MAC Shim Inner MAC
Inner Inner Data Addresses
Addresess QTag

• 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)

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.

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
Nickname
Other Fields
0 1 1 1 0 0 0 0
RBridge1
Extension Flags

• RBridge2 supports and wishes to use extensions B
  and D in a frame to RBridge 1. Shim has

RBridge2
Other, BD flags
Ext. B Data
RBridge1
Ext. D Data
Inner
Ingress Egress
Extensions Data Frame
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.

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.

18
Shim Format Suggestion
Ingress RBridge
V Hop Count M E Reserved
Egress or tree-root RBridge
Pri VLAN ID
Extensions Size
Extension Bits

• 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.

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.