tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7176

Proposed STD
Pages: 45
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ISIS

Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS

Part 1 of 3, p. 1 to 17
None       Next RFC Part

Obsoletes:    6326


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 7176                                        Huawei
Obsoletes: 6326                                          T. Senevirathne
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                              A. Ghanwani
                                                                    Dell
                                                                 D. Dutt
                                                        Cumulus Networks
                                                             A. Banerjee
                                                        Insieme Networks
                                                                May 2014


   Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS

Abstract

   The IETF Transparent Interconnection of Lots of Links (TRILL)
   protocol provides optimal pair-wise data frame forwarding without
   configuration in multi-hop networks with arbitrary topology and link
   technology; it also provides support for multipathing of both unicast
   and multicast traffic.  This document specifies the data formats and
   code points for the IS-IS extensions to support TRILL.  These data
   formats and code points may also be used by technologies other than
   TRILL.  This document obsoletes RFC 6326.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc7176.

Page 2 
Copyright Notice

   Copyright (c) 2014 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.

Table of Contents

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................4
   2. TLV and Sub-TLV Extensions to IS-IS for TRILL ...................4
      2.1. Group Address TLV ..........................................5
           2.1.1. Group MAC Address Sub-TLV ...........................5
           2.1.2. Group IPv4 Address Sub-TLV ..........................7
           2.1.3. Group IPv6 Address Sub-TLV ..........................8
           2.1.4. Group Labeled MAC Address Sub-TLV ...................9
           2.1.5. Group Labeled IPv4 Address Sub-TLV .................10
           2.1.6. Group Labeled IPv6 Address Sub-TLV .................11
      2.2. Multi-Topology-Aware Port Capability Sub-TLVs .............12
           2.2.1. Special VLANs and Flags Sub-TLV ....................12
           2.2.2. Enabled-VLANs Sub-TLV ..............................13
           2.2.3. Appointed Forwarders Sub-TLV .......................14
           2.2.4. Port TRILL Version Sub-TLV .........................15
           2.2.5. VLANs Appointed Sub-TLV ............................17
      2.3. Sub-TLVs of the Router Capability and MT-Capability TLVs ..17
           2.3.1. TRILL Version Sub-TLV ..............................18
           2.3.2. Nickname Sub-TLV ...................................19
           2.3.3. Trees Sub-TLV ......................................20
           2.3.4. Tree Identifiers Sub-TLV ...........................20
           2.3.5. Trees Used Identifiers Sub-TLV .....................21
           2.3.6. Interested VLANs and Spanning Tree Roots Sub-TLV ...22
           2.3.7. VLAN Group Sub-TLV .................................24
           2.3.8. Interested Labels and Spanning Tree Roots Sub-TLV ..25
           2.3.9. RBridge Channel Protocols Sub-TLV ..................27
           2.3.10. Affinity Sub-TLV ..................................29
           2.3.11. Label Group Sub-TLV ...............................30
      2.4. MTU Sub-TLV for Extended Reachability and MT-ISN TLVs .....31
      2.5. TRILL Neighbor TLV ........................................31
   3. MTU PDUs .......................................................33

Top      ToC       Page 3 
   4. Use of Existing PDUs and TLVs ..................................35
      4.1. TRILL IIH PDUs ............................................35
      4.2. Area Address ..............................................35
      4.3. Protocols Supported .......................................35
      4.4. Link State PDUs (LSPs) ....................................35
      4.5. Originating LSP Buffer Size ...............................36
   5. IANA Considerations ............................................36
      5.1. TLVs ......................................................36
      5.2. Sub-TLVs ..................................................36
      5.3. PDUs ......................................................38
      5.4. Reserved and Capability Bits ..............................38
      5.5. TRILL Neighbor Record Flags ...............................39
   6. Security Considerations ........................................39
   7. Changes from RFC 6326 ..........................................39
   8. References .....................................................41
      8.1. Normative References ......................................41
      8.2. Informative References ....................................43
   9. Acknowledgements ...............................................44

1.  Introduction

   The IETF Transparent Interconnection of Lots of Links (TRILL)
   protocol [RFC6325] [RFC7177] provides transparent forwarding in
   multi-hop networks with arbitrary topology and link technologies
   using a header with a hop count and link-state routing.  TRILL
   provides optimal pair-wise forwarding without configuration, safe
   forwarding even during periods of temporary loops, and support for
   multipathing of both unicast and multicast traffic.  Intermediate
   Systems (ISs) implementing TRILL are called Routing Bridges
   (RBridges) or TRILL Switches.

   This document, in conjunction with [RFC6165], specifies the data
   formats and code points for the IS-IS [ISO-10589] [RFC1195]
   extensions to support TRILL.  These data formats and code points may
   also be used by technologies other than TRILL.

   This document obsoletes [RFC6326], which generally corresponded to
   the base TRILL protocol [RFC6325].  There has been substantial
   development of TRILL since the publication of those documents.  The
   main changes from [RFC6326] are summarized below, and a full list is
   given in Section 7.

   1.  Added multicast group announcements by IPv4 and IPv6 address.

   2.  Added facilities for announcing capabilities supported.

   3.  Added a tree affinity sub-TLV whereby ISs can request
       distribution tree association.

Top      ToC       Page 4 
   4.  Added multi-topology support.

   5.  Added control-plane support for TRILL Data frame fine-grained
       labels.  This support is independent of the data-plane
       representation.

   6.  Fixed the verified erratum [Err2869] in [RFC6326].

   Changes herein to TLVs and sub-TLVs specified in [RFC6326] are
   backward compatible.

1.1.  Conventions Used in This Document

   The terminology and acronyms defined in [RFC6325] are used herein
   with the same meaning.

   Additional acronyms and phrases used in this document are:

      BVL - Bit Vector Length

      BVO - Bit Vector Offset

      IIH - IS-IS Hello

      IS - Intermediate System.  For this document, all relevant
      intermediate systems are RBridges [RFC6325].

      MAC - Media Access Control

      MT - Multi-Topology

      NLPID - Network Layer Protocol Identifier

      SNPA - Subnetwork Point of Attachment (MAC Address)

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

2.  TLV and Sub-TLV Extensions to IS-IS for TRILL

   This section, in conjunction with [RFC6165], specifies the data
   formats and code points for the TLVs and sub-TLVs for IS-IS to
   support the IETF TRILL protocol.  Information as to the number of
   occurrences allowed, such as for a TLV in a PDU or set of PDUs or for
   a sub-TLV in a TLV, is summarized in Section 5.

Top      ToC       Page 5 
2.1.  Group Address TLV

   The Group Address (GADDR) TLV, IS-IS TLV type 142, is carried in an
   LSP PDU and carries sub-TLVs that in turn advertise multicast group
   listeners.  The sub-TLVs that advertise listeners are specified
   below.  The sub-TLVs under GADDR constitute a new series of sub-TLV
   types (see Section 5.2).

   GADDR has the following format:

   +-+-+-+-+-+-+-+-+
   |Type=GADDR-TLV |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
   |      sub-TLVs...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-...

   o  Type: TLV type, set to GADDR-TLV 142.

   o  Length: variable depending on the sub-TLVs carried.

   o  sub-TLVs: The Group Address TLV value consists of sub-TLVs
      formatted as described in [RFC5305].

2.1.1.  Group MAC Address Sub-TLV

   The Group MAC Address (GMAC-ADDR) sub-TLV is sub-TLV type number 1
   within the GADDR TLV.  In TRILL, it is used to advertise multicast
   listeners by MAC address as specified in Section 4.5.5 of [RFC6325].
   It has the following format:

Top      ToC       Page 6 
   +-+-+-+-+-+-+-+-+
   |Type=GMAC-ADDR |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESV |     Topology-ID       |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESV |     VLAN ID           |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (2)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the following form with k=6:

   +-+-+-+-+-+-+-+-+
   | Num of Sources|                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Group Address         (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 1 Address      (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 2 Address      (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    .....                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source M Address      (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: GADDR sub-TLV type, set to 1 (GMAC-ADDR).

   o  Length: 5 + m + k*n = 5 + m + 6*n, where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

   o  RESV: Reserved.  4-bit fields that MUST be sent as zero and
      ignored on receipt.

   o  Topology-ID: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

Top      ToC       Page 7 
   o  VLAN ID: This carries the 12-bit VLAN identifier for all
      subsequent MAC addresses in this sub-TLV, or the value zero if no
      VLAN is specified.

   o  Num Group Recs: A 1-byte unsigned integer that is the number of
      group records in this sub-TLV.

   o  GROUP RECORDS: Each group record carries the number of sources.
      If this field is zero, it indicates a listener for (*,G), that is,
      a listener not restricted by source.  It then has a 6-byte
      (48-bit) multicast MAC address followed by 6-byte source MAC
      addresses.  If the sources do not fit in a single sub-TLV, the
      same group address may be repeated with different source addresses
      in another sub-TLV of another instance of the Group Address TLV.

   The GMAC-ADDR sub-TLV is carried only within a GADDR TLV.

2.1.2.  Group IPv4 Address Sub-TLV

   The Group IPv4 Address (GIP-ADDR) sub-TLV is IS-IS sub-TLV type 2
   within the GADDR TLV.  It has the same format as the Group MAC
   Address sub-TLV described in Section 2.1.1 except that k=4.  The
   fields are as follows:

   o  Type: sub-TLV type, set to 2 (GIP-ADDR).

   o  Length: 5 + m + k*n = 5 + m + 4*n, where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

   o  Topology-ID: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

   o  RESV: Must be sent as zero on transmission and is ignored on
      receipt.

   o  VLAN ID: This carries a 12-bit VLAN identifier that is valid for
      all subsequent addresses in this sub-TLV, or the value zero if no
      VLAN is specified.

   o  Num Group Recs: A 1-byte unsigned integer that is the number of
      group records in this sub-TLV.

Top      ToC       Page 8 
   o  GROUP RECORDS: Each group record carries the number of sources.
      If this field is zero, it indicates a listener for (*,G), that is,
      a listener not restricted by source.  It then has a 4-byte
      (32-bit) IPv4 Group Address followed by 4-byte source IPv4
      addresses.  If the number of sources do not fit in a single sub-
      TLV, it is permitted to have the same group address repeated with
      different source addresses in another sub-TLV of another instance
      of the Group Address TLV.

   The GIP-ADDR sub-TLV is carried only within a GADDR TLV.

2.1.3.  Group IPv6 Address Sub-TLV

   The Group IPv6 Address (GIPV6-ADDR) sub-TLV is IS-IS sub-TLV type 3
   within the GADDR TLV.  It has the same format as the Group MAC
   Address sub-TLV described in Section 2.1.1 except that k=16.  The
   fields are as follows:

   o  Type: sub-TLV type, set to 3 (GIPV6-ADDR).

   o  Length: 5 + m + k*n = 5 + m + 16*n, where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

   o  Topology-Id: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

   o  RESV: Must be sent as zero on transmission and is ignored on
      receipt.

   o  VLAN ID: This carries a 12-bit VLAN identifier that is valid for
      all subsequent addresses in this sub-TLV, or the value zero if no
      VLAN is specified.

   o  Num Group Recs: A 1-byte unsigned integer that is the number of
      group records in this sub-TLV.

   o  GROUP RECORDS: Each group record carries the number of sources.
      If this field is zero, it indicates a listener for (*,G), that is,
      a listener not restricted by source.  It then has a 16-byte
      (128-bit) IPv6 Group Address followed by 16-byte source IPv6
      addresses.  If the number of sources do not fit in a single sub-
      TLV, it is permitted to have the same group address repeated with
      different source addresses in another sub-TLV of another instance
      of the Group Address TLV.

   The GIPV6-ADDR sub-TLV is carried only within a GADDR TLV.

Top      ToC       Page 9 
2.1.4.  Group Labeled MAC Address Sub-TLV

   The GMAC-ADDR sub-TLV of the Group Address (GADDR) TLV specified in
   Section 2.1.1 provides for a VLAN ID.  The Group Labeled MAC Address
   sub-TLV, below, extends this to a fine-grained label.

   +-+-+-+-+-+-+-+-+
   |Type=GLMAC-ADDR|                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  RESV |     Topology-ID       |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Fine-Grained Label                     | (3 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Num Group Recs |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (1)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (2)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   .................                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   GROUP RECORDS (N)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each group record is of the following form with k=6:

   +-+-+-+-+-+-+-+-+
   | Num of Sources|                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Group Address         (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 1 Address      (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source 2 Address      (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    .....                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Source M Address      (k bytes)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: GADDR sub-TLV type, set to 4 (GLMAC-ADDR).

   o  Length: 6 + m + k*n = 6 + m + 6*n, where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

Top      ToC       Page 10 
   o  RESV: Reserved.  4-bit field that MUST be sent as zero and ignored
      on receipt.

   o  Topology-ID: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

   o  Label: This carries the fine-grained label [RFC7172] identifier
      for all subsequent MAC addresses in this sub-TLV, or the value
      zero if no label is specified.

   o  Num Group Recs: A 1-byte unsigned integer that is the number of
      group records in this sub-TLV.

   o  GROUP RECORDS: Each group record carries the number of sources.
      If this field is zero, it indicates a listener for (*,G), that is,
      a listener not restricted by source.  It then has a 6-byte
      (48-bit) multicast address followed by 6-byte source MAC
      addresses.  If the sources do not fit in a single sub-TLV, the
      same group address may be repeated with different source addresses
      in another sub-TLV of another instance of the Group Address TLV.

   The GLMAC-ADDR sub-TLV is carried only within a GADDR TLV.

2.1.5.  Group Labeled IPv4 Address Sub-TLV

   The Group Labeled IPv4 Address (GLIP-ADDR) sub-TLV is IS-IS sub-TLV
   type 5 within the GADDR TLV.  It has the same format as the Group
   Labeled MAC Address sub-TLV described in Section 2.1.4 except that
   k=4.  The fields are as follows:

   o  Type: sub-TLV type, set to 5 (GLIP-ADDR).

   o  Length: 6 + m + k*n = 6 + m + 4*n, where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

   o  Topology-ID: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

   o  RESV: Must be sent as zero on transmission and is ignored on
      receipt.

   o  Label: This carries the fine-grained label [RFC7172] identifier
      for all subsequent IPv4 addresses in this sub-TLV, or the value
      zero if no label is specified.

   o  Num Group Recs: A 1-byte unsigned integer that is the number of
      group records in this sub-TLV.

Top      ToC       Page 11 
   o  GROUP RECORDS: Each group record carries the number of sources.
      If this field is zero, it indicates a listener for (*,G), that is,
      a listener not restricted by source.  It then has a 4-byte
      (32-bit) IPv4 Group Address followed by 4-byte source IPv4
      addresses.  If the number of sources do not fit in a single sub-
      TLV, it is permitted to have the same group address repeated with
      different source addresses in another sub-TLV of another instance
      of the Group Address TLV.

   The GLIP-ADDR sub-TLV is carried only within a GADDR TLV.

2.1.6.  Group Labeled IPv6 Address Sub-TLV

   The Group Labeled IPv6 Address (GLIPV6-ADDR) sub-TLV is IS-IS sub-TLV
   type 6 within the GADDR TLV.  It has the same format as the Group
   Labeled MAC Address sub-TLV described in Section 2.1.4 except that
   k=16.  The fields are as follows:

   o  Type: sub-TLV type, set to 6 (GLIPV6-ADDR).

   o  Length: 6 + m + k*n = 6 + m + 16*n, where m is the number of group
      records and n is the sum of the number of group and source
      addresses.

   o  Topology-Id: This field carries a topology ID [RFC5120] or zero if
      topologies are not in use.

   o  RESV: Must be sent as zero on transmission and is ignored on
      receipt.

   o  Label: This carries the fine-grained label [RFC7172] identifier
      for all subsequent IPv6 addresses in this sub-TLV, or the value
      zero if no label is specified.

   o  Num Group Recs: A 1-byte unsigned integer that is the number of
      group records in this sub-TLV.

   o  GROUP RECORDS: Each group record carries the number of sources.
      If this field is zero, it indicates a listener for (*,G), that is,
      a listener not restricted by source.  It then has a 16-byte
      (128-bit) IPv6 Group Address followed by 16-byte source IPv6
      addresses.  If the number of sources do not fit in a single sub-
      TLV, it is permitted to have the same group address repeated with
      different source addresses in another sub-TLV of another instance
      of the Group Address TLV.

   The GLIPV6-ADDR sub-TLV is carried only within a GADDR TLV.

Top      ToC       Page 12 
2.2.  Multi-Topology-Aware Port Capability Sub-TLVs

   TRILL makes use of the Multi-Topology-Aware Port Capability TLV (MT-
   Port-Cap-TLV) as specified in [RFC6165].  The following subsections
   specify the sub-TLVs transported by the MT-Port-Cap-TLV for TRILL.

2.2.1.  Special VLANs and Flags Sub-TLV

   In TRILL, a Special VLANs and Flags (VLAN-FLAGS) sub-TLV is carried
   in every IIH PDU.  It has the following format:

   +--+--+--+--+--+--+--+--+
   |    Type               |                         (1 byte)
   +--+--+--+--+--+--+--+--+
   |    Length             |                         (1 byte)
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |    Port ID                                    | (2 bytes)
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |    Sender Nickname                            | (2 bytes)
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |AF|AC|VM|BY|     Outer.VLAN                    | (2 bytes)
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   |TR|R |R |R |     Designated-VLAN               | (2 bytes)
   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

   o  Type: sub-TLV type, set to MT-Port-Cap-TLV VLAN-FLAGS sub-TLV 1.

   o  Length: 8.

   o  Port ID: An ID for the port on which the enclosing TRILL IIH PDU
      is being sent as specified in [RFC6325], Section 4.4.2.

   o  Sender Nickname: If the sending IS is holding any nicknames as
      discussed in [RFC6325], Section 3.7, one MUST be included here.
      Otherwise, the field is set to zero.  This field is to support
      intelligent end stations that determine the egress IS (RBridge)
      for unicast data through a directory service or the like and that
      need a nickname for their first hop to insert as the ingress
      nickname to correctly format a TRILL Data frame (see [RFC6325],
      Section 4.6.2, point 8).  It is also referenced in connection with
      the VLANs Appointed Sub-TLV (see Section 2.2.5) and can be used as
      the egress on one-hop RBridge Channel messages [RFC7178], for
      example, those use for BFD over TRILL [RFC7175].

   o  Outer.VLAN: A copy of the 12-bit outer VLAN ID of the TRILL IIH
      frame containing this sub-TLV, as specified in [RFC6325], Section
      4.4.5.

Top      ToC       Page 13 
   o  Designated-VLAN: The 12-bit ID of the Designated VLAN for the
      link, as specified in [RFC6325], Section 4.2.4.2.

   o  AF, AC, VM, BY, and TR: These flag bits have the following
      meanings when set to one, as specified in the listed section of
      [RFC6325]:

           RFC 6325
      Bit  Section   Meaning if bit is one
      --------------------------------------

      AF   4.4.2     Originating IS believes it is Appointed
                     Forwarder for the VLAN and port on which the
                     containing IIH PDU was sent.

      AC   4.9.1     Originating port configured as an access port
                     (TRILL traffic disabled).

      VM   4.4.5     VLAN mapping detected on this link.

      BY   4.4.2     Bypass pseudonode.

      TR   4.9.1     Originating port configured as a trunk port
                     (end-station service disabled).

   o  R: Reserved bit.  MUST be sent as zero and ignored on receipt.

2.2.2.  Enabled-VLANs Sub-TLV

   The optional Enabled-VLANs sub-TLV specifies the VLANs enabled at the
   port of the originating IS on which the containing Hello was sent, as
   specified in [RFC6325], Section 4.4.2.  It has the following format:

   +-+-+-+-+-+-+-+-+
   |     Type      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RESV  |  Start VLAN ID        |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | VLAN bit-map....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV type, set to MT-Port-Cap-TLV Enabled-VLANs sub-TLV
      2.

   o  Length: Variable, minimum 3.

Top      ToC       Page 14 
   o  RESV: 4 reserved bits that MUST be sent as zero and ignored on
      receipt.

   o  Start VLAN ID: The 12-bit VLAN ID that is represented by the high-
      order bit of the first byte of the VLAN bit-map.

   o  VLAN bit-map: The highest-order bit indicates the VLAN equal to
      the start VLAN ID, the next highest bit indicates the VLAN equal
      to start VLAN ID + 1, continuing to the end of the VLAN bit-map
      field.

   If this sub-TLV occurs more than once in a Hello, the set of enabled
   VLANs is the union of the sets of VLANs indicated by each of the
   Enabled-VLAN sub-TLVs in the Hello.

2.2.3.  Appointed Forwarders Sub-TLV

   The Designated RBridge (DRB) on a link uses the Appointed Forwarders
   sub-TLV to inform other ISs on the link that they are the designated
   VLAN-x forwarder for one or more ranges of VLAN IDs as specified in
   [RFC6439].  It has the following format:

   +-+-+-+-+-+-+-+-+
   |     Type      |                          (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                          (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Appointment Information (1)         |  (6 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Appointment Information (2)         |  (6 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   .................                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Appointment Information (N)         |  (6 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   where each appointment is of the form:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Appointee Nickname              |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RESV  |        Start.VLAN             |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RESV  |        End.VLAN               |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      ToC       Page 15 
   o  Type: sub-TLV type, set to MT-Port-Cap-TLV AppointedFwrdrs sub-TLV
      3.

   o  Length: 6*n bytes, where there are n appointments.

   o  Appointee Nickname: The nickname of the IS being appointed a
      forwarder.

   o  RESV: 4 bits that MUST be sent as zero and ignored on receipt.

   o  Start.VLAN, End.VLAN: This VLAN ID range is inclusive.  Setting
      both Start.VLAN and VLAN.end to the same value indicates a range
      of one VLAN ID.  If Start.VLAN is not equal to VLAN.end and
      Start.VLAN is 0x000, the sub-TLV is interpreted as if Start.VLAN
      was 0x001.  If Start.VLAN is not equal to VLAN.end and VLAN.end is
      0xFFF, the sub-TLV is interpreted as if VLAN.end was 0xFFE.  If
      VLAN.end is less than Start.VLAN, the sub-TLV is ignored.  If both
      Start.VLAN and VLAN.end are 0x000 or both are 0xFFF, the sub-TLV
      is ignored.  The values 0x000 or 0xFFF are not valid VLAN IDs, and
      a port cannot be enabled for them.

   An IS's nickname may occur as Appointed Forwarder for multiple VLAN
   ranges by occurrences of this sub-TLV within the same or different MT
   Port Capability TLVs within an IIH PDU.  See [RFC6439].

2.2.4.  Port TRILL Version Sub-TLV

   The Port TRILL Version (PORT-TRILL-VER) sub-TLV indicates the maximum
   version of the TRILL standard supported and the support of optional
   hop-by-hop capabilities.  By implication, lower versions are also
   supported.  If this sub-TLV is missing from an IIH, it is assumed
   that the originating IS only supports the base version (version zero)
   of the protocol [RFC6325] and supports no optional capabilities
   indicated by this sub-TLV.

   +-+-+-+-+-+-+-+-+
   | Type          |              (1 byte)
   +-+-+-+-+-+-+-+-+
   | Length        |              (1 byte)
   +-+-+-+-+-+-+-+-+
   | Max-version   |              (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+
   | Capabilities and Header Flags Supported |  (4 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
    0                   1                 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7   0 1

Top      ToC       Page 16 
   o  Type: MT-Port-Cap-TLV sub-TLV type, set to 7 (PORT-TRILL-VER).

   o  Length: 5.

   o  Max-version: A one-byte unsigned integer set to the maximum
      version supported.

   o  Capabilities and Header Flags Supported: A bit vector of 32 bits
      numbered 0 through 31 in network order.  Bits 3 through 13
      indicate that the corresponding TRILL Header hop-by-hop extended
      flags [RFC7179] are supported.  Bits 0 through 2 and 14 to 31 are
      reserved to indicate support of optional capabilities.  A one bit
      indicates that the flag or capability is supported by the sending
      IS.  Bits in this field MUST be set to zero except as permitted
      for a capability being advertised or if a hop-by-hop extended
      header flag is supported.

   This sub-TLV, if present, MUST occur in an MT-Port-Cap-TLV in a TRILL
   IIH.  If there is more than one occurrence, the minimum of the
   supported versions is assumed to be correct and a capability or
   header flag is assumed to be supported only if indicated by all
   occurrences.  The flags and capabilities for which support can be
   indicated in this sub-TLV are disjoint from those in the TRILL-VER
   sub-TLV (Section 2.3.1) so they cannot conflict.  The flags and
   capabilities indicated in this sub-TLV relate to hop-by-hop
   processing that can differ between the ports of an IS (RBridge) and
   thus must be advertised in IIHs.  For example, a capability requiring
   cryptographic hardware assist might be supported on some ports and
   not others.  However, the TRILL version is the same as that in the
   PORT-TRILL-VER sub-TLV.  An IS, if it is adjacent to the sending IS
   of TRILL version sub-TLV(s), uses the TRILL version it received in
   PORT-TRILL-VER sub-TLV(s) in preference to that received in TRILL-VER
   sub-TLV(s).

Top      ToC       Page 17 
2.2.5.  VLANs Appointed Sub-TLV

   The optional VLANs Appointed sub-TLV specifies, for the port of the
   originating IS on which the containing Hello was sent, the VLANs for
   which it is Appointed Forwarder.  This sub-TLV has the following
   format:

   +-+-+-+-+-+-+-+-+
   |     Type      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RESV  |  Start VLAN ID        |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | VLAN bit-map....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   o  Type: sub-TLV type, set to MT-Port-Cap-TLV VLANS-Appointed sub-TLV
      8.

   o  Length: Variable, minimum 3.

   o  RESV: 4 reserved bits that MUST be sent as zero and ignored on
      receipt.

   o  Start VLAN ID: The 12-bit VLAN ID that is represented by the high-
      order bit of the first byte of the VLAN bit-map.

   o  VLAN bit-map: The highest-order bit indicates the VLAN equal to
      the start VLAN ID, the next highest bit indicates the VLAN equal
      to start VLAN ID + 1, continuing to the end of the VLAN bit-map
      field.

   If this sub-TLV occurs more than once in a Hello, the originating IS
   is declaring that it believes itself to be Appointed Forwarder on the
   port on which the enclosing IIH was sent for the union of the sets of
   VLANs indicated by each of the VLANs-Appointed sub-TLVs in the Hello.



(page 17 continued on part 2)

Next RFC Part