Network Working Group D. Fedyk, Ed.
Internet Draft Alcatel-Lucent
Intended status: Standards Track P. Ashwood-Smith, Ed.
Expires: May 2011 Huawei
November 29, 2010
IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging
draft-ietf-isis-ieee-aq-02.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 23 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Fedyk, et al. Expires May 28 2011 [Page 1]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
Abstract
802.1aq Shortest Path Bridging (SPB) is being standardized by the
IEEE as the next step in the evolution of the various spanning tree
and registration protocols. 802.1aq allows for true shortest path
forwarding in a mesh network context utilizing multiple equal cost
paths. This permits it to support much larger layer 2 topologies,
with faster convergence, and vastly improved use of the mesh
topology. Combined with this is single point provisioning for
logical connectivity membership (E-LINE/E-LAN/E-TREE etc).
The control protocol for 802.1aq is IS-IS [IS-IS] augmented with a
small number of TLVs while the encapsulating data paths are
respectively 802.1ad (Provider Bridges) [PB] and 802.1ah (Provider
Backbone Bridges) [PBB]. This memo documents those TLVs while
providing some overview.
Note that 802.1aq requires no state machine or other substantive
changes to [IS-IS]. It is our intention that 802.1aq be simply a new
NLPID and set of TLVs. In the event of any confusion the reader
should take [IS-IS] as authoritative.
Fedyk, et al. Expires May 28, 2011 [Page 2]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
Table of Contents
1. Introduction...................................................4
2. Terminology....................................................4
3. Conventions used in this document..............................5
4. 802.1aq Overview...............................................5
4.1. Data Path SPBM - Unicast..................................7
4.2. Data Path SPBM - Multicast (Head End Replication).........7
4.3. Data Path SPBM - Multicast (Tandem Replication)...........8
4.4. Data Path SPBV Broadcast..................................9
4.5. Data Path SPBV Unicast....................................9
4.6. Data Path SPBV Multicast.................................10
5. SPBM Example..................................................10
6. SPBV Example..................................................12
7. SPB Supported Adjacency types.................................14
8. SPB IS-IS adjacency addressing................................14
9. IS-IS Area Address and SYSID..................................15
10. Level 1/2 Adjacency..........................................15
11. Shortest Path Default Tie Breaking...........................15
12. Shortest Path ECT............................................16
13. Hello (IIH) protocol extensions..............................17
13.1. SPB MCID sub-TLV........................................18
13.2. SPB Digest sub-TLV......................................19
13.3. SPB Base VLAN-Identifiers sub-TLV.......................21
14. Node information extensions..................................22
14.1. SPB Instance sub-TLV....................................22
14.1.1. SPB Instance Opaque ECT-ALGORITHM sub-TLV..........25
15. Adjacency information extensions.............................26
15.1. SPB Link Metric sub-TLV.................................26
15.1.1. SPB Adjacency Opaque ECT-ALGORITHM sub-TLV.........27
16. Service information extensions...............................28
16.1. SPBM Service Identifier and Unicast Address sub-TLV.....28
16.2. SPBV Mac Address sub-TLV................................29
17. Security Considerations......................................31
18. IANA Considerations..........................................31
19. References...................................................32
19.1. Normative References....................................32
19.2. Informative References..................................32
20. Acknowledgments..............................................33
21. Author's Addresses...........................................33
22. Intellectual Property Statement..............................33
23. Disclaimer of Liability......................................34
Fedyk, et al. Expires May 28, 2011 [Page 3]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
1. Introduction
2. Terminology
In addition to well understood IS-IS terms, this memo uses
terminology from IEEE 802.1 and introduces a few new terms:
802.1ad Provider Bridging (PB), Q-in-Q encapsulation)
802.1ah Provider Backbone Bridges (PBB), MAC-IN-MAC
encapsulation
802.1aq Shortest Path Bridging (SPB)
Base-VID VID used to identify a VLAN in management operations
B-DA Backbone Destination Address 802.1ah PBB
B-MAC Backbone MAC Address
B-SA Backbone Source address in 802.1ah PBB header
B-VID Backbone VLAN ID in 802.1ah PBB header
B-VLAN Backbone Virtual LAN
BridgeID 64 bit quantity = Bridge Priority:16 o SYSID:48
BridgePriority 16 bit relative priority of a node for tie breaking
C-MAC Customer MAC. Inner MAC in 802.1ah PBB header
C-VID Customer VLAN ID
C-VLAN Customer Virtual LAN
DA Destination Address
ECT-ALGORITHM 32 bit unique id of an SPF tie breaking set of rules.
ECT-MASK 64 bit mask XORed with BridgeID during tie breaking.
E-LAN Bidirectional Logical Connectivity between >2 UNIs.
E-LINE Bidirectional Logical Connectivity between two UNIs.
E-TREE Asymmetric Logical Connectivity between UNIs.
FDB Filtering Information Base: {DA/VID}->{next hops}
I-SID Logical Grouping Identifier for E-LAN/LINE/TREE UNIs.
LSDB Link State Database
LSP Link State Packet
MAC-IN-MAC Ethernet in Ethernet framing as per 802.1ah[PBB]
MDT Multicast Distribution Tree
MT-ISIS Multi Topology IS-IS as used in [MT]
MT Multi Topology. As used in [MT]
MT-ID Multi Topology Identifier (12 bits). As used in [MT]
NLPID Network Layer Protocol Identifier: IEEE 802.1aq= 0xC1
Q-in-Q Additional S-VLAN after a C-VLAN (802.1ad)[PB]
PBB Provider Backbone Bridge - forwards using PBB
Ingress Check Source Forwarding Check - drops misdirected frames
(S,G) Source & Group - identity of a source specific tree
(*,G) Any Source & Group - identity of a shared tree
SA Source Address.
SPB Shortest Path Bridging - generally all of 802.1aq.
SPB Shortest Path Bridge - device implementing 802.1aq.
SPBM Device implementing SPB MAC mode
Fedyk, et al. Expires May 28, 2011 [Page 4]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
SPBV Device implementing SPB VID mode
SPT Shortest Path Tree computed by one ECT-ALORITHM
SPSourceID 20 bit identifier of the source of multicast frames.
SPVID SPBV: a C-VLAN or S-VLAN that identifies the source.
UNI User Network Interface: Customer to SPB attach point.
VID VLAN ID 12 bit logical identifier after MAC header.
3. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
4. 802.1aq Overview
802.1aq utilizes 802.1Q based Ethernet bridging. The filtering
database (FDB) is populated as a consequence of the forwarding
computed from the IS-IS database.
802.1aq supports multiple modes of operation depending on the type
of data plane and the desired behavior. For the initial two modes of
802.1aq (SPBV and SPBM), routes are shortest path, are forward and
reverse path symmetric with respect to any source / destination pair
within the SPB domain, and are congruent with respect to unicast and
multicast. Hence the shortest path tree (SPT) to a given node is
congruent with the multicast distribution tree (MDT) from a given
node. The MDT for a given VLAN is a pruned subset of the complete
MDT for a given node which is identical to its SPT. Symmetry and
congruency preserve packet ordering and proper fate sharing of OAM
flows by the forwarding path. Such modes are fully supported by
existing 802.1ag and Y.1731 OA&M mechanisms.
VLANs provide a natural delineation of service instances. 802.1aq
supports two modes, SPB VID (SPBV) and SPB MAC (SPBM). In SPBV
multiple VLANS can be used to distribute load on different shortest
path trees (each computed by a different tie breaking rule) on a
service basis. In SPBM service instances are delineated by I-SIDs
but VLANs again can be used to distribute load on different shortest
path trees.
There are two encapsulation methods supported. SPBM can be used in a
PBB network implementing PBB (802.1ah [PBB]) encapsulation. SPBV can
be used in PB networks implementing VLANs, PB (802.1aq [PB]) or PBB
encapsulation. The two modes can co-exist simultaneously in an SPB
network.
Fedyk, et al. Expires May 28, 2011 [Page 5]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
The practical design goals for SPBV and SPBM in the current 802.1aq
specification are networks of size 100 nodes and 1000 nodes
respectively. However since SPBV can be sparsely used in an SPB
Region it can simply span a large SPB region with a small number of
SPVIDs.
In SPBM and SPBV each bridge has at least one unique "known" MAC
address which is advertised by IS-IS in the SYS-ID.
In the forwarding plane, SPBM uses the combination of one or more B-
VIDs and "known" Backbone-MAC (B-MAC) addresses that have been
advertised in IS-IS. The term Backbone simply implies an
encapsulation that is often used in the backbone networks, but the
encapsulation is useful in other types of networks where hiding C-
MACs is useful.
The SPBM filtering database (FDB) is computed and installed for
unicast and multicast MAC addresses, while the SPBV filtering
database is computed and installed for unidirectional VLAN-IDs
(referred to as SPVIDs), while MAC filtering is learned for unicast.
Both SPBV and SPBM use source specific multicast trees. If they
share the same ECT-ALGORITHM (32 bit world wide unique definition of
the computation) the tree is the same SPT. For SPBV (S,G) is encoded
by a source-specific S-VLAN (the SPVID) and a standard Group MAC
address. For SPBM (S,G) is encoded in the destination B-MAC address
as the concatenation of a 20 bit SPB wide unique nodal nickname
(referred to as the SPSourceID) and the 24 bit I-SID together with
the B-VLAN which corresponds to the ECT-ALGORITHM network wide.
802.1aq supports membership attributes which are advertised with the
I-SID (SPBM) or Group Address (SPBV) that define the group.
Individual members can be transmitters (T) and/or receivers (R)
within the group and the multicast state is appropriately sized to
these requests. Multicast group membership is possible even without
transmit membership by performing head end replication to the
receivers thereby eliminating transit multicast state entirely.
Some highly connected mesh networks provide for path diversity by
offering multiple equal cost alternatives between nodes. Since
congruency and symmetry must be honored, a single tree may leave
some links under utilized. By using different deterministic tie
breakers, up to sixteen shortest paths of arbitrary diversity are
possible between any pair of nodes. This distributes the traffic on
a VLAN basis. SPBV and SPBM may share a single SPT with a single
ECT-ALGORITHM or use any combination of the 16 ECT-ALGORITHMs. An
extensible framework permits additional or alternative algorithms
Fedyk, et al. Expires May 28, 2011 [Page 6]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
with other properties and parameters (eg ECMP, (*,G) ) to also be
supported without any changes in this or the IEEE documents.
4.1. Data Path SPBM - Unicast
Unicast frames in SPBM are encapsulated as per 802.1ah [PBB]. A
Backbone Source Address (B-SA), Backbone Destination Address (B-DA),
Backbone VLAN ID (B-VID) and an I-Component Service Instance ID (I-
TAG) are used to encapsulate the Ethernet frame. The B-SA is a B-MAC
associated with the ingress 802.1aq bridge, usually the "known" B-
MAC of that entire bridge. The B-DA is one of the "known" B-MACs
associated with the egress 802.1aq bridge. The B-VID and I-TAG are
mapped based on the physical or logical UNI port (untagged, or
tagged either by S-TAG or C-TAG) being bridged. Normal learning and
broadcast to unknown C-MACs is applied as per [PBB] at the
ingress/egress SPBs only.
Unlike [PBB] on a (*,G) tree, the B-DA forwarding on tandem nodes
(NNI to NNI) is performed without learning. Instead the output of
802.1aq computations, based on the TLVs specified in this document,
are used to populate the Filtering Data Bases (FDB). The FDB entries
map {B-DA, B-VID} to an outgoing interface and are only populated
from the IS-IS database and computations.
The B-SA/B-VID is checked on tandem nodes against the ingress port.
If the B-SA/B-VID (as a destination) entry in the FDB does not point
to the port on which the packet arrived the packet is discarded.
This is referred to as an Ingress Check and serves as a very
powerful loop mitigation mechanism.
4.2. Data Path SPBM - Multicast (Head End Replication)
Head end replication is supported for instances where there is a
sparse community of interest or a low likelihood of multicast
traffic. Head end replication requires no Multicast state in the
core. A UNI port wishing to use head end replication MUST NOT
advertise its I-SID membership with the TX bit set but instead must
locally and dynamically construct the appropriate unicast serial
replication to all the other receivers (RX) of the same I-SID.
When an unknown customer unicast or a multicast frame arrives at an
SPBM User to Network Interface (UNI) port which has been configured
to replicate only at the head end the packet is replicated once for
each receiver, encapsulated and sent as a unicast frame. The set of
receivers is determined by inspecting the IS-IS database for other
SPBs that have registered interest in the same I-SID with the RX
(receive) attribute set. This RX/I-SID pair is found in the SPBM
Fedyk, et al. Expires May 28, 2011 [Page 7]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
Service Identifier and Unicast Address sub-TLV. The packets are
encapsulated as per the SPBM Unicast forwarding above.
4.3. Data Path SPBM - Multicast (Tandem Replication)
Tandem replication uses the Shortest path Tree to replicate Frames
only where the tree forks and there is at least one receiver on each
branch. Tandem replication is bandwidth efficient but uses multicast
FDB entries (state) in core bridges which might be unnecessary if
there is little multicast traffic demand. The head end replication
mode is best suited for the case where there is little or no true
multicast traffic for an I-SID. Tandem replication is triggered on
transit nodes when the I-SID is advertised with the TX bit set.
Broadcast, unknown unicast or multicast frames arriving at an SPBM
UNI port are encapsulated with a B-DA multicast address which
uniquely identifies the encapsulating node (the root of the
Multicast Distribution Tree) and the I-SID scoping this multicast.
This B-DA address is a well formed multicast group address (as per
802.1Q and 802.1ah) which concatenates the SPSourceID A' with the I-
SID M (written as DA=<A',M> and uniquely identifying the (S,G)
tree). This exact format is given in Figure 1 below:
SPSRC TYP L M
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|[16:19]|0|0|1|1| SPSRC [8:15] | SPSRC [0:7] | ISID [16:23] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ISID [8:15] | ISID [0:7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 SPBM Multicast Address format
o M is the multicast bit- always set to 1 for a multicast DA.
o L is the local bit- always set to 1 for a SPBM constructed
multicast DA.
o TYP is the SPSourceID type. Two values are supported. 00 for
statically assigned SPSourceID's and 01 for dynamic assignment.
o SPSRC (SPSourceID) is a 20 bit quantity that uniquely identifies
a SPBM node for all B-VIDs allocated to SPBM operation. This is
just the SPSourceID advertised in the SPB Instance sub-TLV.
Fedyk, et al. Expires May 28, 2011 [Page 8]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
o I-SID is the 24 bit I component Service ID advertised in the SPBM
Service Identifier TLV. It occupies the lower 24 bits of the SPBM
multicast DA. The I-SID value 0xfff is reserved for SPBM control
traffic(refer to the default I-SID in [802.1aq]).
This multicast address format is used as the DA on frames when they
are first encapsulated at ingress to the SPBM network. The DA is
also installed into the FDBs on all SPBM nodes that are on the
corresponding SPT between the source and other nodes that have
registered receiver interest in the same I-SID.
Just as with unicast forwarding, the B-SA/B-VID may be used to
perform an ingress check, but the SPSourceID encoded in the DA and
the "drop-on-unknown" functionality of the FDB in [PBB] achieve the
same effect.
The I-Component at the egress SPBM device has completely standard
[PBB] behavior and therefore will:
1) learn the remote C-SA to B-SA relationship and
2) bridge the original customer frame to the set of local UNI ports
that are associated with the I-SID.
4.4. Data Path SPBV Broadcast
When a packet for an unknown DA arrives at a SPBV UNI port VID
translation (or VID encapsulation for un-tagged Frames) with the
corresponding SPVID for this VLAN and ingress SPB is performed.
SPVID forwarding is simply an SPT that follows normal VLAN
forwarding behavior, with the exception that the SPVID is
unidirectional. As a result shared learning (SVL) is used between
the forward and reverse path SPVIDs associated with the same Base
VID to allow SPBV unicast forwarding to operate in the normal
reverse learning fashion.
Ingress check is done by simply verifying that the bridge to which
the SPVID has been assigned is indeed "shortest path" reachable over
the link over which the packet tagged with that SPVID arrived. This
check is computed from the IS-IS database and is implied when the
SPVID is associated with a specific incoming port.
4.5. Data Path SPBV Unicast
Conversely when a packet for a known DA arrives at a SPBV UNI port
VID translation (or VID encapsulation for un-tagged Frames) with the
corresponding SPVID for this VLAN and ingress SPB is performed.
Fedyk, et al. Expires May 28, 2011 [Page 9]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
Since the SPVID will have been configured to follow a source
specific SPT and the DA is known the packet will follow the source
specific path towards the destination C-MAC.
Ingress check is as per the previous SPBV section.
4.6. Data Path SPBV Multicast
C-DA multicast addresses may be advertised from SPBV UNI ports.
These may be configured or learned through MMRP. The MMRP protocol
is terminated at the edge of the SPBV network and IS-IS carries the
multicast addresses. Tandem SPBV devices will check to see if they
are on the SPF tree between SPBV UNI ports advertising the same C-DA
multicast address, and if so will install multicast state to follow
the SPBV SPF trees.
Ingress check is as per the previous two SPBV sections.
5. SPBM Example
Consider the following small example network shown in Figure 2.
Nodes are drawn in boxes with the last nibble of their B-MAC address
:1..:7, the rest of the B-MAC address nibbles are 4455-6677-00xx.
Links are drawn as -- and / while the interface indexes are drawn as
numbers next to the links. UNI ports are shown as <==> with the
desired I-SID show at the end of the UNI ports as i1.
+----+ +----+
| :4 | 2 ------1 | :5 | <==> i1
+----+ +----+
1 3 3 2
/ \ / \
1 4 3 2
+----+ +----+ +----+
i1 <==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> i1
+----+ +----+ +----+
3 6 5 3
\ / \ /
3 2 1 2
+----+ +----+
| :6 | 1-------3 | :7 | <==> i1
+----+ +----+
Figure 2 - SPBM Example 7 node network
Using the default ECT-ALGORITHM (00-80-C2-01), which picks the equal
cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned
Fedyk, et al. Expires May 28, 2011 [Page 10]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
to B-VID 100. When all links have the same cost, then the 1 hop
shortest paths are all direct and the 2 hop shortest paths (which
are of course symmetric) are as follows:
{ 1-2-3, 1-2-5, 1-2-7, 6-2-5,
4-2-7, 4-1-6, 5-2-7, 6-2-3, 4-2-3 }
Node :1's Unicast forwarding table therefore routes toward B-MACs
:7, :3 and :5 via interface/2 while its single hop paths are all
direct as can be seen from its FDB given in Figure 3.
Node :1 originates multicast since it is at the head of the MDT to
nodes :3, :5 and :7 and is a transmitter of I-SID 1 which nodes :3,
:5 and :7 all wish to receive. Node :1 therefore produces a
multicast forwarding entry who's DA contains its SPSourceID (in the
example the last 20 bits of the B-MAC) and the I-SID 1 and sends to
interface 2 with B-VID=100. Node :1's full unicast(U) and
multicast(M) table is shown in Figure 3. Note that the IN/IF
(incoming interface) field is not specified for unicast traffic and
for multicast traffic has to point back to the root of the tree,
unless it is the head of the tree in which cast we use the
convention if/OO. Since Node :1 is not transit for any multicast it
only has a single entry for the root of its tree for I-SID=1.
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
U| if/** | 4455-6677-0002 | 0100 | {if/2 }
U| if/** | 4455-6677-0003 | 0100 | {if/2 }
U| if/** | 4455-6677-0004 | 0100 | {if/1 }
U| if/** | 4455-6677-0005 | 0100 | {if/2 }
U| if/** | 4455-6677-0006 | 0100 | {if/3 }
U| if/** | 4455-6677-0007 | 0100 | {if/2 }
M| if/00 | 7300-0100-0001 | 0100 | {if/2 }
Figure 3 - SPBM Node :1 FDB - Unicast(U) and Multicast(M)
Node :2, being at the center of the network, has direct 1 hop paths
to all other nodes, therefore its unicast FDB simply sends packets
with the given B-MAC/B-VID=100 to the interface directly to the
addressed node. This can be seen by looking at the unicast entries
(the first 6) shown in Figure 4.
Fedyk, et al. Expires May 28, 2011 [Page 11]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | BVID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
U| if/** | 4455-6677-0001 | 0100 | {if/1 }
U| if/** | 4455-6677-0003 | 0100 | {if/2 }
U| if/** | 4455-6677-0004 | 0100 | {if/4 }
U| if/** | 4455-6677-0005 | 0100 | {if/3 }
U| if/** | 4455-6677-0006 | 0100 | {if/6 }
U| if/** | 4455-6677-0007 | 0100 | {if/5 }
M| if/01 | 7300-0100-0001 | 0100 | {if/2,if/3,if/5 }
M| if/02 | 7300-0300-0001 | 0100 | {if/1 }
M| if/03 | 7300-0500-0001 | 0100 | {if/1,if/5 }
M| if/05 | 7300-0700-0001 | 0100 | {if/1,if/3 }
Figure 4 - SPBM Node :2 FDB Unicast(U) and Multicast(M)
Node :2's multicast is more complicated since it is a transit node
for the 4 members of I-SID=1, therefore it requires 4 multicast FDB
entries depending on which member it is forwarding/replicating on
behalf of. For example, node :2 is on the shortest path between each
of nodes {:3,:5,:7} and :1. So it must replicate from node :1 I-SID
1 out on interfaces 2, 3 and 5 (to reach nodes :3, :5 and :7). It
therefore creates a multicast DA with the SPSourceID of node :1
together with I-SID=1 which it expects to receive over interface/1
and will replicate out interfaces/{2, 3 and 5}. This can be seen in
the first multicast entry in Figure 4.
Note that node :2 is not on the shortest path between nodes :3 and
:5 nor between nodes :3 and :7, however it still has to forward
packets to node :1 from node :3 for this I-SID, which results in the
second multicast forwarding entry in Figure 4. Likewise for packets
originating at nodes 5 or 7, node :2 only has to replicate twice,
which results in the last two multicast forwarding entries in Figure
4.
6. SPBV Example
Using the same example network as Figure 2, we will look at the FDBs
produced for SPBV mode forwarding. Nodes :1, :5, :3 and :7 wish to
transmit and receive the same multicast MAC traffic using multicast
address 0300-0000-000f and at the same time require congruent and
symmetric unicast forwarding. In SPBV mode the only encapsulation is
the C or S-TAG and the MAC addresses SA,DA are reverse-path learned,
as in traditional bridging.
Fedyk, et al. Expires May 28, 2011 [Page 12]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
+----+ +----+
| :4 | 2 ------1 | :5 | <==> MMAC ..:f
+----+ +----+
1 3 3 2
/ \ / \
1 4 3 2
+----+ +----+ +----+
MMAC<==> | :1 | 2----1 | :2 | 2------1 | :3 | <==> MMAC ..:f
..:f +----+ +----+ +----+
3 6 5 3
\ / \ /
3 2 1 2
+----+ +----+
| :6 | 1-------3 | :7 | <==> MMAC ..:f
+----+ +----+
Figure 5 - SPBV Example 7 node network
Assuming the same ECT-ALGORITHM (00-80-C2-01), which picks the equal
cost path with the lowest BridgeID, this ECT-ALGORITHM is assigned
to Base Vid 100, and for each node the SPVID = Base Vid + Node Id
(i.e. 101, 102..107). When all links have the same cost, then the 1
hop shortest paths are all direct and the 2 hop shortest paths
(which are of course symmetric) are as previously given for Figure
2.
Node :1's SPT (Shortest Path Tree) for this ECT-ALGORITHM is
therefore (described as a sequence of unidirectional paths):
{ 1->4, 1->6, 1->2->3, 1->2->5, 1->2->7 }
The FDBs therefore must have entries for the SPVID reserved for
packets originating from node :1 which in this case is VID=101.
Node :2 therefore has a FDB which looks like Figure 6. In particular
it takes packets from VID 101 on interface/01 and sends to nodes :3,
:5 and :7 via if/2, if/3 and if/5. It does not replicate anywhere
else because the other nodes :4 and :6 are reached by the SPT
directly from node :1. The rest of the FDB unicast entries follow a
similar pattern; recall that the shortest path between :4 and :6 is
via node :1, which explains replication onto only two interfaces
from if/4 and if/6. Note that the destination addresses are wild
cards and shared VLAN learning (SVL) exists between these SPVIDs,
because they are all associated with BASE VID = 100, which defines
the VLAN being bridged.
Fedyk, et al. Expires May 28, 2011 [Page 13]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | VID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
U| if/01 | ************** | 0101 | {if/2,if/3,if/5 }
U| if/02 | ************** | 0103 | {if/1,if/4,if/6 }
U| if/04 | ************** | 0104 | {if/2,if/5 }
U| if/03 | ************** | 0105 | {if/1,if/5,if/6 }
U| if/06 | ************** | 0106 | {if/2,if/3 }
U| if/05 | ************** | 0107 | {if/1,if/3,if/4 }
Figure 6 - SPBV Node :2 FDB unicast
Now, since nodes :5, :3, :7 and :1 are advertising membership in the
same multicast group address :f, Node 2 requires additional entries
to replicate just to these specific nodes for the given multicast
group address. These additional multicast entries are given below in
Figure 7.
+-------+-------------------+------+-----------------+
| IN/IF | DESTINATION ADDR | VID | OUT/IF(s) |
+-------+-------------------+------+-----------------+
M| if/01 | 0300-0000-000f | 0101 | {if/2,if/3,if/5 }
M| if/02 | 0300-0000-000f | 0103 | {if/1 }
M| if/03 | 0300-0000-000f | 0105 | {if/1,if/5 }
M| if/05 | 0300-0000-000f | 0107 | {if/1,if/3 }
Figure 7 - SPBV Node :2 FDB Multicast(M)
7. SPB Supported Adjacency types
IS-IS for SPB currently only supports P2P adjacencies. Other link
types are for future study. As a result pseudonodes and links
to/from pseudonodes are not considered as part of the IS-IS SPF
computations and will be avoided if present in the physical
topology. Other NLPIDs may of course use them as per normal.
IS-IS for SPB MUST use the IS-IS Three-Way handshake for IS-IS
Point-to-Point Adjacencies described in RFC 5303.
8. SPB IS-IS adjacency addressing
The default behavior of 802.1aq is to use the normal IS-IS Ethernet
multicast addresses for IS-IS.
There are however additional Ethernet multicast addresses that have
been assigned for 802.1aq for special use cases. These do not in
Fedyk, et al. Expires May 28, 2011 [Page 14]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
anyway change the state machinery or packet formats of IS-IS but
simply recommend and reserve different multicast addresses. Refer to
[802.1aq] for additional details.
9. IS-IS Area Address and SYSID
A stand-alone implementation (supporting ONLY the single NLPID=0x1C)
of SPB MUST use an IS-IS area address value of 0 and the SYSID MUST
be the well known MAC address of the SPB device.
Non stand-alone implementations (supporting other NLPIDs) MUST use
the normal IS-IS rules for the establishment of a level 1 domain
(i.e. multiple area addresses are allowed but where immediate
adjaciencies share a common area address). Level 2 operations of
course place no such restriction on adjacent area addresses.
10. Level 1/2 Adjacency
SPBV and SPBM will operate either within an IS-IS level 1, or an
ISIS level 2. As a result the TLVs specified here may propagate
either in level 1 or level 2 LSPs. IS-IS SPB implementations MUST
support level 1 and MAY support level 2 operations. Hierarchical SPB
is for further study therefore these TLV's MUST NOT be leaked
between level 1 and level 2.
11. Shortest Path Default Tie Breaking
(ECT-ALGORITHM = 00-80-C2-01)
Two mechanisms are used to ensure symmetry and determinism in the
shortest path calculations.
The first mechanism addresses the problem when different ends
(nodes) of an adjacency advertise different values for the SPB-LINK-
METRIC. To solve this the SPB shortest path calculations MUST use
the maximum value of the two node's advertised SPB-LINK-METRICs when
accumulating and minimizing the (sub)path costs.
The second mechanism addresses the problem when two equal sum of
link metrics (sub)paths are found. To solve this the (sub)path with
the fewest hops between the fork/join points MUST win the tie.
However, if both (sub)paths have the same number of hops between the
fork and join points then the default tie breaking MUST pick the
path traversing the intermediate node with the lower BridgeID. The
BridgeID is an 8 byte quantity who's upper 2 bytes are the node's
BridgePriority and the lower 6 bytes are the node's SYSID.
Fedyk, et al. Expires May 28, 2011 [Page 15]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
For example, consider the network in Figure 2 when a shortest path
computation is being done from node :1. Upon reaching node :7 two
competing sub-paths fork at node :1 and join at node :7. The first
via :2 and the second via :6. Assuming that all the nodes advertise
a Bridge Priority of 0, the default tie breaking rule causes the
path traversing node :2 to be selected since it has a lower BridgeID
{0...:2} than node :6 {0...:6}. Note that the operator may cause the
tie breaking logic to pick the alternate path by raising the Bridge
Priority of node :2 above that of node :6.
The above algorithm guarantees symmetric and deterministic results
in addition to having the critical property of transitivity
(shortest path is made up of sub-shortest paths).
12. Shortest Path ECT
(ECT-ALGORITHMs = 00-80-C2-01 .. 00-80-C2-10)
To create diversity in routing SPB defines 16 variations on the
above default tie breaking algorithm, these have world wide unique
designations 00-80-C2-01 through 00-80-C2-10. These designations
consist of the IEEE 802.1 OUI value 00-80-C2 concatenated with
indexes 0X01..0X10. These individual algorithms are implemented by
selecting the (sub) path with the lowest value of:
XOR BYTE BY BYTE(ECT-MASK{ECT-ALGORITHM.index},BridgeID)
Where:
ECT-MASK{17} = { 0x00, 0x00, 0xFF, 0x88,
0x77, 0x44, 0x33, 0xCC,
0xBB, 0x22, 0x11, 0x66,
0x55, 0xAA, 0x99, 0xDD,
0xEE };
XOR BYTE BY BYTE - XORs BridgeID bytes with ECT-MASK
ECT-MASK{1} since it xor's with all 0's is just the same as the
default algorithm described above 00-80-C2-01, while ECT-MASK{0x02}
since it xor's with a mask of all 1's will invert the BridgeID
essentially picking the path traversing the largest Bridge ID. The
other ECT-MASKs produce diverse alternatives. In all cases the
BridgePriority, since it is the most significant part of the
BridgeID permits overriding the SYSID as the selection criteria and
gives the operator a degree of control on the chosen ECT paths.
Fedyk, et al. Expires May 28, 2011 [Page 16]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
To support many other tie breaking mechanisms in the future two
opaque ECT TLV's are defined which may be used to provide parameters
to ECT-ALGORITHMS outside of the currently defined space.
ECT-ALGORITHMS are mapped to VIDs and then services can be assigned
to those VIDs. This permits a degree of traffic engineering since
service assignment to VID is consistent end to end through the
network.
13. Hello (IIH) protocol extensions
IEEE 802.1aq can run in parallel with other Network Layer Protocols
such as IPV4 and IPV6, therefore failure for two SPB nodes to
establish an adjacency MUST NOT cause rejection of an adjacency for
the purposes of other Network Layer Protocols.
IEEE 802.1aq has been assigned the NLPID value 0xC1 [NLPID] which
MUST be used by shortest path bridges (SPBs) to indicate their
ability to run 802.1aq. This is done by including this NLPID value
in the IS-IS IIH PDU Protocols Supported TLV (type 129). 802.1aq
frames MUST only flow on adjacencies that advertise this NLPID in
both directions of the IIH PDUs. 802.1aq computations MUST consider
an adjacency that has not advertised 0xC1 NLPID in both directions
as non-existent (infinite link metric) and MUST ignore any SPB TLV's
they receive over such adjacencies.
IEEE 802.1aq augments the normal IIH PDU with three new TLV's which
like all other SPB TLVs travel within multi topology [MT] TLVs,
therefore allowing multiple logical instances of SPB within a single
IS-IS protocol instance.
Since SPB can use many VIDs and must agree on which VIDs are used
for which purposes, the IIH PDU's carry a digest of all the used
VIDs (on the NNI's) referred to as the SPB-MCID TLV which uses a
common and compact encoding taken reused from 802.1Q.
SPB neighbors MAY support an optional mechanism to verify that the
contents of their topology databases are synchronized (for the
purposes of loop prevention). This is done by exchanging a digest of
the topology information and taking specific actions on forwarding
entries when the digests indicate a mismatch in topology. This
digest is carried in the optional SPB Digest sub-TLV.
Finally SPB needs to know which SPT sets (defined by ECT-ALGORITHMS)
are being used by which VIDs, and this is carried in the Base VLAN
Identifiers sub-TLV.
Fedyk, et al. Expires May 28, 2011 [Page 17]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
13.1. SPB MCID sub-TLV
This sub-TLV is added to an IIH PDU to indicate the digest for the
Multiple spanning tree configuration a.k.a MCID. This TLV is a
digest of local configuration of which VIDs are running which
protocols. (The information is not to the level of a specific
algorithm in the case of SPB). This information should be the same
on all bridges in the topology identified by the MT-Port-Capability
TLV it is being carried within. The data used to generate the MCID
is populated by configuration and is a digest of the VIDs allocated
to various protocols. Two MCIDs are carried to allow non disruptive
transitions between configurations when the changes are non-
critical.
+-+-+-+-+-+-+-+-+
|Type=SPB-MCID | = 6
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCID (50 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Aux MCID (50 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type = 6 (Pending IANA).
o Length: The size of the value defined below (100).
o MCID (50-bytes) The complete MCID defined in IEEE 802.1Q which
identifies an SPT Region on the basis of matching assignments of
VIDs to control regimes (xSTP, SPBV, SPBM, etc). Briefly, the
MCID consists of a 1 byte format selector, a 32 byte
configuration name, a 2 byte revision level and finally a 16 byte
signature of type HMAC-MD5 over an array of 4096 elements that
contain identifiers of the use of the corresponding VID. Refer to
section 13.8 of [802.1aq] for the exact format and procedure.
Note that the use of the VID does not include specification of a
specific SPB ECT-ALGORITHM, rather it is coarser grain.
o Aux MCID (50-bytes) The complete MCID defined in IEEE 802.1Q
which identifies an SPT Region. The aux MCID allows SPT Regions
to be migrated by the allocation of new VLAN to FDB Mappings
without interruption to existing traffic.
Fedyk, et al. Expires May 28, 2011 [Page 18]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
The SPB MCID sub-TLV is carried within the MT-Port-Capability TLV
which in turn is carried in an IIH PDU.
13.2. SPB Digest sub-TLV
This sub-TLV is optionally added to an IIH PDU to indicate the
current topology digest value. This information should settle to be
the same on all bridges in an unchanging topology (identified by the
MT-Port-Capability TLV it is being carried within). Matching digests
indicate (with extremely high probability) that the topology view
between two bridges is synchronized, and is used to control the
updating of forwarding information. The IS-IS Agreement Digest is
computed based on currently topology and is designed to change only
when significant topology changes occur.
During the propagation of LSPs the Agreement Digest may vary between
neighbors until the key topology information in the LSPs are common.
The digest is therefore a summarized means of determining agreement
between nodes on database commonality, and hence infer agreement on
the distance to all multicast roots. When present it is used for
loop prevention as follows: For each shortest path tree where it
has been determined the distance to the root has changed, "unsafe"
multicast forwarding is blocked until the exchanged Agreement
Digests match while "safe" multicast forwarding is allowed to
continue despite the disagreement in digests and hence topology
views. [802.1aq] section 28.2 defines in detail what constitutes
"safe" v.s. "unsafe".
+-+-+-+-+-+-+-+-+
|Type=SPB-Digest| = 7
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-----+-+---+---+
| Res |V| A | D | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Agreement Digest (Length - 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type = 7 (Pending IANA).
o Length: The size of the value.
o V - agreed digest valid bit. See [802.1aq] Sec 28.2.
Fedyk, et al. Expires May 28, 2011 [Page 19]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
o A (2 bits) The Agreement Number 0-3 which aligns with BPDUs
Agreement Number concept [802.1aq]. When the Agreement Digest
for this node changes this number is incremented. The node then
checks for Agreement Digest match (as below). The new local
Agreement Number and the updated local Discarded Agreement Number
are then transmitted with the new Agreement Digest to the node's
neighbors in the hello PDU. Once an Agreement Number has been
sent it is considered outstanding until a matching or more recent
Discarded Agreement Number is received from the neighbor.
o D (2 bits) The Discarded Agreement Number 0-3 which aligns with
BPDUs Agreement Number concept. When an Agreement Digest is
received from a neighbor, this number is set to the received
Agreement Number, to signify that this node has received this new
agreement and discarded any previous ones. The node then checks
whether the local and received Agreement Digests match. If they
do, this node then sets :
the local Discarded Agreement Number = received Agreement
Number + 1
If the Agreement Digests match, AND
received Discarded Agreement Number == local Agreement Number
+ N (N = 0 || 1)
then the node has a topology matched to its neighbor.
Whenever the local Discarded Agreement Number relating to a
neighbor changes, the local Agreement Digest, Agreement Number,
and Discarded Agreement Number are transmitted.
o Agreement Digest. This digest is use to determine when IS-IS is
synchronized between neighbors relative to the MT-Port-Capability
instance. The agreement digest is a hash computed over the set of
all SPB adjacencies (all edges) in all SPB Multi Topology
instances. In other words, the digest includes all VIDs and all
adjacencies for all MT instances of SPB. This reflects the fact
that all SPB nodes in a region must have identical VID
allocations (see 13.1), and so all SPB MT instances will contain
the same set of nodes. The size and exact procedure for computing
the Agreement Digest is defined in section 28.2 of [802.1aq].
The SPB Digest sub-TLV is carried within the MT-Port-Capability TLV
which in turn is carried in an IIH PDU.
Fedyk, et al. Expires May 28, 2011 [Page 20]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
When supported, this sub-TLV MUST be carried on every IIH between
SPB neighbors, not just when a Digest changes.
When one peer supports this TLV and the other does not, loop
prevention by digest agreement MUST NOT be done by either side.
13.3. SPB Base VLAN-Identifiers sub-TLV
This sub-TLV is added to an IIH PDU to indicate the mappings between
ECT algorithms and Base VIDs (and by implication the VID(s) used on
the forwarding path for each SPT Set identified by a Base VID) that
are in use. Under stable operational conditions, this information
should be the same on all bridges in the topology identified by the
MT-PORT-CAP TLV it is being carried within.
+-+-+-+-+-+-+-+-+
|Type= SPB-B-VID| = 8
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-------------------------------+
| ECT - VID Tuple (1) (6 bytes) |
+-----------------------------------------------+
| ......................... |
+-----------------------------------------------+
| ECT - VID Tuples (N) (6 bytes) |
+-----------------------------------------------+
o Type: sub-TLV Type = 8 (Pending IANA).
o Length: The size of the value is ECT-VID Tuples*6 bytes. Each 6-
byte part of the ECT-VID tuple is formatted as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT - Algorithm (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base VID (12 bits) |U|M|RES|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o ECT-ALGORITHM (4 bytes) The ECT-ALGORITHM is advertised when the
bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given
Base VID. There are 17 predefined IEEE algorithms for SPB with
index values 0X00..0X10 occupying the low 8 bits and the IEEE
OUI=00-80-C2 occupying the top 24 bits of the ECT-ALGORITHM.
o Base VID (12-bits) The Base-VID that is associated with the SPT
Set.
Fedyk, et al. Expires May 28, 2011 [Page 21]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
o Use-Flag (1-bit) The Use-flag is set if this bridge, or any
bridge in the LSDB is currently using this ECT-ALGORITHM and Base
VID.
o M-Bit (1-bit) The M-bit indicates if this Base VID operates in
SPBM (M = 1) or SPBV (M = 0) mode.
The SPB Base VLAN-Identifier sub-TLV is carried within the MT-Port-
Capability TLV which in turn is carried in an IIH PDU.
14. Node information extensions
All SPB nodal information extensions travel within a new multi
topology capability TLV MT-Capability (type = 144).
+-+-+-+-+-+-+-+-+
|Type = MT-CAP | = 144
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R| MT ID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(sub-TLVs ... )
The format of this TLV is identical in its first 2 bytes to all
current MT TLV's and carries the MT ID as defined in [MT].
14.1. SPB Instance sub-TLV
The SPB Instance sub-TLV gives the SPSourceID for this node/topology
instance. This is the 20 bit value that is used in the formation of
multicast DA addresses for frames originating from this
node/instance. The SPSourceID occupies the upper 20 bits of the
multicast DA together with 4 other bits (see the SPBM 802.1ah
multicast DA address format section). This sub-TLV MUST be carried
within the MT-Capability TLV in the fragment ZERO LSP. If there is
an additional SPB instance it MUST be declared under a separate MT-
Topology and also carried in the fragment ZERO LSP.
Fedyk, et al. Expires May 28, 2011 [Page 22]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
+-+-+-+-+-+-+-+-+
|Type = SPB-Inst| = 1
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST Root Identifier (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST Root Identifier (cont) (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CIST External ROOT Path Cost (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bridge Priority | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R R R R R R R R R R R|V| SPSourceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Trees | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN-ID (1) Tuples (8 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VLAN-ID (N) Tuples (8 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where VLAN-ID tuples have the format as:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|U|M|A| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT - Algorithm (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Base VID (12 bits) | SPVID (12 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type 1 (Pending IANA).
o Length: Total number of bytes contained in the value field.
o CIST Root Identifier (64-bits)The CIST Root Identifier is for SPB
interworking with RSTP and MSTP at SPT Region Boundaries. This
is an imported value from a Spanning tree.
o CIST External Root Path Cost (32-bits) The CIST External Root
Path Cost is the cost to root, derived from the spanning tree
algorithm.
Fedyk, et al. Expires May 28, 2011 [Page 23]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
o Bridge Priority (16-bits) Bridge priority is the 16 bits that
together with the 6 bytes of the System ID form the Bridge
Identifier. This is configured exactly as specified in IEEE802
[802.1D]. This allows SPB to build a compatible Spanning tree
using link state by combining the Bridge Priority and the System
ID to form the 8 byte Bridge Identifier. The 8 byte Bridge
Identifier is also the input to the 16 pre-defined ECT tie
breaker algorithms.
o V bit (1-Bit) The V bit (SPBM) indicates this SPSourceID is auto
allocated(27.11). If the V bit is clear the SPSourceID has been
configured and must be unique. Allocation of SPSourceID is
defined in IEEE [802.1aq]. Bridges running SPBM will allocate an
SPSourceID if they are not configured with an explicit
SPSourceID. The V Bit allows neighbor bridges to determine if the
auto allocation was enabled. In the rare chance of a collision
of SPsourceID allocation, the bridge with the highest priority
Bridge Identifier will win conflicts and the lower priority
Bridge will be re-allocated or if the lower priority Bridge is
configured it will not be allowed to join the SPT Region.
o The SPSourceID is a 20 bit value used to construct multicast DA's
as described below for multicast frames originating from the
origin (SPB node) of the link state packet (LSP) that contains
this TLV. More details are in IEEE [802.1aq].
o Number of Trees (8-bits) The Number of Trees is set to the number
of [ECT-ALGORITHM, Base-VID plus flags] tuples that follow. Each
ECT-ALGORITHM has a Base VID, an SPVID and flags described below.
This must contain at least the one ECT-ALGORITMM (00-80-C2-01).
Each VID Tuple consists of:
o U-Bit (1-bit) The Use flag is set if this bridge is currently
using this ECT-ALGORITHM for I-SIDs it sources or sinks. This is
a strictly local indication; the semantics differ from the U-bit
found in the Hello, which will set the Use-Flag if it sees other
nodal Use-Flags are set OR it sources or sinks itself.
o M-Bit (1-bit) The M-bit indicates if this is SPBM or SPBV mode.
When cleared the mode is SPBV and when set the mode is SPBM.
Fedyk, et al. Expires May 28, 2011 [Page 24]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
o A bit, The A bit (SPB) when set declares this is an SPVID with
auto allocation. The VID allocation logic details are in IEEE
[802.1aq]. Since SPVIDs are from a small pool of resources
(typically 1000 or less) the chances of collision are high. To
allow auto allocation LSPs are exchanged with the allocated
bridge setting the SPVID to 0 and the allocating bridge sets the
SPVID when it learns the allocated space. SPVID may also be
configured. When the A bit is set to not specify auto allocation
and the SPVID is set to 0 this SPBV bridge is used for transit
only within the SPB region. If a port is configured with the
BASE-VID as an neighbor using RSTP or MSTP the bridge will act as
an ingress filter for that VID.
o ECT-ALGORITHM (4-bytes) ECT-ALGORITHM is advertised when the
bridge supports a given ECT-ALGORITHM (by OUI/Index) on a given
VID. This declaration must match the declaration in the Hello PDU
originating from the same bridge. The ECT-ALGORITHM, BASE-VID
should match what is generated in the Hellos of the same node.
The ECT-ALGORITHM, BASE-VID tuples can come in any order however.
There are currently 17 world wide unique 802.1aq defined ECT-
ALGORITHMS given by values 00-80-C2-00 through 00-80-C2-10.
o Base VID (12-bits) The Base-VID that associated the SPT Set via
the ECT-ALGORITHM.
o SPVID (12-bits) The SPVID is the Shortest Path VID assigned for
the Base VID to this node when using SPBV mode. It is not
defined for SPBM Mode and MUST be 0 for SPBM mode B-VIDs.
14.1.1. SPB Instance Opaque ECT-ALGORITHM sub-TLV
There are multiple ECT algorithms defined for SPB, however for the
future additional algorithms may be defined including but not
limited to ECMP / hash based behaviors and (*,G) multicast trees.
These algorithms will use this optional TLV to define new algorithm
parametric data. For tie breaking parameters there are two broad
classes of algorithm, one which uses nodal data to break ties and
one which uses link data to break ties, as a result this TLV can
associate opaque data with a node or an adjacency or both. This sub-
TLV, when present, MUST be carried within the MT-Capability TLV
(along with a valid SPB Instance sub-TLV). Multiple copies of this
sub-TLV may be carried for different ECT-ALGORITHMs relating to this
node.
There are of course many other uses of this opaque data which have
yet to be defined.
Fedyk, et al. Expires May 28, 2011 [Page 25]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
+-+-+-+-+-+-+-+-+
|Type=SPB-I-OALG| = 2
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Algorithm (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Information (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type 2 (Pending IANA).
o Length: Total number of bytes contained in the value field.
o ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge
supports a given ECT-ALGORITHM (by OUI/Index) on a given VID.
o ECT Information: ECT-ALGORITHM Information of variable length
which should be in sub-TLV format with an IANA numbering space
where appropriate.
15. Adjacency information extensions
15.1. SPB Link Metric sub-TLV
The SPB Link Metric sub-TLV (type = 12) occurs within the Multi
Topology Intermediate System TLV (type 222) or within the Extended
IS Reachability TLV (type 22). If this sub TLV is not present for
an ISIS adjacency then that adjacency MUST NOT carry SPB traffic for
the given topology instance.
+-+-+-+-+-+-+-+-+
|Type=SPB-Metric| = 12
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPB-LINK-METRIC | (3 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of ports | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Identifier | ( 2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type 12 (Pending IANA).
o Length: Total number of bytes contained in the value field.
Fedyk, et al. Expires May 28, 2011 [Page 26]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
o SPB-LINK-METRIC indicates the administrative cost or weight of
using this link as a 24 bit unsigned number. Smaller numbers
indicate lower weights and are more likely to carry SPB traffic.
Only one metric is allowed per SPB instance per link. If
multiple metrics are required multiple SPB instances are
required, either within IS-IS or within several independent IS-IS
instances. If this metric is different at each end of a link, the
maximum of the two values MUST be used in all SPB calculations
for the weight of this link. The maximum SPB-LINK-METRIC value
2^24 - 1 has a special significance; this value indicates that
although the IS-IS adjacency has formed, incompatible values have
been detected in parameters configured within SPB itself for
example different regions, and the link MUST NOT be used for
carrying SPB traffic. Full details are found in [802.1aq].
o Num of Ports is the number of ports associated with this link.
o Port Identifier is the standard IEEE port identifier used to
build a spanning tree associated with this link.
15.1.1. SPB Adjacency Opaque ECT-ALGORITHM sub-TLV
There are multiple ECT algorithms defined for SPB, however for the
future additional algorithms may be defined. The SPB Adjacency
Opaque ECT-ALGORITHM sub-TLV occurs within the Multi Topology
Intermediate System TLV (type 222) or the Extended IS Reachability
TLV (type 22). Multiple copies of this sub-TLV may be carried for
different ECT-ALGORITHMs related to this adjacency.
+-+-+-+-+-+-+-+-+
|Type=SPB-A-OALG| = 13
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Algorithm (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque ECT Information (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type = 13 (PENDING IANA).
o Length: Total number of bytes contained in the value field.
o ECT-ALGORITHM: ECT-ALGORITHM is advertised when the bridge
supports a given ECT-ALGORITHM (by OUI/Index) on a given VID.
Fedyk, et al. Expires May 28, 2011 [Page 27]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
o ECT Information: ECT-ALGORITHM Information of variable length in
sub-TLV format using new IANA type values as appropriate.
16. Service information extensions
16.1. SPBM Service Identifier and Unicast Address sub-TLV
The SPBM Service Identifier and Unicast Address sub-TLV (type=3) is
used to introduce service group membership on the originating node
and/or to advertise an additional B-MAC unicast address present on,
or reachable by the node.
+-+-+-+-+-+-+-+-+
|Type = SPBM-SI | = 3
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-MAC ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B-MAC ADDRESS (6 bytes) | Res. | Base-VID (12 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | ISID #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | ISID #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | ISID #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Type: sub-TLV Type = 3 (Pending IANA)
o Length: Total number of bytes contained in the value field.
o B-MAC ADDRESS is a unicast address of this node. It may be
either the single nodal address, or may address a port or any
other level of granularity relative to the node. In the case
where the node only has one B-MAC address this should be the same
as the SYS-ID of the node. To add multiple B-MACs this TLV must
be repeated per additional B-MAC.
Fedyk, et al. Expires May 28, 2011 [Page 28]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
o ISID #1 .. #N are 24 bit service group membership identifiers.
If two nodes have an I-SID in common, intermediate nodes on the
unique shortest path between them will create forwarding state
for the related B-MAC addresses and will also construct multicast
forwarding state using the I-SID and the node's SPSourceID to
construct a multicast DA as described in IEEE 802.1aq LSB. Each
I-SID has a Transmit(T) and Receive(R) bit which indicates if the
membership is as a Transmitter/Receiver or both (with both bits
set). In the case where the Transmit(T) and Receive(R) bits are
both zero, the I-SID instance is ignored for the purposes of
distributed multicast computation, but the unicast B-MAC address
must be processed and installed at nodes providing transit to
that address. If more I-SIDs are associated with a particular B-
MAC than can fit in a single sub-TLV, this sub-TLV can be
repeated with the same B-MAC but with different I-SID values.
o Note when the T bit is not set an SPB MAY still multicast to all
the other receive members of this I-SID (those advertising with
their R bits set), by configuring edge replication and serial
unicast to each member locally.
The SPBM Service Identifier sub-TLV, when present, MUST be carried
within the MT Capability TLV and can occur multiple times in any LSP
fragment.
16.2. SPBV Mac Address sub-TLV
The SPBV MAC Address (SPBV-MAC-ADDR) sub-TLV is IS-IS sub-TLV type 4
(PENDING IANA). It SHOULD be used for advertisement of Group MAC
Addresses in SPBV mode. Unicast MAC addresses will normally be
distributed by reverse path leaning, but carrying them in this TLV
is not precluded. It has the following format :
+-+-+-+-+-+-+-+-+
| Type=SPBV-ADDR| = 4 (1 byte)
+-+-+-+-+-+-+-+-+
| Length | (1 byte)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|R|S-R| SPVID | (2 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | MAC 1 Address | (1+6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|R| Reserved | MAC N Address | (1+6 bytes)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fedyk, et al. Expires May 28, 2011 [Page 29]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
o Type: sub-TLV Type, set to 4.
o Length: Total number of bytes contained in the value field. The
number of MAC address associated with the SPVID is computed by
(Length - 2)/7.
o S-R bits (2-bits) The SR bits are the service requirement
parameter from MMRP. The service requirement parameters have the
value 0 (Forward all Groups) and 1 (Forward All Unregistered
Groups) defined. However this attribute may also be missing. So
the SR bits are defined as 0 not declared, 1 Forward all Groups
and 2 Forward All Unregistered Groups. The two 'R' reserved bits
immediately preceding these SR bits should be set to zero when
originating this sub-TLV and ignored on receipt.
o SPVID (12-bits) The SPVID and by association Base VID and the
ECT-ALGORITHM and SPT Set that the MAC addresses defined below
will use. If the SPVID is not allocated the SPVID Value is 0.
Note that if the ECT-Algorithm in use is Spanning Tree Algorithm
this value should be populated with the Base VID and the MAC can
be populated.
o T Bit (1-bit) This is the Transmit allowed Bit for a following
group MAC address. This is an indication that the Group MAC
Address in the context of the SPVID of the bridge advertising
this Group MAC should be installed in the FDB of transit bridges,
when the bridge computing the trees is on the corresponding ECT-
ALGORITHM shortest path between the bridge advertising this MAC
with the T bit set, and any receiver of this Group MAC Address.
A bridge that does not advertise this bit set for a MAC Address
should cause no multicast forwarding state to be installed for
traffic originating from that bridge on other transit bridges in
the network.
o R Bit (1-bit) This is the Receive allowed Bit for the following
MAC Address. This is an indication that MAC Addresses as receiver
should be populated and installed when the bridge computing the
trees lies on the corresponding shortest path for this ECT-
ALGORITHM between this receiver and any transmitter to this MAC
Address. An entry that does not have this bit set for a Group
MAC Address is prevented from receiving on this Group MAC Address
because transit bridges will not install multicast forwarding
state towards it in their FDBs, or the traffic is explicitly
filtered.
Fedyk, et al. Expires May 28, 2011 [Page 30]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
o MAC Address (48-bits) The MAC address declares this bridge as
part of the multicast interest for this destination MAC address.
Multicast trees can be efficiently constructed for destination by
populating FDB entries for the subset of the shortest path tree
that connects the bridges supporting the MAC address. This
replaces the function of MMRP for SPTs. The T and R bits above
have meaning as specified above.
The SPBV-MAC-ADDR sub-TLV, when present, MUST be carried within the
MT-Capability TLV and can occur multiple times in any LSP fragment.
17. Security Considerations
This document adds no additional security risks to IS-IS, nor does
it provide any additional security for IS-IS.
18. IANA Considerations
Note that the NLPID value 0xC1 [NLPID] used in the IIH PDUs has
already been assigned by IANA for the purpose of 802.1aq therefore
no further action is required for this code point.
Since 802.1aq operates within the IS-IS Multi Topology framework
every sub-tlv MUST occur in the context of the proper MT TLV. There
are three Multi Topology TLV's in which 802.1aq requests allocation
of sub-TLV's. These are the MT-Port-Capability used in the IIH, the
MT-Capability (new) used within the LSP and finally the MT-
Intermediate-System TLV used to contain adjacency information within
the LSP.
This document creates the following TLVs & sub-TLV's within the IIH
and LSP PDUs MT TLV's as described below. The '*' indicates IANA
action is required. Other entries are shown to provide context only.
A '?' next to a number indicates a requested but of course not
necessarily the final assigned value.
The MT-Capability TLV is the only TLV requiring a new sub-registry.
Type value 144 is requested with a starting sub-tlv value of 1.
Fedyk, et al. Expires May 28, 2011 [Page 31]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
+-----+----+-----------------+--------+------+-------------+
| PDU |TLV | SUB-TLV | TYPE | TYPE | #OCCURRENCE |
+-----+----+-----------------+--------+------+-------------+
IIH
MT-Port-Capability 143
* SPB-MCID 6? 1
* SPB-Digest 7? >=0
* SPB-B-VID 8? 1
LSP
* MT-Capability 144?
* SPB-Inst 1? 1
* SPB-I-OALG 2? >=0
* SPBM-SI 3? >=0
* SPBV-ADDR 4? >=0
MT-Intermediate-System 222
or Extended IS Reachability 22
* SPB-Metric 12? 1
* SPB-A-OALG 13? >=0
19. References
19.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System
to Intermediate System Intra-Domain Routing Exchange
Protocol for use in Conjunction with the Protocol for
Providing the Connectionless-mode Network Service (ISO
8473)", 2002.
[MT] M-ISIS: Multi Topology (MT) Routing in Intermediate System
to Intermediate Systems (IS-ISs), RFC 5120, February 2008.
[NLPID] IANA registry at:
http://www.iana.org/assignments/nlpids/nlpids.xhtml
19.2. Informative References
[PB] "Standard for Local and Metropolitan Area Networks /
Virtual Bridged Local Area Networks / Amendment 4:
Provider Bridges, IEEE STD 802.1ad", 2005.
Fedyk, et al. Expires May 28, 2011 [Page 32]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
[PBB] "Standard for Local and Metropolitan Area Networks /
Virtual Bridged Local Area Networks / Amendment 7:
Provider Backbone Bridges, IEEE STD 802.1ah", 2008.
[802.1aq] "Standard for Local and Metropolitan Area Networks /
Virtual Bridged Local Area Networks / Amendment: Shortest
Path Bridging, Draft IEEE P802.6aq/3.2", 2010.
20. Acknowledgments
The authors would like to thank Ayan Banerjee, Mick Seaman, Janos
Farkas, Les Ginsberg and Mike Shand for contributions and/or
detailed review.
This document was prepared using 2-Word-v2.0.template.dot.
21. Author's Addresses
Don Fedyk
Alcatel-Lucent
Groton, MA, 01450, USA
Donald.Fedyk@alcatel-lucent.com
Peter Ashwood-Smith
Huawei Technologies Canada Ltd,
Ottawa, Ontario, CANADA
Peter.AshwoodSmith@huawei.com
Dave Allan
Ericsson, CANADA
Email: david.i.allan@ericsson.com
Nigel Bragg
Ciena
Email: nbragg@ciena.com
Paul Unbehagen
Alcatel-Lucent
8742 Lucent Boulevard
Highlands Ranch, CO 80129, USA
Paul.Unbehagen@alcatel-lucent.com
22. Intellectual Property Statement
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
Fedyk, et al. Expires May 28, 2011 [Page 33]
Internet-Draft draft-ietf-isis-ieee-aq-02.txt November 2011
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line
IPR repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
23. Disclaimer of Liability
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS.
Fedyk, et al. Expires May 28, 2011 [Page 34]
