Network Working Group                                         R. Stewart
Internet-Draft                                       Cisco Systems, Inc.
Expires: December 29, 2002                                        Q. Xie
                                                          Motorola, Inc.
                                                             M. Stillman
                                                                   Nokia
                                                               M. Tuexen
                                                              Siemens AG
                                                           June 30, 2002


                Aggregate Server Access Protocol (ASAP)
                    draft-ietf-rserpool-asap-04.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

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

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

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

   This Internet-Draft will expire on December 29, 2002.

Copyright Notice

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

Abstract

   Aggregate Server Access Protocol (ASAP) in conjunction with the
   Endpoint Name Resolution Protocol (ENRP) [6] provides a high
   availability data transfer mechanism over IP networks.  ASAP uses a
   name-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



Stewart, et al.         Expires December 29, 2002               [Page 1]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


   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 that ASAP messages passed between
   PE's and ENRP servers MUST use SCTP.

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































Stewart, et al.         Expires December 29, 2002               [Page 2]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


Table of Contents

   1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  5
   1.1     Definitions  . . . . . . . . . . . . . . . . . . . . . . .  5
   1.2     Organization of this document  . . . . . . . . . . . . . .  7
   1.3     Scope of ASAP  . . . . . . . . . . . . . . . . . . . . . .  7
   1.3.1   Extent of the Namespace  . . . . . . . . . . . . . . . . .  7
   1.4     Conventions  . . . . . . . . . . . . . . . . . . . . . . .  7
   2.      Message Definitions  . . . . . . . . . . . . . . . . . . .  8
   2.1     ASAP Parameter Formats . . . . . . . . . . . . . . . . . .  8
   2.2     ASAP Messages  . . . . . . . . . . . . . . . . . . . . . .  8
   2.2.1   REGISTRATION message . . . . . . . . . . . . . . . . . . .  9
   2.2.2   DEREGISTRATION message . . . . . . . . . . . . . . . . . .  9
   2.2.3   REGISTRATION_RESPONSE message  . . . . . . . . . . . . . . 10
   2.2.4   DEREGISTRATION_RESPONSE message  . . . . . . . . . . . . . 10
   2.2.5   NAME_RESOLUTION message  . . . . . . . . . . . . . . . . . 11
   2.2.6   NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . . . 11
   2.2.7   NAME_UNKNOWN message . . . . . . . . . . . . . . . . . . . 12
   2.2.8   ENDPOINT_KEEP_ALIVE message  . . . . . . . . . . . . . . . 12
   2.2.9   ENDPOINT_KEEP_ALIVE_ACK message  . . . . . . . . . . . . . 12
   2.2.10  ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . . . 13
   2.2.11  SERVER_HUNT message  . . . . . . . . . . . . . . . . . . . 13
   2.2.12  SERVER_HUNT_RESPONSE message . . . . . . . . . . . . . . . 13
   2.2.13  COOKIE message . . . . . . . . . . . . . . . . . . . . . . 13
   2.2.14  COOKIE_ECHO message  . . . . . . . . . . . . . . . . . . . 14
   3.      Procedures . . . . . . . . . . . . . . . . . . . . . . . . 15
   3.1     Registration . . . . . . . . . . . . . . . . . . . . . . . 15
   3.2     Deregistration . . . . . . . . . . . . . . . . . . . . . . 16
   3.3     Name resolution  . . . . . . . . . . . . . . . . . . . . . 17
   3.4     Endpoint keep alive  . . . . . . . . . . . . . . . . . . . 18
   3.5     Reporting unreachable endpoints  . . . . . . . . . . . . . 19
   3.6     ENRP server hunt procedures  . . . . . . . . . . . . . . . 19
   3.7     Handle ASAP to ENRP Communication Failures . . . . . . . . 20
   3.7.1   SCTP Send Failure  . . . . . . . . . . . . . . . . . . . . 20
   3.7.2   T1-ENRPrequest Timer Expiration  . . . . . . . . . . . . . 20
   3.8     Cookie handling procedures . . . . . . . . . . . . . . . . 21
   4.      The ASAP Interfaces  . . . . . . . . . . . . . . . . . . . 22
   4.1     Registration.Request Primitive . . . . . . . . . . . . . . 22
   4.2     Deregistration.Request Primitive . . . . . . . . . . . . . 22
   4.3     Cache.Populate.Request Primitive . . . . . . . . . . . . . 23
   4.4     Cache.Purge.Request Primitive  . . . . . . . . . . . . . . 23
   4.5     Data.Send.Request Primitive  . . . . . . . . . . . . . . . 23
   4.5.1   Sending to a Pool Handle . . . . . . . . . . . . . . . . . 24
   4.5.2   Pool Element Selection . . . . . . . . . . . . . . . . . . 25
   4.5.2.1 Round Robin Policy . . . . . . . . . . . . . . . . . . . . 25
   4.5.2.2 Least Used Policy  . . . . . . . . . . . . . . . . . . . . 25
   4.5.2.3 Least Used with Degradation Policy . . . . . . . . . . . . 26
   4.5.2.4 Weighted Round Robin Policy  . . . . . . . . . . . . . . . 26



Stewart, et al.         Expires December 29, 2002               [Page 3]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


   4.5.3   Sending to a Pool Element Handle . . . . . . . . . . . . . 26
   4.5.4   Send by Transport Address  . . . . . . . . . . . . . . . . 27
   4.5.5   Message Delivery Options . . . . . . . . . . . . . . . . . 27
   4.6     Data.Received Notification . . . . . . . . . . . . . . . . 28
   4.7     Error.Report Notification  . . . . . . . . . . . . . . . . 29
   4.8     Examples . . . . . . . . . . . . . . . . . . . . . . . . . 29
   4.8.1   Send to a New Pool . . . . . . . . . . . . . . . . . . . . 29
   4.8.2   Send to a Cached Pool Handle . . . . . . . . . . . . . . . 31
   4.9     PE send failure  . . . . . . . . . . . . . . . . . . . . . 31
   4.9.1   Translation.Request Primitive  . . . . . . . . . . . . . . 31
   4.9.2   Transport.Failure Primitive  . . . . . . . . . . . . . . . 32
   5.      Variables, Timers, and Thresholds  . . . . . . . . . . . . 33
   5.1     Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 33
   5.2     Thresholds and Variables . . . . . . . . . . . . . . . . . 33
   6.      Security Considerations  . . . . . . . . . . . . . . . . . 34
   7.      Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 35
           Normative References . . . . . . . . . . . . . . . . . . . 36
           Informational References (non-normative) . . . . . . . . . 37
           Authors' Addresses . . . . . . . . . . . . . . . . . . . . 37
           Full Copyright Statement . . . . . . . . . . . . . . . . . 38































Stewart, et al.         Expires December 29, 2002               [Page 4]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


1. Introduction

   Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6]
   provides a high availability data transfer mechanism over IP
   networks.  ASAP uses a name-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 name, a.k.a, a
   server pool, ASAP will select one Pool Element (PE), based on the
   current load sharing policy indicated by the server pool, and deliver
   the message to the selected PE.

   While delivering the message, ASAP monitors the reachability of the
   selected PE.  If it is found unreachable, before notifying the sender
   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
   instances of a server pool.

   ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a
   high availability name 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 ASAP user) 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
   name space a.k.a.  ENRP [6].

1.1 Definitions

   This document uses the following terms:

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

   Operation scope: The part of the network visible to Pool Users by a
      specific instance of the reliable server pooling protocols.

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



Stewart, et al.         Expires December 29, 2002               [Page 5]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


   Pool handle (or pool name): A logical pointer to a pool.  Each server
      pool will be identifiable in the operation scope of the system by
      a unique pool handle or "name".

   Pool Element (PE): A server entity having registered to a pool.

   Pool User (PU): A server Pool User.

   Pool Element handle (PE handle): A logical pointer to a particular
      Pool Element in a pool,

   ENRP server: A server program running on a host that manages the name
      space collectively with its peer ENRP servers and replies to the
      service requests from any Pool User or Pool Element.

   Home ENRP server: The ENRP server to which a Pool Element currently
      uses.  A PU or PE normally chooses the ENRP server on their local
      host as the home ENRP server (if one exists).  A PU or PE should
      only have one home ENRP server at any given time.  Note that the
      "home" ENRP server concept exists only within ASAP.  ENRP servers
      provide no special handling of PE's or PU's.  Having a "home" ENRP
      server only provides a mechanism to minimize the number of
      associations a given PE will have.

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

   ENRP server channel: Defined by a well known multicast IP address and
      a well known port number, OR a well known list of transport
      addresses for a group of ENRP servers spanning an operational
      scope.  All ENRP servers in an operation scope can communicate
      with one another through this channel via either multicast OR
      direct point to point SCTP associations.

   ENRP name domain: Defined by the combination of the ENRP client
      channel and the ENRP server channel in the operation scope.

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




Stewart, et al.         Expires December 29, 2002               [Page 6]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


1.2 Organization of this document

   Section 2 details ASAP message formats.  In Section 3 we give the
   detailed ASAP procedures for the ASAP implementer.  And in Section 4
   we give the details of the ASAP interface, focusing on the
   communication primitives between the applications above ASAP and ASAP
   itself, and the communications primitives between ASAP and SCTP (or
   other transport layer).  Also included in this discussion is 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
   processing of a transaction this transaction may be lost.  Some
   services 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 Namespace

   The scope of the ASAP/ENRP is NOT Internet wide.  The namespace is
   neither hierarchical nor arbitrarily large like DNS.  We propose a
   flat peer-to-peer model.  Pools of servers will exist in different
   administrative domains.  For example, suppose we want to use ASAP/
   ENRP.  First, the PU may use DNS to contact an ENRP server.  Suppose
   a PU in North America wishes to contact the 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, that is, the ENRP
   client channel in Japan.  From there the PU would query the ENRP
   server 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].










Stewart, et al.         Expires December 29, 2002               [Page 7]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


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, a number in a pair of parentheses may follow
   the field name to indicate the length of the field in number of
   octets.

2.1 ASAP Parameter Formats

   The basic message format and all parameter formats can be found in
   ENRP-ASAP [5].  Note also that ALL ASAP message exchanged between the
   ENRP server and either a PE or PU MUST user SCTP.  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
   or ENRP-ASAP [5].  The parameter descriptions may also be found  in
   Section 3 of ENRP-ASAP [5].

   The following ASAP message types are defined in this section:



   Type       Message Name
   -----      -------------------------
   0x00       - (reserved by IETF)
   0x01       - Registration
   0x02       - Deregistration
   0x03       - Registration Response
   0x04       - Deregistration Response
   0x05       - Name Resolution
   0x06       - Name Resolution Response
   0x07       - Name Unknown
   0x08       - Endpoint Keep Alive
   0x09       - Endpoint Keep Alive Acknowledgement
   0x0a       - Endpoint Unreachable
   0x0b       - Server Hunt
   0x0c       - Server Hunt Response
   0x0d       - Cookie
   0x0e       - Cookie-Echo







Stewart, et al.         Expires December 29, 2002               [Page 8]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


2.2.1 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 = 0x1  |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Element Parameter                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The pool handle parameter field specifies the name to be registered.
   The PE Parameter field shall be filled in by the registrant endpoint
   to declare its transports and addresses, server pooling policy and
   value, and other operation preferences.  Note that the registration
   message MUST use SCTP and the IP addresses of the PE registered
   within the Pool Element Parameter MUST be a subset of the addresses
   of the SCTP association irrespective of the transport protocol
   regestered by the PE.

2.2.2 DEREGISTRATION message

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


   The PE sending the DEREGISTRATION shall 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 only a PE may only deregister
   itself.












Stewart, et al.         Expires December 29, 2002               [Page 9]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


2.2.3 REGISTRATION_RESPONSE message

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x3  |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Element Parameter                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Operational Error (optional)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Operational Error

   This optional TLV parameter is included if an error occured during
   the registration process.  If the registration was sucessful this
   parameter is not included.

2.2.4 DEREGISTRATION_RESPONSE message

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x4  |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Element Parameter                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Operational Error (optional)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Operational Error

   This optional TLV parameter is included if an error occured during
   the deregistration process.  If the deregistration was sucessful this
   parameter is not included.














Stewart, et al.         Expires December 29, 2002              [Page 10]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


2.2.5 NAME_RESOLUTION message

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

   This message is sent to a ENRP server via an SCTP association to
   request translation of the Pool Handle to a list of Pool Elements.

2.2.6 NAME_RESOLUTION_RESPONSE message

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type = 0x6  |0|0|0|0|0|0|0|0|        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                     Pool Handle Parameter                     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                Overall PE Selection Policy                    :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                    Pool Element Parameter 1                   :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                              ...                              :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                    Pool Element Parameter N                   :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Overall PE Selection Policy:

   This is a PE selection policy parameter.  Indicates the overall
   selection policy of the pool.  If not present, round-robin is
   assumed.

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













Stewart, et al.         Expires December 29, 2002              [Page 11]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


2.2.7 NAME_UNKNOWN message

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

   This message is returned by the ENRP server to indicate that the
   requested Pool Handle hold no registered PE's.

2.2.8 ENDPOINT_KEEP_ALIVE message

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

   This message is sent to a PE by the ENRP server has a "health" check.
   If the transport level Heart Beat mechanism is insufficient (usually
   this means that time outs are set for too long or heartbeats are not
   frequent enough), this adds heartbeat messages with the goal of
   determining health status in a more timely fashion.

2.2.9 ENDPOINT_KEEP_ALIVE_ACK message

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

   This message is sent by the PE to the ENRP server has an
   acknowledgment to the ENDPOINT_KEEP_ALIVE message.











Stewart, et al.         Expires December 29, 2002              [Page 12]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


2.2.10 ENDPOINT_UNREACHABLE message

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

   A PE or PU will send this message to an ENRP server to report the
   unreachability of the specified PE.

2.2.11 SERVER_HUNT message

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

   This message is used by either a PE or PU to request service.  It is
   sent on the ENRP client channel.

2.2.12 SERVER_HUNT_RESPONSE message

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

   This message is used by a ENRP server to respond to a PU or PE.  It
   is sent over a specific SCTP association which is established using
   the IP address and Port number received by the ENRP server in the
   respective Server Hunt message that this message is in response to.

2.2.13 COOKIE message

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

   This message is sent by a PE to a PU.





Stewart, et al.         Expires December 29, 2002              [Page 13]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


2.2.14 COOKIE_ECHO message

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

   This message is sent by a PU to a PE in case of a failover.  The
   Cookie Parameter is one received latest from the failed PE.








































Stewart, et al.         Expires December 29, 2002              [Page 14]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


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.

3.1 Registration

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

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

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

   R2) The ASAP endpoint MUST formulate a Registration message as
      defined in Section 2.2.1 In formulating the message the ASAP
      endpoint MUST:



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

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

      R2.3) Fill in the registration life time parameter with the number
         of seconds that this registration is good 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 EACH type of
         transport the PE is willing to support.

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

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



Stewart, et al.         Expires December 29, 2002              [Page 15]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


   R4) Start a T2-registration timer.

   If the T2-registration timer expires before receiving a
   REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
   received from the SCTP layer, the ASAP endpoint 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 SHOULD restart the registration procedure.

   At the reception of the registration response, the ASAP endpoint MUST
   stop the T2-Registration timer.  If the response indicated 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 must either re-attempt registration after
   correcting the error or return a failure indication to the ASAP
   endpoints upper layer.  The ASAP endpoint MUST NOT 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 attempts it makes in a local variable.  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 PE wishes to deregister from its server pool
   (normally via an upper layer requests see Section 4.2) it SHOULD use
   the following procedures.  Note that an alternate method of
   deregistration is to NOT re-register and to allow the registration
   lift time to expire.

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

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



Stewart, et al.         Expires December 29, 2002              [Page 16]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


   D2) Fill in the PE Identifier.  The identifier MUST be the same one
      used during registration.

   D3) Send the deregistration message to the Home ENRP server using the
      SCTP association.

   D4) Start a T3-Deregistration timer.

   If the T3-Deregistration timer expires before receiving a
   REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is
   received from the SCTP layer, the ASAP endpoint 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 SHOULD restart the deregistration procedure.

   At the reception of the deregistration response, the ASAP endpoint
   MUST stop the T3-deregistration timer.

   Note 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 ignore these
   requests and exit.

3.3 Name resolution

   At any time a PE or PU may wish to resolve a name.  This usually will
   occur when a Endpoint sends to a Pool handle ( Section 4.5.1) or
   requests a cache population (Section 4.3) but may 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 Endpoint (PE or PU)
   wishes to resolve a name it MUST take the following actions:

   NR1) Fill in a NAME_RESOLUTION message ( Section 2.2.5) with the Pool
      Handle to be resolved.  z

   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 proceed to step NR3.

   NR3) Send the NAME_RESOLUTION message to the Home ENRP server using
      SCTP.

   NR4) Start a T1-ENRPrequest timer.

   If the T1-ENRPrequest timer expires before receiving a response
   message, or a SEND.FAILURE notification is received from the SCTP
   layer, the ASAP endpoint SHOULD start the Server Hunt procedure (see
   Section 3.6) in an attempt to get service from a different ENRP



Stewart, et al.         Expires December 29, 2002              [Page 17]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


   server.  After establishing a new Home ENRP server the ASAP endpoint
   SHOULD restart the name resolution procedure.

   At the reception of the response message (either a
   NAME_RESOLUTION_RESPONSE or NAME_UNKNOWN) the endpoint MUST stop its
   T1-ENRPrequest timer.  After stopping the T1 timer the endpoint
   SHOULD process the name response 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 name resolutions made.  If such a cache is used it SHOULD:

   C1) Be consulted before requesting a name resolution.

   C2) Have a stale timeout time associated with the cache so that even
      in the event of a cache-hit, if the cache is "stale" it will cause
      a new name_resolution to be issued to update the cache.

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

   C4) If the cache is NOT stale, the endpoint SHOULD NOT make a
      name_resolution request but instead return 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 a ENDPOINT_KEEP_ALIVE message ( Section 2.2.8).  Upon
   reception of an ENDPOINT_KEEP_ALIVE 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 Registration.  If the Pool
      Handle does not match silently discard the message.

   KA2) Send a ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.9) by:



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

      KA2.2) Fill in the PE Identifier that was used with this PE for



Stewart, et al.         Expires December 29, 2002              [Page 18]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


         registration.

      KA2.3) Send off the ENDPOINT_KEEP_ALIVE_ACK message via the
         appropriate SCTP association for that ENRP server.


3.5 Reporting unreachable endpoints

   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 a ASAP user report via the Transport.Failure Primitive
   (Section 4.9.2).  In either case the ASAP endpoint SHOULD report the
   unavailablilty of the PE by sending a ENDPOINT_UNREACHABLE message to
   its home ENRP server.  The Endpoint should fill in the Pool Handle
   and PE identifier of the unreachable endpoint.  The message MUST be
   sent via SCTP to the Endpoints Home ENRP server.

3.6 ENRP server hunt procedures

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

   SH1) The PE or PU shall send a SERVER_HUNT message (Section 2.2.11)
      over the ENRP client channel.  If the client channel is a multi-
      cast destination only one message is needed.  If the client
      channel is a set of uni-cast addresses then a message SHOULD be
      sent to no more than three ENRP server unicast address.  A
      Endpoint MUST NOT send to more than three at any single time.

   SH2) The Endpoint shall start a T5-Serverhunt timer.

   SH3) If the Endpoint receives a SERVER_HUNT_RESPONSE message the
      endpoint MUST stop its T5-Serverhunt timer.  The Endpoint SHOULD
      also reset the T5-Serverhunt value to its initial value and then
      proceed to step SH5.

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



      SH4.1) The endpoint MUST double the value of the T5-Serverhunt
         timer.

      SH4.2) The endpoint SHOULD Repeat sending a server hunt message by
         proceeding to step SH1.  Note that if the server hunt procedure



Stewart, et al.         Expires December 29, 2002              [Page 19]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


         are using a unicast channel the endpoint SHOULD attempt to
         select a different set of ENRP servers to send the SERVER_HUNT
         message to.

   SH5) The PE or PU shall pick one of the ENRP servers that have
      responded as its new home ENRP server, and send all its subsequent
      the namespace service requests to this new home ENRP server.

   Upon the reception of the SERVER_HUNT message, an ENRP server shall
   always reply to the PE with a SERVER_HUNT_RESPONSE message.

3.7 Handle ASAP to ENRP Communication Failures

   Three types of failure may occur when the ASAP endpoint at an
   endpoint tries to communicate with the 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 indicates that the SCTP layer failed to deliver a message sent
   to the ENRP server.  In other words, the ENRP server is currently
   unreachable.

   In such a case, the ASAP endpoint should not re-send the failed
   message.  Instead, it should discard the failed message and start the
   ENRP server hunt procedure as described in Section 3.6

3.7.2 T1-ENRPrequest Timer Expiration

   When a T1-ENRPrequest timer expires, the ASAP should re-send the
   original request to the ENRP server and re-start the T1-ENRPrequest
   timer.  In parallel, a SERVER_HUNT message should be issued per
   Section 3.6

   This should be repeated up to '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 timer
   should be discarded.  Note that if an alternate ENRP server responds
   the ASAP endpoint SHOULD adopt the responding ENRP server as its new
   "home" server and resend the request to the new "home" server.




Stewart, et al.         Expires December 29, 2002              [Page 20]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


3.8 Cookie handling procedures

   Whenever a PE wants and a control channel exists it can send a Cookie
   Message to the PU via the control channel.  The ASAP layer at the PU
   stores the Cookie parameter and discards an older one if it is
   present.

   If the ASAP layer detects a failure and initiates a failover to a
   different PE, the ASAP layer sends the last received Cookie parameter
   in a Cookie Echo message to the new PE.  The upper layer may be
   involved in the failover procedure.

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

































Stewart, et al.         Expires December 29, 2002              [Page 21]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


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

   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 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 namespace,
   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 namespace 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 a 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 DEREGISTRATION message will be sent by ASAP endpoint to the home
   ENRP server (see Section 2.2.2 and Section 3.2).







Stewart, et al.         Expires December 29, 2002              [Page 22]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


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 name translation
   cache exists, the ASAP endpoint should initiate a mapping information
   query by sending a NAME.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 NAME.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 name 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.



Stewart, et al.         Expires December 29, 2002              [Page 23]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


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



Stewart, et al.         Expires December 29, 2002              [Page 24]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


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

   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 namespace with a new policy value.
   Re-registration shall be done by simply sending another REGISTRATION
   to its home ENRP server (See Section 2.2.1).

   Four basic server pooling policies are defined in ASAP, namely the
   Round Robin, Least Used, Least Used Degrading and Weighted Round
   Robin.  The following sections describes each of these policies.

4.5.2.1 Round Robin Policy

   When a 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



Stewart, et al.         Expires December 29, 2002              [Page 25]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


   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 the policy back to Least Used with
   Degradation.

4.5.2.4 Weighted Round Robin Policy

   [TBD]

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



Stewart, et al.         Expires December 29, 2002              [Page 26]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


   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 name resolution on pool handle by
         sending a NAME.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.




Stewart, et al.         Expires December 29, 2002              [Page 27]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


   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, this option allows the senders ASAP
      endpoint to re-select an alternate PE from the same pool if one
      exists, and silently re-send the message to this newly selected
      endpoint.

   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.




Stewart, et al.         Expires December 29, 2002              [Page 28]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


   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 a
   ASAP Pool Element handle.

   A) If the name 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).



Stewart, et al.         Expires December 29, 2002              [Page 29]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


     ENRP Server                       PU         new-name:PEx

       |                                |                 |
       |                              +---+               |
       |                              | 1 |               |
       |  2. NAME_RESOLUTION          +---+               |
       |<-------------------------------|                 |
       |                              +---+               |
       |                              | 3 |               |
       |  4. NAME_RESOLUTION_REPONSE  +---+               |
       |------------------------------->|                 |
       |                              +---+               |
       |                              | 5 |               |
       |                              +---+  6. "hello1"  |
       |                                |---------------->|
       |                                |                 |


   1) The user at PU invokes:

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

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

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

   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 a
      NAME_RESOLUTION_REPONSE message that contains all the information
      about pool "new-name".

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

   6) Based on the server pooling policy of pool "new-name", 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.








Stewart, et al.         Expires December 29, 2002              [Page 30]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


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-name" after what happened in Section 4.8.1.


     ENRP Server                       PU         new-name:PEx

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


   1) The user at PU invokes:

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

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

   2) Based on the server pooling policy of "new-name", 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 name 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 name cache or no name



Stewart, et al.         Expires December 29, 2002              [Page 31]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


   cache exists, the ASAP endpoint will send a NAME.RESOLUTION request
   using the Pool-Handle.  Upon completion of the name resolution, the
   ASAP endpoint should populate the local name cache (if a local name
   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 ENDPOINT_UNREACHABLE to the "home"
   ENRP server in response to this primitive.  Note ASAP SHOULD NOT send
   a ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous
   request to the translate.request() primitive.



































Stewart, et al.         Expires December 29, 2002              [Page 32]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


5. Variables, Timers, and Thresholds

   The following is a summary of the variables, timers, 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 a 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 name 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 nto during the ENRP server hunt
      procedure and is normally set to 120 seconds.


5.2 Thresholds and Variables

   max-reg-attempt - The maximum number of registration attempts to be
      made before a server hunt is issued.

   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.

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













Stewart, et al.         Expires December 29, 2002              [Page 33]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


6. Security Considerations

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

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

   For networks that cannot or do not wish to use IPsec and prefer
   instead TLS, implementations MUST support TLS with SCTP as described
   in SCTPTLSls [8] 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.  This is also not
   difficult, but it is in contrast to the IPsec solution which is
   transparently layered below Rserpool.

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

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










Stewart, et al.         Expires December 29, 2002              [Page 34]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


7. Acknowledgments

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















































Stewart, et al.         Expires December 29, 2002              [Page 35]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


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., Allen, C., Treese, W., Karlton, P., Freier, A. and
        P. Kocher, "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. and M. Tuexen, "Aggregate
        Server Access Protocol and Endpoint Name Resolution Protocol
        Common Parameters", draft-ietf-rserpool-common-param-01 (work in
        progress), June 2002.

   [6]  Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution
        Protocol (ENRP)", draft-ietf-rserpool-enrp-04 (work in
        progress), May 2002.

   [7]  Bellovin, S., "On the Use of SCTP with IPsec", draft-ietf-ipsec-
        sctp-03 (work in progress), February 2002.

   [8]  Rescorla, E., Tuexen, M. and A. Jungmaier, "TLS over SCTP",
        draft-ietf-tsvwg-tls-over-sctp-00 (work in progress), November
        2001.




















Stewart, et al.         Expires December 29, 2002              [Page 36]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


Informational References (non-normative)

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


Authors' Addresses

   Randall R. Stewart
   Cisco Systems, Inc.
   8725 West Higgins Road
   Suite 300
   Chicago, IL  60631
   USA

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


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

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


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

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


   Michael Tuexen
   Siemens AG
   ICN WN CC SE 7
   D-81359 Munich
   Germany

   Phone: +49 89 722 47210
   EMail: Michael.Tuexen@icn.siemens.de




Stewart, et al.         Expires December 29, 2002              [Page 37]


Internet-Draft    Aggregate Server Access Protocol (ASAP)      June 2002


Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

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



















Stewart, et al.         Expires December 29, 2002              [Page 38]