draft-ietf-rserpool-enrp-07.txt   draft-ietf-rserpool-enrp-08.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Expires: April 20, 2004 R. Stewart Expires: December 8, 2004 R. Stewart
Cisco Cisco
M. Stillman M. Stillman
Nokia Nokia
October 21, 2003 June 9, 2004
Endpoint Name Resolution Protocol (ENRP) Endpoint Name Resolution Protocol (ENRP)
draft-ietf-rserpool-enrp-07.txt draft-ietf-rserpool-enrp-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 http:// The list of current Internet-Drafts can be accessed at
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 April 20, 2004. This Internet-Draft will expire on December 8, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Endpoint Name Resolution Protocol (ENRP) is designed to work in Endpoint Name Resolution Protocol (ENRP) is designed to work in
conjunction with the Aggregate Server Access Protocol (ASAP) to 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
(Rserpool) requirements and architecture. Within the operational (Rserpool) requirements and architecture. Within the operational
scope of Rserpool, ENRP defines the procedures and message formats of scope of Rserpool, ENRP defines the procedures and message formats of
a distributed, fault-tolerant registry service for storing, a distributed, fault-tolerant registry service for storing,
bookkeeping, retrieving, and distributing pool operation and bookkeeping, retrieving, and distributing pool operation and
membership information. membership information.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 6
3. ENRP Message Definitions . . . . . . . . . . . . . . . . . 7 3. ENRP Message Definitions . . . . . . . . . . . . . . . . . . 7
3.1 PEER_PRESENCE message . . . . . . . . . . . . . . . . . . 7 3.1 PEER_PRESENCE message . . . . . . . . . . . . . . . . . . 7
3.2 PEER_NAME_TABLE_REQUEST message . . . . . . . . . . . . . 9 3.2 PEER_NAME_TABLE_REQUEST message . . . . . . . . . . . . . 9
3.3 PEER_NAME_TABLE_RESPONSE message . . . . . . . . . . . . . 9 3.3 PEER_NAME_TABLE_RESPONSE message . . . . . . . . . . . . . 9
3.4 PEER_NAME_UPDATE message . . . . . . . . . . . . . . . . . 11 3.4 PEER_NAME_UPDATE message . . . . . . . . . . . . . . . . . 11
3.5 PEER_LIST_REQUEST message . . . . . . . . . . . . . . . . 12 3.5 PEER_LIST_REQUEST message . . . . . . . . . . . . . . . . 12
3.6 PEER_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13 3.6 PEER_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13
3.7 PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14 3.7 PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14
3.8 PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 15 3.8 PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 15
3.9 PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15 3.9 PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15
3.10 PEER_OWNERSHIP_CHANGE message . . . . . . . . . . . . . . 16 3.10 PEER_OWNERSHIP_CHANGE message . . . . . . . . . . . . . 16
3.11 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 18 3.11 PEER_ERROR message . . . . . . . . . . . . . . . . . . . 18
4. ENRP Operation Procedures . . . . . . . . . . . . . . . . 19 4. ENRP Operation Procedures . . . . . . . . . . . . . . . . . 19
4.1 Methods for Communicating amongst ENRP Servers . . . . . . 19 4.1 Methods for Communicating amongst ENRP Servers . . . . . . 19
4.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 20 4.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 20
4.2.1 Generate a Server Identifier . . . . . . . . . . . . . . . 21 4.2.1 Generate a Server Identifier . . . . . . . . . . . . . 21
4.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . . . 21 4.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . 21
4.2.3 Download ENRP Namespace Data from Mentor Peer . . . . . . 23 4.2.3 Download ENRP Namespace Data from Mentor Peer . . . . 23
4.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 25 4.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 25
4.3.1 Rules on PE Re-registration . . . . . . . . . . . . . . . 27 4.3.1 Rules on PE Re-registration . . . . . . . . . . . . . 27
4.4 Handle PE De-registration . . . . . . . . . . . . . . . . 28 4.4 Handle PE De-registration . . . . . . . . . . . . . . . . 28
4.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 28 4.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 28
4.6 Server Namespace Update . . . . . . . . . . . . . . . . . 29 4.6 Server Namespace Update . . . . . . . . . . . . . . . . . 29
4.6.1 Announcing Addition or Update of PE . . . . . . . . . . . 29 4.6.1 Announcing Addition or Update of PE . . . . . . . . . 29
4.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . . . 30 4.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . 30
4.7 Detecting and Removing Unreachable PE . . . . . . . . . . 31 4.7 Detecting and Removing Unreachable PE . . . . . . . . . . 31
4.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 32 4.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 32
4.9 Maintaining Peer List and Monitoring Peer Status . . . . . 32 4.9 Maintaining Peer List and Monitoring Peer Status . . . . . 32
4.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . . . 32 4.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . 32
4.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . . . 32 4.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . 32
4.9.3 Detecting Peer Server Failure . . . . . . . . . . . . . . 33 4.9.3 Detecting Peer Server Failure . . . . . . . . . . . . 33
4.10 Taking-over a Failed Peer Server . . . . . . . . . . . . . 33 4.10 Taking-over a Failed Peer Server . . . . . . . . . . . . 33
4.10.1 Initiate Server Take-over Arbitration . . . . . . . . . . 33 4.10.1 Initiate Server Take-over Arbitration . . . . . . . 33
4.10.2 Take-over Target Peer Server . . . . . . . . . . . . . . . 34 4.10.2 Take-over Target Peer Server . . . . . . . . . . . . 34
4.11 Namespace Data Auditing and Re-synchronization . . . . . . 35 4.11 Namespace Data Auditing and Re-synchronization . . . . . 35
4.11.1 Auditing Procedures . . . . . . . . . . . . . . . . . . . 35 4.11.1 Auditing Procedures . . . . . . . . . . . . . . . . 35
4.11.2 PE Checksum Calculation Algorithm . . . . . . . . . . . . 36 4.11.2 PE Checksum Calculation Algorithm . . . . . . . . . 36
4.11.3 Re-synchronization Procedures . . . . . . . . . . . . . . 37 4.11.3 Re-synchronization Procedures . . . . . . . . . . . 37
4.12 Handling Unrecognized Message or Unrecognized Parameter . 37 4.12 Handling Unrecognized Message or Unrecognized
5. Variables and Thresholds . . . . . . . . . . . . . . . . . 39 Parameter . . . . . . . . . . . . . . . . . . . . . . . 37
5. Variables and Thresholds . . . . . . . . . . . . . . . . . . 39
5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 39 5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 39 5.2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 39
6. Security Considerations . . . . . . . . . . . . . . . . . 40 6. Security Considerations . . . . . . . . . . . . . . . . . . 40
6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 41 6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 41
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 43 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
Normative References . . . . . . . . . . . . . . . . . . . 44 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
Informative References . . . . . . . . . . . . . . . . . . 45 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 45 8.2 Informative References . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . 46
1. Introduction 1. Introduction
ENRP is designed to work in conjunction with ASAP [1] to accomplish ENRP is designed to work in conjunction with ASAP [1] to accomplish
the functionality of Rserpool as defined by its requirements [2] and the functionality of Rserpool as defined by its requirements [2] and
architecture [3]. architecture [3].
Within the operation scope of Rserpool, ENRP defines the procedures Within the operation scope of Rserpool, ENRP defines the procedures
and message formats of a distributed fault-tolerant registry service and message formats of a distributed fault-tolerant registry service
for storing, bookkeeping, retrieving, and distributing pool operation for storing, bookkeeping, retrieving, and distributing pool operation
skipping to change at page 8, line 39 skipping to change at page 8, line 39
This is the ID of the ENRP server to which the message is This is the ID of the ENRP server to which the message is
intended. If the message is not intended to an individual intended. If the message is not intended to an individual
server (e.g., the message is multicasted to a group of server (e.g., the message is multicasted to a group of
servers), this field MUST be set with all 0's. servers), this field MUST be set with all 0's.
PE Checksum Parameter: PE Checksum Parameter:
This is a TLV that contains the latest PE checksum of the ENRP This is a TLV that contains the latest PE checksum of the ENRP
server who sends the PEER_PRESENCE. This parameter SHOULD be server who sends the PEER_PRESENCE. This parameter SHOULD be
included for namespace consistency auditing. See Section 4.11.1 included for namespace consistency auditing. See Section
for details. 4.11.1 for details.
Server Information Parameter: Server Information Parameter:
If present, contains the server information of the sender of If present, contains the server information of the sender of
this message (Server Information Parameter is defined in [10]). this message (Server Information Parameter is defined in [10]).
This parameter is optional. However, if this message is sent in This parameter is optional. However, if this message is sent
response to a received "reply required" PEER_PRESENCE from a in response to a received "reply required" PEER_PRESENCE from a
peer, the sender then MUST include its server information. peer, the sender then MUST include its server information.
Note, at startup an ENRP server MUST pick a randomly generated, Note, at startup an ENRP server MUST pick a randomly generated,
non-zero 32-bit unsigned integer as its ID and MUST use this same ID non-zero 32-bit unsigned integer as its ID and MUST use this same ID
for its entire life. for its entire life.
3.2 PEER_NAME_TABLE_REQUEST message 3.2 PEER_NAME_TABLE_REQUEST message
An ENRP server sends this message to one of its peers to request a An ENRP server sends this message to one of its peers to request a
copy of the namespace data. This message is normally used during copy of the namespace data. This message is normally used during
skipping to change at page 21, line 14 skipping to change at page 21, line 14
4.2.1 Generate a Server Identifier 4.2.1 Generate a Server Identifier
A new ENRP server MUST generate a non-zero, 32-bit server Id that is A new ENRP server MUST generate a non-zero, 32-bit server Id that is
as unique as possible in the operation scope and this server Id MUST as unique as possible in the operation scope and this server Id MUST
remain unchanged for the lifetime of the server. Normally, a good remain unchanged for the lifetime of the server. Normally, a good
32-bit random number will be good enough as the server Id ([12] 32-bit random number will be good enough as the server Id ([12]
provides some information on randomness guidelines). provides some information on randomness guidelines).
Note, there is a very remote chance (about 1 in 4 billion) that two Note, there is a very remote chance (about 1 in 4 billion) that two
PEs of a pool will generate the same server Id and hence cause a ENRP servers in an operation scope will generate the same server Id
server Id conflict in the pool. However, no severe consequence of and hence cause a server Id conflict in the pool. However, no severe
such a conflict has been identified. consequence of such a conflict has been identified.
4.2.2 Acquire Peer Server List 4.2.2 Acquire Peer Server List
At startup, the ENRP server (initiating server) will first attempt to At startup, the ENRP server (initiating server) will first attempt to
learn all existing peer ENRP servers in the same operation scope, or learn all existing peer ENRP servers in the same operation scope, or
to determine that it is along in the scope. to determine that it is along in the scope.
The initiating server uses an existing peer server to bootstrap The initiating server uses an existing peer server to bootstrap
itself into service. We call this peer server the mentor server. itself into service. We call this peer server the mentor server.
skipping to change at page 25, line 9 skipping to change at page 25, line 9
response. response.
In the case where its PEER_NAME_TABLE_REQUEST is rejected by the In the case where its PEER_NAME_TABLE_REQUEST is rejected by the
mentor peer, the initiating server SHOULD either wait for a few mentor peer, the initiating server SHOULD either wait for a few
seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor server, seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor server,
or if there is a backup mentor peer available, select another mentor or if there is a backup mentor peer available, select another mentor
peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor
server. server.
A started namespace download session may get interrupted for some A started namespace download session may get interrupted for some
reason. To cope with this, the initiating server SHOULD start a timer reason. To cope with this, the initiating server SHOULD start a
every time it finishes sending a PEER_NAME_TABLE_REQUEST to its timer every time it finishes sending a PEER_NAME_TABLE_REQUEST to its
mentor peer. If this timer expires without receiving a response from mentor peer. If this timer expires without receiving a response from
the mentor peer, the initiating server SHOULD abort the current the mentor peer, the initiating server SHOULD abort the current
download session and re-start a new namespace download with a backup download session and re-start a new namespace download with a backup
mentor peer, if one is available. mentor peer, if one is available.
Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the
mentor peer has still more data to send, it SHOULD start a session mentor peer has still more data to send, it SHOULD start a session
timer. If this timer expires without receiving another request from timer. If this timer expires without receiving another request from
the initiating server, the mentor peer SHOULD abort the session, the initiating server, the mentor peer SHOULD abort the session,
cleaning out any resource and record of the session. cleaning out any resource and record of the session.
skipping to change at page 26, line 28 skipping to change at page 26, line 28
load factor of the PE), the ENRP server MUST reject the load factor of the PE), the ENRP server MUST reject the
registration. registration.
B. Inconsistent transport type - The ENRP server MUST reject the B. Inconsistent transport type - The ENRP server MUST reject the
registration. registration.
C. Inconsistent data/control configuration - If the overall pool C. Inconsistent data/control configuration - If the overall pool
configuration is "DATA ONLY", and the registering PE configuration is "DATA ONLY", and the registering PE
indicates "CONTORL plus DATA", the ENRP server SHOULD accept indicates "CONTORL plus DATA", the ENRP server SHOULD accept
the registration but warn the PE that control channel cannot the registration but warn the PE that control channel cannot
be used. If the pool configuration is "CONTROL plus DATA" and be used. If the pool configuration is "CONTROL plus DATA"
the PE indicates "DATA ONLY", the ENRP server MUST reject the and the PE indicates "DATA ONLY", the ENRP server MUST reject
registration. the registration.
3. If the named pool already exists in the namespace AND the 3. If the named pool already exists in the namespace AND the
requesting PE is already a member of the pool, the ENRP server requesting PE is already a member of the pool, the ENRP server
SHOULD consider this as a re-registration case. The ENRP server SHOULD consider this as a re-registration case. The ENRP server
MUST perform the same tests on policy, transport type, transport MUST perform the same tests on policy, transport type, transport
use, as described above. If the re-registration is accepted after use, as described above. If the re-registration is accepted
the test, the ENRP Server SHOULD replace the attributes of the after the test, the ENRP Server SHOULD replace the attributes of
existing PE with the information carried in the received the existing PE with the information carried in the received
REGISTRATION message. REGISTRATION message.
4. After accepting the registration, the ENRP server MUST assign 4. After accepting the registration, the ENRP server MUST assign
itself the owner of this PE. If this is a re-registration, the itself the owner of this PE. If this is a re-registration, the
ENRP server MUST take over ownership of this PE regardless of ENRP server MUST take over ownership of this PE regardless of
whether the PE was previously owned by this server or by another whether the PE was previously owned by this server or by another
server. server.
5. The ENRP server may reject the registration due to reasons such 5. The ENRP server may reject the registration due to reasons such
as invalid values, lack of resource, authentication failure, etc. as invalid values, lack of resource, authentication failure, etc.
skipping to change at page 27, line 45 skipping to change at page 27, line 45
attributes in order to, for example, extend its registration life, attributes in order to, for example, extend its registration life,
change its load factor value, etc. change its load factor value, etc.
A PE may modify its load factor value at any time via A PE may modify its load factor value at any time via
re-registration. Based on the number of PEs in the pool and the re-registration. Based on the number of PEs in the pool and the
pool's overall policy type, this operation allows the PE to pool's overall policy type, this operation allows the PE to
dynamically control its share of inbound messages received by the dynamically control its share of inbound messages received by the
pool (also see Section ???? in [1] for more on load control). pool (also see Section ???? in [1] for more on load control).
Moreover, when re-registering, the PE MUST NOT change its policy Moreover, when re-registering, the PE MUST NOT change its policy
type. The server MUST reject the re-registration if the PE attempt to type. The server MUST reject the re-registration if the PE attempt
change its policy type. In the rejection, the server SHOULD attach an to change its policy type. In the rejection, the server SHOULD
error code "Pooling Policy Inconsistent". attach an error code "Pooling Policy Inconsistent".
Regardless whether it is the current owner of the PE, if the Regardless whether it is the current owner of the PE, if the
re-registration is granted to the PE, the ENRP server MUST assign re-registration is granted to the PE, the ENRP server MUST assign
itself to be the new home ENRP server of the PE. itself to be the new home ENRP server of the PE.
Moreover, if the re-registration is granted, the ENRP server MUST Moreover, if the re-registration is granted, the ENRP server MUST
take the namespace update action as described in Section 4.6 to take the namespace update action as described in Section 4.6 to
inform its peers about the change just made. If the re-registration inform its peers about the change just made. If the re-registration
is denied, no message will be sent to its peers. is denied, no message will be sent to its peers.
skipping to change at page 28, line 21 skipping to change at page 28, line 21
To remove itself from a pool, a PE sends a DEREGISTRATION message to To remove itself from a pool, a PE sends a DEREGISTRATION message to
its home ENRP server. The complete format of DEREGISTRATION message its home ENRP server. The complete format of DEREGISTRATION message
and rules of sending it are defined in [1]. and rules of sending it are defined in [1].
In the DEREGISTRATION message the PE indicates the name of the pool In the DEREGISTRATION message the PE indicates the name of the pool
it belongs to in a pool handle parameter and provides its PE it belongs to in a pool handle parameter and provides its PE
identifier. identifier.
Upon receiving the message, the ENRP server SHALL remove the PE from Upon receiving the message, the ENRP server SHALL remove the PE from
its namespace. Moreover, if the PE is the last one of the named pool, its namespace. Moreover, if the PE is the last one of the named
the ENRP server will remove the pool from the namespace as well. pool, the ENRP server will remove the pool from the namespace as
well.
If the ENRP server fails to find any record of the PE in its If the ENRP server fails to find any record of the PE in its
namespace, it SHOULD consider the de-registration granted and namespace, it SHOULD consider the de-registration granted and
completed. completed.
The ENRP server may reject the de-registration request for various The ENRP server may reject the de-registration request for various
reasons, such as invalid parameters, authentication failure, etc. reasons, such as invalid parameters, authentication failure, etc.
In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE
message to the PE. If the de-registration is rejected, the ENRP message to the PE. If the de-registration is rejected, the ENRP
skipping to change at page 30, line 43 skipping to change at page 30, line 44
When an existing PE is granted de-registration or is removed from its When an existing PE is granted de-registration or is removed from its
namespace for some other reasons (e.g., purging an unreachable PE, namespace for some other reasons (e.g., purging an unreachable PE,
see Section 4.7), the ENRP server MUST uses this procedure to inform see Section 4.7), the ENRP server MUST uses this procedure to inform
all its peers about the change just made. all its peers about the change just made.
This is an ENRP announcement and is sent to all the peer of the home This is an ENRP announcement and is sent to all the peer of the home
ENRP server. See Section 4.1 on how announcements are sent. ENRP server. See Section 4.1 on how announcements are sent.
An ENRP server MUST announce the PE removal to all its peers in a An ENRP server MUST announce the PE removal to all its peers in a
PEER_NAME_UPDATE message with the Update Action field set to DEL_PE, PEER_NAME_UPDATE message with the Update Action field set to DEL_PE,
indicating the removal of an existing PE. The complete information of indicating the removal of an existing PE. The complete information
the PE and the pool its belongs to MUST be indicated in the message of the PE and the pool its belongs to MUST be indicated in the
with a PE parameter and a Pool Handle parameter, respectively. message with a PE parameter and a Pool Handle parameter,
respectively.
[editor's note: only the pool handle and the PE's id are needed, it [editor's note: only the pool handle and the PE's id are needed, it
should reduce the size of the message] should reduce the size of the message]
The sending server MUST fill in its server ID in the Sender Server's The sending server MUST fill in its server ID in the Sender Server's
ID field and leave the Receiver Server's ID blank (i.e., set to all ID field and leave the Receiver Server's ID blank (i.e., set to all
0's). 0's).
When a peer receives this PEER_NAME_UPDATE message, it MUST first When a peer receives this PEER_NAME_UPDATE message, it MUST first
find pool and the PE in its own namespace, and then remove the PE find pool and the PE in its own namespace, and then remove the PE
from its local namespace. If the removed PE is the last one in the from its local namespace. If the removed PE is the last one in the
pool, the peer MUST also delete the pool from its local namespace. pool, the peer MUST also delete the pool from its local namespace.
If the peer fails to find the PE or the pool in its namespace, it If the peer fails to find the PE or the pool in its namespace, it
skipping to change at page 32, line 9 skipping to change at page 32, line 9
Instead, the implementation should try to smooth out the Instead, the implementation should try to smooth out the
ENDPOINT_KEEP_ALIVE message traffic over time. ENDPOINT_KEEP_ALIVE message traffic over time.
The complete definition and rules of sending ENDPOINT_UNREACHABLE and The complete definition and rules of sending ENDPOINT_UNREACHABLE and
receiving ENDPOINT_KEEP_ALIVE messages are described in [1]. receiving ENDPOINT_KEEP_ALIVE messages are described in [1].
4.8 Helping PE and PU to Discover Home ENRP Server 4.8 Helping PE and PU to Discover Home ENRP Server
At its startup time, or whenever its current home ENRP server is not At its startup time, or whenever its current home ENRP server is not
providing services, a PE or PU will attempt to find a new home providing services, a PE or PU will attempt to find a new home
server. For this reason, the PE or PU will need to maintain a list of server. For this reason, the PE or PU will need to maintain a list
currently available ENRP servers in its scope. of currently available ENRP servers in its scope.
To help the PE or PU maintaining this list, an ENRP server, if it is To help the PE or PU maintaining this list, an ENRP server, if it is
enabled for multicast, SHOULD periodically send out a SERVER_ANNOUNE enabled for multicast, SHOULD periodically send out a SERVER_ANNOUNE
message every SERVER-ANNOUNCE-CYCLE seconds to the well-known ASAP message every SERVER-ANNOUNCE-CYCLE seconds to the well-known ASAP
multicast channel. And in the SERVER_ANNOUNE message the ENRP server multicast channel. And in the SERVER_ANNOUNE message the ENRP server
SHOULD include all the transport addresses available for ASAP SHOULD include all the transport addresses available for ASAP
communications. If the ENRP server only supports SCTP for ASAP communications. If the ENRP server only supports SCTP for ASAP
communications, the transport information MAY be omitted in the communications, the transport information MAY be omitted in the
SERVER_ANNOUNCE message. SERVER_ANNOUNCE message.
skipping to change at page 33, line 49 skipping to change at page 33, line 49
server SHOULD wait for a PEER_INIT_TAKEOVER_ACK message from _each_ server SHOULD wait for a PEER_INIT_TAKEOVER_ACK message from _each_
of its known peers, except of the target server. [editor's note: how of its known peers, except of the target server. [editor's note: how
long should it wait?] long should it wait?]
Each of the peer servers that receives the PEER_INIT_TAKEOVER message Each of the peer servers that receives the PEER_INIT_TAKEOVER message
from the initiating server SHOULD take the following actions: from the initiating server SHOULD take the following actions:
1. If the peer server finds that itself is the target server 1. If the peer server finds that itself is the target server
indicated in the PEER_INIT_TAKEOVER message, it MUST immediately indicated in the PEER_INIT_TAKEOVER message, it MUST immediately
announce a PEER_PRESENCE message to all its peer ENRP servers in announce a PEER_PRESENCE message to all its peer ENRP servers in
an attempt to stop this take-over process. This indicates a false an attempt to stop this take-over process. This indicates a
failure detection case by the initiating server. false failure detection case by the initiating server.
2. If the peer server finds that itself has already started its own 2. If the peer server finds that itself has already started its own
take-over arbitration process on the same target server, it MUST take-over arbitration process on the same target server, it MUST
perform the following arbitration: perform the following arbitration:
A. if the peer's server ID is smaller in value than the Sender A. if the peer's server ID is smaller in value than the Sender
Server's ID in the arrived PEER_INIT_TAKEOVER message, the Server's ID in the arrived PEER_INIT_TAKEOVER message, the
peer server SHOULD immediately abort its own take-over peer server SHOULD immediately abort its own take-over
attempt. Moreover, the peer SHOULD mark the target server as attempt. Moreover, the peer SHOULD mark the target server as
"not active" on its internal peer list so that its status "not active" on its internal peer list so that its status
skipping to change at page 35, line 15 skipping to change at page 35, line 15
1. mark itself as the home ENRP server of each of the PEs originally 1. mark itself as the home ENRP server of each of the PEs originally
owned by the target server; owned by the target server;
2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the 2. send a point-to-point ENDPOINT_KEEP_ALIVE message to each of the
PEs. This will trigger the PE to adopt the initiating sever as PEs. This will trigger the PE to adopt the initiating sever as
its new home ENRP server; its new home ENRP server;
3. after claiming the ownership of all the PEs originally owned by 3. after claiming the ownership of all the PEs originally owned by
the target server, announce the ownership changes of all the the target server, announce the ownership changes of all the
affected PEs in a PEER_OWNERSHIP_CHANGE message to all the affected PEs in a PEER_OWNERSHIP_CHANGE message to all the
currently known peers. Note, if the list of affected PEs is long, currently known peers. Note, if the list of affected PEs is
the sender MAY announce the ownership changes in multiple long, the sender MAY announce the ownership changes in multiple
PEER_OWNERSHIP_CHANGE messages. PEER_OWNERSHIP_CHANGE messages.
When a peer receives the PEER_OWNERSHIP_CHANGE message from the When a peer receives the PEER_OWNERSHIP_CHANGE message from the
initiating server, it SHOULD find each of the reported PEs in its initiating server, it SHOULD find each of the reported PEs in its
local copy of the namespace and update the PE's home ENRP server to local copy of the namespace and update the PE's home ENRP server to
be the sender of the message (i.e., the initiating server). be the sender of the message (i.e., the initiating server).
4.11 Namespace Data Auditing and Re-synchronization 4.11 Namespace Data Auditing and Re-synchronization
Message losses or certain temporary breaks in network connectivity Message losses or certain temporary breaks in network connectivity
skipping to change at page 36, line 37 skipping to change at page 36, line 37
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle string of the pool the PE belongs (padded with : : Pool handle string of the pool the PE belongs (padded with :
: zeros to next 32-bit word boundary if needed) : : zeros to next 32-bit word boundary if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Id (4 octets) | | PE Id (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, these are not TLVs. This byte block gives each PE a unique byte Note, these are not TLVs. This byte block gives each PE a unique
pattern in the scope. The 32-bit PE checksum for server B byte pattern in the scope. The 32-bit PE checksum for server B
"pe.checksum.prB" is then calculated over the byte blocks contributed "pe.checksum.prB" is then calculated over the byte blocks contributed
by the 'M' PEs one by one. by the 'M' PEs one by one.
Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0") Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0")
in the same fashion, using the byte blocks of all the PEs owned by in the same fashion, using the byte blocks of all the PEs owned by
itself. itself.
Note, whenever an ENRP finds that its internal namespace has changed Note, whenever an ENRP finds that its internal namespace has changed
(e.g., due to PE registration/deregistration, receiving peer updates, (e.g., due to PE registration/deregistration, receiving peer updates,
removing failed PEs, downloading namespace pieces from a peer, etc.), removing failed PEs, downloading namespace pieces from a peer, etc.),
skipping to change at page 40, line 10 skipping to change at page 40, line 10
MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a
PE that an ENRP server will allow before purging this PE from the PE that an ENRP server will allow before purging this PE from the
namespace. (Default=3) namespace. (Default=3)
6. Security Considerations 6. Security Considerations
Threats Introduced by Rserpool and Requirements for Security in Threats Introduced by Rserpool and Requirements for Security in
Response to Threats [11] describes the threats to the Rserpool Response to Threats [11] 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 document, response to each threat. From the threats described in this
the security services required for the Rserpool protocol are document, the security services required for the Rserpool protocol
enumerated below. are enumerated below.
Threat 1) PE registration/deregistration flooding or spoofing Threat 1) PE registration/deregistration flooding or spoofing
----------- -----------
Security mechanism in response: ENRP server authenticates the PE Security mechanism in response: ENRP server authenticates the PE
Threat 2) PE registers with a malicious ENRP server Threat 2) PE registers with a malicious ENRP server
----------- -----------
Security mechanism in response: PE authenticates the ENRP server Security mechanism in response: PE authenticates the ENRP server
Threat 1 and 2 taken together results in mutual authentication of the Threat 1 and 2 taken together results in mutual authentication of the
skipping to change at page 41, line 26 skipping to change at page 41, line 26
from replay attacks. from replay attacks.
For Rserpool we need to authenticate the following: For Rserpool we need to authenticate the following:
PU <---- ENRP Server (PU authenticates the ENRP server) PU <---- ENRP Server (PU authenticates the ENRP server)
PE <----> ENRP Server (mutual authentication) PE <----> ENRP Server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication) ENRP server <-----> ENRP Server (mutual authentication)
We do not define any new security mechanisms specifically for We do not define any new security mechanisms specifically for
responding to threats 1-7. Rather we use existing IETF security responding to threats 1-7. Rather we use existing IETF security
protocols to provide the security services required. TLS supports all protocols to provide the security services required. TLS supports
these requirements and MUST be implemented. The all these requirements and MUST be implemented. The
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
minimum by implementers of TLS for Rserpool. For purposes of minimum by implementers of TLS for Rserpool. For purposes of
backwards compatibility, ENRP SHOULD support backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other ciphersuite. other ciphersuite.
Threat 8 requires the ASAP protocol to limit the number of Threat 8 requires the ASAP protocol to limit the number of
Endpoint_Unreachable messages (see Section 3.5??? in [1]) to the ENRP Endpoint_Unreachable messages (see Section 3.5??? in [1]) to the ENRP
server. server.
skipping to change at page 44, line 5 skipping to change at page 44, line 5
are not available to an TLS/SCTP user. This is not a difficult are not available to an TLS/SCTP user. This is not a difficult
technical problem, but simply a requirement. When describing an API technical problem, but simply a requirement. When describing an API
of the RSerPool lower layer we have also to take into account the of the RSerPool lower layer we have also to take into account the
differences between TLS and SCTP. differences between TLS and SCTP.
7. Acknowledgements 7. Acknowledgements
The authors wish to thank John Loughney, Lyndon Ong, and many others The authors wish to thank John Loughney, Lyndon Ong, and many others
for their invaluable comments. for their invaluable comments.
Normative References 8. References
8.1 Normative References
[1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-08 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-09
(work in progress), October 2003. (work in progress), June 2004.
[2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
J. and M. Stillman, "Requirements for Reliable Server Pooling", J. and M. Stillman, "Requirements for Reliable Server Pooling",
RFC 3237, January 2002. RFC 3237, January 2002.
[3] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney, [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney,
"Architecture for Reliable Server Pooling", "Architecture for Reliable Server Pooling",
draft-ietf-rserpool-arch-07 (work in progress), October 2003. draft-ietf-rserpool-arch-07 (work in progress), October 2003.
[4] Bradner, S., "The Internet Standards Process -- Revision 3", [4] Bradner, S., "The Internet Standards Process -- Revision 3",
skipping to change at page 44, line 42 skipping to change at page 44, line 44
[8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC
3436, December 2002. 3436, December 2002.
[9] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On [9] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On
the Use of Stream Control Transmission Protocol (SCTP) with the Use of Stream Control Transmission Protocol (SCTP) with
IPsec", RFC 3554, July 2003. IPsec", RFC 3554, July 2003.
[10] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [10] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Server Access Protocol (ASAP) and Endpoint Name Resolution Server Access Protocol (ASAP) and Endpoint Name Resolution
(ENRP) common parameters document", (ENRP) common parameters document",
draft-ietf-rserpool-common-param-05 (work in progress), October draft-ietf-rserpool-common-param-06 (work in progress), June
2003. 2004.
[11] Stillman, M., "Threats Introduced by Rserpool and Requirements [11] Stillman, M., "Threats Introduced by Rserpool and Requirements
for Security in Response to Threats", for Security in Response to Threats",
draft-ietf-rserpool-threats-02 (work in progress), Sept 2003. draft-ietf-rserpool-threats-02 (work in progress), Sept 2003.
Informative References 8.2 Informative References
[12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [12] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
Authors' Addresses Authors' Addresses
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, 2-F9 1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004 Arlington Heights, IL 60004
skipping to change at page 46, line 8 skipping to change at page 46, line 8
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
US US
Phone: +1 607 273 0724 62 Phone: +1 607 273 0724 62
EMail: maureen.stillman@nokia.com EMail: maureen.stillman@nokia.com
Intellectual Property Statement Intellectual Property Statement
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 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; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
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 which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgement Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/