TRILL Working Group Donald Eastlake
INTERNET-DRAFT Mingui Zhang
Intended status: Proposed Standard Huawei
Radia Perlman
Intel Labs
Expires: January 3, 2012 July 4, 2011
RBridges: Multi-Topology Data Plane
<draft-eastlake-trill-rbridge-multi-topo-00.txt>
Abstract
The IETF has standardized RBridges (Routing Bridges), devices that
implement the TRILL (TRansparent Interconnection of Lots of Links)
protocol, a solution for least cost transparent frame routing in
multi-hop networks with arbitrary topologies, using IS-IS
(Intermediate System to Intermediate System) link-state routing and
encapsulation with a hop count.
IS-IS supports multi-topology routing. This document specifies a
TRILL data plane encoding to make use of such routing.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent
to the TRILL working group mailing list.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
D. Eastlake, et al [Page 1]
INTERNET-DRAFT RBridges: Multi-Topology Data Plane
Table of Contents
1. Introduction............................................3
1.1 Terminology............................................3
2. TRILL Multi-Topology (MT)...............................4
2.1 Nicknames and Topology Abbreviation....................4
2.2 Nickname Allocation....................................5
2.3 SPF and Distribution Tree Calculation..................5
3. Processing Multi-Topology Frames........................7
3.1 Ingress Processing.....................................7
4.2 Transit Processing.....................................7
4.3 Egress Processing......................................7
4.4 Address Learning.......................................7
5. IS-IS Extensions........................................8
6. IANA Considerations.....................................9
7. Security Considerations.................................9
8. References.............................................10
8.1 Normative References..................................10
8.2 Informative References................................10
D. Eastlake, et al [Page 2]
INTERNET-DRAFT RBridges: Multi-Topology Data Plane
1. Introduction
The IETF has standardized RBridges (Routing Bridges), devices that
implement the TRILL (TRansparent Interconnection of Lots of Links)
protocol [RFCtrill], a solution for least cost transparent frame
routing in multi-hop networks with arbitrary topologies, using IS-IS
(Intermediate System to Intermediate System) link-state routing [IS-
IS] [RFC1195] [ISIStrill] and encapsulation with a hop count.
TRILL supports VLANs (Virtual Local Area Networks) but the
segregation provided by VLANs is logical, especially so with TRILL.
While maintaining logical separation, the base TRILL standard shares
inter-RBridge links across all VLANs and by default interconnects all
end stations that are in the same VLAN and have connectivity to any
RBridge in the campus.
IS-IS multi-topology [RFC5120] can provide physical separation of
classes of TRILL Data frames, assuming that the RBridges in a campus
can be trusted. This can be used for a variety of purposes including
such things as confining traffic to isolated islands within an
RBridge campus, quality of service traffic engineering, excluding
some frames from links that are particularly exposed to interception,
and providing significant protection against some covert channels
[RFC4949].
Familiarity with the TRILL base protocol standard [RFCtrill], TRILL
use of IS-IS [ISIStrill], and IS-IS multi-topology [RFC5120] is
assumed in this document.
1.1 Terminology
The terminology and acronyms of [RFCtrill] are used in this document
with the additions listed below.
MT - Multi-Topology
TAS - Topology Abbreviation Size
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].
D. Eastlake, et al [Page 3]
INTERNET-DRAFT RBridges: Multi-Topology Data Plane
2. TRILL Multi-Topology (MT)
The essence of TRILL multi-topology (MT) is that (a) when TRILL Data
frames are ingressed or created they are assigned to a topology, (b)
links can be labeled with one or more topologies and different cost,
etc., for different topologies, and (c) a TRILL Data frame is only
allowed on a link labeled with the frame's topology. In addition,
there is a base topology: all links are considered to be labeled to
allow frames in the base topology, and, by default, TRILL Data frames
are considered to be base topology frames.
With minor exceptions, it is important that all transit RBridges
believe a TRILL Data frame is in the same topology to avoid
persistent routing loops. This document specifies how to encode this
information into the egress nickname in a TRILL Data frame. (It is
believed that this technique is supportable by most if not all TRILL
fast path silicon implementations as of the date of this document.)
Implementation of MT has a significant impact on shortest path and
distribution tree computation. In general, it multiplies the level of
effort by the number of different topologies. Using the technique in
this document, it also reduces the number of of available nicknames,
generally dividing it by the number of topologies rounded up to the
next power of two. For these reasons, the number of topologies in use
should be minimized.
2.1 Nicknames and Topology Abbreviation
The TRILL base protocol standard [RFCtrill] specifies 16-bit
nicknames as abbreviations for RBridge IS-IS System IDs. In MT TRILL
the nickname is subdivided into two fields. The least significant TAS
(Topology Abbreviation Size) number of bits indicate the topology
constraints of the nickname while the most significant ( 16 - TAS )
bits continue to act as an abbreviation for an RBridge System ID.
The TAS value for an MT RBridge campus is dictated by the RBridge
that is the highest priority to be a distribution tree root. The
value of TAS can vary from zero to seven. Zero is permitted and
indicates that only the base topology can be used.
In IS-IS, topologies have a 12-bit ID which we refer to as an
absolute topology number. Topology zero is the base topology. All
links are considered to be part of the base topology. Absolute
topology numbers are mapped into abbreviations by a table dictated by
the RBridge that is the highest priority to be a distribution tree
root. In the opening remarks to this Section 2, "topology" should be
read as referring to topology abbreviation.
D. Eastlake, et al [Page 4]
INTERNET-DRAFT RBridges: Multi-Topology Data Plane
Multiple absoolute topology numbers MAY be mapped into the same
abbreviation. This may or may not result in the merger of the mapped
absolute topologies depending on whether their use is disjoint or
overlapping. Absolute topology zero and topology abbreviation zero
always refers to the base topology.
For example, assume that absolute topologies T1 and T2 exist and are
both mapped into the same abbreviation, say 3. If all RBridges
reachable by links labeled T1 or T2 are connected through such links,
then, since MT TRILL forwarding is based on the topology
abbreviation, T1 and T2 are necessarily merged to the extent both
topologies are in use. On the other hand, such RBridges could be
divided into disjoint islands with no connection via T1 or T2 links.
In that case, depending on how frames are topologically classified on
ingress and egress, each such island could independently be
exclusively T1, exclusively T2, merged T1 and T2, or unused.
2.2 Nickname Allocation
RBridges indicate in their LSP whether they support MT by the
presence of the MT TLV [RFC5120]. If all RBridges in a campus support
MT, then RBridges can be configured for and contend for nicknames as
provided in [RFCtrill], but only for nicknames that have TAS number
of low order zero bits. If there are any RBridges in the campus that
do not support MT, then MT RBridges must hold all nicknames from ( k
* 2**TAS ) through ( (k+1) * 2**TAS - 1 ) in order to, in effect,
hold nickname ( k * 2**TAS ).
RBridges not supporting MT are unaware of the subdivision of the
TRILL nickname into subfields. Thus, they may hold artbirary 16-bit
allowed quanities as nicknames. MT aware RBridges know that the
bottom TAS bits of any nicknames held by such MT unaware RBridges are
not topologically significant.
2.3 SPF and Distribution Tree Calculation
Since MT TRILL cannot impose any changes on MT unaware RBridges,
those RBridges will perform their SPF and distribution tree
calculations as specified in [RFCtrill]. For compatibility, MT aware
RBridge MUST perform their base topology SPF and distribution tree
calculations in the same way. MT aware RBridges do this even if one
or more non-zero absolute topologies are being mapped into the base
topology abbreviation zero.
For MT aware RBridges, least cost (SPF) paths are calculated per
topology abbreviation for the abbreviations labeling any link
D. Eastlake, et al [Page 5]
INTERNET-DRAFT RBridges: Multi-Topology Data Plane
connected to that RBridge. For topologies other than the base
toplogy, link costs from the MT-ISN TLV (TLV #222 [RFC5120]) are
used; however, such costs are reported per absolute topology, not per
topology abbreviation. This is resolved for non-zero abbreviations
by using, in SPF calculations, the lowest cost reported for the link
for any absolute topology corresponding the topology abbreviation for
which the calculation is being performed. Non-base topologies do not
necessarily span the campus and there may be RBridges that are
unreachable in such topologies. Frames destined for unreachable
RBridges are discarded.
Distribution trees are also calculated per topology abbreviation by
MT aware RBridges. Such trees are built as described in [RFCtrill]
with the following differences for non-zero topology abbreviations:
1. Link costs are as described in the preceding paragraph on TRILL MT
SPF calculations.
2. The tree root nicknames(s) for the distribution tree(s) for a
particular topology abbreviation are determined using the Trees
sub-TLVs and Tree Identifiers sub-TLVs for all of the absolute
topologies that are mapped into the topology abbreviation for
which distribution tree(s) are being calculated. All nicknames
appearing in these sub-TLVs MUST have their lower TAS number of
bits zero. more tbd
3. Number of trees. What happens if you have 25 topologies but some
of your RBridges only support 16 distribution trees?
D. Eastlake, et al [Page 6]
INTERNET-DRAFT RBridges: Multi-Topology Data Plane
3. Processing Multi-Topology Frames
This section specifies ingress, transit, and egress processing of MT
TRILL Data frames.
3.1 Ingress Processing
On ingressing or creating a frame, an RBridge assigns it to an
absolute topology ID. The method by which this 12-bit topology ID is
assigned is beyond the scope of this document.
The resulting absolute ID is mapped to a topology abbreviation. That
abbreviation is used as the bottom TAS bits in the ingress nickname
field of the resulting TRILL Data frame. For a unicast native frame,
that abbreviation, the VLAN, and the destination MAC address are used
to look up the egress nickname field. If the destination is unknown,
or the native frame is multicast or broadcast, the ingress RBridge
selects a distribution tree
4.2 Transit Processing
No change is required in transit frame processing assuming that SPF
and distribution tree calculations have been performed as specified
in Section 2.3.
4.3 Egress Processing
4.4 Address Learning
D. Eastlake, et al [Page 7]
INTERNET-DRAFT RBridges: Multi-Topology Data Plane
5. IS-IS Extensions
For the general extension of TRILL use of IS-IS to make use of the
multi-topology features of IS-IS, see [trill-mt-control].
In addition, a topology mapping sub-TLV is required, as specified in
[trill-mt-control]. This sub-TLV is across all topologies and occurs
in the Router Capabilities TLV. It specifies the TAS for the campus
and provides a mapping from absolute topology IDs to topology
abbreviations. Absolute topology zero is always mapped to topology
abbreviation zero. No entry is needed for this base topology mapping
and any other mapping for topology zero is ignored. Multiple absolute
topologies may be mapped to the same abbreviation. If there are
mappings of the same absolute topology to multiple abbreviations, the
largest abbreviation, considered as an unsigned integer dominates.
D. Eastlake, et al [Page 8]
INTERNET-DRAFT RBridges: Multi-Topology Data Plane
6. IANA Considerations
TBD
7. Security Considerations
See [RFCtrill] for general RBridge Security Considerations.
As with any communications system, end-to-end encryption and
authentication should be considered for particularly sensitive data.
More TBD
D. Eastlake, et al [Page 9]
INTERNET-DRAFT RBridges: Multi-Topology Data Plane
8. References
The following sections list normative and informative references for
this document.
8.1 Normative References
[IS-IS] - International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in conjunction
with the protocol for providing the connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, Nov
2002.
[RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Intermediate
Systems (IS-ISs)", RFC 5120, February 2008.
[RFC 5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008.
[RFCtrill] - R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A.
Ghanwani, "RBridges: Base Protocol Specification", draft-ietf-
trill-rbridge-protocol-16.txt, in RFC Editor's queue.
[ISIStrill] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, A.
Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-trill-05.txt,
in RFC Editor's queue.
[trill-mt-control] - Manral, V., D. Eastlake, M. Zhang, A. Banerjee,
"Multi Topology Routing Extensions for Transparent
Interconnection of Lots of Links (TRILL)", draft-manral-isis-
trill-multi-topo-01.txt, work in progress.
8.2 Informative References
[RFC4949] - Shirey, R., "Internet Security Glossary, Version 2", FYI
36, RFC 4949, August 2007.
D. Eastlake, et al [Page 10]
INTERNET-DRAFT RBridges: Multi-Topology Data Plane
9. Acknowledgements
The comments and contributions of the following are gratefully
acknowledged:
TBD.
Authors' Addresses
Donald Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Mingui Zhang
Huawei Technologies Co., Ltd
HuaWei Building, No.3 Xinxi Rd., Shang-Di
Information Industry Base, Hai-Dian District,
Beijing, 100085 P.R. China
Email: zhangmingui@huawei.com
Radia Perlman
Intel Labs
2200 Mission College Blvd.
Santa Clara, CA 95054 USA
Phone: +1-408-765-8080
Email: radia@alum.mit.edu
D. Eastlake, et al [Page 11]
INTERNET-DRAFT RBridges: Multi-Topology Data Plane
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2011 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. The definitive version of
an IETF Document is that published by, or under the auspices of, the
IETF. Versions of IETF Documents that are published by third parties,
including those that are translated into other languages, should not
be considered to be definitive versions of IETF Documents. The
definitive version of these Legal Provisions is that published by, or
under the auspices of, the IETF. Versions of these Legal Provisions
that are published by third parties, including those that are
translated into other languages, should not be considered to be
definitive versions of these Legal Provisions. For the avoidance of
doubt, each Contributor to the IETF Standards Process licenses each
Contribution that he or she makes as part of the IETF Standards
Process to the IETF Trust pursuant to the provisions of RFC 5378. No
language to the contrary, or terms, conditions or rights that differ
from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
D. Eastlake, et al [Page 12]