IEEE 802.1aq Shortest Path Bridging
Equal Cost Tree (ECT) Framework Proposal
Peter Ashwood-Smith
incorporating graphics by: Guoli Yin
incorporating MCID input from: Nigel Bragg
ECT 3..16 from: Mick Seaman (per –d2-1)
Nov 2009
IEEE 802.1aq
Atlanta
1
Presentation Structure
• There are strict requirements on ECT algorithms compatible
with SPB :
– we summarise these
• Nonetheless, a number of different algorithms have been
identified and successfully prototyped :
– we give a couple of examples
So what is the best way to preserve rigour and allow future
algorithm innovation ?
• Define an extensible Framework (compatible with previous
work).
• and populate it initially with currently known and validated
algorithms
Nov 2009
IEEE 802.1aq
Atlanta
2
Algorithm requirements review:
Shortest paths computed by SPB must be symmetric and downstream
congruent.
• Symmetry required for:
• Learning in the case of SPPV
• Ingress checking (SA lookup miss => discard) for SPPM
• Downstream congruence required for:
• Hop by hop destination-based (DA/VID) forwarding, every hop
agrees on same ‘rest of path’, so state scales O(N) vs. O(N2)
Equal cost shortest paths computed by SPB must be resolved by a
technique which is independent both of the direction of computation and the
location in the topology of the computing node.
Nov 2009
IEEE 802.1aq
Atlanta
3
Tie-Breaking – base algorithm
•When only one shortest path there is no issue.
•When two equal min sum of link metric paths exist must deterministically pick 1.
•Basic tie breaker is called LowPathID :
• a lexicographically ordered list of the BridgeIds forming the Path
•LowPathId will pick path with the minimum BridgeId between fork/join points.
•LowPathId is trivial to implement in Dijkstra, just backtrack when join occurs:
•Track min BridgeId on each path until they converge (fork point).
•LowPathId is the path with the min of the two mins between fork/join.
Min=1
1
3
•BridgeId = BridgePriority concatenated with SysIID
•Winner can be tuned by adjusting BridgePriority
6
fork
Nov 2009
IEEE 802.1aq
Atlanta
2
4
Min=2
5
join
4
HOW DOES IT WORK IN PRACTICE?
Animated GIF,
run interactive to view.
Low PathID
As applied to a 7
member E-LAN
ISID 100 all
members support
both transmit/receive.
SPF tree shown from
each member :
N
using Low PathID
algorithm.
Symmetry highlighted
Between 35 and 40.
Nov 2009
IEEE 802.1aq
Atlanta
5
Tie-Breaking – 15 additional algorithms allow ECT
•There are 15 additional algorithms defined, allows ECT diversity.
•Each starts by running a 1:1 permutation on the BridgeID’s with XOR against
known (network-global) masks.
•The LowPathID algorithm #1 is run after XOR with mask 0x0 (no change).
•For example, algorithm #2 will invert all the bytes in the BridgeID.
•We have been calling this ‘highPathId’ so uses all 1’s as its mask.
•Each of the other 14 algorithms uses a different bit mask to XOR the BridgeID
into a new unique permutation.
•We implement all 16 by XOR-ing with the mask and finding min of min.
•The masks are as follows (in hex), each nibble in 8 byte mask uses same value.
00 ff 88 77 44 33 cc bb 22 11 66 55 aa 99 dd ee
Nov 2009
IEEE 802.1aq
Atlanta
6
EXAMPLE ECT diversity for Algorithms 1,2 and 9
#S
#1
0 | FF | 22
1 | FE | 23
#2
#3
0 | FF | 22
2 | FD | 20
#D
0 | FF | 22
3 | FC | 21
BridgeID
INPUT
XOR-MASKs
RESULT
#1 xor 0 = 1
#1 xor FF = FE
#1 xor 22 = 23
KEY
#2 xor 0 = 2
#2 xor FF = FD
#2 xor 22 = 20
N = min {BridgeID XOR MASK[i]}
#N = Bridge ID
Nov 2009
IEEE 802.1aq
Atlanta
#3 xor 0 = 3
#3 xor FF = FC
#3 xor 22 = 21
7
HOW DOES IT WORK IN PRACTICE?
Animated GIF,
run interactive
to view.
8 X ECT
66 nodes Metro style
8 x ECT
36 node DS-style/fat
HUGE improvement over
Low/high PathID (x 2 ECT).
But routes get missed because:
If Diameter = D and avg
adjacency = A there are:
O((A-1)D) paths.
What other approaches can
we take to maximize diversity?
Nov 2009
IEEE 802.1aq
Atlanta
8
There seem to be numerous different classes of ECT
algorithm with different properties.
1. Minimum/Max of some nodal identifier over paths.
• 1:1 Permutations of that identifier to spread min around.
• Operator can explicitly set identifiers to tweak spreading.
2. Minimum/Max of some link identifier over paths.
• 1:1 Permutations of that link identifier to spread min around.
• Operator can override link id to tweak spreading.
3. Minimum/Max of a sum of a secondary metric.
• Hash produces the secondary metric.
• User can override the secondary metric to tweak spreading.
4. Algorithms which consider previous ECT algorithms path usage
to increase diversity. (Requires serial run instead of parallel).
Nov 2009
IEEE 802.1aq
Atlanta
9
Since there seems to be a rich area of research to look into new ECT
algorithms and with proper ECT diversity a form of traffic engineering emerges.
So we propose:
1. Fix the 16 ECT algorithms as defined in –d2-1 and advance the spec…but
2. Include a framework that allows new ECT algorithms to be implemented.
3. Framework to include hello/LSA policies & TLVs for safe migration.
4. Framework includes concept of Opaque ECT-DATA on a node or link basis for
future ECT algorithms.
5. Vendors/Researchers and future standards work can build into this
framework without changes to IETF ISIS work or even IEEE 802.1aq.
•
•
Nov 2009
Vendors could sell proprietary ECT behaviors or publish informational.
Other standards bodies can add custom behaviors, Data Center etc.
IEEE 802.1aq
Atlanta
10
The proposal – full text submitted to Don Fedyk
ECT-ALGORITHM ::= OUI:24 || INDEX:8
OUI = 00-80-C2, INDEX 0-16 defined by 802.1aq. 0=STP, 1=LowPathID etc.
ISID  ECT-ALGORITHM
So we expand from 8 bit Algorithm to 32 bits in SPB Instance sub TLV.
HELLO  { < ECT-ALGORITHM, ECT-VID, USE-FLAG > } *
Hello protocol carries algorithm identifier and VID used and indication of its
current usage state for clean migration.
LSP  { < ECT-ALGORITHM, ECT-VID, DATA-VID, USE-FLAG > }*
Announces support for given algorithm and the VID to use. SPBM ECT-VID
and DATA-VID are the same and are just the B-VID. Otherwise SPBV then
ECT-VID is Base-VID and DATA-VID is the SPVID.
LSP  OPAQUE-NODE-ECT-TLV || ECT-ALGORITHM … ECT-DATA
LSP  OPAQUE-LINK-ECT-TLV || ECT-ALGORITHM … ECT-DATA
Allows future expansion.
Nov 2009
IEEE 802.1aq
Atlanta
11
ECT MIGRATION
•USE-FLAGs should be advertised when ISIDs reference an ECT-ALGORITHM.
•Hellos should set USE-FLAG if they are locally referencing or remotely seeing
references to the ECT-ALGORITHM.
• Adjacency permitted if { <ECT-ALGORITHM>, <ECT-VID> } * match.
•If mismatch for a given ECT-ALGORITHM the adjacency is allowed only if
USE-FLAG not set on at least one end.
• this allows a new ECT-ALGORITHM to be introduced gradually whilst
the network continues running the current production algorithm
•Must not locally use an ECT-ALGORITHM unless all adjacencies agree
on ECT-VID.
•This should permit a new ECT-ALGORITHM to be turned on, advertised
and then migrated to.
•It also permits movement away from an ECT-ALGORITHM and then the
deprecation of that ECT-ALGORITHM network wide once no longer in use.
Nov 2009
IEEE 802.1aq
Atlanta
12
MCID – migration issues (SPB only)
1. It may not be possible to accurately populate the VID space a priori.
2. and since we do not want to take down an adjacency just because we
are adding a new un anticipated VID
3. We propose to allow an AUX-MCID to be advertised.
4. An adjacency is not rejected if the primary MCIDs don’t match as long
as there is a match of the AUX-MCID with the primary MCID.
• i.e. either the primary OR the auxiliary MCID of one bridge must
match the primary MCID of the other to keep the adjacency up.
5. This allows configuration of one end of a link followed by out of sync
configuration of the other end without loss of adjacency.
6. Responsibility for ensuring that primary and auxiliary MCIDs represent
compatible super/sub-sets of VIDs lies with the network administrator
• but in-service upgrade of this sort is not for the amateur anyway
Nov 2009
IEEE 802.1aq
Atlanta
13