draft-ietf-rserpool-enrp-13.txt   draft-ietf-rserpool-enrp-14.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Expires: August 11, 2006 R. Stewart Intended status: Experimental R. Stewart
Cisco Systems, Inc. Expires: May 13, 2007 Cisco Systems, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
A. Silverton A. Silverton
Motorola, Inc. Motorola, Inc.
February 7, 2006 November 9, 2006
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
draft-ietf-rserpool-enrp-13.txt draft-ietf-rserpool-enrp-14.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 11, 2006. This Internet-Draft will expire on May 13, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work
in conjunction with the Aggregate Server Access Protocol (ASAP) to in conjunction with the Aggregate Server Access Protocol (ASAP) to
accomplish the functionality of the Reliable Server Pooling accomplish the functionality of the Reliable Server Pooling
skipping to change at page 3, line 5 skipping to change at page 3, line 8
3.8. Helping PE and PU to Discover Home ENRP Server . . . . . . 29 3.8. Helping PE and PU to Discover Home ENRP Server . . . . . . 29
3.9. Maintaining Peer List and Monitoring Peer Status . . . . . 30 3.9. Maintaining Peer List and Monitoring Peer Status . . . . . 30
3.9.1. Discovering New Peer . . . . . . . . . . . . . . . . . 30 3.9.1. Discovering New Peer . . . . . . . . . . . . . . . . . 30
3.9.2. Server Sending Heartbeat . . . . . . . . . . . . . . . 30 3.9.2. Server Sending Heartbeat . . . . . . . . . . . . . . . 30
3.9.3. Detecting Peer Server Failure . . . . . . . . . . . . 30 3.9.3. Detecting Peer Server Failure . . . . . . . . . . . . 30
3.10. Taking-over a Failed Peer Server . . . . . . . . . . . . . 31 3.10. Taking-over a Failed Peer Server . . . . . . . . . . . . . 31
3.10.1. Initiate Server Take-over Arbitration . . . . . . . . 31 3.10.1. Initiate Server Take-over Arbitration . . . . . . . . 31
3.10.2. Take-over Target Peer Server . . . . . . . . . . . . . 32 3.10.2. Take-over Target Peer Server . . . . . . . . . . . . . 32
3.11. Handlespace Data Auditing and Re-synchronization . . . . . 33 3.11. Handlespace Data Auditing and Re-synchronization . . . . . 33
3.11.1. Auditing Procedures . . . . . . . . . . . . . . . . . 33 3.11.1. Auditing Procedures . . . . . . . . . . . . . . . . . 33
3.11.2. PE Checksum Calculation Algorithm . . . . . . . . . . 33 3.11.2. PE Checksum Calculation Algorithm . . . . . . . . . . 34
3.11.3. Re-synchronization Procedures . . . . . . . . . . . . 34 3.11.3. Re-synchronization Procedures . . . . . . . . . . . . 34
3.12. Handling Unrecognized Message or Unrecognized Parameter . 35 3.12. Handling Unrecognized Message or Unrecognized Parameter . 35
4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 36 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 36
4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36
5. Security Considerations . . . . . . . . . . . . . . . . . . . 37 5. Security Considerations . . . . . . . . . . . . . . . . . . . 37
5.1. Implementing Security Mechanisms . . . . . . . . . . . . . 38 5.1. Implementing Security Mechanisms . . . . . . . . . . . . . 38
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1. Normative References . . . . . . . . . . . . . . . . . . . 41 7.1. Normative References . . . . . . . . . . . . . . . . . . . 41
skipping to change at page 4, line 44 skipping to change at page 4, line 44
Pool element handle: See [3]; Pool element handle: See [3];
ENRP handlespace (or handlespace): See [3]; ENRP handlespace (or handlespace): See [3];
ENRP client channel: The communication channel through which an ASAP ENRP client channel: The communication channel through which an ASAP
User (either a PE or PU) requests ENRP handlespace service. The User (either a PE or PU) requests ENRP handlespace service. The
client channel is usually defined by the transport address of the client channel is usually defined by the transport address of the
home server and a well known port number. The channel MAY make home server and a well known port number. The channel MAY make
use of multi-cast or a named list of ENRP servers. use of multi-cast or a named list of ENRP servers.
ENRP server channel: Defined by a well known multicast IP address and ENRP server channel: Defined by a well known multicast IP address
a well known port number. All ENRP servers in an operational and a well known port number. All ENRP servers in an operational
scope can send multicast messages to other servers through this scope can send multicast messages to other servers through this
channel. PEs are also allowed to multicast on this channel channel. PEs are also allowed to multicast on this channel
occasionally; occasionally;
Home ENRP server: The ENRP server to which a PE or PU currently Home ENRP server: The ENRP server to which a PE or PU currently
belongs. A PE MUST only have one home ENRP server at any given belongs. A PE MUST only have one home ENRP server at any given
time and both the PE and its home ENRP server MUST keep track of time and both the PE and its home ENRP server MUST keep track of
this master/slave relationship between them. A PU SHOULD select this master/slave relationship between them. A PU SHOULD select
one of the available ENRP servers as its home ENRP server, but the one of the available ENRP servers as its home ENRP server, but the
ENRP server does not need to know, nor does it need to keep track ENRP server does not need to know, nor does it need to keep track
of this relationship. of this relationship.
skipping to change at page 36, line 19 skipping to change at page 36, line 19
peer.last.heard - the local time that a peer server was last heard peer.last.heard - the local time that a peer server was last heard
(via receiving either a multicast or point-to-point message from (via receiving either a multicast or point-to-point message from
the peer). the peer).
pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server
keeps for a peer. A separate PE checksum is kept for each of its keeps for a peer. A separate PE checksum is kept for each of its
known peers as well as for itself. known peers as well as for itself.
4.2. Thresholds 4.2. Thresholds
MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender will MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender
make to contact an ENRP server (Default=3 times). will make to contact an ENRP server (Default=3 times).
TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will
wait for a response from an ENRP server (Default=5 seconds). wait for a response from an ENRP server (Default=5 seconds).
PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a
heartbeat message to all its known peers. (Default=30 secs.) heartbeat message to all its known peers. (Default=30 secs.)
SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a
SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.) SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.)
MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server
will wait before considering a silent peer server potentially will wait before considering a silent peer server potentially
dead. (Default=61 secs.) dead. (Default=61 secs.)
MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message
sender will wait for a response after sending out a message. sender will wait for a response after sending out a message.
(Default=5 secs.) (Default=5 secs.)
MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a MAX-BAD-PE-REPORT - the maximal number of unreachability reports on
PE that an ENRP server will allow before purging this PE from the a PE that an ENRP server will allow before purging this PE from
handlespace. (Default=3) the handlespace. (Default=3)
5. Security Considerations 5. Security Considerations
Threats Introduced by Rserpool and Requirements for Security in Threats Introduced by Rserpool and Requirements for Security in
Response to Threats [12] describes the threats to the Rserpool Response to Threats [12] describes the threats to the Rserpool
architecture in detail and lists the security requirements in architecture in detail and lists the security requirements in
response to each threat. From the threats described in this response to each threat. From the threats described in this
document, the security services required for the Rserpool protocol document, the security services required for the Rserpool protocol
are enumerated below. are enumerated below.
skipping to change at page 45, line 5 skipping to change at page 45, line 5
Aron J. Silverton Aron J. Silverton
Motorola, Inc. Motorola, Inc.
1301 E. Algonquin Road 1301 E. Algonquin Road
Room 2246 Room 2246
Schaumburg, IL 60196 Schaumburg, IL 60196
USA USA
Phone: +1 847-576-8747 Phone: +1 847-576-8747
Email: aron.j.silverton@motorola.com Email: aron.j.silverton@motorola.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 45, line 29 skipping to change at page 45, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 11 change blocks. 
30 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/