Skip to main content

Multi Topology Encoding within TRILL data frames
draft-tissa-trill-mt-encode-01

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 , Les Ginsberg , Ayan Banerjee , Sam Aldrin , Naveen Nimmu
Last updated 2012-06-17
RFC stream (None)
Formats
Additional resources
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-01
TRILL Working Group                                  Tissa Senevirathne
Internet Draft                                             Les Ginsberg
Intended status: Standard Track                                   CISCO

                                                          Ayan Banerjee
                                                             Consultant

                                                             Sam Aldrin
                                                                HuaaWei

                                                            Naveen Nimmu
                                                                Broadcom

                                                          June 17, 2012
Expires: December 2012

             Multi Topology Encoding within TRILL data frames
                    draft-tissa-trill-mt-encode-01.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 November 17, 2012.

Senevirathne          Expires December 17, 2012                [Page 1]
Internet-Draft      draft-tissa-trill-mt-encode-01            June 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
   carefully, as they describe your rights and restrictions with
   respect to this document.

Abstract

   Two alternate 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. A method that expands TRILL nickname space from 16bits
   to 24 bits is also presented in this draft.

Table of Contents

   1. Introduction...................................................3
   2. Conventions used in this document..............................4
   3. Multi Topology Encoding and nickname Expansion.................4
      3.1. Nickname construction.....................................5
      3.2. Use of Next-Hop VLAN for MT Encoding......................6
   4. Multi Topology Interoperability................................6
      4.1. Interoperability during Migration.........................6
      4.2. Interoperability with RBridges with Non MT capable data
      plane..........................................................7
      4.3. Interoperability with MT unaware RBRdiges.................8
   5. Backward compatibility.........................................8
   6. IS-IS sub-TLV definition.......................................8
      6.1. Nickname MSB capability...................................8
         6.1.1. TRILL sub-TLVs for 24bit nicknames...................8
      6.2. MT capability.............................................9
   7. Security Considerations........................................9
   8. Assignment  Considerations.....................................9
      8.1. IANA Considerations.......................................9
      8.2. IEEE Considerations......................................10
   9. References....................................................10
      9.1. Normative References.....................................10
      9.2. Informative References...................................10
   10. Acknowledgments..............................................11
   Authors' Addresses...............................................11

Senevirathne          Expires December 17, 2012                [Page 2]
Internet-Draft      draft-tissa-trill-mt-encode-01            June 2012

1. Introduction

   Multi Topology is an attractive concept that allows creating
   different virtual topologies or overlays on top of a single physical
   topology. There are several important applications. Few such
   applications are listed below. The list below is by 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

   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 16
   bit 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

Senevirathne          Expires December 17, 2012                [Page 3]
Internet-Draft      draft-tissa-trill-mt-encode-01            June 2012

   [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].

   TRILL protocol, as defined in [RFC6325], defines 16bit nickname
   space. 16bit nickname space allows up to 65536 unique nicknames.
   However, it has been discussed in the working group that, more the
   65536 unique names are required in certain large deployments.
   Possible usage of  Upperbits of Nickname is also being considered
   for encoding Multitoplogy, which further reduces the available nick
   name space. Presented in this document is a method that allows
   expanding the 16bit nickname space to a 24bit nickname space,
   without modifying the TRILL header defined in [RFC6325].

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].

3. Multi Topology Encoding and nickname Expansion

   [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.

   The expansion of nickname space requires expansion of both ingress
   and egress nickname spaces. We propose to encode 8bit MSB of egress
   nickname followed by 8bit MSB of ingress nickname in to the outer
   header. Figure 1 below depicts the proposed encoding.

Senevirathne          Expires December 17, 2012                [Page 4]
Internet-Draft      draft-tissa-trill-mt-encode-01            June 2012

   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                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ethertype = NICKN-ETHTYPE      |EG-NICKN-MSB   |  IG-NICKN-MSB  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             TRILL Header                                      |
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .              Payload                                          .
   .                                                               .
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1  MT ID /NICKN MSB extentions in TRILL

   Ethtype-MT : 16 bit Ethtype to encode Multi Topology ID.

   MT-ID : 16bit Multi Topology IDNICKN-Ethtype : 16 bit Ethtype to
   encode nickname expansion.

   EG-NICKN-MSB : 8bit MSB of the Egress nickname

   IG-NICKN-MSB : 8bit MSB of the Ingress nickname

3.1. Nickname construction

   Each RBridge that is compatible with the proposed scheme, First
   check for presence of Nick-Ethtype, if present extract the EG-NICKN-
   MSB and IG-NICKN-MSB. EG-NICKN-MSB and IG-NICKN-MSB are then
   concatenated with the Egress TRILL nickname and the Ingress TRILL
   nickname to form 24bit nickname space. The derived nickname MUST be
   utilized for forwarding.

Senevirathne          Expires December 17, 2012                [Page 5]
Internet-Draft      draft-tissa-trill-mt-encode-01            June 2012

3.2. 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.

   For sake of simplicity, we propose to map topology-id to Next-VLAN
   based on local policies such as configuration.

4. Multi Topology Interoperability

   There are three 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).
   3. Interoperability with Rbridges that are MT unaware in both Control
     and data planes.

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 December 17, 2012                [Page 6]
Internet-Draft      draft-tissa-trill-mt-encode-01            June 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 reduces the need for multiple physical

Senevirathne          Expires December 17, 2012                [Page 7]
Internet-Draft      draft-tissa-trill-mt-encode-01            June 2012

   links.  This method may be utilized as a permanent method for MT
   encoding in Point-Pont only networks.

4.3. Interoperability with MT unaware RBRdiges

   MT aware RBridges identify MT unaware RBridges with either not
   presence of capability flags (pre RFC6326bis) or MT capability flags
   not being set (Section 6.2. ). In such an event MT aware RBridges
   MUST only forward traffic related to the base topology to MT unaware
   RBridges. Additionally, proposed encoding MUST be removed prior to
   forwarding to MT unaware RBRidges.

5. Backward compatibility

   The proposed methods are encoded as part of the outer header of the
   TRILL frame. An RBridge that is aware of the proposed extensions
   when interfacing with an RBridge that is not capable of the proposed
   extensions MUST remove the proposed encoding from the outer header,
   prior to transmission of TRILL frames on those links that has
   RBridges that are not capable of the proposed extensions.

6. IS-IS sub-TLV definition

6.1. Nickname MSB capability

   To enable auto configuration and detection of Nickname MSB
   capability of the peer RBRIDGE, We propose to define a flag to
   indicate the Nickname MSB capability.

   If this capability is not present in the peer RBridge, the ETH-
   NICKN-MSB will be stripped out from the frame before , the frame is
   forwarded to the Nickname MSB unaware RBridge.

6.1.1. TRILL sub-TLVs for 24bit nicknames

   TRILL standard [RFC6325] is defined for 16bit nickname space. All
   the associated sub-TLVs [RFC6326] are also defined to accommodate
   16bit nicknames. These sub-TLVs cannot be reused to accommodate
   24bit nicknames as that will break the backward compatibility.
   Hence, we propose to request new set of ISIS sub-TLV for following
   TRILL specific sub-TLVs under Router Capability TLV.

   Nickname sub-TLV

   Tree Identifier sub-TLV

   Tree Used Identifier sub-TLV

Senevirathne          Expires December 17, 2012                [Page 8]
Internet-Draft      draft-tissa-trill-mt-encode-01            June 2012

   Interested VLAN and Spanning Tree Root sub-TLV

   Interested Labels and Spanning Tree Root sub-TLV

   Affinity sub-TLV

6.2. 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.2.

   When both of the flags are set RBRridge SHOULD select MT Encoding
   capability.

7. Security Considerations

   TBD

8. Assignment  Considerations

8.1.  IANA Considerations

   IANA is requested to allocate MT Encoding capability Flag,MT to NH-
   VLAN Encoding capability Flags and Nickname MSB capability flag
   under Port TRILL version sub-TLV.

   Additionally IANA is requested to allocate new set of sub-TLV code
   points under Router capability TLV for the following to accommodate
   24bit nickname space:

Senevirathne          Expires December 17, 2012                [Page 9]
Internet-Draft      draft-tissa-trill-mt-encode-01            June 2012

   24bit Nickname sub-TLV

   24bit Tree Identifier sub-TLV

   24bit Tree Used Identifier sub-TLV

   24bit Interested VLAN and Spanning Tree Root sub-TLV

   24bit Interested Labels and Spanning Tree Root sub-TLV

   24bit Affinity sub-TLV

8.2. IEEE Considerations

   IEEE is requested to assign new Ether Type to represent MT-ETHTYPE
   defined in section 3.

9. References

9.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RF5120]  Przygienda, T. et.al , "M-ISIS: Multi Topology (MT)
             Routing in Intermediate System to Intermediate System (IS-
             ISs)", RFC 5120, February, 2008.

9.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.

Senevirathne          Expires December 17, 2012               [Page 10]
Internet-Draft      draft-tissa-trill-mt-encode-01            June 2012

10. 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

   Les Ginsberg
   CISCO Systems
   510 McCarthy Blvd,
   Milpitas, CA 95035.

   Email: ginsberg@cisco.com

   Ayan Banerjee
   Consultant

   Email: ayabaner@gmail.com

Senevirathne          Expires December 17, 2012               [Page 11]
Internet-Draft      draft-tissa-trill-mt-encode-01            June 2012

   Sam Aldrin
   HuaWei Technologies
   2330 Central Expressway
   Santa Clara, CA 95951, USA

   Email: aldrin.ietf@gmail.com

   Naveen Nimmu
   Broadcom         th        9  Floor, Building no 9, Raheja Mind space
   Hi-Tec City, Madhapur,
   Hyderabad - 500 081 India.

   Email: naveen@broadcom.com

Senevirathne          Expires December 17, 2012               [Page 12]