[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 RFC 6329

Network Working Group                                     D. Fedyk, Ed.
Internet Draft                                           Alcatel-Lucent
Intended status: Standards Track                    P.Ashwood-Smith Ed.
Expires: January 2011                                            Huawei

                                                           July 5, 2010

     IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging
                      draft-ietf-isis-ieee-aq-00.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 January 5, 2009.

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.

Abstract



Fedyk, et al.          Expires January 5, 2011                 [Page 1]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   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.



































Fedyk, et al.          Expires January 5, 2011                 [Page 2]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010




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..................................6
      4.2. Data Path SPBM - Multicast (Head End Replication).........7
      4.3. Data Path SPBM - Multicast (Tandem Replication)...........7
      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. IS-IS Area Address and SYSID..................................14
   8. Level 1/2 Adjacency...........................................14
   9. Shortest Path Default Tie Breaking............................15
   10. Shortest Path ECT............................................15
   11. Hello (IIH) protocol extensions..............................16
      11.1. SPB Digest sub-TLV......................................17
      11.2. SPB Base VLAN-Identifiers sub-TLV.......................19
   12. Node information extensions..................................21
      12.1. SPB Instance sub-TLV....................................21
         12.1.1. SPB Instance Opaque ECT-ALGORITHM sub-TLV..........24
   13. Adjacency information extensions.............................24
      13.1. SPB Link Metric sub-TLV.................................24
         13.1.1. SPB Adjacency Opaque ECT-ALGORITHM sub-TLV.........25
   14. Service information extensions...............................26
      14.1. SPBM Service Identifier and Unicast Address sub-TLV.....26
      14.2. SPBV Mac Address sub-TLV................................27
   15. Security Considerations......................................29
   16. IANA Considerations..........................................29
   17. References...................................................30
      17.1. Normative References....................................30
      17.2. Informative References..................................31
   18. Acknowledgments..............................................31
   19. Authors' Addresses...........................................31
   20. Intellectual Property Statement..............................32
   21. Disclaimer of Validity.......................................32







Fedyk, et al.          Expires January 5, 2011                 [Page 3]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


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


Fedyk, et al.          Expires January 5, 2011                 [Page 4]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


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

   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.

   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.




Fedyk, et al.          Expires January 5, 2011                 [Page 5]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


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

   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
   with other properties to be defined in the future.

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


Fedyk, et al.          Expires January 5, 2011                 [Page 6]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   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.

   Unlike [PBB] 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
   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


Fedyk, et al.          Expires January 5, 2011                 [Page 7]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   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 will be 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>). This exact format is given in Figure 1
   below:

     SPSRC  TYP L M
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |[16:19]|0|0|1|1|           SPSRC [0:15]        | ISID [16:23]  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          ISID [0:15]          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  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. Initially it is set to 00. Other
      values are reserved for future automatically assigned SPSOURCEID
      algorithms.

   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.

   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


Fedyk, et al.          Expires January 5, 2011                 [Page 8]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   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.

   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.



Fedyk, et al.          Expires January 5, 2011                 [Page 9]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


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


Fedyk, et al.          Expires January 5, 2011                [Page 10]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010



   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 January 5, 2011                [Page 11]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


          +-------+-------------------+------+-----------------+
          | 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 January 5, 2011                [Page 12]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


                        +----+           +----+
                        | :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 January 5, 2011                [Page 13]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


          +-------+-------------------+------+-----------------+
          | 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. 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) MAY use
   any valid IS-IS area address as required by the other NLPIDs however
   only matching area addresses will form a single SPB domain.

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


Fedyk, et al.          Expires January 5, 2011                [Page 14]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


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

   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, deterministic results in
   addition to having the critical property of transitivity (shortest
   path is made up of sub-shortest paths).

10. Shortest Path ECT

   (ECT-ALGORITHM = 00-80-C2-01 .. -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:





Fedyk, et al.          Expires January 5, 2011                [Page 15]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


        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.

   To support many other tie breaking mechanisms in the future two
   opaque ECT TLV's are defined.

   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.


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




Fedyk, et al.          Expires January 5, 2011                [Page 16]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   IEEE 802.1aq augments the normal IIH PDU with two 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 may 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).

   SPB neighbors require a mechanism to instantaneously 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. This digest is carried in the 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.

11.1. SPB Digest sub-TLV

   This sub-TLV is added to an IIH PDU to indicate the digest for
   Multiple spanning tree configuration Digests (MCID) and the IS-IS
   Agreement Digest.  This information should be the same on all
   bridges in the topology identified by the MT-Port-Capability TLV it
   is being carried within. These digests indicate when the
   configuration and the topology are synchronized respectively, and
   are used to control the updating of forwarding information.  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 transitions between configurations when the changes
   are non-critical. Note MCID and Aux MCID change very slowly and
   infrequently whereas the IS-IS Agreement Digest is computed based on
   currently topology and it changes when significant topology changes.

   During the propagation of LSPs the Agreement Digest will vary
   between neighbors until the LSPs are common. The digest is a
   summarized means of determining agreement between nodes on database
   commonality, and hence infer agreement on the distance to all
   multicast roots. This is essential for loop prevention.  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.






Fedyk, et al.          Expires January 5, 2011                [Page 17]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   +-+-+-+-+-+-+-+-+
   |Type=SPB-Digest| = 6
   +-+-+-+-+-+-+-+-+
   |   Length      |    (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MCID (50 Bytes)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Aux   MCID (50 Bytes)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Agreement Digest (32 Bytes)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |RES    | A |  D|
   +-+-+-+-+-+-+-+-+

   o  Type: sub-TLV Type = 6 (Pending IANA).

   o  Length: The size of the value defined below.

   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.

   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.

   o  Agreement Digest (32-bytes) This digest is use to determine when
      IS-IS is synchronized between neighbors relative to the MT-Port-
      Capability instance. The agreement digest is computed over the
      set of all SPB adjacencies (all edges) that are members of this
      MTID, or in the case of MTID#0, over all the SPB adjacencies. The
      exact procedure is described in section 28.2 of [802.1aq].

   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.


Fedyk, et al.          Expires January 5, 2011                [Page 18]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   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.


   The SPB Digest sub-TLV is carried within the MT-Port-Capability TLV
   which in turn is carried in an IIH PDU. Since these subTLVs are
   quite large and to avoid overflowing a single IIH, the MTID #0 has a
   special meaning and when it is used MUST contain SPB digests
   computed over all Multi Topology instances. That is to say if used
   it includes all VIDs and all adjacencies for all MT instances of
   SPB.

   If MT instance specific digests are desired they may be carried in
   MTIDs != 0.

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








Fedyk, et al.          Expires January 5, 2011                [Page 19]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   +-+-+-+-+-+-+-+-+
   |Type= SPB-B-VID| = 5
   +-+-+-+-+-+-+-+-+
   |   Length      |    (1 byte)
   +-+-+-+-+-+-+-+-+-------------------------------+
   |      ECT - VID Tuple (1)  (6 bytes)           |
   +-----------------------------------------------+
   |      .........................                |
   +-----------------------------------------------+
   |      ECT - VID Tuples (N)  (6 bytes)          |
   +-----------------------------------------------+

   o  Type: sub-TLV Type = 5 (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 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.

   o  Use-Flag (1-bit) The Use-flag is set if this bridge, or any
      bridge that this bridge sees 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.








Fedyk, et al.          Expires January 5, 2011                [Page 20]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


12. Node information extensions

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

   +-+-+-+-+-+-+-+-+
   |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 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  VLAN-ID (1) Tuples    (8 bytes)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  VLAN-ID (N) Tuples    (8 bytes)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      where VLAN-ID tuples have the format as:












Fedyk, et al.          Expires January 5, 2011                [Page 21]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


       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.

   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.






Fedyk, et al.          Expires January 5, 2011                [Page 22]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


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

   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 auto allocated and 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-VIDs pairs 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.


Fedyk, et al.          Expires January 5, 2011                [Page 23]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   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.

12.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.  These algorithms would
   use this optional TLV to define new algorithm tie breaking data.
   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 SHOULD 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.

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

13. Adjacency information extensions

13.1. SPB Link Metric sub-TLV

   The SPB Link Metric sub-TLV (type = 12) occurs within the Multi
   Topology Intermediate System TLV (type 222).  If this sub TLV is not
   present for an ISIS adjacency then that adjacency MUST NOT carry SPB
   traffic for the given topology instance.





Fedyk, et al.          Expires January 5, 2011                [Page 24]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


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

   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.

   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.

13.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). Multiple copies of this sub-TLV
   may be carried for different ECT-ALGORITHMs related to this
   adjacency.










Fedyk, et al.          Expires January 5, 2011                [Page 25]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


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

   o  ECT Information: ECT-ALGORITHM Information of variable length.



14. Service information extensions

14.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                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Fedyk, et al.          Expires January 5, 2011                [Page 26]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   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.

   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 members of this I-SID advertising their R bits set, by
      configuring edge replication and serial unicast to each member
      locally.

   The SPBM Service Identifier sub-TLV SHOULD be carried within the MT
   Capability TLV and can occur multiple times in any LSP fragment.

14.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 :







Fedyk, et al.          Expires January 5, 2011                [Page 27]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


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


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













Fedyk, et al.          Expires January 5, 2011                [Page 28]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   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.

   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 SHOULD be carried within the MT-Capability
   TLV and can occur multiple times in any LSP fragment.

15. Security Considerations

   This document adds no additional security risks to IS-IS, nor does
   it provide any additional security for IS-IS.

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





Fedyk, et al.          Expires January 5, 2011                [Page 29]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


   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 used within the LSP and finally the MT-Intermediate-
   System TLV used to contain adjacency information within the LSP.

   This document creates the following sub-TLV's within the IIH and LSP
   PDUs MT TLV's as described below:
      +-----+----+-----------------+--------+------+-------------+
      | PDU |TLV | SUB-TLV         | TYPE   | TYPE | #OCCURRENCE |
      +-----+----+-----------------+--------+------+-------------+
        IIH
             MT-Port-Capability      143
                   SPB-B-VID                   5      1
                   SPB-Digest                  6      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
                   SPB-Metric                 12      1
                   SPB-A-OALG                 13      >=0

17. References

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





Fedyk, et al.          Expires January 5, 2011                [Page 30]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


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

   [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 9:
             Shortest Path Bridging, Draft IEEE P802.6aq/3.0", 2010.

18. Acknowledgments

   The authors would like to thank Ayan Banerjee, Nigel Bragg, Paul
   Unbehagen, Mick Seaman and Janos Farkas for contributions and
   detailed review.

   This document was prepared using 2-Word-v2.0.template.dot.

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


Fedyk, et al.          Expires January 5, 2011                [Page 31]

Internet-Draft      draft-ietf-isis-ieee-aq-00.txt            July 2010


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


21. Disclaimer of Validity

   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 January 5, 2011                [Page 32]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/