Network Working Group                                         R. Stewart
Internet-Draft                                       Cisco Systems, Inc.
Expires: August 11, 2006
Intended status: Informational                                    Q. Xie
Expires: April 21, 2007                                   Motorola, Inc.
                                                             M. Stillman
                                                                   Nokia
                                                               M. Tuexen
                                      Muenster Univ. of Applied Sciences
                                                        February 7,
                                                        October 18, 2006

                Aggregate Server Access Protocol (ASAP)
                    draft-ietf-rserpool-asap-13.txt
                    draft-ietf-rserpool-asap-14.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. April 21, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Aggregate Server Access Protocol (ASAP) in conjunction with the
   Endpoint Handlespace Redundancy Protocol (ENRP) [7] [8] provides a high
   availability data transfer mechanism over IP networks.  ASAP uses a
   handle-based addressing model which isolates a logical communication
   endpoint from its IP address(es), thus effectively eliminating the
   binding between the communication endpoint and its physical IP
   address(es) which normally constitutes a single point of failure.

   In addition, ASAP defines each logical communication destination as a
   pool, providing full transparent support for server-pooling and load
   sharing.  It also allows dynamic system scalability - members of a
   server pool can be added or removed at any time without interrupting
   the service.

   ASAP is designed to take full advantage of the network level
   redundancy provided by the Stream Transmission Control Protocol
   (SCTP) RFC2960 [4].  Each transport protocol to be used by Pool
   Elements (PE) and Pool Users (PU) MUST have an accompanying
   transports mapping document.  Note  It should be noted that ASAP messages
   passed between PE's and ENRP servers MUST use SCTP. the SCTP transport
   protocol.

   The high availability server pooling is gained by combining two
   protocols, namely ASAP and ENRP, in which ASAP provides the user
   interface for pool handle to address translation, load sharing
   management, and fault management while ENRP defines the high
   availability pool handle translation service.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Organization of this document  . . . . . . . . . . . . . .  6
     1.3.  Scope of ASAP  . . . . . . . . . . . . . . . . . . . . . .  7
       1.3.1.  Extent of the Handlespace  . . . . . . . . . . . . . .  7
     1.4.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  7
   2.  Message Definitions  . . . . . . . . . . . . . . . . . . . . .  8
     2.1.  ASAP Parameter Formats . . . . . . . . . . . . . . . . . .  8
     2.2.  ASAP Messages  . . . . . . . . . . . . . . . . . . . . . .  8
       2.2.1.  ASAP_REGISTRATION message  . . . . . . . . . . . . . .  9
       2.2.2.  ASAP_DEREGISTRATION message  . . . . . . . . . . . . .  9
       2.2.3.  ASAP_REGISTRATION_RESPONSE message . . . . . . . . . . 10
       2.2.4.  ASAP_DEREGISTRATION_RESPONSE message . . . . . . . . . 10 11
       2.2.5.  ASAP_HANDLE_RESOLUTION message . . . . . . . . . . . . 11
       2.2.6.  ASAP_HANDLE_RESOLUTION_RESPONSE message  . . . . . . . 11 12
       2.2.7.  ASAP_ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . 12 14
       2.2.8.  ASAP_ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . 13 15
       2.2.9.  ASAP_ENDPOINT_UNREACHABLE message  . . . . . . . . . . 13 15
       2.2.10. ASAP_SERVER_ANNOUNCE message . . . . . . . . . . . . . 13 16
       2.2.11. COOKIE ASAP_COOKIE message  . . . . . . . . . . . . . . . . . . . . 14 16
       2.2.12. ASAP_COOKIE_ECHO message . . . . . . . . . . . . . . . 14 17
       2.2.13. BUSINESS_CARD ASAP_BUSINESS_CARD message . . . . . . . . . . . . . . . . 14 17
       2.2.14. ASAP_ERROR message . . . . . . . . . . . . . . . . . . 15 18
   3.  Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 16 19
     3.1.  Registration . . . . . . . . . . . . . . . . . . . . . . . 16 19
     3.2.  Deregistration . . . . . . . . . . . . . . . . . . . . . . 17 21
     3.3.  Handle resolution  . . . . . . . . . . . . . . . . . . . . 18 22
     3.4.  Endpoint keep alive  . . . . . . . . . . . . . . . . . . . 19 23
     3.5.  Reporting unreachable endpoints  . . . . . . . . . . . . . 20 24
     3.6.  ENRP server hunt procedures  . . . . . . . . . . . . . . . 20 24
     3.7.  Handle  Handling ASAP Endpoint to ENRP Server Communication
           Failures . . . . . . . . 22 . . . . . . . . . . . . . . . . . 26
       3.7.1.  SCTP Send Failure  . . . . . . . . . . . . . . . . . . 22 26
       3.7.2.  T1-ENRPrequest Timer Expiration  . . . . . . . . . . . 22 26
       3.7.3.  Registration Failure . . . . . . . . . . . . . . . . . 27
     3.8.  Cookie handling procedures . . . . . . . . . . . . . . . . 23 27
     3.9.  Business Card handling procedures  . . . . . . . . . . . . 23 27
   4.  The ASAP Interfaces  . . . . . . . . . . . . . . . . . . . . . 25 29
     4.1.  Registration.Request Primitive . . . . . . . . . . . . . . 25 29
     4.2.  Deregistration.Request Primitive . . . . . . . . . . . . . 25 29
     4.3.  Cache.Populate.Request Primitive . . . . . . . . . . . . . 26 30
     4.4.  Cache.Purge.Request Primitive  . . . . . . . . . . . . . . 26 30
     4.5.  Data.Send.Request Primitive  . . . . . . . . . . . . . . . 26 30
       4.5.1.  Sending to a Pool Handle . . . . . . . . . . . . . . . 27 31
       4.5.2.  Pool Element Selection . . . . . . . . . . . . . . . . 28 32
       4.5.3.  Sending to a Pool Element Handle . . . . . . . . . . . 29 33
       4.5.4.  Send by Transport Address  . . . . . . . . . . . . . . 30 34
       4.5.5.  Message Delivery Options . . . . . . . . . . . . . . . 31 34
     4.6.  Data.Received Notification . . . . . . . . . . . . . . . . 32 35
     4.7.  Error.Report Notification  . . . . . . . . . . . . . . . . 32 36
     4.8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 33 36
       4.8.1.  Send to a New Pool . . . . . . . . . . . . . . . . . . 33 36
       4.8.2.  Send to a Cached Pool Handle . . . . . . . . . . . . . 34 38
     4.9.  PE send failure  . . . . . . . . . . . . . . . . . . . . . 34 38
       4.9.1.  Translation.Request Primitive  . . . . . . . . . . . . 35 38
       4.9.2.  Transport.Failure Primitive  . . . . . . . . . . . . . 35 39
   5.  Timers, Variables, and Thresholds  . . . . . . . . . . . . . . 36 40
     5.1.  Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36 40
     5.2.  Variables  . . . . . . . . . . . . . . . . . . . . . . . . 36 40
     5.3.  Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 40
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 37 42
     6.1.  Chain of trust . . . . . . . . . . . . . . . . . . . . . . 43
     6.2.  Implementing Security Mechanisms . . . . . . . . . . . . . 38 44
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 40 46
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 47
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 41 47
     8.2.  Informational References (non-normative) . . . . . . . . . 41 47
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 48
   Intellectual Property and Copyright Statements . . . . . . . . . . 43 49

1.  Introduction

   The Aggregate Server Access Protocol (ASAP) when used in conjunction
   with ENRP [7] Endpoint Name Resolution Protocol [8] provides a high
   availability data transfer mechanism over IP networks.  ASAP uses a
   handle-based addressing model which isolates a logical communication
   endpoint from its IP address(es), thus effectively eliminating the
   binding between the communication endpoint and its physical IP
   address(es) which normally constitutes a single point of failure.

   When multiple receiver instances exist under the same handle, a.k.a, handle (a.k.a,
   a server pool, pool),an ASAP endpoint will select one Pool Element (PE),
   based on the current load sharing policy indicated by the server
   pool, and deliver
   the its message to the selected PE.

   While delivering the message, ASAP monitors can be used to monitor the
   reachability of the selected PE.  If it is found unreachable, before
   notifying the message sender (an ASAP user) of the failure, ASAP can
   automatically select another PE (if one exists) under that pool and
   attempt to deliver the message to that PE.  In other words, ASAP is
   capable of transparent fail-over amongst PE instances of within a server
   pool.

   ASAP uses the Endpoint Handlespace Redundancy Protocol (ENRP) to
   provide depends on ENRP which provides a high availability pool handle
   space.  ASAP is responsible for the abstraction of the underlying
   transport technologies, load distribution management, fault
   management, as well as the presentation to the upper layer (i.e., the (aka an ASAP
   user) via a unified primitive interface.

   When SCTP RFC2960 [4] is used as the transport layer protocol, ASAP
   can seamlessly incorporate the link-layer redundancy provided by the
   SCTP.

   This document defines the ASAP portion of the high availability
   server pool.  ASAP depends on the services of a high availability
   pool handle database a.k.a.  ENRP [7].

1.1.  Definitions

   This document uses the following terms:

   ASAP User: user:  Either a PE or PU that uses ASAP.

   Operational scope: See [6];
   Operational scope: See [6];  The part of the network visible to pool users by
      a specific instance of the reliable server pooling protocols.

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

   Pool handle: See [6];  A collection of servers providing the same
      application functionality.

   Pool element (PE): See [6]; handle:  A logical pointer to a pool.  Each server pool will be
      identifiable in the operational scope of the system by a unique
      pool handle.

   Pool user (PU): See [6]; element:  A server entity having registered to a pool.

   Pool user:  A server pool user.

   Pool element handle: See [6];

   ENRP handlespace handle (or handlespace): See [6];

   pool registrar: endpoint handle):  A server program running on logical pointer to a host that manages
      particular pool element in a pool, consisting of the pool handle space collectively with its peer ENRP servers
      and replies
      to a destination transport address of the service requests from any Pool User pool element.

   Handle space:  A cohesive structure of pool handles and relations
      that may be queried by an internal or Pool Element. external agent.

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

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

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

   Transport address:  A Transport Address is traditionally defined by
      Network Layer address, Transport Layer protocol and Transport
      Layer port number.  In the case of SCTP running over IP, a
      transport address is defined by the combination of an IP address
      and an SCTP port number (where SCTP is the Transport protocol).

1.2.  Organization of this document

   Section 2 details the ASAP message formats.  In  Section 3 we give details the
   detailed
   ASAP procedures for the an ASAP implementer.  And in implementor.  Section 4
   we give the illustrate
   details of the ASAP interface, focusing on the communication
   primitives employed between the applications above ASAP itself and ASAP
   itself, the applications that
   leverage ASAP, and the communications primitives between ASAP and
   SCTP (or
   other another transport layer).  Also included in this discussion is
   are relevant timers and configurable parameters as appropriate.
   Section 5 provides threshold and protocol variables.

1.3.  Scope of ASAP

   The requirements for high availability and scalability do not imply
   requirements on shared state and data.  ASAP does not provide
   transaction failover.  If a host or application fails during the
   processing of a transaction transaction, this transaction may be lost.  Some
   services may MAY provide a way to handle the failure, but this is not
   guaranteed.  ASAP MAY provide hooks to assist an application in
   building a mechanism to share state but ASAP in itself will NOT share
   any state.

1.3.1.  Extent of the Handlespace

   The scope of the ASAP/ENRP is NOT Internet wide.  The handlespace is
   neither hierarchical nor arbitrarily large like DNS.  We propose a  A flat peer-to-peer model. peer-to-
   peer model is detailed.  Pools of servers will exist in different
   administrative domains.  For example, suppose we want to the use ASAP/
   ENRP. of ASAP and
   ENRP is wanted.  First, the PU may use DNS to contact an ENRP server.
   Suppose a PU in North America wishes to contact the a server pool in
   Japan instead of North America.  The PU would use DNS to get the list
   of IP addresses of the Japanese server pool domain, pool, that is, the ENRP client
   channel in Japan.  From there the PU would query the Home ENRP server
   it established and then directly contact the PE(s) of interest.

1.4.  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 [2].

2.  Message Definitions

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

2.1.  ASAP Parameter Formats

   The basic message format and all parameter formats can be found in
   ENRP-ASAP [5]. [7].  Note also that ALL ASAP messages exchanged between an
   ENRP server and a PE MUST use SCTP as transport, while ASAP messages
   exchanged between an ENRP server and a PU MUST use either SCTP or TCP
   as transport.  PE to PU data traffic MAY use any transport protocol
   specified by the PE during registration.

2.2.  ASAP Messages

   This section details the individual messages used by ASAP.  These
   messages are composed of a standard message format found in Section 4
   of ENRP-ASAP [5]. [7].  The parameter descriptions may also can be found in Section
   3 of ENRP-ASAP [5]. [7].

   The following ASAP message types are defined in this section:

   Type       Message Name
   -----      -------------------------
   0x00       - (reserved by IETF)
   0x01       - ASAP_REGISTRATION
   0x02       - ASAP_DEREGISTRATION
   0x03       - ASAP_REGISTRATION_RESPONSE
   0x04       - ASAP_DEREGISTRATION_RESPONSE
   0x05       - ASAP_HANDLE_RESOLUTION
   0x06       - ASAP_HANDLE_RESOLUTION_RESPONSE
   0x07       - ASAP_ENDPOINT_KEEP_ALIVE
   0x08       - ASAP_ENDPOINT_KEEP_ALIVE_ACK
   0x09       - ASAP_ENDPOINT_UNREACHABLE
   0x0a       - ASAP_SERVER_ANNOUNCE
   0x0b       - ASAP_COOKIE
   0x0c       - ASAP_COOKIE_ECHO
   0x0d       - ASAP_BUSINESS_CARD
   0x0e       - ASAP_ERROR

2.2.1.  ASAP_REGISTRATION 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 = 0x01 |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :

   The REGISTRATION message is sent by a PE to its Home ENRP Server to
   either create a new pool or to add itself to an existing pool.  The
   PE sending the ASAP_REGISTRATION message MUST fill in the Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :
   parameter and the Pool Element Parameter                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parameter.  The pool handle Pool Handle parameter field
   specifies the handle name to be registered.  The PE Parameter field Pool Element parameter MUST
   be filled in by the registrant endpoint to declare its transport address, server pooling
   policy and value, and other operational preferences. as outlined in Section 3.1.  Note that
   the
   ASAP_REGISTRATION PE sending the registration message MUST use send the message using
   an SCTP and association.  Furthermore the IP address(es) of the PE that
   is registered within the Pool Element Parameter parameter MUST be a subset of
   the addresses of IP address(es) used in the SCTP association in respective regardless of the
   registered transport protocol registered by the PE.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x01 |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Element Parameter                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Pool Handle Parameter:

   See [7] section 3.7

   Pool Element Parameter:

   See [7] section 3.8

2.2.2.  ASAP_DEREGISTRATION message

   The ASAP_DEREGISTRATION message is sent by a PE to its Home ENRP
   Server to remove itself from a pool to which it registered.

    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|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                    PE Identifier Parameter                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++

   Pool Handle Parameter:

   See [7] section 3.7

   PE Identifier Parameter:

   See [7] section 3.12

   The PE sending the ASAP_DEREGISTRATION shall MUST fill in the pool handle
   and the PE identifier parameter in order to allow the ENRP server to
   verify the identity of the endpoint.  Note that deregistration is NOT
   allowed by proxy, in other words a PE may only deregister itself.

2.2.3.  ASAP_REGISTRATION_RESPONSE message

   The ASAP_REGISTRATION_RESPONSE message is sent in response by the
   Home ENRP Server to the PE that sent a ASAP_REGISTRATION 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 = 0x03 |0|0|0|0|0|0|0|R|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                    PE Identifier Parameter                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                   Operational Error (optional)                :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   R (Reject) flag Flag:

   When set to '1', indicate this flag indicates that the ENRP server that sent sending
   this message has rejected the registration.  Otherwise,  Otherwise when this flag
   is set to '0', this indicates the registration is has been granted.

   Operational Error

   This optional TLV

   Pool Handle Parameter:

   See [7] section 3.7.

   PE Identifier Parameter:

   See [7] section 3.12

   Operational Error Parameter (optional):

   See [7] section 3.10

   This parameter may be is included if an error or some atypical events
   occurred during the registration was
   rejected.  This TLV, process.  When the R flag is set to
   '1', this parameter, if present, indicates the cause of the
   rejection.  When the R flag is set to '0', this parameter, if
   present, serves as a warning to the registering PE, informing it that
   some of its registration values may have been modified by the ENRP
   server.  If the registration was successful and there is no warning,
   this parameter is not included.

2.2.4.  ASAP_DEREGISTRATION_RESPONSE message

   The ASAP_DEREGISTRATION_RESPONSE message is returned by the Home ENRP
   Server to a PE in response to a ASAP_DEREGISTRATION message or due to
   the expiration of the registration life of the PE in the pool

    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         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                    PE Identifier Parameter                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                   Operational Error (optional)                :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Pool Handle Parameter:

   See [7] section 3.7.

   PE Identifier Parameter:

   See [7] section 3.12.

   Operational Error Error:

   See [7] section 3.10.

   This optional TLV parameter is included if an error or some atypical events
   occurred during the deregistration process.  If the deregistration
   was successful this parameter is not included.

2.2.5.  ASAP_HANDLE_RESOLUTION message

   The ASAP_HANDLE_RESOLUTION message is sent by either a PE or PU to
   its Home ENRP Server to resolve a pool handle into a list of pool
   elements that are members of the pool indicated by the pool handle.

    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| |0|0|0|0|0|0|0|S|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This message

   The 'S' bit:

   The 'S' bit, if set to '1', requests the Home ENRP server to send
   updates to this Pool dynamically when the Pool changes.  Dynamic
   updates to the pool will consist of additional
   ASAP_HANDLE_RESOLUTION_RESPONSE messages, without the user needing to
   send in a ASAP_HANDLE_RESOLUTION.

   If the 'S' bit is sent set to '0' no dynamic updates are requested.

   Note that if a new Home ENRP server is adopted any 'dynamic update
   request' will need to be resent to the new Home ENPR server if the
   endpoint would like to request translation continue to recieve updates.  In other words,
   the ENRP servers do NOT share state regarding which of its PU's are
   requesting automatic update of state.  Thus upon change of Home ENRP
   Server the
   Pool Handle PU will need to resend a list ASAP_HANDLE_RESOLUTION message
   with the 'S' bit set to 1.  Note also, that the 'S' bit will only
   cause dynamic update of a Pool Elements. when the Pool exists.  If sent from a PE negative
   response is returned, no further updates to the SCTP
   association used for registration SHOULD be used. Pool (when it is
   created) will occur.

   Pool Handle parameter:

   See [7] section 3.7.

2.2.6.  ASAP_HANDLE_RESOLUTION_RESPONSE message

   The ASAP_HANDLE_RESOLUTION_RESPONSE message is sent in response by
   the Home ENRP server of the PU or PE that sent a
   ASAP_HANDLEE_RESOLUTION message or periodically upon Pool changes if
   the PU as requested Dynamic updates.

    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|0| |0|0|0|0|0|0|0|A|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :             Overall PE Selection Policy (optional)            :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :               Pool Element Parameter 1 (optional)             :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :               Pool Element Parameter N (optional)             :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                   Operational Error (optional)                :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A bit:

   This bit is set to '1' if the ENRP server accepts the request to send
   automatic updates (i.e. the S bit was set on the request).  If this
   bit is set to '0' either the ENRP server does NOT support automatic
   update, it has resource issues and cannot supply this feature or the
   user did not request it.

   Pool Handle parameter:

   See [7] section 3.7.

   Overall PE Selection Policy: Policy (optional):

   See [7] section 3.6.

   This TLV is a PE selection policy parameter and can be present when the response is positive.  It  If
   present, it indicates the overall pool member selection policy of the
   pool.  If not present, round-robin a round robin overall pool member selection
   policy is assumed.  This TLV parameter is not present when the response
   is negative (i.e., a rejection). negative.

   Note, any load policy parameter inside the within a Pool Element Parameter (if
   present) MUST be ignored, and MUST NOT be used to determine the
   overall pool member selection policy.

   Pool Element Parameters (optional):

   See [7] section 3.10.

   When the response is positive, an array of PE TLVs parameters are
   included, indicating the current PEs and their information about the PEs in the
   named pool.
   In a positive response, at  At least one PE TLV parameter MUST be present.  When the
   response is negative, no PE TLVs parameters are included.

   Operational Error (optional):

   See [7] section 3.10.

   The presence of this TLV parameter indicates that the response is
   negative
   (i.e., the (the handle resolution request was rejected by the ENRP
   server).  The cause code in this TLV parameter (if present) will indicate
   the reason the handle resolution request was rejected (e.g., the
   requested pool handle was not found).  The absence of this parmaeter
   indicates that the response is positive.

2.2.7.  ASAP_ENDPOINT_KEEP_ALIVE message

   The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP Server to a
   PE.  The ASAP_ENDPOINT_KEEP_ALIVE message is used to verify that the
   PE is reachable and requires the PE to adopt the sending server as
   its new Home ENRP Server if the H bit is set to 1.  Regardless of the
   setting of the H bit, an ASAP endpoint MUST respond with an
   ASAP_ENDPOINT_KEEP_ALIVE_ACK to any ASAP_ENDPOINT_KEEP_ALIVE messages
   that arrive.

    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|H|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Server Identifier                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   H (Home ENRP server) flag

   When set to '1', indicate that the ENRP server that sends this
   message want to be the home ENRP server of the receiver of this
   message.

   Server Identifier field indicates Identifier: 32 bit (unsigned integer)

   This is the sender ENRP server ID of the
   message.

   This ENRP server, as discussed in Section 3.2.1 of
   ENRP [8].

   Pool Handle parameter:

   See [7] section 3.7.

2.2.8.  ASAP_ENDPOINT_KEEP_ALIVE_ACK message

   The ASAP_ENDPOINT_KEEP_ALIVE_ACK message is sent to a PE by the ENRP server as a "health" check.
   If the transport level Heart Beat mechanism is insufficient, this
   adds heartbeat messages with the goal of determining health status at
   ASAP level PE in a possibly more timely fashion.  (The transport level
   Heart Beat may sometimes be considered insufficient due to that time
   outs are set for too long or heartbeats are not frequent enough, or,
   that the transport level Heart Beat mechanism's coverage is limited
   only to the transport level at the two ends.)

   Using ASAP keepalive also has additional value response
   to the reliability of
   fault detection when SCTP stack is in the kernel.  In such a case,
   while SCTP level heartbeat monitors the end-to-end connectivity
   between the two SCTP stacks, ASAP keepalive monitors the end-to-end
   liveliness of the ASAP layer above it.

2.2.8.  ASAP_ENDPOINT_KEEP_ALIVE_ACK an ASAP_ENDPOINT_KEEP_ALIVE message sent by an 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 = 0x08 |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                    PE Identifier Parameter                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This

   Pool Handle parameter:

   See [7] section 3.7.

   PE Identifier parameter:

   See [7] section 3.12.

2.2.9.  ASAP_ENDPOINT_UNREACHABLE message

   The ASAP_ENDPOINT_UNREACHABLE message is sent by the either a PE or PU to the
   its Home ENRP server as an
   acknowledgment Server to the ASAP_ENDPOINT_KEEP_ALIVE message.

2.2.9.  ASAP_ENDPOINT_UNREACHABLE message report an unreachable PE.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x09 |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                    PE Identifier Parameter                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   A

   Pool Handle parameter:

   See [7] section 3.7.

   PE or PU will send this Identifier parameter:

   See [7] section 3.12.

2.2.10.  ASAP_SERVER_ANNOUNCE message to

   The ASAP_SERVER_ANNOUNCE message is sent by an ENRP server to report Server such that
   PUs and PEs know the
   unreachability of transport information necessary to connect to
   the specified PE.

2.2.10.  ASAP_SERVER_ANNOUNCE message 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 = 0x0a |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Server Identifier                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                       Transport param #1                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                       Transport param #2                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                                                               :
   :                             .....                             :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                       Transport param #n                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Server Identifier: 32 bit (unsigned integer)

   This message is sent by an ENRP server such that PUs and PEs know the
   transport layer information necessary to connect to ID of the ENRP server.
   The transport server, as discussed in Section 3.2.1 in
   ENRP [8].

   Transport parameters are optional (optional):

   See [7] seections 3.3 and only TCP 3.4 for the SCTP and TCP Transport
   parameters respectively.

   Only SCTP transport and TCP Transport parameters are allowed.  Server Identifier field indicates the sender
   ENRP server of allowed for use within the
   SERVER_ANNOUNCE message.

2.2.11.  COOKIE  ASAP_COOKIE message

   The ASAP_COOKIE message is sent by a PE to a PU allowing the PE to
   convey information it wishes to share using a control channel.

    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 = 0x0b |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         Cookie Parameter                      :

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This

   Cookie Parameter :

   See [7] section 3.11.

2.2.12.  ASAP_COOKIE_ECHO message

   The ASAP_COOKIE_ECHO message is sent by a PE PU to a PU.  It may only be sent new PE when it
   detects a
   control channel exists between failure with the current PE and PU.

2.2.12.  ASAP_COOKIE_ECHO message to aid in failover.  The Cookie
   Parameter sent by the PE is the latest one received from the failed
   PE.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x0c |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         Cookie Parameter                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This message is sent by a PU to a PE in case of a failover.  The 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x0c |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                         Cookie Parameter is one received latest from the failed PE.                      :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Cookie Parameter:

   See [7] section 3.11.

2.2.13.  BUSINESS_CARD  ASAP_BUSINESS_CARD message

   This

   The ASAP_BUSINESS_CARD message is sent by a PU to a PE or from a PE
   to a PU.  This
   parameter MUST NOT be sent if PU using a control channel does NOT exists
   between to convey the PE pool handle and PU. a
   preferred failover ordering.

    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 = 0x0d |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                   Pool Element Parameter-1                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ..                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                   Pool Element Parameter-N                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The sender of this message lists both the

   Pool that the sender
   belongs to and a preferred list of failover candidates. Handle parameter:

   See [7] section 3.7.

   Pool Element parameters:

   See [7] section 3.8.

2.2.14.  ASAP_ERROR message

   This

   The ASAP_ERROR message is used to report sent in response by an operational error.  Currently the
   use of this ASAP endpoint
   receiving an unknown message is undefined, it is reserved for future use
   [Editors Note: we need to come up with concrete uses or get rid of an unknown parameter to the sending
   ASAP endpoint to report the message]. problem or issue.

   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 = 0x0e |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                 Operational Error Parameter                   :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Operation Error parameter:

   See [7] section 3.10

   When an ASAP endpoint receives an ASAP 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 Section 3.

   According to the rules, if an error report to the message sender is
   needed, the ASAP endpoint that discovered the error SHOULD send back
   an ASAP_ERROR message which includes an Operation Error parameter
   with the proper cause code, cause length, and case specific
   information.

3.  Procedures

   This section will focus on the methods and procedures used by an
   internal ASAP endpoint.  Appropriate timers and recovery actions for
   failure detection and management are also discussed.  Also please
   note that ASAP messages, sent between a PE and PU are identified by
   an SCTP Payload Protocol Identifier (PPID) (or equivilant mapped
   function if using TCP).

3.1.  Registration

   When a PE wishes to initiate or join its a server pool it MUST use the
   procedures outlined in this section to register.  Often for registration.  Often, the
   registration will be triggered by a user request primitive (discussed
   in Section 4.1).  The ASAP endpoint PE MUST register using an SCTP association
   established between the
   ASAP endpoint itself and the Home ENRP server.  If the ASAP endpoint PE has
   not established its Home ENRP server server, it MUST follow the procedures
   specified in Section 3.6 to establish its Home ENRP server. in Section 3.6.

   Once the PE's ASAP endpoint has established its Home ENRP server the
   following procedures MUST be followed to register:

   R1)  The PE's SCTP endpoint used to communicate with the Home ENRP
      server MUST be bound to all IP addresses that will be used by the
      PE (irregardless of what transport protocol will be used to
      service user requests to the PE).

   R2)  The PE's ASAP endpoint MUST formulate an ASAP_REGISTRATION
      message as defined in Section 2.2.1 2.2.1.  In formulating the message message,
      the ASAP
      endpoint PE MUST:

      R2.1)  Fill in the Pool Handle Parameter to specify which server
         pool the ASAP endpoint wishes to join.

      R2.2)  Fill in a the PE identifier using a good quality randomly
         generated number (RFC1750 [10] provides some information on
         randomness guidelines).

      R2.3)  Fill in the registration life Registration Life time parameter with the
         number of seconds that this registration is good valid for.  Note a
         PE that wishes to continue service MUST re-register after the
         registration expires.

      R2.4)  Fill in a User Transport Parameter for to specify the type of
         transport and the data/control channel usage the PE is willing
         to support.  Note, to join in joining an existing server pool, the PE
         MUST follow the overall transport type and overall data/control
         channel usage of the pool.  Otherwise, the registration may be
         rejected by the ENRP server.

      R2.5)  Fill in the preferred Pool Member selection policy.

      R2.6) Selection Policy
         parameter.

   R3)  Send the Registration message to the Home ENRP server using
      SCTP.

   R4)  Start a T2-registration timer.

   Note: the PE does not need to fill in the optional ASAP transport
   parameter.  The ASAP transport TLV parameter will be filled in and used
   by the home ENRP server.

   R3) Send the Registration request to the Home ENRP server using SCTP.

   R4) Start a T2-registration timer.

   If the T2-registration timer expires before receiving an
   ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
   received from the SCTP layer, the ASAP endpoint PE shall start the Server Hunt
   procedure (see Section 3.6) in an attempt to get service from a
   different ENRP server.  After establishing a new Home ENRP server the ASAP endpoint
   PE SHOULD restart the registration procedure.

   At the reception of the registration response, the ASAP endpoint PE MUST stop the
   T2-Registration timer.  If the response indicated indicates success,
   then the PE is now
   registered and will be considered an available member of the server
   pool.  If the registration response indicates a failure, the ASAP endpoint PE must
   either re-attempt registration after correcting the error or return a
   failure indication to the ASAP
   endpoints PE's upper layer.  The ASAP endpoint PE MUST NOT re-attempt re-
   attempt registration without correcting the error condition.

   At any time a registered PE MAY wish to re-register to either update
   its member selection policy value or registration expiration time.
   When re-registering the PE MUST use the same PE identifier.

   After successful registration the PE MUST start a T4-reregistration
   timer.  At its expiration a re-registration SHOULD be made starting
   at step R1 including (at completion) restarting the T4-reregistration
   timer.

   Note that an implementation SHOULD keep a record of the number of
   registration (and reregistration) attempts it makes in a local variable.  If
   variable that gets set to zero before the initial registration
   attempt to the Home ENRP server or after a successful re-
   registration.If repeated registration time-outs or failures occurs
   and the local count exceeds the Threshold 'MAX-REG-ATTEMPT' the
   implementation SHOULD report the error to its upper layer and stop
   attempting registration.

3.2.  Deregistration

   In the event the a PE wishes to deregister from its server pool (normally
   via an upper layer requests see Section 4.2) 4.2), it SHOULD use the
   following procedures.  Note procedure.  It should be noted that an alternate method of
   deregistration is to NOT re-register and to allow the registration
   lift time
   life of the PE to expire.  In this case a
   ASAP_DEREGISTRATION_RESPONSE message is sent to the PE's ASAP
   endpoint to indicate the removal of the PE from the pool it
   registered.

   When deregistering the PE SHOULD use the same SCTP association with
   its Home ENRP server that was
   used for registration. registration with its Home ENRP server.  To deregister deregister, the
   PE's ASAP endpoint MUST take the following actions:

   D1)  Fill in the Pool Handle parameter of the ASAP_DEREGISTRATION
      message ( Section 2.2.2) using the same Pool Handle parameter sent
      during registration.

   D2)  Fill in the PE Identifier. Identifier parameter of the ASAP_DEREGISTRATION
      message.  The identifier MUST be the same one as used during
      registration.  The use of the same Pool Handle and Pool Identifier
      parameters used in registration allows the identity of the PE ASAP
      endpoint be verified before deregisteration can occur.

   D3)  Send the ASAP_DEREGISTRATION message to the Home ENRP server
      using the PE's SCTP association.

   D4)  Start a T3-Deregistration timer.

   If the T3-Deregistration timer expires before receiving an either a
   ASAP_REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
   received
   from the PE's SCTP layer, endpint, the PE's ASAP endpoint shall start the
   ENRP Server Hunt procedure (see Section 3.6) in an attempt to get
   service from a different another ENRP server.  After establishing a new Home ENRP
   server
   server, the ASAP endpoint SHOULD restart the deregistration
   procedure.

   At the reception of the deregistration response, ASAP_DEREGISTRATION_RESPONSE, the PE's ASAP
   endpoint MUST stop the T3-deregistration timer.

   Note

   It should be noted that after a successful deregistration the PE MAY
   still receive requests for some period of time.  The PE MAY wish to still
   remain active and service these requests or may wish to exit and ignore these
   requests and exit.
   requests.

3.3.  Handle resolution

   At any time a PE or PU may wish to resolve a handle.  This usually
   will occur when a ASAP Endpoint sends to a Pool handle (
   Section 4.5.1) to its home ENRP server or requests a cache population
   (Section 4.3) but 4.3).  It may also occur for other reasons (e.g. the
   internal ASAP PE wishes to know its peers for sending a message to
   all of them).  When an ASAP Endpoint (PE or PU) wishes to resolve a
   pool handle to a list of accesible transport addresses of the member
   PEs of the pool, it MUST take the following actions:

   NR1)  Fill in an ASAP_HANDLE_RESOLUTION message ( Section 2.2.5) with
      the Pool Handle to be resolved.

   NR2)  If the endpoint does not have a Home ENRP server start the ENRP
      Server Hunt procedures specified in Section 3.6 to obtain one.
      Otherwise
      Otherwise, proceed to step NR3.

   NR3) Send  If a PE, send the ASAP_HANDLE_RESOLUTION message to the home
      ENRP server using SCTP or if a PU, send the ASAP_HANDLE_RESOLUTION
      message to the Home ENRP server using either TCP or SCTP.  If sent
      from a PE, the SCTP association used for registration SHOULD be
      used.

   NR4)  Start a T1-ENRPrequest timer.

   If the T1-ENRPrequest timer expires before receiving a response
   message, the ASAP endpoint SHOULD take the steps described in
   Section 3.7.2.  If a SEND.FAILURE notification is received from the
   SCTP or TCP layer, the ASAP endpoint SHOULD start the Server Hunt
   procedure (see Section 3.6) in an attempt to get service from a
   different ENRP server.  After establishing a new Home ENRP server server,
   the ASAP endpoint SHOULD restart the handle resolution procedure.

   At the reception of the response ASAP_HANDLE_RESOLUTION_RESPONSE message (i.e., an
   ASAP_HANDLE_RESOLUTION_RESPONSE) the
   ASAP endpoint MUST stop its T1-
   ENRPrequest T1-ENRPrequest timer.  After stopping the T1
   T1-ENRPrequest timer the ASAP endpoint SHOULD process the pool handle response message as
   appropriate (e.g. populate a local cache, give the response to the
   ASAP user, and/or use the response to send the ASAP users message).

   Note that some ASAP endpoints MAY use a cache to minimize the number
   of handle resolutions made. sent.  If such a cache is used used, it SHOULD:

   C1)  Be consulted before requesting sending a handle resolution.

   C2)  Have a stale timeout time timer associated with the cache so that even
      in the event of a cache-hit, if cache.  If the
      cache is "stale" it will cause determined to be stale upon a cache hit, a new handle
      resolution to message SHOULD be issued to update sent so the cache. cache can be updated.

   C3)  In the case of a "stale" stale cache the implementation may in parallel
      request an
      update the cache and answer the request or it may block the user
      and wait for an updated cache before proceeding with the users
      request.

   C4)  If the cache is NOT stale, cache is NOT stale, the endpoint SHOULD NOT send a handle
      resolution request but instead SHOULD use the entry from the
      cache.

3.4.  Endpoint keep alive

   The ASAP_ENDPOINT_KEEP_ALIVE message is sent by an ENRP server to a
   PE in order to verify it is reachable.  If the transport level heart
   beat mechanism is insufficient, this message can be used in a heart
   beat mechanism for the ASAP level whose goal is determining the
   health status of the ASAP level in a timely fashion.  (The transport
   level heart beat mechanism may be insufficient due to either the time
   outs or the heart beat interval being set too long, or, that the
   transport level heart beat mechanism's coverage is limited only to
   the transport level at the two ends.)  Additionally, the
   ASAP_ENDPOINT_KEEP_ALIVE message has value in the reliability of
   fault detection if the SCTP stack is in the kernel.  In such a case,
   while SCTP level heartbeat monitors the end-to-end connectivity
   between the two SCTP stacks, the ASAP level heartbeat monitors the
   end-to-end liveliness of the endpoint SHOULD NOT make a handle
      resolution request but instead ASAP layer above it.

   The use of the entry from the cache.

3.4.  Endpoint keep alive

   Periodically an ENRP server may choose to "audit" a PE.  It does this
   by sending an ASAP_ENDPOINT_KEEP_ALIVE message ( Section 2.2.7). 2.2.7) and
   the ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) is described below.
   Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message message, the following
   actions MUST be taken:

   KA1)  The PE must verify that the Pool Handle is correct and matches
      the Pool Handle sent in its earlier ASAP_REGISTRATION. ASAP_REGISTRATION message.  If
      the Pool Handle does not match match, the PE MUST silently discard the
      message.

   KA2)  Send an ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) by: as
      follows:

      KA2.1) Filling  Fill in the Pool Handle Parameter with the PE's Pool
         Handle.

      KA2.2)  Fill in the PE Identifier that was parameter using the PE
         identifier used with by this PE for registration.

      KA2.3)  Send off the ASAP_ENDPOINT_KEEP_ALIVE_ACK message via the
         appropriate SCTP association for that the ENRP server. server which sent the
         ASAP_ENDPOINT_KEEP_ALIVE message.

      KA2.4)  If the 'H' flag in the received ASAP_ENDPOINT_KEEP_ALIVE
         message is set, and the Server Identifier in the message is NOT
         the identity of your Home ENRP server (or it is not set e.g you
         have a no Home ENRP server) adopt the sender of the
         ASAP_ENDPOINT_KEEP_ALIVE message as the new home ENRP server.

3.5.  Reporting unreachable endpoints

   Occasionally

   Occasionally, an ASAP endpoint may realize that a PE is unreachable.  This
   may occur by a specific SCTP error realized by the ASAP endpoint or
   via an ASAP user report via the Transport.Failure Primitive
   (Section 4.9.2).  In either case case, the ASAP endpoint SHOULD report the
   unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE
   message to its home Home ENRP server.  The  Before sending the
   ASAP_ENDPOINT_UNREACHABLE message, the ASAP Endpoint should fill in
   the Pool Handle parameter and PE identifier parameter of the
   unreachable endpoint.  If the sender is a PE PE, the message MUST be
   sent via SCTP to the Endpoints
   Home ENRP server.  Note: SCTP.  It should be noted that an ASAP endpoint MUST report No
   no more than once each time it encounters such an event.

   Note:
   Additionally, when processing a Transport.Failure Primitive
   (Section 4.9.2) the ASAP endpoint MUST NOT send a unreachable report an
   ASAP_ENDPOINT_UNREACHABLE message unless the ASAP
   endpoint user has sent at least one message made a previous
   request to send data to the PE specified by the primitive.

3.6.  ENRP server hunt procedures

   Each PU and PE manages a list of transport addresses of ENRP servers. servers
   it knows about.

   If the multicast capabilities are used within the operational scope an
   ENRP server MUST send periodically every T6-Serverannounce an
   ASAP_SERVER_ANNOUNCE message (Section 2.2.10) including which includes all the
   transport addresses available for ASAP communication to on the multicast
   ENRP client channel.

   If an ASAP_SERVER_ANNOUNCE message is received by a PU or PE PE, it
   SHOULD insert all new included transport address in addresses into its list of
   ENRP server addresses and start a T7-ENRPoutdate timer for each
   address.  For all already known addresses included transport addresses, the T7-ENRPoutdate timers T7-
   ENRPoutdate timer MUST be
   restarted. restarted for each address.  If no
   transport parameters are included in the ASAP_SERVER_ANNOUNCE message
   message, the SCTP transport protocol is assumed to be used and the
   source IP address and the IANA registered ASAP port number are used instead.  It is also assumed
   that the transport protocol used is SCTP.
   for communication with the ENRP server.  If a T7-ENRP T7-ENRPoutdate timer
   for a transport address expires expires, the corresponding address is deleted
   from the managed list of transport addresses. addresses of the PU or PE.

   If no multicast capabilities are not used within the operational scope,
   each PU and PE MUST have a configured list of transport addresses of
   ENRP servers.

   At its startup, startup or when it fails to send to communicate with its home ENRP
   server (i.e., timed-out on a
   service request) with its current home ENRP server, request), a PE or PU shall MUST establish its
   a new Home ENRP server, i.e. server (i.e. setup a TCP connection or SCTP
   association with an a different ENRP server. server).

   To establish a new association or connection home ENRP server the following rules MUST be followed:

   SH1)  The PE or PU SHOULD try to establish an association or
      connection with no more than three ENRP server addresses. server's.  An ASAP
      endpoint MUST NOT try to establish more than three association associations or
      connections at any single time.
      connections.

   SH2)  The ASAP endpoint shall start a T5-Serverhunt timer.

   SH3)  If the ASAP endpoint establishes an association or connection
      it MUST stop its T5-Serverhunt timer.  The ASAP Endpoint SHOULD
      also reset the T5-Serverhunt value timer to its initial value and then
      proceed to step SH6.

   SH4)  If an association or connection establishment fails fails, the ASAP
      endpoint SHOULD try to establish an association or connection by
      using a different transport address.

   SH5)  If the T5-Serverhunt timer expires the following should be
      performed:

      SH5.1)  The ASAP endpoint MUST double the value of the T5-Serverhunt T5-
         Serverhunt timer.  Note that this doubling is capped at the
         value RETRAN.max

      SH5.2)  The ASAP endpoint SHOULD stop the establishment of
         associations and connections. connections with the transport addresses
         selected in step SH1.

      SH5.2)  The ASAP endpoint SHOULD repeat trying to establish an
         association or connection by proceeding to step SH1.  It SHOULD
         attempt to select a different set of transport addresses with
         which to
         connect to. connect.

   SH6)  The PE or PU shall pick one of the ENRP servers that with which it
      was able to establish an association or connection with, connection, and send all its
      subsequent the handlespace service requests ENRP request messages to this new home Home ENRP server.

3.7.  Handle  Handling ASAP Endpoint to ENRP Server Communication Failures

   Three types of failure may occur when the ASAP endpoint at an
   endpoint ether PE
   or PU tries to communicate with the an ENRP server:

   A) SCTP send failure

   B) T1-ENRPrequest timer expiration

   C) Registration failure

   Registration failure is discussed in Section 3.1

3.7.1.  SCTP Send Failure

   This communication failure indicates that the SCTP layer failed was uanble
   to deliver a message sent to the an ENRP server.  In other words, the
   ENRP server is currently unreachable.

   In such a case, the ASAP endpoint should not re-send the failed
   undeliverable message.  Instead, it should discard the failed message and
   start the ENRP server hunt procedure as described in Section 3.6 .
   After finding a new Home ENRP server, the ASAP endpoint should
   reconstruct and retransmit the request.

   Note that an ASAP endpoint MAY also choose to NOT discard the
   message, but to queue it for retransmission after a new Home ENRP
   server is found.  If an ASAP endpoint does choose to discard the
   message, after a new Home ENRP server is found, the ASAP endpoint
   MUST be capable of reconstructing the original request.

3.7.2.  T1-ENRPrequest Timer Expiration

   When a the T1-ENRPrequest timer expires, the ASAP endpoint should re-send
   resend the original request to the ENRP server and re-start restart the T1-ENRPrequest T1-
   ENRPrequest timer.  In parallel, the ASAP endpoint should begin the
   ENRP server hunt procedure should be started as
   outlined procedures described in Section 3.6.

   This should be repeated up to 'MAX-REQUEST-RETRANSMIT' MAX-REQUEST-RETRANSMIT times.  After
   that, an Error.Report notification should be generated to inform the
   ASAP user and the ENRP request message associated with the T1-
   ENRPrequest timer should be discarded.  Note  It should be noted that if an
   alternate ENRP server responds the ASAP endpoint SHOULD adopt the
   responding ENRP server as its new
   "home" Home ENRP server and resend the
   request to the new "home" Home ENRP server.

3.7.3.  Registration Failure

   Registration failure is discussed in Section 3.1.

3.8.  Cookie handling procedures

   Whenever a PE wants wants, and a control channel exists exists, it can send an
   ASAP_COOKIE Message message to a PU via the control channel.  The PU's ASAP
   endpoint stores the Cookie parameter and discards an older cookie if
   it is previously stored.

   Note: a control channel is a communication channel between a PU and
   PE that does not end in data passed to the user.  This is
   accomplished with SCTP by using a PPID to seperate the PU via the control channel.  The ASAP
   layer at the PU stores the Cookie parameter messages
   (Cookie and discards an older one
   if it is present. Business Card) from normal data messages.

   If the PU's ASAP layer endpoint detects a failure and initiates a failover
   to a different PE, it SHOULD send the ASAP layer sends the last lastest received Cookie cookie
   parameter in an ASAP_COOKIE_ECHO message to the new PE.  The upper layer  Upper layers
   may be involved in the failover procedure.

   This

   The cookie mechanism handling procedure can be used as a simple method for state sharing.
   Therefore a cookie should be signed by the sending PE ASAP endpoint
   and
   this the cookie should be verified by the receiving PE. PE's ASAP
   endpoint.  The details of this the verification procedure are out of scope of
   for this document.  It is only important that the PU
   stores always stores
   the last received Cookie Parameter and sends that back unmodified in
   case of a PE failure.

3.9.  Business Card handling procedures

   When communication begins between a PU and a PE either of which could
   be part of a PU/PE combination (i.e. the first a message is sent from the PU to the PE) the ASAP layer in between the PU
   SHOULD
   entities), a PE should always send an a ASAP_BUSINESS_CARD IF the sender is also registered as message to a PE.
   PU.  A PE may also PU should send back a ASAP_BUSINESS_CARD message to a PU PE only if it
   is part of a business card as well.  An PU/PE combination.  A ASAP_BUSINESS_CARD message MUST NOT
   ONLY be sent if a control channel does NOT
   exist exists between the a PU and PE.  After
   communication as been established between a PE and PU PU, a new
   ASAP_BUSINESS_CARD message may be sent at any time by either entity may
   to update its failover
   distribution by sending a new ASAP_BUSINESS_CARD. order.

   The business card ASAP_BUSINESS_CARD message serves two purposes (for both endpoints PU and PE). purposes.  First it lists
   the endpoints pool handle.  For a PU which is part of a PU/PE combination which
   is contacting a PE this is essential so that the PE may also gain learns the full benefits pool
   handle of
   ASAP if the PU is also a PE. PU/PE combination requesting service.  Secondly the business card
   ASAP_BUSINESS_CARD message tells the
   receiver receiving entity a failover
   order that is recommended to follow.  This may should facilitate
   rendezvous between PE's entities that have been working togehter as well as some
   to control of the load redistribution upon the failure of any given PE.

   Upon receipt of an ASAP_BUSINESS_CARD Message message (see Section 2.2.13)
   the receiver receiving ASAP endpoint SHOULD:

   BC1)  Unpack the ASAP_BUSINESS_CARD, message and if no entry exists in the translation
      cache and one exists, populate of the new Pool Handle
      into receiving ASAP endpoint for the cache and request a pool handle resolution of listed
      within the ASAP_BUSINESS_CARD message perform a
      ASAP_HANDLE_RESOLUTION for that pool handle.  If the translation
      cache does hold an entry for the pool handle, then it may be
      necessary to update the pool handle. peer endpoint.

   BC2) Create  Unpack the message and populate a preferred list for this PE of preferred failover order so that in
      the event of a failure
      order.  If the peers PE should fail this preferred list will be
      used to guide the ASAP endpoint in the selection of an alternate PE.

4.  The ASAP Interfaces

   This chapter will focus primarily on the primitives and notifications
   that form the interface between the ASAP-user and ASAP and that
   between ASAP and its lower layer transport protocol (e.g., SCTP).

   Note, the following primitive and notification descriptions are shown
   for illustrative purposes.  We believe that including these
   descriptions in this document is important to the understanding of
   the operation of many aspects of ASAP.  But an ASAP implementation is
   not required to use the exact syntax described in this section.

   An ASAP User passes primitives to the ASAP sub-layer to request
   certain actions.  Upon the completion of those actions or upon the
   detection of certain events, the ASAP layer will notify the ASAP
   user.

4.1.  Registration.Request Primitive

         Format: registration.request(poolHandle,
                                      User Transport parameter(s))

   The poolHandle parameter contains a NULL terminated ASCII string of
   fixed length.  The optional User Transport parameter(s) indicate
   specific transport parameters and types to register with.  If this
   optional parameter is left off, then the SCTP endpoint used to
   communicate with the ENRP server is used as the default User
   Transport parameter.  Note that any IP address contained within a
   User Transport parameter MUST be a bound IP address in the SCTP
   endpoint used to communicate with the ENRP server.

   The ASAP user invokes this primitive to add itself to the
   handlespace, thus becoming a Pool Element of a pool.  The ASAP user
   must register itself with the ENRP server by using this primitive
   before other ASAP users using the handlespace can send message(s) to
   this ASAP user by Pool Handle or by PE handle (see Section 4.5.1 and
   Section 4.5.3).

   In response to the registration primitive, the ASAP endpoint will
   send an ASAP_REGISTRATION message to the home ENRP server (See
   Section 2.2.1 and Section 3.1), and start a T2-registration timer.

4.2.  Deregistration.Request Primitive

         Format: deregistration.request(poolHandle)

   The ASAP PE invokes this primitive to remove itself from the Server
   Pool.  This should be used as a part of the graceful shutdown process
   by the application.

   A ASAP_DEREGISTRATION message will be sent by ASAP endpoint to the
   home ENRP server (see Section 2.2.2 and Section 3.2).

4.3.  Cache.Populate.Request Primitive

          Format: cache.populate.request([Pool-Handle |
                                        Pool-Element-Handle])

   If the address type is a Pool handle and a local handle translation
   cache exists, the ASAP endpoint should initiate a mapping information
   query by sending an ASAP_HANDLE_RESOLUTION message on the Pool handle
   and update it local cache when the response comes back from the ENRP
   server.

   If a Pool-Element-Handle is passed then the Pool Handle is unpacked
   from the Pool-Element-Handle and the ASAP_HANDLE_RESOLUTION message
   is sent to the ENRP server for resolution.  When the response message
   returns from the ENRP server the local cache is updated.

   Note that if the ASAP service does NOT support a local cache this
   primitive performs NO action.

4.4.  Cache.Purge.Request Primitive

      Format: cache.purge.request([Pool-Handle | Pool-Element-Handle])

   If the user passes a Pool handle and local handle translation cache
   exists, the ASAP endpoint should remove the mapping information on
   the Pool handle from its local cache.  If the user passes a Pool-
   Element-Handle then the Pool handle within is used for the
   cache.purge.request.

   Note that if the ASAP service does NOT support a local cache this
   primitive performs NO action.

4.5.  Data.Send.Request Primitive

         Format: data.send.request(destinationAddress, typeOfAddress,
                                   message, sizeOfMessage, Options);

   This primitive requests ASAP to send a message to some specified Pool
   or Pool Element within the current Operational scope.

   Depending on the address type used for the send request, the senders
   ASAP endpoint may perform address translation and Pool Element
   selection before sending the message out.  This also MAY dictate the
   creation of a local transport endpoint in order to meet the required
   transport type.

   The data.send.request primitive can take different forms of address
   types as described in the following sections.

4.5.1.  Sending to a Pool Handle

   In this case the destinationAddress and typeOfAddress together
   indicates a pool handle.

   This is the simplest form of send.data.request primitive.  By
   default, this directs ASAP to send the message to one of the Pool
   Elements in the specified pool.

   Before sending the message out to the pool, the senders ASAP endpoint
   MUST first perform a pool handle to address translation.  It may also
   need to perform Pool Element selection if multiple Pool Elements
   exist in the pool.

   If the senders ASAP implementation does not support a local cache of
   the mapping information or if it does not have the mapping
   information on the pool in its local cache, it will transmit a
   ASAP_HANDLE_RESOLUTION message (see Section 2.2.5 and Section 3.3) to
   the current home ENRP server, and MUST hold the outbound message in
   queue while awaiting the response from the ENRP server (any further
   send request to this pool before the ENRP server responds SHOULD also
   be queued).

   Once the necessary mapping information arrives from the ENRP server,
   the senders ASAP will:

   A) map the pool handle into a list of transport addresses of the
      destination PE(s),

   B) if multiple PEs exist in the pool, ASAP will choose one of them
      and transmit the message to it.  In that case, the choice of the
      PE is made by ASAP endpoint of the sender based on the server
      pooling policy as discussed in Section 4.5.2

   C) Optionally create any transport endpoint that may be needed to
      communicate with the PE selected.

   D) if no transport association or connection exists towards the
      destination PE, ASAP will establish any needed transport state,
   E) send out the queued message(s) to the appropriate transport
      connection using the appropriate send mechanism (e.g. for SCTP the
      SEND primitive in RFC2960 [4] would be used), and,

   F) if the local cache is implemented, append/update the local cache
      with the mapping information received in the ENRP server's
      response.  Also, record the local transport information (e.g. the
      SCTP association id) if any new transport state was created.

   For more on the ENRP server request procedures see ENRP [7]. [8].

   Optionally, the ASAP endpoint of the sender may return a Pool Element
   handle of the selected PE to the application after sending the
   message.  This PE handle can then be used for future transmissions to
   that same PE (see Section 4.5.3).

   Section 3.7 defines the fail-over procedures for cases where the
   selected PE is found unreachable.

4.5.2.  Pool Element Selection

   Each time an ASAP user sends a message to a pool that contains more
   than one PE, the senders ASAP endpoint must select one of the PEs in
   the pool as the receiver of the current message.  The selection is
   done according to the current server pooling policy of the pool to
   which the message is sent.

   Note, no selection is needed if the ASAP_SEND_TOALL option is set
   (see Section 4.5.5).

   Together with the server pooling policy, each PE can also specify a
   Policy Value for itself at the registration time.  The meaning of the
   policy value depends on the current server pooling policy of the
   group.  A PE can also change its policy value whenever it desires, by
   re-registering itself with the handlespace with a new policy value.
   Re-registration shall be done by simply sending another
   ASAP_REGISTRATION to its home ENRP server (See Section 2.2.1).

   Four

   One basic server pooling policies are policy is defined in ASAP, namely the
   Round Robin, Least Used, Least Used Degrading and Weighted Round
   Robin.  The following sections describes each of these policies. this document, others can be found in
   [6]

4.5.2.1.  Round Robin Policy

   When an ASAP endpoint sends messages by Pool Handle and Round-Robin
   is the current policy of that Pool, the ASAP endpoint of the sender
   will select the receiver for each outbound message by round-Robining
   through all the registered PEs in that Pool, in an attempt to achieve
   an even distribution of outbound messages.  Note that in a large
   server pool, the ENRP server MAY NOT send back all PEs to the ASAP
   client.  In this case the client or PU will be performing a round
   robin policy on a subset of the entire Pool.

4.5.2.2.  Least Used Policy

   When the destination Pool is under the Least Used server pooling
   policy, the ASAP endpoint of the message sender will select the PE
   that has the lowest policy value in the group as the receiver of the
   current message.  If more than one PE from the group share the same
   lowest policy value, the selection will be done round Robin amongst
   those PEs.

   It is important to note that this policy means that the same PE will
   be always selected as the message receiver by the sender until the
   load control information of the pool is updated and changed in the
   local cache of the sender (via a cache update see Section 3.3).

4.5.2.3.  Least Used with Degradation Policy

   This policy is the same as the Least Used policy with the exception
   that, each time the PE with the lowest policy value is selected from
   the Pool as the receiver of the current message, its policy value is
   incremented, and thus it may no longer be the lowest value in the
   Pool.

   This provides a degradation of the policy towards round Robin policy
   over time.  As with the Least Used policy, every local cache update
   at the sender will bring ASAP
   client.  In this case the client or PU will be performing a round
   robin policy back to Least Used with
   Degradation.

4.5.2.4.  Weighted Round Robin Policy

   [TBD] on a subset of the entire Pool.

4.5.3.  Sending to a Pool Element Handle

   In this case the destinationAddress and typeOfAddress together
   indicate an ASAP Pool Element handle.

   This requests the ASAP endpoint to deliver the message to the PE
   identified by the Pool Element handle.

   The Pool Element handle should contain the Pool Handle and a
   destination transport address of the destination PE or the Pool
   Handle and the transport type.  Other implementation dependant dependent
   elements may also be cached in a Pool Element handle.

   The ASAP endpoint shall use the transport address and transport type
   to identify the endpoint to communicate with.  If no communication
   state exists with the peer endpoint (and is required by the transport
   protocol) the ASAP endpoint MAY setup the needed state and then
   invoke the SEND primitive for the particular transport protocol to
   send the message to the PE.

   In addition, if a local translation cache is supported the endpoint
   will:

   A) send out the message to the transport address (or association id)
      designated by the PE handle.

   B) determine if the Pool Handle is in the local cache.

      If it is NOT, the endpoint will:

      i) ask the home ENRP server for handle resolution on pool handle
         by sending an ASAP_HANDLE_RESOLUTION message (see
         Section 2.2.5), and

      ii)  use the response to update the local cache.

         If the pool handle is in the cache, the endpoint will only
         update the pool handle if the cache is stale.  A stale cache is
         indicated by it being older than the protocol parameter
         'stale.cache.value' (see Section 5.2).

   Section 3.5 and Section 4.9 defines the fail-over procedures for
   cases where the PE pointed to by the Pool Element handle is found
   unreachable.

   Optionally, the ASAP endpoint may return the actual Pool Element
   handle to which the message was sent (this may be different from the
   Pool Element handle specified when the primitive is invoked, due to
   the possibility of automatic fail-over).

4.5.4.  Send by Transport Address

   In this case the destinationAddress and typeOfAddress together
   indicate a transport address and transport type.

   This directs the senders ASAP endpoint to send the message out to the
   specified transport address.

   No endpoint fail-over is support when this form of send request is
   used.  This form of send request effectively by-passes the ASAP
   endpoint.

4.5.5.  Message Delivery Options

   The Options parameter passed in the various forms of the above
   data.send.request primitive gives directions to the senders ASAP
   endpoint on special handling of the message delivery.

   The value of the Options parameter is generated by bit-wise "OR"ing
   of the following pre-defined constants:

   ASAP_USE_DEFAULT: 0x0000  Use default setting.

   ASAP_SEND_FAILOVER: 0x0001  Enables PE fail-over on this message.  In
      case where the first selected PE or the PE pointed to by the PE
      handle is found unreachable, the sender's ASAP endpoint SHOULD re-
      select an alternate PE from the same pool if one exists, and
      silently re-send the message to this newly selected endpoint.

      Note that this is a best-effort service.  Applications should be
      aware that messages can be lost during the failover process, even
      if the underlying transport supports retrieval of unacknowledged
      data (e.g.  SCTP) (Example: messages acknowledged by the SCTP
      layer at a PE, but not yet read by the PE when a PE failure
      occurs.)  In the case where the underlying transport does not
      support such retrieval (e.g.  TCP), any data already submitted by
      ASAP to the transport layer MAY be lost upon failover.

   ASAP_SEND_NO_FAILOVER: 0x0002  This option prohibits the senders ASAP
      endpoint from re-sending the message to any alternate PE in case
      that the first selected PE or the PE pointed to by the PE handle
      is found unreachable.  Instead, the senders ASAP endpoint shall
      notify its upper layer about the unreachability with an
      Error.Report and return any unsent data.

   ASAP_SEND_TO_LAST: 0x0004  This option requests the senders ASAP
      endpoint to send the message to the same PE in the pool that the
      previous message destined to this pool was sent to.

   ASAP_SEND_TO_ALL: 0x0008  When sending by Pool Handle, this option
      directs the senders ASAP endpoint to send a copy of the message to
      all the PEs, except for the sender itself if the sender is a PE,
      in that pool.

   ASAP_SEND_TO_SELF: 0x0010  This option only applies in combination
      with ASAP_SEND_TO_ALL option.  It permits the senders ASAP
      endpoint also deliver a copy of the message to itself if the
      sender is a PE of the pool (i.e., loop-back).

   ASAP_SCTP_UNORDER: 0x1000  This option requests the transport layer
      to send the current message using un-ordered delivery (note the
      underlying transport must support un-ordered delivery for this
      option to be effective).

4.6.  Data.Received Notification

         Format: data.received(messageReceived, sizeOfMessage,
                               senderAddress, typeOfAddress)

   When a new user message is received, the ASAP endpoint of the
   receiver uses this notification to pass the message to its upper
   layer.

   Along with the message being passed, the ASAP endpoint of the
   receiver should also indicate to its upper layer the message senders
   address.  The senders address can be in the form of either an SCTP
   association id, TCP transport address, UDP transport address, or an
   ASAP Pool Element handle.

   A) If the handle translation local cache is implemented at the
      receiver's ASAP endpoint, a reverse mapping from the senders IP
      address to the pool handle should be performed and if the mapping
      is successful, the senders ASAP Pool Element handle should be
      constructed and passed in the senderAddress field.

   B) If there is no local cache or the reverse mapping is not
      successful, the SCTP association id or other transport specific
      identification (if SCTP is not being used) should be passed in the
      senderAddress field.

4.7.  Error.Report Notification

         Format: error.report(destinationAddress, typeOfAddress,
                              failedMessage, sizeOfMessage)

   An error.report should be generated to notify the ASAP user about
   failed message delivery as well as other abnormalities.

   The destinationAddress and typeOfAddress together indicates to whom
   the message was originally sent.  The address type can be either a
   ASAP Pool Element handle, association id, or a transport address.

   The original message (or the first portion of it if the message is
   too big) and its size should be passed in the failedMessage and
   sizeOfMessage fields, respectively.

4.8.  Examples

   These examples assume an underlying SCTP transport between the PE and
   PU.  Other transports are possible but SCTP is utilized in the
   examples for illustrative purposes.  Note that all communication
   between PU and ENRP server and PE and ENRP servers would be using
   SCTP.

4.8.1.  Send to a New Pool

   This example shows the event sequence when a Pool User sends the
   message "hello" to a pool which is not in the local translation cache
   (assuming local caching is supported).

     ENRP Server                       PU         new-handle:PEx

       |                                |                 |
       |                              +---+               |
       |                              | 1 |               |
       |2. ASAP_HANDLE_RESOLUTION     +---+               |
       |<-------------------------------|                 |
       |                              +---+               |
       |                              | 3 |               |
       |4. ASAP_HANDLE_RESOLUTION_RSP +---+               |
       |------------------------------->|                 |
       |                              +---+               |
       |                              | 5 |               |
       |                              +---+  6. "hello1"  |
       |                                |---------------->|
       |                                |                 |

   1) The user at PU invokes:

      data.send.request("new-handle", handle-type, "hello1", 6, 0);

      The ASAP endpoint, in response, looks up the pool "new-handle" in
      its local cache but fails to find it.

   2) The ASAP endpoint of PU queues the message, and sends an
      ASAP_HANDLE_RESOLUTION request to the ENRP server asking for all
      information about pool "new-handle".

   3) A T1-ENRPrequest timer is started while the ASAP endpoint is
      waiting for the response from the ENRP server.

   4) The ENRP Server responds to the query with an
      ASAP_HANDLE_RESOLUTION_REPONSE
      ASAP_HANDLE_RESOLUTION_RESPONSE message that contains all the
      information about pool "new-handle".

   5) ASAP at PU cancels the T1-ENRPrequest timer and populate its local
      cache with information on pool "new-handle".

   6) Based on the server pooling policy of pool "new-handle", ASAP at
      PU selects the destination PE (PEx), sets up, if necessary, an
      SCTP association towards PEx (explicitly or implicitly), and send
      out the queued "hello1" user message.

4.8.2.  Send to a Cached Pool Handle

   This shows the event sequence when the ASAP user PU sends another
   message to the pool "new-handle" after what happened in
   Section 4.8.1.

     ENRP Server                       PU         new-handle:PEx

       |                                |                 |
       |                              +---+               |
       |                              | 1 |               |
       |                              +---+  2. "hello2"  |
       |                                |---------------->|
       |                                |                 |

   1) The user at PU invokes:

      pdata.send.request("new-handle", handle-type, "hello2", 6, 0);

      The ASAP endpoint, in response, looks up the pool "new-handle" in
      its local cache and find the mapping information.

   2) Based on the server pooling policy of "new-handle", ASAP at PU
      selects the PE (assume EPx is selected again), and sends out
      "hello2" message (assume the SCTP association is already set up).

4.9.  PE send failure

   When the ASAP endpoint in a PE or PU attempts to send a message to a
   PE and fails the failed sender will report the event as described in
   Section 3.5 .

   Additional primitive are also defined in this section to support
   those user applications that do not wish to use ASAP as the actual
   transport.

4.9.1.  Translation.Request Primitive

           Format: translation.request(Pool-Handle)

   If the address type is a Pool handle and a local handle translation
   cache exists, the ASAP endpoint should look within its translation
   cache and return the current known transport types, ports and
   addresses to the caller.

   If the Pool handle does not exist in the local handle cache or no
   handle cache exists, the ASAP endpoint will send an
   ASAP_HANDLE_RESOLUTION request using the Pool handle.  Upon
   completion of the handle resolution, the ASAP endpoint should
   populate the local handle cache (if a local handle cache is
   supported) and return the transport types, ports and addresses to the
   caller.

4.9.2.  Transport.Failure Primitive

       Format: transport.failure(Pool-Handle, Transport-address)

   If an external user encounters a failure in sending to a PE and is
   NOT using ASAP it can use this primitive to report the failure to the
   ASAP endpoint.  ASAP will send an ASAP_ENDPOINT_UNREACHABLE to the
   "home" ENRP server in response to this primitive.  Note ASAP SHOULD
   NOT send a ASAP_ENDPOINT_UNREACHABLE UNLESS the user has actually
   made a previous request to send data to the PE.

5.  Timers, Variables, and Thresholds

   The following is a summary of the timers, variables, and pre-set
   protocol constants used in ASAP.

5.1.  Timers

   T1-ENRPrequest -  A timer started when a request is sent by ASAP to
      the ENRP server (providing application information is queued).
      Normally set to 15 seconds.

   T2-registration -  A timer started when sending an ASAP_REGISTRATION
      request to the home ENRP server, normally set to 30 seconds.

   T3-deregistration -  A timer started when sending a deregistration
      request to the home ENRP server, normally set to 30 seconds.

   T4-reregistration -  This timer is started after successful
      registration into the ASAP ENRP handle space and is used to cause a re-
      registration at a periodic interval.  This timer is normally set
      to 10 minutes or 20 seconds less than the Life Timer parameter
      used in the registration request (whichever is less).

   T5-Serverhunt -  This timer is used during the ENRP server hunt
      procedure and is normally set to 120 10 seconds.

   T6-Serverannounce -  This timer gives the time between the sending of
      consecutive ASAP_SERVER_ANNOUNCE messages.  It is normally set to
      1 second.

   T7-ENRPoutdate -  This timer gives the time a server announcement is
      valid.  It is normally set to 5 seconds.

5.2.  Variables

   stale.cache.value -  A threshold variable that indicates how long a
      cache entry is valid for.

5.3.  Thresholds

   MAX-REG-ATTEMPT -  The maximum number of registration attempts to be
      made before a server hunt is issued.  The default value of this is
      set to 2.

   MAX-REQUEST-RETRANSMIT -  The maximum number of attempts to be made
      when requesting information from the local ENRP server before a
      server hunt is issued.  The default value for this is 2.

   RETRAN-MAX -  This value represents the maximum time between
      registration attmempts and puts a ceiling on how far the
      registration timer will back-off.  The default value for this is
      normally set to 60 seconds.

6.  Security Considerations

   Threats Introduced by Rserpool and Requirements for Security in
   Response to Threats [8] [9] 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
   -----------
   Security mechanism in response: ASAP must control the number of ASAP
   endpoint unreachable messages transmitted from the PU to the ENRP
   server.

   Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from
   the ENRP server
   -----------
   Security mechanism in response: ENRP server must control the number
   of ASAP_ENDPOINT_KEEP_AlIVE 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
   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 implementors of TLS for Rserpool.  For purposes of
   backwards compatibility, ENRP SHOULD support
   TLS_RSA_WITH_3DES_EDE_CBC_SHA.  Implementors 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) to the ENRP server.

   Threat 9 requires the ENRP protocol to limit the number of
   ASAP_ENDPOINT_KEEP_ALIVE messages to the PE (see section x.y??? in
   [8]).

6.1.  Chain of trust

   Security is mandatory to implement in Rserpool and is based on TLS
   implementation in all three architecture components that comprise
   Rserpool -- namely PU, PE and ENRP server.

   Here is a description of all possible data paths and a description of
   the security.

   PU <---> ENRP Server (authentication of ENRP server; queries over
   TLS)
   PE <----> ENRP servers (mutual authentication; registration/
   deregistration over TLS)

   ENRP <----> ENRP servers (mutual authentication; database updates
   using TLS)

   If all components of the system are secured and authenticated, the
   chain of trust is sound.  The root of the trust chain is the ENRP
   server.  If that is secured, then security will be enforced for all
   components that try to threats 1-7.  Rather we use existing IETF security
   protocols connect to provide it.

   Summary of interaction between secured and unsecured components: If
   the security services required.  TLS supports
   all these requirements PE is not secure and MUST be implemented.  The
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at tries to register with a
   minimum by implementers of TLS for Rserpool.  For purposes of
   backwards compatibility, secure ENRP SHOULD support
   TLS_RSA_WITH_3DES_EDE_CBC_SHA.  Implementers MAY also support any
   other ciphersuite.

   Threat 8 requires server,
   the ASAP protocol registration will be rejected.  If an insecure ENRP server tries
   to limit update the number database of ASAP
   Endpoint_Unreachable messages (see Section 3.5) to an ENRP server, then the update will be
   rejected.  If an insecure PU communicates with an ENRP server.

   Threat 9 requires server, it
   will get a response with the understanding that the response is not
   secured.

   **** The final case is the PU sending a secured request to ENRP.  It
   might be that ENRP protocol and PEs are not secured and that is OK.  The
   intent may be to limit secure the number of
   ASAP_ENDPOINT_KEEP_ALIVE messages to communication over the internet. ****

   Summary:

   Unsecured architecture components can all communicate with each other
   thus establishing a chain of trust.  Secured PE (see section x.y??? in
   [7]).

6.1. and ENRP components
   reject any communications with unsecured ENRP and PE components.

   If the above is enforced, then a chain of trust is established for
   the Rserpool user.

6.2.  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
   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]
   [5] or TLS over TCP as described in RFC2246 [3].  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.

7.  Acknowledgments

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

8.  References

8.1.  Normative References

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

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

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

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

   [5]  Stewart, R., Xie, Q., Stillman, M.,  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
        Security over Stream Control Transmission Protocol", RFC 3436,
        December 2002.

   [6]  Tuexen, M. and T. Dreibholz, "Reliable Server Pooling Policies",
        draft-ietf-rserpool-policies-03 (work in progress),
        September 2006.

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

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

   [7]  Xie, Q.,
        draft-ietf-rserpool-common-param-10 (work in progress),
        February 2006.

   [8]  Stewart, R., Stillman, M., Tuexen, M., and A.
        Silverton, "Endpoint Handlespace Redundancy Protocol (ENRP)",
        draft-ietf-rserpool-enrp-12
        draft-ietf-rserpool-enrp-13 (work in progress), July 2005.

   [8] February 2006.

   [9]  Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M.
        Holdrege, "Threats Introduced by Rserpool and Requirements
        for Security in Response response to  Threats",
        draft-ietf-rserpool-threats-05 (work in progress), July 2005.

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

8.2.  Informational References (non-normative)

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

Authors' Addresses

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

   Phone:
   Email: rrs@cisco.com

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

   Phone:
   Email: qxie1@email.mot.com

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

   Phone:
   Email: maureen.stillman@nokia.com

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

   Email: tuexen@fh-muenster.de

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

   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.

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. IETF
   Administrative Support Activity (IASA).