One document matched: draft-hu-trill-rbridge-vrrp-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 00:43:40 |