draft-ietf-rserpool-enrp-04.txt   draft-ietf-rserpool-enrp-05.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Expires: March 4, 2003 R. Stewart Expires: August 30, 2003 R. Stewart
Cisco Cisco
M. Stillman M. Stillman
Nokia Nokia
September 3, 2002 March 1, 2003
Endpoint Name Resolution Protocol (ENRP) Endpoint Name Resolution Protocol (ENRP)
draft-ietf-rserpool-enrp-04.txt draft-ietf-rserpool-enrp-05.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 Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
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 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 March 4, 2003. This Internet-Draft will expire on August 30, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). 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
(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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . 26 4.3.1 Rules on PE Re-registration . . . . . . . . . . . . . . . 26
skipping to change at page 3, line 7 skipping to change at page 3, line 7
4.11.2 Re-synchronization Prodecures . . . . . . . . . . . . . . 34 4.11.2 Re-synchronization Prodecures . . . . . . . . . . . . . . 34
4.12 Handling Unrecognized Message or Unrecognized Parameter . 35 4.12 Handling Unrecognized Message or Unrecognized Parameter . 35
5. Variables and Time Constants . . . . . . . . . . . . . . . 36 5. Variables and Time Constants . . . . . . . . . . . . . . . 36
5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Timer Constants . . . . . . . . . . . . . . . . . . . . . 36 5.2 Timer Constants . . . . . . . . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . . 37
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 38 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 38
Normative References . . . . . . . . . . . . . . . . . . . 39 Normative References . . . . . . . . . . . . . . . . . . . 39
Informative References . . . . . . . . . . . . . . . . . . 40 Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . 41
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 37 skipping to change at page 8, line 37
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.
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 This parameter is optional. However, if this message is sent in
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, non- Note, at startup an ENRP server MUST pick a randomly generated,
zero 32-bit unsigned integer as its ID and MUST use this same ID for non-zero 32-bit unsigned integer as its ID and MUST use this same ID
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
server initialization or namespace re-synchronization. server initialization or namespace re-synchronization.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 11 skipping to change at page 19, line 11
This parameter, defined in [10], indicates the type of error(s) This parameter, defined in [10], indicates the type of error(s)
being reported. being reported.
4. ENRP Operation Procedures 4. ENRP Operation Procedures
In this section, we discuss the operation procedures defined by ENRP. In this section, we discuss the operation procedures defined by ENRP.
An ENRP server MUST following these procedures when sending, An ENRP server MUST following these procedures when sending,
receiving, or processing ENRP messages. receiving, or processing ENRP messages.
Many of the Rserpool events call for both server-to-server and PU/PE- Many of the Rserpool events call for both server-to-server and PU/
to-server message exchanges. Only the message exchanges and PE-to-server message exchanges. Only the message exchanges and
activities between an ENRP server and its peer(s) are considered activities between an ENRP server and its peer(s) are considered
within the ENRP scope and are defined in this document. within the ENRP scope and are defined in this document.
Procedures for exchanging messages between a PE/PU and ENRP servers Procedures for exchanging messages between a PE/PU and ENRP servers
are defined in [1]. are defined in [1].
4.1 Methods for Communicating amongst ENRP Servers 4.1 Methods for Communicating amongst ENRP Servers
Within an Rserpool operation scope, ENRP servers need to communicate Within an Rserpool operation scope, ENRP servers need to communicate
with each other in order to exchange information such as the pool with each other in order to exchange information such as the pool
skipping to change at page 20, line 21 skipping to change at page 20, line 21
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
Rserpool. Rserpool.
2. If an ENRP server disables multicast, it then: 2. If an ENRP server disables multicast, it then:
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 point-to- B. MUST transmit all its out-going announcements over
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 subcribe 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.
D. when sending out an announcement, MUST send a copy to the D. when sending out an announcement, MUST send a copy to the
well-known server multicast channel AND a copy to each of the well-known server multicast channel AND a copy to each of the
peers that are marked as multicast-disabled over a point-to- peers that are marked as multicast-disabled over a
point SCTP association. point-to-point SCTP association.
4.2 ENRP Server Initialization 4.2 ENRP Server Initialization
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
skipping to change at page 22, line 12 skipping to change at page 22, line 12
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 steps 2) and 3) for up to MAX-TIME-SERVER-HUNT times. After that,
that, if there is still no response, the initiating server MUST if there is still no response, the initiating server MUST assume
assume that it is alone in the operation scope. 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
skipping to change at page 24, line 46 skipping to change at page 24, line 46
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 reason. To cope with this, the initiating server SHOULD start a timer
timer everytime it finishes sending a PEER_NAME_TABLE_REQUEST to its everytime it finishes sending a PEER_NAME_TABLE_REQUEST to its mentor
mentor peer. If this timer expires without receiving a response from peer. If this timer expires without receiving a response from the
the mentor peer, the initiating server SHOULD abort the current mentor peer, the initiating server SHOULD abort the current download
download session and re-start a new namespace download with a backup session and re-start a new namespace download with a backup mentor
mentor peer, if one is available. 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 25, line 43 skipping to change at page 25, line 43
requesting PE is not currently a member of the pool, the ENRP requesting PE is not currently a member of the pool, the ENRP
server will add the PE as a new member to the pool; server will add the PE as a new member to the pool;
After adding the PE to the pool, the server MUST check if the After adding the PE to the pool, the server MUST check if the
policy type indicated by the PE is the same as the overall policy policy type indicated by the PE is the same as the overall policy
type of the pool. If different, the ENRP server MUST attempt to type of the pool. If different, the ENRP server MUST attempt to
override the PE's policy and make it the same as the overall override the PE's policy and make it the same as the overall
policy. policy.
A. If no additional policy-related information are required to A. If no additional policy-related information are required to
perform the override (e.g., overriding Least-used with Round- perform the override (e.g., overriding Least-used with
robin does not require additional policy-related Round-robin does not require additional policy-related
information), the ENRP server MUST replace the PE's policy information), the ENRP server MUST replace the PE's policy
type with the overall policy type. type with the overall policy type.
B. If additional policy information is required (e.g., B. If additional policy information is required (e.g.,
overriding Round-robin with Least-load will require the overriding Round-robin with Least-load will require the
knowledge of the load factor of the PE), the ENRP server MUST knowledge of the load factor of the PE), the ENRP server MUST
reject the regirstration with an error code "Pooling policy reject the regirstration with an error code "Pooling policy
inconsistent". inconsistent".
3. If the named pool already exists in the namespace AND the 3. If the named pool already exists in the namespace AND the
skipping to change at page 27, line 5 skipping to change at page 27, line 5
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, attributtes 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 re- A PE may modify its load factor value at any time via
registration. Based on the number of PEs in the pool and the pool's re-registration. Based on the number of PEs in the pool and the
overall policy type, this operation allows the PE to dynamically pool's overall policy type, this operation allows the PE to
control its share of inbound messages received by the pool (also see dynamically control its share of inbound messages received by the
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 type. The server MUST reject the re-registration if the PE attempt to
to change its policy type. In the rejection, the server SHOULD change its policy type. In the rejection, the server SHOULD attach an
attach an error code "Pooling Policy Inconsistent". error code "Pooling Policy Inconsistent".
Regardless whether it is the current owner of the PE, if the re- Regardless whether it is the current owner of the PE, if the
registration is granted to the PE, the ENRP server MUST assign itself re-registration is granted to the PE, the ENRP server MUST assign
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. identifer.
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 its namespace. Moreover, if the PE is the last one of the named pool,
pool, the ENRP server will remove the pool from the namespace as the ENRP server will remove the pool from the namespace as well.
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 12 skipping to change at page 30, line 10
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 annoucements 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 indicating the removal of an existing PE. The complete information of
of the PE and the pool its belongs to MUST be indicated in the the PE and the pool its belongs to MUST be indicated in the message
message with a PE parameter and a Pool Handle parameter, with a PE parameter and a Pool Handle parameter, respectively.
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
skipping to change at page 31, line 24 skipping to change at page 31, line 20
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. The PE or PU will either multicast or send a point-to-point server. For this reason, the PE or PU will need to maintain a list of
SERVER_HUNT message to one or more ENRP servers in the operation currently available ENRP servers in its scope.
scope. For the complete procedure of this, see Section ???? in [1].
To support this procedure, whenever a SERVER_HUNT message is received To help the PE or PU maintaining this list, an ENRP server, if it is
an ENRP server SHOULD immediately respond to the sending PE or PU enabled for multicast, SHOULD periodically send out a SERVER_ANNOUNE
with a SERVER_HUNT_RESPONSE message. message every SERVER-ANNOUNCE-CYCLE seconds to the well-known ASAP
multicast channel. And in the SERVER_ANNOUNE message the ENRP server
SHOULD include all the transport addresses available for ASAP
communications. If the ENRP server only supports SCTP for ASAP
communications, the transport information MAY be omitted in the
SERVER_ANNOUNCE message.
For the complete procedure of this, see Section 3.6?? in [1].
4.9 Maintaining Peer List and Monitoring Peer Status 4.9 Maintaining Peer List and Monitoring Peer Status
An ENRP server MUST keep an internal record on the status of each of An ENRP server MUST keep an internal record on the status of each of
its known peers. This record is referred to as the server's "peer its known peers. This record is referred to as the server's "peer
list" list"
4.9.1 Discovering New Peer 4.9.1 Discovering New Peer
If a message of any type is received from a previously unknown peer, If a message of any type is received from a previously unknown peer,
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 Reply- The ENRP server MUST send a PEER_PRESENCE message with the
required flag set to '1' to the source address found in the arrived Reply-required flag set to '1' to the source address found in the
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 splitted 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
skipping to change at page 32, line 29 skipping to change at page 32, line 32
An ENRP server MUST keep an interanl variable "Peer-last-heared" for An ENRP server MUST keep an interanl variable "Peer-last-heared" 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 cooresponding
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 MAX-TIME-NO- If the send fails or the peer does not reply after
RESPONSE seconds, the ENRP server MUST consider the peer server dead MAX-TIME-NO-RESPONSE seconds, the ENRP server MUST consider the peer
and SHOULD initiate the takeover procedure defined in Section 4.10. server dead and SHOULD initiate the takeover procedure defined in
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 fisrt start a take-over arbitration
skipping to change at page 33, line 9 skipping to change at page 33, line 13
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 an attempt to stop this take-over process. This indicates a false
false failure detection case by the initiating server. 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 34, line 23 skipping to change at page 34, line 26
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 currently known peers. Note, if the list of affected PEs is long,
long, the sender MAY announce the ownership changes in multiple 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 24 skipping to change at page 36, line 24
MAX-TIME-SERVER-HUNT - the maximal number of attempts a sender will MAX-TIME-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 secends).
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.) heartheat message to all its known peers. (Default=30 secs.)
SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a
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
skipping to change at page 39, line 8 skipping to change at page 39, line 8
security requirements of the individual network design. security requirements of the individual network design.
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-04 Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-05
(work in progress), July 2002. (work in progress), October 2002.
[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., Ong, L., Loughney,
J. and M. Stillman, "Architecture for Reliable Server Pooling", J. and M. Stillman, "Architecture for Reliable Server Pooling",
draft-ietf-rserpool-arch-03 (work in progress), July 2002. draft-ietf-rserpool-arch-03 (work in progress), July 2002.
[4] Bradner, S., "The Internet Standards Process -- Revision 3", [4] Bradner, S., "The Internet Standards Process -- Revision 3",
skipping to change at page 41, line 5 skipping to change at page 41, line 5
Maureen Stillman Maureen Stillman
Nokia Nokia
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
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
 End of changes. 

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