[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-perlman-trill-rbridge-vlan-mapping) 00 01 02 03 04 05 06 07 08 09 10

TRILL Working Group                                        Radia Perlman
INTERNET-DRAFT                                          Sun Microsystems
Intended status: Proposed Standard                           Dinesh Dutt
                                                           Cisco Systems
                                                     Donald Eastlake 3rd
                                                        Stellar Switches
Expires: June 3, 2010                                   December 4, 2009



                          RBridge VLAN Mapping

             <draft-ietf-trill-rbridge-vlan-mapping-01.txt>


Status of This Document

   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


Abstract

   Some bridge products perform a feature known as "VLAN mapping" or
   "VLAN ID translation", in which a bridge translates a data frame's
   VLAN ID from one VLAN to another when it forwards a frame from one
   port to another. This feature facilitates scenarios such as combining
   two bridged LANs with overlapping VLAN IDs into one bridged LAN
   without merging two communities just because they have been given the
   same VLAN ID in the original two clouds. This document describes how
   RBridges can achieve the same functionality.





R. Perlman, et al.                                              [Page 1]

INTERNET-DRAFT                                      RBridge VLAN Mapping


Table of Contents

      Status of This Document....................................1
      Abstract...................................................1

      1. Introduction............................................3
      1.1 Terminology............................................4

      2. Internal RBridges and VLAN Mapping......................5
      3. Configuration of Cut Set VLAN Mapping RBridges..........5
      4. Advertisement of VLAN Mappings..........................6
      5. Translation of VLAN IDs by Cut Set RBridges.............6
      6. Reporting Attached VLANs by Cut Set RBridges in LSPs....6
      7. Advertising of Multicast Groups by Cut Set RBridges.....7
      8. Endnode Advertisements by cut set RBridges..............7

      9. IANA Considerations.....................................8
      10. Security Considerations................................8

      11. Normative References...................................9
      12. Informative References.................................9

      Appendix Z: Change Summary................................10
      Authors' Addresses........................................11
      Copyright, Disclaimer, and Additional IPR Provisions......12



























R. Perlman, et al.                                              [Page 2]

INTERNET-DRAFT                                      RBridge VLAN Mapping


1. Introduction

   Bridges perform a feature known as "VLAN mapping" or "VLAN ID
   translation", in which two or more layer 2 clouds are connected
   together using a set of bridges, but in which the VLAN IDs are not
   consistent in the different clouds.

   The set of bridges interconnecting the clouds are known as the "cut
   set", meaning that if that set of bridges is removed, the clouds are
   separated.

   Bridges in the cut set are configured to translate some set of VLAN
   IDs in one cloud to different VLAN IDs when forwarding from one cloud
   to the other.

   One reason to do this is to intentionally not merge VLAN-A endnodes
   in one layer 2 cloud with the community of VLAN-A endnodes in the
   other cloud.

   Another reason to do this is to intentionally merge two communities,
   marked with different VLAN IDs in the different clouds.

   This feature is accomplished solely by configuring bridges in the cut
   set.

   This document explains how to accomplish the same functionality with
   RBridges.  In this document we will assume there are two clouds
   "East" and "West", and RBridges RB1, RB2, and RB3 that interconnect
   the two clouds.

          .   .   .         +-----+            .   .   .
        .   .   . + - - - - + RB1 + - - - - +    .   .   .
      .   W   .             +-----+            .   . E .
        . e .   .                                .   a   .
      .   s   .             +-----+                . s .   .
        . t .   .+ - - - - -+ RB2 + - - - - - - +.   t   .
      .   .   .            -+-+---+                .   .   .
        . C .   .        /    |      _ _ _ _ _ _+.   C   .   .
          l   .  + - - -      |    /               . l .   .
        . o .   .           +-+---+              .   o   .   .
          u   .   .+ - - - -+ RB3 + - - - - - - - +. u .   .
        . d .   .           +-----+                  d   .   .
      .   .   .   .                                .   .   .

   We will refer to RBridges other than the cut set of RBridges as
   "internal RBridges".

   General familiarity with the base TRILL protocol [RFCtrill] is
   assumed in this document.



R. Perlman, et al.                                              [Page 3]

INTERNET-DRAFT                                      RBridge VLAN Mapping


1.1 Terminology

   The same terminology and acronyms are used in this document as in
   [RFCtrill].

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












































R. Perlman, et al.                                              [Page 4]

INTERNET-DRAFT                                      RBridge VLAN Mapping


2. Internal RBridges and VLAN Mapping

   Internal RBridges will not be aware that VLAN mapping is going on.
   They will behave exactly as they would without VLAN mapping.  The
   only evidence they will have of VLAN mapping is the existence of an
   optional TLV field that a cut set RBridge, RB1, MAY include in its
   LSP, listing the VLAN mappings that RB1 is configured to be
   performing.

   Internal RBridges will ignore this TLV field. It is only there for
   detection of misconfiguration.



3. Configuration of Cut Set VLAN Mapping RBridges

   If VLAN A in cloud "East" is to be translated into VLAN B in cloud
   "West", a cut set RBridge RB1 MUST be configured, for every port, as
   to whether that port is in East or West, and configured with VLAN
   mappings, such as:

      "East/VLAN A <----> West/VLAN B"

   That mapping means that when RB1 forwards a frame on a port
   configured to be in East to a port configured to be in West, with the
   VLAN tag of A, it replaces the VLAN tag "A" with "B" in the inner
   encapsulated frame.

   Note that mappings are always symmetric, meaning that if RB1 is
   translating tag "VLAN A" to tag "VLAN B" when forwarding from East to
   West, it will translate tag "VLAN B" to tag "VLAN A" when forwarding
   from West to East.

   The complete rules for a cut set RBridge forwarding a frame from port
   X in VLAN A to port Y are as follows:

   1. If the ports connect to the same cloud, the frame is forwarded
      without VLAN translation.

   2. If the ports connect to different clouds then

      2.a If there is a translation in effect for VLAN A frames arriving
          from the cloud to which port X connects, the VLAN ID is
          changed according to the translation.

      2.b If there is no translation in effect for VLAN A frames
          arriving from the cloud to which port X connects but there is
          a translation from some other VLAN arriving a port X into VLAN
          A when sent out port Y, then the frame is not forwarded out
          port Y.


R. Perlman, et al.                                              [Page 5]

INTERNET-DRAFT                                      RBridge VLAN Mapping


      2.c If neither 2.a nor 2.b applies, the frame is forwarded without
          VLAN translation.



4. Advertisement of VLAN Mappings

   To detect misconfiguration, a cut set RBridge RB1 MAY advertise its
   VLAN mappings. This is done by assigning 16-bit IDs to each of the
   clouds by manual configuration. All cut set RBridges SHOULD be
   configured with the same IDs for the clouds.  So, in our example, if
   "East" is "1" and "West" is "2", and VLAN A in East is mapped to VLAN
   B in West, the TLV would report a set of mappings, including:

      {(1:A,2:B)}



5. Translation of VLAN IDs by Cut Set RBridges

   If RB1 is configured to believe port X is in "East" and port Y is in
   "West", and RB1 is configured such that "East/VLAN A <----> West/VLAN
   B", then when RB1 forwards data frames from port X to port Y, if the
   received frame from port X has (inner header VLAN ID) VLAN A , then
   RB1 changes the VLAN tag from VLAN A to VLAN B as it forwards onto
   port Y.

   Note: This is true whether RB1 is the appointed forwarder on port X
   for VLAN A and the frame arrives unencapsulated, or whether the frame
   has arrived already encapsulated as a VLAN A frame.

   Likewise, RB1 performs the same VLAN translation whether the frame is
   unicast or multicast.



6. Reporting Attached VLANs by Cut Set RBridges in LSPs

   If RB1 is configured to translate VLAN A to VLAN B, then RB1 reports,
   in its LSP, that it is connected to both VLAN A and VLAN B, even if
   RB1 is not appointed forwarder for either or both VLAN A or VLAN B.

   The reason RB1 must claim to be attached to VLAN A and VLAN B is so
   that multi-destination data frames for VLAN A originating in West
   will not get filtered before reaching RB1, and multi-destination data
   frames for VLAN B originating in East will also not get prematurely
   filtered.





R. Perlman, et al.                                              [Page 6]

INTERNET-DRAFT                                      RBridge VLAN Mapping


7. Advertising of Multicast Groups by Cut Set RBridges

   If RB1 is configured to translate VLAN A in East to VLAN B in West,
   then RB1 MUST take steps as described below in order to ensure that a
   multicast packet for group G in VLAN A will not be filtered inside
   the West cloud, if there are receivers for (VLAN A, group G) in East
   and vice versa. If the cut set RBridges do nothing, then a multicast
   for VLAN B, group G would be filtered inside the West cloud, since
   RBridges inside the East cloud will only be requesting receipt of
   VLAN A, group G.

   To solve this problem RB1 MUST report connectivity to an IPv4
   multicast router and an IPv6 multicast router for both VLANs A and B.



8. Endnode Advertisements by cut set RBridges

   TRILL allows RBridges to optionally advertise attached endnodes. This
   endnode advertisement uses the TRILL ESADI (End System Address
   Distribution Information) protocol.

   If cut set RBridge RB1 is translating VLAN A (in East) to VLAN B (in
   West), and RB1 is doing ESADI for its attached endnodes in VLAN A, it
   should transmit the ESADI advertisement tagged with VLAN A when
   forwarding onto ports labeled as "East", and transmit the same ESADI
   advertisement when forwarding onto ports labeled as "West". An East
   VLAN-A ESADI generated by any RBridge in East will automatically get
   translated into a VLAN B ESADI when forwarding into West, because
   ESADIs are handled just like ordinary encapsulated data frames, the
   VLAN tag to which the ESADI belongs is the VLAN tag on the inner data
   frame, and that VLAN tag will be translated by (properly configured)
   cut set RBridges when forwarding between East and West.



















R. Perlman, et al.                                              [Page 7]

INTERNET-DRAFT                                      RBridge VLAN Mapping


9. IANA Considerations

   This document requires no IANA actions. This section should be
   deleted by the RFC Editor before publication.



10. Security Considerations

   See [RFCtrill] for general RBridge Security Considerations.

   If cut set RBridges have misconfigured VLAN mappings, VLANs may be
   inadvertently partitioned or inadvertently merged and frames may be
   delivered in the wrong VLAN. However, misconfiguration of VLAN
   mapping will not cause loops.





































R. Perlman, et al.                                              [Page 8]

INTERNET-DRAFT                                      RBridge VLAN Mapping


11. Normative References

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

   [RFCtrill] R. Perlman, D. Eastlake, D. Dutt, S. Gai, and A. Ghanwani,
      draft-ietf-trill-rbridge-protocol-14.txt, work in progress.



12. Informative References

   None.







































R. Perlman, et al.                                              [Page 9]

INTERNET-DRAFT                                      RBridge VLAN Mapping


Appendix Z: Change Summary

   RFC Editor: Please delete this section on publication.

   1. Because RBridges can not tell what cloud other RBridges are in,
      drop the "optimized" option for advertising multicast listeners
      and require the advertisement of multicast router connectivity.

   2. Specify that the cloud connectivity must be specified for all cut
      set RBridges and that cloud IDs are manually configured and are 16
      bit.

   3. Expand rules for VLAN ID mapping/handling at a cut set RBridge so
      as to drop frames that are for a VLAN ID to which another VLAN ID
      is being mapped. (See Section 3.)

   4. Add mention of "VLAN ID translation", the 802.1 name for VLAN
      mapping.

   5. Minor editing changes.
































R. Perlman, et al.                                             [Page 10]

INTERNET-DRAFT                                      RBridge VLAN Mapping


Authors' Addresses

   Radia Perlman
   Sun Microsystems
   16 Network Circle
   Menlo Park, CA 94025 USA

   Phone: +1-650-960-1300
   Email: Radia.Perlman@sun.com


   Dinesh G. Dutt
   Cisco Systems
   170 Tasman Drive
   San Jose, CA 95134-1706 USA

   Phone: +1-408-527-0955
   Email: ddutt@cisco.com


   Donald Eastlake 3rd
   Stellar Switches, Inc.
   155 Beaver Street
   Milford, MA 01757 USA

   Tel:   +1-508-634-2066
   Email: d3e3e3@gmail.com

























R. Perlman, et al.                                             [Page 11]

INTERNET-DRAFT                                      RBridge VLAN Mapping


Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   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.
























R. Perlman, et al.                                             [Page 12]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/