VRRP Working Group Atul Bansal
INTERNET DRAFT (FORE Systems)
draft-ietf-vrrp-lane-02.txt Rob Enns
(Juniper Networks)
Vivek Menezes
(Pluris)
Rob Montgomery
(Cabletron Systems)
Ayikudy K.Srikanth
Hamayon Mujeeb
(Nortel Networks)
Expires June 2000
VRRP Operation over ATM LAN Emulation
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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-Draft can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of in Internet-Drafts Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This memo specifies the application of the Virtual Router Redundancy
Protocol (VRRP) over networks built using the ATM Forum LAN Emulation
protocol (LANE). The memo specifies the behavior required of a LANE
client (LEC) in order to interoperate with VRRP.
Two schemes "Proxy LEC Scheme" and "Non-Proxy LEC Scheme" are
outlined for running VRRP over LANE. Both schemes can be deployed
Bansal, et al. [Page 1]
INTERNET DRAFT Expires June 2000
simultaneously in the network.
1. Introduction
The Virtual Router Redundancy Protocol (VRRP) [1] specifies a
protocol used to provide dynamic failover in forwarding
responsibility for a set of IP addresses. VRRP provides high
availability of a default forwarding path without requiring hosts to
run routing or router discovery protocols.
ATM Forum LAN Emulation (LANE) [2,3] specifies a protocol used to
emulate Ethernet/IEEE 802.3 and Token Ring/IEEE 802.5 LANs on an
Asynchronous Transfer Mode (ATM) network. LANE is used to extend LAN
connectivity over an ATM backbone.
This memo specifies the behavior required of a LANEv2 client in order
to interoperate with VRRP. The behavioral difference between the
LANEv2 client and LANEv1 client is described in section 7 so that a
LANEv1 client can interoperate with VRRP.
2. Discussion
VRRP operates by electing a master router which responds to a well
known virtual MAC address (VMAC) for the virtual router. When a new
master router is elected, the physical device responding to the VMAC
may change. LANE operates by maintaining a set of mappings from MAC
addresses to ATM addresses. When running VRRP on a LANE network, the
LANE protocol must be notified when a new master router is elected so
that it can update the MAC address to ATM address mapping within the
ELAN for the virtual router's MAC address. In essence while running
VRRP over LANE a virtual MAC address may change location from one LEC
to another.
Some Definitions:
1) ADDRESS ASSOCIATION:
When a LEC represents a particular virtual MAC address the virtual
MAC address is "associated" with the LEC. No two LECs should be
associated with the same MAC address in an ELAN.
2) ADDRESS DISASSOCIATION:
When a LEC stops representing a virtual MAC address which it
apriori represented it is said to have disassociated itself from
the virtual MAC address.
3) Proxy LEC
Bansal, et al. [Page 2]
INTERNET DRAFT Expires June 2000
A LEC which doesn't register its MAC address associations with the
LES. A proxy LEC is responsible for replying to LE_ARP requests
for the MAC addresses it is associated with.
4) Non-Proxy LEC
A LEC that registers its MAC address associations with the LES.
The LES is responsible for replying to LE_ARP requests for MAC
addresses registered by a non-proxy LEC.
5) Targetless LE_ARP_REQUEST:
As defined in section 7.1.30 of [3].
"An LE Client MAY generate an LE_ARP_REQUEST with the
TARGET-LAN-DESTINATION field indicating not present, but with
the SOURCE-LAN-DESTINATION, SOURCE-ATM-ADDRESS, and optionally,
the LLC-Muxed-ATM-Address TLV present. This allows the generating
LE Client to advertise an LE_ARP cache binding to all other LE
Clients in its ELAN. An LE Client receiving a targetless
LE_ARP_REQUEST MUST delete any LE_ARP cache bindings to that
SOURCE-LAN-DESTINATION, and MAY replace any such bindings with
the information from the LE_ARP_REQUEST.
If an LE Client sends out a targetless LE_ARP_REQUEST for a
currently registered unicast LAN Destination, it must have the
same bindings and TLVs as the most recent LE_REGISTER_REQUEST
for that LAN Destination sent to the LE Server.
An LE Client receiving a targetless LE_ARP_REQUEST for a
SOURCE-LAN-DESTINATION not in its cache SHOULD ignore the
request. An LE Client receiving a targetless LE_ARP_REQUEST
for a SOURCE-LAN-DESTINATION that is in its cache SHOULD update
that cache entry with the information in the LE_ARP_REQUEST.
This technique ensures that the LE Client has up-to-date
information, without filling its LE_ARP cache entries for which
it has no use."
6) No-source LE_NARP_REQUEST:
As defined in section 7.1.31 of [3].
"An LE Client MAY generate a no-source LE_NARP_REQUEST to notify
other clients that it no longer represents the unicast LAN
Destination in TARGET-LAN-DESTINATION and TARGET-ATM-ADDRESS
(and LLC-Muxed-ATM-Address TLV, if present). In this case,
SOURCE-ATM-ADDRESS MUST be zero." On receiving a
No-Source LE_NARP_REQUEST a LEC should remove the
TARGET-LAN-DESTINATION to TARGET-ATM-ADDRESS mapping from its
ARP cache.
In VRRP virtual MAC addresses can change their associations with LEC.
Bansal, et al. [Page 3]
INTERNET DRAFT Expires June 2000
Since there are two differenct LEC configurations in an ELAN (Proxy
and Non-Proxy) we discuss ADDRESS ASSOCIATION with both types.
Two common configurations are envisioned when running VRRP over LANE.
In the first, the LANE client (LEC) is co-located with the router
running VRRP. In other words, the LANE client represents one of the
router's network interfaces. In the second scenario, a router
attached to a LAN such as Ethernet is located behind a bridge running
a LANE client. The scenarios are considered in detail in the
following sections.
2.1 Scenario 1 ATM only Attached VRRP Routers
In this scenario we assume the all routers running VRRP are attached
to the LANE network. This scenario is analogous to the first sample
configuration in [1], replacing the Ethernet/Token Ring/FDDI network
with a LANE network.
VRID=1
+-----+ +-----+
| MR1 | | BR1 |
| | | |
+-----+ +-----+
IP A ---------->* *<--------- IP B
| |
| |
| |
@@@@@@@@@@@@@@@+@@@@@@@@@@+@@@@@+@@@@@@@@+@@@@@@@@+@@@@@@@@+@@
^ ^ ^ ^
| | | |
(IP A) (IP A) (IP A) (IP A)
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
Legend:
@@@+@@@+@@@+@@ = LANE network
H = Host computer
MR1 = Master Router
BR1 = Backup Router
* = IP Address
(IP) = default router for hosts
In the above configuration, the end-hosts install a default route to
virtual router #1's IP Address (IP A). All the end-hosts (H1-H4)
bind (IP A) with the virtual router's (VRID=1) virtual MAC address
Bansal, et al. [Page 4]
INTERNET DRAFT Expires June 2000
(VMAC1) which in turn is bound to MR1's link layer address (MR1 LEC's
ATM Address).
Upon MR1 failure, BR1 becomes the master and sends out VRRP
advertisement and its LEC ASSOCIATES itself with VMAC1.
2.2 Scenario 2 ATM and LAN Network Attached
In this scenario we assume that all routers running VRRP are attached
to the LAN network behind the bridges. Furthermore, there are two
virtual routers backing each other. Half of the hosts are using one
virtual router and the other half of the hosts are using the second
virtual router.
VRID=1
+-----+
| MR1 |
| & | +-----+
| BR2 | | H3 |
+-----+ +--+--+
IP A --------->* |
| (IP A)
| |
-------+---+-------------+--
|
+---+---+ +-----+ +-----+
| B1 | | H1 | | H2 |
| | +--+--+ +--+--+
+---+---+ | |
| (IP A) (IP B)
| | |
@@@@@@@@@@+@@@@@@@@@@@@@@@+@@@@@@+@@@@@@@@@@@+@@@@@@
|
+---+---+
| B2 |
| |
+---+---+
|
-+--------+---+------
| |
(IP B) |
| *<---------- IP B
+--+--+ +--+--+
| H4 | | MR2 |
+-----+ | & |
| BR1 |
+-----+
Bansal, et al. [Page 5]
INTERNET DRAFT Expires June 2000
VRID=2
Legend:
@@@+@@@+@@@+@@ = LANE network
---+---+---+-- = Ethernet network
H = Host computer
MR1, MR2 = Master Router
BR1, BR2 = Backup Router
B1,B2 = LANE Bridges
* = IP Address
(IP) = default router for hosts
In the above configuration, MR1 is the master for virtual router #1
serving IP address (IP A) and MR2 is the master for virtual router #2
serving IP address (IP B). The end-hosts H1 and H3 install a default
route to the IP address of virtual router #1 (IP A) and bind (IP A)
with VMAC of the virtual router #1 (VMAC1) which in turn is bound to
the Bridge1's ATM Address (VMAC1 is behind bridge 1). Similarly,
end-hosts H2 and H4 install a default route to (IP B) and bind VMAC2
to Bridge2's ATM address.
Upon MR1 failure, BR1 becomes the master and sends out the VRRP
advertisement with VMAC1 as the source MAC address. The VRRP
advertisement triggers Bridge 1 and Bridge2 to update their station
learning cache. Upon detecting the station move, bridge B1 makes an
ADDRESS DISASSOCIATION from VMAC1 and bridge B2 makes an ADDRESS
ASSOCIATION with VMAC1
Another topology in Scenario 2 can have ATM attached as well as LAN
attached VRRP Routers. In this case, the ATM attached VRRP Router
can use either Proxy or Non-Proxy LEC Scheme and the LANE bridges use
Proxy LEC Scheme.
3.0 Detailed Description of VRRP over LANE
3.1 Non-Proxy LEC Scheme
This scheme is applicable when an ADDRESS ASSOCIATION or ADDRESS
DISASSOCIATION is made by a Non-Proxy LEC.
A LEC joins the ELAN as a non-proxy client. It registers with LES
the physical MAC address associated with the ELAN interface.
On having to make an ADDRESS ASSOCIATION with VMAC the LEC registers
the VMAC with the LES and sends out a "Targetless LE_ARP_REQUEST"
Bansal, et al. [Page 6]
INTERNET DRAFT Expires June 2000
with the VMAC to its own ATM address binding. If the VMAC
registration fails, the master must persist with the registration
phase. The LEC continues to send the Targetless LE_ARP_REQUESTS
(subject to the generation time limits defined in [3]) every second.
(In case of LANE v1 client, send LE_NARP with VMAC as the TARGET-LAN-
DESTINATION and with zero TARGET-ATM-ADDRESS and zero SOURCE-ATM-
ADDRESS)
If a Non-Proxy LEC makes an ADDRESS DISASSOCIATION it unregisters the
VMAC and sends out "No-Source LE_NARP" with the VMAC to its own ATM
address mapping.
If the VRRP router fails without being able to make an ADDRESS
DISASSOCIATION, the LES detects the Control VC failure to the LEC
associated with the VMAC and deletes the current VMAC to ATM binding.
Other LECs in the ELAN will lose their VCs to the failed VRRP router.
There is a potential failure mode if the control VC to the LES isn't
dropped when the master router fails.
Note that the ATM switch can only detect User-Network Interface (UNI)
failure and not the LEC failure. The ATM UNI signalling protocol [4]
specifies a mechanism for detecting the interface failure between the
ATM switch and the ATM host. This mechanism relies on receving the
AAL failure notification from the Signalling ATM Adaption Layer
(SAAL). Upon receiving the AAL failure notification, UNI signalling
waits for the duration specified by the T309 timer value (default is
4 secs) before releasing all active calls on the failed interface.
The SAAL layer [5,6,7] provides reliable transport of signalling
messages between peer entities (e.g., ATM switch and host) and
provides mechanism for detecting the faliure between the peer
entities. Upon detecting the failure between the peer entities, the
SAAL layer notifies the signalling Layer via AAL failure
notification.
Some ATM switch implementations release all VCs on the failed
interface upon link carrier loss. This memo recommends to use
release on carrier loss feature if available. Otherwise, this memo
recommends that both UNI and SAAL timers must be set to detect the
UNI failure under 3 seconds. Upon the UNI failure detection, the ATM
switch must immediately release all VCs related to the failed link.
3.2 Proxy LEC Scheme
This scheme is applicable to a Proxy LEC that makes ADDRESS
ASSOCIATION and ADDRESS DISASSOCIATION.
Bansal, et al. [Page 7]
INTERNET DRAFT Expires June 2000
The LEC must register as a proxy client and can optionally register
its own MAC address with a LES (for pings, TELNET, SNMP, etc.).
On making an ADDRESS ASSOCIATION a LEC sends out a "Targetless
LE_ARP_REQUEST" with the VMAC to its own ATM address binding. It
also makes LE_ARP_REQUEST for this VMAC address. If it gets a
successful reply then it should persist sending "Targetless
LE_ARP_REQUEST" until no reply is received. This retransmission
should not occur more frequently than once per second. (In case of
LANE v1 client, send LE_NARP with VMAC as the TARGET-LAN-DESTINATION
and with zero TARGET-ATM-ADDRESS and zero SOURCE-ATM-ADDRESS)
When the LEC makes an ADDRESS DISASSOCIATION it sends out "No-Source
LE_NARP" with the VMAC to its own ATM address mapping.
3.3 State Description
This section augments the state description defined in Sec 6.4 of
[1].
3.3.1 Initialize
Register either as a Proxy LEC or as a Non-Proxy LEC and complete the
LANE JOIN PHASE [3].
- If the Priority = 255
o Make an ADDRESS ASSOCIATION with the VMAC
o Send an ADVERTISEMENT
o ...(same as [1])
o Transition to the {Master} State
else
o ...(same as [1])
o Transition to the {Backup} State
3.3.2 Backup
While in this state, a VRRP router must do the following:
- MUST not respond to ARP requests for the IP address(es)
associated with the virtual router.
- MUST not respond to LE_ARP_REQUEST for VMAC
- ...(same as [1])
- If the Master_Down_Timer fires, then
o Make an ADDRESS ASSOCIATION with the VMAC.
Bansal, et al. [Page 8]
INTERNET DRAFT Expires June 2000
o send an ADVERTISEMENT
o Broadcast a gratuitous ARP .....
o ...(same as [1])
o Transition to the {Master State}
endif
3.3.3 Master
While in the {Master} State the router functions as the forwarding
router for the IP address(es) associated with the virtual router.
While in this state, a VRRP router must do the following:
- MUST respond to ARP requests for the IP address(es)
associated with the virtual router
- MUST respond to LE_ARP_REQUEST for VMAC
- ... (same as [1])
- If a shutdown event is received, then
o cancel the Adver_Timer
o send an ADVERTISEMENT with Priority = 0
o Make an ADDRESS DISASSOCIATION with the VMAC.
o Transition to {initialize} state
endif
- ... (same as [1])
- If an ADVERTISEMENT is received, then
... (same as [1])
If the Priority in the ADVERTISEMENT is greater than the local
Priority
or
If the Priority in the ADVERTISEMENT is equal to the local
Priority and the the Primary IP address of the sender is greater
than the local primary address, then:
o Make an ADDRESS DISASSOCIATION with the VMAC.
o Transition to {Backup} state
4.0 Requirement on the LANE Bridges for the VRRP Operation over LANE
A LANE bridge must register as a proxy client with LES. This is the
default for LANE bridges. A VRRP router could attach on a LAN port
of a LANE Bridge.
A LANE bridge must make ADDRESS ASSOCIATION on an ELAN port with MAC
addresses that it learns on other ports. It must make ADDRESS
DISASSOCIATION when it learns an a MAC address on an ELAN port on
which it has made an ADDRESS ASSOCIATION with the same MAC.
Bansal, et al. [Page 9]
INTERNET DRAFT Expires June 2000
The ADDRESS ASSOCIATION and ADDRESS ASSOCIATION by LANE bridges upon
detecting the station move is essential for the correct operation
of VRRP in various extended LAN topologies. This behavior should be
default behavior for all LANE bridges independent of VRRP.
5.0 VRRP operation over Token Ring LANE networks
The operation of VRRP over LANE Token Ring is similar to the Ethernet
LANE case discussed above. However, as discussed in [1] RFC 2338,
VRRP over token ring requires the use of a token ring functional
address for the VRID virtual MAC address because of the absence of a
general multicast mechanism over old and new token ring adapter
implementations. The token ring functional address support is the
only generally available multicast mechanism.
The hosts on a Token Ring LANE subnet will use the Token Ring
functional address as the destination MAC address for all IP traffic
going through the IP address(s) of the virtual router. As the
functional address is a multicast address, all such traffic goes
through the ATM LANE BUS, causing a potential congestion of the BUS.
VRRP implementations over pure Token Ring LANE networks (Scenario 1)
should use IEEE 802 MAC Address used for Ethernet, that is,
00-00-5E-00-01-{VRID}. In this case, the lack of a real token ring
adapter makes the need for a functional address a non issue. In the
case of token ring bridged environment, as long as the Master and
all Backups are on LANE, hosts can be on LANE as well as on Token
Ring and there is no need to use functional addresses.
However, if the Master or any of the Backups is on a bridged Token
Ring in a mixed network of bridged token ring and token ring
emulation (Scenario 2), the use of functional addresses cannot be
avoided.
In the case of VRRP in a Token Ring Source route bridged LANE
environment, either the Virtual MAC address or the functional address
could be used but the route descriptor should not be configured.
6.0 Behavior difference between the LANE V1 vs. LANE V2 clients
From 7.1.29 [3]. "An LE Client MAY generate an unsolicited
LE_NARP_REQUEST to allow other clients to learn about a changed
Remote LAN-ATM address binding. This LE_NARP_REQUEST advertises that
the generating LE Client believes that an old binding between TARGET-
LAN-DESTINATION and TARGET-ATM-ADDRESS is no longer valid, and that
the generating LE Client now serves the LAN destination. An LE
Bansal, et al. [Page 10]
INTERNET DRAFT Expires June 2000
Client receiving a valid LE_NARP_REQUEST MAY delete any of its LE_ARP
cache entries that match the TARGET-LAN-DESTINATION and TARGET-ATM-
ADDRESS, and MAY replace such entries with the binding between
TARGET-LAN-DESTINATION and SOURCE-ATM-ADDRESS. The generating LE
Client MUST include the ATM address of the LE Client which was
previously representing the LAN destination. The LLC-Muxed ATM
Address TLV MUST NOT be included in a LANE v1 LE_NARP_REQUEST."
The V1 LE_NARP_REQUEST message didn't consider the two separate cases
of updating ATM address to MAC binding by LANE clients. The first
case is where a LEC who was serving the MAC address by providing the
MAC to its own ATM address. Now, the LEC does not representing the
MAC and it has to inform other LECs about this fact. The second case
is where a LEC starts serving the MAC address and has to inform other
LECs about this fact.
LANEv2 defines two separate messages to handle these two cases. "No-
Source LE_NARP_REQUEST" handles the first case and "Targetless
LE_ARP_REQUESTS" handle the second case.
LANEv1 LE_NARP_REQUEST as defined in [1] can only be used by the
client for the second case. The VRRP operation with LANEv1 requires
that the LANEv1 client send the LE_NARP_REQUEST with zero TARGET-ATM-
ADDRESS and zero SOURCE-ATM-ADDRESS. This is change from [2] and
[3]. The LANEv1 and LANEv2 LES must forward this LE_NARP_REQUESTS to
all LECs. Upon receiving LE_NARP with the Target ATM address of
0x00, all clients (proxy and non-proxy) should delete the MAC to ATM
address mapping for the MAC listed in the TARGET-LAN-ADDRESS.
7.0 Security Consideration
This memo does not define any new protocol packets. Therefore, it
follows the same security mechanisms as defined in [1,2,3].
8.0 Acknowledgments
The authors would like to thank Nischal Sheth, Mike Kazar, Yevgeny
Shakhnovich, Geetha Brown and Danny Mitzel for their comments and
suggestions.
References
[1] Virtual Router Redundancy Protocol, RFC 2338, Internet
Engineering Task Force, April 1998.
ftp://ftp.ietf.org/rfc/rfc2338.txt.
Bansal, et al. [Page 11]
INTERNET DRAFT Expires June 2000
[2] LAN Emulation over ATM Version 1.0, The ATM Forum, January, 1995.
ftp://ftp.atmforum.com/pub/approved-specs/af-lane-0021.000.pdf.
[3] LAN Emulation over ATM Version 2.0 - LUNI Specification, The ATM
Forum, July, 1997.
ftp://ftp.atmforum.com/pub/approved-specs/af-lane-0084.000.pdf.
[4] The ATM Forum, ATM User-Network Interface (UNI) Signalling
Specification, Version 4.0, July 1996.
ftp://ftp.atmforum.com/pub/approved-specs/af-sig-0061.000.pdf
[5] ITU-T Q.2391 (Note 1), B-ISDN User-Network Interface Layer 3 for
Basic Call/Control, March 1994
[6] ITU-T Q.2110, B-ISDN Signalling ATM Adaption Layer - Service
Specific Connection Oriented Protocol (SSCOP) (Note)
[7] ITU-T Q.2130, B-ISDN Signalling ATM Adaption Layer - Service
Specific Coordiation Function for support of signalling at the
user-network interface (SSCF at UNI) (Note)
Authors' Addresses
Atul Bansal
8221 Bell Lane
Vienna, VA 22182 USA
Phone: +1 703 876 3810
Email: atulbans@aol.com
Vivek Menezes
Pluris
10455 Bandley Dr,
Cupertino, CA 95014 USA
Phone: +1 408 861 4147
Email: vivek@pluris.com
Rob Enns
Juniper Networks
385 Ravendale Drive
Mountain View, CA 94043 USA
Phone: +1 650 526 8000
Email: rpe@juniper.net
Rob Montgomery
Cabletron Systems
Pease Training Center
Box 5005, 35 Industrial Way
Rochester, NH 03866-5005 USA
Bansal, et al. [Page 12]
INTERNET DRAFT Expires June 2000
Phone: +1 603 337 9258
EMail: rmontgom@cabletron.com
A.K.Srikanth
Nortel Networks Inc
600 Tech. Park Drwy.
Billerica, MA 01821 USA
Phone: +1 978 916 8226
EMail: asrikant@baynetworks.com
Hamayon Mujeeb
Nortel Networks Inc
600 Tech. Park Drwy.
Billerica, MA 01821 USA
Email: hmujeeb@nortelnetworks.com
Bansal, et al. [Page 13]
