Network Working Group                                             Q. Xie
INTERNET-DRAFT
Internet-Draft                                                  Motorola
                                                            R.
Expires: March 4, 2003                                        R. Stewart
                                                                   Cisco Systems
                                                             M. Stillman
                                                                   Nokia

Expires in six months                                         May 2,
                                                       September 3, 2002

                Endpoint Name Resolution Protocol (ENRP)
                  <draft-ietf-rserpool-enrp-03.txt>
                    draft-ietf-rserpool-enrp-04.txt

Status of This this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026. RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 4, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   Endpoint Name Resolution Protocol (ENRP) is designed to work in
   conjunction with the Aggregate Server Access Protocol (ASAP) to
   accomplish the functionality of the Reliable Server Pooling
   (Rserpool) requirements and architecture.  Within the operational
   scope of Rserpool, ENRP defines the procedures and message formats of
   a distributed, fault-tolerant registry service for storing,
   bookkeeping, retrieving, and distributing pool operation and
   membership information.

Table Of of Contents

   1. Introduction...............................................2
   1.2 Definitions...............................................2     Introduction . . . . . . . . . . . . . . . . . . . . . . .   4
   1.1    Definitions  . . . . . . . . . . . . . . . . . . . . . . .   4
   2. Conventions................................................3     Conventions  . . . . . . . . . . . . . . . . . . . . . . .   6
   3.     ENRP Message Definitions...................................3 Definitions . . . . . . . . . . . . . . . . .   7
   3.1    PEER_PRESENCE message.....................................4 message  . . . . . . . . . . . . . . . . . .   7
   3.2    PEER_NAME_TABLE_REQUEST message...........................5 message  . . . . . . . . . . . . .   8
   3.3    PEER_NAME_TABLE_RESPONSE message..........................5 message . . . . . . . . . . . . .   9
   3.4    PEER_NAME_UPDATE message..................................7 message . . . . . . . . . . . . . . . . .  11
   3.5    PEER_LIST_REQUEST message.................................7 message  . . . . . . . . . . . . . . . .  12
   3.6    PEER_LIST_RESPONSE message................................8 message . . . . . . . . . . . . . . . .  13
   3.7    PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . .  14
   3.8    PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . .  15
   3.9    PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . .  16
   3.10   PEER_OWNERSHIP_CHANGE message  . . . . . . . . . . . . . .  16
   3.11   PEER_ERROR message . . . . . . . . . . . . . . . . . . . .  18
   4.     ENRP Operation Procedures..................................9 Procedures  . . . . . . . . . . . . . . . .  19
   4.1    Methods for Communicating amongst ENRP Servers............9 Servers . . . . . .  19
   4.2    ENRP Server Initialization................................10 Initialization . . . . . . . . . . . . . . . .  20
   4.2.1  Generate a Server Identifier ...........................11 . . . . . . . . . . . . . . .  21
   4.2.2  Acquire Peer Server List................................11
   4.2.2.1 Find the mentor server................................11
   4.2.2.2 Request complete server list from mentor peer.........12 List . . . . . . . . . . . . . . . . .  21
   4.2.3  Download ENRP Namespace Data from mentor Peer...........13 Mentor Peer  . . . . . .  23
   4.3    Handle PE Registration....................................14 Registration . . . . . . . . . . . . . . . . . .  25
   4.3.1  Rules on PE Re-registration.............................16 Re-registration  . . . . . . . . . . . . . . .  26
   4.4    Handle PE De-registration.................................16 De-registration  . . . . . . . . . . . . . . . .  27
   4.5    Pool Handle Translation...................................17 Translation  . . . . . . . . . . . . . . . . .  28
   4.6    Server Namespace Update...................................17 Update  . . . . . . . . . . . . . . . . .  28
   4.6.1  Announcing Addition or Update of PE.....................17 PE  . . . . . . . . . . .  29
   4.6.2  Announcing Removal of PE................................18 PE . . . . . . . . . . . . . . . . .  29
   4.7    Detecting and Removing Unreachable PE.....................19 PE  . . . . . . . . . .  30
   4.8    Helping PE and PU to Discover Home ENRP Server............19 Server . . . . . .  31
   4.9    Maintaining Peer List and Monitoring Peer Status..........20 Status . . . . .  31
   4.9.1  Discovering New Peer....................................20 Peer . . . . . . . . . . . . . . . . . . .  31
   4.9.2  Server Sending Heartbeat................................20 Heartbeat . . . . . . . . . . . . . . . . .  32
   4.9.3  Detecting Peer Server Failure...........................20 Failure  . . . . . . . . . . . . . .  32
   4.10   Taking-over a Failed Peer Server . . . . . . . . . . . . .  32
   4.10.1 Initiate Server Take-over Arbitration  . . . . . . . . . .  32
   4.10.2 Take-over Target Peer Server . . . . . . . . . . . . . . .  33
   4.11   Namespace Data Auditing and Re-synchronization...........21
   4.10 Reporting Re-synchronization . . . . . .  34
   4.11.1 Auditing Prodecures  . . . . . . . . . . . . . . . . . . .  34
   4.11.2 Re-synchronization Prodecures  . . . . . . . . . . . . . .  34
   4.12   Handling Unrecognized Message or Unrecognized Parameter................................21 Parameter  .  35
   5. Protocol     Variables and Time Constants......................21 Constants . . . . . . . . . . . . . . .  36
   5.1 Variables.................................................21    Variables  . . . . . . . . . . . . . . . . . . . . . . . .  36
   5.2    Timer Constants...........................................21 Constants  . . . . . . . . . . . . . . . . . . . . .  36
   6.     Security Considerations....................................22 Considerations  . . . . . . . . . . . . . . . . .  37
   7. References.................................................22
   7.1     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  38
          Normative References . . . . . . . . . . . . . . . . . . .  39
          Informative References....................................23
   8. Acknowledgements...........................................23
   9. References . . . . . . . . . . . . . . . . . .  40
          Authors' Addresses.........................................23 Addresses . . . . . . . . . . . . . . . . . . . .  40
          Full Copyright Statement . . . . . . . . . . . . . . . . .  41

1. Introduction

   ENRP is designed to work in conjunction with ASAP [ASAP] [1] to accomplish
   the functionality of Rserpool as defined by its requirements [RFC3237] [2] and
   architecture [RSPL-ARCH]. [3].

   Within the operation scope of Rserpool, ENRP defines the procedures
   and message formats of a distributed fault-tolerant registry service
   for storing, bookkeeping, retrieving, and distributing pool operation
   and membership information.

   Whenever appropriate, in the rest of this document we will refer to
   this Rserpool registry service as ENRP namespace, or simply
   namespace.

1.2

1.1 Definitions

   This document uses the following terms:

   Operation scope: See [RSPL-ARCH]. [3];

   Pool (or server pool): See [RSPL-ARCH]. [3];

   Pool handle (or pool name): See [RSPL-ARCH]. [3];

   Pool element (PE): See [RSPL-ARCH]. [3];

   Pool user (PU): See [RSPL-ARCH]. [3];

   Pool element handle: See [RSPL-ARCH]. [3];

   ENRP namespace (or namespace): See [RSPL-ARCH]. [3];

   ENRP namespace server (or ENRP server): See [RSPL-ARCH]. [3];

   ENRP client channel: The communication channel through which a PE
      requests for ENRP namespace service.  The ENRP client channel is
      usually defined by the transport address of the home ENRP server
      and a well known port number. number;

   ENRP server channel: Defined by a well known multicast IP address and
      a well known port number.  All ENRP servers in an operation scope
      can send multicast messages to other servers through this channel.
      PEs are also allowed to multicast on this channel
        occasionally. occasionally;

   Home ENRP server: The ENRP server to which a PE or PU currently
      belongs.  A PE MUST only have one home ENRP server at any given
      time and both the PE and its home ENRP server MUST keep track of
      this master/slave relationship between them.  A PU SHOULD select
      one of the available ENRP servers as its home ENRP server, but the
      ENRP server does not need to know, nor does it need to keep track
      of this relationship.

2. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   [RFC2119].
   [5].

3. ENRP Message Definitions

   In this section, we defines the format of all ENRP messages.  These
   are messages sent and received amongst ENRP servers in an operation
   scope.  Messages sent and received between a PE/PU and an ENRP server
   are part of ASAP and are defined in [ASAP]. [1].  A common format, defined in [RSPL-PARAM],
   [10], is used for all ENRP and ASAP messages.

   Most ENRP messages contains a combination of fixed fields and TLV
   parameters.  The TLV parameters are also defined in [PARAMS]. [10].

   All messages, as well as their fields/parameters described below,
   MUST be transmitted in network byte order (a.k.a.  Big Endian, i.e.,
   the most significant byte first).

   For ENRP, the following message types are defined:

         Type       Message Name
         -----      -------------------------
         0x0       - (reserved by IETF)
         0x1       - PEER_PRESENCE
         0x2       - PEER_NAME_TABLE_REQUEST
         0x3       - PEER_NAME_TABLE_RESPONSE
         0x4       - PEER_NAME_UPDATE
         0x5       - PEER_LIST_REQUEST
         0x6       - PEER_LIST_RESPONSE
      0x7-0x11
         0x7       - ASAP messages, defined in [ASAP].
      0x12-0xFF PEER_INIT_TAKEOVER
         0x8       - PEER_INIT_TAKEOVER_ACK
         0x9       - PEER_TAKEOVER_SERVER
         0xa       - PEER_OWNERSHIP_CHANGE
         0xb       - PEER_ERROR
         0xc-0xFF  - (reserved by IETF)

3.1 PEER_PRESENCE message

   This ENRP message is used to announce (periodically) the presence of
   an ENRP server, or to probe the status of a peer ENRP sever.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x1  |0|0|0|0|0|0|0|R|     Message Length = 0xC      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :               Server Information Param (optional)             :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      R (reply_required) flag: 1 bit

         Set to '1' if the sender requires a response to this message,
         otherwise set to '0'.

      Sender Server's ID: 32 bit (unsiged integer)

         This is the ID of the ENRP server which sends the message.

      Receiver Server's ID: 32 bit (unsiged integer)

         This is the ID of the ENRP server to which the message is
         intended.  If the message is not intended to an individual
         server (e.g., the message is multicasted to a group of
         servers), this field MUST be set with all 0's.

      Server Information Parameter:

         If present, contains the server information of the sender of
         this message (Server Information Parameter is defined in [10]).
         This parameter is optional.  However, if this message is sent
         in response to a received "reply required" PEER_PRESENCE from a
         peer, the sender then MUST include its server information.

   Note, at startup an ENRP server MUST pick a randomly generated,
   non-zero non-
   zero 32-bit unsigned integer as its ID and MUST use this same ID for
   its entire life.

3.2 PEER_NAME_TABLE_REQUEST message

   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
   server initialization or namespace re-synchronization.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x2  |0|0|0|0|0|0|0|0|  |0|0|0|0|0|0|0|W|    Message Length = 0xC       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      W (oWn-children-only) flag: 1 bit

         Set to '1' if the sender of this message is only requesting
         information about the PEs owned by the message receiver.
         Otherwise, set to '0'.

      Sender Server's ID:

         See section Section 3.1.

      Receiver Server's ID:

         See section Section 3.1.

3.3 PEER_NAME_TABLE_RESPONSE message
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x3  |0|0|0|0|0|0|R|M|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                     Pool entry #1 (see below)                 :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                              ...                              :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                     Pool entry #n (see below)                 :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      R (Reject) flag: 1 bit

         MUST be set to '1' if the sender of this message is rejecting a
         namespace request.  In such a case, this message MUST be sent
         with no pool entries included.

      M (More_to_send) flag: 1 bit

         Set to '1' if the sender has more pool entries to sent in
         subsequent PEER_NAME_TABLE_RESPONSE messages, otherwise, set to
         '0'.

      Message Length: 16 bits (unsigned integer)

         Indicates the entire length of the message in number of octets.

         Note, the value in Message Length field will NOT cover any
         padding at the end of this message.

      Sender Server's ID:

         See section Section 3.1.

      Receiver Server's ID:

         See section Section 3.1.

      Pool entry #1-#n:

         If R flag is '0', at least one pool entry SHOULD be present in
         the message.  Each pool entry MUST start with a pool handle
         parameter as defined in section 3.1.7, followed by one or more
         pool element parameters, i.e.:

                   +---------------------------+
                   :      Pool handle          :
                   +---------------------------+
                   :         PE #1             :
                   +---------------------------+
                   :         PE #2             :
                   +---------------------------+
                   :          ...              :
                   +---------------------------+
                   :         PE #n             :
                   +---------------------------+

3.4 PEER_NAME_UPDATE message

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x4  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Update Action          |        (reserved)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                        Pool handle                            :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                        Pool Element                           :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Message Length: 16 bits (unsigned integer)

         Indicates the entire length of the message in number of octets.

         Note, the value in Message Length field will NOT cover any
         padding at the end of this message.

      Update Action: 16 bits (unsigned integer)

         This field indicates what act is requested to the specified PE.
         It MUST take one of the following values:

         0x0 - ADD_PE: add or update the specified PE in the ENRP
            namespace

         0x1 - DEL_PE: delete the specified PE from the ENRP namespace.

         Other values are reserved by IETF and MUST not be used.

      Reserved: 16 bits

         MUST be set to 0's by sender and ignored by the receiver.

      Sender Server's ID:

         See section Section 3.1.

      Receiver Server's ID:

         See section Section 3.1.

      Pool handle:

         Specifies to which the PE belongs.

      Pool Element:

         Specifies the PE.

3.5 PEER_LIST_REQUEST message

   This ENRP message is used to request a copy of the current known ENRP
   peer server list.  This message is normally sent from a newly started
   ENRP server to an existing ENRP server as part of the initialization
   process of the new server.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x5  |0|0|0|0|0|0|0|0|    Message Length = 0xC       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sender Server's ID:

         See section Section 3.1.

      Receiver Server's ID:

         See section Section 3.1.

3.6 PEER_LIST_RESPONSE message

   This message is used to respond a PEER_LIST_REQUEST.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x6  |0|0|0|0|0|0|0|R|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                   Server Info Param of Peer #1                :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                           ...                                 :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                   Server Info Param of Peer #n                :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      R (Reject) flag: 1 bit

         MUST be set to '1' if the sender of this message is rejecting a
         peer list request.  In such a case, this message MUST be sent
         with no peer server ID included.

      Message Length: 16 bits (unsigned integer)

         Indicates the entire length of the message in number of octets.

         Note, the value in Message Length field will NOT cover any
         padding at the end of this message.

      Sender Server's ID:

         See section Section 3.1.

      Receiver Server's ID:

         See section Section 3.1.

      Server Information Parameter of Peer #1-#n:

         Each contains a Server Information Parameter of a peer known to
         the sender.  The Server Information Parameter is defined in
      [RSPL-PARAM].

4. ENRP Operation Procedures

   In this section, we discuss the operation procedures defined by
   ENRP. An ENRP server MUST following these procedures when sending,
   receiving, or processing ENRP messages.

   Many of the Rserpool events call for both server-to-server and
   PU/PE-to-server
         [10].

3.7 PEER_INIT_TAKEOVER message exchanges. Only the

   This message exchanges and
   activities between is used by an ENRP server and its peer(s) are considered
   within the ENRP scope and are defined in this document.

   Procedures for exchanging messages between a PE/PU and ENRP servers
   are defined in [ASAP].

4.1 Methods for Communicating amongst ENRP Servers

   Within an Rserpool operation scope, ENRP servers need to
   communicate with each other in order (the takeover initiator) to exchange information such
   as the pool membership changes, namespace data synchronization,
   etc.

   Two types
   declare its intention of communications are used amongst ENRP servers:

     - point-to-point message exchange from one ENPR server to taking over a specific peer server, and

     - announcements from one server to all its peer servers in the
       operation scope.

   Point-to-point communication is always carried out over an SCTP
   associaiton between the sending server ENRP server.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x7  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Target Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sender Server's ID:

         See Section 3.1.

      Receiver Server's ID:

         See Section 3.1.

      Target Server's ID:

         Contains the 32-bit server ID of the peer ENRP that is the
         target of this takeover attempt.

3.8 PEER_INIT_TAKEOVER_ACK message

   This message is used to acknowledge the takeover initiator that the
   sender of this message received the PEER_INIT_TAKEOVER message and
   that it does not object to the takeover.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x8  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Target Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sender Server's ID:

         See Section 3.1.

      Receiver Server's ID:

         See Section 3.1.

      Target Server's ID:

         Contains the 32-bit server ID of the peer ENRP that is the
         target of this takeover attempt.

3.9 PEER_TAKEOVER_SERVER message

   This message is used by the takeover initiator to declare that a
   takeover is underway.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x9  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Target Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sender Server's ID:

         See Section 3.1.

      Receiver Server's ID:

         See Section 3.1.

      Target Server's ID:

         Contains the 32-bit server ID of the peer ENRP that is the
         target of this takeover operation.

3.10 PEER_OWNERSHIP_CHANGE message

   This message is used by the ENRP server, normally after a successful
   takeover, to declare that it is now the new home ENRP server of the
   listed PEs in the listed pools.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0xa  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                       Pool handle #1                          :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :              PE Identifier Param #1 of pool #1                :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                              ...                              :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :              PE Identifier Param #k of pool #1                :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                              ...                              :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                       Pool handle #M                          :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :              PE Identifier Param #1 of pool #M                :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                              ...                              :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :              PE Identifier Param #n of pool #M                :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sender Server's ID:

         See Section 3.1.

      Receiver Server's ID:

         See Section 3.1.

      Pool handles and PE Identifier parameters:

         Each listed pool handle is followed by a list of PE Identifier
         parameters, indicating that the sender of this message is
         taking ownership of the listed PEs in the pool.

3.11 PEER_ERROR message

   This message is used by an ENRP server to report an operation error
   to one of its peers.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0xb  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                   Operation Error Parameter                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sender Server's ID:

         See Section 3.1.

      Receiver Server's ID:

         See Section 3.1.

      Operation Error Parameter:

         This parameter, defined in [10], indicates the type of error(s)
         being reported.

4. ENRP Operation Procedures

   In this section, we discuss the operation procedures defined by ENRP.
   An ENRP server MUST following these procedures when sending,
   receiving, or processing ENRP messages.

   Many of the Rserpool events call for both server-to-server and PU/PE-
   to-server message exchanges.  Only the message exchanges and
   activities between an ENRP server and its peer(s) are considered
   within the ENRP scope and are defined in this document.

   Procedures for exchanging messages between a PE/PU and ENRP servers
   are defined in [1].

4.1 Methods for Communicating amongst ENRP Servers

   Within an Rserpool operation scope, ENRP servers need to communicate
   with each other in order to exchange information such as the pool
   membership changes, namespace data synchronization, etc.

   Two types of communications are used amongst ENRP servers:

   o  point-to-point message exchange from one ENPR server to a specific
      peer server, and

   o  announcements from one server to all its peer servers in the
      operation scope.

   Point-to-point communication is always carried out over an SCTP
   associaiton between the sending server and the receiving server.

   Announcements are communicated out with one of the following two
   approaches:

   1.  The sending server sends the announcement message to a well-known
       RSERPOOL IP multicast channel that its peer servers subscribe to.

       Note: Because IP multicast is not reliable, this approach does
       not gaurrantee that all the peers will receive the announcement
       message.  Moreover, since IP multicast is not secure, this
       approach cannot provide any security to the communication.

   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
       associations between the sending server and the peers.

       This approach gaurrantees the reliabe receiption of the message.
       When needed, data security can be achieved by using IP security
       mechanisms such as IPsec [9] or TLS [8].

   In order to maximize inter-operability of ENRP servers, the following
   rules MUST be followed:

   1.  At the startup time, a new ENRP server SHOULD make a decision on
       whether it will enable IP multicast for ENRP announcements.  This
       decision should be based on factors such as the availability of
       IP multicast and the security requirements from the user of
       Rserpool.

   2.  If an ENRP server disables multicast, it then:

       A.  MUST NOT subscribe to the well-known server multicast
           channel, i.e., it only receives peer announcements over SCTP
           associations, and

       B.  MUST transmit all its out-going announcements over point-to-
           point SCTP associations with its peers.

   3.  If an ENRP server enables itself to use multicast, it then:

       A.  MUST subcribe to the well-known server multicast channel to
           ready itself for receiving
   server.

   Announcements peers' multicast announcements,

       B.  MUST also be prepared to receive peer announcements over
           point-to-point SCTP associations from peers.

       C.  MUST track internally which peers are communicated multicast-enabled and
           which are not.  Note: A peer is always assumed to be
           multicast-disabled until/unless an ENRP message of any type
           is received from that peer over the well-known server
           multicast channel.

       D.  when sending out with one an announcement, MUST send a copy to the
           well-known server multicast channel AND a copy to each of the
           peers that are marked as multicast-disabled over a point-to-
           point SCTP association.

4.2 ENRP Server Initialization

   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
   namespace service if it is the first ENRP server started in the
   operation scope.

4.2.1 Generate a Server Identifier

   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
   remain unchanged for the lifetime of the following two
   approaches:

     1) The sending server.  Normally, a good
   32-bit random number will be good enough as the server sends Id ([11]
   provides some information on randomness guidelines).

4.2.2 Acquire Peer Server List

   At startup, the announcement message ENRP server (initiating server) will first attempt to a
     well-known RSERPOOL IP multicast channel that its
   learn all existing peer ENRP servers subscribe to.

     Note: Because IP multicast in the same operation scope, or
   to determine that it is not reliable, along in the scope.

   The initiating server uses an existing peer server to bootstrap
   itself into service.  We call this approach does
     not gaurrantee that all peer server the peers will receive mentor server.

4.2.2.1 Find the announcement
     message. Moreover, since IP multicast mentor server

   If the initiating server is not secure, this
     approach cannot provide any security to told about an existing peer server
   through some administrative means (such as DNS query, configuration
   database, startup scripts, etc), the communication.

     2) The sending initiating server sends SHOULD then
   use this peer server as its mentor server and SHOULD skip the
   remaining steps in this subsection.

   If multiple copies of existing peer servers are specified, the announcement, initiating
   server SHOULD pick one to each of them as its mentor peer servers, over a set of point-to-point
     SCTP associations between server, keep the sending server
   others as its backup menter peers, and skip the peers.

     This approach gaurrantees remaining steps in
   this subsection.

   If no existing peer server is specified to the reliabe receiption of initiating server AND
   if multicast is available in the
     message. When needed, data security can be achieved by using IP
     security mechanisms such as IPsec [SCTP-IPSEC] or TLS [SCTP-TLS].

   In order to maximize inter-operability of ENRP servers, operation scope, the following rules MUST
   mentor peer discovery procedures SHOULD be followed:

     1) At

   1.  The initiating server SHOULD first join the startup time, a new well-known ENRP
       server multicast channel.

   2.  Then the initiating server SHOULD make send a decision
	on whether it will enable IP multicast for ENRP announcements.
	This decision should be based on factors such as PEER_PRESENCE message,
       with the
	availability of IP multicast and 'Reply_required' flag set, over the security requirements
	from multicast channel.
       Upon the user reception of Rserpool.

     2) If an ENRP this PEER_PRESENCE message, a peer server disables multicast, it then:

       2a)
       MUST NOT subscribe to send a PEER_PRESENCE, without the well-known server multicast
	   channel, i.e., it only receives peer announcements over
	   SCTP associations, and

       2b) MUST transmit all its out-going announcements over
	   point-to-point SCTP associations with its peers.

     3) If an ENRP server enables itself 'Reply_required' flag,
       back to use multicast, it then:

       3a) MUST subcribe the initiating server.

   3.  When the first response to its original PEER_PRESENCE arrives,
       the well-known initiating server multicast channel to
	   ready itself for receiving peers' multicast announcements,

       3b) MUST also be prepared to receive peer announcements over
	   point-to-point SCTP associations from peers.

       3c) MUST track internally which peers are multicast-enabled and
	   which are not. Note: A SHOULD take the sender of this received
       response as its mentor peer is always assumed to be
	   multicast-disabled until/unless an ENRP message server.  This completes the discovery
       of any type
	   is the mentor peer server.

       If responses are also received from that peer over other peers (a likely event
       when multiple peers exist in the well-known operation scope at the time the
       new server
	   multicast channel.

       3d) when sending out an announcement, MUST send a copy to started), the
	   well-known initiating server multicast channel AND SHOULD keep a copy to each list of
	   the
       those responded as its backup mentor peers that (see below).

   4.  If no response to its PEER_PRESENCE message are marked as multicast-disabled over a
	   point-to-point SCTP association.

4.2 ENRP Server Initialization

   This section describes received after
       TIMEOUT-SERVER-HUNT seconds, the steps a new ENRP initiating server needs to take in
   order to join the other existing ENRP servers, or SHOULD repeat
       steps 2) and 3) for up to initiate the
   namespace service MAX-TIME-SERVER-HUNT times.  After
       that, if it there is still no response, the first ENRP initiating server started MUST
       assume that it is alone in the operation scope.

4.2.1 Generate a Server Identifier

   A new ENRP server MUST generate a 32-bit

   5.  If the initiating server Id determined that it is alone in the
       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
       offering ENRP services.

   Note, if multicast is not available (or not allowed for reasons such
   as
   unique as possible security concerns) in the operation scope and this scope, at least one peer
   server Id MUST
   remain unchanged for be specified to the lifetime of initiating server through
   administrative means, unless the server. Normally, a good
   32-bit random number will be good enough as initiation server is the first
   server to start in the operation scope.

   Note, if the administratively specified menter peer(s) fails, the
   initiating server Id
   ([RFC1750] provides some information on randomness guidelines).

4.2.2 Acquire Peer Server List

   At startup, SHOULD use the auto-discover procedure defined in
   steps 1-5 above.

4.2.2.2 Request complete server list from mentor peer

   Once the initiating server finds its mentor peer server (by either
   discovery or administrative means), the ENRP initiating server (initiating server) will first attempt MUST send a
   PEER_LIST_REQUEST message to learn all existing peer ENRP servers in the same operation
   scope, or mentor peer server to determine that it is along in request a copy
   of the scope.

   The initiating complete server uses an existing list maintained by the mentor peer (see
   Section 4.9 for maintaining server to bootstrap
   itself into service. We call list).

   Upon the reception of this request, the mentor peer server SHOULD
   reply with a PEER_LIST_RESPONSE message and include in the message
   body all existing ENRP servers known by the mentor server.

4.2.2.1 Find peer.

   Upon the reception of the PEER_LIST_RESPONSE message from the mentor server

   If
   peer, the initiating server MUST use the server information carried
   in the message to initialize its own peer list.

   However, if the mentor itself is told about an existing in the process of startup and not
   ready to provide a peer server
   through some administrative means (such as DNS query, configuration
   database, startup scripts, etc), list (for example, the initiating server SHOULD then
   use this mentor peer server as is
   waiting for a response to its mentor own PEER_LIST_REQUEST to another
   server), it MUST rejest the request by the initiating server and SHOULD skip
   respond with a PEER_LIST_RESPONSE message with the
   remaining steps R flag set to '1',
   and with no server information included in this subsection.

   If multiple existing peer servers are specified, the response.

   In the case where its PEER_LIST_REQUEST is rejected by the mentor
   peer, the initiating server SHOULD pick one of them as its either wait for a few seconds and
   re-send the PEER_LIST_REQUEST to the mentor server, or if there is a
   backup mentor peer available, select another mentor peer server, keep the
   others as its backup menter peers, server and skip
   send the remaining steps
   in this subsection.

   If no existing PEER_LIST_REQUEST to the new mentor server.

4.2.3 Download ENRP Namespace Data from Mentor Peer

   After a peer server list download is specified to completed, the initiating server
   AND if multicast is available in the operation scope, MUST
   request a copy of the following current namespace data from its mentor peer discovery procedures SHOULD be followed:

   1)
   server, by taking the following steps:

   1.  The initiating server SHOULD MUST first join the well-known ENRP
      server multicast channel.

   2) Then the initiating server SHOULD send a PEER_PRESENCE message,
      with PEER_NAME_TABLE_REQUEST
       message to the 'Reply_required' mentor peer, with W flag set, over set to '0', indicating
       that the multicast channel. entire namespace is requested.

   2.  Upon the reception of this PEER_PRESENCE message, a the mentor peer server MUST send start a PEER_PRESENCE, without
       download session in which a copy of the 'Reply_required' flag,
      back current namespace data
       maintained by the mentor peer is sent to the initiating server.

   3) When server in
       one or more PEER_NAME_TABLE_RESPONSE messages.

       If more than one PEER_NAME_TABLE_RESPONSE message are used during
       the first response download, the mentor peer MUST use the M flag in each
       PEER_NAME_TABLE_RESPONSE message to its original PEER_PRESENCE arrives, indicate whether this message
       is the initiating server SHOULD take last one for the sender download session.  In particular, the
       mentor peer MUST set the M flag to '1' in the outbound
       PEER_NAME_TABLE_RESPONSE if there is more data to be transferred
       and MUST keep track of this received
      response as its the progress of the current download
       session.  The mentor peer server. This completes MUST set the discovery M flag to '0' in the last
       PEER_NAME_TABLE_RESPONSE for the download session and close the
       download session (i.e., removing any internal record of the mentor peer server.

      If responses are also received from other peers (a likely event
      when multiple peers exist in
       session) after sending out the operation scope at last message.

   3.  During the downloading, every time the
      new server started), the initiating server SHOULD keep receives
       a list of
      those responded as PEER_NAME_TABLE_RESPONSE message, it MUST transfer the data
       entries carried in the message into its backup mentor peers (see below).

   4) local namespace database,
       and then check whether or not this message is the last one for
       the download session.

       If no response the M flag is set to its PEER_PRESENCE message are received after
      <TIMEOUT-SERVER-HUNT> seconds, '1' in the just processed
       PEER_NAME_TABLE_RESPONSE message, the initiating server SHOULD
      repeat steps 2) and 3) for up MUST send
       another PEER_NAME_TABLE_REQUEST message to <MAX-TIME-SERVER-HUNT>
      times. After that, if there is still no response, the mentor peer to
       request for the next PEER_NAME_TABLE_RESPONSE message.

   4.  When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE
       message into its local namespace database, the initiating server
       MUST assume that it is alone handle each pool entry carried in the operation scope.

   5) message using the
       following rules:

       A.  If the initiating server determined that it is alone pool does not exist in the
      scope, it local namespace, the
           initiating server MUST skip creates the procedures pool in Sections 4.2.2.2? to
      4.2.3? and MUST consider its initialization complete the local
           namespace and start
      offering ENRP services.

   Note, if multicast is not available (or not allowed for reasons
   such as security concerns) add the PE(s) in the operation scope, at least one
   peer server MUST be specified pool entry to the initiating server through
   administrative means, unless pool.

           When creating the initiation server is pool, the first initiation server MUST set the
           overall member selection policy type of the pool to start the
           policy type indicated in the operation scope.

   Note, if first PE.

       B.  If the administratively specified menter peer(s) fails, pool already exists in the
   initiating server SHOULD use local namespace, but the auto-discover procedure defined
           PE(s) in
   steps 1-5 above.

4.2.2.2 Request complete server list from mentor peer

   Once the initiating server finds its mentor peer server (by either
   discovery or administrative means), pool entry is not currently a member of the
           pool, the initiating server MUST send
   a PEER_LIST_REQUEST message to add the mentor peer server PE(s) to request a
   copy of the complete server list maintained by pool.

       C.  If the mentor peer (see
   Section 4.9? for maintaining server list).

   Upon pool already exists in the reception local namespace AND the
           PE(s) in the Pool entry is already a member of this request, the mentor peer pool, the
           initiating server server SHOULD
   reply with a PEER_LIST_RESPONSE message and include in replace the message
   body all existing ENRP servers known by attributes of the mentor peer.

   Upon
           existing PE(s) with the reception of new information.

   5.  When the PEER_LIST_RESPONSE last PEER_NAME_TABLE_RESPONSE message is received from
       the mentor peer, peer and unpacked into the initiating server MUST use local namespace, the server
   information carried in
       initialization process is completed and the message initiating server
       SHOULD start to initialize its own peer
   list.

   However, if provide ENRP services.

   Under certain circumstances, the mentor peer itself is in the process of startup and may not
   ready be able
   to provide a peer server list (for namespace download to the initiating server.  For
   example, the mentor peer
   is waiting for a response to its own PEER_LIST_REQUEST to another
   server), it is in the middle of initializing its own
   namespace database, or it has currently too many download sessions
   open to other servers.

   In such a case, the mentor peer MUST rejest the request by the
   initiating server and respond with a PEER_LIST_RESPONSE PEER_NAME_TABLE_RESPONSE message
   with the R flag set to '1', and with no server information pool entries included in the
   response.

   In the case where its PEER_LIST_REQUEST PEER_NAME_TABLE_REQUEST is rejected by the
   mentor peer, the initiating server SHOULD either wait for a few
   seconds and re-send the PEER_LIST_REQUEST PEER_NAME_TABLE_REQUEST to the mentor server,
   or if there is a backup mentor peer available, select another mentor
   peer server and send the PEER_LIST_REQUEST PEER_NAME_TABLE_REQUEST to the new mentor
   server.

4.2.3 Download ENRP Namespace Data from Mentor Peer

   After a peer list

   A started namespace download is completed, session may get interrupted for some
   reason.  To cope with this, the initiating server
   MUST request SHOULD start a copy of the current namespace data from its mentor
   peer server, by taking the following steps:

   1) The initiating server MUST first send
   timer everytime it finishes sending a PEER_NAME_TABLE_REQUEST
      message to the its
   mentor peer.

   2) Upon the reception of  If this message, timer expires without receiving a response from
   the mentor peer MUST start a peer, the initiating server SHOULD abort the current
   download session in which and re-start a copy of the current new namespace data
      maintained by download with a backup
   mentor peer, if one is available.

   Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the
   mentor peer is sent has still more data to send, it SHOULD start a session
   timer.  If this timer expires without receiving another request from
   the initiating server
      in one or more PEER_NAME_TABLE_RESPONSE messages.

      If more than one PEER_NAME_TABLE_RESPONSE server, the mentor peer SHOULD abort the session,
   cleaning out any resource and record of the session.

4.3 Handle PE Registration

   To register itself with the namespace, a PE sends a REGISTRATION
   message to its home ENRP server.  The format of REGISTRATION message
   and rules of sending it are used
      during defined in [1].

   In the download, REGISTRATION message, the mentor peer MUST use PE indicates the M flag name of the pool it
   wishes to join in a pool handle parameter, and its complete transport
   information and any load control information in each
      PEER_NAME_TABLE_RESPONSE a PE parameter.

   The ENRP server handles the REGISTRATION message according to indicate whether this
      message is the last one for
   following rules:

   1.  If the download session. In particular, named pool does not exist in the mentor peer namespace, the ENRP
       server MUST set creates a new pool with that name in the M flag namespace
       and add the PE to '1' in the outbound
      PEER_NAME_TABLE_RESPONSE if there pool as its first PE;

       When a new pool is more data to be transferred
      and MUST keep track of created, the progress overall member selection policy
       of the current download
      session. The mentor peer pool MUST be set the M flag to '0' in the last
      PEER_NAME_TABLE_RESPONSE for policy type indicated by the download session and close first
       PE.

   2.  If the
      download session (i.e., removing any internal record of named pool already exists in the
      session) after sending out namespace, but the last message.

   3) During
       requesting PE is not currently a member of the downloading, every time pool, the initiating ENRP
       server
      receives will add the PE as a PEER_NAME_TABLE_RESPONSE message, it MUST transfer new member to the data entries carried in pool;

       After adding the message into its local namespace
      database, and then check whether or not this message is PE to the last
      one for pool, the download session.

      If server MUST check if the M flag
       policy type indicated by the PE is set to '1' in the just processed
      PEER_NAME_TABLE_RESPONSE message, same as the initiating overall policy
       type of the pool.  If different, the ENRP server MUST
      send another PEER_NAME_TABLE_REQUEST message attempt to
       override the PE's policy and make it the same as the mentor peer overall
       policy.

       A.  If no additional policy-related information are required to request for the next PEER_NAME_TABLE_RESPONSE message.

   4) When unpacking
           perform the data entries from a PEER_NAME_TABLE_RESPONSE
      message into its local namespace database, override (e.g., overriding Least-used with Round-
           robin does not require additional policy-related
           information), the initiating ENRP server MUST handle each pool entry carried in replace the message using PE's policy
           type with the following rules:

      4a) overall policy type.

       B.  If additional policy information is required (e.g.,
           overriding Round-robin with Least-load will require the pool does not exist in
           knowledge of the local namespace, load factor of the
          initiating PE), the ENRP server MUST creates
           reject the regirstration with an error code "Pooling policy
           inconsistent".

   3.  If the named pool already exists in the local namespace and add the PE(s) in the pool entry to AND the pool.

	  When creating
       requesting PE is already a member of the pool, the initiation ENRP server MUST set
       SHOULD consider this as a re-registration case.  The ENRP Server
       SHOULD replace the
	  overall member selection policy type attributes of the pool to existing PE with the
	  policy type indicated
       information carried in the first received REGISTRATION message.

   4.  After accepting the registration, the ENRP server MUST assgin
       itself the owner of this PE.

      4b)  If this is a re-registration, the pool already exists in the local namespace, but
       ENRP server MUST take over ownership of this PE regardless of
       whether the
	  PE(s) in PE was previously owned by the pool entry is not currently server or by a member peer of
       it.

   5.  The ENRP server may reject the
	  pool, registration due to reasons such
       as invalid values, lack of resource, authentication failure, etc.

   In all above cases, the initiating ENRP server MUST reply to the requesting PE
   with a REGISTRATION_RESPONSE message.  If the registration is
   rejected, the ENRP server MUST add indicate the PE(s) to rejection by including
   the pool.

      4c) proper Operation Error parameter in the REGISTRATION_RESPONSE
   message.

   If the pool already exists registration is granted with a polcy override (see Step 2a
   above), in the local namespace AND REGISTRATION_RESPONSE message the
	  PE(s) ENRP server SHOULD
   also send back the registrant PE the new policy, in a Member
   Selection Policy Parameter, so as to inform the Pool entry is already PE that a member of policy
   override is performed.

   If the pool, registration is granted (i.e., one of cases 1-3 above), the
	  initiating server
   ENRP server SHOULD replace MUST assign itself to be the attributes home ENRP server of the existing PE(s) with PE,
   i.e., to "own" the new information.

    5) When PE.

      Implementation note: for better performance, the last PEER_NAME_TABLE_RESPONSE message ENRP server may
      find it both efficient and convenient to internally maintain two
      separate PE lists or tables - one is received from for the mentor peer PEs that are "owned"
      by the ENRP server and unpacked into the local namespace, other for all the
       initialization process PEs owned by its
      peer(s).

   Moreover, if the registration is completed and granted, the initiating server
       SHOULD start to provide ENRP services.

   Under certain circumstances, server MUST take
   the mentor peer itself may not be able
   to provide a namespace download update action as described in Section 4.6 to inform its
   peers about the initiating server. For
   example, change just made.  If the mentor peer registration is in the middle of initializing denied, no
   message will be sent to its own
   namespace database, or it has currently too many download sessions
   open peers.

4.3.1 Rules on PE Re-registration

   A PE may re-register itself to other servers.

   In such a case, the mentor peer MUST rejest namespace with a new set of
   attributtes in order to, for example, extend its registration life,
   change its load factor value, etc.

   A PE may modify its load factor value at any time via re-
   registration.  Based on the request by number of PEs in the
   initiating server pool and respond with a PEER_NAME_TABLE_RESPONSE
   message with the R flag set pool's
   overall policy type, this operation allows the PE to '1', and with no dynamically
   control its share of inbound messages received by the pool entries
   included (also see
   Section ???? in [1] for more on load control).

   Moreover, when re-registering, the response.

   In PE MUST NOT change its policy
   type.  The server MUST reject the case where re-registration if the PE attempt
   to change its PEER_NAME_TABLE_REQUEST is rejected by policy type.  In the
   mentor peer, rejection, the initiating server SHOULD either wait for a few
   seconds and re-send
   attach an error code "Pooling Policy Inconsistent".

   Regardless whether it is the PEER_NAME_TABLE_REQUEST to current owner of the mentor
   server, or PE, if there is a backup mentor peer available, select
   another mentor peer server and send the PEER_NAME_TABLE_REQUEST re-
   registration is granted to the new mentor server.

   A started namespace download session may get interrupted for some
   reason. To cope with this, PE, the initiating ENRP server SHOULD start a
   timer everytime it finishes sending a PEER_NAME_TABLE_REQUEST MUST assign itself
   to
   its mentor peer. If this timer expires without receiving a response
   from the mentor peer, be the initiating new home ENRP server SHOULD abort of the
   current download session and re-start a new namespace download with
   a backup mentor peer, if one is available.

   Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, PE.

   Moreover, if the
   mentor peer has still more data to send, it SHOULD start a session
   timer. If this timer expires without receiving another request from re-registration is granted, the initiating server, ENRP server MUST
   take the mentor peer SHOULD abort namespace update action as described in Section 4.6 to
   inform its peers about the session,
   cleaning out any resource and record of change just made.  If the session.

4.3 re-registration
   is denied, no message will be sent to its peers.

4.4 Handle PE Registration De-registration

   To register remove itself with the namespace, from a pool, a PE sends a REGISTRATION DEREGISTRATION message to
   its home ENRP server.  The complete format of REGISTRATION DEREGISTRATION message
   and rules of sending it are defined in [ASAP]. [1].

   In the REGISTRATION message, DEREGISTRATION message the PE indicates the name of the pool
   it wishes belongs to join in a pool handle parameter, parameter and provides its complete
   transport information and PE
   identifer.

   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, the ENRP server will remove the pool from the namespace as
   well.

   If the ENRP server fails to find any load control information in a record of the PE
   parameter. in its
   namespace, it SHOULD consider the de-registration granted and
   completed.

   The ENRP server handles may reject the REGISTRATION de-registration request for various
   reasons, such as invalid parameters, authentication failure, etc.

   In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE
   message according to the
   following rules:

   1) PE.  If the named de-registration is rejected, the ENRP
   server MUST indicate the rejection by including the proper Operation
   Error parameter.

   It should be noted that de-registration does not stop the PE from
   sending or receiving application messages.

   Once the de-registration request is granted AND the PE removed from
   its local copy of the namespace, the ENRP server MUST take the
   namespace update action described in Section 4.6 to inform its peers
   about the change just made.  Otherwise, NO message SHALL be send to
   its peers.

4.5 Pool Handle Translation

   A PU uses the pool does not exist in the namespace, the handle translation service of an ENRP server MUST creates to
   resolve a new pool with that name in the namespace and
   add the PE handle to the pool as its first PE;

   When a new pool is created, list of accessible transport addresses of
   the overall member selection policy PEs of the pool MUST be set to pool.

   This requires the policy type indicated by PU to send a NAME_RESOLUTION message to its home
   ENRP server and in the first PE.

   2) If NAME_RESOLUTION message specify the named pool already exists
   handle to be translated in the namespace, but the
   requesting PE is not currently a member Pool Handle parameter.  Complete
   defintion of the pool, NAME_RESOLUTION message and the rules of sending it
   are defined in [1].

   An ENRP server
   will add the PE as a new member SHOULD be prepared to receive NAME_RESOLUTION requests
   from PUs either over an SCTP associaiton on the pool;

   After adding well-know SCTP port,
   or over a TCP connection on the PE to well-know TCP port.

   Upon reception of the pool, NAME_RESOLUTION message, the ENRP server MUST check if the
   policy type indicated by the PE is the same as the overall policy
   type of
   first look up the pool. pool handle in its namespace.  If different, the pool exits,
   the home ENRP server MUST attempt to
   override the PE's policy compose and make it the same as the overall
   policy.

     2a) If no additional policy-related information are required send back a
   NAME_RESOLUTION_RESPONSE message to
     perform the override (e.g., overriding Least-used with Round-robin
     does not require additional policy-related information), requesting PU.

   In the response message, the ENRP server MUST replace list all the PE's PEs
   currently registered in this pool, in a list of PE parameters.  The
   ENRP server MUST also include a pool member selection policy type with
   parameter to indicate the overall member selection policy
     type.

     2b) If additional policy information is required (e.g.,
     overriding Round-robin with Least-load will require the knowledge
     of the load factor of for the PE),
   pool, if the ENRP server MUST reject current pool member selection policy is not round-robin
   (if the
     regirstration with an error code "Pooling overall policy inconsistent".

   3) is round-Robin, this parameter MAY be
   omitted?).

   If the named pool already exists does not exist in the namespace AND namespace, the
   requesting PE is already ENRP server
   MUST respond with a member NAME_UNKNOWN message.

   The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN
   messages and the pool, the rules of receiving them are defined in [1].

4.6 Server Namespace Update

   This includes a set of update operations used by an ENRP server
   SHOULD consider this as to
   inform its peers when its local namespace is modified, e.g., addition
   of a re-registration case. The ENRP Server
   SHOULD replace the attributes new PE, removal of the an existing PE, change of pool or PE with
   properties.

4.6.1 Announcing Addition or Update of PE

   When a new PE is granted registration to the
   information carried in namespace or an existing
   PE is granted a re-registration, the received REGISTRATION message.

   4) The home ENRP server may reject the registration due uses this
   procedure to reasons such
   as invalid values, lack of resource, authentication failure, etc.

   In inform all above cases, the its peers.

   This is an ENRP server MUST reply announcement and is sent to all the requesting PE
   with a REGISTRATION_RESPONSE message. In the message, peer of the home
   ENRP server.  See Section 4.1 on how annoucements are sent.

   An ENRP server MUST set the Action code to indicate that announce this is update to all its peers in a response
   PEER_NAME_UPDATE message with the Update Action field set to ADD_PE,
   indicating the addition of a new PE registration and MUST indicate in or the Result code whether modification of an
   existing PE.  The complete new information of the registration is granted or rejected.

   If PE and the registration is granted with a polcy override (see Step 2a
   above), in addition pool its
   belongs to the Result code, MUST be indicated in the
   REGISTRATION_RESPONSE message the with a PE parameter and a
   Pool Handle parameter, respectively.

   The home ENRP server SHOULD also send back fill in its server Id in the registrant PE Sender
   Server's ID field and leave the new policy, in Receiver Server's ID blank (i.e., all
   0's).

   When a Member Selection Policy
   Parameter, so as to inform peer receives this PEER_NAME_UPDATE message, it MUST take the PE that a policy override is
   performed.
   following actions:

   1.  If the registration is granted (i.e., one named pool indicated by the pool handle does not exist in
       its local copy of cases 1-3 above), the
   ENRP server namespace, the peer MUST take create the namespace update action as described named
       pool in
   Section 4.6? to inform its peers about the change just made. If local namespace and add the
   registration is denied, no message will be send to its peers.

4.3.1 Rules on PE Re-registration

   A PE may re-register itself to the namespace with a new set of
   attributtes in order to, for example, extend its registration
   life, change its load factor value, etc.

   A PE may modify its load factor value at any time via
   re-registration. Based on pool as the number
       first PE.  It MUST then copy in all other attributes of PEs the PE
       carried in the message.

       When the new pool and is created, the
   pool's overall member selection policy type, this operation allows
       of the PE pool MUST be set to
   dynamically control its share of inbound messages received the policy type indicated by the PE.

   2.  If the named pool (also see Section 4.5.2 already exists in [ASAP] for more on load control).

   Moreover, when re-registering, the PE MUST NOT change its policy
   type. The server MUST reject peer's local copy of the re-registration if
       namespace AND the PE attempt
   to change its policy type. In does not exist, the rejection, peer MUST add the server SHOULD
   attach an error code "Pooling policy inconsistent".

4.4 Handle PE De-registration

   To remove itself from a pool, to
       the pool as a new PE sends a DEREGISTRATION message
   to its home ENRP server. The complete format of DEREGISTRATION
   message and rules of sending it are defined copy in [ASAP].

   In the DEREGISTRATION message the PE indicates the name all attributes of the
   pool it belongs to in a pool handle parameter and provides its PE
   identifer.

   Upon receiving the message, carried
       in the ENRP server SHALL remove message.

   3.  If the PE
   from its namespace. Moreover, if named pool exists AND the PE is the last one already a member of the
   named
       pool, the ENRP server will remove the pool from the namespace
   as well.

   If peer MUST replace the ENRP server fails to find any record attributes of the PE with the new
       information carried in its
   namespace, it SHOULD consider the de-registration message.

4.6.2 Announcing Removal of PE

   When an existing PE is granted and
   completed.

   The ENRP server may reject the de-registration request or is removed from its
   namespace for various
   reasons, such as invalid parameters, authentication failure, etc.

   In response, some other reasons (e.g., purging an unreachable PE,
   see Section 4.7), the ENRP server MUST send a REGISTRATION_RESPONSE
   message uses this procedure to inform
   all its peers about the PE. In change just made.

   This is an ENRP announcement and is sent to all the message, peer of the home
   ENRP server.  See Section 4.1 on how annoucements are sent.

   An ENRP server MUST set announce the
   Action code PE removal to indicate that this is all its peers in a response
   PEER_NAME_UPDATE message with the Update Action field set to a DEL_PE,
   indicating the removal of an existing PE.  The complete information
   of the PE
   de-registration, and indicate the pool its belongs to MUST be indicated in the Result code whether
   message with a PE parameter and a Pool Handle parameter,
   respectively.

   [editor's note: only the
   request is granted or rejected.

   It pool handle and the PE's id are needed, it
   should be noted that de-registration does not stop reduce the PE from size of the message]

   The sending or receiving application messages.

   Once server MUST fill in its server ID in the de-registration request is granted AND Sender Server's
   ID field and leave the Receiver Server's ID blank (i.e., set to all
   0's).

   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 removed
   from its local copy of namespace.  If the namespace, removed PE is the ENRP server last one in the
   pool, the peer MUST take also delete the
   namespace update action described in Section 4.6? to inform pool from its
   peers about local namespace.

   If the change just made. Otherwise, NO message SHALL be
   send peer fails to its peers.

4.5 Pool Handle Translation

   A find the PE or PU uses the pool handle translation service of an ENRP
   server to resolve in its namespace, it
   SHOULD take no further actions.

4.7 Detecting and Removing Unreachable PE

   Whenever a pool handle to PU finds a list of accessible transport
   addresses of the member PEs PE unreachable (e.g., via an SCTP SEND.FAILURE
   Notification, see section 10.2 of [7]), the pool.

   This requires the PE or PU to SHOULD send a NAME_RESOLUTION an
   ENDPOINT_UNREACHABLE message to its home ENRP server and in the NAME_RESOLUTION server.  The message specify
   SHOULD contain the pool handle to be translated in a Pool Handle parameter. Complete
   defintion of the NAME_RESOLUTION message and the rules PE Id of sending
   it are defined in [ASAP]. the unreachable PE.

   Upon the reception of the NAME_RESOLUTION an ENDPOINT_UNREACHABLE message, a server MUST
   immediately send a point-to-point ENDPOINT_KEEP_ALIVE message to the
   PE in question.  If this ENDPOINT_KEEP_ALIVE fails (e.g., it results
   in an SCTP SEND.FAILURE notification), the ENRP server MUST
   first look up consider
   the pool handle in PE as truly unreachable and MUST remove the PE from its namespace. namespace
   and take actions described in Section 4.6.2.

   If the pool exits, ENDPOINT_UNREACHABLE message is transmitted successfully to
   the PE, the home ENRP server MUST compose and send back retain the PE in its namespace.
   Moreover, the server SHOULD keep a
   NAME_RESOLUTION_RESPONSE message counter to the requesting PU or record how many
   ENDPOINT_UNREACHABLE messages it has received reporting reachability
   problem relating to this PE.

   In  If the response message, counter exceeds the protocol
   threshold MAX-BAD-PE-REPORT, the ENRP server MUST list all SHOULD remove the PEs
   currently registered PE
   from its namespace and take actions described in this pool, Section 4.6.2.

   Optionally, an ENRP server may also periodically send point-to-point
   ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the ENRP
   server in a list order to check their reachability status.  If the send of
   ENDPOINT_KEEP_ALIVE to a PE parameters. The fails, the ENRP server MUST also include a pool member selection policy
   parameter to indicate consider the overall member selection policy for
   PE as unreachable and MUST remove the
   pool, PE from its namespace and take
   actions described in Section 4.6.2.  Note, if an ENRP server owns a
   large number of PEs, the current pool member selection policy is implementation should pay attention not
   round-robin (if the overall policy is round-Robin, this parameter
   MAY be omitted?).

   If to
   flood the named pool does not exist in network with bursts of ENDPOINT_KEEP_ALIVE messages.
   Instead, the namespace, implementation should try to smooth out the ENRP server
   MUST respond with a NAME_UNKNOWN message.
   ENDPOINT_KEEP_ALIVE message traffic over time.

   The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN
   messages definition and the rules of sending ENDPOINT_UNREACHABLE and
   receiving them ENDPOINT_KEEP_ALIVE messages are defined described in [ASAP].

4.6 Server Namespace Update

   This includes a set of update operations used by an ENRP server [1].

4.8 Helping PE and PU to
   inform Discover Home ENRP Server

   At its peers when startup time, or whenever its local namespace current home ENRP server is modified, e.g.,
   addition of not
   providing services, a new PE, removal of an existing PE, change of pool
   or PE properties.

4.6.1 Announcing Addition or Update of PE

   When a new PE is granted registration PU will attempt to the namespace or an
   existing PE is granted find a re-registration, the home ENRP server
   uses this procedure to inform all its peers.

   This is an ENRP announcement and is sent to all the peer of the new home ENRP
   server. See Section 4.1 on how annoucements are sent.

   An ENRP server MUST announce this update to all its peers in  The PE or PU will either multicast or send a
   PEER_NAME_UPDATE point-to-point
   SERVER_HUNT message with the Update action field set to
   ADD_PE, indicating the addition of a new PE one or more ENRP servers in the operation
   scope.  For the modification of
   an existing PE. The complete new information procedure of the PE and the pool
   its belongs to MUST be indicated this, see Section ???? in the message with a PE parameter
   and [1].

   To support this procedure, whenever a Pool Handle parameter, respectively.

   The home SERVER_HUNT message is received
   an ENRP server SHOULD fill in its server Id in the Sender
   Server's ID field and leave immediately respond to the Receiver Server's ID blank (i.e.,
   all 0's).

   When sending PE or PU
   with a peer receives this PEER_NAME_UPDATE message, it SERVER_HUNT_RESPONSE message.

4.9 Maintaining Peer List and Monitoring Peer Status

   An ENRP server MUST take
   the following actions:

     1) If the named pool indicated by keep an internal record on the pool handle does not exist
     in its local copy status of each of the namespace, the peer MUST create the named
     pool in
   its local namespace and add the PE known peers.  This record is referred to the pool as the first
     PE. It MUST then copy in all other attributes server's "peer
   list"

4.9.1 Discovering New Peer

   If a message of the PE carried
     in the message.

     When the new pool any type is created, the overall member selection policy
     of received from a previously unknown peer,
   the pool ENRP server MUST be set to the policy type indicated by the PE.

     2) If the named pool already exists consider this peer a new peer in the peer's local copy of
     the namespace AND the PE does not exist, operation
   scope and add it to the peer list.

   The ENRP server MUST add send a PEER_PRESENCE message with the PE Reply-
   required flag set to '1' to the pool as a new PE and copy in all attributes of the PE
     carried source address found in the arrived
   message.

     3) If  This will force the named pool exists AND new peer to reply with its own
   PEER_PRESENCE containing its full server information (see Section
   3.1).

   [editor's note: should we ask for a peer list from the PE is already new peer?
   this may help mending two splitted networks.]

4.9.2 Server Sending Heartbeat

   Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its
   continued presence to all its peer with a member of PEER_PRESENCE message.  In
   the
     pool, PEER_PRESENCE message, the peer ENRP server MUST replace set the attributes
   'Replay_required' flag to '0', indicating that no response is
   required.

   The arrival of this periodic PEER_PRESENCE message will cause all its
   peers to update their internal variable "Peer-last-heared" for the PE with
   sending server (see Section 4.9.3 for more details).

4.9.3 Detecting Peer Server Failure

   An ENRP server MUST keep an interanl variable "Peer-last-heared" for
   each of its known peers and the new
     information carried in value of this variable MUST be
   updated to the message.

4.6.2 Announcing Removal current local time everytime a message of PE

   When an existing PE is granted de-registration any type
   (point-to-point or announcement) is removed received from
   its namespace the cooresponding
   peer.

   If a peer has not been heard for some other reasons (e.g., purging an unreachable
   PE), more than MAX-TIME-LAST-HEARD
   seconds, the ENRP server MUST uses this procedure immediately send a point-to-point
   PEER_PRESENCE with 'Reply_request' flag set to inform all its
   peers about the change just made.

   This is an ENRP announcement and is sent '1' to all that peer.

   If the send fails or the peer of does not reply after MAX-TIME-NO-
   RESPONSE seconds, the
   home ENRP server. See Section 4.1 on how annoucements are sent.

   An ENRP server MUST announce consider the PE removal to all its peers peer server dead
   and SHOULD initiate the takeover procedure defined in Section 4.10.

4.10 Taking-over a
   PEER_NAME_UPDATE message with Failed Peer Server

   In the Update action field set to
   DEL_PE, indicating following descriptions, We call the removal of an existing PE. The complete
   information of ENRP server that detects
   the PE failed peer server and initiates the pool its belongs to MUST be indicated
   in take-over the message with a PE parameter "initiating
   server" and a Pool Handle parameter,
   respectively.

   [editor's note: only the pool handle and failed peer server the PE's id "target server."

4.10.1 Initiate Server Take-over Arbitration

   The initiating server SHOULD fisrt start a take-over arbitration
   process by announcing a PEER_INIT_TAKEOVER message to all its peer
   servers.  See Section 4.1 on how annoucements are needed, it
   should reduce sent.  In the size of
   message, the message]

   The sending initiating server MUST fill in its server ID in the Sender Server's ID field
   and leave the Receiver Target Server's ID blank (i.e.,
   set to all 0's).

   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
   from its local namespace. If the removed PE is the last one in the
   pool, the peer MUST also delete the pool from its local namespace.

   If the peer fails to find the PE or ID.

   After announcing the pool in its namespace, it
   SHOULD take no further actions.

4.7 Detecting and Removing Unreachable PE

   Whenever a PU finds a PE unreachable (e.g., via an SCTP
   SEND.FAILURE Notification, see section 10.2 of [RFC2960]), PEER_INIT_TAKEOVER message, the PU initiating
   server SHOULD send an ENDPOINT_UNREACHABLE wait for a PEER_INIT_TAKEOVER_ACK message to from _each_
   of its home ENRP known peers, except of the target server. The  [editor's note: how
   long should it wait?]

   Each of the peer servers that receives the PEER_INIT_TAKEOVER message
   from the initiating server SHOULD contain take the pool handle and following actions:

   1.  If the PE Id
   of peer server finds that itself is the unreachable PE.

   Upon target server
       indicated in the reception of an ENDPOINT_UNREACHABLE PEER_INIT_TAKEOVER message, a server it MUST immediately send
       announce a point-to-point ENDPOINT_KEEP_ALIVE PEER_PRESENCE message to the PE all its peer ENRP servers in question. If
       an attempt to stop this ENDPOINT_KEEP_ALIVE fails (i.e., take-over process.  This indicates a
       false failure detection case by the initiating server.

   2.  If the peer server finds that itself has already started its own
       take-over arbitration process on the same target server, it
   results MUST
       perform the following arbitration:

       A.  if the peer's server ID is smaller in an SCTP SEND.FAILURE notification), value than the ENRP Sender
           Server's ID in the arrived PEER_INIT_TAKEOVER message, the
           peer server MUST
   consider SHOULD immediately abort its own take-over
           attempt.  Moreover, the PE peer SHOULD mark the target server as truly unreachable
           "not active" on its internal peer list so that its status
           will no longer be monitored by the peer, and reply the
           initiating server with a PEER_INIT_TAKEOVER_ACK message.

       B.  Otherwise, the peer MUST remove ignore the PE from
   its namespace PEER_INIT_TAKEOVER
           message and take actions described in 4.6.2?. no action.

   3.  If the ENDPOINT_UNREACHABLE message peer finds that it is transmitted successfully to
   the PE, neither the ENRP target server MUST retain the PE nor is in
       its namespace.
   Moreover, own take-over process, the peer SHOULD: a) mark the target
       server SHOULD keep a counter as "not active" on its internal peer list so that its
       status will no longer be monitored by this peer, and b) reply to record how
   many ENDPOINT_UNREACHABLE messages
       the initiating server with a PEER_INIT_TAKEOVER_ACK message.

   Once the initiating server has received PEER_INIT_TAKEOVER_ACK
   message from _all_ of its currently known peers (except for the
   target server), it SHOULD consider that it has received reporting
   reachability problem relating won the arbitration
   and SHOULD proceed to this PE. If complete the counter exceeds take-over, following the protocol threshold <MAX-BAD-PE-REPORT>, steps
   described in Section 4.10.2.

   However, if it receives a PEER_PRESENCE from the ENRP target server at any
   point in the arbitration process, the initiating server SHOULD
   remove
   immediately abort the PE from its namespace and take actions described in
   Section 4.6.2?.

   The complete definition take-over process and rules mark the status of sending ENDPOINT_UNREACHABLE
   and ENDPOINT_KEEP_ALIVE messages are described in [ASAP].

4.8 Helping PE and PU to Discover Home ENRP the
   target server as "active".

4.10.2 Take-over Target Peer Server

   At its startup time, or whenever its current home

   The initiating ENRP server is
   not providing services, a PE or PU will attempt to find a new home
   server. The PE or PU will either multicast or send SHOULD first send, via an announcement, a point-to-point
   SERVER_HUNT
   PEER_TAKEOVER_SERVER message to one or more ENRP servers in the operation
   scope. For inform all its active peers that the complete procedure of this, see Section xxxx in
   [ASAP].

   To support this procedure, whenever a SERVER_HUNT message
   take-over is
   received an ENRP enforced.  The target server's ID MUST be filled in the
   message.  The initiating server SHOULD immediately respond to then remove the sending
   PE or PU with a SERVER_HUNT_RESPONSE target server
   from its internal peer list.

   [editor's note: peers should remove the target server from their list
   upon receiving this message.

4.9 Maintaining Peer List  Do we really need this message? we can
   consolidate this with the ownership_change msg.]

   Then it SHOULD examine its local copy of the namespace and Monitoring Peer Status

   An claim
   ownership of each of the PEs originally owned by the target server,
   by following these steps:

   1.  mark itself as the home ENRP server MUST keep internally a record on of each of the PEs originally
       owned by the status of target server;

   2.  send a point-to-point ENDPOINT_KEEP_ALIVE message to each of its known peers. the
       PEs.  This record is referred will trigger the PE to adopt the initiating sever as
       its new home ENRP server;

   3.  after claiming the server's
   "peer list"

4.9.1 Discovering New Peer

   If ownership of all the PEs originally owned by
       the target server, announce the ownership changes of all the
       affected PEs in a PEER_OWNERSHIP_CHANGE message to all the
       currently known peers.  Note, if the list of any type affected PEs is received from a previously unknown
   peer,
       long, the ENRP server MUST consider this peer sender MAY announce the ownership changes in multiple
       PEER_OWNERSHIP_CHANGE messages.

   When a new peer receives the PEER_OWNERSHIP_CHANGE message from the
   initiating server, it SHOULD find each of the reported PEs in its
   local copy of the
   operation scope namespace and add it update the PE's home ENRP server to
   be the peer list.

   If sender of the message is
   received over (i.e., the well-known server multicast channel, initiating server).

4.11 Namespace Data Auditing and Re-synchronization

   Message losses or certain temporary breaks in network connectivity
   may result in data inconsistency in the local namespace copy of some
   of the ENRP servers in an operation scope.  Therefore, each ENRP
   server MUST mark this new peer as multicast-enabled. Otherwise, in the
   new peer MUST be marked as multicast-disabled (see Section 4.1 for
   more details).

   [editor's note: should we ask operation scope SHOULD periodically verify that its
   local copy of namespace data is still in sync with that of its peers.

   This section defines the auditing and re-synchronization procedures
   for an ENRP server to maintain its namespace data consistency.

4.11.1 Auditing Prodecures

   [TBD]

4.11.2 Re-synchronization Prodecures

   Once an ENRP server determines that there is inconsistancy between
   its local namespace data and a peer list from peer's namespace data with regarding
   to the new peer?
   this may help mending two splitted networks.]

   [editor's note: we also want PEs owned by that peer, it SHOULD perform the following steps
   to re-synchronize the data:

   1.  The ENRP server SHOULD first "mark" every PE it knows about that
       is owned by the peer in its local namespace database;

   2.  The ENRP server SHOULD then send a reply-required probe PEER_NAME_TABLE_REQUEST
       message with W flag set to '1' to
   force the new peer to send us its Server Info Param.. so we can now
   it details].

4.9.2 Server Sending Heartbeat

   Every <PEER-HEARTBEAT-CYCLE> seconds, an ENRP server MUST announce
   its continued presence request a complete
       list of PEs owned by the peer;

   3.  Upon reception of the PEER_NAME_TABLE_REQUEST message with W flag
       set to all its '1', the peer server SHOULD immediately respond with a PEER_PRESENCE
   message. In
       PEER_NAME_TABLE_RESPONSE message listing all PEs currently owned
       by the PEER_PRESENCE peer.

   4.  Upon reception of the PEER_NAME_TABLE_RESPONSE message, the ENRP
       server MUST set SHOULD transfer the PE entries carried in the
   'Replay_required' flag to '0', indicating that no response is
   required.

   The arrival of this periodic PEER_PRESENCE message will cause all into
       its peers to update their internal variable <Peer-last-heared> for local namespace database.  If an PE entry being transferred
       already exists in its local database, the sending server (see Section 4.9.3? for more details).

4.9.3 Detecting Peer Server Failure

   An ENRP server MUST keep an interanl variable <Peer-last-heared>
   for each of its known peers
       replace the entry with the copy found in the message and remove
       the value of this variable MUST be
   updated to "mark" from the current local time everytime a entry.

   5.  After transferring all the PE entries from the received
       PEER_NAME_TABLE_RESPONSE message of any type
   (point-to-point or announcement) into its local database, the
       ENRP server SHOULD check whether there are still PE entries that
       remain "marked" in its local namespace.  If so, the ENRP server
       SHOULD silently remove those "marked" entries.

   Note, similar to what is received from described in Section 4.2.3, the cooresponding
   peer.

   If a peer has not been heard for may
   reject the PEER_NAME_TABLE_REQUEST or use more than <MAX-TIME-LAST-HEARD>
   seconds, the one
   PEER_NAME_TABLE_RESPONSE message to respond.

4.12 Handling Unrecognized Message or Unrecognized Parameter

   When an ENRP server MUST immediately send a point-to-point
   PEER_PRESENCE receives an ENRP message with 'Reply_request' flag set to '1' to an unknown message
   type or a message of known type that peer.

   If contains an unknow parameter, it
   SHOULD handle the send fails unknow message or the peer does not reply after
   <MAX-TIME-NO-RESPONSE> seconds, unknown parameter according
   to the ENRP server MUST consider unrecognized message and parameter handling rules defined in
   Sections 3 and 4 in [10].

   According to the
   peer rules, if an error report to the message sender is
   needed, the ENRP server dead and remove that discovered the peer from its peer list.

4.10 Namespace Data Auditing and Re-synchronization

   [TBD]

4.11 Reporting Unrecognized Message or Unrecognized Parameter

   [TBD] error SHOULD send back an
   ENRP_ERROR message with proper error cause code.

5. Variables and Time Constants

5.1 Variables

    <Peer-last-heared>

   Peer-last-heared - the local time that a peer server was last heard
      (via receiving either a multicast or point-to-point message from
      the peer).

5.2 Timer Constants

    <MAX-TIME-SERVER-HUNT>

   MAX-TIME-SERVER-HUNT - the maximal number of attempts a sender will
      make to contact an ENRP server (Default=3 times).

    <TIMEOUT-SERVER-HUNT>

   TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will
      wait for a response from an ENRP server (Default=5 secends).

    <PEER-HEARTBEAT-CYCLE>

   PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a
      heartheat message to all its known peers.  (Default=30 secs.)

    <MAX-TIME-LAST-HEARD>

   MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server
      will wait before considering a silent peer server potentially
      dead.  (Default=61 secs.)

    <MAX-TIME-NO-RESPONSE>

   MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message
      sender will wait for a response after sending out a message.
      (Default=5 secs.)

    <MAX-BAD-PE-REPORT>

   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
      namespace.  (Default=3)

6. Security Considerations

   Due to varying requirements and multiple use cases of Rserpool, we
   point out two basic security protocols, IPsec and TLS.  We
   specifically do not discuss whether one security protocol would be
   preferred over the other.  This choice will be made by designers and
   network architects based on system requirements.

   For networks that demand IPsec security, implementations MUST support [SCTP-IPSEC]
   [9] which describes IPsec-SCTP.  IPsec is two layers below RSerPool.
   Therefore, if IPsec is used for securing Rserpool, no changes or
   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
   instead TLS, implementations MUST support TLS with SCTP as described
   in [SCTP-TLS] [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.  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.
   Security support for the Rserpool end user is optional.  Note that
   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
   user doesn't require security protection for example, against
   eavesdropping for the request for pool handle resolution and
   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
   the requirement for security support for the ENRP server.  It is also
   possible for the ENRP server to reject an unsecured request from the
   user due to its security policy in the case that it requires
   enforcement of strong security.  But this will be determined by the
   security requirements of the individual network design.

7. Acknowledgements

   The authors wish to thank John Loughney, Lyndon Ong, and many others
   for their invaluable comments.

Normative References

   [RFC2026]

   [1]   Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
         Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-04
         (work in progress), July 2002.

   [2]   Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
         J. and M. Stillman, "Requirements for Reliable Server Pooling",
         RFC 3237, January 2002.

   [3]   Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
         J. and M. Stillman, "Architecture for Reliable Server Pooling",
         draft-ietf-rserpool-arch-03 (work in progress), July 2002.

   [4]   Bradner, S., "The Internet Standards Process -- Revision 3",
         BCP 9, RFC 2026, October 1996.

   [RFC2119]

   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [RFC2246] T.

   [6]   Dierks, T. and C. Allen Allen, "The TLS Protocol - Version 1.0",
   RFC 2246, January 1999.

   [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
   H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and,
   V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October
   2000.

   [RFC3237] M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong,
   J. Loughney, M. Stillman: "Requirements for Reliable Server
   Pooling", Protocol Version 1.0", RFC 3237,
         2246, January 2002.

   [ASAP] R. R. 1999.

   [7]   Stewart, Q. Xie: "Aggregate Server Access Protocol
   (ASAP)", <draft-ietf-rserpool-asap-00.txt>, work in progress.

   [RSPL-ARCH] M. Tuexen, Q. R., Xie, R. R. Stewart, E. Lear, M. Shore, Q., Morneault, K., Sharp, C., Schwarzbauer,
         H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server
   Pooling," <draft-ietf-rserpool-arch-00.txt>, work in progress.

   [SCTP-TLS] A. and V. Paxson,
         "Stream Control Transmission Protocol", RFC 2960, October 2000.

   [8]   Jungmaier, E. A., Rescorla, E. and M. Tuexen Tuexen, "TLS over SCTP",
   draft-ietf-tsvwg-tls-over-sctp-00.txt, work
         draft-ietf-tsvwg-tls-over-sctp-00 (work in progress.

   [SCTP-IPSEC] S.M. progress), November
         2001.

   [9]   Bellovin, J. S., Ioannidis, A.D. J., Keromytis,
   R.R. A. and R. Stewart, "On
         the Use of SCTP with IPsec",
   <draft-ietf-ipsec-sctp-03.txt>, work draft-ietf-ipsec-sctp-03 (work in progress.

   [RSPL-PARAM] R.
         progress), February 2002.

   [10]  Stewart, R. and Q. Xie: Xie, "Aggregate Server Access Protocol
         (ASAP) and Endpoint Name Resolution Protocol (ENRP) Common
   Parameters Document", <draft-ietf-rserpool-enrp-asap-param-00.txt>,
   work common parameters
         document", draft-ietf-rserpool-common-param-00 (work in progress.

7.1
         progress), July 2002.

Informative References

   [RFC1750]

   [11]  Eastlake, D. (ed.), D., Crocker, S. and J. Schiller, "Randomness
         Recommendations for Security", RFC 1750, December 1994.

8. Acknowledgements

   The authors wish to thank John Loughney, Lyndon Ong, and many
   others for their invaluable comments.

9.

Authors' Addresses

   Qiaobing Xie                       Phone: +1-847-632-3028
   Motorola, Inc.		      EMail: qxie1@email.mot.com
   1501 W. Shure Drive, 2-F9
   Arlington Heights, IL  60004
   USA
   US

   Phone: +1-847-632-3028
   EMail: qxie1@email.mot.com

   Randall R. Stewart                 Phone: +1-815-477-2127
   Cisco
   24 Burning Bush Trail.	      EMail: rrs@cisco.com Trail
   Crystal Lake, IL  60012
   USA
   US

   Phone: +1-815-477-2127
   EMail: rrs@cisco.com

   Maureen Stillman                   Phone:   +1 607 273 0724 62
   Nokia                              EMail: maureen.stillman@nokia.com
   127 W. State Street
   Ithaca, NY  14850
   USA

                    Expires
   US

   Phone: +1 607 273 0724 62
   EMail: maureen.stillman@nokia.com

Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in six months from May 2002 its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.