INTERNET-DRAFT Mingui Zhang Intended Status: Proposed Standard Huawei Expires: December 2, 2011 May 31, 2011 To Address the Space Limitation of Inner VLAN draft-zhang-trill-vlan-extension-00.txt Abstract TRILL is originally designed for customer networks. When it is used as a provider network to interconnect multiple separate users, the space of current Inner VLAN becomes insufficient. As an easy way, we can introduce a new VLAN ID field to TRILL header. The new VLAN ID can be use in conjunction with the native Inner VLAN, which is usually known as stacked VLANs(or Q-in-Q). The stacked VLANs mechanism is analyzed in this document. In addition, a novel MAC address rewriting mechanism is also brought forward to break the space limitation of the Inner VLAN. The MAC addresses of the native frame are not used for forwarding process in transit RBridges. When the packet enters the TRILL network, the ingress RBridge (Appointed Forwarder) uses a Virtual MAC (VMAC) address to replace the real MAC and embedded the native VLAN ID into this virtual MAC address. When a packet egresses from the TRILL network, the egress RBridge will use the real MAC address to replace the virtual MAC address and deliver it to the destination on the local link. Status of this Memo This Internet-Draft is submitted to IETF 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Mingui Zhang Expires December 2, 2011 [Page 1] INTERNET-DRAFT traffic-engineering May 31, 2011 Copyright and License Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. QinQ Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. MAC Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Protocol Extension . . . . . . . . . . . . . . . . . . . . 4 3.2. Packet Forwarding Scenarios . . . . . . . . . . . . . . . . 5 4. Deployment Issues . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Incremental Deployment . . . . . . . . . . . . . . . . . . 6 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Mobility Support . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Mingui Zhang Expires December 2, 2011 [Page 2] INTERNET-DRAFT traffic-engineering May 31, 2011 1. Introduction When multiple independent users run their own VLANs on the same TRILL network, TRILL has to configure one VLAN for each customer. However, the single Inner VLAN tag of TRILL can only identify 4094 VLANs which is not enough for multi-tenant scenarios. To address this scalability issue, the first way that comes to our mind is to add a new VLAN tag to TRILL header. The newly added VLAN tag and the original Inner VLAN tag forms the stacked VLANs (Q-in-Q) which are widely used in provider bridging networks. The length of headers will surely increases which reduce the utilization of communication channel. Most important, RBridges have to be upgraded to support the new trill header. The MAC rewriting technique analyzed in this draft is another good choice for TRILL to break the above limitation. Traditional switches use the destination MAC address to look up the outgoing interface to the next hop. RBridges work in a different way. The MAC addresses are not used when transit RBridges are forwarding the frames across the TRILL network. In the MAC address rewriting method, a ingress RBridge writes the original VLAN tag into the MAC address field of the original frame; the egress RBridge write the MAC address back and deliver the packet to its destination host. The formerly Inner VLAN defined by TRILL will be used as the second VLAN tag in the stacked VLAN tags. This method does not change the header of TRILL and the transit RBridges need not be upgraded to support a provider network for multiple tenants environment. 1.1. Terminology 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]. 2. QinQ Mechanism To push a new VLAN tag besides the Inner VLAN to current TRILL data to realize QinQ mechanism. There will be 4094 * 4094 =16,760,836 VLANs, which is enough for a provider network to separate its customer VLANs. pros: A. simple but powerful for services segregation; B. widely used by traditional bridged networks therefore easily be accepted con: A. need to change the definition of TRILL header therefore RBridge ASIC need to be change and/or software need to be upgrade; B. the length of TRILL data packets becomes longer; C. other cons of Q- Mingui Zhang Expires December 2, 2011 [Page 3] INTERNET-DRAFT traffic-engineering May 31, 2011 in-Q mechanism 3. MAC Rewriting When a native frame enters a TRILL network, its MAC addresses will be rewritten by the ingress RBridges to include the VLAN ID of the native frame. The rewritten MAC becomes a virtual MAC address which is dubbed as VMAC in this document. When a TRILL data frame with VMAC egresses from the TRILL network, the VMAC is mapped back to its real MAC by the egress RBridge who will find its destination on the local link. The destination host will learn this rewritten VMAC address and used it for future layer2 data forwarding destined to this sender. The ARP query for a IP address to a real MAC address mapping now becomes the IP address to a VMAC address mapping. This mechanism avoid the upgrade of TRILL protocol. The ASIC of RBridges need not be changed. Only the configuration need to be done at the edge RBridges to realize the mapping. There two possible ways to do the mapping between MAC and VMAC at the edge of TRILL networks: A. sequentially numbering the hosts according to its bootstrapping time, set up a mapping database; B. a hash of the hosts' original MAC address, e.g., directly use the lower 3 bytes to fill in the lower 3 bytes of VMAC The bootstrapping becomes different: Previously: Bootstrapping means store the attached host's MAC; Now: Bootstrapping means two steps: 1. Assign a VMAC to the real MAC of the host. 2. store the attached host's VMAC 3.1. Protocol Extension A 24-bit Raw VLAN ID field is used to break the VLAN space limitation in TRILL networks. This field is named as Native VLAN ID field. The Inner VLAN ID originally defined by TRILL will be used us the second VLAN ID in the stacked VLANs mechanism. It is recommended that 3 bytes are used for native VLAN IDs and 3 bytes are used for host identification. This partition can be tuned if necessary. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Native VLAN ID (3 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Destination Mapped MAC Address (3 bytes)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mingui Zhang Expires December 2, 2011 [Page 4] INTERNET-DRAFT traffic-engineering May 31, 2011 Figure 3.1: The Virtual Inner Destination MAC address (dubbed as VMAC) 3.2. Packet Forwarding Scenarios (DA=VMAC_b) (DA=VMAC_b) (DA=VMAC_b) (DA=MAC_b)* | | | | | V V | V +-----+ +-----+ V [Host a]------>| RB1 |==============>| RB2 |------>[Host b] ^ +-----+ +-----+ ^ | ^ ^ | | | | | (SA=MAC_a) (SA=VMAC_a)* (SA=VMAC_a) (SA=VMAC_a) Figure 3.2: A unicast (known or unknown) packet forwarding Of course, the above egress RBridge has already announced the VMAC to the above ingress RBridge before hand. Therefore the ingress RBridge will directly use the announced VMAC to forwarding the frame. In fact, the ingress RBridge does not know the real MAC or the destination host, since ARP will translate IP to VMAC instead the real MAC. Suppose the source MAC address of a is MAC_a. Host a looks up the ARP cache and find that MAC address of the destination is VMAC_b. The frame will be send to RB1 which is a's ingress RBridge. RB1 will replace the Inner.MacSA with VMAC_a according to its local mapping system. This Inner.MacSA will finally be learned by RB2 which is the egress RBridge. When RB2 receives the frame with VMACs, the VMAC_b will be replace with MAC_b which is the real MAC address of host b. Before the above whole procedure, the VMAC_b has already been announced to host a and stored in its ARP cache. By default, for unicast packets, the VLAN ID in the source VAMC and the Destination VMAC should be the same. (DA=BCast) (DA=VMCast)* (DA=VMCast) (DA=VMCast) | | | | | V V | V +-----+ +-----+ V [Host a]------>| RB1 |==============>| RB2 |------>[Host b] ^ +-----+ +-----+ ^ | ^ ^ | | | | | (SA=MAC_a) (SA=VMAC_a)* (SA=VMAC_a) (SA=VMAC_a) Mingui Zhang Expires December 2, 2011 [Page 5] INTERNET-DRAFT traffic-engineering May 31, 2011 Figure 3.3: A broadcast packet forwarding Sometimes, a host need to send out broadcast frames, such as ARP query messages and ARP miss frames. The Inner.MacDA of broadcast frames are FF-FF-FF-FF-FF-FF. In Figure 2.2, the broadcast process is depicted. This Inner.MacDA will be replaced with 20001:FF-FF-FF and will be multicasted across the TRILL network according to the base protocol of TRILL [TRILLbase]. Suppose Inner.MacSA is EE-EE-EE-EE-EE- 01. It will be replaced with 20001:EE-EE-01 at the ingress RBridge. Host b will learn host a's VMAC (20001:EE-EE-01) when it receives this broadcast frame and insert it into its ARP cache. (DA=VMAC_b) (DA=VMAC_b) (DA=VMAC_b) (DA=MAC_b)* | | | | | V /\/\/\/\/\/\ V | V +-----+ / \ +-----+ V [Host a]------>| RB1 |< >| RBx |------>[Host b] ^ +-----+ \ / +-----+ ^ | ^ \/\/\/\/\/\/ ^ | | | | | (SA=MAC_a) (SA=VMAC_a)* (SA=VMAC_a) (SA=VMAC_a) Figure 3.4: A unknown unicast packet forwarding For unknown unicast frame, the forwarding process is the same as known unicast only that RB1 has to multicast the unknown frame on to the TRILL network. Suppose host b is bootstrapped to RBx. RBx will finally egress the unknown unicast frame. 4. Deployment Issues The edge RBridges need to do mapping between original MAC and VMAC. The transit RBridges do not need to process the VMAC field. 4.1. Incremental Deployment Gracefully backward compatible to the traditional TRILL. 5. Scenarios 5.1. Mobility Support When a host is moved to another port of RBridge or moved to a port of another RBridge, the VMAC used for layer2 data forwarding is changed since the new home RBridge may assign a different VMAC for this host. The black-hole issue is now replaced with an ARP outdated issue. There are several ways to solve this problem: Mingui Zhang Expires December 2, 2011 [Page 6] INTERNET-DRAFT traffic-engineering May 31, 2011 1. host immediately sends out gratuitous ARP to bootstrap to the new home RBridge; 2. New home RBridge notify the old home RBridge the the new VMAC and old home RBridge redirect the frame to the new home RBridge; 3. old home RBridge send the frame as unknown unicast frame; 4. To use keep alive mechanism Fore the third method, if the host has moved to another position, the home RBridge will send out the received packets to this host as unknown unicast packets with the VMAC be replaced with broadcast MAC. This action continues until this home switch received the new location of the moved host. This mapping will be send out when the moved host finished the bootstrapping after movement. This can be achieved through gratuitous ARP. Gratuitous ARP is restricted in the local link. The new home switch will send out this mapping to outdate the old home switch. It can spread this bootstrapping information using TRILL ESADI mechanism. The sender can outdate the old mapping between IP and VMAC in its ARP cache when he receives the broadcast packet or to directly replace the old mapping when he receives the ESADI. Mingui Zhang Expires December 2, 2011 [Page 7] INTERNET-DRAFT traffic-engineering May 31, 2011 6. Security Considerations This document does not introduce additional security issues to TRILL networks. 7. IANA Considerations This document requires no IANA actions. 8. References 8.1. Normative References [TRILLBase] R. Perlman, D. Eastlake, D.G. Dutt, S. Gai and A. Ghanwani, "RBridges: Base Protocol Specification", draft-ietf-trill-rbridge-protocol-16.txt, working in progress. 8.2. Informative References none Author's Addresses 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 Mingui Zhang Expires December 2, 2011 [Page 8]