1. Introduction
   1.1. Project/Component Working Name:
	VRRP: Virtual Router Redundancy Protocol
   1.2. Name of Document Author/Supplier:
	Author: Yifan Xu (evan.xu@sun.com)
   1.3. Date of This Document:
	Nov 06, 2008
   1.4. Name of Major Document Customer(s)/Consumer(s):
	1.4.1. The PAC or CPT you expect to review your project:
		Solaris PAC
	1.4.2. The ARC(s) you expect to review your project:
		PSARC
	1.4.3. The Director/VP who is "Sponsoring" this project:
		william.franklin@sun.com
	1.4.4. The name of your business unit:
		Solaris Networking
   1.5. Email Aliases:
    	1.5.1. Responsible Manager: zhaozhou.li@sun.com
    	1.5.2. Responsible Engineer: evan.xu@sun.com, huafeng.lv@sun.com
    	1.5.3. Marketing Manager:
	1.5.4. Interest List: vrrp-dev@opensolaris.org

2. Project Summary
   2.1. Project Description:
	This project aims at implementing RFC 3768 and draft-ietf-vrrp-unified-
	spec-02 - Virtual Router Redundancy Protocol Version 2 for IPv4, as
	well as version 3 for IPv4 and IPv6, with the goal of providing High 
	Availability on Solaris.
   2.2. Risks and Assumptions:
	VRRP version 3 is still a IETF draft, draft-ietf-vrrp-unified-spec-02.
	The project team will monitor any changes.

3. Business Summary
   3.1. Problem Area:
	Running a dynamic routing protocol on every end-host may be infeasible
	for a number of reasons, including administrative overhead, processing
	overhead, security issues, or lack of a protocol implementation for some
	platforms.  Neighbor or router discovery protocols may require active
	participation by all hosts on a network, leading to large timer values
	to reduce protocol overhead in the face of large numbers of hosts. This
	can result in a significant delay in the detection of a lost (i.e., dead
	) neighbor, that may introduce unacceptably long "black hole" periods.

	The use of a statically configured default route creates a single point
	of failure.  Loss of the default router results in a catastrophic event,
	isolating all end-hosts that are unable to detect any alternate path
	that may be available.

	The Virtual Router Redundancy Protocol (VRRP) for IPv4 is designed to
	eliminate the single point of failure inherent in the static default
	routed environment. The Virtual Router Redundancy Protocol for IPv6
	provides a much faster switch over to an alternate default router than
	can be obtained using standard ND procedures.

   3.2. Market/Requester:
	None.

   3.3. Business Justification:
	Provide HA solution for the Integrated Load Balancer project.

   3.4. Competitive Analysis:
	TBD.

   3.5. Opportunity Window/Exposure:
	TBD.

   3.6. How will you know when you are done?:
	TBD.


4. Technical Description:

    4.1. Details:

	While the initial motivation comes from the HA capability requirement of
	the Solaris Layer 3/4 Load Balancer project, this proposal seeks to
	build a general HA service based on the VRRP protocol. By implementing
	the standard, multiple hosts running the VRRP service can build up a
	virtual router which does IPv4/IPv6 addresses fail over when the master
	host fails. For VRRP protocol specifications please see references.

	The VRRP standard is designed for routers, defining a set of virtual
	router associated IP addresses on a single interface, which is usually
	the interface that connects to the internal network and acts as the
	default route for internal machines. The VRRP protocol is incapable of
	protecting IP addresses on multiple interfaces. Thus it cannot work for
	some other network appliances such as load balancers. In this project we
	extend the standard protocol and introduce VRRP group, which binds up
	multiple VRRP instances and performs fail over as a whole.

	A VRRP group contains several VRRP instances, and all these instances
	always have the same state. The group changes its state only when all
	of its instances meet the criterias of state transition.

	This project will provide an SMF service for VRRP, an administration
	tool to manage VRRP configuration/monitoring, and a set of API for other
	services to exploit. Please refer to the appendix for specifications of
	the administration tool and the library.

    4.2. Bug/RFE Number(s):
	TBD.
    
    4.3. In Scope:
	TBD.

    4.4. Out of Scope:
	According the newest version of the RFC, VRRP for IPv4/IPv6 does not
	currently include any type of authentication or confidentiality.

	VRRP MIB is not involved in the project scope.

    4.5. Interfaces:

	Exported Interface	Classification	Comments
	==================	==============	========
	SUNWvrrpu		Committed	Package for VRRP utility
	SUNWvrrpr		Committed	Package for VRRP configuration
	LIBVRRP_VERSION		Committed	VRRP API version

	/usr/sbin/vrrpadm	Committed	VRRP administration tool
	vrrpadm startup		Committed	sub command
	vrrpadm shutdown	Committed	sub command
	vrrpadm remove		Committed	sub command
	vrrpadm create		Uncommitted	sub command
	vrrpadm modify		Uncommitted	sub command
	vrrpadm show		Volatile	sub command

	/usr/sbin/vrrpize	Committed	Tool to "vrrpize" other SMF
						services

	/usr/sbin/vrrpd		Project Private	VRRP daemon		
	/etc/vrrpd/sthook.*	Project Private State transition hooks
	/etc/vrrpd/vrrp.conf	Project Private	VRRP Configuration file

	svc:/network/vrrp:default Uncommitted	FMRI for the VRRP service

	/usr/lib/libvrrp.so		Uncommitted	VRRP APIs
	/usr/include/netinet/vrrp.h	Uncommitted	VRRP protocol
	/usr/include/libvrrp.h		Uncommitted	Exported header file
	/usr/include/libvrrp_impl.h	Project Private	Unexported header file

    4.6. Doc Impact:
	man pages
    
    4.7. Admin/Config Impact:
	TBD.
    
    4.8. HA Impact:
	TBD.
    
    4.9. I18N/L10N Impact:
	TBD.
    
    4.10. Packaging & Delivery:
	SUNWvrrpu, SUNWvrrpr, SUNWman
    
    4.11. Security Impact:
	None.
    
    4.12. Dependencies:
	None.

5. Reference Documents:

	[1] RFC3768: Virtual Router Redundancy Protocol (VRRP)
	http://www.faqs.org/rfcs/rfc3768.html

	[2] Internet-Draft: VRRP Version 3 for IPv4 and IPv6
	http://www.ietf.org/internet-drafts/draft-ietf-vrrp-unified-spec-02.txt

6. Resources and Schedule:
   6.1. Projected Availability:
	March 2009

   6.2. Cost of Effort:
	Development	3 engineers	7 months
	Testing		1 engineer	1 month

   6.3. Cost of Capital Resources:
	None.

   6.4. Product Approval Committee requested information:
   	6.4.1. Consolidation or Component Name:
		ON
	6.4.3. Type of CPT Review and Approval expected:
		Standard
        6.4.4. Project Boundary Conditions:
		TBD.
	6.4.5. Is this a necessary project for OEM agreements:
		No.
	6.4.6. Notes:
	6.4.7. Target RTI Date/Release:
		Q3 or Q4 CY 2009
	6.4.8. Target Code Design Review Date:
		Dec 2008
	6.4.9. Update approval addition:
		No

   6.5. ARC review type:
		Standard
   6.6. ARC Exposure:
		Open
       6.6.1. Rationale:
		N/A

7. Prototype Availability:
   7.1. Prototype Availability:
	A prototype is currently available on OpenSolaris repository.

   7.2. Prototype Cost:
	No additional cost.