One document matched: draft-wu-trill-lsp-ext-tree-distr-opt-01.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-01"
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>Large datacenters are often multi-site in nature and may contain a
large number of Rbridges in each site. A trill Campus network may also
be designed to be multilevel can be divided in to multiple IS-IS <xref
target="IS-IS"></xref><xref target="RFC1195"></xref>L1 Areas
interconnected by L2 backbone area. Routing between Rbridges within a
IS-IS L1 area/ site is known as "Level 1 routing". Routing between IS-IS
L1 areas or sites is known as "Level 2 routing". The IS-IS L1 area
supports Level 1 routing and consists of Rbridges within the site and
link between Rbridges within the site. The L2 backbone area supports
Level 2 routing and consists of Border Rbridges and links between the
Border Rbridges. Border Rbridges may participate in one or more L1 areas
as Level-1 Rbridges inside each site, in addition to their role as Level
2 Rbridge across sites.</t>
<t>In Trill campus network, RBridges use distribution trees to forward
multi-destination frames. In case of one Trill campus network having
multiple sites, the traffic associated with some distributed trees may
travel between sites while the traffic associated with other distributed
trees may be limited to only one site and not allowed to go across other
sites. The traffic spanning across sites is also referred to as the
traffic with global scope. In order to support scaling and performance
of large TRILL networks in the real deployments, it is desirable to
forward most of Multi-destination Trill traffic within the site and
reduce the traffic that is required to span across sites within the
entire TRILL campus. According to The TRILL base protocol, each
distribution tree SHOULD be pruned per VLAN. When it is inevitable to
construct trees that have a scope across sites throughout the TRILL
campus, it is necessary to treat traffic tagged with VLAN differently
based on VLAN scope and distinct the link between Rbridges 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="Motivations">
<t>Distinguishing global vlan from local vlan is to increase the number
of tenants by not breaking the VLAN tag size limits. E.g. one campus
being divided into n sites, without distinction between global vlan and
local vlan, at most support 4K tenants. However, if we distinguish
global vlan from local vlan, suppose each site support only local vlan.
Then each site support 4K tenants, the total number of tenants supported
by one campus can be increased to 4n*K.Suppose some sites support local
vlan, some sites support both local vlan and global vlan, the total
number of tenants supported by one campus (4K,4n*K).</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 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. 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>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 specify a set of
Global VLANs 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 Rbridge; 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 all the corresponding Rbridges in the downstream of the
tree root or highest priority RBridge, 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 has
branches including a link with link attribute is set to public link for
global tree construction, those branches should be eliminated. If the
distribution tree is global tree and has branches containing a link with
link attribute not set to public link for global tree construction,
those branches 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 <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 links owned
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="Unicast Forwarding Consideration">
<t>In unicast forwarding, the MAC forwarding table for a Trill Border
Rbridge is usually learned through the data plane, i.e.,MAC address is
learnt from received Broadcast,Unknown, Unicast,Multicast packet through
distribution tree. For end stations on the local vlan, the broadcast
scope is limited to one local site, the Border Rbridge only learns MAC
address of locally attached end station and the forwarding path between
end stations within one site can be built for unicast. For end stations
on global VLAN, end stations between two sites are within the same layer
2 broadcast domain, the Border Rbridge can learn MAC address of end
stations across sites and the forward path between two sites can be
built as well for unicast. Therefore unicast forwarding between sites
can be controlled through LSP extension we defined in this document.</t>
<t>If the Border Rbridge is statically configured with unicast
forwarding table and the nickname of the destination Rbridge is
specified as one Rbridge’s nickname in other sites, the unicast packet
must be forced to forward to the other sites. In this case, the Border
Rbridge in other sites performs security check to the received packet.
If the VLAN associated with the received packet is local VLAN and the
packet is ingressed from public link across site, the packet should be
discarded. If the VLAN associated with the received packet is Global
VLAN, the packet should be allowed to ingress from public link across
sites.</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>
<section title="Change Logs">
<section title="draft-wu-trill-lsp-ext-tree-distr-opt-01">
<t>The following are the major changes to previous version
draft-wu-trill-lsp-ext-tree-distr-opt-00: <list style="symbols">
<t>Add one new section to discuss Unicast Forwarding.</t>
<t>Add one new section to clarify the motivation to write this
draft.</t>
<t>Some other editorial changes.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:36:48 |