Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7176

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

Pages: 45
Proposed Standard
Obsoletes:  6326
Part 1 of 3 – Pages 1 to 17
None   None   Next

Top   ToC   RFC7176 - 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.
Top   ToC   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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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   RFC7176 - 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 Section