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

Expires in six months                                        June 1,                                       Nov. 20, 2001

                 Enpoint

                 Endpoint Name Resolution Protocol (ENRP)
                  <draft-ietf-rserpool-enrp-00.txt>
                  <draft-ietf-rserpool-enrp-01.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].

    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 Contents

    1. Introduction.................................................. 2 Introduction...............................................2
       1.2 Definitions................................................ 3 Definitions............................................2
    2. Conventions................................................... 4 Conventions................................................3
    3. ENRP Message Definitions...................................... 4 Definitions........................................4
       3.1 PE ENRP Parameter Definition.................................... 4 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 PEER_PRESENCE message...................................... 5
  3.3 message...........................8
	    3.2.2 PEER_NAME_TABLE_REQUEST message............................ 5
  3.4 message.................9
	    3.2.3 PEER_NAME_TABLE_RESPONSE message........................... 6
  3.5 message................9
	    3.2.4 PEER_NAME_UPDATE message................................... 7
  3.6 message........................10
	    3.2.5 PEER_LIST_REQUEST message.................................. 8
  3.7 message.......................11
	    3.2.6 PEER_LIST_RESPONSE message................................. 9
  3.8 TAKEOVER_INITIATE message..................................10
  3.9 TAKEOVER_INITIATE_RESPONSE message.........................11
  3.10 TAKEOVER_PEER_SERVER message..............................11
  3.11 SERVER_DUMP message.......................................12
  3.12 SERVER_DUMP_RESPONSE message..............................12 message......................11
    4. ENRP Operation Procedures.....................................14 Procedures..................................12
       4.1 Basic ENRP Operations......................................14 Operations..................................12
	   4.1.1 PE Registration........................................14 Registration..................................12
	   4.1.2 PE De-registration.....................................15 De-registration...............................13
           4.1.3 Name Translation.......................................16 PE Re-registration...............................13
	   4.1.4 Name Translation.................................14
	   4.1.5 Server Namespace Update................................16
      4.1.4.1 Add a New PE.......................................16
      4.1.4.2 Forceful Removal of a PE...........................17
      4.1.4.3 Advisory Removal of a PE...........................17
      4.1.4.4 Update PE Attributes...............................18
      4.1.4.5 Claim Ownership over Update..........................15
		 4.1.5.1 Add/Update a PE..........................15
		 4.1.5.2 Remove a PE..........................18
      4.1.4.6 Report PE Communication Failure....................18
    4.1.5 PE Change Policy Value.................................19 PE..............................15
	   4.1.6 Server Download Namespace from a Peer Server...........19 Server.....16
	   4.1.7 Server Monitor Peer Status.............................20 Status.......................17
	   4.1.8 Server Download Peer List from a Peer Server...........20 Server.....17
	   4.1.9 ENRP Server Initialization.............................21 Initialization............................17
       4.2 Fault Management Operations................................21 Operations............................18
	   4.2.1 Detect and Report Remove an Unreachable PE.......................21 PE..............18
	   4.2.2 ENRP Server Failure Detection by Heartbeat.............22 Heartbeat............19
	   4.2.3 PE or PU Discover Home ENRP Server Hunt...............................23
    4.2.4 ENRP Server Detecting and Taking-over Inactive Peer ...23
    4.2.5 Registration of Remote PEs.............................25
  4.3 Maintenance Operations.....................................25
    4.3.1 Forceful Removal of a PE...............................25
    4.3.2 Dump Home PE List......................................25
    4.3.3 Dump Remote PE List....................................26
    4.3.4 Dump Peer Server List..................................26 Server...............19
    5.  Variables, Time Constants, Variables and Thresholds....................26 Timer Constants..............................20
       5.1 Variables..................................................26 Variables..............................................20
       5.2 Timer Constants............................................26
  5.3 Thresholds.................................................27 Constants........................................20
    6. References....................................................27 Security COnsiderations....................................20
    7. Acknowledgements..............................................27 References.................................................20
    8. Acknowledgements...........................................21
    9. Authors' Addresses...........................................27 Addresses.........................................21

1. Introduction

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

    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.

     Pool (or server pool):
          A collection of servers providing the same application
          functionality.

     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.

     Pool element (PE):
          A server entity that runs ASAP and has registered to a pool.

     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.

     ENRP namespace server (or ENRP server):
          Entity which runs ENRP and is responsible for managing and
	  maintaining the namespace within the operation scope.

     ENRP maintenance client (or maintanance client):
          A special program that runs ASAP and has the additional
	  capability of exchanging ENRP maintenance messages with an
	  ENRP server in order to perform certain maintenance
	  functions.

     Home ENRP server:
	  The ENRP server to which a PE currently belongs. PEs
	  normally choose the ENRP server on their local host as the
	  home ENRP server, if one exists. A PU shall only have one
	  home ENRP server at any given time, and both the PU and the
	  home ENRP server shall keep track of this master/slave
	  relationship between them.

     ENRP server takeover:
	  The event that a remote ENRP server takes the ownership of
	  all the PEs on a node and becomes their new home ENRP
	  server.

     Caretaker ENRP server:
	  The ENRP server on a remote node which takes ownership of
	  all PEs on the local node because of the absence of an
	  active local ENRP server.

     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. Message Message Definitions

   All messages as well as their fields described below shall be in
   Network Byte Order during transmission. For fields with a length
   bigger than 4 octets, a number in a pair of parentheses may follow
   the filed name to indicate the length of the field in number of
   octets.

3.1 PE ENRP Parameter Definition

    This parameter is used in multiple Formats

   ENRP message to represent an ASAP
    endpoint (i.e., a PE parameters are defined in a pool) and the associated information, such Type-length-value (TLV) format as its transport address(es), load control, and other operational
    status information of the PE.

    The parameter is defined to support PEs with up to 8 different IPv4
    transport addresses.
   shown below.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        IP address #0                          |
    +-------------------------------+-------------------------------+
    |                        IP address #1                          |
    +-------------------------------+-------------------------------+
    \                     \                      \                  \
    /                     /                      /                  /
    \                     \                      \                  \
    +-------------------------------+-------------------------------+
    |                        IP address #7                          |
    +-------------------------------+-------------------------------+
    |          SCTP Port            |         Padding               |
    +-------------------------------+-------------------------------+          Parameter Type       |  Load sharing policy type       Parameter Length        |       Policy
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                       Parameter Value            |
    +---------------+---------------+---------------+---------------+

    The total                         :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameter Type:  16 bits (unsigned integer)

      The Type field is a 16 bit identifier of the type of parameter.
      It takes a value of 0 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 integer)

      The Parameter Length field contains the size of the parameter in
      bytes, including the Parameter Type, Parameter Length, and
      Parameter Value fields.  Thus, a PE parameter with a zero-length
      Parameter Value field would have a Length field of 4.  The
      Parameter Length does not include any padding bytes.

   Parameter Value: variable-length.

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

   The total length of a parameter (including Type, Parameter Length and
   Value fields) MUST be a multiple of 4 bytes.  If the length of the
   parameter is 40 octets.

3.2 PEER_PRESENCE 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 the padding is not included in the parameter
   length field.  A sender SHOULD NOT pad with more than 3 bytes.  The
   receiver 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 ENRP message and discard it, do not process
        any further parameters within it.

   01 - Stop processing this ENRP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        ENRP server message identifier #1 = 0x27047729         |
    +-------------------------------+-------------------------------+
    |        ENRP server message identifier #2 = 0x53829149         |
    +-------------------------------+-------------------------------+
    |        Type = 0x100                            |
    +-------------------------------+-------------------------------+
    |                      sender's IP address                      |
    +-------------------------------+-------------------------------+ 0x1             |      sender's SCTP port      Length = 8               |         padding
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |
    +-------------------------------+-------------------------------+                        IPv4 Address                           |                    receiver's IP
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Address: 32 bits (unsigned integer)

      Contains an IPv4 address                      |
    +-------------------------------+-------------------------------+
    |      receiver's SCTP port     |         padding               |
    +-------------------------------+-------------------------------+
    |                       Reply required                          |
    +-------------------------------+-------------------------------+

    The receiving server's IP address and port do not need to be filled
    in if of the message is being multicasted.

    'Reply_required' flag shall be set to 0x1 if response to this
    message sending endpoint.  It is required, otherwise set to 0x0.

3.3 PEER_NAME_TABLE_REQUEST message binary
      encoded.

3.1.2 IPv6 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        ENRP server message identifier #1            Type = 0x27047729         |
    +-------------------------------+-------------------------------+ 0x2         |        ENRP server message identifier #2          Length = 0x53829149 20          |
    +-------------------------------+-------------------------------+
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Type = 0x102                                                               |
    +-------------------------------+-------------------------------+
      |                 sending server's IP address                         IPv6 Address                          |
    +-------------------------------+-------------------------------+
      |       sender's SCTP port                                                               |         padding
      |
    +-------------------------------+-------------------------------+                                                               |                receiving server's IP
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Address: 128 bit (unsigned integer)
      Contains an IPv6 address                  |
    +-------------------------------+-------------------------------+
    |      receiver's SCTP port     |         padding               |
    +-------------------------------+-------------------------------+
    |                      Table type = (see below)                 |
    +-------------------------------+-------------------------------+

    Note, of the receiver's IP address and port do not need sending endpoint.  It is binary
      encoded.

3.1.3 Pool Element Parameter

    This parameter is used in multiple ENRP message to be filled represent an ASAP
    endpoint (i.e., a PE in
    if a pool) and the message is being multicasted.

    The requested 'Table type' shall take one associated information, such
    as its transport address(es), load control, and other operational
    status information of the following values:

    0x1 --- HOME_LIST: PEs owned by the receiver server.
    0x2 --- REMOTE_LIST: PEs NOT owned by the receiver
	    server.

3.4 PEER_NAME_TABLE_RESPONSE message PE.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        ENRP server message identifier #1 = 0x27047729         |
    +-------------------------------+-------------------------------+
    |        ENRP server message identifier #2 = 0x53829149         |
    +-------------------------------+-------------------------------+
    |         Type = 0x103                            |
    +-------------------------------+-------------------------------+ 0x3            |                     sender's IP address       Length=variable         |
    +-------------------------------+-------------------------------+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      sender's          SCTP port       |         padding               |
    +-------------------------------+-------------------------------+ Port            |                     receiver's    Number of IP address                     |
    +-------------------------------+-------------------------------+
    |      receiver's SCTP port     |         padding addrs=k       |
    +-------------------------------+-------------------------------+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                        IP addr param #0                       :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                        IP addr param #1                       :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                             .....                             :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                        IP addr param #k                       :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Table type = (see below)       Load Policy Type        |
    +-------------------------------+-------------------------------+        Policy Value           |                  More to send = (see below)
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |
    +-------------------------------+-------------------------------+                    Registration Life                          |                     number
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Each of pool names = n                  |
    +-------------------------------+-------------------------------+
    |                                                               |
    | the IP address parameters in a PE parameter can be either
    an IPv4 or IPv6 address parameter.

3.1.4 Pool entry #1 (see below)                 |
    |                                                               |
    +-------------------------------+-------------------------------+
    /                                                               /
    \                                                               \
    /                                                               /
    +-------------------------------+-------------------------------+ Handle 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 = 0x4            |       Length=variable         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                         Pool entry #n (see below) Handle                           :
    :                                                               :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    This parameter holds a pool handle (i.e., a pool name), defined as
    a NULL terminated ASCII string.

3.1.5 Authorization 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 = 0x5            |       Length=variable         |
    +-------------------------------+-------------------------------+

    Field 'Table type' shall take one
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                   Authorization Signature                     :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    This parameter is used to hold an authorization signature. The
    signature is signed over the entire ASAP message and uses a
    preconfigured public/private key pair. The receiver of a message
    which includes this parameter can validate the following values:

    0x1 --- HOME_LIST: PEs owned by message is
    from the sending ENRP server.
    0x2 --- REMOTE_LIST: PEs NOT owned sender by comparing the sending ENRP
	    server.

    Field 'More to send' flag shall be set to 0x1 if there are more pool
    entries to be sent for the requested table type. Otherwise, it shall
    be set signature to 0x0.

    Each 'Pool entry' represents an existing pool and shall consist of one generated
    using the following:

    +-------------------------------+-------------------------------+
    |                                                               |
    |                      Pool handle name (32)                    |
    |                                                               |
    +-------------------------------+-------------------------------+
    |                      number of PEs  = m                       |
    +-------------------------------+-------------------------------+
    |                                                               |
    |                            PE #1 (40)                         |
    |                                                               |
    +-------------------------------+-------------------------------+
    /                                                               /
    \                             .....                             \
    /                                                               /
    +-------------------------------+-------------------------------+
    |                                                               |
    |                            PE #m (40)                         |
    |                                                               |
    +-------------------------------+-------------------------------+

3.5 PEER_NAME_UPDATE message peers public key.

3.1.6 Name Server Identifier 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        ENRP server message identifier #1 = 0x27047729         |
    +-------------------------------+-------------------------------+
    |        ENRP server message identifier #2 = 0x53829149         |
    +-------------------------------+-------------------------------+
    |         Type = 0x104                            |
    +-------------------------------+-------------------------------+ 0x7            |                     sender's IP address          Length=variable      |
    +-------------------------------+-------------------------------+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      sender's       Name Server SCTP port       |         padding Port   |
    +-------------------------------+-------------------------------+          (reserved)           |                    receiver's
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                   IPv4 or IPv6 Addr Param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    When a name server is multi-homed, any one of its IP address                      |
    +-------------------------------+-------------------------------+
    |      receiver's SCTP port     |         padding               |
    +-------------------------------+-------------------------------+
    |                                                               |
    |                     Pool handle name (32)                     |
    |                                                               |
    +-------------------------------+-------------------------------+
    |                                                               |
    |                         PE entry (40)                         |
    |                                                               |
    +-------------------------------+-------------------------------+
    |                 Update action (see below)                     |
    +-------------------------------+-------------------------------+

    The receiver's IP address and port do not need to addresses can
    be filled used in if
    the message its Server Identifier Parameter. This is being multicasted.

    Field 'Update action' shall take one of the following values:

    0x0 --- ADD_ENDPOINT: add the PE as a new member to the named pool
  	    in the local copy of the namespace.
    0x1 --- DELETE_ENDPOINT: delete the specified PE from because the local copy
    combination of namespace _if_ the receiving server owns the PE.
    0x2 --- REMOVE_ENDPOINT: remove the specified PE from the local copy any one of namespace, regardless who owns the PE.
    0x3 --- UPDATE_ENDPOINT: replace the specified PE's attributes with
	    the new information carried in this message.
    0x4 --- ENDPOINT_FAILURE: warn the receiver that the specified PE
            is potentially unreachable.
    0x5 --- CLAIM_ENDPOINT: inform the receiver that the sender has
            taken its IP addresses and its SCTP port
    number always uniquely identifies the ownership of server.

3.2  ENRP Message Formats

   The figure below illustrates the specified PE.

3.6 PEER_LIST_REQUEST common format for all ENRP
   messages. Each message is formatted with a Message
   Type field, a message-specific Flag field, a Message Length field, 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        ENRP server message identifier #1 = 0x27047729         |
    +-------------------------------+-------------------------------+
    |        ENRP server message identifier #2 = 0x53829149         |
    +-------------------------------+-------------------------------+
    | Message Type = 0x10b                            |
    +-------------------------------+-------------------------------+  |                      sender's IP address                      |
    +-------------------------------+-------------------------------+
    |      sender's SCTP port       |         padding               |
    +-------------------------------+-------------------------------+
    |                     receiver's IP address                     |
    +-------------------------------+-------------------------------+
    |      receiver's SCTP port   Msg Flags   |         padding        Message Length         |
    +-------------------------------+-------------------------------+

    The receiver's IP address and port do not need to be filled in if
    the message is being multicasted.

3.7 PEER_LIST_RESPONSE message
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                        Message Value                          :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Message Type: 8 bits (unsigned integer)

      This message shall contain all field identifies the peer information type of information contained in the sending
    server.
      Message Value field. It takes a value from 0                   1                   2 to 254.  The value
      of 255 is reserved for future use as an extension field.

      Message Types are encoded such that the highest-order two bits
      specify the action that must be taken if the message receiver
      does not recognize the Message Type.

      00 - Stop processing this message and discard it.

      01 - Stop processing this message and discard it, and report the
	   unrecognized message in an 'Unrecognized Parameter Type'
	   error.

      10 - reserved.

      11 - reserved.

   Message Flags: 8 bits

      The usage of these bits depends on the message type as given by
      the Message Type. Unless otherwise specified, they are set to
      zero on transmit and are ignored on receipt.

   Message Length: 16 bits (unsigned integer)

      This value represents the size of the message in bytes including
      the Message Type, Message Flags, Message Length, and Message
      Value fields. Therefore, if the Message Value field is
      zero-length, the Length field will 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 to be
      transferred in the message.  The usage and format of this field
      is dependent on the Message Type.

   The total length of a message (including Type, Length and Value
   fields) MUST be a multiple of 4 bytes.  If the length of the
   message is not a multiple of 4 bytes, the sender MUST pad the
   message with all zero bytes and this padding is not included in the
   message length field. The sender should never pad with more than 3
   bytes.  The receiver MUST ignore 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        ENRP server message identifier #1 = 0x27047729         |
    +-------------------------------+-------------------------------+
    |        ENRP server message identifier #2 = 0x53829149         |
    +-------------------------------+-------------------------------+
    |   Type = 0x10c                            |
    +-------------------------------+-------------------------------+
    |                     sender's IP address                       |
    +-------------------------------+-------------------------------+
    |      senders SCTP port        |         padding               |
    +-------------------------------+-------------------------------+
    |                    receiver's IP address                      |
    +-------------------------------+-------------------------------+
    |      receiver's SCTP port     |         padding               |
    +-------------------------------+-------------------------------+
    |                  responseIndication (see below)               |
    +-------------------------------+-------------------------------+
    |                     number of peers = n                       |
    +-------------------------------+-------------------------------+
    |                                                               |
    |                   Peer entry 1 (see below)                    |
    |                                                               |
    +-------------------------------+-------------------------------+
    /                                                               /
    \                                                               \
    /                                                               /
    +-------------------------------+-------------------------------+
    |                                                               |
    |                   Peer entry n (see below)                    |
    | 0x1  |0|0|0|0|0|0|0|R|        Message Length         |
    +-------------------------------+-------------------------------+

    The 'responseIndication' flag shall be set to 0x2 to indicate a
    rejection
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's Server ID param (optional)            :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The receiving server's ID does not need to the request, and no 'Peer entry' shall be attached included if the request
    message is rejected.

    Otherwise, the 'responseIndication' being multicasted.

    "Reply_required" (R) flag shall be set to 0x1 and n
    'Peer entries' attached.

    Each 'Peer entry' shall consist of the following fields:

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Peer's IP address                       |
    +-------------------------------+-------------------------------+
    |       Peer's SCTP port        |         padding               |
    +-------------------------------+-------------------------------+
    |                     Caretaker's IP address                    |
    +-------------------------------+-------------------------------+
    |     caretaker's SCTP port     |         padding               |
    +-------------------------------+-------------------------------+

    The peer's IP address and port number serve as the identification of
    that peer. If the peer '1' if response to this
    message is inactive, its caretaker's IP address and
    port number shall be filled in. Otherwise, the caretaker IP and port
    fields shall be required, otherwise set to zeros.

3.8 TAKEOVER_INITIATE '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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        ENRP server message identifier #1 = 0x27047729         |
    +-------------------------------+-------------------------------+
    |        ENRP server message identifier #2 = 0x53829149         |
    +-------------------------------+-------------------------------+
    |   Type = 0x106                            |
    +-------------------------------+-------------------------------+
    |                 sending server's IP address                   |
    +-------------------------------+-------------------------------+
    |      sender's SCTP port       |         padding               |
    +-------------------------------+-------------------------------+
    |                receiving server's IP address                  |
    +-------------------------------+-------------------------------+
    |      receiver's SCTP port     |         padding               |
    +-------------------------------+-------------------------------+
    |                   Target server's IP address                  |
    +-------------------------------+-------------------------------+
    |    Target server's SCTP port  |         padding 0x2  |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 address and port do ID does not need to be filled in included if the
    message is being multicasted.

    The 'Target server's IP address and port number MUST be supplied.

3.9 TAKEOVER_INITIATE_RESPONSE

    (Editor's note: we may not support multicast of 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        ENRP server message identifier #1 = 0x27047729         |
    +-------------------------------+-------------------------------+
    |        ENRP server message identifier #2 = 0x53829149         |
    +-------------------------------+-------------------------------+
    |   Type = 0x107                            |
    +-------------------------------+-------------------------------+
    |                 sending server's IP address                   |
    +-------------------------------+-------------------------------+
    |      sender's SCTP port       |         padding               |
    +-------------------------------+-------------------------------+
    |                receiving server's IP address                  |
    +-------------------------------+-------------------------------+ 0x3  |0|0|0|0|0|0|0|M|        Message Length         |      receiver's SCTP port     |         padding               |
    +-------------------------------+-------------------------------+
    |                   Target server's IP address                  |
    +-------------------------------+-------------------------------+
    |    Target server's SCTP port  |         padding               |
    +-------------------------------+-------------------------------+

    The receiving server's address and port do not need
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's 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 to '1' if there are more pool entries to be filled sent
       in
    if the message is being multicasted.

    The 'Target server's IP address and port number subsequent PEER_NAME_TABLE_RESPONSE messages. Otherwise, it
       shall be set to '0'.

    Pool entries:

       At least one pool entry MUST be supplied.

3.10 TAKEOVER_PEER_SERVER present in the message. Each
       pool entry MUST start with 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        ENRP server message identifier #1 = 0x27047729         |
    +-------------------------------+-------------------------------+
    |        ENRP server message identifier #2 = 0x53829149         |
    +-------------------------------+-------------------------------+
    |   Type = 0x108                            |
    +-------------------------------+-------------------------------+
    |                 sending server's IP address                   |
    +-------------------------------+-------------------------------+
    |      sender's SCTP port       |         padding               |
    +-------------------------------+-------------------------------+
    |                receiving server's IP address                  |
    +-------------------------------+-------------------------------+
    |      receiver's SCTP port     |         padding               |
    +-------------------------------+-------------------------------+
    |                   Target server's IP address                  |
    +-------------------------------+-------------------------------+ 0x4  |0|0|0|0|0|0|0|0|        Message Length         |    Target server's SCTP port
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's Server ID param (optional)            :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                        Pool handle                            :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                        Pool Element                           :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         padding                       Update action                           |
    +-------------------------------+-------------------------------+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The receiving server's address and port do ID does not need to be filled in included if the
    message is being multicasted.

    The 'Target server's IP address and port number MUST be supplied.

3.11 SERVER_DUMP message

    This is an ENRP service/maintainance message sent

    "Update_action" field:

       shall take one of the following values:

       0x0 - ADD_PE: add the PE as a new member to or update the PE in
	     the named pool in the namespace.
       0x1 - DELETE_PE: delete the specified PE from an ENRP
    service console. 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        ENRP endpoint message identifier #1   Type = 0x18038688       |
    +-------------------------------+-------------------------------+ 0x5  |0|0|0|0|0|0|0|0|        Message Length         |        ENRP endpoint message identifier #2 = 0x77734683       |
    +-------------------------------+-------------------------------+
    |                       Type = 0x7                              |
    +-------------------------------+-------------------------------+
    |                                                               |
    |                    Console handle name (32)                   |
    |                                                               |
    +-------------------------------+-------------------------------+
    |                      Dump Type (see below)                    |
    +-------------------------------+-------------------------------+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's Server ID param (optional)            :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The 'Dump Type' field shall take one of the following values:

    0x0 --- HOME_LIST: dump the list of all the home PEs (i.e., PEs
  	    owned by the receiving server) from the local copy of the
  	    namespace.
    0x1 --- REMOTE_LIST: dump server's ID does not need to be included if the list of
    message is being multicasted.

3.2.6 PEER_LIST_RESPONSE message

    This message shall contain all the remote PEs (i.e., PEs
	    NOT owned by the receiving server) from the local copy of
	    the namespace.
    0x2 --- PEER_LIST: dump the list peer information of all the peers known to the
	    receiving sending
    server.

3.12 SERVER_DUMP_RESPONSE message

    This is an ENRP service/maintainance message sent to an ENRP service
    console as a response to a SERVER_DUMP 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        ENRP endpoint message identifier #1 = 0x18038688       |
    +-------------------------------+-------------------------------+
    |        ENRP endpoint message identifier #2 = 0x77734683       |
    +-------------------------------+-------------------------------+
    |   Type = 0x8                              |
    +-------------------------------+-------------------------------+
    |                                                               |
    |                     Console handle name (32)                  |
    |                                                               |
    +-------------------------------+-------------------------------+
    |                      Dump Type (see below)                    |
    +-------------------------------+-------------------------------+ 0x6  |0|0|0|0|0|0|0|R|        Message Length         |                  Number
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                  Sender's Server ID param                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :              Receiver's Server ID parameter                   :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                   ID of Entries = n (see below)            |
    +-------------------------------+-------------------------------+
    |                                                               |
    |                   Dump entry 1 (see below)                    |
    |                                                               |
    +-------------------------------+-------------------------------+
    /                                                               /
    \                                                               \
    /                                                               /
    +-------------------------------+-------------------------------+
    |                                                               |
    |                   Dump entry n (see below)                    |
    |                                                               |
    +-------------------------------+-------------------------------+

    The 'Dump Type' fields shall take the same values as defined in
    Section 3.11.

    When the 'Dump Type' is HOME_LIST or REMOTE_LIST, the 'Number Peer Server #1                        :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                           ...                                 :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                   ID of
    Entries' field Peer Server #n                        :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                Authorization Parameter (optional)             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    "Reject" (R) flag:

        shall be set to '1' if the number sender of pool entries carried in the
    message, and each 'Dump entry' field shall contain this message is rejecting
	a pool entry and
    shall peer list request. In such a case, this message MUST be defined as:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                      Pool handle name (32)                    |
    |                                                               |
    +-------------------------------+-------------------------------+
    |                    number of PEs in pool = m                  |
    +-------------------------------+-------------------------------+
    |                                                               |
    |                           PE #1 (40)                          |
    |                                                               |
    +-------------------------------+-------------------------------+
    /                                                               /
    \                             .....                             \
    /                                                               /
    +-------------------------------+-------------------------------+
    |                                                               |
    |                           PE #m (40)                          |
    |                                                               |
    +-------------------------------+-------------------------------+

    When the 'Dump Type' is PEER_LIST, the 'Number of Entries' field
    shall be the number of peer entries carried in the message, and each
    'Dump entry' field shall contain a peer entry and shall be defined
    as:

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Peer's IP address                       |
    +-------------------------------+-------------------------------+
    |       Peer's SCTP port        |         padding               |
    +-------------------------------+-------------------------------+
    |                     Caretaker's IP address                    |
    +-------------------------------+-------------------------------+
    |     caretaker's SCTP port      |         padding               |
    +-------------------------------+-------------------------------+

    In a peer entry, the peer's IP address and port number serve as the
    identification of that peer. If the sent
	with no peer is inactive, its
    caretaker's IP address and port number shall be filled
    in. Otherwise, the caretaker IP and port fields shall be zeroed out. server ID included.

4. ENRP Operation Procedures

    In this section, we discuss the procedures defined by ENRP. The
    procedures are divided into three two groups, namely the basic ENRP
    operations, fault management,
    operations and control/maintenance fault management procedures.

    Many of the Rserpool events call for message exchanges exchange and other
    activities between both a PE and an ENRP server and the ENRP server
    and its peers. But only the message exchanges exchange and activities between
    the ENRP server and its peers are considered within the ENRP
    protocol definition scope

    Procedures and message formats for communications between a the PE
    and ENRP servers are defined in [ASAP]. However, in order to put
    our discussion in context, we will give brief description of the
    ASAP activities whenever appropreate.

4.1 Basic ENRP Operations

4.1.1 PE Registration

    ENRP server <-> PE:

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

    To register itself with the name space, a PE sends a REGISTRATION
    message over the ENRP client channel to its home ENRP server.

    In the REGISTRATION message, the PE indicates the name of the pool
    it wishes to join, join in a pool handle parameter, and its port number
    and network access address(es) (e.g., a list of
    valid transport addresses with which the PE can be reached), and any load control information. information in
    a PE parameter.

    The ENRP server handles the REGISTRATION message according to the
    following rules:

    1) If the named pool does not exist in the namespace, the ENRP
    server will creates a new pool with that name in the namespace and
    add the PE to the pool as its first PE;

    2) If the named pool already exists in the namespace, but the
    requesting PE is not currently a member of the pool, ENRP server
    will add the PE as a new member to the pool;
    3) If the named pool already exists in the namespace AND the
    requesting PE is already a member of the pool, i.e., a case of
    duplicated registration, the ENRP server will acknowledge
    shall consider this as a re-registration case. The ENRP Server
    shall replace the
    registration request but will not take any further actions; attributes of the existing PE with the
    information carried in the received REGISTRATION message.

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

    In cases 1 and 2 above, the ENRP server will also assume the
    ownership of the requesting PE.

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

    ENRP server <-> Its peers:

    If the registration request is not a duplicate and is granted, granted (i.e., cases 1-3 above),
    the
    home ENRP server MUST take the namespace modification action as
    described in section 4.1.4.1. 4.1.5.1?. Otherwise, no message shall be
    exchanged with its peers.

4.1.2 PE De-registration

    ENRP server <-> PE:

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

    To remove itself from a pool, a PE sends a DEREGISTRATION message
    over the ENRP client channel to its home ENRP server.

    In response, the home ENRP server sends a REGISTRATION_RESPONSE
    message to the PE and indicates in the message body whether the
    request is granted or rejected.

    If the PE is the last one of the named pool, the home ENRP server
    will remove the pool from the namespace as well.

    The ENRP server may reject the de-registration request due to
    reasons such as invalid parameters, etc.

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

    ENRP server <-> peers:

    Once the de-registration request is granted and the PE removed from
    its local copy of the namespace, the home ENRP server MUST take the
    namespace modification action described in section 4.1.4.2. Section 4.1.5.2.

4.1.3 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 policy value.

    However, an existing PE MUST NOT change its access address list
    via re-registration. Instead, to change its address list a PE
    shall de-register itself first and then register with the
    namespace as a new PE.

    A PE can modify its load policy value at any time via
    re-registration. Based on the number of PEs in the pool and the
    pool's load distrbution policy, this operation allows the PE to
    dynamically control its share of inbound messages received by the
    pool (also see Section 4.5.2 in [ASAP] for more on load control).

    ENRP server <-> PE:

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

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

    Upon the reception of this REGISTRATION message, the home ENRP
    server shall follow the same procedures described in Section
    4.1.1.

    ENRP server <-> peers:

    If the REGISTRATION message is accepted, the home ENRP server
    shall take 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 the ASAP protocol and is defined in [ASAP].

    A PE or PU can use the name translation service provided by the ENRP
    server to resolve a pool name to a list of accessible transport
    addresses of existing PEs.

    This requires the PE or PU to send a NAME_REQUEST NAME_RESOLUTION messages to its
    home ENRP server and in the NAME_REQUEST NAME_RESOLUTION message specify the pool
    name to be translated. translated in a Pool Handle parameter.

    If the named pool exits in the namespace, the home ENRP server will
    send back a NAME_INFORMATION NAME_RESOLUTION_RESPONSE message that shall carry a
    list of PE parameters containing all information of the PEs
    currently registered under that pool name. This information may
    include the current load control policy of the pool, policy value
    of each PE, transport address(es) for each PE, etc.

    Otherwise, the ENRP server shall respond with a NAME_UNKNOWN
    message.

    ENRP server <-> peers:

    None.

4.1.4

4.1.5 Server Namespace Update

    This includes a set of update operations used by an ENRP server to
    inform its peer(s) about the addition of a new PE, removal of an
    existing PE, or change of pool or PE properties, etc.

4.1.4.1 Add properties.

4.1.5.1 Add/Update a New PE

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

    An ENRP server shall multicast over the ENRP server channel a
    PEER_NAME_UPDATE message with the appropriate flag Update_action field set to indicate
    to its peers about
    ADD_PE, indicating the addition of the new PE or the update of an
    existing PE to the namespace. The PE and the pool its belongs to
    shall be indicated in the message with a PE parameter and a Pool
    Handle parameter, respectively (see Section 3.2.4).

    Upon the reception of this PEER_NAME_UPDATE message, each of the
    peer ENRP servers shall take the following actions:

    1) If the named pool under which the new PE has been registered (or
    re-registered) does not exist in the peer's local copy of the
    namespace, the peer ENRP server shall create the named pool in its
    local namespace copy and add the PE to it as the first PE. It then
    shall copy in all other attributes of the PE carried in the
    message.

    2) If the named pool already exists in the peer's local copy of the
    namespace,
    namespace AND the PE does not exist, the peer shall add the new PE to
    the pool as a new PE and copy in all attributes of the PE carried
    in the message.

    3) If the named pool exists AND the PE is already a member of the
    pool in its the local copy of the namespace, the peer ENRP server
    shall take no actions.

    4) If replace the new PE is added to its local copy attributes of namespace (i.e., case
    1 or 2 above), the peer ENRP server shall further check whether the PE is located on the same host as the peer ENRP server itself
    does. If so, the peer ENRP server shall assume the ownership of the
    PE, and take with the claim ownership actions described new information
    carried in section
    4.1.4.5.

4.1.4.2 Forceful Removal of the message.

4.1.5.2 Remove a PE

    This procedure is used by an ENRP server to inform its peer(s) to
    remove an existing PE, regardless of the ownership of the PE.

    The

    An ENRP server shall multicast over the ENRP server channel a
    PEER_NAME_UPDATE message with the appropriate flag Update_action field set to instruct
    its peers to forcefully remove
    DELETE_PE, indicating the removal of an existing PE from their local copy of the
    namespace. The PE and the pool its belongs to shall be indicated
    in the message with a PE parameter and a Pool Handle parameter,
    respectively.

    On the reception of this PEER_NAME_UPDATE message, each peer ENRP
    server shall find and remove the PE from its local copy of the
    namespace regardless whether or
    namespace. If the peer does not it has ownership on find the PE.

4.1.4.3 Advisory Removal PE in its local copy of
    the namespace, it SHOULD take no action.

4.1.6 Server Download Namespace from a PE Peer Server

    This operation is used by allows an ENRP server to instruct its peers to
    remove an existing PE on which request and receive a copy
    of the current namespace from one of its peer does not have an ownership.

    An ENRP server shall multicast over the servers.

    This operation is especially useful for a newly started ENRP server channel a
    PEER_NAME_UPDATE message with the appropriate flag set to instruct
    its peers
    to remove the specified PE from initiate its local copy of the namespace, as well as for an
    existing ENRP server to correct namespace _if_ the peer does not own the PE.

    On inconsistency found during
    its operation.

    1) An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message
    directly to one of its peers.

    2) Upon the reception of this PEER_NAME_UPDATE message, a the peer ENRP server shall find and remove the PE from its local copy of
    initiate a download session in which the namespace _if_ it does not own this PE.

4.1.4.4 Update PE Attributes

    This operation is used by an ENRP server to inform its peers shall be sent
    to
    update the attributes of an existing PE.

    An requesting ENRP server shall multicast over in one or more
    PEER_NAME_TABLE_RESPONSE messages.

    If the sending ENRP server channel a
    PEER_NAME_UPDATE message with determines that multiple
    PEER_NAME_TABLE_RESPONSE messages are needed for the session, it
    shall use the appropriate M flag set to instruct
    its peers in each PEER_NAME_TABLE_RESPONSE message to replace
    inform the attributes of an existing PE receiving ENRP server whether or not the data
    in its local
    copy this message is the last piece of the name space.

    On namespace transfer.

    3) During the reception of this PEER_NAME_UPDATE message, a peer downloading, every time the requesting ENRP server
    receives a PEER_NAME_TABLE_RESPONSE message, it shall replace the attributes of the existing PE with transfer the new
    information
    data entries carried in the message if the PE exists in into its local
    copy of namespace
    database, and then check whether or not the name space. data in this message is
    the last piece being transfered. If more data transfer is indicated,
    the specified PE requesting ENRP server shall send another
    PEER_NAME_TABLE_REQUEST message to the same peer to request for the
    next piece whenever it is not found in ready.

    When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE
    message into its local name space copy, namespace database, the peer requesting ENRP
    server shall add the handle each PE following by the steps following steps:

    1) to 2) in Section 4.1.1.

4.1.4.5 Claim Ownership over a PE

    This operation is used by an ENRP server to claim the ownership on a
    specific PE and to inform its peers about its claim.

    ENRP server <-> PE:

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

    An ENRP server shall send an ASAP ENDPOINT_KEEP_ALIVE message to the
    PE. This message will cause the PE to adopt this ENRP server as its
    new home ENRP server (see section 4.10.3 in [ASAP]).

    ENRP server <-> Its peers:

    An ENRP server shall multicast over the ENRP server channel a
    PEER_NAME_UPDATE message with the appropriate flag set to inform its
    peers that it has taken the ownership of the specified PE.

    Upon the reception of this PEER_NAME_UPDATE message, a peer server
    shall check whether it is the current owner of the PE. If so, this
    peer server shall relinquish its ownership on that PE. Otherwise, no
    action is needed.

4.1.4.6 Report PE Communication Failure

    This operation is used by an ENRP server to warn its peers that it
    has noticed a potentially unreachable PE that the server does not
    have ownership on.

    An ENRP server shall multicast over the ENRP server channel a
    PEER_NAME_UPDATE message with the appropriate flag set to indicate
    that the specified PE is potentially unreachable.

    On the reception of this message, each peer ENRP server shall check
    whether it owns the specified PE. If it does, the peer server shall
    increase the <endpoint-report-failures> counter of the specified PE
    by 1. If the value of the <endpoint-report-failures> counter has
    exceeded the protocol parameter Max-Endpoint-Report-Failures, the
    peer server shall remove the PE from its local namespace and take
    actions described in Section 4.1.4.3. If the peer server named pool does not own the specified PE, it shall take no
    action.

4.1.5 PE Change Policy Value

    A PE can modify its load policy value at any time. Based on the
    number of PEs in the pool and the pool's load distrbution policy,
    this operation allows the PE to dynamically control its share of
    inbound messages received by the pool (also see section 4.5.2?? in
    [ASAP] for more on load control).

    ENRP server <-> PE:

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

    A PE normally sends an UPDATE_POLICY_VALUE ASAP message over the
    ENRP client channel to its home ENRP server in order to modify its
    policy value. The new policy value is always indicated in the
    message.

    Upon the reception of this UPDATE_POLICY_VALUE message, the home
    ENRP server will replace the policy value of that PE in its local
    copy of the namespace with the new value indicated in the message.

    ENRP server <-> peers:

    If the above update on its local copy of the namespace is
    successful, the home ENRP server shall take the Update PE Attributes
    actions as described in Section 4.1.4.4.

4.1.6 Server Download Namespace from a Peer Server

    This operation allows an ENRP server to request and receive a copy
    of a portion of the namespace from one of its peer ENRP servers.

    This operation is especially useful for a newly started ENRP server
    to initiate its local copy of the namespace, as well as for an
    existing ENRP server to correct namespace inconsistency found during
    its operation.

    1) An ENRP server shall first send a PEER_NAME_TABLE_REQUEST message
    directly to one of its peers. In the message, it shall indicate
    which portion of the namespace is being requested.

    2) Upon the reception of this message, the peer server shall
    initiate a download session in which the requested portion of the
    namespace shall be sent to the requesting ENRP server 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 set the appropriate flag in each PEER_NAME_TABLE_RESPONSE
    message to inform the receiving ENRP server whether or not the data
    in this message is the last piece of the transfer.

    3) During the downloading, every time the requesting ENRP server
    receives a PEER_NAME_TABLE_RESPONSE message, it shall transfer the
    data entries carried 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. If more data transfer is indicated,
    the requesting ENRP server shall send another
    PEER_NAME_TABLE_REQUEST message to the same peer to request for the
    next piece whenever it is ready.

    When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE
    message into its local namespace database, the requesting ENRP
    server shall follow the same procedures as described in section
    2.1.1.4.1 when parsing through the PEs carrying in the message one
    by one.

4.1.7 Server Monitor Peer Status

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

    If a message of any type is received from a peer, the ENRP server
    shall update that peers status as <active>.  If a message of any
    type is received from a peer previously unknown, the ENRP server
    shall create a record for the new peer and mark the new peer as
    <active>.

4.1.8 Server Download Peer List from a Peer Server

    This operation allows an ENRP server to request from a peer server a
    copy of its internal peer list. This is useful for a new ENRP server
    to initiate its own peer list at startup.

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

    Upon the reception of this message, the peer server shall reply with
    a PEER_LIST_RESPONSE message and include in the message body a copy
    of its peer list, consisting of all the ENRP servers known by the
    peer togather with their status.

    If the peer itself is in the process of startup, it shall response
    with a PEER_LIST_RESPONSE message but set the appropriate flag to
    indicate that it can not grant the PEER_LIST_REQUEST. In such a
    case, the requesting ENRP server shall select another peer and
    repeat the peer list request with the new peer at a later time.

4.1.9 ENRP Server Initialization

    This section describes the steps a new ENRP server needs to take in
    order to join the other existing ENRP servers for providing the
    namespace service in the operation scope, or initiating the
    namespace service if this is the first ENRP server starting in the
    operation scope.

    1) At startup, before getting into service, the ENRP server
    (initiating server) shall multicast a PEER_PRESENCE message with
    'Reply_required' flag set over the ENRP server channel. This is to
    inform any other existing peers in the operation scope about the
    initiating peer's presence.

    2) Upon the reception of this message, a peer shall send a
    PEER_PRESENCE without 'Reply_required' flag back to the initiating
    server, in order to help the initiating server to build a peer list.

    3) If no response to its PEER_PRESENCE message are received, the
    initiating server shall assume that it is alone in the operation
    scope and shall mark the initialization process as completed. The
    initiation server shall skip the remaining steps and start to offer
    the namespace services.

    4) If there are responses to its PEER_PRESENCE message, the
    initiating server shall then take the actions described in 4.1.8 to
    request a peer list from one of the peers that have responded.

    5) Upon the reception of the PEER_LIST_RESPONSE message from the
    peer, the initiating server shall use the information carried in the
    message to build a complete peer list, including both active and
    inactive peers in the operation scope.

    6) Then, the initiating server shall download the HOME_LIST of the
    namespace from each active peer, as described in 4.1.6.

    Moreover, the initiating server shall also pick one of the active
    peers and request to download the REMOTE_LIST from that peer.

    These downloads once done should allow the initiating server to
    create a complete view of the current namespace.

    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 and Report Unreachable PE

    Two mechanisms exist to detect and report an unreachable PE:

    1) Home ENRP server periodic sanity check

    An ENRP server shall send, in every <Endpoint-sanity-cycle> seconds,
    an ENDPOINT_KEEP_ALIVE message to each of the PE it owns, and shall
    keep the number of consecutive failed send attempts in the counter
    <Endpoint-sanity-failures> of that PE.

    If the value of <Endpoint-sanity-failures> of a PE exceeds the
    pre-set threshold Max-endpoint-sanity-failures, the home ENRP
    server shall remove the PE from its local copy of the namespace
    and take the actions described in section 4.1.4.3 to inform its
    peers.

    The definition and handling of the ENDPOINT_KEEP_ALIVE message by
    the PE are part of ASAP and are described in sections 3.9?? and
    4.10.3?? in [ASAP].

 2) Failure report by peer PE

    Whenever a PE finds a peer PE unreachable (e.g., via an SCTP
    SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the
    former shall send an ENDPOINT_UNREACHABLE message over the ENRP
    client channel to its home ENRP server. The message shall contain
    one of the transport addresses of the unreachable peer PE and have
    the 'Severity' flag set to NORMAL_REPORT in the message.

    The definition and procedure of ENDPOINT_UNREACHABLE message are
    part of ASAP and are described in [ASAP].

    Upon the reception of the ENDPOINT_UNREACHABLE message, the home
    ENRP server shall first check whether it owns the unreachable
    PE. If not, the home ENRP server shall take the actions described
    in section 4.1.4.6.

    If the home ENRP server does own the unreachable PE, it shall
    increase an <Endpoint-report-failures> counter of the unreachable
    PE by 1, and if the value of the <Endpoint-report-failures>
    counter exceeds threshold Max-endpoint-report-failures, the server
    shall remove the PE from its local copy of the namespace and take
    actions described in 4.1.4.3.

4.2.2 ENRP Server Failure Detection by Heartbeat

    An ENRP server shall multicast, in every <Peer-heartbeat-cycle>
    seconds, a PEER_PRESENCE message over the ENRP server channel to
    inform its peers that it is still operational. In the PEER_PRESENCE
    message, the sending ENRP server shall unset the 'Replay_required'
    flag to indicate that no response is required.

    Occassionally, an ENRP server may also send a point-to-point
    PEER_PRESENCE message to a specific peer server, with the
    'Replay_required' flag set in the message, indicating that a
    response is required. In such a case, the receiving peer server 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 Home ENRP Server Hunt

    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 home server hunt procedure.

    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. Moreover, each time the 'Timeout-server-hunt' timer expires
    the criticality should be raised (initially criticality should be
    set to LOW_CRITICALITY).

    Then the PE or PU shall pick one of exist in the local namespace, the
    ENRP servers that have
    responded as its server will creates a new home ENRP server, and send all its subsequent pool with that name in the
    namespace service requests and add the PE to it.

    Upon the reception of pool as the SERVER_HUNT message, an ENRP server shall
    normally reply to first PE;
    2) If the named pool already exists in the local namespace, but
    the PE with a SERVER_HUNT_RESPONSE message, unless
    its peer status information indicates that there is not currently a caretaker member of the pool, ENRP server other than itself for the node where shall
    add the PE resides, AND as a new member to the
    criticality flag pool;

    3) If the named pool already exists in the SERVER_HUNT message local namespace AND
    the requesting PE is not HIGH_CRITICALITY.

4.2.4 already a member of the pool, the ENRP
    server may skip this PE.

4.1.7 Server Detecting and Taking-over Inactive Monitor Peer Status

    An ENRP server shall keep track a record on the time when status of each of its
    known peers. This record is referred to as the last "Peer list" of the
    server.

    An interanl variable <Peer-last-heared> is kept for each peer on
    the peer list and its value updated to the current local time each
    time a message
    (multicast or point-to-point) was of any type is received from each known the peer.

    If a message of any type is received from a peer has not been heard for more than Max-time-last-heard, previously
    unknown, the ENRP server shall send create a point-to-point PEER_PRESENCE with 'Reply
    request' to that peer.

    If the send fails or record for the new peer does not reply after
    Max-time-no-response seconds,
    and add it to the peer list.

4.1.8 Server Download Peer List from a Peer Server

    This operation allows an ENRP server shall initiate the
    following to request from a peer server take-over procedures:

    1) Initiate Server Take-over Arbitration

    The
    a copy of its peer list. This is useful for a new ENRP server (the initiating server) shall to
    initiate a take-over
    arbitration on the inactive its own peer (the target server) by multicasting
    a TAKEOVER_INITIATE message over the list at startup.

    An ENRP server channel. In the
    message, the initiating server shall specify the identification of
    the target server.

    After multicasting the TAKEOVER_INITIATE message, the initiating
    server shall wait for send a TAKEOVER_INITIATE_RESPONSE PEER_LIST_REQUEST message from
    each to a peer to
    request a copy of its active peers. the peer list.

    Upon the reception of this message, other peer servers shall take
    the following actions accordingly:

    A1) If the peer server finds that itself is the target server
	indicated in the TAKEOVER_INITIATE message, it MUST
	immediately multicast shall reply
    with a PEER_PRESENCE PEER_LIST_RESPONSE message over the ENRP
	server channel and include in an attempt to stop the take-over process.

    A2) message body
    a list of server IDs of all known peers.

    If the peer server finds that itself has also initiated a
	take-over process on the same target server AND its IP address is smaller in value than that of the sender of the
	TAKEOVER_INITIATE message, the peer server shall abort its own
	take-over process of startup and perform A3) below.

    A3) Peers other than the target peer and the initiating not ready to
    provide a good peer list, it shall
	mark response with a
    PEER_LIST_RESPONSE message but set the target server as <inactive> and mark R flag in the initiating
	server as message to
    '1' to indicate that it can not grant the caretaker of PEER_LIST_REQUEST. In
    such a case, the target requesting ENRP server shall select another peer
    and reply to repeat the
	initiating server peer list request with the new peer at a TAKEOVER_INITIATE_RESPONSE message.

    A4) Once it has received TAKEOVER_INITIATE_RESPONSE message from
	all of its active peers, later
    time.

4.1.9 Server Initialization

    This section describes the initiating steps a new ENRP server shall consider
	it won the arbitration and shall then needs to take the actions in 2)
	below so as
    order to complete the take-over.

	However, if it receives a PEER_PRESENCE from join the target server
	at any point of other existing ENRP servers for providing the take-over,
    namespace service in the operation scope, or initiating server shall
	immediately abort the take-over process and re-mark
    namespace service if this is the target first ENRP server as <active>.

    2) Take-over starting in the
    operation scope.

    1) At startup, before getting into service, the target peer server

    The initiating ENRP server
    (initiating server) shall multicast a TAKEOVER_PEER_SERVER PEER_PRESENCE message with
    'Reply_required' flag set over the ENRP server channel in order channel. This is to
    inform all its any other existing peers in the operation scope about the take-over.

    In
    initiating peer's presence.

    2) Upon the message, identification reception of the inactive this message, a peer server targeted
    for the take-over MUST be included.

    The initiating server shall mark the target server as <inactive> and
    mark itself as send a
    PEER_PRESENCE without 'Reply_required' flag back to the caretaker of initiating
    server, in order to help the target initiating server in its own to build a peer list.

    Then it shall claim ownership on each of the PEs in

    3) If no response to its local copy
    of PEER_PRESENCE message are received after
    <MAX-TIME-SERVER-HUNT> seconds, the namespace initiating server shall assume
    that it is originally owned by the target server. The
    procedures alone in x.x.x.x. shall be followed when claiming the ownership
    of operation scope and shall mark the PEs.
    initialization process as completed. The initiation server shall finally check whether there are any inactive peers
    (other than
    skip the current target server) which has designated remaining steps and start to offer the
    target server as their caretaker. namespace
    services.

    4) If so, there are responses to its PEER_PRESENCE message, the
    initiating server shall
    perform then take the above ownership take-over procedure on each one of those
    inactive peers as well.

4.2.5 Registration of Remote PEs

    When an ENRP server receives actions described in 4.1.8 to
    request a REGISTRATION message peer list from a PE
    located on a remote machine, it shall always accept and grant the
    registration and assume ownership one of the PE.

    However, if the ENRP server's peer status information indicates peers that have responded.

    5) Upon the peer on reception of the remote machine is inactive AND a caretaker other
    than PEER_LIST_RESPONSE message from the ENRP server itself exists for that machine,
    peer, the ENRP initiating server shall reject use the registration and take no further actions.

    If information carried in the ENRP server has no record about
    message to build a complete peer on that remote node,
    it shall grant list.

    6) Then, the registration as above AND then create initiating server shall request to download a peer
    record in its local peer list about that node, mark copy of
    the new peer as
    inactive, and initiate a take-over procedure on namespace from one of the new peer, as described in section 4.2.4.

4.3 Maintenance 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 by an ENRP maintenance client to
    monitor the name space data detect and perform maintenances on ENRP servers
    in recover from
    various system faults.

4.2.1 Detect and Remove an operation scope.

4.3.1 Forceful Removal of Unreachable PE

    Whenever a PE

    In order to force the removal of finds a peer PE from unreachable (e.g., via an SCTP
    SEND.FAILURE Notification, see section 10.2 of [RFC2960]), the namespace, a
    maintenance client
    former shall send an ENDPOINT_UNREACHABLE message over the ENRP
    client channel to an
    existing its home ENRP server, and in the server. The message shall indicate contain
    the pool handle and one of the transport addresses of the target
    unreachable peer PE in a PE parameter.

    Note: The definition and have the 'Severity' flag
    set to FINAL_REPORT. procedure of ENDPOINT_UNREACHABLE message
    are part of ASAP and are described in [ASAP].

    Upon the reception of this the ENDPOINT_UNREACHABLE message, the home
    ENRP server shall immediately send an ENDPOINT_KEEP_ALIVE message
    to the PE that is reported as unreachable. If this
    ENDPOINT_KEEP_ALIVE fails (i.e., it results in an SCTP
    SEND.FAILURE notification), the ENRP server shall consider the PE
    as truly unreachable and shall remove the target PE from its local copy
    of the namespace and take actions described in Section 4.1.4.2 to inform
    its peers to do the same.

4.3.2 Dump Home PE List

    To require a copy in 4.1.5.2.

    Note: The definition and handling of the information on all ENDPOINT_KEEP_ALIVE
    message by the PEs owned 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 an Heartbeat

    An ENRP
    server, a maintenance client server shall send multicast, in every <PEER-HEARTBEAT-CYCLE>
    seconds, a SERVER_DUMP PEER_PRESENCE message with
    'Dump type' flag set to HOME_LIST over the ENRP server channel to
    inform its peers that it is still operational. In the server.

    Upon receiving this multicasted
    PEER_PRESENCE message, the sending ENRP server shall response with a
    SERVER_DUMP_RESPONSE message with set the 'Dump type'
    'Replay_required' flag set to
    HOME_LIST to '0' indicating that no response is
    required.

    An ENRP server shall keep track the maintenance client, and in time when the last message body,
    include information on all the PEs
    (multicast or point-to-point) was received from each known peer in
    the server currently owns.

4.3.3 Dump Remote PE List

    To require internal variable <Peer-last-heared>.

    If a copy of the information on all peer has not been heard for more than <MAX-TIME-LAST-HEARD>
    seconds, the PEs NOT owned by an ENRP server, a maintenance client server shall send a SERVER_DUMP message point-to-point PEER_PRESENCE
    with 'Dump type' 'Reply_request' flag set to REMOTE_LIST '1' to that peer.

    If the server.

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

    When an ENRP server receives a
    SERVER_DUMP_RESPONSE PEER_PRESENCE message with the 'Dump type'
    'Reply_request' flag set to
    REMOTE_LIST '1', it MUST immediately respond to
    the maintenance client, and in the sender with its own point-to-point PEER_PRESENCE message body,
    include information on all the PEs
    without setting the server currently does NOT
    own.

4.3.4 Dump Peer 'Replay_required' flag.

4.2.3 PE or PU Discover Home ENRP Server List

    To require a copy

    This action is part of the peer list known to a specific ENRP server
    (this list most likely will also represent ALL the active ASAP protocol and
    inactive ENPR servers is defined in the operation scope), a maintenance client
    shall [ASAP].

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

    Upon receiving this message,

    In the home server hunt procedure, the PE or PU shall response with multicast a
    SERVER_DUMP_RESPONSE
    SERVER_HUNT message with the 'Dump type' flag set to
    PEER_SERVER_LIST to over the maintenance client, ENRP client channel, and in the shall repeat
    sending this message body,
    include information on all the peers that server currently knows.

5.  Variables, Time Constants, and Thresholds

    The following is every <TIMEOUT-SERVER-HUNT> seconds until a summary of the variables, time values, and
    pre-set thresholds used in ASAP and
    SERVER_HUNT_RESPONSE message is received from an ENRP protocol.

5.1 Variables

    Endpoint-report-failures --- per registered PE, this keeps server.

    Then the
    number PE or PU shall pick one of unreachable reports concerning the PE.

    Endpoint-sanity-failures --- per registered PE; ENRP servers that have
    responded as its new home ENRP server, and send all its subsequent
    the namespace service requests to this keeps new home server.

    Upon the
    number reception of failed sanity message send attempts concerning the PE.

    Peer-server-last-heard --- per peer SERVER_HUNT message, an ENRP server; this is server shall
    reply to the PE with a time
    stamp on when SERVER_HUNT_RESPONSE message.

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 was received from this peer server. the peer).

5.2 Timer Constants

    Endpoint-sanity-cycle ---

    <PEER-HEARTBEAT-CYCLE> - the period for a home ENRP server to start
    a new round of PE sanity check.

    Peer-heartbeat-cycle ---the period for an ENRP server to send out a
			     heartheat message to its known peers.

5.3 Thresholds

    Max-endpoint-sanity-failures --- pre-set threshold for
    Endpoint-sanity-failures.

    Max-endpoint-report-failures ---
			     (Default=30 secs.)

    <MAX-TIME-LAST-HEARD> - pre-set threshold for
    Endpoint-report-failures.

    Max-time-last-heard --- 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
    Peer-server-last-heard.

    Max-time-no-response --- pre-set threshold how long a message
			     sender will wait for a peer server to
    answer response after
			     sending out a PEER_PRESENCE message with reply required.

    Timeout-server-hunt --- message. (Default=5 secs.)

    <TIMEOUT-SERVER-HUNT> - pre-set threshold for how long a PE sender
			    will wait for the REGISTRATION_RESPONSE from its home ENRP server. before sending another
			    SERVER_HUNT message out. (Default=5 secs.)

6. Security COnsiderations

   [TBD]

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

    [RSERPOOL1] 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>, work in progress.

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

7.

8. Acknowledgements

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

8.

9.  Authors' Addresses

   Randall R. Stewart
   24 Burning Bush Trail.
   Crystal Lake, IL 60012
   USA

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

   Qiaobing Xie
   Motorola, Inc.
   1501 W. Shure Drive, #2309
   Arlington Heights, IL 60004
   USA

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

                    Expires in six months from June Nov. 2001