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

expires in six months                                       March 1,                                         May 3, 2002

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

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 Namespace..........................5 Namespace.......................... 5
       1.4  Conventions........................................... 5
    2. Conventions................................................5
    3. Message Definitions........................................5
       3.1 Definitions........................................ 6
       2.1 ASAP Parameter 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 Formats................................. 6
       2.2 ASAP Message Formats...................................9
	   3.2.1 Formats................................... 6
	   2.2.1 REGISTRATION message.............................10
	   3.2.2 message............................. 6
	   2.2.2 DEREGISTRATION message...........................10
	   3.2.3 message........................... 7
	   2.2.3 REGISTRATION_RESPONSE message....................11
	   3.2.4 message.................... 7
	   2.2.4 NAME_RESOLUTION message..........................11
	   3.2.5 message.......................... 8
	   2.2.5 NAME_RESOLUTION_RESPONSE message.................12
	   3.2.6 message................. 8
	   2.2.6 NAME_UNKNOWN message.............................12
	   3.2.7 message............................. 9
	   2.2.7 ENDPOINT_KEEP_ALIVE message......................12
	   3.2.8 message...................... 9
	   2.2.8 ENDPOINT_KEEP_ALIVE_ACK message.................. 9
	   2.2.9 ENDPOINT_UNREACHABLE message ....................12
	   3.2.9 ....................10
	   2.2.10 SERVER_HUNT message .............................13
	   3.2.10 ............................10
	   2.2.11 SERVER_HUNT_RESPONSE message....................13 message....................10
    3. Procedures.................................................11
      3.1 Registration............................................11
      3.2 Deregistration..........................................12
      3.3 Name resolution.........................................13
      3.4 Endpoint keep alive.....................................14
      3.5 Reporting unreachable endpoints.........................14
      3.6 ENRP server hunt procedures.............................14
      3.7 Handle ASAP to ENRP Communication Failures..............15
	   3.7.1 SCTP Send Failure................................15
	   3.7.2 T1-ENRPrequest Timer Expiration..................15
    4. The ASAP Interfaces........................................13 Interfaces........................................16
       4.1 Registration.Request Primitive.........................13 Primitive.........................16
       4.2 Deregistration.Request Primitive.......................14 Primitive.......................16
       4.3 Cache.Populate.Request Primitive.......................14 Primitive.......................17
       4.4 Cache.Purge.Request Primitive..........................14 Primitive..........................17
       4.5 Data.Send.Request Primitive............................14 Primitive............................17
	   4.5.1 Sending to a Pool Handle.........................15 Handle.........................18
	   4.5.2 Pool Element Selection...........................16 Selection...........................19
		 4.5.2.1 Round Robin Policy.......................16 Policy.......................19
		 4.5.2.2 Least Used Policy........................17 Policy........................19
		 4.5.2.3 Least Used with Degradation Policy.......17 Policy.......20
		 4.5.2.4 Weighted Round Robin Policy..............17 Policy..............20
           4.5.3 Sending to a Pool Element Handle.................17 Handle.................20
	   4.5.4 Send by Transport Address........................18 Address........................21
	   4.5.5  Message Delivery Options........................18 Options........................21
       4.6 Data.Received Notification.............................19 Notification.............................22
       4.7 Error.Report Notification..............................20 Notification..............................23
       4.8 Examples...............................................20 Examples...............................................23
	   4.8.1 Send to a New Pool Handle........................20 Handle........................23
	   4.8.2 Send to a Cached Pool Handle.....................21 Handle.....................24
       4.9 Handle ASAP to ENRP Communication Failures.............22 PE send failure........................................25
           4.9.1 SCTP Send Failure................................22 Translation.Request Primitive....................25
           4.9.2 T1-ENRPrequest Timer Expiration..................22
	   4.9.3 Handle ENDPOINT_KEEP_ALIVE Messages..............22
	   4.9.4 Home ENRP Server Hunt............................23 Transport.Failure Primitive......................25
    5. Variables, Timers, and Constants...........................23 Constants...........................25
       5.1 Timers.................................................23 Timers.................................................25
       5.2 Thresholds.............................................23 Thresholds.............................................26
    6. Security Considerations....................................24 Considerations....................................26
    7. References.................................................24 References.................................................27
    8. Acknowledgements...........................................24 Acknowledgments............................................27
    9. Authors' Addresses.........................................24 Addresses.........................................28

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

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 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
    address addresses of the Japanese server pool domain, that is,
    the address of
    an ENRP server(s) client channel in Japan. From there the PU would query the
    ENRP server and then directly contact the PE(s) of interest.

2.

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

3.

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 filed name to indicate the length of the field in number of
   octets.

3.1

2.1 ASAP Parameter Formats

   The basic message format and all parameter formats can be found
   in [ENRP-ASAP]. Note also that ALL ASAP parameters 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 defined in composed of a Type-length-value (TLV) standard message format as
   shown below.

       0                   1                   2                   3
       0 1 2 3 found in
   Section 4 5 6 7 8 9 0 1 2 or [ENRP-ASAP], elements and parameters. The parameter
   descriptions may also be found in Section 3 4 5 6 7 8 9 0 1 2 of [ENRP-ASAP].

   The following ASAP message types are defined in this section:

      Type       Message Name
      -----      -------------------------
      0x00       - (reserved by IETF)
      0x01-0x06  - defined by [ENRP]
      0x07	 - Registration
      0x08       - Deregistration
      0x09       - Registration Response
      0x0a       - Name Resolution
      0x0b       - Name Resolution Response
      0x0c	 - Name Unknown
      0x0d       - Endpoint Keep Alive
      0x0e	 - Endpoint Keep Alive Acknowledgement
      0x0f	 - Endpoint Unreachable
      0x10	 - Server Hunt
      0x11	 - Server Hunt Response

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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Parameter   Type       |       Parameter = 0x7  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                          Pool Handle                          :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Element Parameter Value                    :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter (optional)         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Parameter Type:  16 bits (unsigned integer)

    The Type pool handle parameter field is a 16 bit identifier of specifies the type of parameter.
      It takes a value of 0 name 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 Length:  16 bits (unsigned integer) be registered.
    The PE Parameter Length field contains the size of the parameter shall be filled in
      bytes, including by the Parameter Type, Parameter Length, registrant endpoint
    to declare its transports 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 Parameter Value field contains addresses, server pooling policy and
    value, and other operation preferences. Note that the actual information to be
      transferred in registration
    message MUST use SCTP and the parameter.

   The total length IP addresses of a parameter (including Type, the PE registered
    within the Pool Element Parameter Length and
   Value fields) MUST be a multiple of 4 bytes.  If the length subset of the
   parameter is not a multiple addresses
    of 4 bytes, the sender pads the Parameter
   at the end (i.e., after the Parameter Value field) with all zero
   bytes.  The length SCTP association irrespective of the padding is not included in transport protocol
    regestered by 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 PE.

2.2.2 DEREGISTRATION 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x1             | 0x8  |0|0|0|0|0|0|0|0|        Message Length = 8         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        IPv4 Address                        PE Identifier                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv4 Address: 32 bits (unsigned integer)

      Contains an IPv4 address

      The PE sending the DEREGISTRATION shall fill in the pool handle
      and the PE identifier in order to allow the ENRP server to verify
      the identity of the sending endpoint.  It Note that deregistration is binary
      encoded.

3.1.2 IPv6 Address Parameter

       0                   1                   2                   3 NOT
      allowed by proxy, in other words only a PE may only deregister
      itself.

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 = 0x2         | 0x3  |0|0|0|0|0|0|0|0|        Message Length = 20         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Element Parameter                    :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Action code   |             (reserved)                        |                         IPv6 Address                          |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Operational Error (optional)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IPv6 Address: 128 bit (unsigned integer)

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

3.1.3 Pool Element
      :                    Authorization Parameter

    This parameter is used in multiple ASAP  (optional)        :

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

    Action: (8 bits)

       The message to represent an ASAP
    endpoint (i.e., a PE that this results code is in a pool) response to:

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

    Reserved: (24 bits)

       Ignored by the receiver and set to 0 by the associated information, such
    as its transport address(es), load control, and other operational
    status information of sender.

    Operational Error

       This optional TLV parameter is included if an error
       occured during the PE.

     0                   1                   2                   3 registration/deregistration process.
       If the registration/deregistration was sucessful this
       parameter is not included.

2.2.4 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 = 0x3            |       Length=variable 0xa  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |
      :                     Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    This message is sent to a ENRP server via an SCTP Port            |    Number association to
    request translation of IP addrs=k the Pool Handle to a list of Pool Elements.

2.2.5 NAME_RESOLUTION_RESPONSE message

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0xb  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                        IP addr param #0                     Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                        IP addr param #1                Overall PE Selection Policy                    :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Pool Element Parameter 1                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                             .....                              ...                              :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                        IP addr param #k                    Pool Element Parameter N                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |       Load Policy Type        |        Policy Value           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Registration Life                          |
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Each of the IP address parameters in

Overall PE Selection Policy:

   This is a PE parameter can be either
    an IPv4 or IPv6 address selection policy parameter.

3.1.4 Indicates the overall selection
   policy of the pool. If not present, round-robin is assumed.

   Note, any load policy parameter inside the Pool Handle Element Parameter

     0                   1                   2                   3
   (if present) MUST be ignored, and MUST NOT be used to determine
   the overall pool policy.

2.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 = 0x4            |       Length=variable 0xc  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
    :                     Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                                                               :
    :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    This parameter holds a pool handle that message is a NULL terminated ASCII
    string.

3.1.5 Authorization Parameter

     0                   1                   2                   3 returned by the ENRP server to indicate that
    the requested Pool Handle hold no registered PE's.

2.2.7 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 = 0x5            |       Length=variable 0xd  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Signature                     :

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

    This parameter message is used sent to hold an authorization signature. The
    signature is signed over the entire ASAP message and uses a
    preconfigured public/private key pair. The receiver of a message
    which includes this parameter can validate the message is
    from the sender PE by comparing the signature to one generated
    using the peers public key.

3.2 ASAP Message Formats

   The figure below illustrates ENRP server has a "health"
    check.  If the common format for all ASAP
   messages. Each message transport level Heart Beat mechanism is formatted 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 Message
   Type field, a message-specific Flag field, a Message Length field,
   and a Value field.

       0                   1                   2                   3 more timely fashion.

2.2.8 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Message   Type  |   Msg Flags   | = 0xe  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            PE Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                        Message Value                          :
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type: 8 bits (unsigned integer)

    This field identifies the type of information contained in the
      Message Value field. It takes a value from 0 to 254.  The value
      of 255 message is reserved for future use as an extension field.

      Message Types are encoded such that sent by the highest-order two bits
      specify PE to the action that must be taken if ENRP server has an
    acknowledgment to the ENDPOINT_KEEP_ALIVE message.

2.2.9 ENDPOINT_UNREACHABLE message receiver
      does not recognize 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 Type.

      00 - Stop processing this message and discard it.

      01 - Stop processing Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            PE Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter (optional)         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    A PE or PU will send this message and discard it, and to an ENRP server to report the
	   unrecognized message in an 'Unrecognized Parameter Type'
	   error.

      10 - reserved.

      11 - reserved.

   Message Flags: 8 bits

      The usage
    unreachability of these bits depends on the specified PE.

2.2.10 SERVER_HUNT 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 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 message.  The usage and format of this field
      is dependent on the Message Type.

   The total length of a message (including Type, Length and Value
   fields) MUST be a multiple of 4 bytes.  If the 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x1 0x10 |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                          Pool Handle                          :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Element Parameter         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                 Authorization Parameter (optional)            :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The pool handle parameter field specifies the name to be registered.
    The PE Parameter field shall be filled in

    This message is used by the registrant
    endpoint either a PE or PU to declare its transport addresses, server pooling
    policy and value, and other operation preferences.

3.2.2 DEREGISTRATION request service. It
    is sent on the ENRP client channel.

2.2.11 SERVER_HUNT_RESPONSE message

       0 1 2 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type = 0x2 0x11 |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

    This message is used by a ENRP server to verify
      the identity of the endpoint.

3.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                    :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Action code   |  Result code  |        (reserved)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Action: (8 bits)

       The 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 results code message is in response to:

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

    Result code: (8 bits)

       0x0 -- request granted
       0x1 -- request denied, unspecifed
       0x2 -- request denied, authorization to.

3. Procedures

    This chapter will focus on the methods and procedures used by an
    internal ASAP endpoint. Appropriate timers and recovery actions for
    failure
       0x3 -- request denied, invalid values

    Reserved: (16 bits)

       Ignored 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 receiver ASAP endpoint and set 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 0 by establish its Home ENRP server.

    Once the sender.

3.2.4 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 = 0x4  |0|0|0|0|0|0|0|0|        Message Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

       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                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Pool Element Parameter 1                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                              ...                              :
      :                                                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Pool Element Parameter N                   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.6 NAME_UNKNOWN
        as defined in Section 2.2.1. In formulating the 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         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :
        the ASAP endpoint MUST:

          R2.1) Fill in the the Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.7 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         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      : 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] 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.
          R2.6) Fill in any optional authorization parameter,
                if required.
      R3) Send the Registration request to the Home ENRP server
          using SCTP.
      R4) Start a T2-registration timer.

    If the T2-registration timer expires before receiving 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.
    D2) Fill in the PE Identifier. The identifier MUST be the same
        one used during registration.
    D3) Fill in any optional authorization parameter, if required.
    D4) Send the deregistration message to the Home ENRP server
        using the SCTP association.
    D5) 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)
    or requests a cache population (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.4) with
         the Pool Handle to be resolved.
    NR2) Fill in any optional authorization parameter, as required.
    NR2.1) 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
    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.7). 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) If an authorization parameter is included the
        endpoint SHOULD verify that the message is authentic. If
        the verification fails, silently discard the message.
   KA3) Send a ENDPOINT_KEEP_ALIVE_ACK (section 2.2.8) by:
     KA3.1) Filling in the Pool Handle Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                    Authorization Parameter  (optional)        :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2.8 ENDPOINT_UNREACHABLE with the
            PE's Pool Handle.
     KA3.2) Fill in the PE Identifier that was used with this
            PE for registration.
     KA3.3) Fill in any optional authorization parameter,
            as required.
     KA3.4) Send off the 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         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      : 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 Error.Report primitive
    (section 4.7). 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 Parameter                     :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                     Pool Element Parameter                    :

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

3.2.9
    and PE identifier of the unreachable endpoint and any authorization
    parameter that may be required. 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.10) 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 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 4.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

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

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

4. 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 that between ASAP and its lower layer transport protocol
    (e.g., SCTP).

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

    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)

    where the 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 Pool Handle or by PE handle (see Sections 4.5.1
    and 4.5.2).

    In response to the registration primitive, the ASAP layer endpoint will send
    a REGISTRATION message to the home ENRP server (See section 3.2.1), Section 2.2.1 and
    Section 3.1), 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 4.9.4) in 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
    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 layer endpoint to the home ENRP
    server (see Section 3.2.2). 2.2.2 and Section 3.2).

4.3 Cache.Populate.Request Primitive

    Format: cache.populate.request(destinationAddress, typeOfAddress) 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 layer 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.

    The destinationAddress field contains the address for which the
    cache needs to be populated. The typeOfAddress indicates the address
    type. Allowable types are Pool handle and Pool Element handle.  In
    the case of

    If a Pool Element handle, Pool-Element-Handle is passed then the Pool handle Handle is extracted unpacked
    from the Pool Element handle Pool-Element-Handle and used to form a the NAME.RESOLUTION message (see Section 3.5). 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(destinationAddress, typeOfAddress) cache.purge.request([Pool-Handle | Pool-Element-Handle])

    If the address type is user passes a Pool handle and local name translation cache
    exists, the ASAP layer 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
    sender's
    senders ASAP layer endpoint may perform address translation and Pool
    Element selection before sending the message out. This also MAY
    dictate the creation of a local transport endpoint in order to meet
    the required transport type.

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

4.5.1 Sending to a Pool Handle

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

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

    Before sending the message out to the pool, the sender's senders ASAP layer
    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 sender's 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.4 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 sender's 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 layer 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 a new transport association,

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

    D) transport state,

    E) send out the queued message(s) to the SCTP association appropriate transport
       connection using the appropriate send mechanism (e.g. for
       SCTP the SEND primitive (see [RFC2960]), in [RFC2960] would be used), and,
    E)

    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, id) if a any new
       association transport state was created.

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

    Optionally, the ASAP layer 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 4.5.5 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 sender's senders ASAP layer 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).

    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 server pooling
    policy specified by the first PE joining the pool will
    become the current server pooling policy of the group.

    Moreover, together

    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.

    Note, if this first PE removes itself from the pool
    (e.g., by de-registration from the 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. server (See section 3.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 layer 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 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 layer endpoint of the message sender will select the PE that
    has the lowest policy value in the group as the receiver of the
    current message. If more than one PE from the group share the same
    lowest policy value, the selection will be done round Robin amongst
    those PEs.

    It is important to note that this policy means that the same PE will
    be always selected as the message receiver by the sender until the
    load control information of the pool is updated and changed in the
    local cache of the sender (see (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 layer endpoint to deliver the message to the PE
    identified by the Pool Element handle.

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

    The ASAP layer endpoint shall use the transport address and transport type
    to identify the
    SCTP association (or 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 a new one if necessary) the needed state and
    then invoke the SCTP SEND primitive for the particular transport
    protocol to send the message to the PE.

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

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

    B) determine if the pool handle 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, message (see Section 3.3), 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'.
       'stale.cache.value' (see section 3.3).

    Section 4.5.5? 3.5 and 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 layer endpoint may return the actual Pool Elment 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 an SCTP a transport address. address and transport type.

    This directs the sender's senders ASAP layer 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
    layer.
    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 sender's senders ASAP
    layer
    endpoint on special handling of the message delivery.

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

    ASAP_USE_DEFAULT: 0x0000

    Use default setting.

    ASAP_SEND_FAILOVER: 0x0001

    Enables PE fail-over on this message. In case where the first
    selected PE or the PE pointed to by the PE handle is found
    unreachable, this option allows the sender's senders ASAP layer 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.

    Endpoint unreachable is normally indicated by the SCTP
    COMMUNICATION.LOST or SEND.FAILURE notification.

    ASAP_SEND_NO_FAILOVER: 0x0002
    This option prohibits the sender's senders ASAP layer 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 sender's senders ASAP layer 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 sender's senders ASAP layer 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 sender's senders ASAP
    layer
    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 sender's senders ASAP layer endpoint also deliver a copy of the
    message to itself if the sender is a PE of the pool (i.e., loopback). loop-back).

    ASAP_SCTP_UNORDER: 0x1000

    This option instructs requests the SCTP transport layer to send the current
    message using un-ordered delivery. 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 layer endpoint of the receiver
    uses this notification to pass the message to its upper layer.

    Along with the message being passed, the ASAP layer endpoint of the receiver
    should also indicate to its upper layer the message sender's senders
    address. The sender's 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 layer, endpoint, a reverse mapping from the sender's senders IP
    address to the pool handle should be performed and if the mapping is
    successful, the sender's 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 (see Section
    ? for details). abnormalities.

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

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

4.8 Examples

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

4.8.1 Send to a New Pool

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

    ENRP Server                       PU         new-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 layer, endpoint, in response, looks up the pool "new-name" in its
       local cache but fails to find it.

    2) The ASAP layer 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 layer 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.

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:

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

       The ASAP layer, 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 Handle ASAP to ENRP Communication Failures

    Three types of PE send failure may occur when

    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.9.1 SCTP Send Failure

    This indicates that the SCTP layer failed a PE or PU attempts to deliver send 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
    PE and fails the failed message and start sender will report the
    ENRP server hunt procedure event as described
    in Section ?.

4.9.2 T1-ENRPrequest Timer Expiration

    When a T1-ENRPrequest timer expires, the section 3.5

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

4.9.1 Translation.Request Primitive

    Format: translation.request(Pool-Handle)

    If the ENRP server address type is a Pool handle 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 local name
    translation cache exists, the ASAP user endpoint should look within
    its translation cache and return the ENRP request message associated with current known transport
    types, ports and addresses to the timer
    should be discarded.

4.9.3 Handle ENDPOINT_KEEP_ALIVE Messages

    At times, an ASAP endpoint may receive ENDPOINT_KEEP_ALIVE messages
    (see Section 3.2.7?) from caller.

    If the ENRP server. This message requires Pool handle does not exist in the local name cache or no response and should be silently discarded by name
    cache exists, the ASAP layer.

4.9.4 Home ENRP Server Hunt

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

    The PE or PU shall multicast Pool-Handle. Upon completion of the name resolution, the
    ASAP endpoint should populate the local name cache (if a SERVER_HUNT message over local name
    cache is supported) and return the ENRP
    client channel, transport types, ports and shall repeat
    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 this message every
    <TIMEOUT-SERVER-HUNT> seconds until to a SERVER_HUNT_RESPONSE message
    is received from an ENRP server.

    Then 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 is
    NOT using ASAP it can use this primitive to report the namespace service requests failure to this new home ENRP server.

    Upon
    the reception of ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the SERVER_HUNT message, an "home"
    ENRP server shall
    always reply in response to this primitive. Note ASAP SHOULD NOT send
    a ENDPOINT_UNREACHABLE UNLESS the PE with user as actually made a SERVER_HUNT_RESPONSE message. previous
    request to the translate.request() primitive.

5. Variables, Timers, and Constants

    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-registration-reattempt - If the registration cycle does not
    complete, this

    T3-deregistration- A timer is begun started when sending a deregistration
    request to restart the registration
    process. Normal value for this timer is 10 minutes. 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.

5.2 Thresholds

    Timeout-registration - pre-set threshold; how long an PE
    will wait for minutes or 20 seconds less than the REGISTRATION_RESPONSE from its home ENRP server.

    Timeout-server-hunt Life Timer parameter used
    in the registration request (whichever is less).

    T5-Serverhunt - pre-set threshold; how long a PE will
    wait for This timer is used nto during 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.
    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.

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] 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 [SCTPTLS] or TLS over TCP as described in [RFC2246].
    When using TLS/SCTP we must ensure that RSerPool does not use any
    features of SCTP that are not available to an TLS/SCTP user.  This
    is not a difficult technical problem, but simply a
    requirement. When describing an API of the RSerPool lower layer we
    have also to take into account the differences between TLS and
    SCTP. This is also not difficult, but it is in contrast to the
    IPsec solution which is transparently layered below Rserpool.

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

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

7. References

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

     [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-02.txt, work in progress.

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

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

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

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

     [ENRP-ASAP] - New draft.

17.1 Bibliography

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

8. Acknowledgements Acknowledgments

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

9.  Authors' Addresses

   Randall R. Stewart                 Phone:                      Tel: +1-815-477-2127
   24 Burning Bush Trail.
   Cisco Systems, Inc.                     EMail: rrs@cisco.com
   Crystal Lake, IL 60012
   USA
   8725 West Higgins Road
   Suite 300
   Chicago, Ill 60631

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

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

                    Expires in six months from Mar. 2002