Multi Topology Encoding within TRILL data frames
draft-tissa-trill-mt-encode-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Tissa Senevirathne , Ayan Banerjee , Les Ginsberg , Sam Aldrin | ||
| Last updated | 2012-03-26 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tissa-trill-mt-encode-00
TRILL Working Group Tissa Senevirathne
Internet Draft Ayan Banerjee
Intended status: Standard Track Les Ginsberg
CISCO
Sam Aldrin
HuaaWei
March 26, 2012
Expires: September 2012
Multi Topology Encoding within TRILL data frames
draft-tissa-trill-mt-encode-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 26, 2012.
Copyright Notice
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
Senevirathne Expires September 26, 2012 [Page 1]
Internet-Draft draft-tissa-trill-mt-encode-00 March 2012
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
Two alternative methods of encoding Multi Topology Identifier within
the TRILL data frames are presented. Methods proposed herein do not
require overloading TRILL RBridge nickname to encode Multi Topology
Identifier.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................3
3. Multi Topology Encoding........................................4
3.1. Use of Next-Hop VLAN for MT Encoding......................4
4. Interoperability...............................................5
4.1. Interoperability during Migration.........................5
4.2. Interoperability with RBridges with Non MT capable data
plane..........................................................6
5. IS-IS sub-TLV definition.......................................7
5.1. MT capability.............................................7
6. Security Considerations........................................7
7. Assignment Considerations.....................................7
7.1. IANA Considerations.......................................7
7.2. IEEE Considerations.......................................7
8. References.....................................................7
8.1. Normative References......................................7
8.2. Informative References....................................8
9. Acknowledgments................................................8
Authors' Addresses................................................8
1. Introduction
Multi Topology is an attractive concept that allows to create
different virtual or overlays on top of a single physical topology.
There are several important applications. Few of such are listed
below. The list below is no means an exhaustive list and there are
other applications that may utilize the MT framework.
Application specific topology (Storage topology vs. data topology)
Virtual topologies for different customers
Expansion of TRILL nickname space
Senevirathne Expires September 26, 2012 [Page 2]
Internet-Draft draft-tissa-trill-mt-encode-00 March 2012
Traffic Engineering
[RFC5120] presents Multi topology (MT) framework for IS-IS. MT has
two important parts; IS-IS control plane extensions and Data plane
encoding. [RFC5120] presents IS-IS control plane extensions. [TRILL-
MT1] and [TRILL-MT2] presents required IS-IS sub-TLV definitions and
the data plane encoding for TRILL.
In this document we propose methods that facilitate encoding of
12bit Multi topology ID in to TRILL frames without reducing the
effective TRILL nickname space. Additionally, the proposed scheme
does not require definition of new Topology mapping sub-TLV. In
other words, IS-IS control plane is similar to [RFC5120] and does
not require additional complexity of mapping absolute Topology ID to
abbreviated topology ID.
Methods proposed in this document encode the MT topology ID into
TRILL data frames without modifying the TRILL header. Hence, MT
capable, RBridges interfacing with non MT capable RBridges can
selectively not encode the proposed MT extensions on interfaces with
non MT capable RBridges. Non MT capable RBridges do not required to
be in the base topology. They can be in any valid topology. Only
restriction is non MT capable RBridges can belong to a single
topology only. In its IS-IS HELLO messages, RrRidges exchange its MT
capability and topology information. RBridges that are not capable
of supporting proposed MT extension in data plane, MUST announce
itself as non MT capable, but MAY advertise its association to a
topology other than the base topology by including MT extensions
proposed in [RFC5120]. MT encoding capability is announced by
setting the proposed MT encoding capability bit in Port TRILL
Version sub-TLV [rfc6326bis]. Presence of IS-IS Multi Topology TLV
[RFC5120], indicates only the associated topology. MT encoding
capability indicates RBRidges ability to support proposed data plane
extensions. When MT capability is not set RBridge MUST not use the
proposed data plane encoding methods, instead it must associate the
announcing RBRidge to the advertised topology or base topology in
the absence of Multi-Topology TLV [RFC5120]
2. Conventions used in this document
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 [RFC2119].
Senevirathne Expires September 26, 2012 [Page 3]
Internet-Draft draft-tissa-trill-mt-encode-00 March 2012
3. Multi Topology Encoding
[RFC6325] TRILL Base Protocol, proposes encoding scheme of TRILL
frames. TRILL frames contain outer MAC Header, 802.1QTAG, TRILL
header and user Data. We propose to include multi topology ID after
the 802.1Q TAG. Multi Toplogy ID is preceded by Ethernet Type MT-
ETHTYPE. Figure 1 below depicts the proposed encoding.
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = C-Tag [802.1Q-2005]| Outer.VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ethertype = MT-ETHTYPE | MT-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TRILL Header |
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Payload .
. .
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Encoding of MT ID in TRILL
Required extensions to the IS-IS HELLO to support MT ID encoding is
presented in the section x.
3.1. Use of Next-Hop VLAN for MT Encoding
Alternatively, Next-Hop VLAN may be utilized to encode MT ID in
point to point only networks. Next Hop VLAN on TRILL outer header is
independent of the inner VLAN. On Point-Pont links Next Hop VLAN is
only required to be of local significance. Hence, we propose to map
topologies to Next-Hop VLAN per link basis.
Senevirathne Expires September 26, 2012 [Page 4]
Internet-Draft draft-tissa-trill-mt-encode-00 March 2012
For sake of simplicity, we propose to map topology-id to Next-VLAN
based on local policies such as configuration.
4. Interoperability
There are two possible scenarios of Interoperability with RBridges
that are non MT capable.
1. Interoperability During migration
2. Interoperability with RBridges that are non MT capable in the data
plane. (i.e. Software is MT aware and supports the extensions
specified here-in but, data plane is not capable of supporting the
proposed encoding methods)
4.1. Interoperability during Migration
We recommend upgrading from the core to the edge, as depicted in
the figure below. With this approach, different clusters of RBridges
may belong to different topologies or to the same topology. RBridges
in the core provide connectivity to RBridge clusters at the edge in
a topology aware manner.
Senevirathne Expires September 26, 2012 [Page 5]
Internet-Draft draft-tissa-trill-mt-encode-00 March 2012
+-----------+
| | Edge-1 to Edge 4 are
| Edge-1 | RBridge clusters that are
| | Non MT aware
| |
+-----------+
o
|
o
+---------------+
+----------+ | |
| | | Core (Topology| +----------+
|Edge 3 |o--------o| aware) | | |
| | | Topologies |o--------o| Edge 4 |
+----------+ | T1 and T2 | | |
| | +----------+
+---------------+
o
|
O
+-----------+
| |
|Edge 2 |
| |
| |
+-----------+
Figure 1 MT aware interconnect
In the above diagram Core may be configured to connect Edge 1 and
Edge 2 to a different Topology than the topology of Edge 3 and Edge
4.
RBridges in Edge 1 - 4 are not required to be MT capable or aware.
RBridges in the core associate the corresponding links to the
appropriate topology.
4.2. Interoperability with RBridges with Non MT capable data plane
RBridges with Non MT capable data plane may implement MT support by
dedicating a separate link for each topology.
Alternatively, RBRidges, on point-point links may assign a different
next hop VLAN for different topologies and derive topology ID based
on VLAN. Use Next-Hop VLAN reduce the need for multiple physical
Senevirathne Expires September 26, 2012 [Page 6]
Internet-Draft draft-tissa-trill-mt-encode-00 March 2012
links. This method may be utilized as a permanent method for MT
encoding in Point-Pont only networks.
5. IS-IS sub-TLV definition
5.1. MT capability
We propose to define two MT capability flags within Port TRILL
Version sub-TLV.
1. MT Encoding capability
2. MT to NH-VLAN Encoding capability
MT Encoding capability flag indicates the RBridge is capable
encoding MT ID using ETHTYPE-MT as defined in section 3.
MT to NH-VLAN Encoding capability flag indicates the announcing
RBRidge is capable of using NH-VLAN to MT ID mapping as presented in
section 3.1.
When both of the flags are set RBRridge SHOULD select MT Encoding
capability.
6. Security Considerations
TBD
7. Assignment Considerations
7.1. IANA Considerations
IANA is requested to allocate MT Encoding capability Flag and MT to
NH-VLAN Encoding capability Flags under Port TRILL version sub-TLV..
7.2. IEEE Considerations
IEEE is requested to assign new Ether Type to represent MT-ETHTYPE
defined in section 3.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Senevirathne Expires September 26, 2012 [Page 7]
Internet-Draft draft-tissa-trill-mt-encode-00 March 2012
[RF5120] Przygienda, T. et.al , "M-ISIS: Multi Topology (MT)
Routing in Intermediate System to Intermediate System (IS-
ISs)", RFC 5120, February, 2008.
8.2. Informative References
[TRILL-MT1] Manral,V. et.al., "Multiple Topology Routing Extensions
for Transparent Interconnection of Lots of Links (TRILL)",
draft-manral-isis-trill-multi-topo-03, Work in Progress,
December, 2011.
[TRILL-MT2] Eastlake, D. et.al., "Multi Topology TRILL", draft-
eastlake-trill-rbridge-multi-topo-02, Work in Progress,
January, 2012.
[rfc6326bis] Eastlake, D. et.al., "Transparent Interconnection of
Lots of Links (TRILL) Use of IS-IS", draft-eastlake-isis-
rfc6326bis-02, Work in Progress, December, 2011.
9. Acknowledgments
Special acknowledgment to Dinesh Dutt, for encouragements, support
and coming up with the initial idea.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Tissa Senevirathne
CISCO Systems
375 East Tasman Drive,
San Jose, CA 95134
Phone: +1-408-853-2291
Email: tsenevir@cisco.com
Senevirathne Expires September 26, 2012 [Page 8]
Internet-Draft draft-tissa-trill-mt-encode-00 March 2012
Ayan Banerjee
CISCO Systems
425 East Tasman Drive,
San Jose, CA 95134
Phone: +1-408-527-0539
Email: ayabaner@cisco.com
Les Ginsberg
CISCO Systems
510 McCarthy Blvd,
Milpitas, CA 95035.
Email: ginsberg@cisco.com
Sam Aldrin
HuaWei Technologies
2330 Central Expressway
Santa Clara, CA 95951, USA
Email: aldrin.ietf@gmail.com
Senevirathne Expires September 26, 2012 [Page 9]