IEEE 802.1aq

<h2 id="history">History</h2>
On 4 March 2006 the working group posted 802.1aq draft 0.1.<a class="footnote-ref" id="fnref:10" href="#fn:10">10</a> In March 2012 the IEEE approved the 802.1aq standard.<a class="footnote-ref" id="fnref:11" href="#fn:11">11</a>
In May 2013, the first public multivendor interoperability was demonstrated as SPB served as the backbone for Interop 2013 in Las Vegas.<a class="footnote-ref" id="fnref:12" href="#fn:12">12</a> In 2013 and 2014 SPB was used to build the InteropNet backbone with only one-tenth the resources of prior years.<a class="footnote-ref" id="fnref:13" href="#fn:13">13</a> During <a href="/facts/Interop/9cSmE8TA">Interop</a> 2014 SPB was used as the backbone protocol which can enable <a href="/facts/Software-defined_networking/MJGFxyoj">software-defined networking</a> (SDN) functionalities.<a class="footnote-ref" id="fnref:14" href="#fn:14">14</a><a class="footnote-ref" id="fnref:15" href="#fn:15">15</a>
The <a href="/facts/2014_Winter_Olympics/PeL2E3jE">2014 Winter Olympics</a> were the first "fabric-enabled" Games using SPB "IEEE 802.1aq" technology.<a class="footnote-ref" id="fnref:16" href="#fn:16">16</a><a class="footnote-ref" id="fnref:17" href="#fn:17">17</a> During the games this fabric network could handle up to 54 Tbit/s of traffic.<a class="footnote-ref" id="fnref:18" href="#fn:18">18</a>

<h2 id="associated-protocols">Associated protocols</h2>
<ul><li><a href="/facts/IEEE_802.1Q-2014/nxc5VxI2">IEEE 802.1Q-2014</a> - Bridges and Bridged Networks - This standard incorporates Shortest Path Bridging (IEEE 802.1aq) with the following: IEEE Std 802.1Q-2011, IEEE Std 802.1Qbe-2011, IEEE Std 802.1Qbc-2011, IEEE Std 802.1Qbb-2011, IEEE Std 802.1Qaz-2011, IEEE Std 802.1Qbf-2011, IEEE Std 802.1Qbg-2012, IEEE Std 802.1Q-2011/Cor 2–2012, and IEEE Std 802.1Qbp-2014, and much functionality previously specified in 802.1D.<a class="footnote-ref" id="fnref:19" href="#fn:19">19</a></li>
<li><a href="/facts/IEEE_802.1ag/Ro1C2ysD">IEEE 802.1ag</a> - Connectivity Fault Management (CFM)</li>
<li>IEEE 802.1Qbp - Equal Cost Multiple Paths in Shortest Path Bridging<a class="footnote-ref" id="fnref:20" href="#fn:20">20</a></li>
<li>IEEE P802.1Qcj - Automatic Attachment to Provider Backbone Bridging (PBB) services<a class="footnote-ref" id="fnref:21" href="#fn:21">21</a></li>
<li>RFC 6329 - IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging</li></ul>
<h3>RFC 6329</h3>
The <a href="/facts/Intermediate_System_to_Intermediate_System/zaNkSwhW">Intermediate System to Intermediate System</a> (IS-IS) protocol, as defined in the <a href="/facts/IETF/tIcCsFhX">IETF</a> proposed standard <a href="/facts/RFC_(identifier)/esftTvE7">RFC</a> <a href="https://www.rfc-editor.org/rfc/rfc6329">6329</a>, is used as the <a href="/facts/Control_plane/oq1oXmUz">control plane</a> for SPB.<a class="footnote-ref" id="fnref:22" href="#fn:22">22</a><a class="footnote-ref" id="fnref:23" href="#fn:23">23</a><a class="footnote-ref" id="fnref:24" href="#fn:24">24</a><a class="footnote-ref" id="fnref:25" href="#fn:25">25</a> SPB requires no state machine or other substantive changes to IS-IS, and simply requires a new Network Layer Protocol Identifier (NLPID) and set of <a href="/facts/Type%25E2%2580%2593length%25E2%2580%2593value/IMeVVbpK">TLVs</a>.<a class="footnote-ref" id="fnref:26" href="#fn:26">26</a>: Section 13 
SPB allows for shortest-path forwarding in a mesh-connected Ethernet network utilizing multiple equal-cost paths. This permits SPB to support large Layer 2 topologies, with faster convergence, and improved use of the mesh topology when compared to networks configured with Spanning Tree Protocol. SPB augments IS-IS with a small number of TLVs and sub-TLVs, and supports two Ethernet encapsulating data paths, <a href="/facts/IEEE_802.1ad/5BEhLjXz">IEEE 802.1ad</a> provider bridges (PB) and <a href="/facts/IEEE_802.1ah/wblMUsQl">IEEE 802.1ah</a> Provider Backbone Bridges (PBB).
SPB is designed to run in parallel with other network-layer protocols such as <a href="/facts/IPv4/bnQ5MEqm">IPv4</a> and <a href="/facts/IPv6/d4dg7kIL">IPv6</a>. Standards mandate that the failure of two nodes to establish an SPB adjacency will not have a collateral impact, such as the rejection of an adjacency for other network-layer protocols (e.g. <a href="/facts/OSPF/PACpGUHb">OSPF</a>).

<h4>Protocol extensions</h4>
The IS-IS extensions defined in RFC 6329 that deliver standardized support for 802.1aq SPB are:

<ul><li>IS-IS Hello (IIH) Protocol Extensions</li>
<li>Node Information Extensions</li>
<li>Adjacency Information Extensions</li>
<li>Service Information Extensions</li></ul>
<h5>IS-IS Hello (IIH) protocol extensions</h5>
802.1aq has been designed to operate in parallel with other network layer protocols such as IPv4 and IPv6; therefore, failure of two nodes to establish an SPB adjacency will not cause network layer protocols to also reject an adjacency. RFC 6328 assigns 802.1aq the Network Layer Protocol ID (NLPID) value 0xC1.<a class="footnote-ref" id="fnref:27" href="#fn:27">27</a> This NLPID is used by SPB Bridges to indicate their ability to form adjacencies and operate as part of an 802.1aq domain. 802.1aq frames flow on adjacencies that advertise this NLPID in both directions, and nodes regard an adjacency that has not been advertised in both directions as non-existent (with infinite link metric). 802.1aq augments the normal IIH PDU with three new TLVs, which like all other SPB TLVs, travel within Multi-Topology TLVs, therefore allowing multiple logical instances of SPB within a single IS-IS protocol instance.
SPB can use many VIDs, agreeing on which VIDs are used for which purposes. The IIH PDUs carry a digest of all the used VIDs, referred to as the Multiple Spanning Tree Configuration TLV which uses a common and compact encoding reused from IEEE 802.1Q.
For the purposes of loop prevention SPB neighbors may also support a mechanism to verify that the contents of their topology databases are synchronized. Exchanging digests of SPB topology information, using the optional SPB-Digest sub-TLV, allows nodes to compare information and take specific action where a mismatch in topology is indicated.
Finally, SPB needs to know which shortest path tree (SPT) sets are being used by which VIDs, and this is carried in the Base VLAN Identifiers TLV.

<h5>Node information extensions</h5>
All SPB nodal information extensions travel within a new Multi-Topology (MT) capability TLV. There can be one or many MT-Capability TLVs present, depending on the amount of information that needs to be carried.
The SPB Instance sub-TLV gives the Shortest Path Source ID (SPSourceID) for this node or topology instance. This is used in the formation of multicast destination addresses (DAs) for frames originating from this node or instance.
There are multiple ECT algorithms defined for SPB and additional algorithms may be defined in the future including but not limited to <a href="/facts/Equal-cost_multi-path_routing/yWnENc41">ECMP</a>- or hash-based behaviors and (*,G) <a href="/facts/IP_multicast/YklMRaV5">Multicast</a> trees. These algorithms will use this optional TLV to define new algorithm parametric data. For tie-breaking parameters, there are two broad classes of algorithms, one that uses nodal data to break ties and one that uses link data to break ties. The SPB Instance Opaque Equal cost Tree Algorithm TLV is used to associate opaque tie-breaking data with a node.

<h5>Adjacency information extensions</h5>
The SPB Link Metric sub-TLV occurs within the Multi-Topology Intermediate System Neighbor TLV or within the Extended IS Reachability TLV. SPB Adjacency Opaque Equal Cost Tree Algorithm TLV also occurs within the Multi-Topology Intermediate System TLV or the Extended IS Reachability TLV. Where this sub-TLV is not present for an IS-IS adjacency, that adjacency will not carry SPB traffic for the given topology instance.

<h5>Service information extensions</h5>
The SPBM Service Identifier and Unicast Address TLV is used to introduce service group membership on the originating node or to advertise an additional B-MAC unicast address present on, or reachable by the node. The SPBV MAC Address TLV is the IS-IS sub-TLV used for advertisement of group MAC addresses in SPBV mode.

<h2 id="benefits">Benefits</h2>

Shortest Path Bridging-VID (SPBV) and Shortest Path Bridging-MAC (SPBM) are two operating modes of 802.1aq. Both inherit key benefits of <a href="/facts/Link_state_routing/kFHQ5FkA">link state routing</a>:

<ul><li>the ability to use all available physical connectivity, because loop avoidance uses a control plane with a global view of network topology</li>
<li>fast restoration of connectivity after failure, again because of link state routing's global view of network topology</li>
<li>under failure, the property that only directly affected traffic is impacted during restoration</li>
<li>rapid restoration of broadcast and multicast connectivity, because IS-IS floods all of the required information in the SPB extensions to IS-IS, thereby allowing unicast and multicast connectivity to be installed in parallel, with no need for a second phase signaling process to run over the converged unicast topology to compute and install multicast trees.</li></ul>
SPBM offers emulation of a transparent Ethernet LAN segment. It implements VLANs with scoped multicast trees, which means no egress discard of <a href="/facts/Broadcast%2c_unknown-unicast_and_multicast_traffic/CGdXdQLS">broadcast, unknown-unicast and multicast traffic</a>, a feature common to approaches that use a small number of shared trees, hence the network does not simply degrade with size as the percentage of frames discarded goes up.
The carrier-space equivalent of this application is the delivery of <a href="/facts/Ethernet_VPN/sqNaV2SJ">Ethernet VPN</a> services to Enterprises over common carrier infrastructure. The required attributes are fundamentally the same; complete transparency for customer Ethernet services (both point-to-point and LAN), and complete isolation between one customer's traffic and that of all other customers.
A further consequence of SPBM's transparency in both <a href="/facts/Data_plane/EWNoEXdo">data plane</a> and control plane is that it delivers the <a href="/facts/MEF_Forum/rqE3hCFV">MEF 6.1</a> service set. It also provides the carrier with the toolkit to support geo-redundant broadband backhaul; in these applications, many DSLAMs or other access equipment must be backhauled to multiple <a href="/facts/Broadband_Remote_Access_Server/WxvAQWL4">Broadband Remote Access Server</a> (BRAS) sites, with application-determined binding of sessions to a BRAS. However, DSLAMs must not be allowed to communicate with each other, because carriers then lose the ability to control peer-to-peer connectivity. MEF <a href="/facts/E-TREE/d6pkk6Ha">E-TREE</a> does just this, and further provides an efficient multicast fabric for the distribution of <a href="/facts/IPTV/tHqsXX6h">IPTV</a>.
SPBM offers both an ideal multicast replication model, where packets are replicated only at fork points in the shortest path tree that connects members, and also the less state-intensive head-end replication model where in essence serial unicast packets are sent to all other members along the same shortest path first tree. These two models are selected by specifying properties of the service at the edge which affect the transit node decisions on multicast state installation. This allows for a trade-off to be made between optimum transit replication points (with their larger state costs) vs. reduced core state (but much more traffic) of the head-end replication model. These selections can be different for different members of the same Individual Service ID (I-SID) allowing different trade-offs to be made for different members.
Figure 5 below is a quick way to understand what SPBM is doing on the scale of the entire network. Figure 5 shows how a 7-member E-LAN is created from the edge membership information and the deterministic distributed calculation of per source, per service trees with transit replication. Head-end replication is not shown as it is trivial and simply uses the existing unicast FIBs to forward copies serially to the known other receivers.

<h2 id="operations-and-management">Operations and management</h2>
802.1aq builds on all existing Ethernet <a href="/facts/Operations%2c_administration_and_management/3nsCyyeB">operations, administration and management</a> (OA&M). Since 802.1aq ensures that its <a href="/facts/Unicast/PHStTfFe">unicast</a> and <a href="/facts/Multicast/D9IspSfl">multicast</a> packets for a given <a href="/facts/Virtual_LAN/QhdJNaWX">virtual LAN</a> (VLAN) follow the same forward and reverse path and use completely standard 802 encapsulations, all the methods of IEEE 802.1ag and Y.1731<a class="footnote-ref" id="fnref:28" href="#fn:28">28</a> operate unchanged on an 802.1aq network.

<h2 id="high-level">High level</h2>
See also: <a href="/facts/Data_center_bridging/dTRARS4R">Data center bridging § Other groups</a>
802.1aq is the IEEE-sanctioned link state Ethernet control plane for all IEEE VLANs covered in IEEE 802.1Q.<a class="footnote-ref" id="fnref:29" href="#fn:29">29</a> The Shortest Path Bridging virtual local area network identifier (VLAN ID) or Shortest Path Bridging VID (SPBV) provides a capability that is backward compatible with <a href="/facts/Spanning_tree/qQPN9taR">spanning tree</a> technologies. The SPBM provides additional values that use Provider Backbone Bridge (PBB) capabilities. SPB (the generic term for both) combines an Ethernet data path (either IEEE 802.1Q in the case of SPBV, or PBBs per IEEE 802.1ah in the case of SPBM) with an IS-IS link state control protocol running between Shortest Path bridges (<a href="/facts/Network-to-network_interface/wDf1D4KE">Network-to-network interface</a> (NNI) links). The link state protocol is used to discover and advertise the network topology and compute SPTs from all bridges in the SPT Region.
In SPBM, the backbone MAC (B-MAC) addresses of the participating nodes and also the service membership information for interfaces to non-participating devices (<a href="/facts/User%25E2%2580%2593network_interface/HgjWNrs7">User–network interface</a> (UNI) ports) is distributed. Topology data is then input to a calculation engine which computes symmetric shortest path trees based on minimum cost from each participating node to all other participating nodes. In SPBV these trees provide a shortest path tree where individual <a href="/facts/MAC_address/SVcTfgUH">MAC address</a> can be learned and <a href="/facts/Group_address/cIau2Hee">group address</a> membership can be distributed. In SPBM the shortest path trees are then used to populate forwarding tables for each participating node's individual B-MAC addresses and for group addresses; Group <a href="/facts/Multicast/D9IspSfl">multicast</a> trees are subtrees of the default shortest path tree formed by (source, group) pairing. Depending on the topology, several different equal-cost multi-path trees are possible and SPB supports multiple algorithms per IS-IS instance.
In SPB as with other link-state-based protocols, the computations are done in a distributed fashion. Each node computes the Ethernet-compliant forwarding behavior independently based on a normally synchronized common view of the network and UNI ports. Ethernet filtering Database (or forwarding) tables are populated locally to independently and deterministically implement its portion of the network forwarding behavior.
The two different flavors of data path give rise to two slightly different versions of this protocol. One (SPBM) is intended where complete isolation of many separate instances of client LANs and their associated device MAC addresses is desired, and it therefore uses a full encapsulation (MAC-in-MAC a.k.a. IEEE 802.1ah). The other (SPBV) is intended where such isolation of client device MAC addresses is not necessary, and it reuses only the existing VLAN tag on participating NNI links. Chronologically SPBV came first, with the project originally being conceived to address scalability and convergence of <a href="/facts/Multiple_Spanning_Tree_Protocol/nRztftbM">MSTP</a>.
At the time the specification for PBB was progressing it became apparent that leveraging both the PBB data plane and a link state control plane would significantly extend Ethernet's capabilities and applications. Provider Link State Bridging (PLSB) was a straw man proposal brought to the IEEE 802.1aq Shortest Path Bridging Working Group, to provide a concrete example of such a system. As IEEE 802.1aq standardization progressed, some of the detailed mechanisms proposed by PLSB were replaced by functional equivalents, but all of the key concepts embodied in PLSB were carried forward into the standard.

<h3>Shortest Path Bridging-VID</h3>

A primary feature of Shortest Path Bridging is the ability to use link state IS-IS to learn network topology. In SPBV the mechanism used to identify the tree is to use a different Shortest Path VLAN ID (SPVID) for each source bridge. The IS-IS topology is used both to allocate unique SPVIDs and to enable shortest path forwarding for individual and group addresses. Originally targeted for small, low-configuration networks, SPB grew into a larger project encompassing the latest provider control plane for SPBV and harmonizing the concepts of Ethernet's data plane.
SPB defines a shortest path region which is the boundary of the shortest path topology and the rest of the VLAN topology, which may be any number of legacy bridges. SPB operates by learning the SPB-capable bridges and growing the region to include the SPB-capable bridges that have the same Base VID and MSTID configuration digest (Allocation of VIDs for SPB purposes).
SPBV builds shortest-path trees that support loop prevention and optionally support loop mitigation on the SPVID. SPBV still allows learning of Ethernet MAC addresses but it can distribute multicast addresses that can be used to prune the shortest path trees according to the multicast membership either through Multiple MAC Registration Protocol (MMRP) or directly using IS-IS distribution of multicast membership.
SPBV builds shortest-path trees but also interworks with legacy bridges running <a href="/facts/Rapid_Spanning_Tree_Protocol/ofHHMBuM">Rapid Spanning Tree Protocol</a> and <a href="/facts/Multiple_Spanning_Tree_Protocol/nRztftbM">Multiple Spanning Tree Protocol</a> (MSTP). SPBV uses techniques from MSTP regions to interwork with non-SPT regions behaving logically as a large distributed bridge as viewed from outside the region.
SPBV supports shortest path trees but SPBV also builds a spanning tree which is computed from the link state database and uses the Base VID. This means that SPBV can use this traditional spanning tree for computation of the common and internal spanning tree (CIST). The CIST is the default tree used to interwork with other legacy bridges. It also serves as a fallback spanning tree if there are configuration problems with SPBV.
SPBV has been designed to manage a moderate number of bridges. SPBV differs from SPBM in that MAC addresses are learned on all bridges that lie on the shortest path and shared VLAN learning is used since destination MACs may be associated with multiple SPVIDs. SPBV learns all MACs it forwards even outside the SPBV region.

<h3>Shortest Path Bridging-MAC</h3>

Shortest Path Bridging-MAC (SPBM) reuses the PBB data plane which does not require that the Backbone Core Bridges (BCB) learn encapsulated client addresses. At the edge of the network the C-MAC (client) addresses are learned. SPBM is very similar to Provider Link State Bridging (PLSB) using the same data and control planes but the format and contents of the control messages in PLSB are not compatible.
Individual MAC frames of <a href="/facts/Unicast/PHStTfFe">unicast</a> traffic from an Ethernet-attached device that are received at the SPBM edge are encapsulated in a PBB IEEE 802.1ah header and then traverse the IEEE 802.1aq network unchanged until they are stripped of the encapsulation as they egress back to the non-participating attached network at the far side of the participating network.
<a href="/facts/Ethernet/nMfhU8tU">Ethernet</a> destination addresses (from UNI port attached devices) perform learning over the logical LAN and are forwarded to the appropriate participating B-MAC address to reach the far end Ethernet destination. In this manner, Ethernet MAC addresses are never looked up in the core of an IEEE 802.1aq network. When comparing SPBM to PBB, the behavior is almost identical to a PBB IEEE 802.1ah network. PBB does not specify how B-MAC addresses are learned and PBB may use a spanning tree to control the B-VLAN. In SPBM the main difference is that B-MAC address are distributed or computed in the control plane, eliminating the B-MAC learning in PBB. Also SPBM ensures that the route followed is the shortest path tree.
The forward and reverse paths used for unicast and <a href="/facts/Multicast/D9IspSfl">multicast</a> traffic in an IEEE 802.1aq network are <a href="/facts/Symmetric/hpu7DK8p">symmetric</a>. This symmetry permits IEEE 802.1ag Continuity Fault Management (CFM) to operate unchanged for SPBV and SPBM and has desirable properties with respect to time distribution protocols such as <a href="/facts/Precision_Time_Protocol/N5u5HVqx">Precision Time Protocol</a>.
Group address and unknown destination individual frames are optimally transmitted to only members of the same Ethernet service. IEEE 802.1aq supports the creation of thousands of logical Ethernet services in the form of E-LINE, E-LAN or E-TREE constructs which are formed between non-participating logical ports of the IEEE 802.1aq network. These group address packets are encapsulated with a PBB header which indicates the source participating address in the SA while the DA indicates the locally significant group address this frame should be forwarded on and which source bridge originated the frame. The IEEE 802.1aq multicast forwarding tables are created based on computations such that every bridge which is on the shortest path between a pair of bridges which are members of the same service group will create proper forwarding database (FDB) state to forward or replicate frames it receives to that members of that service group. Since the group address computation produce shortest path trees, there is only ever one copy of a multicast packet on any given link. Since only bridges on a shortest path between participating logical ports create forwarding database (FDB) state the multicast makes the efficient use of network resources.
The actual group address forwarding operation operates more or less identically to classical Ethernet, the backbone destination address (B-DA)+ backbone VLAN identifier (B-VID) combination are looked up to find the egress set of next hops. The only difference compared with classical Ethernet is that reverse learning is disabled for participating bridge backbone media access control (B-MAC) addresses and is replaced with an ingress check and discard (when the frame arrives on an incoming interface from an unexpected source). Learning is however implemented at the edges of the SPBM multicast tree to learn the B-MAC to MAC address relationship for correct individual frame encapsulation in the reverse direction (as packets arrive over the Interface).
Properly implemented an IEEE 802.1aq network can support up to 1000 participating bridges and provide tens of thousands of layer 2 E-LAN services to Ethernet devices. This can be done by simply configuring the ports facing the Ethernet devices to indicate they are members of a given service. As new members come and go, the IS-IS protocol will advertise the I-SID membership changes and the computations will grow or shrink the trees in the participating node network as necessary to maintain the efficient multicast property for that service.
IEEE 802.1aq has the property that only the point of attachment of a service needs configuration when a new attachment point comes or goes. The trees produced by the computations will automatically be extended or pruned as necessary to maintain connectivity. In some existing implementations this property is used to automatically (as opposed to through configuration) add or remove attachment points for dual-homed technologies such as rings to maintain optimum packet flow between a nonparticipating ring protocol and the IEEE 802.1aq network by activating a secondary attachment point and deactivating a primary attachment point.

<h3>Failure recovery</h3>

Failure recovery is as per normal <a href="/facts/IS-IS/zaNkSwhW">IS-IS</a> with the link failure being advertised and new computations being performed, resulting in new FDB tables. Since no Ethernet addresses are advertised or known by this protocol, there is no re-learning required by the SPBM core and its learned encapsulations are unaffected by a transit node or link failure.
Fast link failure detection may be performed using IEEE 802.1ag Continuity Check Messages (CCMs) which test link status and report a failure to the IS-IS protocol. This allows much faster failure detection than is possible using the IS-IS hello message loss mechanisms.
Both SPBV and SPBM inherit the rapid convergence of a link state control plane. A special attribute of SPBM is its ability to rebuild multicast trees in a similar time to unicast convergence, because it substitutes computation for signaling. When an SPBM bridge has performed the computations on a topology database, it knows whether it is on the shortest path between a root and one or more leaves of the SPT and can install state accordingly. Convergence is not gated by incremental discovery of a bridge's place on a multicast tree by the use of separate signaling transactions. However, SPBM on a node does not operate completely independently of its peers, and enforces agreement on the current network topology with its peers. This very efficient mechanism uses exchange of a single digest of link state covering the entire network view, and does not need agreement on each path to each root individually. The result is that the volume of messaging exchanged to converge the network is in proportion to the incremental change in topology and not the number of multicast trees in the network. A simple link event that may change many trees is communicated by signaling the link event only; the consequent tree construction is performed by local computation at each node. The addition of a single service access point to a service instance involves only the announcement of the I-SID, regardless of the number of trees. Similarly the removal of a bridge, which might involve the rebuilding of hundreds to thousands of trees, is signaled only with a few link state updates.
Commercial offerings will likely offer SPB over multi-chassis lag. In this environment multiple switch chassis appear as a single switch to the SPB control plane, and multiple links between pairs of chassis appear as an aggregate link. In this context a single link or node failure is not seen by the control plane and is handled locally resulting in sub 50ms recovery times.

<h3>Animations</h3>

Following are three animated GIFs which help to show the behavior of 802.1aq.
The first of these gifs, shown in Figure 5, demonstrates the routing in a 66 node network where we have created a 7-member E-LAN using ISID 100. In this example we show the equal cost tree (ECT) created from each member to reach all of the other members. We cycle through each member to show the full set of trees created for this service. We pause at one point to show the symmetry of routing between two of the nodes and emphasize it with a red line. In each case the source of the tree is highlighted with a small purple V.
The second of these animated gifs, shown in Figure 6, demonstrates 8 ECT paths in the same 66 node network as Figure 4. In each subsequent animated frame the same source is used (in purple) but a different destination is shown (in yellow). For each frame, all of the shortest paths are shown superimposed between the source and destination. When two shortest paths traverse the same hop, the thickness of the lines being drawn is increased. In addition to the 66 node network, a small multi level Data Center style network is also shown with sources and destinations both within the servers (at the bottom) and from servers to the router layer at the top. This animation helps to show the diversity of the ECT being produced.
The last of these animated gifs, shown in Figure 7, demonstrates source destination ECT paths using all 16 of the standard algorithms currently defined.

<h2 id="details">Details</h2>
<h3>Equal cost multi tree</h3>

Sixteen equal cost multi tree (ECMT) paths are initially defined, however there are many more possible. ECMT in an IEEE 802.1aq network is more predictable than with <a href="/facts/Internet_Protocol/Qq6VeEal">internet protocol (IP)</a> or <a href="/facts/Multiprotocol_Label_Switching/k7cx1PWw">multiprotocol label switching (MPLS)</a> because of symmetry between the forward and reverse paths. The choice as to which ECMT path will be used is therefore an operator assigned head end decision while it is a local / hashing decision with IP/MPLS.
IEEE 802.1aq, when faced with a choice between two equal link cost paths, uses the following logic for its first ECMT tie breaking algorithm: first, if one path is shorter than the other in terms of hops, the shorter path is chosen, otherwise, the path with the minimum Bridge Identifier { BridgePriority concatenated with (IS-IS SysID) } is chosen. Other ECMT algorithms are created by simply using known permutations of the BridgePriority||SysIds. For example, the second defined ECMT algorithm uses the path with the minimum of the inverse of the BridgeIdentifier and can be thought of as taking the path with the maximum node identifier. For SPBM, each permutation is instantiated as a distinct B-VID. The upper limit of multipath permutations is gated by the number of B-VIDs delegated to 802.1aq operation, a maximum of 4094, although the number of useful path permutations would only require a fraction of the available B-VID space. Fourteen additional ECMT algorithms are defined with different bit masks applied to the BridgeIdentifiers. Since the BridgeIdentifier includes a priority field, it is possible to adjust the ECMT behavior by changing the BridgePriority up or down.
A service is assigned to a given ECMT B-VID at the edge of the network by configuration. As a result, non-participating packets associated with that service are encapsulated with the VID associated with the desired ECMT end to end path. All individual and group address traffic associated with this service will therefore use the proper ECMT B-VID and be carried symmetrically end to end on the proper equal cost multi path. Essentially the operator decides which services go in which ECMT paths, unlike a hashing solution used in other systems such as IP/MPLS. Trees can support <a href="/facts/Link_aggregation/3BE3qHDT">link aggregation</a> (LAG) groups within a tree "branch" segment where some form of hashing occurs.
This symmetric and end-to-end ECMT behavior gives IEEE 802.1aq a highly predictable behavior and offline engineering tools can accurately model exact data flows. The behavior is also advantageous to networks where one-way delay measurements are important. This is because the one way delay can be accurately computed as 1/2 the round-trip delay. Such computations are used by time distribution protocols such as <a href="/facts/IEEE_1588/N5u5HVqx">IEEE 1588</a> for frequency and time-of-day synchronization as required between precision clock sources and wireless base stations.
Shown above are three figures [5,6,7] which show 8 and 16 equal cost tree (ECT) behavior in different network topologies. These are composites of screen captures of an 802.1aq network emulator and show the source in purple, the destination in yellow, and then all the computed and available shortest paths in pink. The thicker the line, the more shortest paths use that link. The animations show three different networks and a variety of source and destination pairs which continually change to help visualize what is happening.
The equal cost tree (ECT) algorithms can be almost extended through the use of OPAQUE data which allows extensions beyond the base 16 algorithms more or less infinitely. It is expected that other standards groups or vendors will produce variations on the currently defined algorithms with behaviors suited for different networks styles. It is expected that numerous shared tree models will also be defined, as will hop by hop hash based <a href="/facts/Equal-cost_multi-path_routing/yWnENc41">equal-cost multi-path</a> (ECMP) style behaviors .. all defined by a VID and an algorithm that every node agrees to run.

<h3>Traffic engineering</h3>

802.1aq does not spread traffic on a hop-by-hop basis. Instead, 802.1aq allows assignment of a Service ID (ISID) to a VLAN ID (VID) at the edge of the network. A VID will correspond to exactly one of the possible sets of shortest path nodes in the network and will never stray from that routing. If there are 10 or so shortest paths between different nodes, it is possible to assign different services to different paths and to know that the traffic for a given service will follow exactly the given path. In this manner traffic can easily be assigned to the desired shortest path. In the event that one of the paths becomes overloaded it is possible to move some services off that shortest path by reassigning those service's ISID to a different, less loaded, VID at the edges of the network.
The deterministic nature of the routing makes offline prediction/computation/experimentation of the network loading much simpler since actual routes are not dependent on the contents of the packet headers except for the VLAN identifier.

Figure 4 shows four different equal-cost paths between nodes 7 and 5. An operator can achieve a relatively good balance of traffic across the cut between nodes [0 and 2] and [1 and 3] by assigning the services at nodes 7 and 5 to one of the four desired VIDs. Using more than 4 equal cost tree (ECT) paths in the network will likely allow all 4 of these paths to be used. Balance can also be achieved between nodes 6 and 4 in a similar manner.
In the event that an operator does not wish to manually assign services to shortest paths it is a simple matter for a switch vendor to allow a simple hash of the ISID to one of the available VIDS to give a degree of non-engineered spreading. For example, the ISID modulo the number of ECT-VIDs could be used to decide on the actual relative VID to use.
In the event that the ECT paths are not sufficiently diverse the operator has the option of adjusting the inputs to the distributed ECT algorithms to apply attraction or repulsion from a given node by adjusting that node's Bridge Priority. This can be experimented with via offline tools until the desired routes are achieved at which point the bias can be applied to the real network and then ISIDs can be moved to the resulting routes.
Looking at the animations in Figure 6 shows the diversity available for traffic engineering in a 66 node network. In this animation, there are 8 ECT paths available from each highlighted source to destination and therefore services could be assigned to 8 different pools based on the VID. One such initial assignment in Figure 6 could therefore be (ISID modulo 8) with subsequent fine tuning as required.

<h3>Example</h3>

We will work through SPBM behavior on a small example, with emphasis on the shortest-path trees for unicast and multicast.
The network shown in Figure 1 consists of 8 participating nodes numbered 0 through 7. These would be switches or routers running the IEEE 802.1aq protocol. Each of the 8 participating nodes has a number of adjacencies numbered 1..5. These would likely correspond to interface indexes, or possibly port numbers. Since 802.1aq does not support parallel interfaces each interface corresponds to an adjacency. The port / interface index numbers are of course local and are shown because the output of the computations produce an interface index (in the case of unicast) or a set of interface indexes (in the case of multicast) which are part of the forwarding information base (FIB) together with a destination MAC address and backbone VID.
The network has a fully meshed inner core of four nodes (0..3) and then four outer nodes (4,5,6 and 7), each <a href="/facts/Dual-homed/VFvPRDQW">dual-homed</a> onto a pair of inner core nodes.
Normally when nodes come from the factory they have a MAC address assigned which becomes a node identifier but for the purpose of this example we will assume that the nodes have MAC addresses of the form 00:00:00:00:N:00 where N is the node id (0..7) from Figure 1. Therefore, node 2 has a MAC address of 00:00:00:00:02:00. Node 2 is connected to node 7 (00:00:00:00:07:00) via node 2's interface/5.
The <a href="/facts/IS-IS/zaNkSwhW">IS-IS</a> protocol runs on all the links shown since they are between participating nodes. The IS-IS hello protocol has a few additions for 802.1aq including information about backbone VIDs to be used by the protocol. We will assume that the operator has chosen to use backbone VIDs 101 and 102 for this instance of 802.1aq on this network.
The node will use their MAC addresses as the IS-IS SysId and join a single IS-IS level and exchange link-state packets (LSPs in IS-IS terminology). The LSPs will contain node information and link information such that every node will learn the full topology of the network. Since we have not specified any link weights in this example, the IS-IS protocol will pick a default link metric for all links, therefore all routing will be minimum hop count.
After topology discovery the next step is distributed calculation of the unicast routes for both ECMP VIDs and population of the unicast forwarding tables (FIBs).

Consider the route from Node 7 to Node 5: there are a number of equal-cost paths. 802.1aq specifies how to choose two of them: the first is referred to as the Low PATH ID path. This is the path which has the minimum node id on it. In this case the Low PATH ID path is the 7->0->1->5 path (as shown in red in Figure 2). Therefore, each node on that path will create a forwarding entry toward the MAC address of node five using the first ECMP VID 101. Conversely, 802.1aq specifies a second ECMP tie-breaking algorithm called High PATH ID. This is the path with the maximum node identifier on it and in the example is the 7->2->3->5 path (shown in blue in Figure 2).
Node 7 will therefore have a FIB that among other things indicates:

<ul><li>MAC 00:00:00:05:00 / vid 101 the next hop is interface/1.</li>
<li>MAC 00:00:00:05:00 / vid 102 the next hop is interface/2.</li></ul>
Node 5 will have exactly the inverse in its FIB:

<ul><li>MAC 00:00:00:07:00 / vid 101 the next hop is interface/1.</li>
<li>MAC 00:00:00:07:00 / vid 102 the next hop is interface/2.</li></ul>
The intermediate nodes will also produce consistent results so for example node 1 will have the following entries.

<ul><li>MAC 00:00:00:07:00 / vid 101 the next hop is interface/5.</li>
<li>MAC 00:00:00:07:00 / vid 102 the next hop is interface/4.</li>
<li>MAC 00:00:00:05:00 / vid 101 the next hop is interface/2.</li>
<li>MAC 00:00:00:05:00 / vid 102 the next hop is interface/2.</li></ul>
And Node 2 will have entries as follows:

<ul><li>MAC 00:00:00:05:00 / vid 101 the next hop is interface/2.</li>
<li>MAC 00:00:00:05:00 / vid 102 the next hop is interface/3.</li>
<li>MAC 00:00:00:07:00 / vid 101 the next hop is interface/5.</li>
<li>MAC 00:00:00:07:00 / vid 102 the next hop is interface/5.</li></ul>
If we had an attached non-participating device at Node 7 talking to a non-participating device at Node 5 (for example Device A talks to Device C in Figure 3), they would communicate over one of these shortest paths with a MAC-in-MAC encapsulated frame. The MAC header on any of the NNI links would show an outer source address of 00:00:00:70:00, an outer destination address of 00:00:00:50:00 and a BVID of either 101 or 102 depending on which has been chosen for this set of non-participating ports/vids. The header once inserted at node 7 when received from node A, would not change on any of the links until it egressed back to non-participating Device C at Node 5. All participating devices would do a simple DA+VID lookup to determine the outgoing interface, and would also check that incoming interface is the proper next hop for the packet's SA+VID. The addresses of the participating nodes 00:00:00:00:00:00 ... 00:00:00:07:00 are never learned but are advertised by IS-IS as the node's SysId.
Unicast forwarding to a non-participating client (e.g. A, B, C, D from Figure 3) address is of course only possible when the first hop participating node (e.g. 7) is able to know which last hop participating node (e.g. 5) is attached to the desired non-participating node (e.g. C). Since this information is not advertised by IEEE 802.1aq it has to be learned. The mechanism for learning is identical to <a href="/facts/IEEE_802.1ah/wblMUsQl">IEEE 802.1ah</a>, in short, the corresponding outer MAC unicast DA, if not known is replaced by a multicast DA and when a response is received, the SA of that response now tells us the DA to use to reach the non-participating node that sourced the response. e.g. node 7 learns that C is reached by node 5.

Since we wish to group/scope sets of non-participating ports into services and prevent them from multicasting to each other, IEEE 802.1aq provides mechanism for per source, per service multicast forwarding and defines a special multicast destination address format to provide this.
Since the multicast address must uniquely identify the tree, and because there is a tree per source per unique service, the multicast address contains two components, a service component in the low order 24 bits and a network-wide unique identifier in the upper 22 bits. Since this is a multicast address the multicast bit is set, and since we are not using the standard OUI space for these manufactured addresses, the Local 'L' bit is set to disambiguate these addresses. In Figure 3 above, this is represented with the DA=[7,O] where the 7 represents packets originating from node 7 and the colored O represents the E-LAN service we are scoped within.
Prior to creating multicast forwarding for a service, nodes with ports that face that service must be told they are members. For example, nodes 7,4,5 and 6 are told they are members of the given service, for example service 200, and further that they should be using BVID 101. This is advertised by ISIS and all nodes then do the SPBM computation to determine if they are participating either as a head end or tail end, or a tandem point between other head and tail ends in the service. Since node 0 is a tandem between nodes 7 and 5 it creates a forwarding entry for packets from node 7 on this service, to node 5. Likewise, since it is a tandem between nodes 7 and 4 it creates forwarding state from node 7 for packets in this service to node 4 this results in a true multicast entry where the DA/VID have outputs on two interfaces 1 and 2. Node 2 on the other hand is only on one shortest path in this service and only creates a single forwarding entry from node 7 to node 6 for packets in this service.
Figure 3 only shows a single E-LAN service and only the tree from one of the members, however very large numbers of E-LAN services with membership from 2 to every node in the network can be supported by advertising the membership, computing the tandem behaviors, manufacturing the known multicast addresses and populating the FIBs. The only real limiting factors are the FIB table sizes and computational power of the individual devices both of which are growing yearly in leaps and bounds.

<h2 id="implementation-notes">Implementation notes</h2>

802.1aq takes IS-IS topology information augmented with service attachment (I-SID) information, does a series of computations and produces a forwarding table (filtering table) for unicast and multicast entries.
The IS-IS extensions that carry the information required by 802.1aq are given in the isis-layer2 IETF document listed below.
An implementation of 802.1aq will first modify the IS-IS hellos to include an NLPID (network layer protocol identifier) of 0xC01 in their Protocols-Supported <a href="/facts/Type%25E2%2580%2593length%25E2%2580%2593value/IMeVVbpK">type–length–value</a> (TLV) (type 129) which has been reserved for 802.1aq. The hellos also must include an MSTID (which gives the purpose of each VID) and finally each ECMT behavior must be assigned to a VID and exchanged in the hellos. The hellos would normally run untagged. Note that NLPID of IP is not required to form an adjacency for 802.1aq but also will not prevent an adjacency when present.
The links are assigned 802.1aq specific metrics which travel in their own TLV (Type Length Value) which is more or less identical to the IP link metrics. The calculations will always use the maximum of the two unidirectional link metrics to enforce symmetric route weights.
The node is assigned a mac address to identify it globally and this is used to form the IS-IS SYSID. A box mac would normally serve this purpose. The Area-Id is not directly used by 802.1aq but should, of course, be the same for nodes in the same 802.1aq network. Multiple areas/levels are not yet supported.
The node is further assigned an SPSourceID which is a 20 bit network wide unique identifier. This can often be the low 20 bits of the SYSID (if unique) or can be dynamically negotiated or manually configured.
The SPSourceID and the ECMT assignments to B-VIDs are then advertised into the IS-IS network in their own 802.1aq TLV.
The 802.1aq computations are restricted to links between nodes that have an 802.1aq link weight and which support the NLPID 0xC01. As previously discussed the link weights are forced to be symmetric for the purpose of computation by taking the min of two dissimilar values.
When a service is configured in the form of an I-SID assignment to an ECMT behavior that I-SID is then advertised along with the desired ECMT behavior and an indication of its transmit, receive properties (a new TLV is used for this purpose of course).
When an 802.1aq node receives an IS-IS update it will compute the unique shortest path to all other IS-IS nodes that support 802.1aq. There will be one unique (symmetric) shortest path per ECMT behavior. The tie breaking used to enforce this uniqueness and ECMT is described below.
The unicast FDB/FIB will be populated based on this first shortest path computation. There will be one entry per ECMT behavior/B-VID produced.
The transit multicast computation (which only applies when transit replication is desired and not applicable to services that have chosen head end replication) can be implemented in many ways, care must be taken to keep this efficient, but in general a series of shortest path computations must be done. The basic requirement is to decide 'am I on the shortest path between two nodes one of which transmits an I-SID and the other receives that I-SID.'
Rather poor performing pseudocode for this computation looks something like this:

for each NODE in network which originates at least one transmit ISID do
 SPF = compute the shortest path trees from NODE for all ECMT B-VIDs.
 for each ECMT behavior do
 for each NEIGHBOR of NODE do
 if NEIGHBOR is on the SPF towards NODE for this ECMT then
 T = NODE's transmit ISIDs unioned with all receive
 ISIDs below us on SPF
 for each ISID in T do
 create/modify multicast entry where [
 MAC-DA = NODE.SpsourceID:20||ISID:24||LocalBit:1||MulticastBit:1
 B-VID = VID associated with this ECMT
 out port = interface to NEIGHBOR
 in port = port towards NODE on the SPF for this ECMT
 ]

The above pseudocode computes many more SPF's than strictly necessary in most cases and better algorithms are known to decide if a node is on a shortest path between two other nodes. A reference to a paper presented at the IEEE which gives a much faster algorithm that drastically reduces the number of outer iterations required is given below.
In general though even the exhaustive algorithm above is more than able to handle several hundred node networks in a few tens of milliseconds on the 1 GHz or greater common CPUs when carefully crafted.
For ISIDs that have chosen head-end replication the computation is trivial and involves simply finding the other attachment points that receive that ISID and creating a serial unicast table to replicate to them one by one.

<h3>Tie-breaking</h3>
802.1aq must produce deterministic symmetric downstream congruent shortest paths. This means that not only must a given node compute the same path forward and reverse but all the other nodes downstream (and upstream) on that path must also produce the same result. This downstream congruence is a consequence of the hop by hop forwarding nature of Ethernet since only the destination address and VID are used to decide the next hop. It is important to keep this in mind when trying to design other ECMT algorithms for 802.1aq as this is an easy trap to fall into.
It begins by taking the unidirectional link metrics that are advertised by ISIS for 802.1aq and ensuring that they are symmetric. This is done by simply taking the MIN of the two values at both ends prior to doing any computations. This alone does not guarantee symmetry however.

The 802.1aq standard describes a mechanism called a PATHID which is a network-wide unique identifier for a path. This is a useful logical way to understand how to deterministically break ties but is not how one would implement such a tie-breaker in practice.
The PATHID is defined as just the sequence of SYSIDs that make up the path (not including the end points).. sorted. Every path in the network therefore has a unique PATHID independent of where in the network the path is discovered.
802.1aq always picks the lowest PATHID path when a choice presents itself in the shortest path computations. This ensures that every node will make the same decision.
For example, in Figure 7 above, there are four equal-cost paths between node 7 and node 5 as shown by the colors blue, green, pink and brown. The PATHID for these paths are as follows:

<ul><li>PATHID[brown] = {0,1}</li>
<li>PATHID[pink] = {0,3}</li>
<li>PATHID[green] = {1,2}</li>
<li>PATHID[blue] = {2,3}</li></ul>
The lowest PATHID is therefore the brown path {0,1}.
This low PATHID algorithm has very desirable properties. The first is that it can be done progressively by simply looking for the lowest SYSID along a path and secondly because an efficient implementation that operates stepwise is possible by simply back-tracking two competing paths and looking for the minimum of the two paths minimum SYSIDs.
The low PATHID algorithm is the basis of all 802.1aq tie breaking. ECMT is also based on the low PATHID algorithm by simply feeding it different SYSID permutations – one per ECMT algorithm. The most obvious permutation to pass is a complete inversion of the SYSID by XOR-ing it with 0xfff... prior to looking for the min of two minimums. This algorithm is referred to as high PATHID because it logically chooses the largest PATHID path when presented with two equal-cost choices.
In the example in figure 7, the path with the highest PATHID is therefore the blue path whose PATHID is {2,3}. Simply inverting all the SYSIDs and running the low PATHID algorithm will yield same result.
The other 14 defined ECMT algorithms use different permutations of the SYSID by XOR-ing it with different bit masks which are designed to create relatively good distribution of bits. It should be clear that different permutations will result in the purple and green paths being lowest in turn.
The 17 individual 64-bit masks used by the ECT algorithm are made up of the same byte value repeated eight times to fill each 64-bit mask. These 17 byte values are as follows:

ECT-MASK[17] = { 0x00, 0x00, 0xFF, 0x88,
 0x77, 0x44, 0x33, 0xCC,
 0xBB, 0x22, 0x11, 0x66,
 0x55, 0xAA, 0x99, 0xDD,
 0xEE };

ECT-MASK[0] is reserved for a common spanning tree algorithm, while ECT-MASK[1] creates the Low PATHID set of shortest path first trees, ECT-MASK[2] creates the High PATHID set of shortest path trees and the other indexes create other relatively diverse permutations of shortest path first trees.
In addition the ECMT tie-breaking algorithms also permit some degree of human override or tweaking. This is accomplished by including a BridgePriority field together with the SYSID such that the combination, called a BridgeIdentifier, becomes the input to the ECT algorithm. By adjusting the BridgePriority up or down a path's PATHID can be raised or lowered relative to others and a substantial degree of tunability is afforded.
The above description gives an easy to understand way to view the tie breaking; an actual implementation simply backtracks from the fork point to the join point in two competing equal-cost paths (usually during the <a href="/facts/Dijkstra%2527s_algorithm/ehun88jl">Dijkstra shortest path</a> computation) and picks the path traversing the lowest (after masking) BridgePriority|SysId.

<h2 id="interoperability">Interoperability</h2>
The first public interoperability tests of IEEE 802.1aq were held in Ottawa in October 2010. Two vendors provided SPBM implementations and a total of 5 physical switches and 32 emulated switches were tested for control/data and OA&M.<a class="footnote-ref" id="fnref:30" href="#fn:30">30</a>
Further events were held in Ottawa in January 2011 with 5 vendors and 6 implementations,<a class="footnote-ref" id="fnref:31" href="#fn:31">31</a> at 2013's Interop event at Las Vegas where an SPBM network was used as a backbone.<a class="footnote-ref" id="fnref:32" href="#fn:32">32</a><a class="footnote-ref" id="fnref:33" href="#fn:33">33</a>

<h2 id="competitors">Competitors</h2>
<a href="/facts/MC-LAG/5nWNY7ed">MC-LAG</a>, <a href="/facts/VXLAN/X7RmKePU">VXLAN</a>, and <a href="/facts/QFabric/A0j19324">QFabric</a> have all been proposed, but the IETF <a href="/facts/TRILL/7lHM52Xe">TRILL</a> standard (Transparent Interconnect of Lots of Links) is considered the major competitor of IEEE 802.1aq, and: "the evaluation of relative merits and difference of the two standards proposals is currently a hotly debated topic in the networking industry."<a class="footnote-ref" id="fnref:34" href="#fn:34">34</a>

<h2 id="deployments">Deployments</h2>
Deployment considerations and interoperability best practices are documented in an IETF document titled "SPB Deployment Considerations"<a class="footnote-ref" id="fnref:35" href="#fn:35">35</a>

<ul><li>2013 <a href="/facts/Interop/9cSmE8TA">Interop</a>: Networking Leaders Demo Shortest Path Bridging<a class="footnote-ref" id="fnref:36" href="#fn:36">36</a></li>
<li>2014 <a href="/facts/Interop/9cSmE8TA">Interop</a>: InteropNet Goes IPv6, Includes Shortest Path Bridging<a class="footnote-ref" id="fnref:37" href="#fn:37">37</a></li></ul>
Extreme Networks, by virtue of their acquisition of the Avaya Networking business and assets, is currently the leading exponent of SPB-based deployments; their enhanced and extended implementation of SPB - including integrated Layer 3 IP Routing and IP Multicast functionality - is marketed under the banner of the "Fabric Connect" technology. Additionally, Extreme Networks is supporting an <a href="/facts/IETF_Internet_Draft/h13QYxXa">IETF Internet Draft</a> Draft that defines a means of automatically extended SPBM-based services to end-devices via conventional Ethernet Switches, leveraging an <a href="/facts/IEEE_802.1AB/8EeXor0m">IEEE 802.1AB</a> LLDP-based communications protocol; this capability - marketing "<a href="/facts/Virtual_Enterprise_Network_Architecture/gGUf1VsL">Fabric Attach</a>" technology - allows for the automatic attachment of end-devices, and includes dynamic configuration of VLAN/I-SID (VSN) mappings.<a class="footnote-ref" id="fnref:38" href="#fn:38">38</a><a class="footnote-ref" id="fnref:39" href="#fn:39">39</a>
Avaya (acquired by Extreme Networks) has deployed SPB/Fabric Connect solutions for businesses operating across a number of industry verticals:<a class="footnote-ref" id="fnref:40" href="#fn:40">40</a>

<ul><li>Education, examples include: Leeds Metropolitan University,<a class="footnote-ref" id="fnref:41" href="#fn:41">41</a> Macquaire University,<a class="footnote-ref" id="fnref:42" href="#fn:42">42</a> Pearland Independent School District,<a class="footnote-ref" id="fnref:43" href="#fn:43">43</a> Ajman University of Science & Technology<a class="footnote-ref" id="fnref:44" href="#fn:44">44</a></li>
<li>Transportation, examples include: Schiphol Telematics,<a class="footnote-ref" id="fnref:45" href="#fn:45">45</a> Rheinbahn,<a class="footnote-ref" id="fnref:46" href="#fn:46">46</a> Sendai City Transportation Bureau,<a class="footnote-ref" id="fnref:47" href="#fn:47">47</a> NSB<a class="footnote-ref" id="fnref:48" href="#fn:48">48</a></li>
<li>Banking & Finance, examples include: Fiducia,<a class="footnote-ref" id="fnref:49" href="#fn:49">49</a> Sparebanken Vest<a class="footnote-ref" id="fnref:50" href="#fn:50">50</a></li>
<li>Major Events, examples include: 2013 & 2014 Interop (InteropNet Backbone),<a class="footnote-ref" id="fnref:51" href="#fn:51">51</a> 2014 Sochi Winter Olympics,<a class="footnote-ref" id="fnref:52" href="#fn:52">52</a> Dubai World Trade Center<a class="footnote-ref" id="fnref:53" href="#fn:53">53</a><a class="footnote-ref" id="fnref:54" href="#fn:54">54</a></li>
<li>Healthcare, examples include: Oslo University Hospital,<a class="footnote-ref" id="fnref:55" href="#fn:55">55</a><a class="footnote-ref" id="fnref:56" href="#fn:56">56</a> Concord Hospital,<a class="footnote-ref" id="fnref:57" href="#fn:57">57</a> Franciscan Alliance,<a class="footnote-ref" id="fnref:58" href="#fn:58">58</a> Sydney Adventist Hospital<a class="footnote-ref" id="fnref:59" href="#fn:59">59</a></li>
<li>Manufacturing, examples include: Fujitsu Technology Solutions<a class="footnote-ref" id="fnref:60" href="#fn:60">60</a></li>
<li>Media, examples include: Schibsted,<a class="footnote-ref" id="fnref:61" href="#fn:61">61</a> Medienhaus Lensing,<a class="footnote-ref" id="fnref:62" href="#fn:62">62</a> Sanlih Entertainment Television<a class="footnote-ref" id="fnref:63" href="#fn:63">63</a></li>
<li>Government, examples include: City of Redondo Beach,<a class="footnote-ref" id="fnref:64" href="#fn:64">64</a> City of Breda,<a class="footnote-ref" id="fnref:65" href="#fn:65">65</a> Bezirksamt Neukölln<a class="footnote-ref" id="fnref:66" href="#fn:66">66</a></li></ul>
<h2 id="product-support">Product support</h2>
<ul><li><a href="/facts/Alcatel-Lucent/X0rLGYr7">Alcatel-Lucent</a> 7750-SR,</li>
<li><a href="https://www.al-enterprise.com">Alcatel-Lucent Enterprise</a> OmniSwitch 9900,<a class="footnote-ref" id="fnref:67" href="#fn:67">67</a> OmniSwitch 6900,<a class="footnote-ref" id="fnref:68" href="#fn:68">68</a> OmniSwitch 6860,<a class="footnote-ref" id="fnref:69" href="#fn:69">69</a> OmniSwitch 6865<a class="footnote-ref" id="fnref:70" href="#fn:70">70</a></li>
<li>Extreme Networks 5000 Series (5720, 5520, 5420 and 5320)</li>
<li><a href="/facts/Avaya_VSP-9000_System/QVn1Maak">Extreme Networks VSP 9000 Series</a><a class="footnote-ref" id="fnref:71" href="#fn:71">71</a></li>
<li>Extreme Networks VSP 8400 Series</li>
<li><a href="/facts/Avaya_VSP_8000_Series/8aEIcA1M">Extreme Networks VSP 8000 Series</a> (VSP 8284XSQ, VSP 8404C)</li>
<li><a href="/facts/Avaya_VSP-7000_System/T7p8k6Rr">Extreme Networks VSP 7200 Series</a><a class="footnote-ref" id="fnref:72" href="#fn:72">72</a></li>
<li><a href="/facts/Avaya_VSP-4000_System/5DUcgkVR">Extreme Networks VSP 4000 Series</a><a class="footnote-ref" id="fnref:73" href="#fn:73">73</a><a class="footnote-ref" id="fnref:74" href="#fn:74">74</a><a class="footnote-ref" id="fnref:75" href="#fn:75">75</a><a class="footnote-ref" id="fnref:76" href="#fn:76">76</a> (VSP 4450GSX-PWR+, VSP 4450GSX-DC, VSP 4450GTX-HT-PWR+, VSP 4850GTS, VSP 4850GTS-PWR+, VSP 4850GTS-DC)<a class="footnote-ref" id="fnref:77" href="#fn:77">77</a></li>
<li>Extreme Networks ERS 5900 Series</li>
<li><a href="/facts/Extreme_Networks/KvjBGmj2">Extreme Networks</a> ERS 4900 Series</li>
<li><a href="/facts/Extreme_Networks/KvjBGmj2">Extreme Networks</a> ERS 4800 Series<a class="footnote-ref" id="fnref:78" href="#fn:78">78</a></li>
<li><a href="/facts/Enterasys_Networks/ArbI18l9">Enterasys Networks</a> S140 and S180<a class="footnote-ref" id="fnref:79" href="#fn:79">79</a><a class="footnote-ref" id="fnref:80" href="#fn:80">80</a><a class="footnote-ref" id="fnref:81" href="#fn:81">81</a></li>
<li><a href="/facts/Extreme_Networks/KvjBGmj2">Extreme Networks</a> K-Series<a class="footnote-ref" id="fnref:82" href="#fn:82">82</a></li>
<li><a href="/facts/Huawei/Qwu0tbnL">Huawei</a> S9300 (prototype only at the moment)</li>
<li>Solana<a class="footnote-ref" id="fnref:83" href="#fn:83">83</a></li>
<li><a href="/facts/Spirent/UqP6un5f">Spirent</a><a class="footnote-ref" id="fnref:84" href="#fn:84">84</a></li>
<li><a href="/facts/Hewlett-Packard/abuNSYNu">HP</a> 5900, 5920, 5930, 11900,<a class="footnote-ref" id="fnref:85" href="#fn:85">85</a><a class="footnote-ref" id="fnref:86" href="#fn:86">86</a> 12500,<a class="footnote-ref" id="fnref:87" href="#fn:87">87</a> 12900</li>
<li>IP Infusion's ZebOS network platform<a class="footnote-ref" id="fnref:88" href="#fn:88">88</a></li>
<li>IXIA<a class="footnote-ref" id="fnref:89" href="#fn:89">89</a></li>
<li>JDSU<a class="footnote-ref" id="fnref:90" href="#fn:90">90</a></li></ul>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Connection-oriented_Ethernet/DuSdx4Vt">Connection-oriented Ethernet</a></li>
<li><a href="/facts/Provider_Backbone_Bridge_Traffic_Engineering/rU6E9CJq">Provider Backbone Bridge Traffic Engineering</a> (PBB-TE)</li>
<li><a href="/facts/Virtual_Enterprise_Network_Architecture/gGUf1VsL">Virtual Enterprise Network Architecture</a></li></ul>
<h2 id="notes">Notes</h2>

<ul><li><a href="http://networkingnerd.net/2013/10/14/avaya-and-the-magic-of-spb/">"Avaya and the Magic of SPB"</a>. The Networking Nerd. 14 October 2013. Retrieved 14 October 2013.</li>
<li><a href="https://www.youtube.com/watch?v=aEmTyXuY_8g">"Paul Unbehagen talks SPB"</a>. Interop New york 2013 Tech Field Day. 3 October 2013. Retrieved 3 October 2013.</li>
<li><a href="http://packetpushers.net/show-158-avaya-software-defined-data-centre-fabric-connect">"Show 158: Avaya Software-Defined Data Center and Fabric Connect"</a>. Packet Pushers Podcast. 21 August 2013. Retrieved 21 August 2013.</li>
<li><a href="http://packetpushers.net/show-147-avaya-fabric-connect-makes-multicast-simple-really-sponsored">"Show 147: Avaya Fabric Connect Makes Multicast Simple (Really)"</a>. Packet Pushers Podcast. 13 May 2013. Retrieved 13 May 2013.</li>
<li><a href="http://packetpushers.net/show-136-avaya-considerations-for-turning-your-network-into-an-ethernet-fabric-sponsored/">"Show 136: Avaya - Consideration For Turning Your Network into An Ethernet Fabric"</a>. Packet Pushers Podcast. 18 February 2013. Retrieved 18 February 2013.</li>
<li><a href="http://packetpushers.net/case-shortest-path-bridging-802-1aq-spb">"Show 44: The Case for Shortest Path Bridging"</a>. Packet Pushers Podcast. 15 May 2011. Retrieved 15 May 2011.</li>
<li>Ashwood-Smith, Peter (24 February 2011). <a href="https://web.archive.org/web/20120321071227/http://www.apricot-apan.asia/__data/assets/powerpoint_doc/0013/32008/APRICOT_SPB_Overview.ppt">"( ASIA PACIFIC CONFERENCE )"</a>. Archived from the original on 21 March 2012. Retrieved 20 July 2011.</li>
<li>Ashwood-Smith, Peter (3 October 2010). <a href="http://www.nanog.org/meetings/nanog50/presentations/Sunday/IEE_shortest_path_bridging.wmv">"Shortest Path Bridging IEEE 802.1aq Tutorial Video"</a> (WMV). NANOG 50. Retrieved 20 July 2011.</li>
<li>Ashwood-Smith, Peter (3 October 2010). <a href="https://web.archive.org/web/20110727114050/http://www.nanog.org/meetings/nanog50/presentations/Sunday/IEEE_8021aqShortest_Path.pdf">"Shortest Path Bridging IEEE 802.1aq Tutorial Slides"</a> (PDF). NANOG 50. Archived from <a href="http://www.nanog.org/meetings/nanog50/presentations/Sunday/IEEE_8021aqShortest_Path.pdf">the original</a> (PDF) on 27 July 2011. Retrieved 20 July 2011.</li>
<li>Ashwood-Smith, Peter (15 June 2010). <a href="http://www.nanog.org/meetings/nanog49/presentations/Tuesday/shrt_pth_brdg.wmv">"Shortest Path Bridging IEEE 802.1aq Video"</a> (WMV). NANOG 49. Retrieved 20 July 2011.</li>
<li>Ashwood-Smith, Peter (15 June 2010). <a href="https://web.archive.org/web/20110727112330/http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Ashwood-SPB.pdf">"Shortest Path Bridging IEEE 802.1aq Slides"</a> (PDF). NANOG 49. Archived from <a href="http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Ashwood-SPB.pdf">the original</a> (PDF) on 27 July 2011. Retrieved 20 July 2011.</li>
<li>Ashwood-Smith, Peter (7 September 2010). <a href="https://web.archive.org/web/20120308170132/http://www.uknof.org.uk/uknof17/Ashwood_Smith-SPB.pdf">"Shortest Path Bridging IEEE 802.1aq Overview & Applications"</a> (PDF). UK Network Operators Forum. Archived from <a href="http://www.uknof.org.uk/uknof17/Ashwood_Smith-SPB.pdf">the original</a> (PDF) on 8 March 2012. Retrieved 20 July 2011.</li>
<li>Fedyk, Don (12 July 2010). <a href="https://web.archive.org/web/20120309160741/http://www.internet2.edu/presentations/jt2010july/20100712-Shortest_Path_Bridgingv3-Fedyk.pdf">"Shortest Path Bridging IEEE 802.1aq Overview"</a> (PDF). Archived from <a href="http://www.internet2.edu/presentations/jt2010july/20100712-Shortest_Path_Bridgingv3-Fedyk.pdf">the original</a> (PDF) on 9 March 2012. Retrieved 20 July 2011.</li>
<li><a href="http://www.ieee802.org/1/files/public/docs2010/aq-fedyk-SPB-DataCenter-tutorial-0710-v1.ppt">"Shortest Path Bridging IEEE 802.1aq - Insightful Technology Talk"</a>. 14 July 2010. Retrieved 20 July 2011.</li>
<li>Allan, David (August 2010). <a href="https://web.archive.org/web/20120319204132/http://www.ontc-prism.org/issues/ONTC_PRISM-vol1-no-3.pdf">"Shortest Path Bridging: A Novel Control Plane for Ethernet"</a> (PDF). ONTC PRISM Newsletter. 1 (3). Archived from <a href="http://www.ontc-prism.org/issues/ONTC_PRISM-vol1-no-3.pdf">the original</a> (PDF) on 19 March 2012. Retrieved 20 July 2011.</li>
<li><a href="http://www.ieee802.org/1/pages/802.1aq.html">"802.1aq Shortest Path Bridging Work Group"</a>. IEEE. Retrieved 20 July 2011.</li>
<li>Chiabaut, Jérôme; Bragg, Nigel (November 2009). <a href="http://www.ieee802.org/1/files/public/docs2009/aq-nbragg-fast-spf-for-SPB-1109-v01.pdf">"Speeding up the SPB Computation"</a> (PDF). Retrieved 20 July 2011.</li>
<li>Ashwood-Smith, Peter (November 2009). <a href="http://www.ieee802.org/1/files/public/docs2009/aq-ashwood-ECT-framework-1109-v1.ppt">"IEEE 802.1aq Equal Cost Tree (ECT) Framework Proposal"</a>. Retrieved 20 July 2011.</li>
<li>Fedyk, Don; Bottorff, Paul (January 2007). <a href="http://www.ieee802.org/1/files/public/docs2007/aq-fedyk-provider-link-state-bridging-0107-01.pdf">"Provider Link State Bridging (PLSB)"</a> (PDF). Retrieved 20 July 2011.</li>
<li>Fedyk, Don. <a href="http://www.ieee802.org/1/files/public/docs2007/aq-fedyk-plsb-present-0107.pdf">"Provider Link State Bridging"</a> (PDF).</li>
<li>Avaya VSP Configuration Guide<a class="footnote-ref" id="fnref:91" href="#fn:91">91</a></li>
<li>Allan, D.; Ashwood-Smith, P.; Bragg, N.; Fedyk, D. (12 September 2008). "Provider link state bridging". IEEE Communications Magazine. 46 (9): 110–117. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1109%2FMCOM.2008.4623715">10.1109/MCOM.2008.4623715</a>. <a href="/facts/ISSN_(identifier)/DPAflDvU">ISSN</a> <a href="https://search.worldcat.org/issn/0163-6804">0163-6804</a>. <a href="/facts/S2CID_(identifier)/ldJsHa2Y">S2CID</a> <a href="https://api.semanticscholar.org/CorpusID:37237892">37237892</a>.</li></ul>
<h2 id="further-reading">Further reading</h2>
<ul><li>Howard Solomon (7 September 2011). <a href="http://www.itworldcanada.com/news/tests-shows-spb-ready-say-network-equipment-makers/143907">"Tests shows SPB ready, say network equipment makers"</a>. IT World Canada. Retrieved 11 September 2011.</li>
<li>"Alcatel, Avaya, Huawei, Spirent trial SPB interoperability". Telecom Paper. 8 September 2011.</li>
<li>Allan, David; Bragg, Nigel (13 March 2012). 802.1aq Shortest Path Bridging Design and Evolution: The Architects' Perspective. John Wiley & Sons Inc. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 978-1-118-14866-2.</li>
<li><a href="http://www.avaya.com/usa/resource/assets/factsheet/Introduction_to_Shortest_Path_Bridging_dn4799.pdf">"Introduction to Shortest Path Bridging"</a> (PDF). Avaya. September 2009. Retrieved 5 January 2011.[permanent dead link‍]</li>
<li><a href="http://www.nanog.org/meetings/nanog50/presentations/Monday/NANOG50.Talk63.NANOG50_TRILL-SPB-Debate-Roisman.pdf">The Great Debate: TRILL Versus 802.1aq (SBP)</a>, <a href="/facts/North_American_Network_Operators%2527_Group/kMJqx1uf">NANOG</a> 50 session (October 2010)</li></ul>
<h2 id="external-links">External links</h2>

Wikimedia Commons has media related to IEEE 802.1aq.

<ul><li><a href="http://www.ieee802.org/">802 Committee website</a></li>
<li><a href="http://www.marketwatch.com/story/alcatel-lucent-avaya-huawei-solana-and-spirent-showcase-shortest-path-bridging-interoperability-2011-09-07-9370?reflink=MW_news_stmp">Avaya Alcatel-Lucent Huawei Solana and Sprient Showcase Shortest Path Bridging Interoperability</a> <a href="https://web.archive.org/web/20110928011905/http://www.marketwatch.com/story/alcatel-lucent-avaya-huawei-solana-and-spirent-showcase-shortest-path-bridging-interoperability-2011-09-07-9370?reflink=MW_news_stmp">Archived</a> 28 September 2011 at the <a href="/facts/Wayback_Machine/nmQ3a6JC">Wayback Machine</a>; Marketwatch, 7 September 2011 - Retrieved 7 September 2011</li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1">"Alcatel-Lucent, Avaya, Huawei, Solana and Spirent Showcase Shortest Path Bridging Interoperability". Huawei. 7 September 2011. Retrieved 11 September 2011. <a href="http://www.marketwire.com/press-release/alcatel-lucent-avaya-huawei-solana-spirent-showcase-shortest-path-bridging-interoperability-paris-alu-1557944.htm" target="_blank">http://www.marketwire.com/press-release/alcatel-lucent-avaya-huawei-solana-spirent-showcase-shortest-path-bridging-interoperability-paris-alu-1557944.htm</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
<li id="fn:2">Luo, Zhen; Suh, Changjin (3 March 2011). "An improved shortest path bridging protocol for Ethernet backbone network". The International Conference on Information Networking 2011 (ICOIN2011). IEEE Xplore. pp. 148–153. doi:10.1109/ICOIN.2011.5723169. ISBN 978-1-61284-661-3. ISSN 1976-7684. S2CID 11193141. <a href="978-1-61284-661-3" target="_blank">978-1-61284-661-3</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></li>
<li id="fn:3">"Lab Testing Summary Report; Data Center Configuration with SPB" (PDF). Miercom. September 2011. Retrieved 25 December 2011. <a href="http://docs.media.bitpipe.com/io_10x/io_101870/item_458574/Miercom%20Report%20Avaya%20Ethernet%20Fabric%20SR111013%2015Oct11%20%282%29.pdf" target="_blank">http://docs.media.bitpipe.com/io_10x/io_101870/item_458574/Miercom%20Report%20Avaya%20Ethernet%20Fabric%20SR111013%2015Oct11%20%282%29.pdf</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></li>
<li id="fn:4">Shuang Yu. "IEEE approves new IEEE 802.1aq™ Shortest path bridging". IEEE Standards Association. Archived from the original on 14 May 2013. Retrieved 19 June 2012. Using the IEEE's next-generation VLAN, called a Service Interface Identifier (I-SID), it is capable of supporting 16 million unique services compared to the VLAN limit of four thousand. <a href="https://web.archive.org/web/20130514211405/http://standards.ieee.org/news/2012/802.1aq.html" target="_blank">https://web.archive.org/web/20130514211405/http://standards.ieee.org/news/2012/802.1aq.html</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></li>
<li id="fn:5">Peter Ashwood-Smith (24 February 2011). "Shortest Path Bridging IEEE 802.1aq Overview" (PDF). Huawei. Archived from the original (PDF) on 15 May 2013. Retrieved 11 May 2012. <a href="https://web.archive.org/web/20130515115628/http://meetings.apnic.net/__data/assets/pdf_file/0012/32007/APRICOT_SPB_Overview.pdf" target="_blank">https://web.archive.org/web/20130515115628/http://meetings.apnic.net/__data/assets/pdf_file/0012/32007/APRICOT_SPB_Overview.pdf</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></li>
<li id="fn:6">Jim Duffy (11 May 2012). "Largest Illinois healthcare system uproots Cisco to build $40M private cloud". PC Advisor. Retrieved 11 May 2012. Shortest Path Bridging will replace Spanning Tree in the Ethernet fabric. <a href="http://www.pcadvisor.co.uk/news/internet/3357242/largest-illinois-healthcare-system-uproots-cisco-build-40m-private-cloud/" target="_blank">http://www.pcadvisor.co.uk/news/internet/3357242/largest-illinois-healthcare-system-uproots-cisco-build-40m-private-cloud/</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></li>
<li id="fn:7">"IEEE Approves New IEEE 802.1aq Shortest Path Bridging Standard". Tech Power Up. 7 May 2012. Retrieved 11 May 2012. <a href="http://www.techpowerup.com/165594/IEEE-Approves-New-IEEE-802.1aq-Shortest-Path-Bridging-Standard.html" target="_blank">http://www.techpowerup.com/165594/IEEE-Approves-New-IEEE-802.1aq-Shortest-Path-Bridging-Standard.html</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></li>
<li id="fn:8">D. Fedyk, Ed.; P. Ashwood-Smith, Ed.; D. Allan, A. Bragg; P. Unbehagen (April 2012). "IS-IS Extensions Supporting IEEE 802.1aq". IETF. Retrieved 12 May 2012. <a href="http://www.ietf.org/mail-archive/web/ietf-announce/current/msg10166.html" target="_blank">http://www.ietf.org/mail-archive/web/ietf-announce/current/msg10166.html</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></li>
<li id="fn:9">Unbehagen, Paul; Bragg, Nigel; Allan, David; Fedyk, Don; Ashwood-Smith, Peter J. (April 2012). Fedyk, D; Ashwood-Smith, P (eds.). IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging. IETF. doi:10.17487/RFC6329. RFC 6329. <a href="https://datatracker.ietf.org/doc/html/rfc6329" target="_blank">https://datatracker.ietf.org/doc/html/rfc6329</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></li>
<li id="fn:10">"802.1aq - Shortest Path Bridging". <a href="http://www.ieee802.org/1/pages/802.1aq.html" target="_blank">http://www.ieee802.org/1/pages/802.1aq.html</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></li>
<li id="fn:11">"Shortest Path Bridging 802.1aq - IEEE REVCOM approval today". 29 March 2012. Retrieved 2 April 2012. <a href="http://www.ietf.org/mail-archive/web/spb-isis/current/msg00043.html" target="_blank">http://www.ietf.org/mail-archive/web/spb-isis/current/msg00043.html</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></li>
<li id="fn:12">"Interop: Networking Leaders Demo Shortest Path Bridging". <a href="http://www.cio-today.com/story.xhtml?story_id=013001BYO4K5&full_skip=1" target="_blank">http://www.cio-today.com/story.xhtml?story_id=013001BYO4K5&full_skip=1</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></li>
<li id="fn:13">"Avaya Extends the Automated Campus to End the Network Waiting Game". Avaya. 1 April 2014. Retrieved 18 April 2014. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140401" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140401</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></li>
<li id="fn:14">"Avaya Networking Solutions Close the Gap between Data Center and End Devices". Avaya. 26 March 2014. Retrieved 18 April 2014. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140326" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140326</a> <a href="#fnref:14" class="footnote-back-ref">↩</a></li>
<li id="fn:15">"Can I use Shortest Path Bridging hardware to build my SDN network". 8 April 2014. Retrieved 18 April 2014. <a href="http://rtomaszewski.blogspot.com/2014/04/can-i-use-shortest-path-bridging.html" target="_blank">http://rtomaszewski.blogspot.com/2014/04/can-i-use-shortest-path-bridging.html</a> <a href="#fnref:15" class="footnote-back-ref">↩</a></li>
<li id="fn:16">"Sochi 2014 Olympic Winter Games" (PDF). Avaya. 2013. Archived from the original (PDF) on 13 May 2014. Retrieved 10 December 2013. <a href="https://web.archive.org/web/20140513215409/http://www.avaya.com/ru/resource/assets/casestudies/DN7191EN-Sochi.pdf" target="_blank">https://web.archive.org/web/20140513215409/http://www.avaya.com/ru/resource/assets/casestudies/DN7191EN-Sochi.pdf</a> <a href="#fnref:16" class="footnote-back-ref">↩</a></li>
<li id="fn:17">"Avaya at Sochi 2014". Avaya. Archived from the original on 2 May 2014. Retrieved 1 May 2014. <a href="https://web.archive.org/web/20140502000611/http://www2.avaya.com/ru/sochi2014/" target="_blank">https://web.archive.org/web/20140502000611/http://www2.avaya.com/ru/sochi2014/</a> <a href="#fnref:17" class="footnote-back-ref">↩</a></li>
<li id="fn:18">James Careless (16 December 2013). "Avaya builds massive Wi-Fi net for 2014 Winter Olympics". Network World. Archived from the original on 4 April 2014. Retrieved 11 August 2016. <a href="https://web.archive.org/web/20140404152259/http://www.networkworld.com/news/2013/121613-avaya-wifi-olympics-276776.html?source=NWWNLE_nlt_network_systems_2013-12-16" target="_blank">https://web.archive.org/web/20140404152259/http://www.networkworld.com/news/2013/121613-avaya-wifi-olympics-276776.html?source=NWWNLE_nlt_network_systems_2013-12-16</a> <a href="#fnref:18" class="footnote-back-ref">↩</a></li>
<li id="fn:19">"802.1Q-2014 - Bridges and Bridged Networks". <a href="http://www.ieee802.org/1/pages/802.1Q-2014.html" target="_blank">http://www.ieee802.org/1/pages/802.1Q-2014.html</a> <a href="#fnref:19" class="footnote-back-ref">↩</a></li>
<li id="fn:20">"802.1Qbp - Equal Cost Multiple Paths". <a href="http://www.ieee802.org/1/pages/802.1bp.html" target="_blank">http://www.ieee802.org/1/pages/802.1bp.html</a> <a href="#fnref:20" class="footnote-back-ref">↩</a></li>
<li id="fn:21">"P802.1Qcj – Automatic Attachment to Provider Backbone Bridging (PBB) services". <a href="https://1.ieee802.org/tsn/802-1qcj/" target="_blank">https://1.ieee802.org/tsn/802-1qcj/</a> <a href="#fnref:21" class="footnote-back-ref">↩</a></li>
<li id="fn:22">Ashwood-Smith, Peter (October 2010). "Shortest Path Bridging IEEE 802.1aq Tutorial and Demo" (PDF). NANOG. <a href="http://www.nanog.org/meetings/nanog50/presentations/Sunday/IEEE_8021aqShortest_Path.pdf" target="_blank">http://www.nanog.org/meetings/nanog50/presentations/Sunday/IEEE_8021aqShortest_Path.pdf</a> <a href="#fnref:22" class="footnote-back-ref">↩</a></li>
<li id="fn:23">Fedyk, Don (October 2012). "Introduction to Shortest Path Bridging" (PDF). Netnod. Archived from the original (PDF) on 4 March 2016. <a href="https://web.archive.org/web/20160304215248/http://www.netnod.se/sites/default/files/SPB-fedyk-091012.pdf" target="_blank">https://web.archive.org/web/20160304215248/http://www.netnod.se/sites/default/files/SPB-fedyk-091012.pdf</a> <a href="#fnref:23" class="footnote-back-ref">↩</a></li>
<li id="fn:24">"Avaya - Considerations for Turning your Network into an Ethernet Fabric". Packet Pushers. 18 February 2013. <a href="http://packetpushers.net/show-136-avaya-considerations-for-turning-your-network-into-an-ethernet-fabric-sponsored/" target="_blank">http://packetpushers.net/show-136-avaya-considerations-for-turning-your-network-into-an-ethernet-fabric-sponsored/</a> <a href="#fnref:24" class="footnote-back-ref">↩</a></li>
<li id="fn:25">"SDN, NFV & Network Virtualization Technologies". SDNCentral. Retrieved 22 August 2014. <a href="http://www.sdncentral.com/sdn-technologies/" target="_blank">http://www.sdncentral.com/sdn-technologies/</a> <a href="#fnref:25" class="footnote-back-ref">↩</a></li>
<li id="fn:26">Unbehagen, Paul; Bragg, Nigel; Allan, David; Fedyk, Don; Ashwood-Smith, Peter J. (April 2012). Fedyk, D; Ashwood-Smith, P (eds.). IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging. IETF. doi:10.17487/RFC6329. RFC 6329. <a href="https://datatracker.ietf.org/doc/html/rfc6329" target="_blank">https://datatracker.ietf.org/doc/html/rfc6329</a> <a href="#fnref:26" class="footnote-back-ref">↩</a></li>
<li id="fn:27">Eastlake, D. (July 2011). "IANA Considerations for Network Layer Protocol Identifiers". IETF. doi:10.17487/RFC6328. <a href="http://tools.ietf.org/html/rfc6328" target="_blank">http://tools.ietf.org/html/rfc6328</a> <a href="#fnref:27" class="footnote-back-ref">↩</a></li>
<li id="fn:28">ITU-T Recommendation Y.1731 OAM functions and mechanisms for Ethernet based networks <a href="http://www.itu.int/rec/T-REC-Y.1731/enl" target="_blank">http://www.itu.int/rec/T-REC-Y.1731/enl</a> <a href="#fnref:28" class="footnote-back-ref">↩</a></li>
<li id="fn:29">"802.1aq - Shortest Path Bridging". Retrieved 20 July 2011. <a href="http://www.ieee802.org/1/pages/802.1aq.html" target="_blank">http://www.ieee802.org/1/pages/802.1aq.html</a> <a href="#fnref:29" class="footnote-back-ref">↩</a></li>
<li id="fn:30">Ashwood-Smith, Peter; Keesara, Srikanth. "Brief Update on 802.1aq SPB (M) First Interop" (PDF). Retrieved 20 July 2011. <a href="http://www.ieee802.org/1/files/public/docs2010/aq-ashwood-interop1-1110-v02.pdf" target="_blank">http://www.ieee802.org/1/files/public/docs2010/aq-ashwood-interop1-1110-v02.pdf</a> <a href="#fnref:30" class="footnote-back-ref">↩</a></li>
<li id="fn:31">Ashwood-Smith, Peter; Vargas, Edgard. "Brief Update on 802.1aq SPB (M) Third Interop" (PDF). Retrieved 20 July 2011. <a href="http://ieee802.org/1/files/public/docs2011/aq-ashwood-smith-spbm-3rd-interop-0718-v01.pdf" target="_blank">http://ieee802.org/1/files/public/docs2011/aq-ashwood-smith-spbm-3rd-interop-0718-v01.pdf</a> <a href="#fnref:31" class="footnote-back-ref">↩</a></li>
<li id="fn:32">Kline, Deb (1 May 2013). "Networking Industry Leaders to Showcase Shortest Path Bridging Interoperability at Interop 2013". Avaya. Retrieved 1 February 2015. <a href="https://www.avaya.com/usa/about-avaya/newsroom/news-releases/2013/pr-130501?mobile=true" target="_blank">https://www.avaya.com/usa/about-avaya/newsroom/news-releases/2013/pr-130501?mobile=true</a> <a href="#fnref:32" class="footnote-back-ref">↩</a></li>
<li id="fn:33">Smith, Sue (7 May 2013). "Interop: Networking Leaders Demo Shortest Path Bridging". NewsFactor Network. Archived from the original on 29 June 2013. Retrieved 1 February 2015. <a href="https://archive.today/20130629235956/http://www.newsfactor.com/news//story.xhtml?story_id=0210025H8IFX" target="_blank">https://archive.today/20130629235956/http://www.newsfactor.com/news//story.xhtml?story_id=0210025H8IFX</a> <a href="#fnref:33" class="footnote-back-ref">↩</a></li>
<li id="fn:34">Borivoje Furht; Armando Escalante (2011). Handbook of Data Intensive Computing. Springer. p. 16. ISBN 978-1-4614-1415-5. <a href="978-1-4614-1415-5" target="_blank">978-1-4614-1415-5</a> <a href="#fnref:34" class="footnote-back-ref">↩</a></li>
<li id="fn:35">Roger Lapuh; Paul Unbehagen; Peter Ashwood-Smith; Phillip Taylor (23 March 2012). "SPB Deployment Considerations". Ietf Datatracker. IETF. Retrieved 29 May 2012. <a href="http://tools.ietf.org/id/draft-lapuh-spb-deployment-01.txt" target="_blank">http://tools.ietf.org/id/draft-lapuh-spb-deployment-01.txt</a> <a href="#fnref:35" class="footnote-back-ref">↩</a></li>
<li id="fn:36">"Interop: Networking Leaders Demo Shortest Path Bridging". May 2013. Archived from the original on 2 December 2013. Retrieved 30 May 2013. <a href="https://web.archive.org/web/20131202234031/http://www.newsfactor.com/news/Interop-Debuts-Shortest-Path-Bridging/story.xhtml?story_id=13100006UU9N&full_skip=1" target="_blank">https://web.archive.org/web/20131202234031/http://www.newsfactor.com/news/Interop-Debuts-Shortest-Path-Bridging/story.xhtml?story_id=13100006UU9N&full_skip=1</a> <a href="#fnref:36" class="footnote-back-ref">↩</a></li>
<li id="fn:37">Sean Michael Kerner (7 April 2014). "InteropNet Goes IPv6, Includes Shortest Path Bridging". Enterprise Networking Planet. Archived from the original on 19 April 2014. Retrieved 18 April 2014. <a href="https://web.archive.org/web/20140419133601/http://www.enterprisenetworkingplanet.com/datacenter/interopnet-goes-ipv6-includes-shortest-path-bridging-video.html" target="_blank">https://web.archive.org/web/20140419133601/http://www.enterprisenetworkingplanet.com/datacenter/interopnet-goes-ipv6-includes-shortest-path-bridging-video.html</a> <a href="#fnref:37" class="footnote-back-ref">↩</a></li>
<li id="fn:38">"Avaya Networking Solutions Close the Gap between Data Center and End Devices". Avaya Inc. 26 March 2014. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140326" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140326</a> <a href="#fnref:38" class="footnote-back-ref">↩</a></li>
<li id="fn:39">"Avaya Fabric Connect extends SPB to wiring closets". 8 April 2014. Archived from the original on 14 August 2014. Retrieved 14 August 2014. <a href="https://web.archive.org/web/20140814193130/http://searchnetworking.techtarget.com/news/2240217811/Avaya-Fabric-Connect-extends-SPB-to-wiring-closets" target="_blank">https://web.archive.org/web/20140814193130/http://searchnetworking.techtarget.com/news/2240217811/Avaya-Fabric-Connect-extends-SPB-to-wiring-closets</a> <a href="#fnref:39" class="footnote-back-ref">↩</a></li>
<li id="fn:40">"Avaya – Considerations for Turning your Network into an Ethernet Fabric". Packet Pushers. 18 February 2013. <a href="http://packetpushers.net/show-136-avaya-considerations-for-turning-your-network-into-an-ethernet-fabric-sponsored/" target="_blank">http://packetpushers.net/show-136-avaya-considerations-for-turning-your-network-into-an-ethernet-fabric-sponsored/</a> <a href="#fnref:40" class="footnote-back-ref">↩</a></li>
<li id="fn:41">"Network Downtime Results in Job, Revenue Loss". Avaya Inc. 5 March 2014. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140305_void" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140305_void</a> <a href="#fnref:41" class="footnote-back-ref">↩</a></li>
<li id="fn:42">"Macquarie University Delivers Enhanced Student Collaboration and Services with Avaya Networking Solutions". Avaya Inc. 8 November 2012. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2012/pr-121108" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2012/pr-121108</a> <a href="#fnref:42" class="footnote-back-ref">↩</a></li>
<li id="fn:43">"Texas School District Embraces Avaya Networking Infrastructure to Enable 21st-Century Learning Models" (PDF). Avaya Inc. May 2014. <a href="http://www.avaya.com/usa/documents/pearland-isd-avaya-case-study-dn7523av-final-2014-5-7.pdf" target="_blank">http://www.avaya.com/usa/documents/pearland-isd-avaya-case-study-dn7523av-final-2014-5-7.pdf</a> <a href="#fnref:43" class="footnote-back-ref">↩</a></li>
<li id="fn:44">"Avaya's Fabric Connect solution helps University transition to next-generation technology-enabled learning methods". Avaya Inc. May 2013. <a href="http://www.avaya.com/emea/case-for-avaya/customer-stories/ajman-university-of-science-and-technology" target="_blank">http://www.avaya.com/emea/case-for-avaya/customer-stories/ajman-university-of-science-and-technology</a> <a href="#fnref:44" class="footnote-back-ref">↩</a></li>
<li id="fn:45">"Avaya Network Powers New Luggage Handling System at Schiphol Airport". Avaya Inc. 25 April 2012. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2012/pr-120425" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2012/pr-120425</a> <a href="#fnref:45" class="footnote-back-ref">↩</a></li>
<li id="fn:46">"Transport company gets data communications moving" (PDF). Avaya Inc. October 2013. <a href="http://www.avaya.com/uk/documents/rheinbahn_ag.pdf" target="_blank">http://www.avaya.com/uk/documents/rheinbahn_ag.pdf</a> <a href="#fnref:46" class="footnote-back-ref">↩</a></li>
<li id="fn:47">"Transportation Bureau Sendai City Enhancing the passenger experience" (PDF). Avaya Inc. July 2014. <a href="http://www.avaya.com/usa/documents/sendai-city.pdf" target="_blank">http://www.avaya.com/usa/documents/sendai-city.pdf</a> <a href="#fnref:47" class="footnote-back-ref">↩</a></li>
<li id="fn:48">"Rapid Transit" (PDF). Avaya Inc. June 2014. <a href="http://www.avaya.com/uk/documents/dn7558uk.pdf" target="_blank">http://www.avaya.com/uk/documents/dn7558uk.pdf</a> <a href="#fnref:48" class="footnote-back-ref">↩</a></li>
<li id="fn:49">"Avaya Announces Software-Defined Data Center Framework and Roadmap". Avaya Inc. 21 August 2013. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2013/pr-130821" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2013/pr-130821</a> <a href="#fnref:49" class="footnote-back-ref">↩</a></li>
<li id="fn:50">"Sparebanken Vest Banks on Avaya for Future-Proofed Network Infrastructure Upgrade". Avaya Inc. 8 May 2012. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2012/pr-120508a" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2012/pr-120508a</a> <a href="#fnref:50" class="footnote-back-ref">↩</a></li>
<li id="fn:51">"InteropNet 2013: Unbreakable! Avaya Fabric Connect Delivers on All Fronts". Avaya Inc. 15 May 2013. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2013/pr-130515" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2013/pr-130515</a> <a href="#fnref:51" class="footnote-back-ref">↩</a></li>
<li id="fn:52">Owen, David (30 November 2011). "US firm Avaya named as Sochi 2014 network equipment supplier". Inside the Games. <a href="http://www.insidethegames.biz/olympics/winter-olympics/2014/15030-us-firm-avaya-named-as-sochi-2014-network-equipment-supplier" target="_blank">http://www.insidethegames.biz/olympics/winter-olympics/2014/15030-us-firm-avaya-named-as-sochi-2014-network-equipment-supplier</a> <a href="#fnref:52" class="footnote-back-ref">↩</a></li>
<li id="fn:53">"Dubai World Trade Centre to deploy conferencing solution based on Avaya's Virtual Enterprise Network Architecture". TCM. 23 October 2013. Archived from the original on 22 May 2014. Retrieved 7 November 2013. <a href="https://web.archive.org/web/20140522105836/http://techchannelmea.com/techchannelmea/new-products/enterprise/dubai-world-trade-centre-to-deploy-conferencing-solution-based-on-avayas-virtual-enterprise-network-architecture.htm" target="_blank">https://web.archive.org/web/20140522105836/http://techchannelmea.com/techchannelmea/new-products/enterprise/dubai-world-trade-centre-to-deploy-conferencing-solution-based-on-avayas-virtual-enterprise-network-architecture.htm</a> <a href="#fnref:53" class="footnote-back-ref">↩</a></li>
<li id="fn:54">"Perfectly provisioned" (PDF). Avaya Inc. July 2014. <a href="http://www.avaya.com/usa/documents/dwtc-fabric-connect-case-study.pdf" target="_blank">http://www.avaya.com/usa/documents/dwtc-fabric-connect-case-study.pdf</a> <a href="#fnref:54" class="footnote-back-ref">↩</a></li>
<li id="fn:55">"Avaya Networking Transforms Oslo University Hospital Network". Avaya Inc. 8 May 2012. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2012/pr-120508c" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2012/pr-120508c</a> <a href="#fnref:55" class="footnote-back-ref">↩</a></li>
<li id="fn:56">"Avaya Networking Transforms Oslo University Hospital Network". Firmenpresse. 8 May 2012. <a href="http://www.firmenpresse.de/pressrelease143827.html" target="_blank">http://www.firmenpresse.de/pressrelease143827.html</a> <a href="#fnref:56" class="footnote-back-ref">↩</a></li>
<li id="fn:57">"Concord Hospital Boosts Bandwidth and Reduces Costs with Avaya's Virtual Enterprise Network Architecture Solutions". Avaya Inc. 8 May 2012. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2012/pr-120508d" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2012/pr-120508d</a> <a href="#fnref:57" class="footnote-back-ref">↩</a></li>
<li id="fn:58">"Franciscan Alliance & Fabric Connect: Redefining the Delivery of Healthcare Services" (PDF). Avaya Inc. May 2013. <a href="http://www.avaya.com/usa/resource/assets/casestudies/Franciscan_Alliance_Case_Study.pdf" target="_blank">http://www.avaya.com/usa/resource/assets/casestudies/Franciscan_Alliance_Case_Study.pdf</a> <a href="#fnref:58" class="footnote-back-ref">↩</a></li>
<li id="fn:59">"Strong, Stable Network Underpins Sydney Adventist Hospital" (PDF). Avaya Inc. May 2012. <a href="http://www.avaya.com/usa/resource/assets/casestudies/Sydney_Adventist_Hospital_Case_Study.pdf" target="_blank">http://www.avaya.com/usa/resource/assets/casestudies/Sydney_Adventist_Hospital_Case_Study.pdf</a> <a href="#fnref:59" class="footnote-back-ref">↩</a></li>
<li id="fn:60">"Avaya Extends the Automated Campus to End the Network Waiting Game". Avaya Inc. 1 April 2014. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140401" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140401</a> <a href="#fnref:60" class="footnote-back-ref">↩</a></li>
<li id="fn:61">"Avaya Networking Solutions Close the Gap between Data Center and End Devices". Avaya Inc. 26 March 2014. <a href="http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140326" target="_blank">http://www.avaya.com/usa/about-avaya/newsroom/news-releases/2014/pr-140326</a> <a href="#fnref:61" class="footnote-back-ref">↩</a></li>
<li id="fn:62">"Good news for data communication". Avaya 2014. May 2014. <a href="https://sales.avaya.com/documents/1399552195109" target="_blank">https://sales.avaya.com/documents/1399552195109</a> <a href="#fnref:62" class="footnote-back-ref">↩</a></li>
<li id="fn:63">"Enabling Sanlih Entertainment Television New Digital Broadcasting System" (PDF). Avaya Inc. June 2012. <a href="http://www.avaya.com/apac/resource/assets/casestudies/casestudy_CA4_20120620_EN.pdf" target="_blank">http://www.avaya.com/apac/resource/assets/casestudies/casestudy_CA4_20120620_EN.pdf</a> <a href="#fnref:63" class="footnote-back-ref">↩</a></li>
<li id="fn:64">"Coastal Californian Community Deploys Avaya Network to Enable Mission-Critical Applications" (PDF). Avaya Inc. June 2014. <a href="http://www.avaya.com/usa/documents/redondobeachcfa.pdf" target="_blank">http://www.avaya.com/usa/documents/redondobeachcfa.pdf</a> <a href="#fnref:64" class="footnote-back-ref">↩</a></li>
<li id="fn:65">"Breda City Council looks forward to a more agile future with Avaya VENA Fabric Connect". Avaya Inc. December 2013. <a href="http://www.avaya.com/emea/case-for-avaya/customer-stories/city-of-breda" target="_blank">http://www.avaya.com/emea/case-for-avaya/customer-stories/city-of-breda</a> <a href="#fnref:65" class="footnote-back-ref">↩</a></li>
<li id="fn:66">"On their own initiative forward-looking". Avaya Inc. February 2014. <a href="https://sales.avaya.com/documents/1399552195850" target="_blank">https://sales.avaya.com/documents/1399552195850</a> <a href="#fnref:66" class="footnote-back-ref">↩</a></li>
<li id="fn:67">"Alcatel-Lucent OmniSwitch 9900 Datasheet EN" (PDF). <a href="https://www.al-enterprise.com/-/media/assets/internet/documents/omniswitch-9900-modular-lan-chassis-datasheet-en.pdf" target="_blank">https://www.al-enterprise.com/-/media/assets/internet/documents/omniswitch-9900-modular-lan-chassis-datasheet-en.pdf</a> <a href="#fnref:67" class="footnote-back-ref">↩</a></li>
<li id="fn:68">"Alcatel-Lucent OmniSwitch 6900 DataSheet EN" (PDF). Retrieved 7 January 2013. <a href="https://www.al-enterprise.com/-/media/assets/internet/documents/omniswitch-6900-stackable-lan-switches-datasheet-en.pdf" target="_blank">https://www.al-enterprise.com/-/media/assets/internet/documents/omniswitch-6900-stackable-lan-switches-datasheet-en.pdf</a> <a href="#fnref:68" class="footnote-back-ref">↩</a></li>
<li id="fn:69">"Alcatel-Lucent OmniSwitch 6860 Data Sheet EN" (PDF). <a href="https://www.al-enterprise.com/-/media/assets/internet/documents/omniswitch-6860-datasheet-en.pdf" target="_blank">https://www.al-enterprise.com/-/media/assets/internet/documents/omniswitch-6860-datasheet-en.pdf</a> <a href="#fnref:69" class="footnote-back-ref">↩</a></li>
<li id="fn:70">"Alcatel-Lucent OmniSwitch 6865 Data Sheet EN" (PDF). <a href="https://www.al-enterprise.com/-/media/assets/internet/documents/omniswitch-6865-datasheet-en.pdf" target="_blank">https://www.al-enterprise.com/-/media/assets/internet/documents/omniswitch-6865-datasheet-en.pdf</a> <a href="#fnref:70" class="footnote-back-ref">↩</a></li>
<li id="fn:71">"Avaya rolls out networking blueprint for data centre". 11 November 2010. Archived from the original on 16 December 2010. Retrieved 20 July 2011. <a href="https://web.archive.org/web/20101216050519/http://ciol.com/Technology/Networking/Products/Avaya-rolls-out-networking-blueprint-for-data-centre/143333/0/" target="_blank">https://web.archive.org/web/20101216050519/http://ciol.com/Technology/Networking/Products/Avaya-rolls-out-networking-blueprint-for-data-centre/143333/0/</a> <a href="#fnref:71" class="footnote-back-ref">↩</a></li>
<li id="fn:72">"Avaya Virtual Service Platform 7000 Switch Delivers Real Performance". 4 May 2011. Archived from the original on 13 December 2011. Retrieved 20 July 2011. The VSP is a 10 GbE top-of-rack switch that supports Shortest Path Bridging (SPB), Edge Virtual Bridging (EVB), and Fiber Channel over Ethernet (FCoE) networking standards. <a href="https://web.archive.org/web/20111213000138/http://www.enterprisenetworkingplanet.com/nethub/article.php/3932526/Avaya-Virtual-Service-Platform-7000-Switch-Delivers-Real-Performance.htm" target="_blank">https://web.archive.org/web/20111213000138/http://www.enterprisenetworkingplanet.com/nethub/article.php/3932526/Avaya-Virtual-Service-Platform-7000-Switch-Delivers-Real-Performance.htm</a> <a href="#fnref:72" class="footnote-back-ref">↩</a></li>
<li id="fn:73">"Avaya aims to boost IP multicast methods with new network fabric". ZDNet. Retrieved 13 April 2013. <a href="https://www.zdnet.com/article/avaya-aims-to-boost-ip-multicast-methods-with-new-network-fabric/" target="_blank">https://www.zdnet.com/article/avaya-aims-to-boost-ip-multicast-methods-with-new-network-fabric/</a> <a href="#fnref:73" class="footnote-back-ref">↩</a></li>
<li id="fn:74">"Avaya Announces New Innovations in Fabric-Enabled Networking". Retrieved 17 April 2013. <a href="http://www.benzinga.com/pressreleases/13/04/w3504666/avaya-announces-new-innovations-in-fabric-enabled-networking" target="_blank">http://www.benzinga.com/pressreleases/13/04/w3504666/avaya-announces-new-innovations-in-fabric-enabled-networking</a> <a href="#fnref:74" class="footnote-back-ref">↩</a></li>
<li id="fn:75">"Avaya unveils new offerings for fabric-enabled networking". Retrieved 17 April 2013. <a href="http://www.telecompaper.com/news/avaya-unveils-new-offerings-for-fabric-enabled-networking--938001" target="_blank">http://www.telecompaper.com/news/avaya-unveils-new-offerings-for-fabric-enabled-networking--938001</a> <a href="#fnref:75" class="footnote-back-ref">↩</a></li>
<li id="fn:76">"Avaya's new network fabric supports tens of thousands of video streams for IP multicasting". Archived from the original on 21 April 2013. Retrieved 18 April 2013. <a href="https://web.archive.org/web/20130421053358/http://www.fierceenterprisecommunications.com/story/avayas-new-network-fabric-supports-tens-thousands-video-streams-ip-multicas/2013-04-18" target="_blank">https://web.archive.org/web/20130421053358/http://www.fierceenterprisecommunications.com/story/avayas-new-network-fabric-supports-tens-thousands-video-streams-ip-multicas/2013-04-18</a> <a href="#fnref:76" class="footnote-back-ref">↩</a></li>
<li id="fn:77">"Virtual Services Platform 4000". Avaya. <a href="https://support.avaya.com/products/P1440/virtual-services-platform-4000-series" target="_blank">https://support.avaya.com/products/P1440/virtual-services-platform-4000-series</a> <a href="#fnref:77" class="footnote-back-ref">↩</a></li>
<li id="fn:78">"Avaya Networking Solutions Close the Gap between Data Centre and End Devices". SDN Zone. Archived from the original on 14 July 2014. Retrieved 26 March 2014. <a href="https://web.archive.org/web/20140714183521/http://www.sdnzone.com/news/2014/03/26/7745585.htm" target="_blank">https://web.archive.org/web/20140714183521/http://www.sdnzone.com/news/2014/03/26/7745585.htm</a> <a href="#fnref:78" class="footnote-back-ref">↩</a></li>
<li id="fn:79">Duffy, Jim. "Enterasys enhances data center offerings". Network World. Archived from the original on 2 March 2014. <a href="https://web.archive.org/web/20140302181237/http://www.networkworld.com/news/2013/061813-enterasys-270953.html" target="_blank">https://web.archive.org/web/20140302181237/http://www.networkworld.com/news/2013/061813-enterasys-270953.html</a> <a href="#fnref:79" class="footnote-back-ref">↩</a></li>
<li id="fn:80">McGillicuddy, Shamus "Shortest Path Bridging: The interoperable alternate to spanning tree", Alcatel-Lucent and Huawei also support SPB and Enterasys Networks has SPB in its roadmap <a href="#fnref:80" class="footnote-back-ref">↩</a></li>
<li id="fn:81">unknown (9 May 2012). "Shortest Not all Unified Network Architectures are really so simple". Archived from the original on 14 June 2013. Retrieved 5 May 2013. Shortest Path Bridging IEEE 802.1aq <a href="https://web.archive.org/web/20130614044104/http://blogs.enterasys.com/not-all-unified-network-architectures-are-really-so-simple/" target="_blank">https://web.archive.org/web/20130614044104/http://blogs.enterasys.com/not-all-unified-network-architectures-are-really-so-simple/</a> <a href="#fnref:81" class="footnote-back-ref">↩</a></li>
<li id="fn:82">"K-Series Firmware Version 8.62.02.0022" (PDF). Extreme Networks. March 2017. Retrieved 14 March 2017. <a href="http://documentation.extremenetworks.com/release_notes/EOS/9038887-01_K-Series_RelNote_FW0862020022.pdf" target="_blank">http://documentation.extremenetworks.com/release_notes/EOS/9038887-01_K-Series_RelNote_FW0862020022.pdf</a> <a href="#fnref:82" class="footnote-back-ref">↩</a></li>
<li id="fn:83">"Alcatel-Lucent, Avaya, Huawei, Solana and Spirent Showcase Shortest Path Bridging Interoperability". IT News Link. Archived from the original on 20 September 2012. Retrieved 13 May 2012. <a href="https://web.archive.org/web/20120920042648/http://itnewslink.com/article.php?id_article=13777" target="_blank">https://web.archive.org/web/20120920042648/http://itnewslink.com/article.php?id_article=13777</a> <a href="#fnref:83" class="footnote-back-ref">↩</a></li>
<li id="fn:84">"SPIRENT TESTCENTER SHORTEST PATH BRIDGING TEST PACKAGE". Spirent N. Retrieved 13 May 2012. <a href="https://www.spirent.com/~/media/Datasheets/Broadband/PAB/SpirentTestCenter/STC_Shortest_Path_Bridging_Test_Package_datasheet.ashx" target="_blank">https://www.spirent.com/~/media/Datasheets/Broadband/PAB/SpirentTestCenter/STC_Shortest_Path_Bridging_Test_Package_datasheet.ashx</a> <a href="#fnref:84" class="footnote-back-ref">↩</a></li>
<li id="fn:85">"HP FlexFabric 11900 Switch Series" (PDF). Archived from the original (PDF) on 5 November 2013. Retrieved 4 November 2013. <a href="https://web.archive.org/web/20131105073336/http://h17007.www1.hp.com/docs/interop/2013/4AA4-6497ENW.pdf" target="_blank">https://web.archive.org/web/20131105073336/http://h17007.www1.hp.com/docs/interop/2013/4AA4-6497ENW.pdf</a> <a href="#fnref:85" class="footnote-back-ref">↩</a></li>
<li id="fn:86">"HP Discover 2012". HP. Archived from the original on 14 July 2014. Retrieved 15 June 2012. <a href="https://web.archive.org/web/20140714150345/http://www.slideshare.net/HPenterprise/tb2377-michelet-trill-vs-spbfinal-13225366" target="_blank">https://web.archive.org/web/20140714150345/http://www.slideshare.net/HPenterprise/tb2377-michelet-trill-vs-spbfinal-13225366</a> <a href="#fnref:86" class="footnote-back-ref">↩</a></li>
<li id="fn:87">Kline, Deb (1 May 2013). "Networking Industry Leaders to Showcase Shortest Path Bridging Interoperability at Interop 2013". Avaya. Retrieved 1 February 2015. <a href="https://www.avaya.com/usa/about-avaya/newsroom/news-releases/2013/pr-130501?mobile=true" target="_blank">https://www.avaya.com/usa/about-avaya/newsroom/news-releases/2013/pr-130501?mobile=true</a> <a href="#fnref:87" class="footnote-back-ref">↩</a></li>
<li id="fn:88">"Shortest Path Bridging (SPB)". IP Infusion. Archived from the original on 17 September 2012. Retrieved 7 October 2012. <a href="https://web.archive.org/web/20120917102701/http://ipinfusion.com/products/zebos/protocols/data-center-ethernet/SPB" target="_blank">https://web.archive.org/web/20120917102701/http://ipinfusion.com/products/zebos/protocols/data-center-ethernet/SPB</a> <a href="#fnref:88" class="footnote-back-ref">↩</a></li>
<li id="fn:89">"IxNetwork: Specifications". IXIA. Archived from the original on 2 September 2013. Retrieved 25 July 2013. <a href="https://web.archive.org/web/20130902191127/http://www.ixiacom.com/products/network_test/applications/ixnetwork/specifications/index.php" target="_blank">https://web.archive.org/web/20130902191127/http://www.ixiacom.com/products/network_test/applications/ixnetwork/specifications/index.php</a> <a href="#fnref:89" class="footnote-back-ref">↩</a></li>
<li id="fn:90">"QT-600 Ethernet Probe". Rep Com International. JDSU. Archived from the original on 14 July 2014. Retrieved 26 August 2013. <a href="https://web.archive.org/web/20140714142410/http://www.repcom.com/qt-600-ethernet-probe/" target="_blank">https://web.archive.org/web/20140714142410/http://www.repcom.com/qt-600-ethernet-probe/</a> <a href="#fnref:90" class="footnote-back-ref">↩</a></li>
<li id="fn:91">Nnanna (5 February 2017). "8 Reasons To Choose Avaya Instead of Cisco for Your Data Network – NJ IT Support". BlueSodium. Archived from the original on 5 March 2017. Retrieved 5 March 2017. <a href="https://web.archive.org/web/20170305194823/http://www.bluesodium.com/blog/8-reasons-to-choose-avaya-instead-of-cisco-for-your-data-network/" target="_blank">https://web.archive.org/web/20170305194823/http://www.bluesodium.com/blog/8-reasons-to-choose-avaya-instead-of-cisco-for-your-data-network/</a> <a href="#fnref:91" class="footnote-back-ref">↩</a></li>
</ol>

IEEE 802.1aq open-in-new

IEEE 802.1aq