[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
                                                            R. R. Stewart
                                                            Cisco Systems
                                                              M. Stillman
                                                                    Nokia


Expires in six months                                         May 2, 2002


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

Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026. Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups. Note that other groups may also
   distribute working documents as Internet-Drafts.

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

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


Abstract

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

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


Table Of Contents

   1. Introduction...............................................2
   1.2 Definitions...............................................2
   2. Conventions................................................3
   3. ENRP Message Definitions...................................3
   3.1 PEER_PRESENCE message.....................................4
   3.2 PEER_NAME_TABLE_REQUEST message...........................5
   3.3 PEER_NAME_TABLE_RESPONSE message..........................5
   3.4 PEER_NAME_UPDATE message..................................7
   3.5 PEER_LIST_REQUEST message.................................7
   3.6 PEER_LIST_RESPONSE message................................8

Xie, et al                                                      [Page 1]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

   4. ENRP Operation Procedures..................................9
   4.1 Methods for Communicating amongst ENRP Servers............9
   4.2 ENRP Server Initialization................................10
   4.2.1 Generate a Server Identifier ...........................11
   4.2.2 Acquire Peer Server List................................11
   4.2.2.1 Find the mentor server................................11
   4.2.2.2 Request complete server list from mentor peer.........12
   4.2.3 Download ENRP Namespace Data from mentor Peer...........13
   4.3 Handle PE Registration....................................14
   4.3.1 Rules on PE Re-registration.............................16
   4.4 Handle PE De-registration.................................16
   4.5 Pool Handle Translation...................................17
   4.6 Server Namespace Update...................................17
   4.6.1 Announcing Addition or Update of PE.....................17
   4.6.2 Announcing Removal of PE................................18
   4.7 Detecting and Removing Unreachable PE.....................19
   4.8 Helping PE and PU to Discover Home ENRP Server............19
   4.9 Maintaining Peer List and Monitoring Peer Status..........20
   4.9.1 Discovering New Peer....................................20
   4.9.2 Server Sending Heartbeat................................20
   4.9.3 Detecting Peer Server Failure...........................20
   4.10 Namespace Data Auditing and Re-synchronization...........21
   4.10 Reporting Unrecognized Message
        or Unrecognized Parameter................................21
   5. Protocol Variables and Time Constants......................21
   5.1 Variables.................................................21
   5.2 Timer Constants...........................................21
   6. Security Considerations....................................22
   7. References.................................................22
   7.1 Informative References....................................23
   8. Acknowledgements...........................................23
   9. Authors' Addresses.........................................23



1. Introduction

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

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

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


1.2 Definitions

   This document uses the following terms:

Xie, et al                                                      [Page 2]


Internet Draft        Endpoint Name Resolution Protocol         May 2002


   Operation scope:
        See [RSPL-ARCH].

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

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

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

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

   Pool element handle:
        See [RSPL-ARCH].

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

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

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

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


2. Conventions

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


3. ENRP Message Definitions

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

Xie, et al                                                      [Page 3]


Internet Draft        Endpoint Name Resolution Protocol         May 2002


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

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

   For ENRP, the following message types are defined:

      Type       Message Name
      -----      -------------------------
      0x0       - (reserved by IETF)
      0x1       - PEER_PRESENCE
      0x2       - PEER_NAME_TABLE_REQUEST
      0x3       - PEER_NAME_TABLE_RESPONSE
      0x4       - PEER_NAME_UPDATE
      0x5       - PEER_LIST_REQUEST
      0x6       - PEER_LIST_RESPONSE
      0x7-0x11  - ASAP messages, defined in [ASAP].
      0x12-0xFF - (reserved by IETF)


3.1 PEER_PRESENCE message

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

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

   R (reply_required) flag: 1 bit

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

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

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

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

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


Xie, et al                                                      [Page 4]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

   Note, at startup an ENRP server MUST pick a randomly generated,
   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

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x2  |0|0|0|0|0|0|0|0|    Message Length = 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.3 PEER_NAME_TABLE_RESPONSE message

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

   R (Reject) flag: 1 bit

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

Xie, et al                                                      [Page 5]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

      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.

   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             :
                +---------------------------+



Xie, et al                                                      [Page 6]


Internet Draft        Endpoint Name Resolution Protocol         May 2002


3.4 PEER_NAME_UPDATE message

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

   Message Length: 16 bits (unsigned integer)

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

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

   Update Action: 16 bits (unsigned integer)

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

      0x0 - ADD_PE: add or update the specified PE in the ENRP
            namespace
      0x1 - DEL_PE: delete the specified PE from the ENRP namespace.

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

   Reserved: 16 bits

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

   Sender Server's ID:

      See section 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

Xie, et al                                                      [Page 7]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

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

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

   Sender Server's ID:

      See section 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
      with no peer server ID included.

   Message Length: 16 bits (unsigned integer)

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

   Sender Server's ID:

      See section 3.1.

Xie, et al                                                      [Page 8]


Internet Draft        Endpoint Name Resolution Protocol         May 2002


   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
      [RSPL-PARAM].


4. ENRP Operation Procedures

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

   Many of the Rserpool events call for both server-to-server and
   PU/PE-to-server 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 [ASAP].


4.1 Methods for Communicating amongst ENRP Servers

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

   Two types of communications are used amongst ENRP servers:

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

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

   Point-to-point communication is always carried out over an SCTP
   associaiton between the sending server 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

Xie, et al                                                      [Page 9]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

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

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

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

   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:

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

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

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

       3a) MUST subcribe to the well-known server multicast channel to
           ready itself for receiving peers' multicast announcements,

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

       3c) MUST track internally which peers are multicast-enabled and
           which are not. Note: A 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.

       3d) 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

Xie, et al                                                     [Page 10]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

   namespace service if it is the first ENRP server started in the
   operation scope.


4.2.1 Generate a Server Identifier

   A new ENRP server MUST generate a 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
   ([RFC1750] provides some information on randomness guidelines).


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 menter peers, and skip the remaining steps
   in this subsection.

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

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

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

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


Xie, et al                                                     [Page 11]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

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

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

   5) If the initiating server determined that it is alone in the
      scope, it MUST skip the procedures in Sections 4.2.2.2? to
      4.2.3? and MUST consider its initialization complete and start
      offering ENRP services.

   Note, if multicast is not available (or not allowed for reasons
   such as security concerns) in the operation scope, at least one
   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 menter peer(s) fails, the
   initiating server SHOULD use the auto-discover procedure defined in
   steps 1-5 above.


4.2.2.2 Request complete server list from mentor peer

   Once the initiating server finds its mentor peer server (by either
   discovery or administrative means), the initiating server MUST 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
   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 rejest the request by the initiating server and
   respond with a PEER_LIST_RESPONSE message with the R flag set to
   '1', and with no server information included in the response.

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

Xie, et al                                                     [Page 12]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

   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.

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

      If more than one PEER_NAME_TABLE_RESPONSE message are 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 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:

      4a) 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.


Xie, et al                                                     [Page 13]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

      4b) 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.

      4c) 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 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 rejest 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, 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 everytime 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 [ASAP].

   In the REGISTRATION message, the PE indicates the name of the pool

Xie, et al                                                     [Page 14]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

   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.

   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;

   After adding the PE to the pool, the server MUST check if the
   policy type indicated by the PE is the same as the overall policy
   type of the pool. If different, the ENRP server MUST attempt to
   override the PE's policy and make it the same as the overall
   policy.

     2a) If no additional policy-related information are required to
     perform the override (e.g., overriding Least-used with Round-robin
     does not require additional policy-related information), the ENRP
     server MUST replace the PE's policy type with the overall policy
     type.

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

   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
   SHOULD replace the attributes of the existing PE with the
   information carried in the received REGISTRATION message.

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

   In all above cases, the ENRP server MUST reply to the requesting PE
   with a REGISTRATION_RESPONSE message. In the message, the ENRP
   server MUST set the Action code to indicate that this is a response
   to a PE registration and MUST indicate in the Result code whether
   the registration is granted or rejected.

   If the registration is granted with a polcy override (see Step 2a
   above), in addition to the Result code, in the
   REGISTRATION_RESPONSE message the ENRP server SHOULD also send back
   the registrant PE the new policy, in a Member Selection Policy

Xie, et al                                                     [Page 15]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

   Parameter, so as to inform the PE that a policy override is
   performed.

   If the registration is granted (i.e., one of cases 1-3 above), the
   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 send to its peers.


4.3.1 Rules on PE Re-registration

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

   A PE may modify its load factor value at any time via
   re-registration. Based on 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 4.5.2 in [ASAP] 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".


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

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

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

   If the ENRP server fails to find any 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 REGISTRATION_RESPONSE
   message to the PE. In the message, the ENRP server MUST set the
   Action code to indicate that this is a response to a PE
   de-registration, and indicate in the Result code whether the
   request is granted or rejected.

Xie, et al                                                     [Page 16]


Internet Draft        Endpoint Name Resolution Protocol         May 2002


   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 PE or 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 PE or PU to send a NAME_RESOLUTION message to its
   home ENRP server and in the NAME_RESOLUTION message specify the
   pool handle to be translated in a Pool Handle parameter. Complete
   defintion of the NAME_RESOLUTION message and the rules of sending
   it are defined in [ASAP].

   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 or PE.

   In the response message, the ENRP server MUST 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 [ASAP].


4.6 Server Namespace Update

   This includes a set of update operations used by an ENRP server to
   inform its peers when its local namespace 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

Xie, et al                                                     [Page 17]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

   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 annoucements 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 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), 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 annoucements 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,

Xie, et al                                                     [Page 18]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

   respectively.

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

   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 [RFC2960]), 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 (i.e., 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 4.6.2?.

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

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


4.8 Helping PE and PU to Discover Home ENRP Server

   At its startup time, or whenever its current home ENRP server is
   not providing services, a PE or PU will attempt to find a new home
   server. The PE or PU will either multicast or send a point-to-point
   SERVER_HUNT message to one or more ENRP servers in the operation
   scope. For the complete procedure of this, see Section xxxx in
   [ASAP].

Xie, et al                                                     [Page 19]


Internet Draft        Endpoint Name Resolution Protocol         May 2002


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


4.9 Maintaining Peer List and Monitoring Peer Status

   An ENRP server MUST keep internally a record on the status of each
   of its known peers. This record is 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.





   If the message is
   received over the well-known server multicast channel, the ENRP
   server MUST mark this new peer as multicast-enabled. Otherwise, the
   new peer MUST be marked as multicast-disabled (see Section 4.1 for
   more details).

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

   [editor's note: we also want to send a reply-required probe to
   force the new peer to send us its Server Info Param.. so we can now
   it details].

4.9.2 Server Sending Heartbeat

   Every <PEER-HEARTBEAT-CYCLE> seconds, an ENRP server 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 peers to update their internal variable <Peer-last-heared> for
   the sending server (see Section 4.9.3? for more details).


4.9.3 Detecting Peer Server Failure

   An ENRP server MUST keep an interanl variable <Peer-last-heared>
   for each of its known peers and the value of this variable MUST be
   updated to the current local time everytime a message of any type

Xie, et al                                                     [Page 20]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

   (point-to-point or announcement) is received from the cooresponding
   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 remove the peer from its peer list.


4.10 Namespace Data Auditing and Re-synchronization

   [TBD]


4.11 Reporting Unrecognized Message or Unrecognized Parameter

   [TBD]


5.  Variables and Time Constants

5.1 Variables

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

5.2 Timer Constants

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

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

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

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

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

    <MAX-BAD-PE-REPORT> - the maximal number of unreachability reports

Xie, et al                                                     [Page 21]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

                          on a PE that an ENRP server will allow
                          before purging this PE from the namespace.
                          (Default=3)


6. Security Considerations

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

   For networks that demand IPsec security, implementations MUST
   support [SCTP-IPSEC] which describes IPsec-SCTP. IPsec is two
   layers below RSerPool. Therefore, if IPsec is used for securing
   Rserpool, no changes or special considerations need to be made to
   Rserpool to secure the protocol.

   For networks that cannot or do not wish to use IPsec and prefer
   instead TLS, implementations MUST support TLS with SCTP as
   described in [SCTP-TLS] or TLS over TCP as described in [RFC2246].
   When using TLS/SCTP we must ensure that RSerPool does not use any
   features of SCTP that are not available to an TLS/SCTP user.  This
   is not a difficult technical problem, but simply a
   requirement. When describing an API of the RSerPool lower layer we
   have also to take into account the differences between TLS and
   SCTP. This is also not difficult, but it is in contrast to the
   IPsec solution which is transparently layered below Rserpool.

   Support for security is required for the ENRP server and the PEs.
   Security support for the Rserpool end user is optional.  Note that
   the end user implementation contains a piece of the Rserpool
   protocol -- namely ASAP -- whereby the pool handle is passed for
   name resolution to the ENRP server and IP address(es) are
   returned.

   The argument for optional end user security is as follows: If the
   user doesn't require security protection for example, against
   eavesdropping for the request for pool handle resolution and
   response, then they are free to make that choice.  However, if the
   end user does require security, they are guaranteed to get it due
   to the requirement for security support for the ENRP server. It is
   also possible for the ENRP server to reject an unsecured request
   from the user due to its security policy in the case that it
   requires enforcement of strong security.  But this will be
   determined by the security requirements of the individual network
   design.


7. References

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

Xie, et al                                                     [Page 22]


Internet Draft        Endpoint Name Resolution Protocol         May 2002


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

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

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

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

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

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

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

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

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


7.1 Informative References

   [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
   Security", RFC 1750, December 1994.


8. Acknowledgements

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


9.  Authors' Addresses

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

Xie, et al                                                     [Page 23]


Internet Draft        Endpoint Name Resolution Protocol         May 2002

   USA

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

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



                    Expires in six months from May 2002







































Xie, et al                                                     [Page 24]


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