Presentation aq-ashwood-ECT-framework-1109-v1.ppt

Nov 2009 IEEE 802.1aq Atlanta

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 BraggECT 3..16 from: Mick Seaman (per –d2-1)

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

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.

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.

•BridgeId = BridgePriority concatenated with SysIID•Winner can be tuned by adjusting BridgePriority

Min=11 3

2 4

6 5

Min=2

joinfork

4


HOW DOES IT WORK IN PRACTICE?

Low PathID

As applied to a 7member E-LAN

ISID 100 all members supportboth transmit/receive.

SPF tree shown fromeach member :

using Low PathIDalgorithm.

Symmetry highlightedBetween 35 and 40.

N

5

Animated GIF,run interactive to view.


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

6


#S

#D

0 | FF | 221 | FE | 23

0 | FF | 222 | FD | 20

0 | FF | 223 | FC | 21

#1 #2 #3

XOR-MASKsRESULT

N = min {BridgeID XOR MASK[i]}

#N = Bridge ID

Low PathID (alg=1) High Path ID

(alg = 2)

Alg=

9

EXAMPLE ECT diversity for Algorithms 1,2 and 9

KEY

#1 xor 0 = 1#1 xor FF = FE#1 xor 22 = 23

#2 xor 0 = 2#2 xor FF = FD#2 xor 22 = 20

#3 xor 0 = 3#3 xor FF = FC#3 xor 22 = 21

BridgeIDINPUT

7


HOW DOES IT WORK IN PRACTICE? 8 X ECT66 nodes Metro style

8 x ECT36 node DS-style/fat

HUGE improvement overLow/high PathID (x 2 ECT).

But routes get missed because:

If Diameter = D and avgadjacency = A there are:

O((A-1)D) paths.

What other approaches canwe take to maximize diversity?

Animated GIF,run interactiveto view.

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

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

• Vendors could sell proprietary ECT behaviors or publish informational.• Other standards bodies can add custom behaviors, Data Center etc.

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-ALGORITHMSo 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-DATALSP OPAQUE-LINK-ECT-TLV || ECT-ALGORITHM … ECT-DATA

Allows future expansion.

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 ifUSE-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 agreeon ECT-VID.

•This should permit a new ECT-ALGORITHM to be turned on, advertisedand then migrated to.

•It also permits movement away from an ECT-ALGORITHM and then thedeprecation of that ECT-ALGORITHM network wide once no longer in use.

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

13

Documents

Presentation aq-ashwood-ECT-framework-1109-v1.ppt