Internet DRAFT - draft-eastlake-trill-rbridge-multi-topo
draft-eastlake-trill-rbridge-multi-topo
TRILL Working Group Donald Eastlake
INTERNET-DRAFT Mingui Zhang
Updates: 6325 Huawei
Intended status: Proposed Standard Radia Perlman
Intel Labs
Vishwas Manral
Hewlett-Packard
Ayan Banerjee
Cumulus
Expires: January 15, 2013 July 16, 2012
Multiple Topology TRILL
<draft-eastlake-trill-rbridge-multi-topo-03.txt>
Abstract
The IETF TRILL (TRansparent Interconnection of Lots of Links)
protocol is a solution for least cost transparent frame routing in
multi-hop networks with arbitrary topologies and link technologies,
using IS-IS (Intermediate System to Intermediate System) link-state
routing and encapsulation with a hop count. IS-IS supports multiple
topology routing. This document specifies a TRILL data plane encoding
and procedures 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 TRILL: Multi-Topology
Table of Contents
1. Introduction............................................3
1.1 Terminology............................................3
2. TRILL Multi-Topology....................................4
2.1 Nicknames and Topology Abbreviation....................4
2.2 Nickname Allocation....................................5
2.3 SPF and Distribution Tree Calculation..................6
2.3.1 Base Topology SPF....................................6
2.3.2 Non-Zero Topology SPF................................6
2.3.3 Distribution Tree Calculation........................6
3. Processing Multi-Topology Frames........................8
3.1 Ingress Processing.....................................8
3.2 Transit Processing.....................................8
3.3 Egress Processing......................................9
3.4 Address Learning and Asymmetric Topologies.............9
5. IS-IS Extensions.......................................10
6. IANA Considerations....................................11
7. Security Considerations................................11
8. Acknowledgements.......................................11
9. References.............................................12
9.1 Normative References..................................12
9.2 Informative References................................12
D. Eastlake, et al [Page 2]
INTERNET-DRAFT TRILL: Multi-Topology
1. Introduction
The IETF has standardized RBridges (Routing Bridges), devices that
implement the TRILL (TRansparent Interconnection of Lots of Links)
protocol [RFC6325], 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] [RFC6326bis] and encapsulation with a hop count.
TRILL supports VLANs (Virtual Local Area Networks) but the
segregation provided by VLANs in TRILL is logical, not physical.
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
sub-sets 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 a sub-set traffic to an island 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 [RFC6325], TRILL
use of IS-IS [RFC6326bis], and IS-IS multi-topology [RFC5120] is
assumed in this document.
1.1 Terminology
The terminology and acronyms of [RFC6325] are used in this document
with the additions listed below.
Highest Priority RBridge - The RBridge in the campus that is the
highest priority to be a base topology tree root.
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 TRILL: Multi-Topology
2. TRILL Multi-Topology
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 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. (Note: It
is believed that this technique is supportable by most if not all
TRILL fast path silicon implementations.)
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 in which the average
RBridge participates. 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 overlapping topologies in use should be
minimized.
2.1 Nicknames and Topology Abbreviation
The TRILL base protocol standard [RFC6325] specifies 16-bit nicknames
as abbreviations for 7-bytes IS-IS IDs. In MT TRILL the nickname is
subdivided into two fields. The least significant TAS (Topology
Abbreviation Size) number of bits indicate the topology constraint 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 highest
priority RBridge. To prevent transient disruption, other RBridges
that might become the highest priority RBridge SHOULD be configured
with the same TAS value. The value of TAS can vary from zero to
seven. Zero 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 highest priority RBridge. To prevent transient disruption, other
RBridges that might become the highest priority RBridge should be
D. Eastlake, et al [Page 4]
INTERNET-DRAFT TRILL: Multi-Topology
configured with the same TAS topology abbreviation table. In the
opening remarks to this Section 2, "topology" should be read as
referring to topology abbreviation.
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 Tp1 and Tp2 exist and
are both mapped into the same specific abbreviation. If all RBridges
in the campus reachable by links labeled Tp1 or Tp2 are connected
through such links, then, since MT TRILL forwarding is based on the
topology abbreviation, Tp1 and Tp2 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 between the
islands via links allowing Tp1 or Tp2. In that case, depending on how
frames are topologically classified, each such island could
independently be exclusively Tp1, exclusively Tp2, merged Tp1 and
Tp2, 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 [RFC6325], 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.
The nickname allocation described above and in [RFC6325] runs based
on the nickname priority values appearing in Router Capabilities TLVs
(TLV #242), which is what MT unaware RBridges will use. The Nicknames
sub-TLV is allowed in the MT Router Capabilities TLV (TLV #144) for
the sole purpose of permitting nicknames to have different priorities
to be root in different topologies; in particular, the Nicknames sub-
TLV field giving the priority to hold that nickname is ignore for
Nicknames sub-TLVs in the MT Router Capabilities TLV.
D. Eastlake, et al [Page 5]
INTERNET-DRAFT TRILL: Multi-Topology
2.3 SPF and Distribution Tree Calculation
This section discusses MT SPF and distribution tree calculation.
2.3.1 Base Topology SPF
Since MT TRILL cannot impose any changes on MT unaware RBridges,
those RBridges will perform their SPF and distribution tree
calculations as specified in [RFC6325]. For compatibility, MT aware
RBridge MUST perform their base topology SPF and distribution tree
calculations in the same way. In particular, the base topology
consists of those links listed in Extended IS Reachability TLVs (TLV
#22). For backward compatibility, MT aware RBridges use only links
listed in TLV #22 for the base topology, which SHOULD be all links,
even if there exist MT-ISN TLVs (TLV #222) listing topology zero or
if one or more non-zero absolute topologies are being mapped into the
base topology abbreviation zero.
2.3.2 Non-Zero Topology SPF
For MT aware RBridges, least cost (SPF) paths are also calculated per
topology abbreviation for the non-zero abbreviations labeling any
link connected to that RBridge. When paths are being calculated for a
topology abbreviation, only links labeled with absolute topologies
that map to that abbreviation are considered.
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.
2.3.3 Distribution Tree Calculation
Distribution trees are also calculated per topology abbreviation by
MT aware RBridges. At least one distribution tree is always built as
described in [RFC6325] for the base topology using the tree root
nickname priorities advertised in the Router Capabilities TLV. That
tree will span the campus. Care should be taken that the highest
priority RBridge is configured to not request too many distribution
D. Eastlake, et al [Page 6]
INTERNET-DRAFT TRILL: Multi-Topology
trees be calculated in the base topology. There may be silicon limits
to how many distribution trees can be efficienlty handled and too
many base topology trees could starve other topologies that should
have a distributon tree.
For non-zero topology abbreviations, a distribution tree will be
composed only of links that are in at least one of the absolute
topologies that map to that abbreviation and the tree may not span
the campus. Such distribution trees might not span the campus and
there might be multiple disjoint distribution trees for a particular
topology abbreviation.
The calculation of additional distribution trees for non-zero
topology abbreviations is accomplished using the same method of
building from root as described in [RFC6325] but using link costs as
described in the preceding section on TRILL non-zero topology SPF
calculations. The number of such trees may be constrained by the
capabilities of RBridges in the campus as advertised in the Trees
sub-TLV in the Router Capabilities TLV. However, that limit is of the
number of trees actually including that RBridge and would not
include, for example, a distribution tree for some topology present
only in a remote island of RBridges.
After the base topology trees are calculated, trees for non-zero
topologies are calculated, one per topology abbreviation, starting
with the highest topology abbreviation in use and working down to the
lowest non-zero topology. If additional tree are available and
requested, they are distrubted to the topology abbreviations. For the
details see Appendix ... [[Since it is important that all RBridges
agree on the calculation of distribution trees, I think this is going
to need some psudo code in an appendix.]]
D. Eastlake, et al [Page 7]
INTERNET-DRAFT TRILL: Multi-Topology
3. Processing Multi-Topology Frames
This section specifies ingress, transit, and egress processing of MT
TRILL Data frames, how asymetric topologies can occur, and address
learning.
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; however, different
frames with the same source MAC address, VLAN, and egress RBridge
SHOULD be assigned to the same topology. In TRILL, topology does not
provide another level of VLAN but identifies a subset of traffic.
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 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 for that
topology abbreviation that includes the ingress RBridge. If more than
one tree is available, the method of choice is beyond the scope of
this document, but by default, it should pick the tree whose root is
least cost from the ingress RBridge.
3.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.
The next hop RBridge for TRILL unicast frames will automatically be
restricted to the appropriate topology. The same applies to the zero
or more next hops for the tree that a TRILL multi-destination frame
is being distributed on. There is no change in the Reverse Path
Forwarding Check.
D. Eastlake, et al [Page 8]
INTERNET-DRAFT TRILL: Multi-Topology
3.3 Egress Processing
There is no change in egress processing.
3.4 Address Learning and Asymmetric Topologies
There is no change in address learning. This can result in
asymmetric topology use.
For example assume end stations ESa and ESb in the same VLAN-x
attached to RB1 and RB2 respectively want to communicate. Generally,
the initial frame from RB1 will be classified in topology
abbreviation T1 and sent on a T1 distribution tree which should be
pruned for VLAN-x. If that tree includes RB2, the frame will be
delivered to RB2 that will egress it to ESb or, if it has not yet
learned which of its links ESb is attached to, RB2 will egress the
frame to all of its links in VLAN-x for which it is appointed
forwarder [RFC6439]. In addition, RB2 will learn that ESa in VLAN-x
is attached to RB1 but the nickname it learns from RB1 will have T1
encoded in it so that RB1 also learns, that ESa is in T1. When ESb
send a return frame to ESa, RB2 will classify that frame as in
topology abbreviation T2, encode that in the ingress nickname of the
TRILL header, and send the frame to RB1 in T1 because the egress
nickname RB2 will use was that learned from the receipt of the above
frame from RB1 in T1. At this point, ESa and ESb can continue
communicating using TRILL unicast frames in each direction with
frames from ESa to ESb in T1 while those from ESb to ESa will be in
T2.
If it is desired that T1 equal T2, then RB1 and RB2 must be
configured to classify the incoming native frames as in the same
topology. Note that, if many topologies are in use but there are
fewer distribution trees, the initial ESa frame in the example above
might have been distributed in a T3 distribution tree. This will not
affect RB2 learning which will learn from the T1 topology encoded
into the ingress nickname in the encapsulated frame's TRILL Header.
D. Eastlake, et al [Page 9]
INTERNET-DRAFT TRILL: Multi-Topology
5. IS-IS Extensions
For the extensions to the TRILL use of IS-IS to make use multi-
topology, see [trill-mt].
These include the addition of a topology mapping sub-TLV. 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, and mappings of that
absolute topology to smaller abbreviations are ignored.
D. Eastlake, et al [Page 10]
INTERNET-DRAFT TRILL: Multi-Topology
6. IANA Considerations
IANA coniderations for this draft are in [trill-mt].
7. Security Considerations
See [RFC6325] 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
8. Acknowledgements
The comments and contributions of the following are gratefully
acknowledged:
Meenakshi Kaushik and Dinesh Dutt.
D. Eastlake, et al [Page 11]
INTERNET-DRAFT TRILL: Multi-Topology
9. References
The following sections list normative and informative references for
this document.
9.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.
[RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC6439] - Perlman, R., Eastlake, D., Li, Y., Banerjee, A., and F.
Hu, "Routing Bridges (RBridges): Appointed Forwarders", RFC
6439, November 2011.
[RFC6326bis] - Eastlake, D., A. Banerjee, D. Dutt, R. Perlman, A.
Ghanwani, "TRILL Use of IS-IS", draft-eastlake-isis-rfc6326bis,
work in progress.
[trill-mt] - 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,
work in progress.
9.2 Informative References
[RFC4949] - Shirey, R., "Internet Security Glossary, Version 2", FYI
36, RFC 4949, August 2007.
D. Eastlake, et al [Page 12]
INTERNET-DRAFT TRILL: Multi-Topology
Authors' Addresses
Donald Eastlake 3rd
Huawei R&D USA
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
Vishwas Manral
Hewlett-Packard Co.
19111 Pruneridge Ave.
Cupertino, CA 95014 USA
Phone: 1-408-447-0000
Email: vishwas.manral@hp.com
Ayan Banerjee
Cumulus Networks
1089 West Evelyn Avenue
Sunnyvale, CA 94086 USA
Email: ayabaner@gmail.com
D. Eastlake, et al [Page 13]
INTERNET-DRAFT TRILL: Multi-Topology
Copyright, Disclaimer, and Additional IPR Provisions
Copyright (c) 2012 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 14]
