Network Working Group                                              Q. Xie
INTERNET-DRAFT                                                   Motorola
                                                            R. R. Stewart
                                                            Cisco Systems
                                                              M. Stillman
                                                                    Nokia

Expires in six months                                       March 1,                                         May 2, 2002

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

Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026. 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.

   The list of current Internet-Drafts can be accessed at
   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.

Abstract

   Endpoint Name Resolution Protocol (ENRP) is designed to work in
   conjunction with the Aggregate Server Access Protocol (ASAP) [ASAP]
   to accomplish the functionality of the Reliable Server Pooling
   (Rserpool) requirements and architecture as defined in [RSERPOOL1]
    and [RSERPOOL2]. architecture.

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

Table Of Contents

   1. Introduction...............................................2
   1.2 Definitions............................................2 Definitions...............................................2
   2. Conventions................................................3
   3. Message Definitions........................................4
       3.1 ENRP Parameter Formats.................................4
	   3.1.1 IPv4 Address Parameter...........................5
	   3.1.2 IPv6 Address Parameter ..........................5
	   3.1.3 Pool Element Parameter...........................6
	   3.1.4 Pool Handle Parameter............................6
	   3.1.5 Authorization Parameter..........................7
	   3.1.6 Name Server Identifier Parameter.................7
       3.2 ENRP Message Formats..................................7
	    3.2.1 Definitions...................................3
   3.1 PEER_PRESENCE message...........................8
	    3.2.2 message.....................................4
   3.2 PEER_NAME_TABLE_REQUEST message.................9
	    3.2.3 message...........................5
   3.3 PEER_NAME_TABLE_RESPONSE message................9
	    3.2.4 message..........................5
   3.4 PEER_NAME_UPDATE message........................10
	    3.2.5 message..................................7
   3.5 PEER_LIST_REQUEST message.......................11
	    3.2.6 message.................................7
   3.6 PEER_LIST_RESPONSE message......................11 message................................8
   4. ENRP Operation Procedures..................................12 Procedures..................................9
   4.1 Basic Methods for Communicating amongst ENRP Servers............9
   4.2 ENRP Operations..................................12
	   4.1.1 PE Registration..................................12
	   4.1.2 PE De-registration...............................13
           4.1.3 PE Re-registration...............................13
	   4.1.4 Name Translation.................................14
	   4.1.5 Server Namespace Update..........................15
		 4.1.5.1 Add/Update a PE..........................15
		 4.1.5.2 Remove a PE..............................15
	   4.1.6 Server Download Namespace from Initialization................................10
   4.2.1 Generate a Peer Server.....16
	   4.1.7 Server Monitor Identifier ...........................11
   4.2.2 Acquire Peer Status.......................17
	   4.1.8 Server List................................11
   4.2.2.1 Find the mentor server................................11
   4.2.2.2 Request complete server list from mentor peer.........12
   4.2.3 Download Peer List ENRP Namespace Data from a Peer Server.....17
	   4.1.9 mentor Peer...........13
   4.3 Handle PE Registration....................................14
   4.3.1 Rules on PE Re-registration.............................16
   4.4 Handle PE De-registration.................................16
   4.5 Pool Handle Translation...................................17
   4.6 Server Initialization............................17
       4.2 Fault Management Operations............................18
	   4.2.1 Detect Namespace Update...................................17
   4.6.1 Announcing Addition or Update of PE.....................17
   4.6.2 Announcing Removal of PE................................18
   4.7 Detecting and Remove an Removing Unreachable PE..............18
	   4.2.2 Server Failure Detection by Heartbeat............19
	   4.2.3 PE.....................19
   4.8 Helping PE or and PU to Discover Home ENRP Server...............19 Server............19
   4.9 Maintaining Peer List and Monitoring Peer Status..........20
   4.9.1 Discovering New Peer....................................20
   4.9.2 Server Sending Heartbeat................................20
   4.9.3 Detecting Peer Server Failure...........................20
   4.10 Namespace Data Auditing and Re-synchronization...........21
   4.10 Reporting Unrecognized Message
        or Unrecognized Parameter................................21
   5. Protocol Variables and Timer Constants..............................20 Time Constants......................21
   5.1 Variables..............................................20 Variables.................................................21
   5.2 Timer Constants........................................20 Constants...........................................21
   6. Security COnsiderations....................................20 Considerations....................................22
   7. References.................................................20 References.................................................22
   7.1 Informative References....................................23
   8. Acknowledgements...........................................21 Acknowledgements...........................................23
   9. Authors' Addresses.........................................21 Addresses.........................................23

1. Introduction

    Endpoint Name Resolution Protocol (ENRP)

   ENRP is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) ASAP [ASAP] to
   accomplish the functionality of the Reliable Server Pooling
    (Rserpool) requirements and architecture Rserpool as defined in [RSERPOOL1] by its
   requirements [RFC3237] and [RSERPOOL2]. architecture [RSPL-ARCH].

   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 Definitions

   This document uses the following terms:

   Operation scope:
          The part of the network visible to pool users by a specific
          instance of the reliable server pooling protocols.
        See [RSPL-ARCH].

   Pool (or server pool):
          A collection of servers providing the same application
          functionality.
        See [RSPL-ARCH].

   Pool handle (or pool name):
          A logical pointer to a pool. Each server pool will be
          identifiable in the operation scope of the system by a unique
          pool handle or "name".

     ENRP namespace (or namespace):
          A cohesive structure of pool names and relations that may be
          queried by an internal or external agent.
        See [RSPL-ARCH].

   Pool element (PE):
          A server entity that runs ASAP and has registered to a pool.
        See [RSPL-ARCH].

   Pool user (PU):
          A server pool user that runs ASAP. Note, a PU can also be a
	  PE if it has registered itself to a pool.
        See [RSPL-ARCH].

   Pool element handle:
        See [RSPL-ARCH].

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

   ENRP namespace server (or ENRP server):
          Entity which runs ENRP and is responsible for managing and
	  maintaining the namespace within the operation scope.
        See [RSPL-ARCH].

   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.

   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.

     Network Byte Order:
	  Most significant byte first, a.k.a Big Endian.

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].

3. ENRP Message Definitions

   All

   In this section, we defines the format of all ENRP messages. These
   are messages as well as their fields described below shall be sent and received amongst ENRP servers in
   Network Byte Order during transmission. For fields with a length
   bigger than 4 octets, an operation
   scope. Messages sent and received between a number PE/PU and an ENRP
   server are part of ASAP and are defined in [ASAP]. A common format,
   defined in [RSPL-PARAM], is used for all ENRP and ASAP messages.

   Most ENRP messages contains a pair combination of parentheses may follow
   the filed name to indicate fixed fields and TLV
   parameters. The TLV parameters are also defined in [PARAMS].

   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 length of most significant byte first).

   For ENRP, the field 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  - ASAP messages, defined in number of
   octets. [ASAP].
      0x12-0xFF - (reserved by IETF)

3.1 PEER_PRESENCE message

   This ENRP Parameter Formats message is used to announce (periodically) the presence
   of an ENRP parameters are defined in server, or to probe the status of a Type-length-value (TLV) format as
   shown below. 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Parameter   Type       |       Parameter = 0x1  |0|0|0|0|0|0|0|R|     Message Length = 0xC      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                       Parameter Value                         :
      :                                                               :
   |                      Sender Server's ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameter Type:  16 bits (unsigned integer)

      The Type field is a 16
   |                     Receiver Server's ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   R (reply_required) flag: 1 bit identifier of

      Set to '1' if the type of parameter.
      It takes sender requires a value of 0 response to 65534.

      The value of 65535 is reserved for IETF-defined extensions. Values
      other than those defined in specific SCTP chunk description are
      reserved for use by IETF.

   Parameter Length:  16 bits (unsigned this message,
      otherwise set to '0'.

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

      The Parameter Length field contains

      This is the size ID of the parameter in
      bytes, including ENRP server which sends the Parameter Type, Parameter Length, and
      Parameter Value fields.  Thus, a parameter with a zero-length
      Parameter Value field would have a Length field message.

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

      This is the ID of 4.  The
      Parameter Length does not include any padding bytes.

   Parameter Value: variable-length.

      The Parameter Value field contains the actual information ENRP server to be
      transferred in which the parameter.

   The total length of a parameter (including Type, Parameter Length and
   Value fields) MUST be a multiple of 4 bytes. message is
      intended. If the length of the
   parameter message is not a multiple of 4 bytes, the sender pads the Parameter
   at the end (i.e., after the Parameter Value field) with all zero
   bytes.  The length of intended to an individual
      server (e.g., the padding message is not included in the parameter
   length field.  A sender SHOULD NOT pad with more than 3 bytes.  The
   receiver multicasted to a group of servers),
      this field MUST ignore the padding bytes.

   The Parameter Types are encoded such that the highest-order two bits
   specify the action that must be taken if the processing endpoint does
   not recognize the Parameter Type.

   00 - Stop processing this set with all 0's.

   Note, at startup an ENRP message server MUST pick a randomly generated,
   non-zero 32-bit unsigned integer as its ID and discard it, do not process
        any further parameters within it.

   01 - Stop processing MUST use this ENRP same
   ID for its entire life.

3.2 PEER_NAME_TABLE_REQUEST message and discard it, do not process
        any further parameters within it, and report the unrecognized
        parameter in an 'Unrecognized Parameter Type' error.

   10 - Skip this parameter and continue processing.

   11 - Skip this parameter and continue processing but report the
        unrecognized parameter in an 'Unrecognized Parameter Type'
	error.

   In the following sections, we define the common parameter formats
   used in ENRP.

3.1.1 IPv4 Address Parameter

    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             | 0x2  |0|0|0|0|0|0|0|0|    Message Length = 8 0xC       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IPv4 Address                      Sender Server's ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Address: 32 bits (unsigned integer)

      Contains an IPv4 address of the sending endpoint.  It is binary
      encoded.

3.1.2 IPv6 Address Parameter
   |                     Receiver Server's ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Sender Server's ID:

      See section 3.1.

   Receiver Server's ID:

      See 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 = 0x2         | 0x3  |0|0|0|0|0|0|R|M|        Message Length = 20         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sender Server's ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         IPv6 Address                          |
      |                                                               |
      |                     Receiver Server's ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Address: 128 bit (unsigned integer)
      Contains an IPv6 address of the sending endpoint.  It is binary
      encoded.

3.1.3
   :                                                               :
   :                     Pool Element Parameter

    This parameter is used in multiple ENRP message to represent an ASAP
    endpoint (i.e., a PE in a pool) and entry #1 (see below)                 :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                              ...                              :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                     Pool entry #n (see below)                 :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   R (Reject) flag: 1 bit

      MUST be set to '1' if the associated information, sender of this message is rejecting
      a namespace request. In such
    as its transport address(es), load control, and other operational
    status information 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 PE. 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 3.1.

   Receiver Server's ID:

      See 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 = 0x3            |       Length=variable 0x4  |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SCTP Port        Update Action          |    Number of IP addrs=k        (reserved)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                        IP addr param #0                       :
   |                      Sender Server's ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                        IP addr param #1                       :
   |                     Receiver Server's ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
    :                             .....                             :
    :                        Pool handle                            :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                        IP addr param #k                        Pool Element                           :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Load Policy Type        |        Policy Value           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Registration Life                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Each

   Message Length: 16 bits (unsigned integer)

      Indicates the entire length of the IP address parameters message in a PE parameter can be either
    an IPv4 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 IPv6 address parameter.

3.1.4 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 3.1.

   Receiver Server's ID:

      See section 3.1.

   Pool Handle Parameter 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 = 0x4 0x5  |0|0|0|0|0|0|0|0|    Message Length = 0xC       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Length=variable                      Sender Server's ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                         Pool Handle                           :
    :                                                               :
    :                                                               :
   |                     Receiver Server's ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Sender Server's ID:

      See section 3.1.

   Receiver Server's ID:

      See section 3.1.

3.6 PEER_LIST_RESPONSE message

   This parameter holds a pool handle (i.e., a pool name), defined as message is used to respond a NULL terminated ASCII string.

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

    This parameter is used

   R (Reject) flag: 1 bit

      MUST be set to hold an authorization signature. The
    signature is signed over '1' if the entire ASAP sender of this message and uses is rejecting a
    preconfigured public/private key pair. The receiver of
      peer list request. In such a message
    which includes case, this parameter can validate the message is
    from the sender by comparing the signature to one generated
    using MUST be sent
      with no peer server ID included.

   Message Length: 16 bits (unsigned integer)

      Indicates the peers public key.

3.1.6 Name entire length of the message in number of
      octets.

   Sender Server's ID:

      See section 3.1.

   Receiver Server's ID:

      See section 3.1.

   Server Identifier Information Parameter

     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            |          Length=variable      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Name Server SCTP Port   |          (reserved)           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                   IPv4 or IPv6 Addr Param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    When of Peer #1-#n:

      Each contains a name server is multi-homed, any one Server Information Parameter of its IP addresses can
    be used in its a peer known to the
      sender. The Server Identifier Parameter. This Information Parameter is because defined in
      [RSPL-PARAM].

4. ENRP Operation Procedures

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

   Many of its IP addresses the Rserpool events call for both server-to-server and its SCTP port
    number always uniquely identifies
   PU/PE-to-server message exchanges. Only the server.

3.2 message exchanges and
   activities between an ENRP Message Formats

   The figure below illustrates server and its peer(s) are considered
   within the common format ENRP scope and are defined in this document.

   Procedures for all exchanging messages between a PE/PU and ENRP
   messages. Each message is formatted 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 to exchange information such
   as the pool membership changes, namespace data synchronization,
   etc.

   Two types of communications are used amongst ENRP servers:

     - point-to-point message exchange from one ENPR server to a Message
   Type field, a message-specific Flag field, a Message Length field,
       specific peer server, and a
   Value field.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Message Type  |   Msg Flags   |        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                        Message Value                          :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Message Type: 8 bits (unsigned integer)

      This field identifies the type of information contained in the
      Message Value field. It takes a value

     - announcements from 0 one server to 254.  The value
      of 255 all its peer servers in the
       operation scope.

   Point-to-point communication is reserved for future use as always carried out over an extension field.

      Message Types SCTP
   associaiton between the sending server and the receiving
   server.

   Announcements are encoded such that communicated out with one of the highest-order following two bits
      specify the action that must be taken if
   approaches:

     1) The sending server sends the announcement message receiver 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 recognize gaurrantee that all the Message Type.

      00 - Stop processing this message and discard it.

      01 - Stop processing peers will receive the announcement
     message. Moreover, since IP multicast is not secure, this message and discard it, and report
     approach cannot provide any security to the
	   unrecognized message in an 'Unrecognized Parameter Type'
	   error.

      10 - reserved.

      11 - reserved.

   Message Flags: 8 bits communication.

     2) The usage sending server sends multiple copies of these bits depends on the message type as given by the Message Type. Unless otherwise specified, they are set announcement,
     one to
      zero on transmit and are ignored on receipt.

   Message Length: 16 bits (unsigned integer)

      This value represents the size each of its peer servers, over a set of point-to-point
     SCTP associations between the message in bytes including
      the Message Type, Message Flags, Message Length, sending server and Message
      Value fields. Therefore, if the Message Value field is
      zero-length, peers.

     This approach gaurrantees the Length field will reliabe receiption of the
     message. When needed, data security can be set to 4.  The Message
      Length field does not count any padding.

   Message Value: variable length

      The Message Value field contains the actual information achieved by using IP
     security mechanisms such as IPsec [SCTP-IPSEC] or TLS [SCTP-TLS].

   In order to be
      transferred in the message.  The usage and format maximize inter-operability of this field
      is dependent on ENRP servers, the Message Type.

   The total length of a message (including Type, Length and Value
   fields)
   following rules MUST be followed:

     1) At the startup time, a multiple of 4 bytes.  If 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 length
	availability of IP multicast and the
   message is not a multiple of 4 bytes, security requirements
	from the sender user of Rserpool.

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

       2a) MUST pad NOT subscribe to the
   message with all zero bytes well-known server multicast
	   channel, i.e., it only receives peer announcements over
	   SCTP associations, and this padding is not included in the
   message length field. The sender should never pad

       2b) MUST transmit all its out-going announcements over
	   point-to-point SCTP associations with more than 3
   bytes.  The receiver its peers.

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

       3a) MUST ignore subcribe to the padding bytes.

3.2.1 PEER_PRESENCE 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 = 0x1  |0|0|0|0|0|0|0|R|        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's Server ID param (optional)            :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The receiving server's ID does not need well-known server multicast channel to
	   ready itself for receiving peers' multicast announcements,

       3b) MUST also be included if the
    message 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 peer is being multicasted.

    "Reply_required" (R) flag shall be set always assumed to '1' if response to this be
	   multicast-disabled until/unless an ENRP message of any type
	   is required, otherwise set received from that peer over the well-known server
	   multicast channel.

       3d) when sending out an announcement, MUST send a copy to '0'.

3.2.2 PEER_NAME_TABLE_REQUEST 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 = 0x2  |0|0|0|0|0|0|0|0|        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's 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 ID param (optional)            :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The receiving server's ID does not need Initialization

   This section describes the steps a new ENRP server needs to be included take in
   order to join the other existing ENRP servers, or to initiate the
   namespace service if it is the
    message first ENRP server started in the
   operation scope.

4.2.1 Generate a Server Identifier

   A new ENRP server MUST generate a 32-bit server Id that is being multicasted.

    (Editor's note: we may not support multicast of as
   unique as possible in the operation scope and this message).

3.2.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|0|M|        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's server Id MUST
   remain unchanged for the lifetime of the server. Normally, a good
   32-bit random number will be good enough as the server Id
   ([RFC1750] provides some information on randomness guidelines).

4.2.2 Acquire Peer Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's Server ID parameter                   :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                     Pool entry #1 (see below)                 :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                              ...                              :

    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                     Pool entry #n (see below)                 :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    "More_to_send" (M) flag:

       shall be set List

   At startup, the ENRP server (initiating server) will first attempt
   to '1' if there learn all existing peer ENRP servers in the same operation
   scope, or to determine that it is along in the scope.

   The initiating server uses an existing peer server to bootstrap
   itself into service. We call this peer server the mentor server.

4.2.2.1 Find the mentor server

   If the initiating server is told about an existing peer server
   through some administrative means (such as DNS query, configuration
   database, startup scripts, etc), the initiating server SHOULD then
   use this peer server as its mentor server and SHOULD skip the
   remaining steps in this subsection.

   If multiple existing peer servers are more pool entries specified, the initiating
   server SHOULD pick one of them as its mentor peer server, keep the
   others as its backup menter peers, and skip the remaining steps
   in this subsection.

   If no existing peer server is specified to the initiating server
   AND if multicast is available in the operation scope, the following
   mentor peer discovery procedures SHOULD be sent followed:

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

   2) Then the initiating server SHOULD send a PEER_PRESENCE message,
      with the 'Reply_required' flag set, over the multicast channel.
      Upon the reception of this PEER_PRESENCE message, a peer server
      MUST send a PEER_PRESENCE, without the 'Reply_required' flag,
      back to the initiating server.

   3) When the first response to its original PEER_PRESENCE arrives,
      the initiating server SHOULD take the sender of this received
      response as its mentor peer server. This completes the discovery
      of the mentor peer server.

      If responses are also received from other peers (a likely event
      when multiple peers exist in the operation scope at the time the
      new server started), the initiating server SHOULD keep a list of
      those responded as its backup mentor peers (see below).

   4) If no response to its PEER_PRESENCE message are received after
      <TIMEOUT-SERVER-HUNT> seconds, the initiating server SHOULD
      repeat steps 2) and 3) for up to <MAX-TIME-SERVER-HUNT>
      times. After that, if there is still no response, the initiating
      server MUST assume that it is alone in subsequent PEER_NAME_TABLE_RESPONSE messages. Otherwise, the operation scope.

   5) If the initiating server determined that it
       shall be set is alone in the
      scope, it MUST skip the procedures in Sections 4.2.2.2? to '0'.

    Pool entries:

       At
      4.2.3? and MUST consider its initialization complete and start
      offering ENRP services.

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

   Note, if the administratively specified menter peer(s) fails, the
   initiating server 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 initiating server MUST start with send
   a pool handle parameter, followed by
       one or more pool element (PE) parameters, i.e.:

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

3.2.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         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's Server ID param (optional)            :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                        Pool handle                            :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                        Pool Element                           :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Update action                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The receiving server's ID does not need PEER_LIST_REQUEST message to be included if the
    message is being multicasted.

    "Update_action" field:

       shall take one mentor peer server to request a
   copy of the following values:

       0x0 - ADD_PE: add complete server list maintained by the PE as a new member to or update mentor peer (see
   Section 4.9? for maintaining server list).

   Upon the PE in reception of this request, the named pool mentor peer server SHOULD
   reply with a PEER_LIST_RESPONSE message and include in the namespace.
       0x1 - DELETE_PE: delete message
   body all existing ENRP servers known by the specified PE from mentor peer.

   Upon the namespace.

3.2.5 PEER_LIST_REQUEST 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 = 0x5  |0|0|0|0|0|0|0|0|        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's Server ID param (optional)            :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The receiving server's ID does not need to be included if reception of the
    message is being multicasted.

3.2.6 PEER_LIST_RESPONSE message

    This message shall contain all from the peer
   mentor peer, the initiating server MUST use the server
   information of carried in the sending
    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 = 0x6  |0|0|0|0|0|0|0|R|        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's Server ID parameter                   :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                   ID of Peer Server #1                        :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                           ...                                 :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                   ID of Peer Server #n                        :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    "Reject" (R) flag:

        shall be set message to '1' initialize its own peer
   list.

   However, if the sender of this message mentor itself is rejecting in the process of startup and not
   ready to provide a peer server list request. In such (for example, the mentor peer
   is waiting for a case, this message response to its own PEER_LIST_REQUEST to another
   server), it MUST be sent rejest the request by the initiating server and
   respond with a PEER_LIST_RESPONSE message with the R flag set to
   '1', and with no server information included in the response.

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

4. and send the PEER_LIST_REQUEST to the new mentor server.

4.2.3 Download ENRP Operation Procedures

    In this section, we discuss Namespace Data from Mentor Peer

   After a peer list download is completed, the procedures defined initiating server
   MUST request a copy of the current namespace data from its mentor
   peer server, by ENRP. taking the following steps:

   1) The
    procedures initiating server MUST first send a PEER_NAME_TABLE_REQUEST
      message to the mentor peer.

   2) Upon the reception of this message, the mentor peer MUST start a
      download session in which a copy of the current namespace data
      maintained by the mentor peer is sent to the initiating server
      in one or more PEER_NAME_TABLE_RESPONSE messages.

      If more than one PEER_NAME_TABLE_RESPONSE message are divided into two groups, namely used
      during the basic ENRP
    operations download, the mentor peer MUST use the M flag in each
      PEER_NAME_TABLE_RESPONSE message to indicate whether this
      message is the last one for the 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 fault management procedures.

    Many MUST keep track of the Rserpool events call for message exchange and other
    activities between both a PE and an ENRP server and the ENRP server
    and its peers. But only progress of the message exchange and activities between current download
      session. The mentor peer MUST set the ENRP server and its peers are considered within M flag to '0' in the ENRP
    protocol definition scope

    Procedures and message formats last
      PEER_NAME_TABLE_RESPONSE for communications between the PE download session and ENRP servers are defined in [ASAP]. However, in order to put
    our discussion in context, we will give brief description close the
      download session (i.e., removing any internal record of the
    ASAP activities whenever appropreate.

4.1 Basic ENRP Operations

4.1.1 PE Registration

    ENRP
      session) after sending out the last message.

   3) During the downloading, every time the initiating server <-> PE:

    This action is part of
      receives a PEER_NAME_TABLE_RESPONSE message, it MUST transfer
      the ASAP protocol and is defined data entries carried in [ASAP].

    To register itself with the name space, a PE sends a REGISTRATION message over into its local namespace
      database, and then check whether or not this message is the ENRP client channel last
      one for the download session.

      If the M flag is set to its home ENRP server.

    In '1' in the REGISTRATION just processed
      PEER_NAME_TABLE_RESPONSE message, the PE indicates the name of initiating server MUST
      send another PEER_NAME_TABLE_REQUEST message to the pool
    it wishes mentor peer
      to join in request for the next PEER_NAME_TABLE_RESPONSE message.

   4) When unpacking the data entries from a pool handle parameter, and PEER_NAME_TABLE_RESPONSE
      message into its port number
    and network access address(es) and any load control information in
    a PE parameter.

    The ENRP local namespace database, the initiating
      server handles MUST handle each pool entry carried in the REGISTRATION message according to using
      the following rules:

    1)

      4a) If the named pool does not exist in the local namespace, the ENRP
          initiating server will MUST creates a new the pool with that name in the local
          namespace and add the PE PE(s) in the pool entry to the pool.

	  When creating the pool, the initiation server MUST set the
	  overall member selection policy type of the pool as its to the
	  policy type indicated in the first PE;

    2) PE.

      4b) If the named pool already exists in the local namespace, but the
    requesting PE
	  PE(s) in the pool entry is not currently a member of the
	  pool, ENRP the initiating server
    will MUST add the PE as a new member PE(s) to the pool;
    3) pool.

      4c) If the named pool already exists in the local namespace AND the
    requesting PE
	  PE(s) in the Pool entry is already a member of the pool, the ENRP
	  initiating server
    shall consider this as a re-registration case. The ENRP Server
    shall server SHOULD replace the attributes of
	  the existing PE PE(s) with the
    information carried in new information.

    5) When the last PEER_NAME_TABLE_RESPONSE message is received REGISTRATION message.

    4) The ENRP server may reject the registration due to reasons such
    as invalid values, lack of resource, etc.

    In all cases, the ENRP server will reply to from
       the requesting PE with
    a REGISTRATION_RESPONSE message, mentor peer and will indicate in the message
    body whether unpacked into the registration is granted or rejected.

    ENRP server <-> Its peers:

    If local namespace, the registration request
       initialization process is granted (i.e., cases 1-3 above), completed and the ENRP initiating server MUST take
       SHOULD start to provide ENRP services.

   Under certain circumstances, the namespace modification action as
    described in section 4.1.5.1?. Otherwise, no message shall mentor peer itself may not be
    exchanged with its peers.

4.1.2 PE De-registration

    ENRP server <-> PE:

    This action is part of able
   to provide a namespace download to the ASAP protocol and initiating server. For
   example, the mentor peer is defined in [ASAP].

    To remove itself from a pool, a PE sends a DEREGISTRATION message
    over the ENRP client channel to middle of initializing its home ENRP server. own
   namespace database, or it has currently too many download sessions
   open to other servers.

   In response, such a case, the home ENRP mentor peer MUST rejest the request by the
   initiating server sends and respond with a REGISTRATION_RESPONSE PEER_NAME_TABLE_RESPONSE
   message to with the PE R flag set to '1', and indicates with no pool entries
   included in the message body whether the
    request is granted or rejected.

    If response.

   In the PE case where its PEER_NAME_TABLE_REQUEST is rejected by the last one of the named pool, the home ENRP server
    will remove the pool from
   mentor peer, the namespace as well.

    The ENRP initiating server may reject SHOULD either wait for a few
   seconds and re-send the de-registration request due PEER_NAME_TABLE_REQUEST to
    reasons such as invalid parameters, etc.

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

    ENRP server <-> peers:

    Once the de-registration request if there is granted and the PE removed from
    its local copy of the namespace, the home ENRP a backup mentor peer available, select
   another mentor peer server MUST take and send the
    namespace modification action described in Section 4.1.5.2.

4.1.3 PE Re-registration

    A PE may re-register itself PEER_NAME_TABLE_REQUEST to
   the new mentor server.

   A started namespace download session may get interrupted for some
   reason. To cope with this, the initiating server SHOULD start a new set of
    attributtes in order to, for example, extend its registration
    life, change its load policy value.

    However, an existing PE MUST NOT change its access address list
    via re-registration. Instead,
   timer everytime it finishes sending a PEER_NAME_TABLE_REQUEST to change
   its address list mentor peer. If this timer expires without receiving a PE
    shall de-register itself first and then register with response
   from the
    namespace as a new PE.

    A PE can modify its load policy value at any time via
    re-registration. Based on mentor peer, the number of PEs in initiating server SHOULD abort the pool
   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, if the
    pool's load distrbution policy,
   mentor peer has still more data to send, it SHOULD start a session
   timer. If this operation allows timer expires without receiving another request from
   the PE to
    dynamically control its share of inbound messages received by initiating server, the
    pool (also see Section 4.5.2 in [ASAP] for more on load control).

    ENRP server <-> PE:

    This action is part of mentor peer SHOULD abort the ASAP protocol session,
   cleaning out any resource and is defined in [ASAP]. record of the session.

4.3 Handle PE Registration

   To perform a re-registration, register itself with the namespace, a registered PE shall simply send sends a new REGISTRATION
   message with a new set of attributes over the
    ENRP client channel to its home ENRP server.

    Upon the reception The format of this REGISTRATION message
   and rules of sending it are defined in [ASAP].

   In the REGISTRATION message, the home ENRP
    server shall follow PE indicates the same procedures described name of the pool
   it wishes to join in Section
    4.1.1. a pool handle parameter, and its complete
   transport information and any load control information in a PE
   parameter.

   The ENRP server <-> peers:

    If handles the REGISTRATION message is accepted, the home ENRP server
    shall take according to the action described in Section 4.1.5.1?. Otherwise, no
    message shall be exchanged with its peers.

4.1.4 Name Translation

    ENRP server <-> PE or PU:

    This action is part of
   following rules:

   1) If the ASAP protocol and is defined named pool does not exist in [ASAP].

    A PE or PU can use the name translation service provided by namespace, the ENRP
   server to resolve MUST creates a new pool with that name to a list of accessible transport
    addresses of existing PEs.

    This requires in the namespace and
   add the PE or PU to send a NAME_RESOLUTION messages to the pool as its
    home ENRP server and in first PE;

   When a new pool is created, the NAME_RESOLUTION message specify overall member selection policy of
   the pool
    name to MUST be translated in a Pool Handle parameter. set to the policy type indicated by the first PE.

   2) If the named pool exits already exists in the namespace, but the
   requesting PE is not currently a member of the pool, the home ENRP server
   will
    send back a NAME_RESOLUTION_RESPONSE message that shall carry add the PE as a
    list of new member to the pool;

   After adding the PE parameters containing all information of to the PEs
    currently registered under that pool name. This information may
    include pool, the server MUST check if the current load control
   policy of type indicated by the pool, PE is the same as the overall policy value
   type of each PE, transport address(es) for each PE, etc.

    Otherwise, the pool. If different, the ENRP server shall respond MUST attempt to
   override the PE's policy and make it the same as the overall
   policy.

     2a) If no additional policy-related information are required to
     perform the override (e.g., overriding Least-used with a NAME_UNKNOWN
    message. Round-robin
     does not require additional policy-related information), the ENRP
     server <-> peers:

    None.

4.1.5 Server Namespace Update

    This includes a set MUST replace the PE's policy type with the overall policy
     type.

     2b) If additional policy information is required (e.g.,
     overriding Round-robin with Least-load will require the knowledge
     of update operations used by an the load factor of the PE), the ENRP server to
    inform its peer(s) about MUST reject the addition of a new PE, removal of
     regirstration with an
    existing PE, or change of error code "Pooling policy inconsistent".

   3) If the named pool or already exists in the namespace AND the
   requesting PE properties.

4.1.5.1 Add/Update is already a PE

    When member of the pool, the ENRP server
   SHOULD consider this as a new PE is granted registration to re-registration case. The ENRP Server
   SHOULD replace the attributes of the namespace or an existing PE is granted a re-registration, with the home
   information carried in the received REGISTRATION message.

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

   In all its peers.

    An ENRP server shall multicast over above cases, the ENRP server channel a
    PEER_NAME_UPDATE message with the Update_action field set MUST reply to
    ADD_PE, indicating the addition of the new requesting PE or
   with a REGISTRATION_RESPONSE message. In the update of an
    existing PE to message, the namespace. The PE and ENRP
   server MUST set the pool its belongs Action code to indicate that this is a response
   to
    shall be indicated in the message with a PE parameter registration and MUST indicate in the Result code whether
   the registration is granted or rejected.

   If the registration is granted with a Pool
    Handle parameter, respectively polcy override (see Section 3.2.4).

    Upon Step 2a
   above), in addition to the reception of this PEER_NAME_UPDATE message, each of Result code, in the
   REGISTRATION_RESPONSE message the
    peer ENRP servers shall take server SHOULD also send back
   the following actions:

    1) If registrant PE the named pool under which new policy, in a Member Selection Policy
   Parameter, so as to inform the PE has been registered (or
    re-registered) does not exist in that a policy override is
   performed.

   If the peer's local copy registration is granted (i.e., one of cases 1-3 above), the
    namespace, the peer
   ENRP server shall create MUST take the named pool namespace update action as described in
   Section 4.6? to inform its
    local namespace copy and add peers about the change just made. If 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 it as the first PE. It then
    shall copy namespace with a new set of
   attributtes in all other attributes 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 number of the PE carried PEs in the
    message.

    2) If the named pool already exists in and the peer's local copy
   pool's overall policy type, this operation allows the PE to
   dynamically control its share of inbound messages received by the
    namespace AND
   pool (also see Section 4.5.2 in [ASAP] for more on load control).

   Moreover, when re-registering, the PE does not exist, MUST NOT change its policy
   type. The server MUST reject the peer shall add re-registration if the PE attempt
   to change its policy type. In the pool as rejection, the server SHOULD
   attach an error code "Pooling policy inconsistent".

4.4 Handle PE De-registration

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

   In the message.

    3) If the named pool exists AND DEREGISTRATION message the PE is already a member indicates the name of the
   pool it belongs to in a pool handle parameter and provides its PE
   identifer.

   Upon receiving the local copy of the namespace, message, the peer ENRP server
    shall replace the attributes of SHALL remove the PE with the new information
    carried in
   from its namespace. Moreover, if the message.

4.1.5.2 Remove a PE

    This procedure is used by an the last one of the
   named pool, the ENRP server to inform its peer(s) to will remove an existing PE.

    An ENRP server shall multicast over the pool from the namespace
   as well.

   If the ENRP server channel a
    PEER_NAME_UPDATE message with the Update_action field set fails to
    DELETE_PE, indicating the removal find any record of an existing PE from the
    namespace. The PE in its
   namespace, it SHOULD consider the de-registration granted and
   completed.

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

   In response, the ENRP server MUST send a REGISTRATION_RESPONSE
   message to shall be indicated
    in the message with a PE parameter and a Pool Handle parameter,
    respectively.

    On PE. In the reception of this PEER_NAME_UPDATE message, each peer the ENRP server shall find and remove MUST set the
   Action code to indicate that this is a response to a PE from its local copy of
   de-registration, and indicate in the
    namespace. If Result code whether the peer
   request is granted or rejected.

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

   Once the de-registration request is granted AND the PE removed from
   its local copy of the namespace, it SHOULD take no action.

4.1.6 Server Download Namespace from a Peer Server

    This operation allows an the ENRP server to request and receive a copy
    of MUST take the current
   namespace from one of update action described in Section 4.6? to inform its peer ENRP servers.

    This operation is especially useful for a newly started ENRP server
   peers about the change just made. Otherwise, NO message SHALL be
   send to initiate its local copy of peers.

4.5 Pool Handle Translation

   A PE or PU uses the namespace, as well as for pool handle translation service of an
    existing ENRP
   server to correct namespace inconsistency found during
    its operation.

    1) An ENRP server shall first send resolve a PEER_NAME_TABLE_REQUEST message
    directly pool handle to one a list of accessible transport
   addresses of its peers.

    2) Upon the reception member PEs of this message, the peer server shall
    initiate a download session in which pool.

   This requires the namespace shall be sent PE or PU to the requesting send a NAME_RESOLUTION message to its
   home ENRP server and in one or more
    PEER_NAME_TABLE_RESPONSE messages.

    If the sending ENRP server determines that multiple
    PEER_NAME_TABLE_RESPONSE messages are needed for the session, it
    shall use the M flag in each PEER_NAME_TABLE_RESPONSE NAME_RESOLUTION message to
    inform the receiving ENRP server whether or not specify the data
   pool handle to be translated in this a Pool Handle parameter. Complete
   defintion of the NAME_RESOLUTION message is and the last piece rules of sending
   it are defined in [ASAP].

   Upon reception of the namespace transfer.

    3) During the downloading, every time NAME_RESOLUTION message, the requesting ENRP server
    receives a PEER_NAME_TABLE_RESPONSE message, it shall transfer MUST
   first look up the
    data entries carried pool handle in the message into its local namespace
    database, and then check whether or not the data in this message is
    the last piece being transfered. namespace. If more data transfer is indicated, the requesting pool exits,
   the home ENRP server shall MUST compose and send another
    PEER_NAME_TABLE_REQUEST back a
   NAME_RESOLUTION_RESPONSE message to the same peer to request for the
    next piece whenever it is ready.

    When unpacking requesting PU or PE.

   In the data entries from a PEER_NAME_TABLE_RESPONSE
    message into its local namespace database, response message, the requesting ENRP server shall handle each MUST list all the PEs
   currently registered in this pool, in a list of PE by parameters. The
   ENRP server MUST also include a pool member selection policy
   parameter to indicate the following steps:

    1) overall member selection policy for the
   pool, if the current pool member selection policy is not
   round-robin (if the overall policy is round-Robin, this parameter
   MAY be omitted?).

   If the named pool does not exist in the local namespace, the ENRP server will creates a new pool
   MUST respond with that name in the
    namespace a NAME_UNKNOWN message.

   The complete format of NAME_RESOLUTION_RESPONSE and NAME_UNKNOWN
   messages and add the PE to the pool as the first PE;
    2) If the named pool already exists rules of receiving them are defined in the [ASAP].

4.6 Server Namespace Update

   This includes a set of update operations used by an ENRP server to
   inform its peers when its local namespace, but
    the PE namespace is not currently modified, e.g.,
   addition of a member new PE, removal of an existing PE, change of the pool, ENRP server shall
    add the pool
   or PE as properties.

4.6.1 Announcing Addition or Update of PE

   When a new member PE is granted registration to the pool;

    3) If the named pool already exists in the local namespace AND
    the requesting or an
   existing PE is already granted a member of the pool, re-registration, the home ENRP server may skip
   uses this PE.

4.1.7 Server Monitor Peer Status

    An ENRP server shall keep a record on the status of each of procedure to inform all its
    known peers.

   This record is referred an ENRP announcement and is sent to as all the "Peer list" peer of the
   home ENRP server.

    An interanl variable <Peer-last-heared> is kept for each peer See Section 4.1 on
    the peer list and its value updated how annoucements are sent.

   An ENRP server MUST announce this update to the current local time each
    time all its peers in a
   PEER_NAME_UPDATE message of any type is received from with the peer.

    If a message of any type is received from a peer previously
    unknown, Update action field set to
   ADD_PE, indicating the ENRP server shall create addition of a record for new PE or the modification of
   an existing PE. The complete new peer information of the PE and add it the pool
   its belongs to MUST be indicated in the peer list.

4.1.8 Server Download Peer List from message with a Peer Server

    This operation allows an PE parameter
   and a Pool Handle parameter, respectively.

   The home ENRP server to request from a peer SHOULD fill in its server Id in the Sender
   Server's ID field and leave the Receiver Server's ID blank (i.e.,
   all 0's).

   When a copy of its peer list. This is useful for a new ENRP server to
    initiate receives this PEER_NAME_UPDATE message, it MUST take
   the following actions:

     1) If the named pool indicated by the pool handle does not exist
     in its own peer list at startup.

    An ENRP server shall send a PEER_LIST_REQUEST message to a peer to
    request a local copy of the namespace, the peer list.

    Upon MUST create the reception named
     pool in its local namespace and add the PE to the pool as the first
     PE. It MUST then copy in all other attributes of this message, the peer server shall reply
    with a PEER_LIST_RESPONSE message and include PE carried
     in the message body
    a list of server IDs message.

     When the new pool is created, the overall member selection policy
     of all known peers. the pool MUST be set to the policy type indicated by the PE.

     2) If the peer itself is named pool already exists in the process peer's local copy of startup and
     the namespace AND the PE does not ready to
    provide a good exist, the peer list, it shall response with MUST add the PE
     to the pool as a
    PEER_LIST_RESPONSE message but set new PE and copy in all attributes of the R flag PE
     carried in the message to
    '1' to indicate that it can not grant message.

     3) If the PEER_LIST_REQUEST. In
    such named pool exists AND the PE is already a case, member of the requesting ENRP server shall select another peer
    and repeat
     pool, the peer list request with MUST replace the new peer at a later
    time.

4.1.9 Server Initialization

    This section describes attributes of the PE with the steps a new ENRP server needs to take
     information carried in
    order to join the other message.

4.6.2 Announcing Removal of PE

   When an existing ENRP servers for providing the PE is granted de-registration or is removed from
   its namespace service in for some other reasons (e.g., purging an unreachable
   PE), the operation scope, or initiating ENRP server MUST uses this procedure to inform all its
   peers about the
    namespace service if this change just made.

   This is the first an ENRP server starting in announcement and is sent to all the
    operation scope.

    1) At startup, before getting into service, peer of the
   home ENRP server. See Section 4.1 on how annoucements are sent.

   An ENRP server
    (initiating server) shall multicast MUST announce the PE removal to all its peers in a PEER_PRESENCE
   PEER_NAME_UPDATE message with
    'Reply_required' flag set over the ENRP server channel. This is Update action field set to
    inform any other
   DEL_PE, indicating the removal of an existing peers in PE. The complete
   information of the operation scope about PE and the
    initiating peer's presence.

    2) Upon pool its belongs to MUST be indicated
   in the reception of this message, message with a peer shall send PE parameter and a
    PEER_PRESENCE without 'Reply_required' flag back to Pool Handle parameter,
   respectively.

   [editor's note: only the initiating
    server, in order to help pool handle and the initiating server to build a peer list.

    3) If no response to its PEER_PRESENCE message PE's id are received after
    <MAX-TIME-SERVER-HUNT> seconds, the initiating server shall assume
    that needed, it is alone in
   should reduce the operation scope and shall mark size of the
    initialization process as completed. message]

   The initiation sending server shall
    skip MUST fill in its server ID in the remaining steps Sender
   Server's ID field and start to offer leave the namespace
    services.

    4) If there are responses Receiver Server's ID blank (i.e.,
   set to its PEER_PRESENCE all 0's).

   When a peer receives this PEER_NAME_UPDATE message, it MUST first
   find pool and the
    initiating server shall PE in its own namespace, and then take remove the actions described in 4.1.8 to
    request a peer list PE
   from one of the peers that have responded.

    5) Upon its local namespace. If the reception of removed PE is the PEER_LIST_RESPONSE message from last one in the
    peer,
   pool, the initiating server shall use peer MUST also delete the information carried in pool from its local namespace.

   If the
    message to build a complete peer list.

    6) Then, the initiating server shall request fails to download a copy of find the namespace from one of PE or the peer, as described pool in 4.1.6.

    At this point, the initialization process is completed and the
    initiating server shall start to provide namespace services.

4.2 Fault Management Operations

    The following operations are used to detect and recover from
    various system faults.

4.2.1 Detect its namespace, it
   SHOULD take no further actions.

4.7 Detecting and Remove an Removing Unreachable PE

   Whenever a PE PU finds a peer PE unreachable (e.g., via an SCTP
   SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the
    former shall PU
   SHOULD send an ENDPOINT_UNREACHABLE message over the ENRP
    client channel to its home ENRP
   server. The message shall SHOULD contain the pool handle and one the PE Id
   of the transport addresses unreachable PE.

   Upon the reception of 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 (i.e., it
   results in an SCTP SEND.FAILURE notification), the ENRP server MUST
   consider the PE as truly unreachable peer and MUST remove the PE from
   its namespace and take actions described in 4.6.2?.

   If the ENDPOINT_UNREACHABLE message is transmitted successfully to
   the PE, the ENRP server MUST retain the PE in its namespace.
   Moreover, the server SHOULD keep a counter to record how
   many ENDPOINT_UNREACHABLE messages it has received reporting
   reachability problem relating to this PE. If the counter exceeds
   the protocol threshold <MAX-BAD-PE-REPORT>, the ENRP server SHOULD
   remove the PE from its namespace and take actions described in
   Section 4.6.2?.

   The complete definition and rules of sending ENDPOINT_UNREACHABLE
   and ENDPOINT_KEEP_ALIVE messages are described in [ASAP].

4.8 Helping PE and PU to Discover Home ENRP Server

   At its startup time, or whenever its current home ENRP server is
   not providing services, a PE or PU will attempt to find a new home
   server. The PE or PU will either multicast or send a point-to-point
   SERVER_HUNT message to one or more ENRP servers in a PE parameter.

    Note: The definition and the operation
   scope. For the complete procedure of ENDPOINT_UNREACHABLE message
    are part of ASAP and are described this, see Section xxxx in
   [ASAP].

    Upon the reception of the ENDPOINT_UNREACHABLE message, the home

   To support this procedure, whenever a SERVER_HUNT message is
   received an ENRP server shall SHOULD immediately send an ENDPOINT_KEEP_ALIVE message respond to the sending
   PE that or PU with a SERVER_HUNT_RESPONSE message.

4.9 Maintaining Peer List and Monitoring Peer Status

   An ENRP server MUST keep internally a record on the status of each
   of its known peers. This record is reported referred to as unreachable. the server's
   "peer list"

4.9.1 Discovering New Peer

   If this
    ENDPOINT_KEEP_ALIVE fails (i.e., it results in an SCTP
    SEND.FAILURE notification), a message of any type is received from a previously unknown
   peer, the ENRP server shall MUST consider this peer a new peer in the PE
    as truly unreachable
   operation scope and shall remove the PE from its local copy
    of add it to the namespace and take actions described in 4.1.5.2.

    Note: The definition and handling of peer list.

   If the ENDPOINT_KEEP_ALIVE message by is
   received over the well-known server multicast channel, the PE are part of ASAP and are described in Sections
    3.2.8? and 4.9.3? in [ASAP].

4.2.2 Server Failure Detection by Heartbeat

    An ENRP
   server shall multicast, in every <PEER-HEARTBEAT-CYCLE>
    seconds, MUST mark this new peer as multicast-enabled. Otherwise, the
   new peer MUST be marked as multicast-disabled (see Section 4.1 for
   more details).

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

   [editor's note: we also want to send a reply-required probe 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 channel MUST announce
   its continued presence to
    inform all its peers that it is still operational. peer with a PEER_PRESENCE
   message. In the multicasted PEER_PRESENCE message, the sending ENRP server shall MUST set the
   'Replay_required' flag to '0' '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 sending server (see Section 4.9.3? for more details).

4.9.3 Detecting Peer Server Failure

   An ENRP server shall MUST keep track an interanl variable <Peer-last-heared>
   for each of its known peers and the time when value of this variable MUST be
   updated to the last current local time everytime a message
    (multicast of any type
   (point-to-point or point-to-point) was announcement) is received from each known peer in the internal variable <Peer-last-heared>. cooresponding
   peer.

   If a peer has not been heard for more than <MAX-TIME-LAST-HEARD>
   seconds, the ENRP server shall send a point-to-point PEER_PRESENCE
    with 'Reply_request' flag set to '1' to that peer.

    If the send fails or the peer does not reply after
    <MAX-TIME-NO-RESPONSE> seconds, the ENRP server shall consider
    the peer server dead and shall remove the peer from its peer list.

    When an ENRP server receives a PEER_PRESENCE message with
    'Reply_request' flag set to '1', it MUST immediately respond to
    the sender with its own point-to-point PEER_PRESENCE message
    without setting the 'Replay_required' flag.

4.2.3 PE or PU Discover Home ENRP Server

    This action is part of ASAP protocol and is defined in [ASAP].

    At its startup, or when it fails to send to (i.e., timed-out on a
    service request) with its current home ENRP server, a PE or PU shall
    initiate the following procedure to find a new home server.

    In the home server hunt procedure, the PE or PU shall multicast a
    SERVER_HUNT message over the ENRP client channel, and shall repeat
    sending this message every <TIMEOUT-SERVER-HUNT> seconds until a
    SERVER_HUNT_RESPONSE message is received from an ENRP server.

    Then the PE or PU shall pick one of the ENRP servers that have
    responded as its new home ENRP server, and send all its subsequent
    the namespace service requests point-to-point
   PEER_PRESENCE with 'Reply_request' flag set to this new home server.

    Upon '1' to that peer.

   If the reception of send fails or the peer does not reply after
   <MAX-TIME-NO-RESPONSE> seconds, the SERVER_HUNT message, an ENRP server shall
    reply to MUST consider the PE with a SERVER_HUNT_RESPONSE message.
   peer server dead and remove the peer from its peer list.

4.10 Namespace Data Auditing and Re-synchronization

   [TBD]

4.11 Reporting Unrecognized Message or Unrecognized Parameter

   [TBD]

5.  Variables and Time Constants

5.1 Variables

    <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> - the maximal number of attempts a sender
			     will make to contact an ENRP server
			     (Default=3 times).

    <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> - the period for an ENRP server to send out announce a
			     heartheat message to all its known peers.
			     (Default=30 secs.)

    <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> - pre-set threshold for how long a message
			     sender will wait for a response after
			     sending out a message. (Default=5 secs.)

    <TIMEOUT-SERVER-HUNT>

    <MAX-BAD-PE-REPORT> - pre-set threshold for how long the maximal number of unreachability reports
			  on a sender PE that an ENRP server will wait allow
			  before sending another
			    SERVER_HUNT message out. (Default=5 secs.) purging this PE from the namespace.
			  (Default=3)

6. Security COnsiderations 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 [SCTPIPSEC] [SCTP-IPSEC] 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 [SCTPTLS] [SCTP-TLS] or TLS over TCP as described in [RFC2246].
   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. References

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

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

    [ASAP]

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

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

    [RSERPOOL1] 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. R. Stewart, E. Lear, M. Shore, L. Ong,
   J. Loughney, M. Stillman: "Requirements for Reliable Server
    Pooling," <draft-ietf-rserpool-reqts-03.txt>,
   Pooling", RFC 3237, January 2002.

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

    [RSERPOOL2]

   [RSPL-ARCH] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore,
   L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server
   Pooling," <draft-ietf-rserpool-arch-00.txt>, work in progress.

    [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.

    [SCTPTLS]

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

    [SCTPIPSEC]

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

    [RFC2246] T. Dierks, C. Allen "The TLS

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

7.1 Informative References

   [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
   Security", RFC 2246, January 1999. 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

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

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

                    Expires in six months from Mar. May 2002