[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-xie-rserpool-enrp) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 RFC 5353

Network Working Group                                             Q. Xie
Internet-Draft                                                  Motorola
Expires: December 8, 2004                                     R. Stewart
                                                                    Cisco
                                                              M. Stillman
                                                                    Nokia
                                                             June 9, 2004


                 Endpoint Name Resolution Protocol (ENRP)
                     draft-ietf-rserpool-enrp-08.txt

Status of this Memo

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    and any of which I become aware will be disclosed, in accordance with
    RFC 3668.

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

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

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

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

    This Internet-Draft will expire on December 8, 2004.

Copyright Notice

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

Abstract

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



Xie, et al.             Expires December 8, 2004                [Page 1]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    bookkeeping, retrieving, and distributing pool operation and
    membership information.

Table of Contents

    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
      1.1  Definitions  . . . . . . . . . . . . . . . . . . . . . . .   4
    2.   Conventions  . . . . . . . . . . . . . . . . . . . . . . . .   6
    3.   ENRP Message Definitions . . . . . . . . . . . . . . . . . .   7
      3.1  PEER_PRESENCE message  . . . . . . . . . . . . . . . . . .   7
      3.2  PEER_NAME_TABLE_REQUEST message  . . . . . . . . . . . . .   9
      3.3  PEER_NAME_TABLE_RESPONSE message . . . . . . . . . . . . .   9
      3.4  PEER_NAME_UPDATE message . . . . . . . . . . . . . . . . .  11
      3.5  PEER_LIST_REQUEST message  . . . . . . . . . . . . . . . .  12
      3.6  PEER_LIST_RESPONSE message . . . . . . . . . . . . . . . .  13
      3.7  PEER_INIT_TAKEOVER message . . . . . . . . . . . . . . . .  14
      3.8  PEER_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . .  15
      3.9  PEER_TAKEOVER_SERVER message . . . . . . . . . . . . . . .  15
      3.10   PEER_OWNERSHIP_CHANGE message  . . . . . . . . . . . . .  16
      3.11   PEER_ERROR message . . . . . . . . . . . . . . . . . . .  18
    4.   ENRP Operation Procedures  . . . . . . . . . . . . . . . . .  19
      4.1  Methods for Communicating amongst ENRP Servers . . . . . .  19
      4.2  ENRP Server Initialization . . . . . . . . . . . . . . . .  20
        4.2.1  Generate a Server Identifier . . . . . . . . . . . . .  21
        4.2.2  Acquire Peer Server List . . . . . . . . . . . . . . .  21
        4.2.3  Download ENRP Namespace Data from Mentor Peer  . . . .  23
      4.3  Handle PE Registration . . . . . . . . . . . . . . . . . .  25
        4.3.1  Rules on PE Re-registration  . . . . . . . . . . . . .  27
      4.4  Handle PE De-registration  . . . . . . . . . . . . . . . .  28
      4.5  Pool Handle Translation  . . . . . . . . . . . . . . . . .  28
      4.6  Server Namespace Update  . . . . . . . . . . . . . . . . .  29
        4.6.1  Announcing Addition or Update of PE  . . . . . . . . .  29
        4.6.2  Announcing Removal of PE . . . . . . . . . . . . . . .  30
      4.7  Detecting and Removing Unreachable PE  . . . . . . . . . .  31
      4.8  Helping PE and PU to Discover Home ENRP Server . . . . . .  32
      4.9  Maintaining Peer List and Monitoring Peer Status . . . . .  32
        4.9.1  Discovering New Peer . . . . . . . . . . . . . . . . .  32
        4.9.2  Server Sending Heartbeat . . . . . . . . . . . . . . .  32
        4.9.3  Detecting Peer Server Failure  . . . . . . . . . . . .  33
      4.10   Taking-over a Failed Peer Server . . . . . . . . . . . .  33
        4.10.1   Initiate Server Take-over Arbitration  . . . . . . .  33
        4.10.2   Take-over Target Peer Server . . . . . . . . . . . .  34
      4.11   Namespace Data Auditing and Re-synchronization . . . . .  35
        4.11.1   Auditing Procedures  . . . . . . . . . . . . . . . .  35
        4.11.2   PE Checksum Calculation Algorithm  . . . . . . . . .  36
        4.11.3   Re-synchronization Procedures  . . . . . . . . . . .  37
      4.12   Handling Unrecognized Message or Unrecognized
             Parameter  . . . . . . . . . . . . . . . . . . . . . . .  37



Xie, et al.             Expires December 8, 2004                [Page 2]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    5.   Variables and Thresholds . . . . . . . . . . . . . . . . . .  39
      5.1  Variables  . . . . . . . . . . . . . . . . . . . . . . . .  39
      5.2  Thresholds . . . . . . . . . . . . . . . . . . . . . . . .  39
    6.   Security Considerations  . . . . . . . . . . . . . . . . . .  40
      6.1  Implementing Security Mechanisms . . . . . . . . . . . . .  41
    7.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  43
    8.   References . . . . . . . . . . . . . . . . . . . . . . . . .  44
    8.1  Normative References . . . . . . . . . . . . . . . . . . . .  44
    8.2  Informative References . . . . . . . . . . . . . . . . . . .  45
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  45
         Intellectual Property and Copyright Statements . . . . . . .  46








































Xie, et al.             Expires December 8, 2004                [Page 3]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


1.  Introduction

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

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

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

1.1  Definitions

    This document uses the following terms:

    Operation scope: See [3];

    Pool (or server pool): See [3];

    Pool handle (or pool name): See [3];

    Pool element (PE): See [3];

    Pool user (PU): See [3];

    Pool element handle: See [3];

    ENRP namespace (or namespace): See [3];

    ENRP namespace server (or ENRP server): See [3];

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

    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;

    Home ENRP server: The ENRP server to which a PE or PU currently
       belongs.  A PE MUST only have one home ENRP server at any given
       time and both the PE and its home ENRP server MUST keep track of



Xie, et al.             Expires December 8, 2004                [Page 4]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


       this master/slave relationship between them.  A PU SHOULD select
       one of the available ENRP servers as its home ENRP server, but the
       ENRP server does not need to know, nor does it need to keep track
       of this relationship.















































Xie, et al.             Expires December 8, 2004                [Page 5]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


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













































Xie, et al.             Expires December 8, 2004                [Page 6]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


3.  ENRP Message Definitions

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

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

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

    For ENRP, the following message types are defined:

          Type       Message Name
          -----      -------------------------
          0x0       - (reserved by IETF)
          0x1       - PEER_PRESENCE
          0x2       - PEER_NAME_TABLE_REQUEST
          0x3       - PEER_NAME_TABLE_RESPONSE
          0x4       - PEER_NAME_UPDATE
          0x5       - PEER_LIST_REQUEST
          0x6       - PEER_LIST_RESPONSE
          0x7       - PEER_INIT_TAKEOVER
          0x8       - PEER_INIT_TAKEOVER_ACK
          0x9       - PEER_TAKEOVER_SERVER
          0xa       - PEER_OWNERSHIP_CHANGE
          0xb       - PEER_ERROR
          0xc-0xFF  - (reserved by IETF)


3.1  PEER_PRESENCE message

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













Xie, et al.             Expires December 8, 2004                [Page 7]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x1  |0|0|0|0|0|0|0|R|     Message Length = 0xC      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sender Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Receiver Server's ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                      PE Checksum Param                        :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :               Server Information Param (optional)             :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       R (reply_required) flag: 1 bit

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

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

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

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

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

       PE Checksum Parameter:

          This is a TLV that contains the latest PE checksum of the ENRP
          server who sends the PEER_PRESENCE.  This parameter SHOULD be
          included for namespace consistency auditing.  See Section
          4.11.1 for details.

       Server Information Parameter:

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

    Note, at startup an ENRP server MUST pick a randomly generated,



Xie, et al.             Expires December 8, 2004                [Page 8]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    non-zero 32-bit unsigned integer as its ID and MUST use this same ID
    for its entire life.

3.2  PEER_NAME_TABLE_REQUEST message

    An ENRP server sends this message to one of its peers to request a
    copy of the namespace data.  This message is normally used during
    server initialization or namespace re-synchronization.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x2  |0|0|0|0|0|0|0|W|    Message Length = 0xC       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sender Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Receiver Server's ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



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

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

       Sender Server's ID:

          See Section 3.1.

       Receiver Server's ID:

          See Section 3.1.


3.3  PEER_NAME_TABLE_RESPONSE message














Xie, et al.             Expires December 8, 2004                [Page 9]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x3  |0|0|0|0|0|0|R|M|        Message Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sender Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Receiver Server's ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
       :                     Pool entry #1 (see below)                 :
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
       :                              ...                              :
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
       :                     Pool entry #n (see below)                 :
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       R (Reject) flag: 1 bit

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

       M (More_to_send) flag: 1 bit

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

       Message Length: 16 bits (unsigned integer)

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

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

       Sender Server's ID:

          See Section 3.1.





Xie, et al.             Expires December 8, 2004               [Page 10]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


       Receiver Server's ID:

          See Section 3.1.

       Pool entry #1-#n:

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

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


3.4  PEER_NAME_UPDATE message


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x4  |0|0|0|0|0|0|0|0|        Message Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Update Action          |        (reserved)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sender Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Receiver Server's ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                        Pool handle                            :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                        Pool Element                           :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       Message Length: 16 bits (unsigned integer)

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



Xie, et al.             Expires December 8, 2004               [Page 11]


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

       Update Action: 16 bits (unsigned integer)

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

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

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

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

       Reserved: 16 bits

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

       Sender Server's ID:

          See Section 3.1.

       Receiver Server's ID:

          See Section 3.1.

       Pool handle:

          Specifies to which the PE belongs.

       Pool Element:

          Specifies the PE.


3.5  PEER_LIST_REQUEST message

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











Xie, et al.             Expires December 8, 2004               [Page 12]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x5  |0|0|0|0|0|0|0|0|    Message Length = 0xC       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sender Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Receiver Server's ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       Sender Server's ID:

          See Section 3.1.

       Receiver Server's ID:

          See Section 3.1.


3.6  PEER_LIST_RESPONSE message

    This message is used to respond a PEER_LIST_REQUEST.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x6  |0|0|0|0|0|0|0|R|        Message Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sender Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Receiver Server's ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                   Server Info Param of Peer #1                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                           ...                                 :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                   Server Info Param of Peer #n                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       R (Reject) flag: 1 bit

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



Xie, et al.             Expires December 8, 2004               [Page 13]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


          with no peer server ID included.

       Message Length: 16 bits (unsigned integer)

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

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

       Sender Server's ID:

          See Section 3.1.

       Receiver Server's ID:

          See Section 3.1.

       Server Information Parameter of Peer #1-#n:

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


3.7  PEER_INIT_TAKEOVER message

    This message is used by an ENRP server (the takeover initiator) to
    declare its intention of taking over a specific peer ENRP server.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x7  |0|0|0|0|0|0|0|0|        Message Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sender Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Receiver Server's ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Target Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       Sender Server's ID:

          See Section 3.1.




Xie, et al.             Expires December 8, 2004               [Page 14]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


       Receiver Server's ID:

          See Section 3.1.

       Target Server's ID:

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


3.8  PEER_INIT_TAKEOVER_ACK message

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


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x8  |0|0|0|0|0|0|0|0|        Message Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sender Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Receiver Server's ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Target Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       Sender Server's ID:

          See Section 3.1.

       Receiver Server's ID:

          See Section 3.1.

       Target Server's ID:

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


3.9  PEER_TAKEOVER_SERVER message

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



Xie, et al.             Expires December 8, 2004               [Page 15]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    takeover is underway.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0x9  |0|0|0|0|0|0|0|0|        Message Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sender Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Receiver Server's ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Target Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       Sender Server's ID:

          See Section 3.1.

       Receiver Server's ID:

          See Section 3.1.

       Target Server's ID:

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


3.10  PEER_OWNERSHIP_CHANGE message

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















Xie, et al.             Expires December 8, 2004               [Page 16]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0xa  |0|0|0|0|0|0|0|0|        Message Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sender Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Receiver Server's ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                       Pool handle #1                          :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :              PE Identifier Param #1 of pool #1                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                              ...                              :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :              PE Identifier Param #k of pool #1                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                                                               :
       :                              ...                              :
       :                                                               :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                       Pool handle #M                          :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :              PE Identifier Param #1 of pool #M                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                              ...                              :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :              PE Identifier Param #n of pool #M                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       Sender Server's ID:

          See Section 3.1.

       Receiver Server's ID:

          See Section 3.1.

       Pool handles and PE Identifier parameters:

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






Xie, et al.             Expires December 8, 2004               [Page 17]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


3.11  PEER_ERROR message

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


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Type = 0xb  |0|0|0|0|0|0|0|0|        Message Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Sender Server's ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Receiver Server's ID                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                   Operation Error Parameter                   :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       Sender Server's ID:

          See Section 3.1.

       Receiver Server's ID:

          See Section 3.1.

       Operation Error Parameter:

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



















Xie, et al.             Expires December 8, 2004               [Page 18]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


4.  ENRP Operation Procedures

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

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

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

4.1  Methods for Communicating amongst ENRP Servers

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

    Two types of communications are used amongst ENRP servers:

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

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

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

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

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

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

    2.  The sending server sends multiple copies of the announcement, one
        to each of its peer servers, over a set of point-to-point SCTP
        associations between the sending server and the peers.

        This approach guarantees the reliable reception of the message.
        When needed, data security can be achieved by using IP security



Xie, et al.             Expires December 8, 2004               [Page 19]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


        mechanisms such as IPsec [9] or TLS [8].

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

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

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

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

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

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

        A.  MUST subscribe to the well-known server multicast channel to
            ready itself for receiving peers' multicast announcements,

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

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

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


4.2  ENRP Server Initialization

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





Xie, et al.             Expires December 8, 2004               [Page 20]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


4.2.1  Generate a Server Identifier

    A new ENRP server MUST generate a non-zero, 32-bit server Id that is
    as unique as possible in the operation scope and this server Id MUST
    remain unchanged for the lifetime of the server.  Normally, a good
    32-bit random number will be good enough as the server Id ([12]
    provides some information on randomness guidelines).

    Note, there is a very remote chance (about 1 in 4 billion) that two
    ENRP servers in an operation scope will generate the same server Id
    and hence cause a server Id conflict in the pool.  However, no severe
    consequence of such a conflict has been identified.

4.2.2  Acquire Peer Server List

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

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

4.2.2.1  Find the mentor server

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

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

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

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

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




Xie, et al.             Expires December 8, 2004               [Page 21]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


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

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

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

    5.  If the initiating server determined that it is alone in the
        scope, it MUST skip the procedures in Section 4.2.2.2 and Section
        4.2.3 and MUST consider its initialization completed and start
        offering ENRP services.

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

    Note, if the administratively specified mentor peer(s) fails, the
    initiating server SHOULD use the auto-discover procedure defined in
    steps 1-5 above.

4.2.2.2  Request complete server list from mentor peer

    Once the initiating server finds its mentor peer server (by either
    discovery or administrative means), the initiating server MUST send a
    PEER_LIST_REQUEST message to the mentor peer server to request a copy
    of the complete server list maintained by the mentor peer (see
    Section 4.9 for maintaining server list).

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

    Upon the reception of the PEER_LIST_RESPONSE message from the mentor
    peer, the initiating server MUST use the server information carried
    in the message to initialize its own peer list.

    However, if the mentor itself is in the process of startup and not



Xie, et al.             Expires December 8, 2004               [Page 22]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    ready to provide a peer server list (for example, the mentor peer is
    waiting for a response to its own PEER_LIST_REQUEST to another
    server), it MUST reject the request by the initiating server and
    respond with a PEER_LIST_RESPONSE message with the R flag set to '1',
    and with no server information included in the response.

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

4.2.3  Download ENRP Namespace Data from Mentor Peer

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

    1.  The initiating server MUST first send a PEER_NAME_TABLE_REQUEST
        message to the mentor peer, with W flag set to '0', indicating
        that the entire namespace is requested.

    2.  Upon the reception of this message, the mentor peer MUST start a
        download session in which a copy of the current namespace data
        maintained by the mentor peer is sent to the initiating server in
        one or more PEER_NAME_TABLE_RESPONSE messages (Note, the mentor
        server may find it particularly desirable to use multiple
        PEER_NAME_TABLE_RESPONSE messages to send the namespace when the
        namespace is large, especially when forming and sending out a
        single response containing a large namespace may interrupt its
        other services).

        If more than one PEER_NAME_TABLE_RESPONSE message are used during
        the download, the mentor peer MUST use the M flag in each
        PEER_NAME_TABLE_RESPONSE message to indicate whether this message
        is the last one for the download session.  In particular, the
        mentor peer MUST set the M flag to '1' in the outbound
        PEER_NAME_TABLE_RESPONSE if there is more data to be transferred
        and MUST keep track of the progress of the current download
        session.  The mentor peer MUST set the M flag to '0' in the last
        PEER_NAME_TABLE_RESPONSE for the download session and close the
        download session (i.e., removing any internal record of the
        session) after sending out the last message.

    3.  During the downloading, every time the initiating server receives
        a PEER_NAME_TABLE_RESPONSE message, it MUST transfer the data
        entries carried in the message into its local namespace database,
        and then check whether or not this message is the last one for



Xie, et al.             Expires December 8, 2004               [Page 23]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


        the download session.

        If the M flag is set to '1' in the just processed
        PEER_NAME_TABLE_RESPONSE message, the initiating server MUST send
        another PEER_NAME_TABLE_REQUEST message to the mentor peer to
        request for the next PEER_NAME_TABLE_RESPONSE message.

    4.  When unpacking the data entries from a PEER_NAME_TABLE_RESPONSE
        message into its local namespace database, the initiating server
        MUST handle each pool entry carried in the message using the
        following rules:

        A.  If the pool does not exist in the local namespace, the
            initiating server MUST creates the pool in the local
            namespace and add the PE(s) in the pool entry to the pool.

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

        B.  If the pool already exists in the local namespace, but the
            PE(s) in the pool entry is not currently a member of the
            pool, the initiating server MUST add the PE(s) to the pool.

        C.  If the pool already exists in the local namespace AND the
            PE(s) in the Pool entry is already a member of the pool, the
            initiating server SHOULD replace the attributes of the
            existing PE(s) with the new information.

    5.  When the last PEER_NAME_TABLE_RESPONSE message is received from
        the mentor peer and unpacked into the local namespace, the
        initialization process is completed and the initiating server
        SHOULD start to provide ENRP services.

    Under certain circumstances, the mentor peer itself may not be able
    to provide a namespace download to the initiating server.  For
    example, the mentor peer is in the middle of initializing its own
    namespace database, or it has currently too many download sessions
    open to other servers.

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

    In the case where its PEER_NAME_TABLE_REQUEST is rejected by the
    mentor peer, the initiating server SHOULD either wait for a few
    seconds and re-send the PEER_NAME_TABLE_REQUEST to the mentor server,



Xie, et al.             Expires December 8, 2004               [Page 24]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    or if there is a backup mentor peer available, select another mentor
    peer server and send the PEER_NAME_TABLE_REQUEST to the new mentor
    server.

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

    Similarly, after sending out a PEER_NAME_TABLE_RESPONSE, if the
    mentor peer has still more data to send, it SHOULD start a session
    timer.  If this timer expires without receiving another request from
    the initiating server, the mentor peer SHOULD abort the session,
    cleaning out any resource and record of the session.

4.3  Handle PE Registration

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

    In the REGISTRATION message, the PE indicates the name of the pool it
    wishes to join in a pool handle parameter, and its complete transport
    information and any load control 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 MUST creates a new pool with that name in the namespace
        and add the PE to the pool as its first PE;

        When a new pool is created, the overall member selection policy
        of the pool MUST be set to the policy type indicated by the first
        PE, the overall pool transport type MUST be set to the transport
        type indicated by the PE, and the overall pool data/control
        channel configuration MUST be set to what is indicated in the
        Transport Use field of the User Transport parameter by the
        registering PE.

    2.  If the named pool already exists in the namespace, but the
        requesting PE is not currently a member of the pool, the ENRP
        server will add the PE as a new member to the pool;

        However, before adding the PE to the pool, the server MUST check



Xie, et al.             Expires December 8, 2004               [Page 25]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


        if the policy type, transport type, and transport usage indicated
        by the registering PE is consistent with those of the pool.  If
        different, the ENRP server MUST either attempt to override the
        PE's value(s) or to reject the registration if overriding is not
        possible.

        A.  Inconsistent policy - If no additional policy-related
            information are required to perform an override of pool
            policy (e.g., overriding Least-used with Round-robin does not
            require additional policy-related information), the ENRP
            server MUST replace the PE's policy type with the overall
            policy type of the pool.  However, if additional policy
            information is required for the overriding (e.g., overriding
            Round-robin with Least-load will require the knowledge of the
            load factor of the PE), the ENRP server MUST reject the
            registration.

        B.  Inconsistent transport type - The ENRP server MUST reject the
            registration.

        C.  Inconsistent data/control configuration - If the overall pool
            configuration is "DATA ONLY", and the registering PE
            indicates "CONTORL plus DATA", the ENRP server SHOULD accept
            the registration but warn the PE that control channel cannot
            be used.  If the pool configuration is "CONTROL plus DATA"
            and the PE indicates "DATA ONLY", the ENRP server MUST reject
            the registration.

    3.  If the named pool already exists in the namespace AND the
        requesting PE is already a member of the pool, the ENRP server
        SHOULD consider this as a re-registration case.  The ENRP server
        MUST perform the same tests on policy, transport type, transport
        use, as described above.  If the re-registration is accepted
        after the test, the ENRP Server SHOULD replace the attributes of
        the existing PE with the information carried in the received
        REGISTRATION message.

    4.  After accepting the registration, the ENRP server MUST assign
        itself the owner of this PE.  If this is a re-registration, the
        ENRP server MUST take over ownership of this PE regardless of
        whether the PE was previously owned by this server or by another
        server.

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

    In all above cases, the ENRP server MUST reply to the requesting PE
    with a REGISTRATION_RESPONSE message.  If the registration is



Xie, et al.             Expires December 8, 2004               [Page 26]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    accepted, the ENRP server MUST set the 'R' flag in the
    REGISTRATION_RESPONSE to '0'.  If the registration is rejected, the
    ENRP server MUST indicate the rejection by setting the 'R' flag in
    the REGISTRATION_RESPONSE to '1'.

    If the registration is rejected, the ENRP server SHOULD include the
    proper error cause(s) in the REGISTRATION_RESPONSE message.

    If the registration is granted but with an override of some PE's
    original values, in the REGISTRATION_RESPONSE message the ENRP server
    SHOULD include the proper error cause(s) so that the PE can be warned
    about the overriding and be informed about the new value(s).

    If the registration is granted (either a new registration or a
    re-registration case), the ENRP server MUST assign itself to be the
    home ENRP server of the PE, i.e., to "own" the PE.

       Implementation note: for better performance, the ENRP server may
       find it both efficient and convenient to internally maintain two
       separate PE lists or tables - one is for the PEs that are "owned"
       by the ENRP server and the other for all the PEs owned by its
       peer(s).

    Moreover, if the registration is granted, the ENRP server MUST take
    the namespace update action as described in Section 4.6 to inform its
    peers about the change just made.  If the registration is denied, no
    message will be sent to its peers.

4.3.1  Rules on PE Re-registration

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

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

    Moreover, when re-registering, the PE MUST NOT change its policy
    type.  The server MUST reject the re-registration if the PE attempt
    to change its policy type.  In the rejection, the server SHOULD
    attach an error code "Pooling Policy Inconsistent".

    Regardless whether it is the current owner of the PE, if the
    re-registration is granted to the PE, the ENRP server MUST assign
    itself to be the new home ENRP server of the PE.



Xie, et al.             Expires December 8, 2004               [Page 27]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    Moreover, if the re-registration is granted, the ENRP server MUST
    take the namespace update action as described in Section 4.6 to
    inform its peers about the change just made.  If the re-registration
    is denied, no message will be sent to its peers.

4.4  Handle PE De-registration

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

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

    Upon receiving the message, the ENRP server SHALL remove the PE from
    its namespace.  Moreover, if the PE is the last one of the named
    pool, the ENRP server will remove the pool from the namespace as
    well.

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

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

    In response, the ENRP server MUST send a DEREGISTRATION_RESPONSE
    message to the PE.  If the de-registration is rejected, the ENRP
    server MUST indicate the rejection by including the proper Operation
    Error parameter.

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

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

4.5  Pool Handle Translation

    A PU uses the pool handle translation service of an ENRP server to
    resolve a pool handle to a list of accessible transport addresses of
    the member PEs of the pool.

    This requires the PU to send a NAME_RESOLUTION message to its home



Xie, et al.             Expires December 8, 2004               [Page 28]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    ENRP server and in the NAME_RESOLUTION message specify the pool
    handle to be translated in a Pool Handle parameter.  Complete
    definition of the NAME_RESOLUTION message and the rules of sending it
    are defined in [1].

    An ENRP server SHOULD be prepared to receive NAME_RESOLUTION requests
    from PUs either over an SCTP association on the well-know SCTP port,
    or over a TCP connection on the well-know TCP port.

    Upon reception of the NAME_RESOLUTION message, the ENRP server MUST
    first look up the pool handle in its namespace.  If the pool exits,
    the home ENRP server MUST compose and send back a
    NAME_RESOLUTION_RESPONSE message to the requesting PU.

    In the response message, the ENRP server SHOULD list all the PEs
    currently registered in this pool, in a list of PE parameters.  The
    ENRP server MUST also include a pool member selection policy
    parameter to indicate the overall member selection policy for the
    pool, if the current pool member selection policy is not round-robin
    (if the overall policy is round-Robin, this parameter MAY be
    omitted?).

    If the named pool does not exist in the namespace, the ENRP server
    MUST respond with a NAME_UNKNOWN message.

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

4.6  Server Namespace Update

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

4.6.1  Announcing Addition or Update of PE

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

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

    An ENRP server MUST announce this update to all its peers in a
    PEER_NAME_UPDATE message with the Update Action field set to ADD_PE,
    indicating the addition of a new PE or the modification of an
    existing PE.  The complete new information of the PE and the pool its



Xie, et al.             Expires December 8, 2004               [Page 29]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    belongs to MUST be indicated in the message with a PE parameter and a
    Pool Handle parameter, respectively.

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

    When a peer receives this PEER_NAME_UPDATE message, it MUST take the
    following actions:

    1.  If the named pool indicated by the pool handle does not exist in
        its local copy of the namespace, the peer MUST create the named
        pool in its local namespace and add the PE to the pool as the
        first PE.  It MUST then copy in all other attributes of the PE
        carried in the message.

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

    2.  If the named pool already exists in the peer's local copy of the
        namespace AND the PE does not exist, the peer MUST add the 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, the peer MUST replace the attributes of the PE with the new
        information carried in the message.


4.6.2  Announcing Removal of PE

    When an existing PE is granted de-registration or is removed from its
    namespace for some other reasons (e.g., purging an unreachable PE,
    see Section 4.7), the ENRP server MUST uses this procedure to inform
    all its peers about the change just made.

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

    An ENRP server MUST announce the PE removal to all its peers in a
    PEER_NAME_UPDATE message with the Update Action field set to DEL_PE,
    indicating the removal of an existing PE.  The complete information
    of the PE and the pool its belongs to MUST be indicated in the
    message with a PE parameter and a Pool Handle parameter,
    respectively.

    [editor's note: only the pool handle and the PE's id are needed, it
    should reduce the size of the message]



Xie, et al.             Expires December 8, 2004               [Page 30]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


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

    When a peer receives this PEER_NAME_UPDATE message, it MUST first
    find pool and the PE in its own namespace, and then remove the PE
    from its local namespace.  If the removed PE is the last one in the
    pool, the peer MUST also delete the pool from its local namespace.

    If the peer fails to find the PE or the pool in its namespace, it
    SHOULD take no further actions.

4.7  Detecting and Removing Unreachable PE

    Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE
    Notification, see section 10.2 of [7]), the PU SHOULD send an
    ENDPOINT_UNREACHABLE message to its home ENRP server.  The message
    SHOULD contain the pool handle and the PE Id of the unreachable PE.

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

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

    Optionally, an ENRP server may also periodically send point-to-point
    ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the ENRP
    server in order to check their reachability status.  If the send of
    ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST consider the
    PE as unreachable and MUST remove the PE from its namespace and take
    actions described in Section 4.6.2.  Note, if an ENRP server owns a
    large number of PEs, the implementation should pay attention not to
    flood the network with bursts of ENDPOINT_KEEP_ALIVE messages.
    Instead, the implementation should try to smooth out the
    ENDPOINT_KEEP_ALIVE message traffic over time.

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




Xie, et al.             Expires December 8, 2004               [Page 31]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


4.8  Helping PE and PU to Discover Home ENRP Server

    At its startup time, or whenever its current home ENRP server is not
    providing services, a PE or PU will attempt to find a new home
    server.  For this reason, the PE or PU will need to maintain a list
    of currently available ENRP servers in its scope.

    To help the PE or PU maintaining this list, an ENRP server, if it is
    enabled for multicast, SHOULD periodically send out a SERVER_ANNOUNE
    message every SERVER-ANNOUNCE-CYCLE seconds to the well-known ASAP
    multicast channel.  And in the SERVER_ANNOUNE message the ENRP server
    SHOULD include all the transport addresses available for ASAP
    communications.  If the ENRP server only supports SCTP for ASAP
    communications, the transport information MAY be omitted in the
    SERVER_ANNOUNCE message.

    For the complete procedure of this, see Section 3.6?? in [1].

4.9  Maintaining Peer List and Monitoring Peer Status

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

4.9.1  Discovering New Peer

    If a message of any type is received from a previously unknown peer,
    the ENRP server MUST consider this peer a new peer in the operation
    scope and add it to the peer list.

    The ENRP server MUST send a PEER_PRESENCE message with the
    Reply-required flag set to '1' to the source address found in the
    arrived message.  This will force the new peer to reply with its own
    PEER_PRESENCE containing its full server information (see Section
    3.1).

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

4.9.2  Server Sending Heartbeat

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

    The arrival of this periodic PEER_PRESENCE message will cause all its



Xie, et al.             Expires December 8, 2004               [Page 32]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    peers to update their internal variable "peer.last.heard" for the
    sending server (see Section 4.9.3 for more details).

4.9.3  Detecting Peer Server Failure

    An ENRP server MUST keep an internal variable "peer.last.heard" for
    each of its known peers and the value of this variable MUST be
    updated to the current local time every time a message of any type
    (point-to-point or announcement) is received from the corresponding
    peer.

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

    If the send fails or the peer does not reply after
    MAX-TIME-NO-RESPONSE seconds, the ENRP server MUST consider the peer
    server dead and SHOULD initiate the takeover procedure defined in
    Section 4.10.

4.10  Taking-over a Failed Peer Server

    In the following descriptions, We call the ENRP server that detects
    the failed peer server and initiates the take-over the "initiating
    server" and the failed peer server the "target server."

4.10.1  Initiate Server Take-over Arbitration

    The initiating server SHOULD first start a take-over arbitration
    process by announcing a PEER_INIT_TAKEOVER message to all its peer
    servers.  See Section 4.1 on how announcements are sent.  In the
    message, the initiating server MUST fill in the Sender Server's ID
    and Target Server's ID.

    After announcing the PEER_INIT_TAKEOVER message, the initiating
    server SHOULD wait for a PEER_INIT_TAKEOVER_ACK message from _each_
    of its known peers, except of the target server.  [editor's note: how
    long should it wait?]

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

    1.  If the peer server finds that itself is the target server
        indicated in the PEER_INIT_TAKEOVER message, it MUST immediately
        announce a PEER_PRESENCE message to all its peer ENRP servers in
        an attempt to stop this take-over process.  This indicates a
        false failure detection case by the initiating server.




Xie, et al.             Expires December 8, 2004               [Page 33]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


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

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

        B.  Otherwise, the peer MUST ignore the PEER_INIT_TAKEOVER
            message and take no action.

    3.  If the peer finds that it is neither the target server nor is in
        its own take-over process, the peer SHOULD: a) mark the target
        server as "not active" on its internal peer list so that its
        status will no longer be monitored by this peer, and b) reply to
        the initiating server with a PEER_INIT_TAKEOVER_ACK message.

    Once the initiating server has received PEER_INIT_TAKEOVER_ACK
    message from _all_ of its currently known peers (except for the
    target server), it SHOULD consider that it has won the arbitration
    and SHOULD proceed to complete the take-over, following the steps
    described in Section 4.10.2.

    However, if it receives a PEER_PRESENCE from the target server at any
    point in the arbitration process, the initiating server SHOULD
    immediately abort the take-over process and mark the status of the
    target server as "active".

4.10.2  Take-over Target Peer Server

    The initiating ENRP server SHOULD first send, via an announcement, a
    PEER_TAKEOVER_SERVER message to inform all its active peers that the
    take-over is enforced.  The target server's ID MUST be filled in the
    message.  The initiating server SHOULD then remove the target server
    from its internal peer list.

    [editor's note: peers should remove the target server from their list
    upon receiving this message.  Do we really need this message? we can
    consolidate this with the ownership_change msg.]

    Then it SHOULD examine its local copy of the namespace and claim
    ownership of each of the PEs originally owned by the target server,
    by following these steps:




Xie, et al.             Expires December 8, 2004               [Page 34]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    1.  mark itself as the home ENRP server of each of the PEs originally
        owned by the target server;

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

    3.  after claiming the ownership of all the PEs originally owned by
        the target server, announce the ownership changes of all the
        affected PEs in a PEER_OWNERSHIP_CHANGE message to all the
        currently known peers.  Note, if the list of affected PEs is
        long, the sender MAY announce the ownership changes in multiple
        PEER_OWNERSHIP_CHANGE messages.

    When a peer receives the PEER_OWNERSHIP_CHANGE message from the
    initiating server, it SHOULD find each of the reported PEs in its
    local copy of the namespace and update the PE's home ENRP server to
    be the sender of the message (i.e., the initiating server).

4.11  Namespace Data Auditing and Re-synchronization

    Message losses or certain temporary breaks in network connectivity
    may result in data inconsistency in the local namespace copy of some
    of the ENRP servers in an operation scope.  Therefore, each ENRP
    server in the operation scope SHOULD periodically verify that its
    local copy of namespace data is still in sync with that of its peers.

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

4.11.1  Auditing Procedures

    The auditing of namespace consistency is based on the following
    procedures:

    1.  An ENRP server SHOULD keep a separate PE checksum (a 32-bit
        integer internal variable) for each of its known peers and for
        itself.  For an ENRP server with 'k' known peers, we denote these
        internal variables as "pe.checksum.pr0", "pe.checksum.pr1", ...,
        "pe.checksum.prk", where "pe.checksum.pr0" is the server's own PE
        checksum.  The definition and detailed algorithm for calculating
        these PE checksum variables are given in Section 4.11.2.

    2.  Each time an ENRP server sends out a PEER_PRESENCE, it SHOULD
        include in the message its current PE checksum (i.e.,
        "pe.checksum.pr0").

    3.  When an ENRP server (server A) receives a PE checksum (carried in



Xie, et al.             Expires December 8, 2004               [Page 35]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


        an arrived PEER_PRESENCE) from a peer ENRP server (server B),
        server A SHOULD compare the PE checksum found in the
        PEER_PRESENCE with its own internal PE checksum of server B
        (i.e., "pe.checksum.prB").

    4.  If the two values match, server A will consider that there is no
        namespace inconsistency between itself and server B and should
        take no further actions.

    5.  If the two values do NOT match, server A SHOULD consider that
        there is a namespace inconsistency between itself and server B
        and a re-synchronization process SHOULD be carried out
        immediately with server B (see Section 4.11.3).


4.11.2  PE Checksum Calculation Algorithm

    When an ENRP server (server A) calculate an internal PE checksum for
    a peer (server B), it MUST use the following algorithm.

    Let us assume that in server A's internal namespace there are
    currently 'M' PEs that are owned by server B.  Each of the 'M' PEs
    will then contribute to the checksum calculation with the following
    byte block:

        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 string of the pool the PE belongs (padded with   :
       :  zeros to next 32-bit word boundary if needed)                :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        PE Id (4 octets)                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Note, these are not TLVs.  This byte block gives each PE a unique
    byte pattern in the scope.  The 32-bit PE checksum for server B
    "pe.checksum.prB" is then calculated over the byte blocks contributed
    by the 'M' PEs one by one.

    Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0")
    in the same fashion, using the byte blocks of all the PEs owned by
    itself.

    Note, whenever an ENRP finds that its internal namespace has changed
    (e.g., due to PE registration/deregistration, receiving peer updates,
    removing failed PEs, downloading namespace pieces from a peer, etc.),
    it MUST immediately update all its internal PE checksums that are
    affected by the change.



Xie, et al.             Expires December 8, 2004               [Page 36]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    Implementation Note: when the internal namespace changes (e.g., a new
    PE added or an existing PE removed), an implementation needs not to
    re-calculate the affected PE checksum; it should instead simply
    update the checksum by adding or subtracting the byte block of the
    corresponding PE from the previous checksum value.

4.11.3  Re-synchronization Procedures

    Once an ENRP server determines that there is inconsistency between
    its local namespace data and a peer's namespace data with regarding
    to the PEs owned by that peer, it SHOULD perform the following steps
    to re-synchronize the data:

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

    2.  The ENRP server SHOULD then send a PEER_NAME_TABLE_REQUEST
        message with W flag set to '1' to the peer to request a complete
        list of PEs owned by the peer;

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

    4.  Upon reception of the PEER_NAME_TABLE_RESPONSE message, the ENRP
        server SHOULD transfer the PE entries carried in the message into
        its local namespace database.  If an PE entry being transferred
        already exists in its local database, the ENRP server MUST
        replace the entry with the copy found in the message and remove
        the "mark" from the entry.

    5.  After transferring all the PE entries from the received
        PEER_NAME_TABLE_RESPONSE message into its local database, the
        ENRP server SHOULD check whether there are still PE entries that
        remain "marked" in its local namespace.  If so, the ENRP server
        SHOULD silently remove those "marked" entries.

    Note, similar to what is described in Section 4.2.3, the peer may
    reject the PEER_NAME_TABLE_REQUEST or use more than one
    PEER_NAME_TABLE_RESPONSE message to respond.

4.12  Handling Unrecognized Message or Unrecognized Parameter

    When an ENRP server receives an ENRP message with an unknown message
    type or a message of known type that contains an unknown parameter,
    it SHOULD handle the unknown message or the unknown parameter
    according to the unrecognized message and parameter handling rules



Xie, et al.             Expires December 8, 2004               [Page 37]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    defined in Sections 3 and 4 in [10].

    According to the rules, if an error report to the message sender is
    needed, the ENRP server that discovered the error SHOULD send back an
    ENRP_ERROR message with proper error cause code.














































Xie, et al.             Expires December 8, 2004               [Page 38]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


5.  Variables and Thresholds

5.1  Variables

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

    pe.checksum.pr - the internal 32-bit PE checksum that an ENRP server
       keeps for a peer.  A separate PE checksum is kept for each of its
       known peers as well as for itself.


5.2  Thresholds

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

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

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

    SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a
       SERVER_ANNOUNCE message to all PEs and PUs.  (Default=5 secs.)

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

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

    MAX-BAD-PE-REPORT - the maximal number of unreachability reports on a
       PE that an ENRP server will allow before purging this PE from the
       namespace.  (Default=3)













Xie, et al.             Expires December 8, 2004               [Page 39]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


6.  Security Considerations

    Threats Introduced by Rserpool and Requirements for Security in
    Response to Threats [11] describes the threats to the Rserpool
    architecture in detail and lists the security requirements in
    response to each threat.  From the threats described in this
    document, the security services required for the Rserpool protocol
    are enumerated below.

    Threat 1) PE registration/deregistration flooding or spoofing
    -----------
    Security mechanism in response: ENRP server authenticates the PE

    Threat 2) PE registers with a malicious ENRP server
    -----------
    Security mechanism in response: PE authenticates the ENRP server

    Threat 1 and 2 taken together results in mutual authentication of the
    ENRP server and the PE.

    Threat 3) Malicious ENRP server joins the ENRP server pool
    -----------
    Security mechanism in response: ENRP servers mutually authenticate

    Threat 4) A PU communicates with a malicious ENRP server for name
    resolution
    -----------
    Security mechanism in response: The PU authenticates the ENRP server

    Threat 5) Replay attack
    -----------
    Security mechanism in response: Security protocol which has
    protection from replay attacks

    Threat 6) Corrupted data which causes a PU to have misinformation
    concerning a pool handle resolution
    -----------
    Security mechanism in response: Security protocol which supports
    integrity protection

    Threat 7) Eavesdropper snooping on namespace information
    -----------
    Security mechanism in response: Security protocol which supports data
    confidentiality

    Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP
    server
    -----------



Xie, et al.             Expires December 8, 2004               [Page 40]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    Security mechanism in response: ASAP must control the number of
    endpoint unreachable messages transmitted from the PU to the ENRP
    server.

    Threat 9) Flood of Endpoint_KeepAlive messages to the PE from the
    ENRP server
    -----------
    Security mechanism in response: ENRP server must control the number
    of Endpoint_KeepAlive messages to the PE

    To summarize the threats 1-7 require security mechanisms which
    support authentication, integrity, data confidentiality, protection
    from replay attacks.

    For Rserpool we need to authenticate the following:

       PU <----  ENRP Server (PU authenticates the ENRP server)
       PE <----> ENRP Server (mutual authentication)
       ENRP server <-----> ENRP Server (mutual authentication)

    We do not define any new security mechanisms specifically for
    responding to threats 1-7.  Rather we use existing IETF security
    protocols to provide the security services required.  TLS supports
    all these requirements and MUST be implemented.  The
    TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
    minimum by implementers of TLS for Rserpool.  For purposes of
    backwards compatibility, ENRP SHOULD support
    TLS_RSA_WITH_3DES_EDE_CBC_SHA.  Implementers MAY also support any
    other ciphersuite.

    Threat 8 requires the ASAP protocol to limit the number of
    Endpoint_Unreachable messages (see Section 3.5??? in [1]) to the ENRP
    server.

    Threat 9 requires the ENRP protocol to limit the number of
    Endpoint_KeepAlive messages to the PE (see Section x.y???).

6.1  Implementing Security Mechanisms

    ENRP servers, PEs, PUs MUST implement TLS.  ENRP servers and PEs must
    support mutual authentication.  ENRP servers must support mutual
    authentication among themselves.  PUs MUST authenticate ENRP servers.

    ENRP servers and PEs SHOULD possess a site certificate whose subject
    corresponds to their canonical hostname.  PUs MAY have certificates
    of their own for mutual authentication with TLS, but no provisions
    are set forth in this document for their use.  All Rserpool elements
    that support TLS MUST have a mechanism for validating certificates



Xie, et al.             Expires December 8, 2004               [Page 41]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


    received during TLS negotiation; this entails possession of one or
    more root certificates issued by certificate authorities (preferably
    well-known distributors of site certificates comparable to those that
    issue root certificates for web browsers).

    Implementations MUST support TLS with SCTP as described in RFC3436
    [8] or TLS over TCP as described in RFC2246 [6].  When using TLS/SCTP
    we must ensure that RSerPool does not use any features of SCTP that
    are not available to an TLS/SCTP user.  This is not a difficult
    technical problem, but simply a requirement.  When describing an API
    of the RSerPool lower layer we have also to take into account the
    differences between TLS and SCTP.







































Xie, et al.             Expires December 8, 2004               [Page 42]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


7.  Acknowledgements

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















































Xie, et al.             Expires December 8, 2004               [Page 43]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


8.  References

8.1  Normative References

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

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

    [3]   Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney,
          "Architecture for Reliable Server Pooling",
          draft-ietf-rserpool-arch-07 (work in progress), October 2003.

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

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

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

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

    [8]   Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC
          3436, December 2002.

    [9]   Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On
          the Use of Stream Control Transmission Protocol (SCTP) with
          IPsec", RFC 3554, July 2003.

    [10]  Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
          Server Access Protocol (ASAP) and Endpoint Name Resolution
          (ENRP) common parameters document",
          draft-ietf-rserpool-common-param-06 (work in progress), June
          2004.

    [11]  Stillman, M., "Threats Introduced by Rserpool and Requirements
          for Security in Response to Threats",
          draft-ietf-rserpool-threats-02 (work in progress), Sept 2003.






Xie, et al.             Expires December 8, 2004               [Page 44]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


8.2  Informative References

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


Authors' Addresses

    Qiaobing Xie
    Motorola, Inc.
    1501 W. Shure Drive, 2-F9
    Arlington Heights, IL  60004
    US

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


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

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


    Maureen Stillman
    Nokia
    127 W. State Street
    Ithaca, NY  14850
    US

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















Xie, et al.             Expires December 8, 2004               [Page 45]


Internet-Draft     Endpoint Name Resolution Protocol           June 2004


Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    ietf-ipr@ietf.org.


Disclaimer of Validity

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

    Copyright (C) The Internet Society (2004).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Xie, et al.             Expires December 8, 2004               [Page 46]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/