Network Working Group                                       R. R. Stewart
INTERNET-DRAFT                                         Cisco Systems Inc.
                                                                   Q. Xie
                                                                 Motorola

expires in six months                                        June 01,2001                                    November 19,2001

                Aggregate Server Access Protocol (ASAP)
                  <draft-ietf-rserpool-asap-00.txt>
                  <draft-ietf-rserpool-asap-01.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.

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

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

Abstract

    Aggregate Server Access Protocol (ASAP) in conjunction with ENRP the
    Endpoint Name Resolution Protocol (ENRP) [ENRP] 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.

    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) [SCTP].

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

Table Of Contents

    1. Introduction................................................ 3 Introduction...............................................3
       1.1 Definitions............................................... 3 Definitions............................................3
       1.2 Organization of this document............................. 5 document..........................5
       1.3 Scope of ASAP............................................. 5 ASAP..........................................5
	   1.3.1 Extent of the name space............................... 5 Namespace..........................5
    2. Conventions................................................. 5 Conventions................................................5
    3. Message Summary............................................. 5 Definitions........................................5
       3.1 PE ASAP Parameter Definition................................... 6 Formats.................................6
	   3.1.1 IPv4 Address Parameter...........................7
	   3.1.2 IPv6 Address Parameter ..........................7
	   3.1.3 Pool Element Parameter...........................7
	   3.1.4 Pool Handle Parameter............................8
	   3.1.5 Authorization Parameter..........................8
       3.2 ASAP Message Formats...................................9
	   3.2.1 REGISTRATION message...................................... 6
     3.3 message.............................10
	   3.2.2 DEREGISTRATION message.................................... 7
     3.4 message...........................10
	   3.2.3 REGISTRATION_RESPONSE message............................. 7
     3.5 message....................11
	   3.2.4 NAME_RESOLUTION message................................... 8
     3.6 message..........................11
	   3.2.5 NAME_RESOLUTION_RESPONSE message.......................... 8
     3.7 message.................12
	   3.2.6 NAME_UNKNOWN message...................................... 9
     3.8 UPDATE_POLICY_VALUE message............................... 9
     3.9 message.............................12
	   3.2.7 ENDPOINT_KEEP_ALIVE message............................... 9
     3.10 message......................12
	   3.2.8 ENDPOINT_UNREACHABLE message ............................10
     3.11 ....................12
	   3.2.9 SERVER_HUNT message .....................................10
     3.12 .............................13
	   3.2.10 SERVER_HUNT_RESPONSE message.............................11 message....................13
    4. The ASAP Interfaces.........................................11 Interfaces........................................13
       4.1 Registration.Request Primitive............................11 Primitive.........................13
       4.2 Deregistration.Request Primitive..........................12 Primitive.......................14
       4.3 Cache.Populate.Request Primitive..........................12 Primitive.......................14
       4.4 Cache.Purge.Request Primitive.............................12 Primitive..........................14
       4.5 Data.Send.Request Primitive...............................12 Primitive............................14
	   4.5.1 Sending to a Pool.......................................13 Pool Handle.........................15
	   4.5.2 Pool Element Selection.................................14 Selection...........................16
		 4.5.2.1 Pool selection policy - Round Robin.................14 Robin Policy.......................16
		 4.5.2.2 Pool Selection Policy - Least Used Policy...........15 Policy........................17
		 4.5.2.3 Pool Selection Policy - Least Used with Degradation
               Policy..............................................15 Policy.......17
		 4.5.2.4 Pool Selection Policy - Weighted round robin........15 Round Robin Policy..............17
           4.5.3 Sending to a Pool Element Handle.......................15 Handle.................17
	   4.5.4 Send by Transport Address..............................16 Address........................18
	   4.5.5 Options................................................16  Message Delivery Options........................18
       4.6 Data.Received Notification................................18 Notification.............................19
       4.7 Error.Report Notification.................................18 Notification..............................20
       4.8 SCTP primitives...........................................18 Examples...............................................20
	   4.8.1 SCTP SEND Primitive....................................18
      4.8.2 SCTP RECEIVE Primitive.................................19
      4.8.3 SCTP SET.PRIMARY Primitive.............................19
      4.8.4 SCTP DATA.ARRIVE Notification..........................19
      4.8.5 SCTP SEND.FAILURE Notification.........................19
      4.8.6 SCTP COMMUNICATION.LOST Notification...................20
      4.8.7 SCTP NETWORK.STATUS.CHANGE Notification................20
     4.9 Examples..................................................20
      4.9.1 Send to an Unknown Name................................20
      4.9.2 a New Pool Handle........................20
	   4.8.2 Send to a Cached Name..................................21
     4.10 Pool Handle.....................21
       4.9 Handle ASAP to ENRP Communication Failures...............22
      4.10.1 Failures.............22
	   4.9.1 SCTP Send Failure.....................................22
      4.10.2 Failure................................22
	   4.9.2 T1-ENRPrequest Timer Expiration.......................22
      4.10.3 Expiration..................22
	   4.9.3 Handle ENDPOINT_KEEP_ALIVE Messages...................22 Messages..............22
	   4.9.4 Home ENRP Server Hunt............................23
    5. Variables, Timer Values, Timers, and Thresholds....................23 Constants...........................23
       5.1 Timer values..............................................23 Timers.................................................23
       5.2 Thresholds................................................23 Thresholds.............................................23
    6. References..................................................23 Security Considerations....................................24
    7. Acknowledgements............................................24 References.................................................24
    8. Acknowledgements...........................................24
    9. Authors' Addresses.........................................24

1. Introduction

    Aggregate Server Access Protocol (ASAP) in conjunction with ENRP
    [ENRP] 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 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] 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 availiablity name space
    a.k.a. ENRP.

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

    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 Element (PE):
         A server entity having registered to a pool.

    Pool user User (PU):
         A server pool user. Pool element User.

    Pool Element handle (or endpoint (PE handle):
         A logical pointer to a particular pool element 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 User or
         Pool Element.

    Home ENRP server:
        The ENRP server to which a Pool element Element currently
         belongs. Pool elements uses. A PU
	or PE normally choose chooses the ENRP server on their local host as
	the home ENRP server (if one exists). A Pool element shall PU or PE should only
	have one home ENRP server at any given time. Both the PE and the server shall
         keep track of this master/slave relationship between them.

    ENRP server takeover:
         The event that a remote ENRP server takes the ownership
         of all the Pool elements on a host and becomes their
         home server.

    Caretaker ENRP server:
        The ENRP server on a remote host which takes ownership
        of all PEs on a host because of the absence of an
        active local

    ENRP server.

    PU client channel:
        The communication channel through which a an ASAP Pool User (either a
	PE or PU) requests for ENRP namespace service. The PU client channel
	is usually defined by the transport address of the
        home server and a well known port number.

    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.

    ENRP name domain:
        Defined by the combination of the PU 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).

1.2 Organization of this document

    Chapter 3 details ASAP message formats. In Chapter 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.  Chapter 5
    provides settable protocol values.

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 name space 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 I we want to use
    ASAP/ENRP.  First, the PU will may use DNS to contact an ENRP server.
    Suppose a PU in North America wish wishes to contact the server pool in
    Japan instead of North America. The PU would use DNS to get the IP
    address of the Japanese server pool domain, that is, the address of
    an ENRP server('s) server(s) in Japan. From there the PU would query the
    ENRP server and then directly contact the PE's PE(s) of interest.

2. Conventions

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

3. Message Summary Definitions

   All messages as well as their fields described below MUST 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 filed name to indicate the length of the field in number of
   octets.

3.1 PE ASAP Parameter Definition

    This parameter is used in multiple Formats

   ASAP message to represent parameters are defined in a PEP
    or endpoint and the associated information, such Type-length-value (TLV) format as its transport
    address(es), load control, and other operational status information
    of the PE.

    The parameter is defined to support PEs with up to 8 different IPv4
    transport addresses.
   shown below.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        IP address #0                          |
   +-------------------------------+-------------------------------+
   |                        IP address #1                          |
   +-------------------------------+-------------------------------+
   \                     \                      \                  \
   /                     /                      /                  /
   \                     \                      \                  \
   +-------------------------------+-------------------------------+
   |                        IP address #7                          |
   +-------------------------------+-------------------------------+
   |          SCTP Port            |         Padding               |
   +-------------------------------+-------------------------------+          Parameter Type       |  Load sharing policy type       Parameter Length        |       Policy
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                       Parameter Value            |
   +---------------+---------------+---------------+---------------+                         :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameter Type:  16 bits (unsigned integer)

      The size Type field is a 16 bit identifier of the type of parameter.
      It takes a PE Parameter is 40 octets.

3.2 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 value of 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        ENRP endpoint message identifier #1 = 0x18038688       |
   +-------------------------------+-------------------------------+
   |        ENRP endpoint message identifier #2 = 0x77734683       |
   +-------------------------------+-------------------------------+
   |                       Type = 0x3                              |
   +-------------------------------+-------------------------------+
   |                                                               |
   |                 pool handle (32)                              |
   |                                                               |
   +-------------------------------+-------------------------------+
   |                                                               |
   |                 PE to 65534.

      The value of 65535 is reserved for IETF-defined extensions. Values
      other than those defined in specific SCTP chunk description are
      reserved for use by IETF.

   Parameter (40)                             |
   |                                                               |
   +-------------------------------+-------------------------------+ Length:  16 bits (unsigned integer)

      The pool handle Parameter Length field specifies contains the name to be registered, that
    shall be composed size of up to 32 characters. the parameter in
      bytes, including the Parameter Type, Parameter Length, and
      Parameter Value fields.  Thus, a parameter with a zero-length
      Parameter Value field would have a Length field of 4.  The
      Parameter Length does not include any padding bytes.

   Parameter Value: variable-length.

      The PE Parameter Value field
    shall contains the actual information to be filled
      transferred in by the registrant endpoint to declare its
    transport addresses, server pooling policy and value, parameter.

   The total length of a parameter (including Type, Parameter Length and other
    operation preferences.

3.3 DEREGISTRATION
   Value fields) MUST be a multiple of 4 bytes.  If the length of the
   parameter is not a multiple of 4 bytes, the sender pads the Parameter
   at the end (i.e., after the Parameter Value field) with all zero
   bytes.  The length of the padding is not included in the parameter
   length field.  A sender SHOULD NOT pad with more than 3 bytes.  The
   receiver MUST ignore the padding bytes.

   The Parameter Types are encoded such that the highest-order two bits
   specify the action that must be taken if the processing endpoint does
   not recognize the Parameter Type.

   00 - Stop processing this ASAP message and discard it, do not process
        any further parameters within it.

   01 - Stop processing this ASAP message and discard it, do not process
        any further parameters within it, and report the unrecognized
        parameter in an 'Unrecognized Parameter Type' error.

   10 - Skip this parameter and continue processing.

   11 - Skip this parameter and continue processing but report the
        unrecognized parameter in an 'Unrecognized Parameter Type'
	error.

   In the following sections, we define the common parameter formats
   used in ASAP.

3.1.1 IPv4 Address Parameter

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        ENRP endpoint message identifier #1 = 0x18038688       |
   +-------------------------------+-------------------------------+
   |        ENRP endpoint message identifier #2 = 0x77734683       |
   +-------------------------------+-------------------------------+
   |        Type = 0x4                              |
   +-------------------------------+-------------------------------+
   |                                                               |
   |                 pool handle (32)                              |
   |                                                               |
   +-------------------------------+-------------------------------+
   |                                                               | 0x1             |                 PE Parameter (40)      Length = 8               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        IPv4 Address                           |
   +-------------------------------+-------------------------------+

    The endpoint sending the DEREGISTRATION shall fill in the name and
    the PE Parameter in order to allow the ENRP server to verify the
    identity
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Address: 32 bits (unsigned integer)

      Contains an IPv4 address of the sending endpoint.

3.4 REGISTRATION_RESPONSE message  It is binary
      encoded.

3.1.2 IPv6 Address Parameter

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        ENRP endpoint message identifier #1 = 0x18038688       |
   +-------------------------------+-------------------------------+
   |        ENRP endpoint message identifier #2 = 0x77734683       |
   +-------------------------------+-------------------------------+
   |            Type = 0x5                              |
   +-------------------------------+-------------------------------+ 0x2         |          Length = 20          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 pool handle (32)                                                               |
      |                         IPv6 Address                          |
   +-------------------------------+-------------------------------+
      |                     Result = (see below)                                                               |
   +-------------------------------+-------------------------------+
      |                   Requested action = (see below)                                                               |
   +-------------------------------+-------------------------------+
   |                                                               |
   |                 PE
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Address: 128 bit (unsigned integer)

      Contains an IPv6 address of the sending endpoint.  It is binary
      encoded.

3.1.3 Pool Element Parameter (40)                             |
   |                                                               |
   +-------------------------------+-------------------------------+

    In response

    This parameter is used in multiple ASAP message to represent an ASAP
    endpoint (i.e., a REGISTRATION, the 'Requested action' field shall be
    set to 0x0, and the 'Result' field shall take the following values:
     0x0 -- registration granted
     0x1 -- registration rejected

    In response to PE in a DEREGISTRATION, the 'Requested action' field shall
    be set to 0x1, pool) and the 'Result' field shall take the following
    values:

     0x2 -- de-registration granted
     0x3 -- de-registration rejected: endpoint not found
     0x4 -- de-registration rejected: associated information, such
    as its transport address(es), load control, and other failures.

    PE Parameter shall be filled in for verification purposes.

3.5 NAME_RESOLUTION message operational
    status information of 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        ENRP endpoint message identifier #1         Type = 0x18038688       |
   +-------------------------------+-------------------------------+ 0x3            |        ENRP endpoint message identifier #2 = 0x77734683       Length=variable         |
   +-------------------------------+-------------------------------+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Type = 0x1          SCTP Port            |
   +-------------------------------+-------------------------------+    Number of IP addrs=k       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                        IP addr param #0                       :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                        IP addr param #1                       :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                             .....                             :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                        IP addr param #k                       :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Load Policy Type        |                 requested name (32)        Policy Value           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Registration Life                          |
   +-------------------------------+-------------------------------+

3.6 NAME_RESOLUTION_RESPONSE message
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Each of the IP address parameters in a PE parameter can be either
    an IPv4 or IPv6 address parameter.

3.1.4 Pool Handle Parameter

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        ENRP endpoint message identifier #1 = 0x18038688       |
   +-------------------------------+-------------------------------+
   |        ENRP endpoint message identifier #2 = 0x77734683       |
   +-------------------------------+-------------------------------+
   |         Type = 0x2                              |
   +-------------------------------+-------------------------------+
   | 0x4            |       Length=variable         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                                                               :
    :                         Pool Handle                           :
    :                                                               :
    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    This parameter holds a pool handle (32)                              |
   |                                                               |
   +-------------------------------+-------------------------------+
   |                  number of entries = n (see below)            |
   +-------------------------------+-------------------------------+
   |                                                               |
   |                 PE Parameter 1 (40)                           |
   |                                                               |
   +-------------------------------+-------------------------------+
   /                                                               /
   \                                                               \
   /                                                               /
   +-------------------------------+-------------------------------+
   |                                                               |
   |                 PE that is a NULL terminated ASCII
    string.

3.1.5 Authorization Parameter n (40)                           |
   |                                                               |
   +-------------------------------+-------------------------------+

3.7 NAME_UNKNOWN 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |        ENRP endpoint message identifier #1 = 0x18038688       |
   +-------------------------------+-------------------------------+
   |        ENRP endpoint message identifier #2 = 0x77734683       |
   +-------------------------------+-------------------------------+
   |         Type = 0x0                              |
   +-------------------------------+-------------------------------+
   |                                                               |
   |                 requested name (32)                           | 0x5            |       Length=variable         |
   +-------------------------------+-------------------------------+

3.8 UPDATE_POLICY_VALUE 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        ENRP endpoint message identifier #1 = 0x18038688       |
   +-------------------------------+-------------------------------+
   |        ENRP endpoint
    :                                                               :
    :                   Authorization Signature                     :

    :                                                               :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    This parameter is used to hold an authorization signature. The
    signature is signed over the entire ASAP message identifier #2 = 0x77734683       |
   +-------------------------------+-------------------------------+
   |                       Type = 0x11                             |
   +-------------------------------+-------------------------------+
   |                                                               |
   |                      pool handle (32)                         |
   |                                                               |
   +-------------------------------+-------------------------------+
   |                                                               |
   |                      PE Parameter (40)                        |
   |                                                               |
   +-------------------------------+-------------------------------+
   |                        New policy value                       |
   +-------------------------------+-------------------------------+

3.9 ENDPOINT_KEEP_ALIVE and uses a
    preconfigured public/private key pair. The receiver of a 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        ENRP endpoint
    which includes this parameter can validate the message identifier #1 = 0x18038688       |
   +-------------------------------+-------------------------------+
   |        ENRP endpoint is
    from the sender by comparing the signature to one generated
    using the peers public key.

3.2 ASAP Message Formats

   The figure below illustrates the common format for all ASAP
   messages. Each message identifier #2 = 0x77734683       |
   +-------------------------------+-------------------------------+
   | is formatted with a Message
   Type = 0x6                              |
   +-------------------------------+-------------------------------+
   |                                                               |
   |                      pool handle (32)                         |
   |                                                               |
   +-------------------------------+-------------------------------+

3.10 ENDPOINT_UNREACHABLE message field, a message-specific Flag field, a Message Length field,
   and a Value field.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        ENRP endpoint message identifier #1 = 0x18038688       |
   +-------------------------------+-------------------------------+
   |        ENRP endpoint message identifier #2 = 0x77734683       |
   +-------------------------------+-------------------------------+
   | Message Type = 0xa                              |
   +-------------------------------+-------------------------------+
   |                                                               |
   |                      pool handle (32)                         |
   |                                                               |
   +-------------------------------+-------------------------------+
   |                     Endpoint IP address                       |
   +-------------------------------+-------------------------------+  |      Endpoint's SCTP port     |         padding   Msg Flags   |
   +-------------------------------+-------------------------------+        Message Length         |                Type
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
      :                        Message Value                          :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type: 8 bits (unsigned integer)

      This field identifies the type of severity (see below)                   |
   +-------------------------------+-------------------------------+

    The 'pool handle' is not required to be filled information contained in for this
    message, however the IP address and SCTP port number
      Message Value field. It takes a value from 0 to 254.  The value
      of 255 is reserved for future use as an extension field.

      Message Types are encoded such that the endpoint highest-order two bits
      specify the action that must be supplied in taken if the message.

    'Type message receiver
      does not recognize the Message Type.

      00 - Stop processing this message and discard it.

      01 - Stop processing this message and discard it, and report the
	   unrecognized message in an 'Unrecognized Parameter Type'
	   error.

      10 - reserved.

      11 - reserved.

   Message Flags: 8 bits

      The usage of severity' shall take one these bits depends on the message type as given by
      the Message Type. Unless otherwise specified, they are set to
      zero on transmit and are ignored on receipt.

   Message Length: 16 bits (unsigned integer)

      This value represents the size of the following values:

     0x0 --- NORMAL_REPORT: warning message in bytes including
      the Message Type, Message Flags, Message Length, and Message
      Value fields. Therefore, if the Message Value field is
      zero-length, the Length field will be set to 4.  The Message
      Length field does not count any padding.

   Message Value: variable length

      The Message Value field contains the actual information to be
      transferred in the server.
     0x1 --- FINAL_REPORT: message.  The usage and format of this field
      is dependent on the specified endpoint must Message Type.

   The total length of a message (including Type, Length and Value
   fields) MUST be removed by a multiple of 4 bytes.  If the
             server immediately.

3.11 SERVER_HUNT length of the
   message is not a multiple of 4 bytes, the sender MUST pad the
   message with all zero bytes and this padding is not included in the
   message length field. The sender should never pad with more than 3
   bytes.  The receiver MUST ignore the padding bytes.

3.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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        ENRP endpoint message identifier #1 = 0x18038688       |
   +-------------------------------+-------------------------------+
   |        ENRP endpoint message identifier #2 = 0x77734683       |
   +-------------------------------+-------------------------------+
   |   Type = 0xb                              |
   +-------------------------------+-------------------------------+
   |                                                               | 0x1  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                          Pool Handle                          :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Element Parameter                    :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter (optional)         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The pool handle (32)                         |
   |                                                               |
   +-------------------------------+-------------------------------+
   |                     criticality (see below)                   |
   +-------------------------------+-------------------------------+

    The 'criticality' parameter field shall take one of specifies the following values:

    0x1 --- LOW_CRITICALITY
    0x2 --- MED_CRITICALITY
    0x3 --- HIGH_CRITICALITY

3.12 SERVER_HUNT_RESPONSE name to be registered.
    The PE Parameter field shall be filled in by the registrant
    endpoint to declare its transport addresses, server pooling
    policy and value, and other operation preferences.

3.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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        ENRP endpoint message identifier #1   Type = 0x18038688       |
   +-------------------------------+-------------------------------+ 0x2  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Element Parameter                    :

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The PE sending the DEREGISTRATION shall fill in the pool handle
      and the PE Parameter in order to allow the ENRP endpoint server to verify
      the identity of the endpoint.

3.2.3 REGISTRATION_RESPONSE message identifier #2 = 0x77734683       |
   +-------------------------------+-------------------------------+

       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 = 0xc                              |
   +-------------------------------+-------------------------------+
   | 0x3  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Element Parameter                    :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      pool handle (32) Action code   |  Result code  |        (reserved)             |
   +-------------------------------+-------------------------------+

4.
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Action: (8 bits)

       The ASAP Interfaces

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

    Appropriate timers and recovery actions for this results code is in response to:

       0x0 -- registration
       0x1 -- de-registration

    Result code: (8 bits)

       0x0 -- request granted
       0x1 -- request denied, unspecifed
       0x2 -- request denied, authorization failure detection and
    management are also discussed.

    An ASAP User (PU OR PE) passes primitives to the ASAP sub-layer to
       0x3 -- request certain actions. Upon the completion of those actions or
    upon the detection of certain events, the ASAP will notify denied, invalid values

    Reserved: (16 bits)

       Ignored by the
    ASAP-user.

4.1 Registration.Request Primitive

    Format: registration.request(endpointName)

    where receiver and set to 0 by the endpointName parameter contains a NULL terminated ASCII
    string of fixed length.

    The ASAP user invokes this primitive to add itself to the name
    space, thus becoming a Pool Element. The ASAP user must register its
    name with the ENRP server by using this primitive before other ASAP
    endpoints using the name space can send message(s) to this ASAP user
    by name or by Pool element handle (see Sections ? and ?).

    In response to the registration primitive, the ASAP layer will send
    a REGISTRATION sender.

3.2.4 NAME_RESOLUTION message to the home ENRP server (See section ?),
    and 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 layer shall start the Server
    Hunt procedure (see Section ?) in an attempt to get service
    from a remote ENRP server.

4.2 Deregistration.Request Primitive

    Format: deregistration.request()

    The ASAP user 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

       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                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.5 NAME_RESOLUTION_RESPONSE message will be sent by ASAP layer to the home ENRP
    server (see Section ?).

4.3 Cache.Populate.Request Primitive

    Format: cache.populate.request(destinationAddress, typeOfAddress)

    If the address type is a

       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 (or name) and a local name
    translation cache exists, the ASAP layer should initiate a mapping
    information query on the Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Pool handle and update it local cache when the
    response comes back from the ENRP server.

4.4 Cache.Purge.Request Primitive

    Format: cache.purge.request(destinationAddress, typeOfAddress)

    If the address type is a Element Parameter 1                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                              ...                              :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Pool handle (or name) and local name
    translation cache exists, the ASAP layer should remove the mapping
    information on the Element Parameter N                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.6 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 = 0x6  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool handle from its local cache.

4.5 Data.Send.Request Primitive

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

    This primitive requests ASAP to send a Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.7 ENDPOINT_KEEP_ALIVE message to some specified

       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 or Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.8 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 = 0x9  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool element within the current Operational scope.

    Depending on the address type used for the send request, the
    sender's ASAP layer may perform address translation and Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Element
    selection before sending the Parameter                    :

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter (optional)         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.9 SERVER_HUNT message out.

    The data.send primitive can take the following forms of address
    type.

4.5.1 Sending to a Pool

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

    This is the simplest form of data.request primitive. By default,
    this directs ASAP to send the

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0xa  |0|0|0|0|0|0|0|0|        Message Length         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                 Authorization Parameter (optional)            :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.10 SERVER_HUNT_RESPONSE message to one of the pool elements
    in

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0xb  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                 Authorization Parameter (optional)            :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4. The ASAP Interfaces

    This chapter will focus primarily on the server pool.

    Before sending primitives and
    notifications that form the message out to interface between the Pool, ASAP-user and the sender's
    ASAP and that between ASAP and its lower layer
    MUST first perform a name to address translation. It may transport protocol
    (e.g., SCTP).

    Appropriate timers and recovery actions for failure detection and
    management are also need discussed.

    An ASAP User passes primitives to perform Pool Element selection if multiple Pool Elements exist in
    the Server Pool.

    If the sender's ASAP implementation does not support a local cache of sub-layer to
    request certain actions. Upon the translation information completion of those actions or if it does not have
    upon the translation
    information on that Pool in its local cache, it will transmit
    a request for detection of certain events, the name mapping information to ASAP will notify the ENRP server, and
    MUST hold
    ASAP user.

4.1 Registration.Request Primitive

    Format: registration.request(poolHandle)

    where the outbound message in queue while awaiting poolHandle parameter contains a NULL terminated ASCII
    string of fixed length.

    The ASAP user invokes this primitive to add itself to the response
    from
    namespace, thus becoming a Pool Element of a pool. The ASAP user
    must register itself with the ENRP server (any further send request to by using this Pool primitive
    before other ASAP users using the ENRP server responds SHOULD also be queued).

    Once the necessary mapping information arrives from the ENRP server,
    the sender's namespace can send message(s) to
    this ASAP will:

    A) map user by pool handle or by PE handle (see Sections 4.5.1
    and 4.5.2).

    In response to the name into a list of transport addresses of registration primitive, the
       destination PE(s),

    B) If multiple PEs exist in that Pool, ASAP layer will choose
       one of them and transmit the send
    a REGISTRATION message to it.  In that case, the
       choice of home ENRP server (See section 3.2.1),
    and start a T2-registration timer.

    If the PE T2-registration timer expires before receiving a
    REGISTRATION_RESPONSE message, or a SEND.FAILURE notification is made by
    received from the SCTP layer, the ASAP layer of the sender based on shall start the server pooling policy as discussed Server
    Hunt procedure (see Section 4.9.4) in section ?.

    C) if no association exists towards an attempt to get service
    from a different ENRP server.

4.2 Deregistration.Request Primitive

    Format: deregistration.request(poolHandle)

    The ASAP PE invokes this primitive to remove itself from the destination, establish
    Server Pool.  This should be used as a new
       SCTP association,

    NOTE: if part of the underlying SCTP implementation supports implicit
    association setup, this step is not needed (see [RFC2960]).

    D) send out graceful shutdown
    process by the queued application.

    A DEREGISTRATION message will be sent by ASAP layer to the SCTP association using the
       SEND primitive home ENRP
    server (see [RFC2960]), and,

    E) if Section 3.2.2).

4.3 Cache.Populate.Request Primitive

    Format: cache.populate.request(destinationAddress, typeOfAddress)

    If the local cache address type is implemented, append/update the a Pool handle and a local name
    translation cache
       with exists, the ASAP layer should initiate a mapping
    information received in the ENRP server's
       response. Also, record the local SCTP association id, if query by sending a new
       association was created.

    For more NAME.RESOLUTION message on the Pool
    handle and update it local cache when the response comes back from
    the ENRP server request procedures see [ENRP].

    Optionally, server.

    The destinationAddress field contains the address for which the
    cache needs to be populated. The typeOfAddress indicates the ASAP layer of address
    type. Allowable types are Pool handle and Pool Element handle.  In
    the sender may return case of a Pool Element
    handle of the selected PE to handle, the application after sending Pool handle is extracted from
    the
    message. This Pool Element handle can then be and used for future transmissions to
    that PE form a NAME.RESOLUTION
    message (see Section ?).

    Section ? defines the fail-over procedures for cases where 3.5).

4.4 Cache.Purge.Request Primitive

    Format: cache.purge.request(destinationAddress, typeOfAddress)

    If the
    selected PE address type is found unreachable.

4.5.2 Pool Element Selection

    Each time a ASAP user sends a message to a Pool that contains
    more than one PE, handle and local name
    translation cache exists, the sender's ASAP layer must select one of should remove the PEs in mapping
    information on the Pool as the receiver of the current
    message. The selection is done according handle from its local cache.

4.5 Data.Send.Request Primitive

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

    This primitive requests ASAP to the current server
    pooling policy of the Pool send a message to which some specified
    Pool or Pool Element within the message is sent.

    Note, no selection is needed if current Operational scope.

    Depending on the ASAP_SEND_TOALL option is set
    (see Section ?).

    When joining a Pool, along with its registration each
    PE specifies its preferred server pooling policy address type used for receiving
    messages sent to this Pool. But only the server pooling
    policy specified by the first PE joining send request, the
    sender's ASAP layer may perform address translation and Pool will
    become Element
    selection before sending the current server pooling policy message out.

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

    Moreover, destinationAddress and typeOfAddress together with the server pooling policy, each PE can
    also specify
    indicates a Policy Value for itself at pool handle.

    This is the registration time. The
    meaning simplest form of send.data.request primitive. By
    default, this directs ASAP to send the policy value depends on the current server pooling
    policy message to one of the group. A PE can also change its policy value
    whenever it desires, see Section ? for details.

    Note, if this first PE removes itself from the Pool
    (e.g., by de-registration from the name space) and
    Elements in the remaining
    PEs have specified conflicting server pooling policies at
    their corresponding registrations, it is implementation specific pool.

    Before sending the message out to
    determine the new current server pooling policy.

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

4.5.2.1 sender's ASAP layer
    MUST first perform a pool handle to address translation. It may
    also need to perform Pool Element selection policy - Round Robin

    When a ASAP endpoint sends messages by if multiple Pool Handle and Round-Robin
    is
    Elements exist in the current policy of that Pool, pool.

    If the sender's ASAP layer implementation does not support a local cache
    of the sender
    will select mapping information or if it does not have the receiver for each outbound message by round-Robining
    through all mapping
    information on the registered PEs in that Pool, pool in an attempt its local cache, it will transmit a
    NAME.RESOLUTION message to
    achieve an even distribution of outbound messages. Note that the current home ENRP server, and
    MUST hold the outbound message in a
    large server pool, queue while awaiting the response
    from the ENRP deamon may NOT server (any further send back all PEs request to the ASAP client. In this case pool before
    the client or PU will ENRP server responds SHOULD also be
    performing a round robin policy on queued).

    Once the necessary mapping information arrives from the ENRP server,
    the sender's ASAP will:

    A) map the pool handle into a subset list of transport addresses of the entire Pool.

4.5.2.2 Pool Selection Policy - Least Used Policy

    When the
       destination Pool is under the Least Used server pooling
    policy, PE(s),

    B) if multiple PEs exist in the pool, ASAP layer will choose
       one of them and transmit the message sender will select the PE to it. In that
    has the lowest policy value in the group as case, the receiver
       choice 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 made by ASAP layer of the sender until based on
       the
    load control information of server pooling policy as discussed in section 4.5.2.

    C) if no transport association exists towards the Pool destination PE,
       ASAP will establish a new transport association,

    NOTE: if the underlying SCTP implementation supports implicit
    association setup, this step is updated and changed in not needed (see [SCTP-API]).

    D) send out the
    local cache of queued message(s) to the sender SCTP association using the
       SEND primitive (see section ?).

4.5.2.3 Pool Selection Policy - Least Used with Degradation Policy

    This policy is [RFC2960]), and,
    E) if the same as local cache is implemented, append/update the Least Used policy local cache
       with the exception
    that, each time mapping information received in the PE with ENRP server's
       response. Also, record the lowest policy value is selected from local SCTP association id, if a new
       association was created.

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

    Optionally, the receiver ASAP layer of the current message, its policy value is
    incremented, and thus it sender may no longer be the lowest value in the
    Pool.

    This provides return a degradation Pool Element
    handle of the policy towards round Robin policy
    over time. As with the Least Used policy, every local cache update
    at selected PE to the sender will bring application after sending the policy back
    message. This PE handle can then be used for future transmissions to Least Used with
    Degradation.

4.5.2.4
    that same PE (see Section 4.5.3).

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

4.5.2 Pool Element Selection Policy - Weighted round robin

    [TBD]

4.5.3 Sending to

    Each time an ASAP user sends a Pool Element Handle

    In this case the destinationAddress and typeOfAddress together
    indicates message to a ASAP pool element handle.

    This requests that contains
    more than one PE, the sender's ASAP layer to deliver the message to must select one of
    the PE
    identified by PEs in the pool element handle.

    The pool element handle should contains the name and as the primary
    destination transport address receiver of the destination PE. current
    message. The ASAP layer shall use the address to identify the SCTP
    association (or to setup a new one if necessary) and then invoke the
    SCTP SEND primitive selection is done according to send the message current server
    pooling policy of the pool to which the PE.

    If local cache message is supported and sent.

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

    When joining a pool, along with its registration each
    PE specifies its preferred server pooling policy for receiving
    messages sent to this pool. But only the Pool
    found in server pooling
    policy specified by the first PE joining the pool element handle is not available in will
    become the local
    cache, current server pooling policy of the sender's ASAP layer SHOULD, after sending group.

    Moreover, together with the message, server pooling policy, each PE can
    also transmit specify a request Policy Value for itself at the Pool handle mapping information to
    the ENRP server. Once registration time. The
    meaning of the necessary mapping information arrives from policy value depends on the ENRP server, current server pooling
    policy of the sender's ASAP will update group. A PE can also change its local cache policy value
    whenever it desires, by re-registering itself with the newly received mapping information for that Pool handle.

    Section ? defines namespace
    with a new policy value. Re-registration shall be done by simply
    sending another REGISTRATION to its home ENRP server.

    Note, if this first PE removes itself from the fail-over procedures for cases where pool
    (e.g., by de-registration from the PE
    pointed name space) and the remaining
    PEs have specified conflicting server pooling policies at
    their corresponding registrations, it is implementation specific to
    determine the new current server pooling policy.

    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 the Pool Element handle Handle and Round-Robin
    is found unreachable.

    Optionally, the current policy of that Pool, the ASAP layer may return of the actual Pool Elment handle
    to which sender
    will select the receiver for each outbound message was sent (this may be different from by round-Robining
    through all the Pool
    Element handle specified when registered PEs in that Pool, in an attempt to
    achieve an even distribution of outbound messages. Note that in a
    large server pool, the primitive is invoked, due ENRP server may NOT send back all PEs
    to the
    possibility of automatic fail-over).

4.5.4 Send by Transport Address ASAP client. In this case the destinationAddress and typeOfAddress together
    indicates an SCTP transport address.

    This directs 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 sender's ASAP layer to send of the message out to sender will select the
    specified transport address.

    No endpoint fail-over is support when this form of send request is
    used. This mode of sending effectively by-passes PE that
    has the ASAP layer.

4.5.5 Options

    The Options parameter passed lowest policy value in the various forms of the above
    data.request primitive gives directions to group as the sender's ASAP layer
    on special handling receiver of the message delivery.

    Options can be grouped as follows:

    - PE fail-over (allowed, or prohibited),
    - whether to send to
    current message. If more than one PE or to from the whole Pool,
    - whether to send 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 last sent to within will
    be always selected as the Pool, message receiver by the sender until the
    load control information of the pool is updated and
    - options passed to changed in the SCTP transport protocol.

    The complete list
    local cache of Options the sender (see section ?).

4.5.2.3 Least Used with Degradation Policy

    This policy is the same as follows:

    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 Least Used policy with the exception
    that, each time the PE pointed to by with the handle lowest policy value is found unreachable,
    this option allows the sender's ASAP layer to re-select an alternate
    PE selected from
    the same Pool if one exists, and silently re-send the
    message to this newly selected endpoint.

    Endpoint unreachable is normally indicated by as the Communication Lost
    or Send Failure notification from SCTP.

    ASAP_SEND_NO_FAILOVER: 0x0002

    This option prohibits receiver of the sender's ASAP layer from re-sending current message, its policy value is
    incremented, and thus it may no longer be the
    message to any alternate PE lowest value in case that the first selected PE or
    Pool.

    This provides a degradation of the PE to by policy towards round Robin policy
    over time. As with the handle is found unreachable. Instead, Least Used policy, every local cache update
    at the sender's
    ASAP layer shall notify its upper layer about sender will bring the unreachability policy back to Least Used with an Error.Indication
    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 any unsent data.

    ASAP_SEND_TO_LAST: 0x0004 typeOfAddress together
    indicate an ASAP Pool Element handle.

    This option requests the sender's ASAP layer to send deliver the message to the same PE in
    identified by the Pool that the previous message was
    sent to.

    ASAP_SEND_TOALL: 0x0008

    When sending by Element handle.

    The Pool Handle, this option directs the sender's ASAP
    layer 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_TOSELF: 0x0010.

    This option only applies in combination with ASAP_SEND_TOALL option.
    It permits Element handle should contain the sender's ASAP layer also deliver poolHandle and a copy of the
    message to itself (i.e., loopback).

    ASAP_SCTP_BUNDLE: 0x0100

    This option allows the local SCTP
    destination transport layer to bundle the
    outbound messages whenever possible into bigger datagrams before
    transmitting them onto address of the network.

    ASAP_SCTP_NO_BUNDLE: 0x0200

    This option disallows destination PE or the local SCTP transport layer to bundle
    outbound messages.

    ASAP_SCTP_HB_ON: 0x0400

    This option instructs
    poolHandle and the local SCTP transport 'association id'.

    The ASAP layer to turn on
    heartbeat on the SCTP association indicated by the
    destinationAddress parameter.

    ASAP_SCTP_HB_OFF: 0x0800

    This option instructs shall use the local SCTP transport layer address to turn off
    heartbeat on identify the
    SCTP association indicated by the
    destinationAddress parameter.

    ASAP_SCTP_UNORDER: 0x1000

    This option instructs the SCTP transport layer (or to send the current
    message using un-ordered delivery.

4.6 Data.Received Notification

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

    When setup a new user message is received, the ASAP layer of the receiver
    uses this notification to pass one if necessary) and then
    invoke the message SCTP SEND primitive to its upper layer.

    Along with send the message being passed, the ASAP layer of the receiver
    should also indicate to its upper layer the message sender's
    address. The sender's address can be in the form of either an SCTP
    association id, or a ASAP pool element handle.

    A) If the name translation PE.

    In addition, if a local translation cache is implemented at supported the
    receiver's ASAP layer, a reverse mapping from
    endpoint will:

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

    B) determine if the pool handle should be performed and if is in the mapping local cache.

       If it is
    successful, NOT, the sender's ASAP endpoint will:
       i) ask the home ENRP server for name resolution on pool element handle should be
    constructed
	  by sending a NAME.RESOLUTION message, and passed in
       ii) use the response to update the senderAddress field.

    B) If there is no local cache or cache.

       If the reverse mapping pool handle is not
    successful, the SCTP association id 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 cache, the ASAP user about
    failed message delivery as well as other abnormalities (see Section
    ? for details).

    The destinationAddress and typeOfAddress together indicates to whom endpoint will only
       update 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 handle if the first portion of cache is stale. A stale cache is
       indicated by it if being older than the message protocol parameter
       'stale.cache.value'.

    Section 4.5.5? defines the fail-over procedures for cases where
    the PE pointed to by the Pool Element handle is
    too big) and its size should be passed in found unreachable.

    Optionally, the ASAP layer may return the actual Pool Elment handle
    to which the failedMessage and
    sizeOfMessage fields, respectively.

4.8 SCTP primitives

4.8.1 SCTP SEND Primitive

    Basic Format:

    SEND(association id, buffer address, byte count, options)
         -> result

    The outbound message will was sent (this may be held in different from the buffer Pool
    Element handle specified when this the primitive is invoked. The 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 an SCTP transport address.

    This directs the sender's ASAP layer shall identify to send the SCTP association which
    connects message out to the intended destination and fill in
    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 'association
    id'. ASAP
    layer.

4.5.5 Message Delivery Options

    The options field will hold Options parameter passed in the options destined various forms of the above
    data.send.request primitive gives directions to the SCTP
    transport sender's ASAP
    layer (see ?). on special handling of the message delivery.

    The returned 'result' can indicate whether there value of the Options parameter is any local error
    executing generated by bit-wise
    "OR"ing of the primitive.

4.8.2 SCTP RECEIVE Primitive

    Basic Format:

    RECEIVE(association id, buffer address, buffer size) -> byte count

    This primitive reads 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 user message out from
    selected PE or the SCTP
    stack (if there PE pointed to by the PE handle is found
    unreachable, this option allows the sender's ASAP layer to
    re-select an alternate PE from the same pool if one available) exists, and put it into the specified
    buffer. The size of
    silently re-send the message read, in octets, will also be
    returned.

4.8.3 to this newly selected endpoint.

    Endpoint unreachable is normally indicated by the SCTP SET.PRIMARY Primitive

    Basic Format:

    SET.PRIMARY(association id, destination transport address) -> result
    COMMUNICATION.LOST or SEND.FAILURE notification.

    ASAP_SEND_NO_FAILOVER: 0x0002

    This can be used option prohibits the sender's ASAP layer from re-sending the
    message to instructs SCTP any alternate PE in case that the first selected PE or
    the PE pointed to use by the specified
    destination transport address as PE handle is found unreachable. Instead,
    the new primary destination address
    for sending messages.

4.8.4 SCTP DATA.ARRIVE Notification

    SCTP sender's ASAP layer invokes this notification when a user message is
    successfully received shall notify its upper layer about the
    unreachability with an Error.Report and ready for retrieval. return any unsent data.

    ASAP_SEND_TO_LAST: 0x0004

    This shall prompt option requests the sender's ASAP layer to invoke the RECEIVE primitive to get send the data (see ?).

4.8.5 SCTP SEND.FAILURE Notification

    If a message can not be delivered to the specified association id,
    for any reason, SCTP will invoke this notification to notify ASAP.

    In response,
    the ASAP shall take same PE in the following steps:

    A) If pool that the previous message destined to this
    pool was originally sent to.

    ASAP_SEND_TO_ALL: 0x0008

    When sending by Pool handle or Pool Element
       handle and with Handle, this option ASAP_SEND_FAILOVER set, retransmit directs the
       message sender's ASAP
    layer to an alternate PE send a copy of the same Pool if one exists in message to all the Server Pool. The proper server pooling policy shall be followed PEs, except for the
    sender itself if more than one alternates exist in the group.

    B) If no alternate exists or option ASAP_SEND_FAILOVER sender is not set
       when 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 sender's ASAP layer also deliver a copy of the
    message was originally sent, generate an Error.report to
       report itself if the failure to sender is a PE of the pool (i.e., loopback).

    ASAP_SCTP_UNORDER: 0x1000

    This option instructs the ASAP user.

4.8.6 SCTP COMMUNICATION.LOST Notification

    When SCTP loses communication transport layer to an PE completely or detects that send the current
    message using un-ordered delivery.

4.6 Data.Received Notification

    Format: data.received(messageReceived, sizeOfMessage, senderAddress,
                          typeOfAddress)
    When a new user message is received, the PE has performed an abort or graceful shutdown operation, it
    invokes this notification to notify ASAP layer.

    When handling layer of the receiver
    uses this notification ASAP shall report this event to its
    ENRP server via an ENDPOINT_UNREACHABLE pass the message to its upper layer.

    Along with the severity
    level set to NORMAL_REPORT (see ?).

    If local mapping cache is implemented, message being passed, the ASAP layer of the receiver
    should also
    mark the PE as unreachable in indicate to its local cache. And if all the PEs in
    that Pool are marked as unreachable, the ASAP upper layer should remove the Pool from its local cache.

4.8.7 SCTP NETWORK.STATUS.CHANGE Notification message sender's
    address. The SCTP sends this notification to the ASAP layer when the
    reachability status of a transport sender's address can be in the form of a specific either an SCTP
    association has changed. id, or a ASAP Pool Element handle.

    A) If the name translation local mapping cache is supported, implemented at the
    receiver's ASAP layer, upon
    reception of this notification, a reverse mapping from the sender's IP
    address to the pool handle should look up be performed and if the information of
    this PE in its local cache mapping is
    successful, the sender's ASAP Pool Element handle should be
    constructed and record passed in the reachability change. senderAddress field.

    B) If there is no local cache or the address in question becomes unreachable and reverse mapping is not
    successful, the primary
    address of SCTP association id should be passed in the association,
    senderAddress field.

4.7 Error.Report Notification

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

    An error.report should be generated to notify the ASAP layer MAY also elect a new
    primary user about
    failed message delivery as well as other abnormalities (see Section
    ? for this details).

    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 by invoking id, or a transport address.

    The original message (or the SET.PRIMARY primitive
    (Section ?).

    If first portion of it if the local cache message is not support or
    too big) and its size should be passed in the reverse look up does not
    succeed, ASAP takes no action.

4.9 failedMessage and
    sizeOfMessage fields, respectively.

4.8 Examples

4.9.1

4.8.1 Send to an Unknown Name a New Pool

    This example shows the event sequence when the a Pool user,
    Endpoint 1 (EP1) User sends the
    message "hello world" "hello" to a name pool which is not in the local mapping
    translation cache (assuming local caching is supported).

    ENRP Server                            EP1         new-name:EP2                       PU         new-name:PEx

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

    1) The user at EP1 PU invokes:

       data.send("new-name",

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

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

    2) The ASAP layer of EP1 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 layer 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 EP1 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 EP1
       PU selects the destination PE (EP2), (PEx), sets up, if necessary, an
       SCTP association towards EP2 PEx (explicitly or implicitly), and
       send out
       "hello" the queued "hello1" user message.

4.9.2

4.8.2 Send to a Cached Name Pool Handle

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

    ENRP Server                  EP1                    new-name:EP2                       PU         new-name:PEx

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

    1) The user at EP1 PU invokes:

       data.request("new-name",

       data.send.request("new-name", name-type, "hello world 2", 13, "hello2", 6, 0);

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

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

4.10

4.9 Handle ASAP to ENRP Communication Failures

    Three types of failure may occur when the ASAP layer 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 ?.

4.10.1

4.9.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 layer 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 ?.

4.10.2

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

    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.

4.10.3

4.9.3 Handle ENDPOINT_KEEP_ALIVE Messages

    At times, a an ASAP endpoint may receive ENDPOINT_KEEP_ALIVE messages
    (see section 3.1.2.1?) Section 3.2.7?) from the ENRP server. This message requires
    no response and should be silently discarded by the ASAP layer. However, each time

4.9.4 Home ENRP Server Hunt

    At its startup, or when an ENDPOINT_KEEP_ALIVE 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.

    The PE or PU shall multicast a SERVER_HUNT message over the ENRP
    client channel, and shall repeat sending this message every
    <TIMEOUT-SERVER-HUNT> seconds until a SERVER_HUNT_RESPONSE message
    is received, received from an ENRP server.

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

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

5. Variables, Timer Values, Timers, and Thresholds Constants

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

5.1 Timer values 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 local home ENRP server, normally set to 30 seconds.

    T3-registration-reattempt - If the registration cycle does not
    complete
    complete, this timer is begun to restart the registration
    process. Normal value for this timer is 10 minutes.

    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.

5.2 Thresholds

    Timeout-registration --- - pre-set threshold; how long an PE
    will wait for the REGISTRATION_RESPONSE from its home ENRP server.

    Timeout-server-hunt --- - pre-set threshold; how long an endpoint a PE will
    wait for the REGISTRATION_RESPONSE from its home ENRP server.

    num-of-serverhunts - The current count of server hunt messages that
    have been transmitted.

    registration-count - The current count of attempted registrations.

    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.

6. Security Considerations

   To be determined.

7. References

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

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

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

     [ENRP] Q. Xie, R. R. Stewart "Endpoint Name Resolution Protocol",
            draft-ietf-rserpool-enrp-00.txt,
            draft-ietf-rserpool-enrp-01.txt, work in progress.

7.

     [SCTP-API] R. R. Stewart, Q. Xie, L Yarroll, J. Wood, K. Poon,
		K. Fujita "Sockets API Extensions for SCTP",
                draft-ietf-tsvwg-sctpsocket-01.txt, work in progress.

8. Acknowledgements

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

8.

9.  Authors' Addresses

   Randall R. Stewart
   24 Burning Bush Trail.
   Crystal Lake, IL 60012
   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