draft-ietf-rserpool-enrp-05.txt   draft-ietf-rserpool-enrp-06.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Expires: August 30, 2003 R. Stewart Expires: November 13, 2003 R. Stewart
Cisco Cisco
M. Stillman M. Stillman
Nokia Nokia
March 1, 2003 May 15, 2003
Endpoint Name Resolution Protocol (ENRP) Endpoint Name Resolution Protocol (ENRP)
draft-ietf-rserpool-enrp-05.txt draft-ietf-rserpool-enrp-06.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 August 30, 2003. This Internet-Draft will expire on November 13, 2003.
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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . 26 4.3.1 Rules on PE Re-registration . . . . . . . . . . . . . . . 27
4.4 Handle PE De-registration . . . . . . . . . . . . . . . . 27 4.4 Handle PE De-registration . . . . . . . . . . . . . . . . 27
4.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 28 4.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 28
4.6 Server Namespace Update . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . 29 4.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . . . 30
4.7 Detecting and Removing Unreachable PE . . . . . . . . . . 30 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 . . . . . . 31
4.9 Maintaining Peer List and Monitoring Peer Status . . . . . 31 4.9 Maintaining Peer List and Monitoring Peer Status . . . . . 32
4.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . 32
4.10 Taking-over a Failed Peer Server . . . . . . . . . . . . . 32 4.10 Taking-over a Failed Peer Server . . . . . . . . . . . . . 33
4.10.1 Initiate Server Take-over Arbitration . . . . . . . . . . 32 4.10.1 Initiate Server Take-over Arbitration . . . . . . . . . . 33
4.10.2 Take-over Target Peer Server . . . . . . . . . . . . . . . 33 4.10.2 Take-over Target Peer Server . . . . . . . . . . . . . . . 34
4.11 Namespace Data Auditing and Re-synchronization . . . . . . 34 4.11 Namespace Data Auditing and Re-synchronization . . . . . . 35
4.11.1 Auditing Prodecures . . . . . . . . . . . . . . . . . . . 34 4.11.1 Auditing Prodecures . . . . . . . . . . . . . . . . . . . 35
4.11.2 Re-synchronization Prodecures . . . . . . . . . . . . . . 34 4.11.2 Re-synchronization Prodecures . . . . . . . . . . . . . . 35
4.12 Handling Unrecognized Message or Unrecognized Parameter . 35 4.12 Handling Unrecognized Message or Unrecognized Parameter . 36
5. Variables and Time Constants . . . . . . . . . . . . . . . 36 5. Variables and Time Constants . . . . . . . . . . . . . . . 37
5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 5.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Timer Constants . . . . . . . . . . . . . . . . . . . . . 36 5.2 Timer Constants . . . . . . . . . . . . . . . . . . . . . 37
6. Security Considerations . . . . . . . . . . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . . 38
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 38 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 39
Normative References . . . . . . . . . . . . . . . . . . . 39 Normative References . . . . . . . . . . . . . . . . . . . 40
Informative References . . . . . . . . . . . . . . . . . . 40 Informative References . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . 42
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 23, line 24 skipping to change at page 23, line 24
request a copy of the current namespace data from its mentor peer request a copy of the current namespace data from its mentor peer
server, by taking the following steps: server, by taking the following steps:
1. The initiating server MUST first send a PEER_NAME_TABLE_REQUEST 1. The initiating server MUST first send a PEER_NAME_TABLE_REQUEST
message to the mentor peer, with W flag set to '0', indicating message to the mentor peer, with W flag set to '0', indicating
that the entire namespace is requested. that the entire namespace is requested.
2. Upon the reception of this message, the mentor peer MUST start a 2. Upon the reception of this message, the mentor peer MUST start a
download session in which a copy of the current namespace data download session in which a copy of the current namespace data
maintained by the mentor peer is sent to the initiating server in maintained by the mentor peer is sent to the initiating server in
one or more PEER_NAME_TABLE_RESPONSE messages. one or more PEER_NAME_TABLE_RESPONSE messages (Note, the mentor
server may find it particularly desirable to use multiple
PEER_NAME_TABLE_RESPONSE messages to send the namespace when the
namespace is large, especially when forming and sending out a
single response containing a large namespace may interrupt its
other services).
If more than one PEER_NAME_TABLE_RESPONSE message are used during If more than one PEER_NAME_TABLE_RESPONSE message are used during
the download, the mentor peer MUST use the M flag in each the download, the mentor peer MUST use the M flag in each
PEER_NAME_TABLE_RESPONSE message to indicate whether this message PEER_NAME_TABLE_RESPONSE message to indicate whether this message
is the last one for the download session. In particular, the is the last one for the download session. In particular, the
mentor peer MUST set the M flag to '1' in the outbound mentor peer MUST set the M flag to '1' in the outbound
PEER_NAME_TABLE_RESPONSE if there is more data to be transferred PEER_NAME_TABLE_RESPONSE if there is more data to be transferred
and MUST keep track of the progress of the current download and MUST keep track of the progress of the current download
session. The mentor peer MUST set the M flag to '0' in the last session. The mentor peer MUST set the M flag to '0' in the last
PEER_NAME_TABLE_RESPONSE for the download session and close the PEER_NAME_TABLE_RESPONSE for the download session and close the
skipping to change at page 25, line 30 skipping to change at page 25, line 34
The ENRP server handles the REGISTRATION message according to the The ENRP server handles the REGISTRATION message according to the
following rules: following rules:
1. If the named pool does not exist in the namespace, the ENRP 1. If the named pool does not exist in the namespace, the ENRP
server MUST creates a new pool with that name in the namespace server MUST creates a new pool with that name in the namespace
and add the PE to the pool as its first PE; and add the PE to the pool as its first PE;
When a new pool is created, the overall member selection policy When a new pool is created, the overall member selection policy
of the pool MUST be set to the policy type indicated by the first of the pool MUST be set to the policy type indicated by the first
PE. PE, the overall pool transport type MUST be set to the transport
type indicated by the PE, and the overall pool data/control
channel configuration MUST be set to what is indicated in the
Transport Use field of the User Transport parameter by the
registering PE.
2. If the named pool already exists in the namespace, but the 2. If the named pool already exists in the namespace, but the
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 However, before adding the PE to the pool, the server MUST check
policy type indicated by the PE is the same as the overall policy if the policy type, transport type, and transport usage indicated
type of the pool. If different, the ENRP server MUST attempt to by the registering PE is consistent with those of the pool. If
override the PE's policy and make it the same as the overall different, the ENRP server MUST either attempt to override the
policy. PE's value(s) or to reject the registration if overriding is not
possible.
A. If no additional policy-related information are required to A. Inconsistent policy - If no additional policy-related
perform the override (e.g., overriding Least-used with information are required to perform an override of pool
Round-robin does not require additional policy-related policy (e.g., overriding Least-used with Round-robin does not
information), the ENRP server MUST replace the PE's policy require additional policy-related information), the ENRP
type with the overall policy type. server MUST replace the PE's policy type with the overall
policy type of the pool. However, if additional policy
information is required for the overriding (e.g., overriding
Round-robin with Least-load will require the knowledge of the
load factor of the PE), the ENRP server MUST reject the
registration.
B. If additional policy information is required (e.g., B. Inconsistent transport type - The ENRP server MUST reject the
overriding Round-robin with Least-load will require the registration.
knowledge of the load factor of the PE), the ENRP server MUST
reject the regirstration with an error code "Pooling policy C. Inconsistent data/control configuration - If the overall pool
inconsistent". configuration is "DATA ONLY", and the registering PE
indicates "CONTORL plus DATA", the ENRP server SHOULD accept
the registration but warn the PE that control channel cannot
be used. If the pool configuration is "CONTROL plus DATA" and
the PE indicates "DATA ONLY", the ENRP server MUST reject the
registration.
3. If the named pool already exists in the namespace AND the 3. If the named pool already exists in the namespace AND the
requesting PE is already a member of the pool, the ENRP server requesting PE is already a member of the pool, the ENRP server
SHOULD consider this as a re-registration case. The ENRP Server SHOULD consider this as a re-registration case. The ENRP server
SHOULD replace the attributes of the existing PE with the MUST perform the same tests on policy, transport type, transport
information carried in the received REGISTRATION message. use, as described above. If the re-registration is accepted after
the test, the ENRP Server SHOULD replace the attributes of the
existing PE with the information carried in the received
REGISTRATION message.
4. After accepting the registration, the ENRP server MUST assgin 4. After accepting the registration, the ENRP server MUST assgin
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 the server or by a peer of whether the PE was previously owned by this server or by another
it. 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
rejected, the ENRP server MUST indicate the rejection by including accepted, the ENRP server MUST set the 'R' flag in the
the proper Operation Error parameter in the REGISTRATION_RESPONSE REGISTRATION_RESPONSE to '0'. If the registration is rejected, the
message. ENRP server MUST indicate the rejection by setting the 'R' flag in
the REGISTRATION_RESPONSE to '1'.
If the registration is granted with a polcy override (see Step 2a If the registration is rejected, the ENRP server SHOULD include the
above), in the REGISTRATION_RESPONSE message the ENRP server SHOULD proper error cause(s) in the REGISTRATION_RESPONSE message.
also send back the registrant PE the new policy, in a Member
Selection Policy Parameter, so as to inform the PE that a policy
override is performed.
If the registration is granted (i.e., one of cases 1-3 above), the If the registration is granted but with an override of some PE's
ENRP server MUST assign itself to be the home ENRP server of the PE, original values, in the REGISTRATION_RESPONSE message the ENRP server
i.e., to "own" the PE. SHOULD include the proper error cause(s) so that the PE can be warned
about the overriding and be informed about the new value(s).
If the registration is granted (either a new registration or a
re-registration case), the ENRP server MUST assign itself to be the
home ENRP server of the PE, i.e., to "own" the PE.
Implementation note: for better performance, the ENRP server may Implementation note: for better performance, the ENRP server may
find it both efficient and convenient to internally maintain two find it both efficient and convenient to internally maintain two
separate PE lists or tables - one is for the PEs that are "owned" separate PE lists or tables - one is for the PEs that are "owned"
by the ENRP server and the other for all the PEs owned by its by the ENRP server and the other for all the PEs owned by its
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
 End of changes. 

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