draft-ietf-rserpool-enrp-06.txt   draft-ietf-rserpool-enrp-07.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Expires: November 13, 2003 R. Stewart Expires: April 20, 2004 R. Stewart
Cisco Cisco
M. Stillman M. Stillman
Nokia Nokia
May 15, 2003 October 21, 2003
Endpoint Name Resolution Protocol (ENRP) Endpoint Name Resolution Protocol (ENRP)
draft-ietf-rserpool-enrp-06.txt draft-ietf-rserpool-enrp-07.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 http://
www.ietf.org/ietf/1id-abstracts.txt. 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 November 13, 2003. This Internet-Draft will expire on April 20, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . 27 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 . . . . . . 31 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 . . . . . . . . . . . . . . 32 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 Prodecures . . . . . . . . . . . . . . . . . . . 35 4.11.1 Auditing Procedures . . . . . . . . . . . . . . . . . . . 35
4.11.2 Re-synchronization Prodecures . . . . . . . . . . . . . . 35 4.11.2 PE Checksum Calculation Algorithm . . . . . . . . . . . . 36
4.12 Handling Unrecognized Message or Unrecognized Parameter . 36 4.11.3 Re-synchronization Procedures . . . . . . . . . . . . . . 37
5. Variables and Time Constants . . . . . . . . . . . . . . . 37 4.12 Handling Unrecognized Message or Unrecognized Parameter . 37
5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 37 5. Variables and Thresholds . . . . . . . . . . . . . . . . . 39
5.2 Timer Constants . . . . . . . . . . . . . . . . . . . . . 37 5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 39
6. Security Considerations . . . . . . . . . . . . . . . . . 38 5.2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 39
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 39 6. Security Considerations . . . . . . . . . . . . . . . . . 40
Normative References . . . . . . . . . . . . . . . . . . . 40 6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 41
Informative References . . . . . . . . . . . . . . . . . . 41 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 41 Normative References . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . 42 Informative References . . . . . . . . . . . . . . . . . . 45
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 14 skipping to change at page 8, line 14
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 |0|0|0|0|0|0|0|R| Message Length = 0xC | | Type = 0x1 |0|0|0|0|0|0|0|R| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Checksum Param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Param (optional) : : Server Information Param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (reply_required) flag: 1 bit R (reply_required) flag: 1 bit
Set to '1' if the sender requires a response to this message, Set to '1' if the sender requires a response to this message,
otherwise set to '0'. otherwise set to '0'.
Sender Server's ID: 32 bit (unsiged integer) Sender Server's ID: 32 bit (unsigned integer)
This is the ID of the ENRP server which sends the message. This is the ID of the ENRP server which sends the message.
Receiver Server's ID: 32 bit (unsiged integer) Receiver Server's ID: 32 bit (unsigned integer)
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:
This is a TLV that contains the latest PE checksum of the ENRP
server who sends the PEER_PRESENCE. This parameter SHOULD be
included for namespace consistency auditing. See Section 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 in
response to a received "reply required" PEER_PRESENCE from a 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
skipping to change at page 19, line 34 skipping to change at page 19, line 34
Two types of communications are used amongst ENRP servers: Two types of communications are used amongst ENRP servers:
o point-to-point message exchange from one ENPR server to a specific o point-to-point message exchange from one ENPR server to a specific
peer server, and peer server, and
o announcements from one server to all its peer servers in the o announcements from one server to all its peer servers in the
operation scope. operation scope.
Point-to-point communication is always carried out over an SCTP Point-to-point communication is always carried out over an SCTP
associaiton between the sending server and the receiving server. association between the sending server and the receiving server.
Announcements are communicated out with one of the following two Announcements are communicated out with one of the following two
approaches: approaches:
1. The sending server sends the announcement message to a well-known 1. The sending server sends the announcement message to a well-known
RSERPOOL IP multicast channel that its peer servers subscribe to. RSERPOOL IP multicast channel that its peer servers subscribe to.
Note: Because IP multicast is not reliable, this approach does Note: Because IP multicast is not reliable, this approach does
not gaurrantee that all the peers will receive the announcement not guarantee that all the peers will receive the announcement
message. Moreover, since IP multicast is not secure, this message. Moreover, since IP multicast is not secure, this
approach cannot provide any security to the communication. approach cannot provide any security to the communication.
2. The sending server sends multiple copies of the announcement, one 2. The sending server sends multiple copies of the announcement, one
to each of its peer servers, over a set of point-to-point SCTP to each of its peer servers, over a set of point-to-point SCTP
associations between the sending server and the peers. associations between the sending server and the peers.
This approach gaurrantees the reliabe receiption of the message. This approach guarantees the reliable reception of the message.
When needed, data security can be achieved by using IP security When needed, data security can be achieved by using IP security
mechanisms such as IPsec [9] or TLS [8]. mechanisms such as IPsec [9] or TLS [8].
In order to maximize inter-operability of ENRP servers, the following In order to maximize inter-operability of ENRP servers, the following
rules MUST be followed: rules MUST be followed:
1. At the startup time, a new ENRP server SHOULD make a decision on 1. At the startup time, a new ENRP server SHOULD make a decision on
whether it will enable IP multicast for ENRP announcements. This whether it will enable IP multicast for ENRP announcements. This
decision should be based on factors such as the availability of decision should be based on factors such as the availability of
IP multicast and the security requirements from the user of IP multicast and the security requirements from the user of
skipping to change at page 20, line 26 skipping to change at page 20, line 26
A. MUST NOT subscribe to the well-known server multicast A. MUST NOT subscribe to the well-known server multicast
channel, i.e., it only receives peer announcements over SCTP channel, i.e., it only receives peer announcements over SCTP
associations, and associations, and
B. MUST transmit all its out-going announcements over B. MUST transmit all its out-going announcements over
point-to-point SCTP associations with its peers. point-to-point SCTP associations with its peers.
3. If an ENRP server enables itself to use multicast, it then: 3. If an ENRP server enables itself to use multicast, it then:
A. MUST subcribe to the well-known server multicast channel to A. MUST subscribe to the well-known server multicast channel to
ready itself for receiving peers' multicast announcements, ready itself for receiving peers' multicast announcements,
B. MUST also be prepared to receive peer announcements over B. MUST also be prepared to receive peer announcements over
point-to-point SCTP associations from peers. point-to-point SCTP associations from peers.
C. MUST track internally which peers are multicast-enabled and C. MUST track internally which peers are multicast-enabled and
which are not. Note: A peer is always assumed to be which are not. Note: A peer is always assumed to be
multicast-disabled until/unless an ENRP message of any type multicast-disabled until/unless an ENRP message of any type
is received from that peer over the well-known server is received from that peer over the well-known server
multicast channel. multicast channel.
skipping to change at page 21, line 10 skipping to change at page 21, line 10
This section describes the steps a new ENRP server needs to take in This section describes the steps a new ENRP server needs to take in
order to join the other existing ENRP servers, or to initiate the order to join the other existing ENRP servers, or to initiate the
namespace service if it is the first ENRP server started in the namespace service if it is the first ENRP server started in the
operation scope. operation scope.
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 ([11] 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
PEs of a pool will generate the same server Id and hence cause a
server Id conflict in the pool. However, no severe 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.
4.2.2.1 Find the mentor server 4.2.2.1 Find the mentor server
If the initiating server is told about an existing peer server If the initiating server is told about an existing peer server
through some administrative means (such as DNS query, configuration through some administrative means (such as DNS query, configuration
database, startup scripts, etc), the initiating server SHOULD then database, startup scripts, etc), the initiating server SHOULD then
use this peer server as its mentor server and SHOULD skip the use this peer server as its mentor server and SHOULD skip the
remaining steps in this subsection. remaining steps in this subsection.
If multiple existing peer servers are specified, the initiating If multiple existing peer servers are specified, the initiating
server SHOULD pick one of them as its mentor peer server, keep the server SHOULD pick one of them as its mentor peer server, keep the
others as its backup menter peers, and skip the remaining steps in others as its backup mentor peers, and skip the remaining steps in
this subsection. this subsection.
If no existing peer server is specified to the initiating server AND If no existing peer server is specified to the initiating server AND
if multicast is available in the operation scope, the following if multicast is available in the operation scope, the following
mentor peer discovery procedures SHOULD be followed: mentor peer discovery procedures SHOULD be followed:
1. The initiating server SHOULD first join the well-known ENRP 1. The initiating server SHOULD first join the well-known ENRP
server multicast channel. server multicast channel.
2. Then the initiating server SHOULD send a PEER_PRESENCE message, 2. Then the initiating server SHOULD send a PEER_PRESENCE message,
skipping to change at page 22, line 12 skipping to change at page 22, line 17
response as its mentor peer server. This completes the discovery response as its mentor peer server. This completes the discovery
of the mentor peer server. of the mentor peer server.
If responses are also received from other peers (a likely event If responses are also received from other peers (a likely event
when multiple peers exist in the operation scope at the time the when multiple peers exist in the operation scope at the time the
new server started), the initiating server SHOULD keep a list of new server started), the initiating server SHOULD keep a list of
those responded as its backup mentor peers (see below). those responded as its backup mentor peers (see below).
4. If no response to its PEER_PRESENCE message are received after 4. If no response to its PEER_PRESENCE message are received after
TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat
steps 2) and 3) for up to MAX-TIME-SERVER-HUNT times. After that, steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After
if there is still no response, the initiating server MUST assume that, if there is still no response, the initiating server MUST
that it is alone in the operation scope. assume that it is alone in the operation scope.
5. If the initiating server determined that it is alone in the 5. If the initiating server determined that it is alone in the
scope, it MUST skip the procedures in Section 4.2.2.2 and Section scope, it MUST skip the procedures in Section 4.2.2.2 and Section
4.2.3 and MUST consider its initialization completed and start 4.2.3 and MUST consider its initialization completed and start
offering ENRP services. offering ENRP services.
Note, if multicast is not available (or not allowed for reasons such Note, if multicast is not available (or not allowed for reasons such
as security concerns) in the operation scope, at least one peer as security concerns) in the operation scope, at least one peer
server MUST be specified to the initiating server through server MUST be specified to the initiating server through
administrative means, unless the initiation server is the first administrative means, unless the initiation server is the first
server to start in the operation scope. server to start in the operation scope.
Note, if the administratively specified menter peer(s) fails, the Note, if the administratively specified mentor peer(s) fails, the
initiating server SHOULD use the auto-discover procedure defined in initiating server SHOULD use the auto-discover procedure defined in
steps 1-5 above. steps 1-5 above.
4.2.2.2 Request complete server list from mentor peer 4.2.2.2 Request complete server list from mentor peer
Once the initiating server finds its mentor peer server (by either Once the initiating server finds its mentor peer server (by either
discovery or administrative means), the initiating server MUST send a discovery or administrative means), the initiating server MUST send a
PEER_LIST_REQUEST message to the mentor peer server to request a copy PEER_LIST_REQUEST message to the mentor peer server to request a copy
of the complete server list maintained by the mentor peer (see of the complete server list maintained by the mentor peer (see
Section 4.9 for maintaining server list). Section 4.9 for maintaining server list).
skipping to change at page 22, line 50 skipping to change at page 23, line 6
reply with a PEER_LIST_RESPONSE message and include in the message reply with a PEER_LIST_RESPONSE message and include in the message
body all existing ENRP servers known by the mentor peer. body all existing ENRP servers known by the mentor peer.
Upon the reception of the PEER_LIST_RESPONSE message from the mentor Upon the reception of the PEER_LIST_RESPONSE message from the mentor
peer, the initiating server MUST use the server information carried peer, the initiating server MUST use the server information carried
in the message to initialize its own peer list. in the message to initialize its own peer list.
However, if the mentor itself is in the process of startup and not However, if the mentor itself is in the process of startup and not
ready to provide a peer server list (for example, the mentor peer is ready to provide a peer server list (for example, the mentor peer is
waiting for a response to its own PEER_LIST_REQUEST to another waiting for a response to its own PEER_LIST_REQUEST to another
server), it MUST rejest the request by the initiating server and server), it MUST reject the request by the initiating server and
respond with a PEER_LIST_RESPONSE message with the R flag set to '1', respond with a PEER_LIST_RESPONSE message with the R flag set to '1',
and with no server information included in the response. and with no server information included in the response.
In the case where its PEER_LIST_REQUEST is rejected by the mentor In the case where its PEER_LIST_REQUEST is rejected by the mentor
peer, the initiating server SHOULD either wait for a few seconds and peer, the initiating server SHOULD either wait for a few seconds and
re-send the PEER_LIST_REQUEST to the mentor server, or if there is a re-send the PEER_LIST_REQUEST to the mentor server, or if there is a
backup mentor peer available, select another mentor peer server and backup mentor peer available, select another mentor peer server and
send the PEER_LIST_REQUEST to the new mentor server. send the PEER_LIST_REQUEST to the new mentor server.
4.2.3 Download ENRP Namespace Data from Mentor Peer 4.2.3 Download ENRP Namespace Data from Mentor Peer
skipping to change at page 24, line 24 skipping to change at page 24, line 30
When creating the pool, the initiation server MUST set the When creating the pool, the initiation server MUST set the
overall member selection policy type of the pool to the overall member selection policy type of the pool to the
policy type indicated in the first PE. policy type indicated in the first PE.
B. If the pool already exists in the local namespace, but the B. If the pool already exists in the local namespace, but the
PE(s) in the pool entry is not currently a member of the PE(s) in the pool entry is not currently a member of the
pool, the initiating server MUST add the PE(s) to the pool. pool, the initiating server MUST add the PE(s) to the pool.
C. If the pool already exists in the local namespace AND the C. If the pool already exists in the local namespace AND the
PE(s) in the Pool entry is already a member of the pool, the PE(s) in the Pool entry is already a member of the pool, the
initiating server server SHOULD replace the attributes of the initiating server SHOULD replace the attributes of the
existing PE(s) with the new information. existing PE(s) with the new information.
5. When the last PEER_NAME_TABLE_RESPONSE message is received from 5. When the last PEER_NAME_TABLE_RESPONSE message is received from
the mentor peer and unpacked into the local namespace, the the mentor peer and unpacked into the local namespace, the
initialization process is completed and the initiating server initialization process is completed and the initiating server
SHOULD start to provide ENRP services. SHOULD start to provide ENRP services.
Under certain circumstances, the mentor peer itself may not be able Under certain circumstances, the mentor peer itself may not be able
to provide a namespace download to the initiating server. For to provide a namespace download to the initiating server. For
example, the mentor peer is in the middle of initializing its own example, the mentor peer is in the middle of initializing its own
namespace database, or it has currently too many download sessions namespace database, or it has currently too many download sessions
open to other servers. open to other servers.
In such a case, the mentor peer MUST rejest the request by the In such a case, the mentor peer MUST reject the request by the
initiating server and respond with a PEER_NAME_TABLE_RESPONSE message initiating server and respond with a PEER_NAME_TABLE_RESPONSE message
with the R flag set to '1', and with no pool entries included in the with the R flag set to '1', and with no pool entries included in the
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 timer
everytime it finishes sending a PEER_NAME_TABLE_REQUEST to its mentor every time it finishes sending a PEER_NAME_TABLE_REQUEST to its
peer. If this timer expires without receiving a response from the mentor peer. If this timer expires without receiving a response from
mentor peer, the initiating server SHOULD abort the current download the mentor peer, the initiating server SHOULD abort the current
session and re-start a new namespace download with a backup mentor download session and re-start a new namespace download with a backup
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.
4.3 Handle PE Registration 4.3 Handle PE Registration
To register itself with the namespace, a PE sends a REGISTRATION To register itself with the namespace, a PE sends a REGISTRATION
skipping to change at page 26, line 34 skipping to change at page 26, line 41
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 after
the test, the ENRP Server SHOULD replace the attributes of the the test, the ENRP Server SHOULD replace the attributes of the
existing PE with the information carried in the received existing PE with the information carried in the received
REGISTRATION message. REGISTRATION message.
4. After accepting the registration, the ENRP server MUST assgin 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.
In all above cases, the ENRP server MUST reply to the requesting PE In all above cases, the ENRP server MUST reply to the requesting PE
with a REGISTRATION_RESPONSE message. If the registration is with a REGISTRATION_RESPONSE message. If the registration is
skipping to change at page 27, line 28 skipping to change at page 27, line 35
peer(s). peer(s).
Moreover, if the registration is granted, the ENRP server MUST take Moreover, if the registration is granted, the ENRP server MUST take
the namespace update action as described in Section 4.6 to inform its the namespace update action as described in Section 4.6 to inform its
peers about the change just made. If the registration is denied, no peers about the change just made. If the registration is denied, no
message will be sent to its peers. message will be sent to its peers.
4.3.1 Rules on PE Re-registration 4.3.1 Rules on PE Re-registration
A PE may re-register itself to the namespace with a new set of A PE may re-register itself to the namespace with a new set of
attributtes 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 to
skipping to change at page 28, line 4 skipping to change at page 28, line 11
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.
4.4 Handle PE De-registration 4.4 Handle PE De-registration
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
identifer. 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 pool,
the ENRP server will remove the pool from the namespace as well. 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
skipping to change at page 28, line 46 skipping to change at page 29, line 5
4.5 Pool Handle Translation 4.5 Pool Handle Translation
A PU uses the pool handle translation service of an ENRP server to A PU uses the pool handle translation service of an ENRP server to
resolve a pool handle to a list of accessible transport addresses of resolve a pool handle to a list of accessible transport addresses of
the member PEs of the pool. the member PEs of the pool.
This requires the PU to send a NAME_RESOLUTION message to its home This requires the PU to send a NAME_RESOLUTION message to its home
ENRP server and in the NAME_RESOLUTION message specify the pool ENRP server and in the NAME_RESOLUTION message specify the pool
handle to be translated in a Pool Handle parameter. Complete handle to be translated in a Pool Handle parameter. Complete
defintion of the NAME_RESOLUTION message and the rules of sending it definition of the NAME_RESOLUTION message and the rules of sending it
are defined in [1]. are defined in [1].
An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests
from PUs either over an SCTP associaiton on the well-know SCTP port, from PUs either over an SCTP association on the well-know SCTP port,
or over a TCP connection on the well-know TCP port. or over a TCP connection on the well-know TCP port.
Upon reception of the NAME_RESOLUTION message, the ENRP server MUST Upon reception of the NAME_RESOLUTION message, the ENRP server MUST
first look up the pool handle in its namespace. If the pool exits, first look up the pool handle in its namespace. If the pool exits,
the home ENRP server MUST compose and send back a the home ENRP server MUST compose and send back a
NAME_RESOLUTION_RESPONSE message to the requesting PU. NAME_RESOLUTION_RESPONSE message to the requesting PU.
In the response message, the ENRP server MUST list all the PEs In the response message, the ENRP server SHOULD list all the PEs
currently registered in this pool, in a list of PE parameters. The currently registered in this pool, in a list of PE parameters. The
ENRP server MUST also include a pool member selection policy ENRP server MUST also include a pool member selection policy
parameter to indicate the overall member selection policy for the parameter to indicate the overall member selection policy for the
pool, if the current pool member selection policy is not round-robin pool, if the current pool member selection policy is not round-robin
(if the overall policy is round-Robin, this parameter MAY be (if the overall policy is round-Robin, this parameter MAY be
omitted?). omitted?).
If the named pool does not exist in the namespace, the ENRP server If the named pool does not exist in the namespace, the ENRP server
MUST respond with a NAME_UNKNOWN message. MUST respond with a NAME_UNKNOWN message.
skipping to change at page 29, line 38 skipping to change at page 29, line 45
of a new PE, removal of an existing PE, change of pool or PE of a new PE, removal of an existing PE, change of pool or PE
properties. properties.
4.6.1 Announcing Addition or Update of PE 4.6.1 Announcing Addition or Update of PE
When a new PE is granted registration to the namespace or an existing When a new PE is granted registration to the namespace or an existing
PE is granted a re-registration, the home ENRP server uses this PE is granted a re-registration, the home ENRP server uses this
procedure to inform all its peers. procedure to inform all its peers.
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 annoucements are sent. ENRP server. See Section 4.1 on how announcements are sent.
An ENRP server MUST announce this update to all its peers in a An ENRP server MUST announce this update to all its peers in a
PEER_NAME_UPDATE message with the Update Action field set to ADD_PE, PEER_NAME_UPDATE message with the Update Action field set to ADD_PE,
indicating the addition of a new PE or the modification of an indicating the addition of a new PE or the modification of an
existing PE. The complete new information of the PE and the pool its existing PE. The complete new information of the PE and the pool its
belongs to MUST be indicated in the message with a PE parameter and a belongs to MUST be indicated in the message with a PE parameter and a
Pool Handle parameter, respectively. Pool Handle parameter, respectively.
The home ENRP server SHOULD fill in its server Id in the Sender The home ENRP server SHOULD fill in its server Id in the Sender
Server's ID field and leave the Receiver Server's ID blank (i.e., all Server's ID field and leave the Receiver Server's ID blank (i.e., all
skipping to change at page 30, line 31 skipping to change at page 30, line 39
information carried in the message. information carried in the message.
4.6.2 Announcing Removal of PE 4.6.2 Announcing Removal of PE
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 annoucements 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 of
the PE and the pool its belongs to MUST be indicated in the message the PE and the pool its belongs to MUST be indicated in the message
with a PE parameter and a Pool Handle parameter, respectively. 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]
skipping to change at page 32, line 31 skipping to change at page 32, line 42
the ENRP server MUST consider this peer a new peer in the operation the ENRP server MUST consider this peer a new peer in the operation
scope and add it to the peer list. scope and add it to the peer list.
The ENRP server MUST send a PEER_PRESENCE message with the The ENRP server MUST send a PEER_PRESENCE message with the
Reply-required flag set to '1' to the source address found in the Reply-required flag set to '1' to the source address found in the
arrived message. This will force the new peer to reply with its own arrived message. This will force the new peer to reply with its own
PEER_PRESENCE containing its full server information (see Section PEER_PRESENCE containing its full server information (see Section
3.1). 3.1).
[editor's note: should we ask for a peer list from the new peer? [editor's note: should we ask for a peer list from the new peer?
this may help mending two splitted networks.] this may help mending two split networks.]
4.9.2 Server Sending Heartbeat 4.9.2 Server Sending Heartbeat
Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its
continued presence to all its peer with a PEER_PRESENCE message. In continued presence to all its peer with a PEER_PRESENCE message. In
the PEER_PRESENCE message, the ENRP server MUST set the the PEER_PRESENCE message, the ENRP server MUST set the
'Replay_required' flag to '0', indicating that no response is 'Replay_required' flag to '0', indicating that no response is
required. required.
The arrival of this periodic PEER_PRESENCE message will cause all its The arrival of this periodic PEER_PRESENCE message will cause all its
peers to update their internal variable "Peer-last-heared" for the peers to update their internal variable "peer.last.heard" for the
sending server (see Section 4.9.3 for more details). sending server (see Section 4.9.3 for more details).
4.9.3 Detecting Peer Server Failure 4.9.3 Detecting Peer Server Failure
An ENRP server MUST keep an interanl variable "Peer-last-heared" for An ENRP server MUST keep an internal variable "peer.last.heard" for
each of its known peers and the value of this variable MUST be each of its known peers and the value of this variable MUST be
updated to the current local time everytime a message of any type updated to the current local time everytime a message of any type
(point-to-point or announcement) is received from the cooresponding (point-to-point or announcement) is received from the corresponding
peer. peer.
If a peer has not been heard for more than MAX-TIME-LAST-HEARD If a peer has not been heard for more than MAX-TIME-LAST-HEARD
seconds, the ENRP server MUST immediately send a point-to-point seconds, the ENRP server MUST immediately send a point-to-point
PEER_PRESENCE with 'Reply_request' flag set to '1' to that peer. PEER_PRESENCE with 'Reply_request' flag set to '1' to that peer.
If the send fails or the peer does not reply after If the send fails or the peer does not reply after
MAX-TIME-NO-RESPONSE seconds, the ENRP server MUST consider the peer MAX-TIME-NO-RESPONSE seconds, the ENRP server MUST consider the peer
server dead and SHOULD initiate the takeover procedure defined in server dead and SHOULD initiate the takeover procedure defined in
Section 4.10. Section 4.10.
4.10 Taking-over a Failed Peer Server 4.10 Taking-over a Failed Peer Server
In the following descriptions, We call the ENRP server that detects In the following descriptions, We call the ENRP server that detects
the failed peer server and initiates the take-over the "initiating the failed peer server and initiates the take-over the "initiating
server" and the failed peer server the "target server." server" and the failed peer server the "target server."
4.10.1 Initiate Server Take-over Arbitration 4.10.1 Initiate Server Take-over Arbitration
The initiating server SHOULD fisrt start a take-over arbitration The initiating server SHOULD first start a take-over arbitration
process by announcing a PEER_INIT_TAKEOVER message to all its peer process by announcing a PEER_INIT_TAKEOVER message to all its peer
servers. See Section 4.1 on how annoucements are sent. In the servers. See Section 4.1 on how announcements are sent. In the
message, the initiating server MUST fill in the Sender Server's ID message, the initiating server MUST fill in the Sender Server's ID
and Target Server's ID. and Target Server's ID.
After announcing the PEER_INIT_TAKEOVER message, the initiating After announcing the PEER_INIT_TAKEOVER message, the initiating
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:
skipping to change at page 35, line 22 skipping to change at page 35, line 35
Message losses or certain temporary breaks in network connectivity Message losses or certain temporary breaks in network connectivity
may result in data inconsistency in the local namespace copy of some may result in data inconsistency in the local namespace copy of some
of the ENRP servers in an operation scope. Therefore, each ENRP of the ENRP servers in an operation scope. Therefore, each ENRP
server in the operation scope SHOULD periodically verify that its server in the operation scope SHOULD periodically verify that its
local copy of namespace data is still in sync with that of its peers. local copy of namespace data is still in sync with that of its peers.
This section defines the auditing and re-synchronization procedures This section defines the auditing and re-synchronization procedures
for an ENRP server to maintain its namespace data consistency. for an ENRP server to maintain its namespace data consistency.
4.11.1 Auditing Prodecures 4.11.1 Auditing Procedures
[TBD] The auditing of namespace consistency is based on the following
procedures:
4.11.2 Re-synchronization Prodecures 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit
integer internal variable) for each of its known peers and for
itself. For an ENRP server with 'k' known peers, we denote these
internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ...,
"pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE
checksum. The definition and detailed algorithm for calculating
these PE checksum variables are given in Section 4.11.2.
Once an ENRP server determines that there is inconsistancy between 2. Each time an ENRP server sends out a PEER_PRESENCE, it SHOULD
include in the message its current PE checksum (i.e.,
"pe.checksum.pr0").
3. When an ENRP server (server A) receives a PE checksum (carried in
an arrived PEER_PRESENCE) from a peer ENRP server (server B),
server A SHOULD compare the PE checksum found in the
PEER_PRESENCE with its own internal PE checksum of server B
(i.e., "pe.checksum.prB").
4. If the two values match, server A will consider that there is no
namespace inconsistency between itself and server B and should
take no further actions.
5. If the two values do NOT match, server A SHOULD consider that
there is a namespace inconsistency between itself and server B
and a re-synchronization process SHOULD be carried out
immediately with server B (see Section 4.11.3).
4.11.2 PE Checksum Calculation Algorithm
When an ENRP server (server A) calculate an internal PE checksum for
a peer (server B), it MUST use the following algorithm.
Let us assume that in server A's internal namespace there are
currently 'M' PEs that are owned by server B. Each of the 'M' PEs
will then contribute to the checksum calculation with the following
byte block:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle string of the pool the PE belongs (padded with :
: zeros to next 32-bit word boundary if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Id (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, these are not TLVs. This byte block gives each PE a unique byte
pattern in the scope. The 32-bit PE checksum for server B
"pe.checksum.prB" is then calculated over the byte blocks contributed
by the 'M' PEs one by one.
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
itself.
Note, whenever an ENRP finds that its internal namespace has changed
(e.g., due to PE registration/deregistration, receiving peer updates,
removing failed PEs, downloading namespace pieces from a peer, etc.),
it MUST immediately update all its internal PE checksums that are
affected by the change.
Implementation Note: when the internal namespace changes (e.g., a new
PE added or an existing PE removed), an implementation needs not to
re-calculate the affected PE checksum; it should instead simply
update the checksum by adding or subtracting the byte block of the
corresponding PE from the previous checksum value.
4.11.3 Re-synchronization Procedures
Once an ENRP server determines that there is inconsistency between
its local namespace data and a peer's namespace data with regarding its local namespace data and a peer's namespace data with regarding
to the PEs owned by that peer, it SHOULD perform the following steps to the PEs owned by that peer, it SHOULD perform the following steps
to re-synchronize the data: to re-synchronize the data:
1. The ENRP server SHOULD first "mark" every PE it knows about that 1. The ENRP server SHOULD first "mark" every PE it knows about that
is owned by the peer in its local namespace database; is owned by the peer in its local namespace database;
2. The ENRP server SHOULD then send a PEER_NAME_TABLE_REQUEST 2. The ENRP server SHOULD then send a PEER_NAME_TABLE_REQUEST
message with W flag set to '1' to the peer to request a complete message with W flag set to '1' to the peer to request a complete
list of PEs owned by the peer; list of PEs owned by the peer;
skipping to change at page 36, line 18 skipping to change at page 37, line 50
remain "marked" in its local namespace. If so, the ENRP server remain "marked" in its local namespace. If so, the ENRP server
SHOULD silently remove those "marked" entries. SHOULD silently remove those "marked" entries.
Note, similar to what is described in Section 4.2.3, the peer may Note, similar to what is described in Section 4.2.3, the peer may
reject the PEER_NAME_TABLE_REQUEST or use more than one reject the PEER_NAME_TABLE_REQUEST or use more than one
PEER_NAME_TABLE_RESPONSE message to respond. PEER_NAME_TABLE_RESPONSE message to respond.
4.12 Handling Unrecognized Message or Unrecognized Parameter 4.12 Handling Unrecognized Message or Unrecognized Parameter
When an ENRP server receives an ENRP message with an unknown message When an ENRP server receives an ENRP message with an unknown message
type or a message of known type that contains an unknow parameter, it type or a message of known type that contains an unknown parameter,
SHOULD handle the unknow message or the unknown parameter according it SHOULD handle the unknown message or the unknown parameter
to the unrecognized message and parameter handling rules defined in according to the unrecognized message and parameter handling rules
Sections 3 and 4 in [10]. defined in Sections 3 and 4 in [10].
According to the rules, if an error report to the message sender is According to the rules, if an error report to the message sender is
needed, the ENRP server that discovered the error SHOULD send back an needed, the ENRP server that discovered the error SHOULD send back an
ENRP_ERROR message with proper error cause code. ENRP_ERROR message with proper error cause code.
5. Variables and Time Constants 5. Variables and Thresholds
5.1 Variables 5.1 Variables
Peer-last-heared - 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).
5.2 Timer Constants 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
known peers as well as for itself.
MAX-TIME-SERVER-HUNT - the maximal number of attempts a sender will 5.2 Thresholds
MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender will
make to contact an ENRP server (Default=3 times). 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 secends). 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
heartheat 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 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
Due to varying requirements and multiple use cases of Rserpool, we Threats Introduced by Rserpool and Requirements for Security in
point out two basic security protocols, IPsec and TLS. We Response to Threats [11] describes the threats to the Rserpool
specifically do not discuss whether one security protocol would be architecture in detail and lists the security requirements in
preferred over the other. This choice will be made by designers and response to each threat. From the threats described in this document,
network architects based on system requirements. the security services required for the Rserpool protocol are
enumerated below.
For networks that demand IPsec security, implementations MUST support Threat 1) PE registration/deregistration flooding or spoofing
[9] which describes IPsec-SCTP. IPsec is two layers below RSerPool. -----------
Therefore, if IPsec is used for securing Rserpool, no changes or Security mechanism in response: ENRP server authenticates the PE
special considerations need to be made to Rserpool to secure the
protocol.
For networks that cannot or do not wish to use IPsec and prefer Threat 2) PE registers with a malicious ENRP server
instead TLS, implementations MUST support TLS with SCTP as described -----------
in [8] or TLS over TCP as described in [6]. When using TLS/SCTP we Security mechanism in response: PE authenticates the ENRP server
must ensure that RSerPool does not use any features of SCTP that are
not available to an TLS/SCTP user. This is not a difficult technical
problem, but simply a requirement. When describing an API of the
RSerPool lower layer we have also to take into account the
differences between TLS and SCTP. This is also not difficult, but it
is in contrast to the IPsec solution which is transparently layered
below Rserpool.
Support for security is required for the ENRP server and the PEs. Threat 1 and 2 taken together results in mutual authentication of the
Security support for the Rserpool end user is optional. Note that ENRP server and the PE.
the end user implementation contains a piece of the Rserpool protocol
-- namely ASAP -- whereby the pool handle is passed for name
resolution to the ENRP server and IP address(es) are returned.
The argument for optional end user security is as follows: If the Threat 3) Malicious ENRP server joins the ENRP server pool
user doesn't require security protection for example, against -----------
eavesdropping for the request for pool handle resolution and Security mechanism in response: ENRP servers mutually authenticate
response, then they are free to make that choice. However, if the
end user does require security, they are guaranteed to get it due to Threat 4) A PU communicates with a malicious ENRP server for name
the requirement for security support for the ENRP server. It is also resolution
possible for the ENRP server to reject an unsecured request from the -----------
user due to its security policy in the case that it requires Security mechanism in response: The PU authenticates the ENRP server
enforcement of strong security. But this will be determined by the
security requirements of the individual network design. Threat 5) Replay attack
-----------
Security mechanism in response: Security protocol which has
protection from replay attacks
Threat 6) Corrupted data which causes a PU to have misinformation
concerning a pool handle resolution
-----------
Security mechanism in response: Security protocol which supports
integrity protection
Threat 7) Eavesdropper snooping on namespace information
-----------
Security mechanism in response: Security protocol which supports data
confidentiality
Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP
server
-----------
Security mechanism in response: ASAP must control the number of
endpoint unreachable messages transmitted from the PU to the ENRP
server.
Threat 9) Flood of Endpoint_KeepAlive messages to the PE from the
ENRP server
-----------
Security mechanism in response: ENRP server must control the number
of Endpoint_KeepAlive messages to the PE
To summarize the threats 1-7 require security mechanisms which
support authentication, integrity, data confidentiality, protection
from replay attacks.
For Rserpool we need to authenticate the following:
PU <---- ENRP Server (PU authenticates the ENRP server)
PE <----> ENRP Server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication)
We do not define any new security mechanisms specifically for
responding to threats 1-7. Rather we use existing IETF security
protocols to provide the security services required. TLS supports all
these requirements and MUST be implemented. The
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
minimum by implementers of TLS for Rserpool. For purposes of
backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other ciphersuite.
Threat 8 requires the ASAP protocol to limit the number of
Endpoint_Unreachable messages (see Section 3.5??? in [1]) to the ENRP
server.
Threat 9 requires the ENRP protocol to limit the number of
Endpoint_KeepAlive messages to the PE (see Section x.y???).
6.1 Implementing Security Mechanisms
ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must
support mutual authentication. ENRP servers must support mutual
authentication among themselves. PUs MUST authenticate ENRP servers.
ENRP servers and PEs SHOULD possess a site certificate whose subject
corresponds to their canonical hostname. PUs MAY have certificates
of their own for mutual authentication with TLS, but no provisions
are set forth in this document for their use. All Rserpool elements
that support TLS MUST have a mechanism for validating certificates
received during TLS negotiation; this entails possession of one or
more root certificates issued by certificate authorities (preferably
well-known distributors of site certificates comparable to those that
issue root certificates for web browsers).
Implementations MUST support TLS with SCTP as described in RFC3436
[8] or TLS over TCP as described in RFC2246 [6]. When using TLS/SCTP
we must ensure that RSerPool does not use any features of SCTP that
are not available to an TLS/SCTP user. This is not a difficult
technical problem, but simply a requirement. When describing an API
of the RSerPool lower layer we have also to take into account the
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 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-05 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-08
(work in progress), October 2002. (work in progress), October 2003.
[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., Ong, L., Loughney, [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney,
J. and M. Stillman, "Architecture for Reliable Server Pooling", "Architecture for Reliable Server Pooling",
draft-ietf-rserpool-arch-03 (work in progress), July 2002. 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",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999. 2246, January 1999.
[7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [7] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC
draft-ietf-tsvwg-tls-over-sctp-00 (work in progress), November 3436, December 2002.
2001.
[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 SCTP with IPsec", draft-ietf-ipsec-sctp-03 (work in the Use of Stream Control Transmission Protocol (SCTP) with
progress), February 2002. IPsec", RFC 3554, July 2003.
[10] Stewart, R. and Q. Xie, "Aggregate Server Access Protocol [10] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
(ASAP) and Endpoint Name Resolution (ENRP) common parameters Server Access Protocol (ASAP) and Endpoint Name Resolution
document", draft-ietf-rserpool-common-param-00 (work in (ENRP) common parameters document",
progress), July 2002. draft-ietf-rserpool-common-param-05 (work in progress), October
2003.
[11] Stillman, M., "Threats Introduced by Rserpool and Requirements
for Security in Response to Threats",
draft-ietf-rserpool-threats-02 (work in progress), Sept 2003.
Informative References Informative References
[11] 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
US US
 End of changes. 

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