[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: August 11, 2006                                      R. Stewart
                                                     Cisco Systems, Inc.
                                                             M. Stillman
                                                                   Nokia
                                                               M. Tuexen
                                      Muenster Univ. of Applied Sciences
                                                            A. Silverton
                                                          Motorola, Inc.
                                                        February 7, 2006


            Endpoint Handlespace Redundancy Protocol (ENRP)
                    draft-ietf-rserpool-enrp-13.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 August 11, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work



Xie, et al.              Expires August 11, 2006                [Page 1]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  ENRP Message Definitions . . . . . . . . . . . . . . . . . . .  6
     2.1.  ENRP_PRESENCE message  . . . . . . . . . . . . . . . . . .  6
     2.2.  ENRP_HANDLE_TABLE_REQUEST message  . . . . . . . . . . . .  8
     2.3.  ENRP_HANDLE_TABLE_RESPONSE message . . . . . . . . . . . .  8
     2.4.  ENRP_HANDLE_UPDATE message . . . . . . . . . . . . . . . . 10
     2.5.  ENRP_LIST_REQUEST message  . . . . . . . . . . . . . . . . 11
     2.6.  ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 12
     2.7.  ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 13
     2.8.  ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14
     2.9.  ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 14
     2.10. ENRP_ERROR message . . . . . . . . . . . . . . . . . . . . 15
   3.  ENRP Operation Procedures  . . . . . . . . . . . . . . . . . . 17
     3.1.  Methods for Communicating amongst ENRP Servers . . . . . . 17
     3.2.  ENRP Server Initialization . . . . . . . . . . . . . . . . 18
       3.2.1.  Generate a Server Identifier . . . . . . . . . . . . . 19
       3.2.2.  Acquire Peer Server List . . . . . . . . . . . . . . . 19
       3.2.3.  Download ENRP Handlespace Data from Mentor Peer  . . . 21
     3.3.  Handle PE Registration . . . . . . . . . . . . . . . . . . 23
       3.3.1.  Rules on PE Re-registration  . . . . . . . . . . . . . 25
     3.4.  Handle PE De-registration  . . . . . . . . . . . . . . . . 25
     3.5.  Pool Handle Translation  . . . . . . . . . . . . . . . . . 26
     3.6.  Server Handlespace Update  . . . . . . . . . . . . . . . . 27
       3.6.1.  Announcing Addition or Update of PE  . . . . . . . . . 27
       3.6.2.  Announcing Removal of PE . . . . . . . . . . . . . . . 28
     3.7.  Detecting and Removing Unreachable PE  . . . . . . . . . . 28
     3.8.  Helping PE and PU to Discover Home ENRP Server . . . . . . 29
     3.9.  Maintaining Peer List and Monitoring Peer Status . . . . . 30
       3.9.1.  Discovering New Peer . . . . . . . . . . . . . . . . . 30
       3.9.2.  Server Sending Heartbeat . . . . . . . . . . . . . . . 30
       3.9.3.  Detecting Peer Server Failure  . . . . . . . . . . . . 30
     3.10. Taking-over a Failed Peer Server . . . . . . . . . . . . . 31
       3.10.1. Initiate Server Take-over Arbitration  . . . . . . . . 31
       3.10.2. Take-over Target Peer Server . . . . . . . . . . . . . 32
     3.11. Handlespace Data Auditing and Re-synchronization . . . . . 33



Xie, et al.              Expires August 11, 2006                [Page 2]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


       3.11.1. Auditing Procedures  . . . . . . . . . . . . . . . . . 33
       3.11.2. PE Checksum Calculation Algorithm  . . . . . . . . . . 33
       3.11.3. Re-synchronization Procedures  . . . . . . . . . . . . 34
     3.12. Handling Unrecognized Message or Unrecognized Parameter  . 35
   4.  Variables and Thresholds . . . . . . . . . . . . . . . . . . . 36
     4.1.  Variables  . . . . . . . . . . . . . . . . . . . . . . . . 36
     4.2.  Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 37
     5.1.  Implementing Security Mechanisms . . . . . . . . . . . . . 38
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 41
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 42
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
   Intellectual Property and Copyright Statements . . . . . . . . . . 45




































Xie, et al.              Expires August 11, 2006                [Page 3]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


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

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

1.1.  Definitions

   This document uses the following terms:

   Operational scope: See [3];

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

   Pool handle: See [3];

   Pool element (PE): See [3];

   Pool user (PU): See [3];

   Pool element handle: See [3];

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

   ENRP client channel: The communication channel through which an ASAP
      User (either a PE or PU) requests ENRP handlespace service.  The
      client channel is usually defined by the transport address of the
      home server and a well known port number.  The channel MAY make
      use of multi-cast or a named list of ENRP servers.

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







Xie, et al.              Expires August 11, 2006                [Page 4]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


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

1.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
   [6].





































Xie, et al.              Expires August 11, 2006                [Page 5]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


2.  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 operational
   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
   [11], 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 [11].

   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
         -----      -------------------------
         0x00      - (reserved by IETF)
         0x01      - ENRP_PRESENCE
         0x02      - ENRP_HANDLE_TABLE_REQUEST
         0x03      - ENRP_HANDLE_TABLE_RESPONSE
         0x04      - ENRP_HANDLE_UPDATE
         0x05      - ENRP_LIST_REQUEST
         0x06      - ENRP_LIST_RESPONSE
         0x07      - ENRP_INIT_TAKEOVER
         0x08      - ENRP_INIT_TAKEOVER_ACK
         0x09      - ENRP_TAKEOVER_SERVER
         0x0a      - ENRP_ERROR
         0x0b-0xff - (reserved by IETF)

2.1.  ENRP_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 August 11, 2006                [Page 6]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


       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 = 0x01 |0|0|0|0|0|0|0|R|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      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 ENRP_PRESENCE.  This parameter SHOULD be
         included for handlespace consistency auditing.  See
         Section 3.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 [11]).
         This parameter is optional.  However, if this message is sent
         in response to a received "reply required" ENRP_PRESENCE from a
         peer, the sender then MUST include its server information.

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



Xie, et al.              Expires August 11, 2006                [Page 7]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


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

2.2.  ENRP_HANDLE_TABLE_REQUEST message

   An ENRP server sends this message to one of its peers to request a
   copy of the handlespace data.  This message is normally used during
   server initialization or handlespace 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 = 0x02 |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 2.1.

      Receiver Server's ID:

         See Section 2.1.

2.3.  ENRP_HANDLE_TABLE_RESPONSE message















Xie, et al.              Expires August 11, 2006                [Page 8]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


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



      M (More_to_send) flag: 1 bit

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

      R (Reject) flag: 1 bit

         MUST be set to '1' if the sender of this message is rejecting a
         handlespace request.  In such a case, this message MUST be sent
         with no pool entries 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 2.1.





Xie, et al.              Expires August 11, 2006                [Page 9]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


      Receiver Server's ID:

         See Section 2.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             :
                   +---------------------------+

2.4.  ENRP_HANDLE_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 = 0x04 |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Update Action          |        (reserved)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                        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 August 11, 2006               [Page 10]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


         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
            handlespace

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

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

      Receiver Server's ID:

         See Section 2.1.

      Pool handle:

         Specifies to which the PE belongs.

      Pool Element:

         Specifies the PE.

2.5.  ENRP_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 August 11, 2006               [Page 11]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


       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 = 0x05 |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 2.1.

      Receiver Server's ID:

         See Section 2.1.

2.6.  ENRP_LIST_RESPONSE message

   This message is used to respond an ENRP_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 = 0x06 |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.



Xie, et al.              Expires August 11, 2006               [Page 12]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


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

      Receiver Server's ID:

         See Section 2.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
         [11].

2.7.  ENRP_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 = 0x07 |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 2.1.







Xie, et al.              Expires August 11, 2006               [Page 13]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


      Receiver Server's ID:

         See Section 2.1.

      Target Server's ID:

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

2.8.  ENRP_INIT_TAKEOVER_ACK message

   This message is used to acknowledge the takeover initiator that the
   sender of this message received the ENRP_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 = 0x08 |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 2.1.

      Receiver Server's ID:

         See Section 2.1.

      Target Server's ID:

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

2.9.  ENRP_TAKEOVER_SERVER message

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




Xie, et al.              Expires August 11, 2006               [Page 14]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


       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 = 0x09 |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 2.1.

      Receiver Server's ID:

         See Section 2.1.

      Target Server's ID:

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

2.10.  ENRP_ERROR message

   This message is used by an ENRP server to report an operational 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 = 0x0a |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Sender Server's ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Receiver Server's ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                 Operational Error Parameter                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+







Xie, et al.              Expires August 11, 2006               [Page 15]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


      Sender Server's ID:

         See Section 2.1.

      Receiver Server's ID:

         See Section 2.1.

      Operational Error Parameter:

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







































Xie, et al.              Expires August 11, 2006               [Page 16]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


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

3.1.  Methods for Communicating amongst ENRP Servers

   Within an Rserpool operational scope, ENRP servers need to
   communicate with each other in order to exchange information such as
   the pool membership changes, handlespace 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
      operational 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 August 11, 2006               [Page 17]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


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

   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.

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






Xie, et al.              Expires August 11, 2006               [Page 18]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


3.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 operational 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 ([13]
   provides some information on randomness guidelines).

   Note, there is a very remote chance (about 1 in 4 billion) that two
   ENRP servers in an operational 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.

3.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 operational 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.

3.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 operational 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 an ENRP_PRESENCE message,
       with the 'Reply_required' flag set, over the multicast channel.
       Upon the reception of this ENRP_PRESENCE message, a peer server
       MUST send an ENRP_PRESENCE, without the 'Reply_required' flag,
       back to the initiating server.




Xie, et al.              Expires August 11, 2006               [Page 19]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   3.  When the first response to its original ENRP_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 operational 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 ENRP_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 operational scope.

   5.  If the initiating server determined that it is alone in the
       scope, it MUST skip the procedures in Section 3.2.2.2 and
       Section 3.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 operational 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 operational 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.

3.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
   an ENRP_LIST_REQUEST message to the mentor peer server to request a
   copy of the complete server list maintained by the mentor peer (see
   Section 3.9 for maintaining server list).

   The initiating server SHOULD start a timer every time it finishes
   sending an ENRP_LIST_REQUEST message.  If the timer expires before
   receiving a response from the mentor peer, the initiating server
   SHOULD abort and send a new server list request to a backup mentor
   peer, if one is available.

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



Xie, et al.              Expires August 11, 2006               [Page 20]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   Upon the reception of the ENRP_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 ENRP_LIST_REQUEST to another
   server), it MUST reject the request by the initiating server and
   respond with an ENRP_LIST_RESPONSE message with the R flag set to
   '1', and with no server information included in the response.

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

3.2.3.  Download ENRP Handlespace Data from Mentor Peer

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

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

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

       If more than one ENRP_HANDLE_TABLE_RESPONSE message are used
       during the download, the mentor peer MUST use the M flag in each
       ENRP_HANDLE_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
       ENRP_HANDLE_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 ENRP_HANDLE_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.



Xie, et al.              Expires August 11, 2006               [Page 21]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   3.  During the downloading, every time the initiating server receives
       an ENRP_HANDLE_TABLE_RESPONSE message, it MUST transfer the data
       entries carried in the message into its local handlespace
       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
       ENRP_HANDLE_TABLE_RESPONSE message, the initiating server MUST
       send another ENRP_HANDLE_TABLE_REQUEST message to the mentor peer
       to request for the next ENRP_HANDLE_TABLE_RESPONSE message.

   4.  When unpacking the data entries from a ENRP_HANDLE_TABLE_RESPONSE
       message into its local handlespace 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 handlespace, the
           initiating server MUST creates the pool in the local
           handlespace 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 handlespace, 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 handlespace 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 ENRP_HANDLE_TABLE_RESPONSE message is received from
       the mentor peer and unpacked into the local handlespace, 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 handlespace download to the initiating server.  For
   example, the mentor peer is in the middle of initializing its own
   handlespace 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 an ENRP_HANDLE_TABLE_RESPONSE
   message with the R flag set to '1', and with no pool entries included
   in the response.



Xie, et al.              Expires August 11, 2006               [Page 22]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


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

   A started handlespace download session may get interrupted for some
   reason.  To cope with this, the initiating server SHOULD start a
   timer every time it finishes sending an ENRP_HANDLE_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 handlespace download with a
   backup mentor peer, if one is available.

   Similarly, after sending out an ENRP_HANDLE_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.

3.3.  Handle PE Registration

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

   In the ASAP_REGISTRATION message, the PE indicates the handle 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 ASAP_REGISTRATION message according to
   the following rules:

   1.  If the named pool does not exist in the handlespace, the ENRP
       server MUST creates a new pool with that handle in the
       handlespace 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.





Xie, et al.              Expires August 11, 2006               [Page 23]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   2.  If the named pool already exists in the handlespace, 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
       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 reject the registration.

   3.  If the named pool already exists in the handlespace 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
       ASAP_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.  The ENRP server MUST also record the SCTP transport
       address from which it received the ASAP_REGISTRATION in the ASAP
       Transport parameter TLV inside the PE parameter of this PE.

   5.  The ENRP server may reject the registration due to other 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 an ASAP_REGISTRATION_RESPONSE message.  If the registration is
   accepted, the ENRP server MUST set the 'R' flag in the
   ASAP_REGISTRATION_RESPONSE to '0'.  If the registration is rejected,
   the ENRP server MUST indicate the rejection by setting the 'R' flag
   in the ASAP_REGISTRATION_RESPONSE to '1'.

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

   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



Xie, et al.              Expires August 11, 2006               [Page 24]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


      peer(s).

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

3.3.1.  Rules on PE Re-registration

   A PE may re-register itself to the handlespace 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.

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

3.4.  Handle PE De-registration

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

   In the ASAP_DEREGISTRATION message the PE indicates the handle 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 handlespace.  Moreover, if the PE is the last one of the named
   pool, the ENRP server will remove the pool from the handlespace as
   well.



Xie, et al.              Expires August 11, 2006               [Page 25]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


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

   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 an
   ASAP_DEREGISTRATION_RESPONSE message to the PE.  If the de-
   registration is rejected, the ENRP server MUST indicate the rejection
   by including the proper Operational 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 handlespace, the ENRP server MUST take the
   handlespace update action described in Section 3.6 to inform its
   peers about the change just made.  Otherwise, NO message SHALL be
   send to its peers.

3.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 an ASAP_HANDLE_RESOLUTION message to its
   home ENRP server and in the ASAP_HANDLE_RESOLUTION message specify
   the pool handle to be translated in a Pool Handle parameter.
   Complete definition of the ASAP_HANDLE_RESOLUTION message and the
   rules of sending it are defined in [1].

   An ENRP server SHOULD be prepared to receive ASAP_HANDLE_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 ASAP_HANDLE_RESOLUTION message, the ENRP server
   MUST first look up the pool handle in its handlespace.  If the pool
   exits, the home ENRP server MUST compose and send back an
   ASAP_HANDLE_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



Xie, et al.              Expires August 11, 2006               [Page 26]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   (if the overall policy is round-Robin, this parameter MAY be
   omitted?).

   If the named pool does not exist in the handlespace, the ENRP server
   MUST reject the handle resolution request by responding with an
   ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Poor
   Handle error.

   The complete format of ASAP_HANDLE_RESOLUTION_RESPONSE message and
   the rules of receiving it are defined in [1].

3.6.  Server Handlespace Update

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

3.6.1.  Announcing Addition or Update of PE

   When a new PE is granted registration to the handlespace 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 3.1 on how announcements are sent.

   An ENRP server MUST announce this update to all its peers in a
   ENRP_HANDLE_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 ENRP_HANDLE_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 handlespace, the peer MUST create the named
       pool in its local handlespace 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



Xie, et al.              Expires August 11, 2006               [Page 27]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


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

3.6.2.  Announcing Removal of PE

   When an existing PE is granted de-registration or is removed from its
   handlespace for some other reasons (e.g., purging an unreachable PE,
   see Section 3.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 3.1 on how announcements are sent.

   An ENRP server MUST announce the PE removal to all its peers in an
   ENRP_HANDLE_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]

   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 ENRP_HANDLE_UPDATE message, it MUST first
   find pool and the PE in its own handlespace, and then remove the PE
   from its local handlespace.  If the removed PE is the last one in the
   pool, the peer MUST also delete the pool from its local handlespace.

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

3.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 [8]), the PU SHOULD send an
   ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server.  The



Xie, et al.              Expires August 11, 2006               [Page 28]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   message SHOULD contain the pool handle and the PE Id of the
   unreachable PE.

   Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server
   MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE
   message to the PE in question (the 'H' flag in the message SHOULD be
   set to '0' in this case).  If this ASAP_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 handlespace and take actions described in Section 3.6.2.

   If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully
   to the PE, the ENRP server MUST retain the PE in its handlespace.
   Moreover, the server SHOULD keep a counter to record how many
   ASAP_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 handlespace and take actions described in
   Section 3.6.2.

   Optionally, an ENRP server may also periodically send point-to-point
   ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each
   of the PEs owned by the ENRP server in order to check their
   reachability status.  If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE
   fails, the ENRP server MUST consider the PE as unreachable and MUST
   remove the PE from its handlespace and take actions described in
   Section 3.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 ASAP_ENDPOINT_KEEP_ALIVE messages.  Instead, the
   implementation should try to smooth out the ASAP_ENDPOINT_KEEP_ALIVE
   message traffic over time.

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

3.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 an
   ASAP_SERVER_ANNOUNCE message every SERVER-ANNOUNCE-CYCLE seconds to
   the well-known ASAP multicast channel.  And in the
   ASAP_SERVER_ANNOUNCE message the ENRP server SHOULD include all the



Xie, et al.              Expires August 11, 2006               [Page 29]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   transport addresses available for ASAP communications.  If the ENRP
   server only supports SCTP for ASAP communications, the transport
   information MAY be omitted in the ASAP_SERVER_ANNOUNCE message.

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

3.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"

3.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 operational
   scope and add it to the peer list.

   The ENRP server MUST send an ENRP_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
   ENRP_PRESENCE containing its full server information (see
   Section 2.1).

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

3.9.2.  Server Sending Heartbeat

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

   The arrival of this periodic ENRP_PRESENCE message will cause all its
   peers to update their internal variable "peer.last.heard" for the
   sending server (see Section 3.9.3 for more details).

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



Xie, et al.              Expires August 11, 2006               [Page 30]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   seconds, the ENRP server MUST immediately send a point-to-point
   ENRP_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 3.10.

3.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."

3.10.1.  Initiate Server Take-over Arbitration

   The initiating server SHOULD first start a take-over arbitration
   process by announcing an ENRP_INIT_TAKEOVER message to all its peer
   servers.  See Section 3.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 ENRP_INIT_TAKEOVER message, the initiating
   server SHOULD wait for an ENRP_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 ENRP_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 ENRP_INIT_TAKEOVER message, it MUST immediately
       announce an ENRP_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.

   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 ENRP_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 an ENRP_INIT_TAKEOVER_ACK message.





Xie, et al.              Expires August 11, 2006               [Page 31]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


       B.  Otherwise, the peer MUST ignore the ENRP_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 an ENRP_INIT_TAKEOVER_ACK message.

   Once the initiating server has received ENRP_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 3.10.2.

   However, if it receives an ENRP_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".

3.10.2.  Take-over Target Peer Server

   The initiating ENRP server SHOULD first send, via an announcement, a
   ENRP_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.

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

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

   2.  send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message, with the
       'H' flag set to '1', to each of the PEs.  This will trigger the
       PE to adopt the initiating sever as its new home ENRP server;

   When a peer receives the ENRP_TAKEOVER_SERVER message from the
   initiating server, it SHOULD update its local peer list and PE cache
   by following these steps:

   1.  remove the target server from its internal peer list;

   2.  update the home ENRP server of each PE in its local copy of the
       handlespace to be the sender of the message, i.e., the initiating
       server.



Xie, et al.              Expires August 11, 2006               [Page 32]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


3.11.  Handlespace Data Auditing and Re-synchronization

   Message losses or certain temporary breaks in network connectivity
   may result in data inconsistency in the local handlespace copy of
   some of the ENRP servers in an operational scope.  Therefore, each
   ENRP server in the operational scope SHOULD periodically verify that
   its local copy of handlespace 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 handlespace data consistency.

3.11.1.  Auditing Procedures

   The auditing of handlespace 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 3.11.2.

   2.  Each time an ENRP server sends out an ENRP_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
       an arrived ENRP_PRESENCE) from a peer ENRP server (server B),
       server A SHOULD compare the PE checksum found in the
       ENRP_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
       handlespace 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 handlespace inconsistency between itself and server B
       and a re-synchronization process SHOULD be carried out
       immediately with server B (see Section 3.11.3).

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



Xie, et al.              Expires August 11, 2006               [Page 33]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   Let us assume that in server A's internal handlespace 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 16-bit PE checksum for server B
   "pe.checksum.prB" is then calculated over the byte blocks contributed
   by the 'M' PEs one by one.  The PE checksum calculation MUST use the
   Internet algorithm described in [4].

   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 handlespace has
   changed (e.g., due to PE registration/deregistration, receiving peer
   updates, removing failed PEs, downloading handlespace pieces from a
   peer, etc.), it MUST immediately update all its internal PE checksums
   that are affected by the change.

   Implementation Note: when the internal handlespace 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.

3.11.3.  Re-synchronization Procedures

   Once an ENRP server determines that there is inconsistency between
   its local handlespace data and a peer's handlespace 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 handlespace database;

   2.  The ENRP server SHOULD then send an ENRP_HANDLE_TABLE_REQUEST
       message with W flag set to '1' to the peer to request a complete



Xie, et al.              Expires August 11, 2006               [Page 34]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


       list of PEs owned by the peer;

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

   4.  Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the
       ENRP server SHOULD transfer the PE entries carried in the message
       into its local handlespace 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
       ENRP_HANDLE_TABLE_RESPONSE message into its local database, the
       ENRP server SHOULD check whether there are still PE entries that
       remain "marked" in its local handlespace.  If so, the ENRP server
       SHOULD silently remove those "marked" entries.

   Note, similar to what is described in Section 3.2.3, the peer may
   reject the ENRP_HANDLE_TABLE_REQUEST or use more than one
   ENRP_HANDLE_TABLE_RESPONSE message to respond.

3.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
   defined in Sections 3 and 4 in [11].

   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 August 11, 2006               [Page 35]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


4.  Variables and Thresholds

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

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














Xie, et al.              Expires August 11, 2006               [Page 36]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


5.  Security Considerations

   Threats Introduced by Rserpool and Requirements for Security in
   Response to Threats [12] 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 handle
   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 handlespace information
   -----------
   Security mechanism in response: Security protocol which supports data
   confidentiality

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



Xie, et al.              Expires August 11, 2006               [Page 37]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   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
   ASAP_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???).

5.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 August 11, 2006               [Page 38]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   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
   [9] or TLS over TCP as described in RFC2246 [7].  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 August 11, 2006               [Page 39]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


6.  Acknowledgements

   The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson,
   Thomas Dreibholz, and many others for their invaluable comments and
   feedback.














































Xie, et al.              Expires August 11, 2006               [Page 40]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


7.  References

7.1.  Normative References

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

   [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., Loughney, J., and
         A. Silverton, "Architecture for Reliable Server Pooling",
         draft-ietf-rserpool-arch-10 (work in progress), July 2005.

   [4]   Braden, R., Borman, D., and C. Partridge, "Computing the
         Internet Checksum", RFC 1071, September 1988.

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

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

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

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

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

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

   [11]  Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate
         Server Access Protocol (ASAP) and Endpoint Handlespace
         Redundancy Protocol (ENRP) Parameters",
         draft-ietf-rserpool-common-param-09 (work in progress),
         July 2005.

   [12]  Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M.
         Holdrege, "Threats Introduced by Rserpool and Requirements for



Xie, et al.              Expires August 11, 2006               [Page 41]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


         Security in Response to Threats",
         draft-ietf-rserpool-threats-05 (work in progress), July 2005.

7.2.  Informative References

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












































Xie, et al.              Expires August 11, 2006               [Page 42]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


Authors' Addresses

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

   Phone:
   Email: qxie1@email.mot.com


   Randall R. Stewart
   Cisco Systems, Inc.
   4875 Forest Drive
   Suite 200
   Columbia, SC  29206
   USA

   Phone:
   Email: rrs@cisco.com


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

   Phone:
   Email: maureen.stillman@nokia.com


   Michael Tuexen
   Muenster Univ. of Applied Sciences
   Stegerwaldstr. 39
   48565 Steinfurt
   Germany

   Email: tuexen@fh-muenster.de











Xie, et al.              Expires August 11, 2006               [Page 43]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


   Aron J. Silverton
   Motorola, Inc.
   1301 E. Algonquin Road
   Room 2246
   Schaumburg, IL 60196
   USA

   Phone: +1 847-576-8747
   Email: aron.j.silverton@motorola.com










































Xie, et al.              Expires August 11, 2006               [Page 44]

Internet-Draft       Endpoint Handlespace Redundancy       February 2006


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 (2006).  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 August 11, 2006               [Page 45]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/