One document matched: draft-wu-trill-lsp-ext-tree-distr-opt-00.xml


<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wu-trill-lsp-ext-tree-distr-opt-00"
     ipr="trust200902" updates="6325">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title abbrev="LSP extension for Distribution Tree">LSP extension for Tree
    Distribution Optimization across sites</title>

    <author fullname="Qin Wu" initials="Q." surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>bill.wu@huawei.com</email>
      </address>
    </author>

    <author fullname="Weiguo Hao" initials="W." surname="Hao">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>101 Software Avenue, Yuhua District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>haoweiguo@huawei.com</email>
      </address>
    </author>

    <date year="2012" />

    <area>Internet Area</area>

    <workgroup>Transparent Interconnection of Lots of Links Working
    Group</workgroup>

    <keyword>RFC</keyword>

    <keyword>Request for Comments</keyword>

    <keyword>I-D</keyword>

    <keyword>Internet-Draft</keyword>

    <keyword>Transparent Interconnection of Lots of Links Protocol</keyword>

    <abstract>
      <t>This document specifies an extension to LSP for the Rbridge in one
      site to advertise Global VLAN scope and associated link attribute to all
      the Rbridges both in the site of that Border Rbridge and the other
      adjacent sites in the same campus. With this extension, RBridges can
      prune the distribution tree of multi-destination frames according to the
      scope of the VLAN and link attribute defined in this document.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>IS-IS was designed to be multilevel <xref target="IS-IS"></xref><xref
      target="RFC1195"></xref>. A trill Campus network may also be designed to
      be multilevel, e.g., partition it into multiple “sites” in 2-level.
      Routing between Rbridges within a site is known as "Level 1 routing".
      Routing between sites is known as "Level 2 routing". The Level 2 Trill
      site network with Level 2 routing support consists of Border Rbridges
      and links between the Border Rbridges. Border Rbridges may participate
      in one or more sites as Level-1 Rbridges inside each site, in addition
      to their role as Level 2 Rbridge across sites.</t>

      <t>In case of multiple sites within one Trill campus network, some
      subset of traffic on a number of VLANs traverses across sites within the
      TRILL campus while some subset of traffic belonging to a number of other
      VLANs may be limited to only one site and not allowed to go to other
      sites. In order to support scaling and performance of large TRILL
      networks in the real deployments, it is more desirable to forward Multi-
      destination traffic within the site and reduce the traffic that is
      required to span across sites within the entire TRILL campus.</t>

      <t>The scope of global traffic may be identified either through VLAN or
      link type that is used between Rbridges. When it is inevitable to
      construct trees that have a scope across sites throughout the TRILL
      campus, it is necessary to treat traffic based on VLAN scope and
      distinct the link between Rbridge in one site and link between two
      Border Rbridge in two sites to support large scale multi-tenants
      application.</t>

      <t>This document specifies an extension to LSP for the Rbridge in one
      site to advertise Global VLAN scope and associated link attribute to all
      the Rbridges both in the site of that Border Rbridge and the other
      adjacent sites in the same campus. With this extension, RBridges can
      prune the distribution tree of multi-destination frames according to the
      scope of the VLAN and link attribute defined in this document.</t>
    </section>

    <section title="Conventions used in this document">
      <t>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 <xref
      target="RFC2119">RFC2119</xref>.</t>
    </section>

    <section title="TLV and Sub-TLV Extensions to IS-IS for Inter-site Distribution Tree">
      <t>This section describes data formats and code points for the TLVs and
      sub-TLVs added to IS-IS defined by this specification to support the
      multi-level TRILL or re-used from that already contained in the standard
      IS-IS extensions defined in <xref target="RFC6326"></xref>.</t>

      <section title="Global-VLANs Sub-TLV for the Router Capability TLV">
        <t>The optional Global-VLANs sub-TLV specifies the VLANs that have
        global scope and enable Construction of global multi-destination trees
        among different sites. It has the following format:<figure
            title="Figure 1: Report Block Structure">
            <artwork>
   +-+-+-+-+-+-+-+-+
   |     Type      |                  (1 byte)
   +-+-+-+-+-+-+-+-+
   |   Length      |                  (1 byte)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | RESV  |  Start VLAN ID        |  (2 bytes)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | VLAN bit-map....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          </figure></t>

        <section title="Definition of Fields in Sub-TLV">
          <t><list style="hanging">
              <t hangText="Type: 8bits"><vspace blankLines="1" />Router
              Capability sub-TLV type, set to TBD (GLOBAL-VLANs).<vspace
              blankLines="1" /></t>

              <t hangText="Length: 8bits"><vspace blankLines="1" />Variable,
              minimum 3.<vspace blankLines="1" /></t>

              <t hangText="RESV: 4bits"><vspace blankLines="1" />4 reserved
              bits that MUST be sent as zero and ignored on receipt.<vspace
              blankLines="1" /></t>

              <t hangText="Start VLAN ID:12bits"><vspace blankLines="1" />The
              12-bit VLAN ID that is represented by the high order bit of the
              first byte of the VLAN bit-map.<vspace blankLines="1" /></t>

              <t hangText="VLAN bit-map:"><vspace blankLines="1" />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.<vspace
              blankLines="1" /></t>
            </list></t>
        </section>
      </section>

      <section title="Link-Attributes Sub-TLV extension for extended IS reachability TLV">
        <t>The link-attribute sub-TLV is carried within the TLV 22 and has a
        format identical to the sub-TLV format used by the Traffic Engineering
        Extensions for IS-IS (<xref target="RFC3784"></xref>): 1 octet of
        sub-type, 1 octet of length of the value field of the sub-TLV followed
        by the value field -- in this case, a 16 bit flags field.</t>

        <t>The Link-attribute sub-type is 19 and the link-attribute has a
        length of 2 octets.</t>

        <t>This sub-TLV is OPTIONAL and MUST appear at most once for a single
        IS neighbor. If a received Link State Packet (LSP) contains more than
        one Link-Attribute Sub-TLV, an implementation SHOULD decide to
        consider only the first encountered instance. The following bit is
        defined:<list style="hanging">
            <t hangText="Public Link Type For TRILL(0x03)">When set, this
            indicates that the link is public link for TRILL sites
            interconnection.</t>
          </list></t>
      </section>
    </section>

    <section title="Use of TLV and Sub-TLV for Tree Distribution Optimization within or across sites">
      <t>When the TRILL campus is divided into multiple sites, each site may
      have one or more Border Rbridges used to interconnect other remaining
      sites and form the Level 2 IS-IS Trill network which consists of Level 2
      Rbridges and links between the Level 2 Rbridges. Such Level2 IS-IS Trill
      network can be used to construct global multi-destination tree spanning
      across various sites. <figure anchor="fig1"
          title="Example of multiple sites within one Trill Campus">
          <artwork>
     TRILL Site 1                              TRILL Site 2
+-------------------+  +---------------+   +-------------------+
|                   |  |               |   |                   |
| +---+      +----+ |  |      WAN      |   |+----+       +---+ |
| |RB1|------+BRB2| |--|L2 Connectivity|---||BRB3|-------|RB4| |
| +---+      +----+ |  |               |   |+----+       +---+ |
|                   |  |               |   |                   |
+-------------------+  +---------------+   +-------------------+
                                |
                                |
                      +-------------------+
                      |      +----+       |
                      |      |BRB5|       |
                      |      +----+       |
                      | +---+   |   +---+ |
                      | |RB6|---+---|RB7| |
                      | +---+       +---+ |
                      +-------------------+
                          TRILL Site 3
</artwork>
        </figure></t>

      <t>However in order to support scaling and performance of large TRILL
      networks in the real deployments, firstly, not all the links between the
      level 2 Rbridges need to be used to Construct global multi- destination
      trees. If the link between the level 2 Rbridges is allowed to construct
      global multi-destination trees, we can set this link attribute into
      public interface for global tree construction. In this document, we
      reuse Link Attribute sub-TLV for the extended IS reachability TLV and
      allocate a new bit value inside link Attribute Sub-TLV to support
      indication of public link for global tree construction. The border
      Rbridge in one site need to advertise this link attribute Sub-TLV to all
      the neighboring Border Rbridges in other neighboring sites and then this
      sub-TLV will be further forwarded to all the Rbridges in the site of
      each neighboring Border Rbridge. RBridges in each site can prune the
      distribution tree of multi- destination frames according to such link
      attribute.</t>

      <t>Secondly, not all traffic should have global scope and need to span
      across sites. Since each distribution tree SHOULD be pruned per VLAN
      according to <xref target="RFC6325"></xref>, we can use specified Global
      VLAN to identify the traffic that has global scope. In this document, we
      define one new sub-TLV for the Router Capability TLV, i.e., Global-
      VLANs Sub-TLV. This Sub-TLV can be used by Rbriges in one site to
      determine whether Construction of global multi-destination trees across
      sites is allowed. In order to achieve this, the tree root or highest
      priority RBridge in one site configured to know a number of appropriate
      VLANs as Global VLANs and announce such information to the nearest
      border Rbrige; Then such border Rbridge in this site need to advertise
      Global VLAN Sub-TLV to all the neighboring Border Rbridges in other
      neighboring sites and then this sub-TLV will be further forwarded to all
      the Rbridges in the site of each neighboring Border Rbridge. When Global
      VLAN and link attribute Sub-TLV described above has been distributed to
      each Rbridges, RBridges can prune the distribution tree of
      multi-destination frames according to the scope of the VLAN and link
      attribute defined in this document, eliminating branches that own link
      type mismatching with Distribution Tree scope identified by VLAN. If the
      distribution tree is local tree and there is a branch including a link
      with link attribute is set to public link for global tree construction,
      such branch should be eliminated. If the distribution tree is global
      tree and there is one branch containing a link with link attribute not
      set to public link for global tree construction, such branch also should
      be eliminated. <figure anchor="fig2" title="Distribution Tree">
          <artwork>
          +---+
          | a |
          +---+
     L1 \       \  L2
      \           \
     \              \
   +---+           +---+
   | b |           | c |
   +---+           +---+
              L3  \      \ L4
  VLAN20         \         \
               \             \
             +---+         +---+
             | d |         | e |
             +---+         +---+
               _             _
               _             _     \
public link    _L5           _L6     \ L7
               _             _         \
             +---+         +---+      +---+
             | f |         | g |      | h |
             +---+         +---+      +---+

             VLAN10        VLAN10    VLAN20
</artwork>
        </figure></t>

      <t>Take distribution tree in the <xref target="fig2"></xref> as an
      example, Rbridge a is root node. Rbridge f,g are leaf nodes that have
      end station on VLAN 10 while Rbridge b,h are another two leaf nodes and
      that have end station on VLAN 20. The link between Rbridge d and f is
      public link used across sites while the other links in the figure 2 are
      link owns by one single site. Assume VLAN 10 are local VLAN and VLAN 20
      are Global VLAN, after distribution tree pruning is done, Rbrige c
      should eliminate branch that has Rridge d and f since distribution tree
      is pruned based on local VLAN 10 and Link 5 in that branch is public
      link, which mismatch with each other.</t>
    </section>

    <section title="IANA Considerations">
      <t>IANA is requested to assign a new codepoint for the Global-VLANs
      Sub-TLV defined in this document and carried within TLV 242.</t>

      <t>IANA has created a registry for bit values inside the link-attributes
      sub-TLV called “link-attribute bit values for sub-TLV 19 of TLV 22”.</t>

      <t>This document instructs IANA to add a new bit value in the
      link-attribute bit values for sub-TLV 19 of TLV 22 registry as
      follows:<figure>
          <artwork>
Value   Name                              Reference
-----   ----                              ---------
0x3    Public Link Type between sites   [This document]
</artwork>
        </figure></t>

      <t>Further values are to be allocated by the Standards Action process
      defined in <xref target="RFC2434"></xref>, with Early Allocation
      (defined in <xref target="RFC4020"></xref>) permitted.</t>
    </section>

    <section title="Security Considerations">
      <t>The security considerations documented in <xref
      target="RFC4971"></xref><xref target="RFC5305"></xref> are applicable
      for the Sub-TLV extension defined in this document.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>- +1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997" />

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <t>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 RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="RFC1195">
        <front>
          <title>Use of OSI IS-IS for routing in TCP/IP and dual
          environments</title>

          <author fullname="Masataka Ohta" initials="M." surname="Ohta">
            <organization></organization>
          </author>

          <date month="December" year="1990" />

          <abstract>
            <t>This document defines the Extended Report (XR) packet type for
            the RTP Control Protocol (RTCP), and defines how the use of XR
            packets can be signaled by an application if it employs the
            Session Description Protocol (SDP). XR packets are composed of
            report blocks, and seven block types are defined here. The purpose
            of the extended reporting format is to convey information that
            supplements the six statistics that are contained in the report
            blocks used by RTCP's Sender Report (SR) and Receiver Report (RR)
            packets. Some applications, such as multicast inference of network
            characteristics (MINC) or voice over IP (VoIP) monitoring, require
            other and more detailed statistics. In addition to the block types
            defined here, additional block types may be defined in the future
            by adhering to the framework that this document provides.</t>
          </abstract>
        </front>
      </reference>

      <reference anchor="RFC6326">
        <front>
          <title>Transparent Interconnection of Lots of Links (TRILL) Use of
          IS-IS</title>

          <author fullname="Donald Eastlake" initials="D." surname="Eastlake ">
            <organization>Columbia University</organization>
          </author>

          <author fullname="Ayan Banerjee" initials="A." surname="Banerjee">
            <organization></organization>
          </author>

          <author fullname="Dinesh Dutt" initials="D." surname="Dutt">
            <organization></organization>
          </author>

          <author fullname="Radia Perlman" initials="R." surname="Perlman">
            <organization></organization>
          </author>

          <author fullname="Anoop Ghanwani" initials="A." surname="Ghanwani">
            <organization></organization>
          </author>

          <date month="July" year="2011" />
        </front>

        <seriesInfo name="RFC" value="6326" />

        <format type="TXT" />
      </reference>

      <reference anchor="RFC6325">
        <front>
          <title>Routing Bridges (RBridges): Base Protocol
          Specification</title>

          <author fullname="Radia Perlman" initials="R." surname="Perlman">
            <organization></organization>
          </author>

          <author fullname="Donald Eastlake" initials="D." surname="Eastlake ">
            <organization>Columbia University</organization>
          </author>

          <author fullname="Dinesh Dutt" initials="D." surname="Dutt">
            <organization></organization>
          </author>

          <author fullname="Silvano Gai" initials="S." surname="Gai">
            <organization></organization>
          </author>

          <author fullname="Anoop Ghanwani" initials="A." surname="Ghanwani">
            <organization></organization>
          </author>

          <date month="July" year="2011" />
        </front>

        <seriesInfo name="RFC" value="6325" />

        <format type="TXT" />
      </reference>

      <reference anchor="RFC3784">
        <front>
          <title>Intermediate System to Intermediate System (IS-IS) Extensions
          for Traffic Engineering (TE)</title>

          <author fullname="H. Smit" initials="H." surname="Smit">
            <organization></organization>
          </author>

          <date month="June" year="2004" />
        </front>
      </reference>

      <reference anchor="RFC5029">
        <front>
          <title>SDP: Session Description Protocol</title>

          <author fullname="JP Vasseur" initials="J." surname="Vasseur">
            <organization></organization>
          </author>

          <author fullname="Stefano Previdi" initials="S." surname="Previdi">
            <organization></organization>
          </author>

          <date month="September" year="2007" />
        </front>
      </reference>

      <reference anchor="RFC2434">
        <front>
          <title>Guidelines for Writing an IANA Considerations Section in
          RFCs</title>

          <author fullname="Thomas Narten" initials="T." surname="Narten">
            <organization>Columbia University</organization>
          </author>

          <author fullname="Harald Tveit Alvestrand" initials="H."
                  surname="Alvestrand">
            <organization></organization>
          </author>

          <date month="October" year="1998" />
        </front>

        <seriesInfo name="RFC" value="2434" />

        <format type="TXT" />
      </reference>

      <reference anchor="RFC4020">
        <front>
          <title>Early IANA Allocation of Standards Track Code Points</title>

          <author fullname="K.Kompella" initials="K." surname="Kompella">
            <organization>Columbia University</organization>
          </author>

          <author fullname="A. Zinin" initials="A." surname="Zinin">
            <organization></organization>
          </author>

          <date month="February" year="2005" />
        </front>

        <seriesInfo name="RFC" value="4020" />

        <format type="TXT" />
      </reference>

      <reference anchor="RFC4971">
        <front>
          <title>Intermediate System to Intermediate System (IS-IS) Extensions
          for Advertising Router Information</title>

          <author fullname="Jean-Philippe Vasseur" initials="J."
                  surname="Vasseur">
            <organization></organization>
          </author>

          <date month="July" year="2007" />
        </front>
      </reference>

      <reference anchor="RFC5305">
        <front>
          <title>S-IS Extensions for Traffic Engineering</title>

          <author fullname="Tony Li" initials="T." surname="Li">
            <organization>Columbia University</organization>
          </author>

          <author fullname="Henk Smit" initials="H." surname="Smit">
            <organization></organization>
          </author>

          <date month="October" year="2008" />
        </front>

        <seriesInfo name="RFC" value="5305" />

        <format type="TXT" />
      </reference>

      <reference anchor="IS-IS">
        <front>
          <title>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)</title>

          <author>
            <organization></organization>
          </author>

          <date year="2002" />
        </front>

        <seriesInfo name="ISO/IEC 10589:2002" value="Second Edition" />
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="TRILL-ML">
        <front>
          <title>RBridges: Multilevel TRILL</title>

          <author fullname="Radia Perlman" initials="R." surname="Perlman ">
            <organization></organization>
          </author>

          <author fullname="Donald Eastlake" initials="D." surname="Eastlake">
            <organization></organization>
          </author>

          <author fullname="Anoop Ghanwani" initials="A." surname="Ghanwani">
            <organization></organization>
          </author>

          <author fullname="Hongjun Zhai" initials="H." surname="Zhai">
            <organization></organization>
          </author>

          <date month="October" year="2011" />
        </front>

        <seriesInfo name="ID"
                    value="draft-perlman-trill-rbridge-multilevel-03" />
      </reference>
    </references>
  </back>
</rfc>

PAFTECH AB 2003-20262026-04-24 01:37:41