TRILL Tutorial - Ethernet Technology Summit
TRILL Tutorial - Ethernet Technology Summit
TRILL Tutorial - Ethernet Technology Summit
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>TRILL</strong> <strong>Tutorial</strong><br />
Donald E. Eastlake, 3 rd<br />
Huawei R&D USA<br />
<br />
San Jose, CA USA February<br />
2012 1
The Speaker<br />
Donald E. Eastlake, 3 rd<br />
u Principal Engineer, Huawei R&D USA<br />
Co-Chair, IETF <strong>TRILL</strong> Working Group<br />
Voting member of IEEE 802.1 Working Group<br />
Chair, IETF PPPEXT Working Group<br />
Author of over 50 IETF RFCs<br />
Note:<br />
§<br />
This tutorial is a high level overview. It is not possible to include<br />
all the details in a presentation of this length.<br />
San Jose, CA USA February<br />
2012 2
CONTENTS<br />
§ Introduction<br />
• What is <strong>TRILL</strong>?<br />
• Least Cost Paths<br />
• Unicast Multi-Pathing<br />
• <strong>TRILL</strong> History<br />
• <strong>TRILL</strong> Features<br />
§ <strong>TRILL</strong> Examples<br />
§ <strong>TRILL</strong> Availability<br />
§ Technical Details<br />
§ <strong>TRILL</strong> Protocol Layer<br />
§ Example Processing<br />
§ Multi-Destination Traffic<br />
§ <strong>TRILL</strong> Support of DCB<br />
§ <strong>TRILL</strong> Comparisons<br />
§ References<br />
San Jose, CA USA February<br />
2012 3
What is <strong>TRILL</strong>?<br />
§ TRansparent Interconnection of Lots of Links<br />
• <strong>TRILL</strong> WG Charter<br />
– http://www.ietf.org/dyn/wg/charter/trill-charter.html<br />
• A standard specified by the IETF <strong>TRILL</strong> WG co-chaired by<br />
– Donald E. Eastlake 3 rd , Huawei Technologies<br />
– Erik Nordmark, Cisco Systems<br />
§ <strong>TRILL</strong> Switch / RBridge (Routing Bridge)<br />
• Devices that implements <strong>TRILL</strong><br />
§ <strong>TRILL</strong>/RBridge Campus –<br />
• A network of RBridges, links, and any intervening<br />
bridges, bounded by end stations / layer 3 routers.<br />
San Jose, CA USA February<br />
2012 4
What is <strong>TRILL</strong>?<br />
§ A Compatible Protocol<br />
• Attached end nodes just think it is <strong>Ethernet</strong>.<br />
§ The more classic bridges you convert to<br />
<strong>TRILL</strong> Switches, the better your network’s<br />
stability and bandwidth utilization.<br />
San Jose, CA USA February<br />
2012 5
What is <strong>TRILL</strong>?<br />
§ Basically a simple idea:<br />
• Encapsulate native frames in a transport header<br />
providing a hop count<br />
• Route the encapsulated frames using IS-IS<br />
• Decapsulate native frames before delivery<br />
§ Provides<br />
• Least cost paths with zero/minimal configuration<br />
• Equal Cost Multi-Pathing of unicast<br />
• Multi-paths of multi-destination<br />
San Jose, CA USA February<br />
2012 6
Least Cost Paths<br />
B1 <br />
= end sta-on <br />
B3 <br />
B2 <br />
A three bridge network<br />
San Jose, CA USA February<br />
2012 7
Least Cost Paths<br />
B1 <br />
= end sta-on <br />
B3 <br />
B2 <br />
Spanning tree eliminates loops<br />
by disabling ports<br />
San Jose, CA USA February<br />
2012 8
Least Cost Paths<br />
RB1 <br />
= end sta-on <br />
RB3 <br />
RB2 <br />
A three RBridge network: better performance<br />
using all facilities<br />
San Jose, CA USA February<br />
2012 9
Unicast Multi-Pathing<br />
B1 <br />
B3 <br />
B5 <br />
B2 <br />
B4 <br />
= end sta)on <br />
Bridges limit traffic to one path<br />
San Jose, CA USA February<br />
2012 10
Unicast Multi-Pathing<br />
RB1 <br />
RB3 <br />
RB5 <br />
RB2 <br />
RB4 <br />
RBridges support<br />
multi-path for higher throughput<br />
= end sta)on <br />
San Jose, CA USA February<br />
2012 11
<strong>TRILL</strong> History up to 2009<br />
l<br />
l<br />
l<br />
l<br />
l<br />
l<br />
l<br />
l<br />
l<br />
l<br />
l<br />
l<br />
1964: Packet switching/routing invented by Paul Baran.<br />
1973: <strong>Ethernet</strong> invented by Robert Metcalfe<br />
1979: Link State Routing invented by John McQuillan.<br />
1985: Radia Perlman invents the Spanning Tree Protocol.<br />
1987: DECnet Phase V / IS-IS designed by Radia Perlman.<br />
2002: Beth Israel Deaconess Hospital network in Boston melts<br />
down due to deficiencies in the Spanning Tree Protocol.<br />
2004: <strong>TRILL</strong> presented by inventor Radia Perlman at Infocom.<br />
2005: <strong>TRILL</strong> presented to IEEE 802 by Radia Perlman, rejected.<br />
2005: IETF Charters the <strong>TRILL</strong> Working Group.<br />
2008: MTU problem delays protocol while fix is incorporated.<br />
2009: RFC 5556 “<strong>TRILL</strong>: Problem and Applicability Statement”<br />
2009: <strong>TRILL</strong> Protocol passed up to IESG for Standards Approval.<br />
San Jose, CA USA February<br />
2012 12
<strong>TRILL</strong> in 2010/2011<br />
l 2010: <strong>TRILL</strong> approved as an IETF Standard (March 15, 2010)<br />
l<br />
l<br />
l<br />
l Ethertypes, Multicast addresses & NLPID assigned<br />
2010: Successful <strong>TRILL</strong> control plane interop at UNH IOL<br />
2011: <strong>TRILL</strong> Protocol base document set published:<br />
l<br />
l<br />
l<br />
l<br />
l<br />
RFC 6325: “RBridges: <strong>TRILL</strong> Base Protocol<br />
Specification” (Includes <strong>TRILL</strong> over <strong>Ethernet</strong>)<br />
RFC 6326: “<strong>TRILL</strong> Use of IS-IS”<br />
RFC 6327: “RBridges: Adjacency”<br />
RFC 6361: “<strong>TRILL</strong> over PPP”<br />
RFC 6439: “RBridges: Appointed Forwarders”<br />
2011: <strong>TRILL</strong> Working Group Re-Chartered to do further<br />
development of the <strong>TRILL</strong> protocol<br />
San Jose, CA USA February<br />
2012 13
<strong>TRILL</strong> Features<br />
Bridges<br />
<strong>TRILL</strong><br />
Switch<br />
Routers<br />
§ Transparency<br />
§ Plug & Play<br />
§ Virtual LANs<br />
• Multi-tenant support<br />
§ Frame Priorities<br />
§ Data Center Bridging<br />
§ Virtualization Support<br />
§ Multi-pathing<br />
§ Optimal Paths<br />
§ Rapid Fail Over<br />
§ The safety of a TTL<br />
• Implemented in data plane<br />
§ Extensions<br />
San Jose, CA USA February<br />
2012 14
Yet More <strong>TRILL</strong> Features<br />
§ Breaks up spanning tree for greater stability.<br />
§ Unicast forwarding tables at transit RBridges scale<br />
with the number of RBridges, not the number of end<br />
stations. Transit RBridges do not learn end station<br />
addresses.<br />
§ Compatible with existing IP Routers. <strong>TRILL</strong> switches<br />
are as transparent to IP routers as bridges are.<br />
§ Jumbo frame support including jumbo routing frames<br />
§ Has a poem (see next slide)<br />
• The only other bridging or routing protocol with a poem is<br />
Spanning Tree. (see Algorhyme on the web)<br />
San Jose, CA USA February<br />
2012 15
Algorhyme V2<br />
§<br />
§<br />
§<br />
§<br />
§<br />
§<br />
§<br />
§<br />
§<br />
§<br />
§<br />
§<br />
§<br />
I hope that we shall one day see<br />
A graph more lovely than a tree.<br />
A graph to boost efficiency<br />
While still configuration-free.<br />
A network where RBridges can<br />
Route packets to their target LAN.<br />
The paths they find, to our elation,<br />
Are least cost paths to destination!<br />
With packet hop counts we now see,<br />
The network need not be loop-free!<br />
RBridges work transparently,<br />
Without a common spanning tree.<br />
- By Ray Perlner<br />
San Jose, CA USA February<br />
2012 16
CONTENTS<br />
§ Introduction<br />
§ <strong>TRILL</strong> Examples<br />
• Acme Power Plant<br />
• Acme Data Center<br />
§ <strong>TRILL</strong> Availability<br />
§ Technical Details<br />
§ <strong>TRILL</strong> Protocol Layer<br />
§ Example Processing<br />
§ Multi-Destination Traffic<br />
§ <strong>TRILL</strong> Support of DCB<br />
§ <strong>TRILL</strong> Comparisons<br />
§ References<br />
San Jose, CA USA February<br />
2012 17
A<br />
A A A A A A A A A A A<br />
Acme Power Plant<br />
Rapid Spanning<br />
Tree Protocol<br />
Domain<br />
GB GB GB GB<br />
GB<br />
GB<br />
A A A A A<br />
CB<br />
A<br />
CB<br />
Bridged Process<br />
Control Network<br />
A = Access Bridge <br />
GB = aGgrega-on <br />
Bridge <br />
CB = Core Bridge <br />
San Jose, CA USA February<br />
2012 18
A<br />
A A A A A A A A A A A<br />
Acme Power Plant<br />
Rapid Spanning<br />
Tree Protocol<br />
Domain<br />
GB GB GB GB<br />
GB<br />
GB<br />
A A A A A<br />
CB<br />
A<br />
CB<br />
Spanning Tree<br />
Eliminates<br />
Loops by<br />
Disabling Ports<br />
A = Access Bridge <br />
GB = aGgrega-on <br />
Bridge <br />
CB = Core Bridge <br />
San Jose, CA USA February<br />
2012
A<br />
A A A A A A A A A A A<br />
Acme Power Plant<br />
RSTP<br />
Domain<br />
RSTP<br />
Domain<br />
GB GB GB GB<br />
GB<br />
CRB<br />
GB<br />
A A A A A A<br />
CRB<br />
RSTP<br />
Domain<br />
Process Control<br />
Network with RBridge<br />
Core breaking up<br />
spanning tree<br />
A = Access Bridge <br />
GB = aGgrega-on <br />
Bridge <br />
CRB = Core RBridge <br />
San Jose, CA USA February<br />
2012
A A A A A A<br />
A<br />
A A A A A<br />
Acme Power Plant<br />
GRB GRB GRB GRB<br />
GRB<br />
GRB<br />
A A A A A A<br />
Process Control<br />
Network with RBridge<br />
Mesh eliminating<br />
spanning tree<br />
A = Access Bridge <br />
GRB = aGgrega-on <br />
RBridge <br />
San Jose, CA USA February<br />
2012
Acme Data Center<br />
1:1 Backup<br />
Distribution Bridges<br />
must be able to handle<br />
100% of the load. Only 1<br />
path available between<br />
any pair of “B”s.<br />
Wan<br />
Router<br />
Dist.<br />
Bridge<br />
Wan<br />
Router<br />
Dist.<br />
Bridge<br />
Data Center<br />
Network with<br />
Bridges<br />
B = Head of Rack <br />
Bridge <br />
B B B B B B B B B B B B B B B<br />
San Jose, CA USA February<br />
2012
Acme Data Center<br />
N:1 Backup<br />
Distribution Bridges need to<br />
handle only 25% of the load.<br />
Multiple available paths<br />
between “H”s.<br />
H = Head of Rack <br />
RBridge <br />
Dist.<br />
RBridge<br />
Dist.<br />
RBridge<br />
Wan<br />
Router<br />
Dist.<br />
RBridge<br />
Wan<br />
Router<br />
Data Center<br />
Network with<br />
RBridges<br />
Dist.<br />
RBridge<br />
Dist.<br />
RBridge<br />
H H H H H H H H H H H H H H H<br />
San Jose, CA USA February<br />
2012
CONTENTS<br />
§ Introduction<br />
§ <strong>TRILL</strong> Examples<br />
§ <strong>TRILL</strong> Availability<br />
§ Technical Details<br />
§ <strong>TRILL</strong> Protocol Layer<br />
§ Example Processing<br />
§ Multi-Destination Traffic<br />
§ <strong>TRILL</strong> Support of DCB<br />
§ <strong>TRILL</strong> Comparisons<br />
§ References<br />
San Jose, CA USA February<br />
2012 24
<strong>TRILL</strong> Products<br />
§ “Pre-standard” products<br />
– Both to be convertible to standard <strong>TRILL</strong><br />
• Cisco FabricPath<br />
• Brocade VCS<br />
§ IBM / Blade Networks RackSwitch G8264<br />
support for the <strong>TRILL</strong> Standard.<br />
§ Many additional <strong>TRILL</strong> standard supporting<br />
products to be announced in 2012.<br />
San Jose, CA USA February<br />
2012 25
<strong>TRILL</strong> Silicon Availability<br />
• Here are six publicly known independent silicon<br />
implementations of the <strong>TRILL</strong> Fast Path. In some cases there<br />
are multiple different chips.<br />
• Broadcom – merchant silicon<br />
• Brocade – VCS product<br />
• Cisco – FabricPath product<br />
• Fulcrum – merchant silicon<br />
• Marvell – merchant silicon<br />
• Mellanox – merchant silicon<br />
San Jose, CA USA February<br />
2012 26
Open Source <strong>TRILL</strong><br />
• Oracle: <strong>TRILL</strong> for Solaris<br />
• http://hub.opensolaris.org/bin/view/Project+rbridges/WebHome<br />
• <strong>TRILL</strong> Port to Linux (in process):<br />
National University of Sciences and <strong>Technology</strong><br />
(NUST),<br />
§<br />
§<br />
Dr. Ali Khayam<br />
Islamabad, Pakistan<br />
• http://www.wisnet.seecs.nust.edu.pk/people/~khayam/index.php<br />
San Jose, CA USA February<br />
2012 27
CONTENTS<br />
§ Introduction<br />
§ <strong>TRILL</strong> Examples<br />
§ <strong>TRILL</strong> Availability<br />
§ Technical Details<br />
§ <strong>TRILL</strong> Protocol Layer<br />
§ Example Processing<br />
§ Multi-Destination Traffic<br />
§ <strong>TRILL</strong> Support of DCB<br />
§ <strong>TRILL</strong> Comparisons<br />
§ References<br />
San Jose, CA USA February<br />
2012 28
<strong>TRILL</strong> is Based on IS-IS<br />
§ <strong>TRILL</strong> switches (RBridges) use IS-IS link state<br />
routing<br />
• Neighbor RBridges find each other by exchanging Hellos<br />
• This information is flooded so all RBridges in the campus<br />
know about all adjacencies. Then all RBridges can<br />
– calculate the topology for least cost unicast forwarding,<br />
including Equal Cost Multi-Pathing<br />
– Calculate the same distribution trees for multi-destination<br />
frames<br />
• Other flooded information supports nicknames (see later<br />
slide), optimization of multicast distribution based on VLAN<br />
attachment and multicast listeners, etc.<br />
San Jose, CA USA February<br />
2012 29
<strong>TRILL</strong> is Based on IS-IS<br />
§ The IS-IS (Intermediate System to Intermediate<br />
System) link state routing protocol was chosen for<br />
<strong>TRILL</strong> over IETF OSPF (Open Shortest Path First),<br />
the only plausible alternative, for the following<br />
reasons:<br />
• IS-IS runs directly at Layer 2. Thus no IP addresses are<br />
needed, as they are for OSPF, and IS-IS can run with zero<br />
configuration.<br />
• IS-IS uses a TLV (type, length, value) encoding which<br />
makes it easy to define and carry new types of data.<br />
San Jose, CA USA February<br />
2012 30
<strong>TRILL</strong> Nicknames<br />
§ <strong>TRILL</strong> Switches are identified by IS-IS System ID but<br />
also by 2-bytes nicknames.<br />
§ Nicknames can be configured but by default are autoallocated.<br />
In case of collisions, the lower priority<br />
RBridge must select a new nickname.<br />
§ Nicknames:<br />
• Saves space in headers.<br />
• An RBridge can hold more than one nickname so that<br />
– It can be the root of more than one different distribution tree.<br />
– May be used to distinguish frames following traffic engineered<br />
routes versus least cost routes.<br />
San Jose, CA USA February<br />
2012 31
MAC Address Learning<br />
§ By IS-IS all <strong>TRILL</strong> Switches in the campus learn<br />
about and can reach each other but what about<br />
reaching end station MAC addresses?<br />
• By default, <strong>TRILL</strong> Switches at the edge (directly connected<br />
to end stations) learn attached VLAN/MAC addresses from<br />
data.<br />
• Optionally, MAC addresses can be passed through the<br />
control plane.<br />
• MAC addresses can be statically configured.<br />
• Transit <strong>TRILL</strong> Switches do not learn end station addresses.<br />
San Jose, CA USA February<br />
2012 32
RBridges on an Access Link<br />
§ You can have multiple RBridges on a link with one or<br />
more end stations.<br />
§ One is elected to be in charge of the link and to<br />
handle end station traffic. But to load split, it can each<br />
VLAN to another RBridge on the link.<br />
RB1 RB2 RB3 <br />
B1 B2 B3 <br />
San Jose, CA USA February<br />
2012 33
<strong>TRILL</strong> Encapsulation<br />
§ When an edge <strong>TRILL</strong> Switch receives an end station<br />
(native) frame, it encapsulates it with a <strong>TRILL</strong> Header<br />
and then adds a link header and forwards it.<br />
• On <strong>Ethernet</strong>, the local link header is addressed<br />
from the local source RBridge to the next hop<br />
RBridge for unicast frames or to the All-RBridges<br />
multicast address for multi-destination frames.<br />
• The <strong>TRILL</strong> Header specifies the ingress RBridge<br />
and either the egress RBridge for unicast frames<br />
or the distribution tree for multi-destination frames.<br />
San Jose, CA USA February<br />
2012 34
<strong>TRILL</strong> Encapsulation<br />
§ Summary of reasons for encapsulation:<br />
• Provides a hop count to mitigate loop issues<br />
• To hide the original source address to avoid confusing any<br />
bridges present as might happen if multi-pathing were in use<br />
• To direct unicast frames toward the egress RBridge so that<br />
forwarding tables in transit RBridges need only be sized with<br />
the number of RBridges in the campus, not the number of<br />
end stations<br />
• To provide a separate outer VLAN tag, when necessary, for<br />
forwarding traffic between RBridges, independent of the<br />
original VLAN of the frame<br />
San Jose, CA USA February<br />
2012 35
<strong>TRILL</strong> Details<br />
§ <strong>TRILL</strong> Header<br />
<strong>TRILL</strong> Ethertype<br />
V<br />
R<br />
M<br />
ExtLng<br />
Hop<br />
Egress RBridge Nickname<br />
Ingress RBridge Nickname<br />
• Nicknames – auto-configured 16-bit campus local names for<br />
<strong>TRILL</strong> Switches (RBridges)<br />
• V = Version (2 bits)<br />
• R = Reserved (2 bits)<br />
• M = Multi-Destination (1 bit)<br />
• ExtLng = Length of <strong>TRILL</strong> Header Extensions<br />
• Hop = Hop Limit (6 bits)<br />
San Jose, CA USA February<br />
2012 36
<strong>TRILL</strong> Over <strong>Ethernet</strong><br />
Data:<br />
DA<br />
SA<br />
VLAN *<br />
<strong>TRILL</strong><br />
Ethertype<br />
0x22F3<br />
<strong>TRILL</strong><br />
Header<br />
Payload Frame<br />
(DA, SA, VLAN/Tenant, Data)<br />
FCS<br />
<strong>Ethernet</strong> Link<br />
Transport Header<br />
Original Frame with<br />
VLAN/Tenant Label<br />
IS-IS:<br />
DA<br />
SA VLAN * L2-IS-IS<br />
Ethertype<br />
0x22F4<br />
IS-IS PDU<br />
FCS<br />
RBridge<br />
One<br />
<strong>Ethernet</strong><br />
Cloud<br />
RBridge<br />
Two<br />
* Link Transport VLAN only needed for VLAN sensitive link.<br />
RBridge<br />
Three<br />
San Jose, CA USA February<br />
2012 37
<strong>TRILL</strong> Over PPP<br />
Data:<br />
PPP <strong>TRILL</strong><br />
Data Protocol<br />
0x005D<br />
<strong>TRILL</strong><br />
Header<br />
Payload Frame<br />
(DA, SA, VLAN/Tenant, Data)<br />
PPP<br />
FCS<br />
PPP Link<br />
Transport Header<br />
Original Frame with<br />
VLAN/Tenant Label<br />
IS-IS:<br />
PPP <strong>TRILL</strong><br />
IS-IS Protocol<br />
0x405D<br />
IS-IS PDU<br />
PPP<br />
FCS<br />
RBridge<br />
One<br />
PPP<br />
RBridge<br />
Two<br />
San Jose, CA USA February<br />
2012 38
CONTENTS<br />
§ Introduction<br />
§ <strong>TRILL</strong> Examples<br />
§ <strong>TRILL</strong> Availability<br />
§ Technical Details<br />
§ <strong>TRILL</strong> Protocol Layer<br />
§ Example Processing<br />
§ Multi-Destination Traffic<br />
§ <strong>TRILL</strong> Support of DCB<br />
§ <strong>TRILL</strong> Comparisons<br />
§ References<br />
San Jose, CA USA February<br />
2012 39
<strong>TRILL</strong> Protocol Layer<br />
§ <strong>TRILL</strong> operates at Layer 2 ½<br />
§ Layer 3<br />
§ <strong>TRILL</strong><br />
Routers<br />
(plus servers and other end stations)<br />
<strong>TRILL</strong> Switches<br />
§ Layer 2<br />
Bridges<br />
Hubs/Repeaters<br />
San Jose, CA USA February<br />
2012 40
<strong>TRILL</strong> Protocol Layer<br />
§ Direct Connection at the same protocol layer<br />
Device<br />
Peers<br />
Connection<br />
Device<br />
San Jose, CA USA February<br />
2012 41
<strong>TRILL</strong> Protocol Layer<br />
§ Former Situation<br />
Router /<br />
End<br />
Station<br />
Peers<br />
Router /<br />
End<br />
Station<br />
Bridge<br />
Bridge<br />
Non-Peers<br />
San Jose, CA USA February<br />
2012 42
<strong>TRILL</strong> Protocol Layer<br />
§ Former Situation<br />
• or maybe<br />
Router /<br />
End<br />
Station<br />
Peers<br />
Router /<br />
End<br />
Station<br />
Customer<br />
Bridge<br />
Customer<br />
Bridge<br />
Peers<br />
Customer<br />
Bridge<br />
Non-Peers<br />
Provider<br />
Bridge(s)<br />
Provider<br />
Bridge(s)<br />
San Jose, CA USA February<br />
2012 43
<strong>TRILL</strong> Protocol Layer<br />
§ With <strong>TRILL</strong> Switches<br />
Router /<br />
End<br />
Station<br />
Peers<br />
Router /<br />
End<br />
Station<br />
<strong>TRILL</strong><br />
Switch<br />
Peers<br />
<strong>TRILL</strong><br />
Switch<br />
Peers<br />
<strong>TRILL</strong><br />
Switch<br />
Non-Peers<br />
Bridge(s)<br />
Bridge(s)<br />
San Jose, CA USA February<br />
2012 44
CONTENTS<br />
§ Introduction<br />
§ <strong>TRILL</strong> Examples<br />
§ <strong>TRILL</strong> Availability<br />
§ Technical Details<br />
§ <strong>TRILL</strong> Protocol Layer<br />
§ Example Processing<br />
§ Multi-Destination Traffic<br />
§ <strong>TRILL</strong> Support of DCB<br />
§ <strong>TRILL</strong> Comparisons<br />
§ References<br />
San Jose, CA USA February<br />
2012 45
Input Port Processing<br />
§ Detailed example of unicast frame <strong>TRILL</strong><br />
routing on an <strong>Ethernet</strong> link<br />
Input Na)ve Frame on link: <br />
Dest MAC<br />
Src MAC<br />
Data<br />
FCS<br />
VLAN<br />
• Input port adds VLAN-ID and priority if frame untagged<br />
Input Na)ve Frame a7er input port: <br />
Dest MAC<br />
Src MAC<br />
VLAN<br />
Data<br />
FCS<br />
San Jose, CA USA February<br />
2012 46
<strong>TRILL</strong> Unicast Ingress<br />
Input Na)ve Frame: <br />
Dest MAC<br />
Src MAC<br />
VLAN<br />
Data<br />
FCS<br />
Look Up Egress, Next<br />
Hop DA & Output Port<br />
Output <strong>TRILL</strong> Data Frame: <br />
DA<br />
SA VLAN 1<br />
TTL=n<br />
Egress<br />
<strong>TRILL</strong> Header<br />
Ingress<br />
Payload Frame<br />
New<br />
FCS<br />
Link Transport <br />
Header <br />
Ingressing <br />
RBridge <br />
Original Frame with <br />
VLAN or Tenant ID <br />
1<br />
Outer VLAN tag is a transport artifact and only needed if RBridges are connected by a<br />
bridged LAN or carrier <strong>Ethernet</strong> requiring a VLAN tag or the like.<br />
San Jose, CA USA February<br />
2012 47
<strong>TRILL</strong> Unicast Transit<br />
DA<br />
Incoming Link <br />
Transport Header <br />
SA<br />
VLAN 1<br />
<strong>TRILL</strong> Hdr<br />
Egress<br />
TTL=n<br />
Ingress<br />
Input <strong>TRILL</strong> Data Frame: <br />
Payload Frame<br />
FCS<br />
Transit RBridge <br />
Look Up Next<br />
DA & Output Port<br />
DA<br />
SA VLAN 1<br />
Outgoing Link <br />
Transport Header <br />
<strong>TRILL</strong> Hdr<br />
Egress<br />
TTL=n-1<br />
Ingress<br />
Payload Frame<br />
New<br />
FCS<br />
Output <strong>TRILL</strong> Data Frame: <br />
1<br />
Input and output Outer VLANs can differ. The true VLAN or<br />
Tenant ID of the data is inside the payload frame. Outer<br />
VLAN is only needed if link is VLAN sensitive.<br />
San Jose, CA USA February<br />
2012 48
<strong>TRILL</strong> Unicast Egress<br />
Link Transport <br />
Header <br />
DA<br />
SA<br />
VLAN 1<br />
<strong>TRILL</strong> Hdr<br />
Egress<br />
Egressing <br />
RBridge <br />
Ingress<br />
Input <strong>TRILL</strong> Data Frame: <br />
Payload Frame<br />
FCS<br />
Output Na)ve Frame: <br />
Dest MAC<br />
Src MAC VLAN 2<br />
Data<br />
New FCS<br />
Look Up Output Port <br />
1<br />
Outer VLAN only needed if RBridges are connected by a bridged<br />
LAN or carrier <strong>Ethernet</strong> requiring a VLAN tag or the like<br />
2<br />
Final native frame VLAN tag may be omitted depending on<br />
RBridge output port configuration.<br />
San Jose, CA USA February<br />
2012 49
Output Port Processing<br />
Output Na)ve Frame before output port: <br />
Dest MAC<br />
Src MAC<br />
VLAN<br />
Data<br />
New FCS<br />
§ Output port may be configured to output<br />
untagged and will do so by default for the port<br />
VLAN ID<br />
Dest MAC<br />
Src MAC<br />
Data<br />
New FCS<br />
San Jose, CA USA February<br />
2012 50
CONTENTS<br />
§ Introduction<br />
§ <strong>TRILL</strong> Examples<br />
§ <strong>TRILL</strong> Availability<br />
§ Technical Details<br />
§ <strong>TRILL</strong> Protocol Layer<br />
§ Example Processing<br />
§ Multi-Destination Traffic<br />
§ <strong>TRILL</strong> Support of DCB<br />
§ <strong>TRILL</strong> Comparisons<br />
§ References<br />
San Jose, CA USA February<br />
2012 51
Multi-Destination Traffic<br />
§ Multi-destination frames are send on a bidirectional<br />
distribution tree.<br />
• The root of a tree is a <strong>TRILL</strong> Switch or a link<br />
(pseudo-node) determined by a separate priority<br />
and represented by nickname.<br />
• The ingress RBridge picks the tree, puts the tree<br />
root nickname in the “egress nickname” slot, and<br />
sets the M bit in the <strong>TRILL</strong> Header.<br />
§ All the RBridges in a campus calculate the<br />
same trees.<br />
San Jose, CA USA February<br />
2012 52
Multi-Destination Traffic<br />
§ Multi-destination frames are more dangerous<br />
than unicast because they can multiply at fork<br />
points in the distribution tree.<br />
• So, in addition to the Hop Count, a Reverse Path<br />
Forwarding Check is performed. This discards the<br />
frame if, for the ingress and tree, it seems to be<br />
arriving on the wrong port.<br />
• To reduce the RPFC state, ingress routers can<br />
announce which tree or trees they will use.<br />
San Jose, CA USA February<br />
2012 53
Multi-Destination Traffic<br />
§ As a frame is propagated on a distribution<br />
tree, its distribution can be pruned by VLAN<br />
and by multicast group since it is not useful to<br />
send a frame down a tree branch if<br />
• There are no end stations downstream in the<br />
VLAN of the frame, or<br />
• The frame is multicast and there is no multicast<br />
listener or multicast router downstream.<br />
San Jose, CA USA February<br />
2012 54
Multi-Destination Traffic<br />
§ A single RBridge can even be the root of multiple<br />
least cost trees which may be useful if it is the source<br />
or sink of lots of multi-destination traffic.<br />
RB5 RB6 RB7 <br />
RB1 <br />
RB2 <br />
RB3 <br />
RB4 <br />
= end sta)on <br />
San Jose, CA USA February<br />
2012 55
CONTENTS<br />
§ Introduction<br />
§ <strong>TRILL</strong> Examples<br />
§ <strong>TRILL</strong> Availability<br />
§ Technical Details<br />
§ <strong>TRILL</strong> Protocol Layer<br />
§ Example Processing<br />
§ Multi-Destination Traffic<br />
§ <strong>TRILL</strong> Support of DCB<br />
§ <strong>TRILL</strong> Comparisons<br />
§ References<br />
San Jose, CA USA February<br />
2012 56
<strong>TRILL</strong> Support of DCB<br />
§ The goal is “loss-less” <strong>Ethernet</strong>. That is, no<br />
loss due to queue overflow<br />
§ Basic <strong>Ethernet</strong> PAUSE “works”, but is a very<br />
blunt instrument<br />
• Interference with loss dependent flow control such<br />
as TCP<br />
• Blocking of high priority control frames<br />
• Congestion spreading<br />
San Jose, CA USA February<br />
2012 57
<strong>TRILL</strong> Support of DCB<br />
§ Answer 1:<br />
• Consider different frame priorities as different pipes<br />
– 802.1Qbb: Separate PAUSE per priority<br />
– 802.1Qaz: Allocate bandwidth between priorities<br />
§ Answer 2:<br />
• Provide back pressure on the origin of congesting flows<br />
– 802.1Qau: Congestion Notification (CN)<br />
§ Combining them may work best<br />
San Jose, CA USA February<br />
2012 58
<strong>TRILL</strong> Support of DCB<br />
§ Answer 1: Consider different frame priorities as<br />
different pipes<br />
• 802.1Qbb: Separate PAUSE per priority<br />
– Don’t enable for priorities where urgent control frames are sent<br />
or where loss dependent flow control is in use<br />
– Enable for priorities where loss-less flow is more important.<br />
• 802.1Qaz: Ability to allocate bandwidth between these pipes<br />
– Highest priority frames not restricted<br />
– Remainder of bandwidth can be carved up and frames can be<br />
selected in preference to “higher priority” frames if they have not<br />
used the allocation for their pipe.<br />
• The above are implemented in port queuing.<br />
San Jose, CA USA February<br />
2012 59
<strong>TRILL</strong> Support of DCB<br />
§ For PFC and ETS, all stations are peers:<br />
Router /<br />
End<br />
Station<br />
Peers<br />
Router /<br />
End<br />
Station<br />
Peers<br />
RBridge<br />
Peers<br />
RBridge<br />
Bridge<br />
Bridge<br />
San Jose, CA USA February<br />
2012 60
<strong>TRILL</strong> Support of DCB<br />
§ Answer 2: Congestion Notification (CN): Provide back<br />
pressure on the origin of congesting flows<br />
• When queue depth exceeds a bound, send a Congestion<br />
Notification Message CNM back to source MAC address in<br />
the congesting frame’s VLAN<br />
• Enabled per priority. (CNM itself usually priority 6.)<br />
• Frames can be labeled with a CN tag for more fine grained<br />
flows<br />
• Mostly implemented in port logic<br />
§ In <strong>TRILL</strong> a CN tag, if present, goes inside the<br />
encapsulated frame and a CNM is just a native<br />
frame, except for one corner case.<br />
San Jose, CA USA February<br />
2012 61
<strong>TRILL</strong> Support of DCB<br />
Link<br />
Header<br />
<strong>TRILL</strong><br />
Header<br />
Orig.<br />
DA<br />
Orig.<br />
SA<br />
Orig.<br />
VLAN<br />
CN<br />
Tag<br />
Original<br />
Payload<br />
FCS<br />
Encapsulated Frame<br />
§ However, RBridges may have to handle<br />
CNMs generated by <strong>TRILL</strong> ignorant bridges<br />
between RBridges. Such a CNM will be<br />
initially addressed to the previous hop<br />
RBridge, not the original end station.<br />
San Jose, CA USA February<br />
2012 62
<strong>TRILL</strong> Support of DCB<br />
Origin<br />
RBridge<br />
Bridge(s)<br />
RBridge<br />
Adjusted CNM<br />
CNM<br />
§ Previous hop RBridge has to adjust the CNM<br />
so that it goes back to the origin end station.<br />
§ Note: All of the Data Center Bridging facilities depend<br />
on appropriate engineering, limited delay bandwidth<br />
product, etc., to actually provide “loss-less” service.<br />
San Jose, CA USA February<br />
2012 63
CONTENTS<br />
§ Introduction<br />
§ <strong>TRILL</strong> Examples<br />
§ <strong>TRILL</strong> Availability<br />
§ Technical Details<br />
§ <strong>TRILL</strong> Protocol Layer<br />
§ Example Processing<br />
§ Multi-Destination Traffic<br />
§ <strong>TRILL</strong> Support of DCB<br />
§ <strong>TRILL</strong> Comparisons<br />
§ References<br />
San Jose, CA USA February<br />
2012 64
<strong>TRILL</strong> Comparisons<br />
§ <strong>TRILL</strong> versus MPLS<br />
• MPLS is an older, more mature technology with<br />
better Quality of Service features, etc.<br />
• MPLS is more configuration intensive. <strong>TRILL</strong> can<br />
be auto-configuring.<br />
• <strong>TRILL</strong> provides easier support of multicast<br />
• <strong>TRILL</strong> can usually scale better because<br />
– MPLS requires a label entry at each LSR (Label Switched<br />
Router) for each MPLS path through that LSR<br />
– <strong>TRILL</strong> requires a nickname entry at each RBridge for<br />
each <strong>TRILL</strong> switch in the campus<br />
San Jose, CA USA February<br />
2012 65
<strong>TRILL</strong> Comparisons<br />
§ <strong>TRILL</strong> versus IP<br />
• IP is an older, more mature technology<br />
• IP chips are cheaper than <strong>TRILL</strong> chips because of<br />
greater volume but <strong>TRILL</strong> forwarding is simpler so,<br />
with equal volume, <strong>TRILL</strong> would be cheaper<br />
• <strong>TRILL</strong> supports VM mobility. Changing subnets<br />
changes IP Address, breaking TCP connections<br />
• <strong>TRILL</strong> is better at multicast because<br />
– IP requires a complex protocol like PIM to do multicast<br />
– <strong>TRILL</strong> has simple multicast distribution, with pruning for<br />
optimization, designed in from the start<br />
San Jose, CA USA February<br />
2012 66
<strong>TRILL</strong> Comparisons<br />
§ IETF <strong>TRILL</strong> versus IEEE 802.1aq<br />
• 802.1aq (Shortest Path Bridging) is better integrated with the<br />
previous bridging standards, for example it uses 802.1 OAM<br />
• <strong>TRILL</strong> breaks up Spanning Tree into smaller regions as<br />
much as it can. 802.1aq, although it provides shortest paths<br />
like <strong>TRILL</strong>, still propagates Spanning Tree Protocol,<br />
connecting Spanning Trees into bigger trees.<br />
• <strong>TRILL</strong> supports both point-to-point and multi-access links<br />
and efficient encoding on non-<strong>Ethernet</strong> links. 802.1aq is<br />
designed only for point-to-point <strong>Ethernet</strong> links.<br />
• Unicast routing computation for N switches is O(N*(log N))<br />
for <strong>TRILL</strong> and O(N 2 *(log N)) for 802.1aq<br />
San Jose, CA USA February<br />
2012 67
<strong>TRILL</strong> Comparisons<br />
§ Overall:<br />
• All of the protocols are being extended or<br />
related projects being started, so all are<br />
being improved.<br />
• Different technologies have different<br />
strengths – you should use the best one for<br />
your situation.<br />
San Jose, CA USA February<br />
2012 68
CONTENTS<br />
§ Introduction<br />
§ <strong>TRILL</strong> Examples<br />
§ <strong>TRILL</strong> Availability<br />
§ Technical Details<br />
§ <strong>TRILL</strong> Protocol Layer<br />
§ Example Processing<br />
§ Multi-Destination Traffic<br />
§ <strong>TRILL</strong> Support of DCB<br />
§ <strong>TRILL</strong> Comparisons<br />
§ References<br />
San Jose, CA USA February<br />
2012 69
<strong>TRILL</strong> IETF RFCs<br />
§ The core <strong>TRILL</strong> protocol RFCs<br />
• RFC 6325, “RBridges: <strong>TRILL</strong> Base Protocol<br />
Specification”<br />
• RFC 6326, “<strong>TRILL</strong> Use of IS-IS”<br />
• RFC 6327, “RBridges: Adjacency”<br />
• RFC 6361, “<strong>TRILL</strong> over PPP”<br />
• RFC 6439, “RBridges: Appointed Forwarders”<br />
§ Related RFC<br />
• RFC 5556, “<strong>TRILL</strong> Problem and Applicability”<br />
San Jose, CA USA February<br />
2012 70
Other References<br />
§ Introductory Internet Protocol Journal Article<br />
• http://www.cisco.com/web/about/ac123/ac147/<br />
archived_issues/ipj_14-3/143_trill.html<br />
§ MIB<br />
• https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-mib/<br />
§ BFD Support<br />
• https://datatracker.ietf.org/doc/draft-ietf-trill-rbridge-bfd/<br />
§ Multi-Tenant Support<br />
• https://datatracker.ietf.org/doc/draft-ietf-trill-fine-labeling<br />
San Jose, CA USA February<br />
2012 71
END<br />
Donald E. Eastlake, 3 rd<br />
Huawei R&D USA<br />
<br />
San Jose, CA USA February<br />
2012 72