TRILL Working Group

1
TRILL Working Group

• Changes fromdraft-trill-rbridge-protocol-02.txt
• to
• draft-trill-rbridge-protocol-03.txt
• Dinesh Dutt, Cisco
• Silvano Gai, Nuova
• Radia Perlman, Sun

2
Added the RBridge Model
-------------------------------------------------
--------- Higher Layer
Entities -----------------
------------------------------------- \
Trill Layer RBridge Relay Entity Trill Layer
/ ---------------------------------------
--------------- Data Link Layer
Data Link Layer -----------------
-----------------
Physical Layer Physical
Layer ----------------
----------------
P1
P2

• An Rbridge Relay Entity that interconnects two
  Rbridge ports
• At least one port (two in the example)
• Higher Layer Entities, including at least the
  IS-IS protocol.
• The TRILL Layer. An RBridge encapsulates incoming
  IEEE 802.3 frames (in this document also
  referred to as Ethernet frames) with a
  TRILL header to forward them to other Rbridges.

3
Added examples of Encapsulations
-------------------------------- Outer
Ethernet Header -------------------------
------- TRILL Header
-------------------------------- Inner
Ethernet Header -------------------------
------- Ethernet Payload
--------------------------------
Ethernet FCS
--------------------------------
--------------------------------
PPP Header --------------------------
------ TRILL Header
-------------------------------- Inner
Ethernet Header -------------------------
------- Ethernet Payload
--------------------------------
Ethernet FCS
--------------------------------
4
Defined the term Multi-Destination

• It identifies 1. frames for unknown unicast
  destinations the Inner.MacDa is unicast,
  but the ingress RBridge does not know its
  location 2. frames for layer 2 multicast
  addresses derived from IP multicast
  addresses the Inner.MacDa is multicast 3.
  frames for layer 2 multicast addresses not
  derived from IP multicast addresses the
  Inner.MacDa is multicast 4. frames for the
  layer 2 broadcast addresses the Inner.MacDa is
  broadcast 5. ARP queries the
  Inner.MacDa is broadcast 6. ND queries the
  Inner.MacDa is multicast

5
TRILL Header Format

----------------
V Hop Limit M
Reserved ---------------
-----------------
Ingress RBridge Address Egress RBridge
Address -------------
-------------------

• V (Version) 2-bit. See Section 3.1.1.
• Hop Limit 6-bit unsigned integer. See Section
  3.1.3.
• M (Multi-destination) 1-bit. See Section 3.1.2.
• Reserved 7-bit.
• Ingress RBridge Address 16-bit address. See
  Section 3.1.4.2.
• Egress RBridge Address 16-bit address. See
  Section 3.1.4.1.

6
Added Ethernet Encapsulation
----------------------
----------
Outer Destination MAC Address
---------------------
----------- Outer Destination
MAC Address Outer Source MAC Address
-----------------------
---------
Outer Source MAC Address
-----------------------
--------- Ethertype IEEE
802.1Q UP C Outer VID
-----------------------
--------- Ethertype TRILL
V Hop Limit M Reserved
-------------------------
------- Egress RBridge Address
Ingress RBridge Address
-------------------------
------- Inner
Destination MAC Address
------------------------
-------- Inner Destination MAC
Address InnerSource MAC Address
-------------------------
------- Inner
Source MAC Address
-------------------------
------- Ethertype IEEE 802.1Q
UP C Inner VID
-------------------------
-------

Original Ethernet Payload


-------------------------
-------
New FCS
-------------------------
-------
7
Added IVLAN and OVLAN

• The Outer VLAN Tag MAY or MAY NOT be present. If
  present, it is used to enable two RBridges to
  become adjacent through an Ethernet cloud that
  support VLANs.
• The Inner VLAN Tag contains the VLAN information
  associated with the original frame.
• Clarified that in the rest of the document the
  term VLAN means inner VLAN.

8
MAY, SHOULD, MUST (1)

• Changed some text to utilize RFC2119 terms
• an RBridge MAY suppress the inner VLAN tag for
  frames with VID 1.
• some RBridges MAY be configured to not be the
  root of distribution tree
• If Ri is a tree root, then any RBridge Rn that
  needs to send multi-destination traffic MAY
  select the Ri-tree
• An Ingress RBridge MUST flood an ARP/ND query if
  the target is unknown, but MAY do so for a known
  target if it wants to assure freshness of the
  information
• RBridges MUST calculate at least one distribution
  tree, and by default compute one distribution
  tree for every Rbridge.

9
MAY, SHOULD, MUST (2)

• RBridges
• SHOULD store a successfully acquired nickname in
  non-volatile memory and attempt to reuse it on
  reboot
• SHOULD implement an "optimized ARP/ND response"
• MUST learn the location of endnodes.
• MUST calculate a distribution tree for every
  RBridge with RequestTree TRUE or for the RBridge
  with lowest ID if none have RequestTree TRUE
• MUST comply with the decision of Rn to be the
  root of a distribution tree
• Pseudonodes (shared links) MUST set RequestTree
  FALSE

10
Miscellaneous

• Added some pseudo-code for forwarding behavior
• Removed duplications in the text
• Fixed other minor issues

11
Added Algorhyme V2

• 1.1. Algorhyme V2 I hope that we shall one
  day see A graph more lovely than a tree.
  A graph to boost efficiency While still
  configuration-free. A network where
  RBridges can Route packets to their target
  LAN. The paths they find, to our
  elation, Are least cost paths to destination!
  With packet hop counts we now see,
  The network need not be loop-free!
  RBridges work transparently. Without a common
  spanning tree.
  Ray Perlner