TRILL H. Zhai Internet-Draft F. Hu Intended status: Standards Track ZTE Corporation Expires: August 29, 2011 Feb 25, 2011 Extending the Virtual Router Redundancy Protocol for TRILL campus draft-hu-trill-rbridge-vrrp-00.txt Abstract TRILL can be implemented in data center, which is request high reliability and stable, but if RBridge breaks down, the switch time is up to IS-IS topology convergence time. This is not satisfied to the data center service. VRRP provides a redundancy mechanism to avoid single point of failure and fast switching over. This draft proposes to extend VRRP protocol to TRILL in data center. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 29, 2011. Copyright 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 Zhai & Hu Expires August 29, 2011 [Page 1] Internet-Draft VRRP For TRILL Feb 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Application Scenario . . . . . . . . . . . . . . . . . . . . . 4 4. TRILL VRRP Frames . . . . . . . . . . . . . . . . . . . . . . 5 4.1. TRILL-VRRP Multicast Address . . . . . . . . . . . . . . . 6 4.2. Source RBridge MAC Address . . . . . . . . . . . . . . . . 6 4.3. L2-TRILL-VRRP Ethertype . . . . . . . . . . . . . . . . . 6 4.4. Frame Check Sequence (FCS) . . . . . . . . . . . . . . . . 7 5. TRILL VRRP Payload Format . . . . . . . . . . . . . . . . . . 7 5.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Virtual RB ID . . . . . . . . . . . . . . . . . . . . . . 8 5.4. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.5. Count Nicknames . . . . . . . . . . . . . . . . . . . . . 8 5.6. Rsvd . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.7. Maximum Advertisement Interval (Max Adver Int) . . . . . . 8 5.8. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.9. Virtual System ID . . . . . . . . . . . . . . . . . . . . 9 5.10. Nickname(s) . . . . . . . . . . . . . . . . . . . . . . . 9 6. VRRP Protocol State Machine . . . . . . . . . . . . . . . . . 9 7. IS-IS Adjacency . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative references . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Zhai & Hu Expires August 29, 2011 [Page 2] Internet-Draft VRRP For TRILL Feb 2011 1. Introduction TRILL (transparent Interconnection of Lots of Links) is a new technology merging the advantages of layer two and layer three technology[RFCtrill], and is designed to replace STP(Spanning Tree Protocol). The routing protocol IS-IS is used as control plane protocol to discover the topology and advertise link state. When the topology changes, IS-IS LSPs flood the link state to other adjacency. The topology convergence time is about dozens of seconds. As TRILL deploys in many data centers, it's necessary to interconnect the different data centers. The interconnection scenario is as figure 1. BRB (Border RBridge) is the border of data center, and all the data cross data center will get through BRB. If BRB is down, the cross data center communication will get down. BRB becomes the bottleneck of data center and is very easy to create a single point of failure. The solution is to provide redundant equipment to backup BRB. If BRB is broken down, the backup BRB can replace it. But the switching time is dependent the topology convergence time.However,it is request very high reliability in data center for providing video data application. This draft propose to apply VRRP for ensure switching speed. The VRRP mechanism can implement the millisecond switching time to ensure video data [VRRPv3]. The BRB and backup BRB are configured as a VRRP group with the same virtual system ID and virtual nickname. The master BRB of the group floods the virtual nickname to adjacency.If the Master becomes unavailable then the highest priority Backup will be elected as Master after a short delay, providing a controlled transition of the virtual RBridge responsibility with minimal service interruption, and the master elected floods LSPs and data forwarding in TRILL campus, and the content of LSPs and the IS-IS link state topology doesn't change. Data Center Interconnection +-----------------------+ +------------------------+ | | | | | +------+ |------------| +------+ | | +----+ | | | | | | +----+ | | | BR1|----+ BRB1 +----| IP Cloud |----+ BRB2 +----|BR2 | | | +----+ | | | | | | +----+ | | +------+ |------------| +------+ | | Data Center 1 | | Data Center 2 | +-----------------------+ +------------------------+ Figure 1 Zhai & Hu Expires August 29, 2011 [Page 3] Internet-Draft VRRP For TRILL Feb 2011 2. Terminology Border RBridge: Abbr. BRB, a device locates the border of TRILL campus and runs TRILL protocol, BRB is used to communicate with other TRILL campus VRRP RBridge: an RBridge running the Virtual Router Redundancy Protocol. It may participate in one or more VRRP groups. Virtual RBridge: An abstract object managed by VRRP that acts as a default RBridge for devices on a shared LAN. It consists of a Virtual System Identifier and a set of associated nickname (s) across a common LAN. A VRRP RBridge may backup one or more virtual RBridges. Nickname OwnerGBPoThe VRRP RBridge that has the virtual RBridge's nickname as one of its nickname addresses. This is the RBridge that, when up, will respond to packets addressed to one of these nickname addresses for ICMP pings, TCP connections, etc. Virtual RBridge masterGBPoThe VRRP RBridge that is assuming the responsibility of forwarding packets sent to the nickname associated with the virtual RBridge, and answering ARP requests for these nickname. Note that if the nickname owner is available, then it will always become the Master. Virtual RBridge backupGBPoThe set of VRRP RBridge available to assume forwarding responsibility for a virtual RBridge should the current Master fail. 3. Application Scenario The following figure shows a typical network with two VRRP BRBs implementing one virtual RBridge. One BRB is the virtual RBridge master, and the other BRB is virtual RBridge backup. BRB1 is assigned nickname owner of nickname A, and RBR2 is assigned nickname owner of nickname B. A virtual RBridge is then defined by associating a virtual nickname, which can be one of the nicknames of RBR1 and RBR2, or a different nickname from nickname A and nickname B. if virtual nickname is the nickname RB1, RBR1 is the nickname owner, then RBR1 is the virtual RBridge master automatically. Otherwise, the virtual RBridge master will be elected from RB1 and RB2 according to the priority. VRRP protocol manages virtual RBridge fail over to a backup RBridge. The master RBridge floods the IS-IS LSPs and data forwarding according to virtual system id and nickname(s) in TRILL campus. Zhai & Hu Expires August 29, 2011 [Page 4] Internet-Draft VRRP For TRILL Feb 2011 +-------------+ +-------------+ | BRB1 | | BRB2 | |(MRB VRBID=1)| |(BRB VRBID=1)| |NICKNAME A | |NICKNAME B | +------+------+ +----+--------+ | VRID=1 | | | NICKNAME A | | -------+------+-----+------------+---+---------+---------- | | | | | | | | | | | | +--+--+ +--+--+ +--+--+ +--+--+ | RB1 | | RB2 | | RB3 | | RB4 | +-----+ +-----+ +--+--+ +--+--+ Legend: ---+---+---+-- = Ethernet BRB = Border RBridge RB = RBidge MRB = Master RBridge BRB = Backup RBridge Figure 2 4. TRILL VRRP Frames By multicasting periodically a TRILL VRRP frame, a master RBridge announces its existence and functionality to the backup RBridge(s) in a VRRP group. If none TRILL VRRP frame is received in a certain time, backup RBridge(s) will consider the master unavailable and trigger a new master RBridge election process. A TRILL VRRP frame on an 802.3 link is structured as figure 3. All such frames are Ethertype encoded. The RBridge port out which such a frame is sent will strip the outer VLAN tag if configured to do so. Zhai & Hu Expires August 29, 2011 [Page 5] Internet-Draft VRRP For TRILL Feb 2011 VRRP Frame Structure Outer Ethernet Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TRILL-VRRP Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TRILL-VRRP continued | Source RBridge MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source RBridge MAC Address continued | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = C-Tag [802.1Q] | Outer.VLAN Tag Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2-TRILL-VRRP Ethertype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VRRP for TRILL Payload: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TRILL VRRP Payload | Frame Check Sequence: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCS (Frame Check Sequence) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 4.1. TRILL-VRRP Multicast Address The TRILL-VRRP multicast address is an IP-derived multicast MAC address. The IP address is: 224.0.0.18 The IP-derived multicast address is a link local scope multicast address. RBridges MUST NOT forwards a frame with this destination address to another link. 4.2. Source RBridge MAC Address It is a MAC address of RBridge port out which this TRILL VRRP frame is sent 4.3. L2-TRILL-VRRP Ethertype It is used to indicate that the payload in the frame is a TRILL VRRP packet Zhai & Hu Expires August 29, 2011 [Page 6] Internet-Draft VRRP For TRILL Feb 2011 4.4. Frame Check Sequence (FCS) Each Ethernet frame has a single Frame Check Sequence (FCS) that is computed to cover the entire frame, for detecting frame corruption due to bit errors on a link. Thus, when a frame is encapsulated, the original FCS is not included but is discarded. Any received frame for which the FCS check fails SHOULD be discarded (this may not be possible in the case of cut through forwarding). Although the FCS is normally calculated just before transmission, it is desirable, when practical, for an FCS to accompany a frame within an RBridge after receipt. 5. TRILL VRRP Payload Format The format of TRILL VRRP payload is structured as figure 4. VRRP Payload Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Virtual RB ID | Priority |Count Nicknames| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(rsvd) | Max Adver Int | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Virtual System ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Virtual System ID Continued | Nickname (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname (2) | Nickname (3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname (n-1) | Nickname (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 5.1. Version The version field specifies the TRILL VRRP protocol version of this packet. This document defines version 1. Zhai & Hu Expires August 29, 2011 [Page 7] Internet-Draft VRRP For TRILL Feb 2011 5.2. Type The type field specifies the type of this TRILL VRRP packet. The only packet type defined in this version of the protocol is: 1 ADVERTISEMENT A packet with unknown type MUST be discarded. 5.3. Virtual RB ID The Virtual RBridge Identifier (VRBID) field identifies the virtual RBridge this packet is reporting status for. It is a configurable item in the range 1-255 (decimal). There is no default. 5.4. Priority The priority field specifies the sending TRILL VRRP RBridge's priority for the virtual RBridge. Higher values equal higher priority. This field is an 8-bit unsigned integer field. The priority value for the TRILL VRRP RBridge that owns the nicknames associated with the virtual nickname MUST be 255 (decimal). TRILL VRRP RBridges backing up a virtual RBridge MUST use priority values between 1-254 (decimal) and the default priority value is 100(decimal). The priority value zero (0) has special meaning, indicating that the current Master has stopped participating in TRILL VRRP. This is used to trigger backup RBridges to quickly transition to Master without having to wait for the current Master to time out. 5.5. Count Nicknames The number of nicknames contained in this TRILL VRRP advertisement. 5.6. Rsvd This field MUST be set to zero on transmission and ignored on reception. 5.7. Maximum Advertisement Interval (Max Adver Int) The Maximum Advertisement Interval is a 12-bit field that indicates the time interval (in centiseconds) between ADVERTISEMENTS. The default is 100 centiseconds (1 second). Zhai & Hu Expires August 29, 2011 [Page 8] Internet-Draft VRRP For TRILL Feb 2011 5.8. Checksum The checksum field is used to detect data corruption in the TRILL VRRP message. The checksum is the 16-bit one's complement of the one's complement sum of the entire TRILL VRRP message starting with the version field. For computing the checksum, the checksum field is set to zero. See RFC1071 for more detail [CKSM]. 5.9. Virtual System ID The virtual system id is a 48-bit field that indicates the system id of the virtual RBridge this packet is reporting status for. All the RBridges in a virtual RBridge MUST be configured with the same virtual system id. When a TRILL VRRP packet with different virtual system id from local virtual system id is received, the packet MUST be discarded. This field is used for troubleshooting misconfigured RBridges. 5.10. Nickname(s) One or more nicknames are associated with the virtual RBridge. The number of nicknames included is specified in the "Count Nicknames" field. These fields are used for troubleshooting misconfigured RBridges. 6. VRRP Protocol State Machine The VRRP protocol state machine is not change. There are three states: Initialize, backup and master. Initialize state is to wait for a startup event; backup state is to monitor the availability and state of the master RBridge. The master BRB election is according to the priority value. When the RBridge is elected as virtual RBridge master, it floods LSP with virtual nickname to its' adjacencies. If the RBridge is the nickname owner, it's the virtual nickname master automatically, and floods LSPs with owner nickname. Backup RBridge monitors and receives the VRRP packet from master. If backup RBridge has already enabled IS-IS protocol, it should flood LSP to withdraw its nickname LSA. Otherwise backup RBridge shouldn't flood LSP to its neighbors. Backup RBridge exchanges hello packet with its neighbor, and receives LSP from its adjacencies except master RBridgeGBP[not]but never advertises local LSA, which is advertised by master RBridge. Zhai & Hu Expires August 29, 2011 [Page 9] Internet-Draft VRRP For TRILL Feb 2011 7. IS-IS Adjacency Master RBridge should setup and maintain all the adjacencies with other RBridges except backup RBridge. Backup RBridge receives the other RBridges hello packets and IS-IS packets (such as LSP, CSNP, PSNP) besides master RBridge, but should not send any hello and IS-IS packets (LSP, CSNP, PSNP) to other RBridges. The backup RBridge can be detect, 2-way, and report states [TrillAdj]. 8. Security Considerations 9. Acknowledgements The authors would like to gratefully acknowledge many people who have contributed discussion and ideas to the making of this proposal. They include Lizhong Jin, Mingjiang Cheng,Min Xiao, Bo Wu, Xiefeng Gong, Jingjing Zhao, Erchun Lv,etc. 10. References 10.1. Normative references [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004. [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010. [RFCtrill] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "RBridges: Base Protocol Specification", draft-ietf- trill-rbridge-protocol-16.txt, in RFC Editor's queue, Mar 2010. [TrillAdj] Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "RBridges: Adjacency", draft-ietf-trill-adj-02.txt, work in process, Feb 2011. Zhai & Hu Expires August 29, 2011 [Page 10] Internet-Draft VRRP For TRILL Feb 2011 10.2. Informative References Authors' Addresses Hongjun Zhai ZTE Corporation 68 Zijinghua Road Nanjing 200012 China Phone: +86-25-52877345 Email: zhai.hongjun@zte.com.cn Fangwei Hu ZTE Corporation 889 Bibo Road Shanghai 201203 China Phone: +86-21-68896273 Email: hu.fangwei@zte.com.cn Zhai & Hu Expires August 29, 2011 [Page 11]