tech-invite   World Map
3GPP     Specs     Glossaries     UICC       T+       IETF     RFCs     Groups     SIP     ABNFs       Search     Home

RFC 5352

 
 
 

Aggregate Server Access Protocol (ASAP)

Part 2 of 3, p. 18 to 42
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 18 
3.  Procedures

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

3.1.  Registration

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

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

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

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

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

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

Top      Up      ToC       Page 19 
      R2.3)  Fill in the Registration Lifetime parameter with the number
         of seconds that this registration is valid for.  Note that a PE
         that wishes to continue service MUST re-register before the
         registration expires.

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

      R2.5)  Fill in the preferred Pool Member Selection Policy
         parameter.

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

   R4)  Start a T2-registration timer.

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

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

   At the reception of the registration response, the PE MUST stop the
   T2-registration timer.  If the response indicates success, the PE is
   registered and will be considered an available member of the server
   pool.  If the registration response indicates a failure, the PE must
   either re-attempt registration after correcting the error or return a
   failure indication to the PE's upper layer.  The PE 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.

Top      Up      ToC       Page 20 
   Note that an implementation SHOULD keep a record of the number of
   registration (and re-registration) attempts it makes in a local
   variable that gets set to zero before the initial registration
   attempt to the Home ENRP server or after a successful re-
   registration.  If repeated registration timeouts 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.

   The ENRP server handles the ASAP_REGISTRATION message according to
   the following rules:

   1.  If the named pool does not exist in the handlespace, the ENRP
       server MUST create a new pool with that handle in the handlespace
       and add the PE to the pool as its first PE.

       When a new pool is created, the overall member selection policy
       of the pool MUST be set to the policy type indicated by the first
       PE, the overall pool transport type MUST be set to the transport
       type indicated by the PE, and the overall pool data/control
       channel configuration MUST be set to what is indicated in the
       Transport Use field of the User Transport parameter by the
       registering PE.

   2.  If the named pool already exists in the handlespace, but the
       requesting PE is not currently a member of the pool, the ENRP
       server will add the PE as a new member to the pool.

       However, before adding the PE to the pool, the server MUST check
       if the policy type, transport type, and transport usage indicated
       by the registering PE is consistent with those of the pool.  If
       different, the ENRP server MUST reject the registration.

   3.  If the named pool already exists in the handlespace *and* the
       requesting PE is already a member of the pool, the ENRP server
       SHOULD consider this as a re-registration case.  The ENRP server
       MUST perform the same tests on policy, transport type, and
       transport use, as described above.  If the re-registration is
       accepted after the test, the ENRP server SHOULD replace the
       attributes of the existing PE with the information carried in the
       received ASAP_REGISTRATION message.

   4.  After accepting the registration, the ENRP server MUST assign
       itself the owner of this PE.  If this is a re-registration, the
       ENRP server MUST take over ownership of this PE, regardless of
       whether the PE was previously owned by this server or by another

Top      Up      ToC       Page 21 
       server.  The ENRP server MUST also record the SCTP transport
       address from which it received the ASAP_REGISTRATION in the ASAP
       Transport parameter TLV inside the PE parameter of this PE.

   5.  The ENRP server may reject the registration due to other reasons
       such as invalid values, lack of resource, authentication failure,
       etc.

   In all above cases, the ENRP server MUST reply to the requesting PE
   with an ASAP_REGISTRATION_RESPONSE message.  If the registration is
   accepted, the ENRP server MUST set the R flag in the
   ASAP_REGISTRATION_RESPONSE to '0'.  If the registration is rejected,
   the ENRP server MUST indicate the rejection by setting the R flag in
   the ASAP_REGISTRATION_RESPONSE to '1'.

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

   If the registration is granted (either a new registration or a re-
   registration case), the ENRP server MUST assign itself to be the Home
   ENRP server of the PE, i.e., to "own" the PE.

      Implementation note: For better performance, the ENRP server may
      find it both efficient and convenient to internally maintain two
      separate PE lists or tables -- one is for the PEs that are owned
      by the ENRP server and the other is for all the PEs owned by their
      peer(s).

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

3.2.  De-Registration

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

   When de-registering, the PE SHOULD use the SCTP association that was
   used for registration with its Home ENRP server.  To de-register, the
   PE's ASAP Endpoint MUST take the following actions:

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

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

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

   D4)  Start a T3-Deregistration timer.

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

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

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

   Upon receiving the message, the ENRP server SHALL remove the PE from
   its handlespace.  Moreover, if the PE is the last one of the named
   pool, the ENRP server will remove the pool from the handlespace as
   well.

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

   The ENRP server may reject the de-registration request for various
   reasons, such as invalid parameters, authentication failure, etc.

   In response, the ENRP server MUST send an
   ASAP_DEREGISTRATION_RESPONSE message to the PE.  If the de-
   registration is rejected, the ENRP server MUST indicate the rejection
   by including the proper Operational Error parameter.

Top      Up      ToC       Page 23 
   It should be noted that de-registration does not stop the PE from
   sending or receiving application messages.

   Once the de-registration request is granted *and* the PE removed from
   its local copy of the handlespace, the ENRP server MUST take the
   handlespace update action to inform its peers about the change just
   made.  Otherwise, the ENRP server MUST NOT inform its peers.

3.3.  Handle Resolution

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

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

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

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

   NR4)  Start a T1-ENRPrequest timer.

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

   At the reception of the ASAP_HANDLE_RESOLUTION_RESPONSE message, the
   ASAP Endpoint MUST stop its T1-ENRPrequest timer.  After stopping the
   T1-ENRPrequest timer, the ASAP Endpoint SHOULD process the message as
   appropriate (e.g., populate a local cache, give the response to the
   ASAP User, and/or use the response to send the ASAP User's message).

Top      Up      ToC       Page 24 
   Note that some ASAP Endpoints MAY use a cache to minimize the number
   of handle resolutions sent.  If a cache is used, it SHOULD:

   C1)  Be consulted before sending a handle resolution.

   C2)  Have a stale timeout timer associated with each cache entry.  If
      the cache entry is determined to be stale upon a cache hit, a
      handle resolution message SHOULD be sent so the cache can be
      updated.

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

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

   It should be noted that the impact of using a cache depends on the
   policy and the requirements of the application.  For some
   applications, cache-usage can increase the performance of the system;
   for some, it can decrease it.

   An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION
   requests from PUs, either over an SCTP association on the well-known
   SCTP port, or over a TCP connection on the well-known TCP port.

   Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server
   MUST first look up the pool handle in its handlespace.  If the pool
   exists, the Home ENRP server MUST compose and send back an
   ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU.

   In the response message, the ENRP server SHOULD list all the PEs
   currently registered in this pool, in a list of PE parameters.  The
   ENRP server MUST also include a pool member selection policy
   parameter to indicate the overall member selection policy for the
   pool, if the current pool member selection policy is not Round-Robin.

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

Top      Up      ToC       Page 25 
3.4.  Endpoint Keep Alive

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

   The use of the ASAP_ENDPOINT_KEEP_ALIVE message (Section 2.2.7) and
   the ASAP_ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) is described below.
   Upon reception of an ASAP_ENDPOINT_KEEP_ALIVE message, the following
   actions MUST be taken:

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

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

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

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

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

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

Top      Up      ToC       Page 26 
3.5.  Unreachable Endpoints

   Occasionally, an ASAP Endpoint may realize a PE is unreachable.  This
   may occur by a specific SCTP error realized by the ASAP endpoint or
   via an ASAP User report via the Transport.Failure Primitive
   (Section 6.9.2).  In either case, the ASAP Endpoint SHOULD report the
   unavailability of the PE by sending an ASAP_ENDPOINT_UNREACHABLE
   message to any ENRP server.  Before sending the
   ASAP_ENDPOINT_UNREACHABLE message, the ASAP Endpoint should fill in
   the Pool Handle parameter and PE Identifier parameter of the
   unreachable endpoint.  If the sender is a PE, the message MUST be
   sent via SCTP.  It should be noted that an ASAP Endpoint MUST report
   no more than once each time it encounters such an event.
   Additionally, when processing a Transport.Failure Primitive
   (Section 6.9.2), the ASAP Endpoint MUST NOT send an
   ASAP_ENDPOINT_UNREACHABLE message unless the user has made a previous
   request to send data to the PE specified by the primitive.

   Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, an ENRP
   server MUST immediately send a point-to-point
   ASAP_ENDPOINT_KEEP_ALIVE message to the PE in question (the H flag in
   the message SHOULD be set to '0', in this case).  If this
   ASAP_ENDPOINT_KEEP_ALIVE fails (e.g., it results in an SCTP
   SEND.FAILURE notification), the ENRP server MUST consider the PE as
   truly unreachable and MUST remove the PE from its handlespace.

   If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully
   to the PE, the ENRP server MUST retain the PE in its handlespace.
   Moreover, the server SHOULD keep a counter to record how many
   ASAP_ENDPOINT_UNREACHABLE messages it has received reporting
   reachability problem relating to this PE.  If the counter exceeds the
   protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove
   the PE from its handlespace.

   Optionally, an ENRP server may also periodically send point-to-point
   ASAP_ENDPOINT_KEEP_ALIVE (with the H flag set to '0') messages to
   each of the PEs owned by the ENRP server in order to check their
   reachability status.  If the sending of ASAP_ENDPOINT_KEEP_ALIVE to a
   PE fails, the ENRP server MUST consider the PE as unreachable and
   MUST remove the PE from its handlespace.  Note, if an ENRP server
   owns a large number of PEs, the implementation should pay attention
   not to flood the network with bursts of ASAP_ENDPOINT_KEEP_ALIVE
   messages.  Instead, the implementation MUST distribute the
   ASAP_ENDPOINT_KEEP_ALIVE message traffic over a time period.  This
   can be achieved by varying the time between two
   ASAP_ENDPOINT_KEEP_ALIVE messages to the same PE randomly by plus/
   minus 50 percent.

Top      Up      ToC       Page 27 
3.6.  ENRP Server Hunt Procedures

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

   If multicast capabilities are used within the operational scope, an
   ENRP server MUST send periodically every (N+1)*T6-Serverannounce an
   ASAP_SERVER_ANNOUNCE message (Section 2.2.10), which includes all the
   transport addresses available for ASAP communication on the multicast
   ENRP client channel, where N is the number of ENRP servers the server
   has found via receiving ASAP_SERVER_ANNOUNCE messages.  This should
   result in a message rate of approximately 1 ASAP_SERVER_ANNOUNCE per
   T6-Serverannounce.

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

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

   At its startup, or when it fails to communicate with its Home ENRP
   server (i.e., timed out on an ENRP request), a PE or PU MUST
   establish a new Home ENRP server (i.e., set up a TCP connection or
   SCTP association with a different ENRP server).

   To establish a Home ENRP server, the following rules MUST be
   followed:

   SH1)  The PE or PU SHOULD try to establish an association or
      connection, with no more than three ENRP servers.  An ASAP
      Endpoint MUST NOT establish more than three associations or
      connections.

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

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

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

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

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

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

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

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

3.7.  Handling ASAP Endpoint to ENRP Server Communication Failures

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

   A) SCTP send failure

   B) T1-ENRPrequest timer expiration

   C) Registration failure

3.7.1.  SCTP Send Failure

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

Top      Up      ToC       Page 29 
   In such a case, the ASAP Endpoint MUST NOT re-send the undeliverable
   message.  Instead, it SHOULD discard the message and start the ENRP
   Server Hunt procedure as described in Section 3.6.  After finding a
   new Home ENRP server, the ASAP Endpoint should re-send the request.

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

3.7.2.  T1-ENRPrequest Timer Expiration

   When the T1-ENRPrequest timer expires, the ASAP Endpoint should re-
   send the original request to the ENRP server and restart the T1-
   ENRPrequest timer.  In parallel, the ASAP Endpoint should begin the
   ENRP server hunt procedures described in Section 3.6.

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

3.7.3.  Registration Failure

   Registration failure is discussed in Section 3.1.

3.8.  Cookie Handling Procedures

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

   Note: A control channel is a communication channel between a PU and
   PE that does not carry data passed to the user.  This is accomplished
   with SCTP by using a PPID to separate the ASAP messages (Cookie and
   Business Card) from normal data messages.

   If the PU's ASAP Endpoint detects a failure and initiates a failover
   to a different PE, it SHOULD send the latest received cookie
   parameter in an ASAP_COOKIE_ECHO message to the new PE as the first
   message on the control channel.  Upper layers may be involved in the
   failover procedure.

Top      Up      ToC       Page 30 
   The cookie handling procedure can be used for state sharing.
   Therefore, a cookie should be signed by the sending PE ASAP Endpoint
   and the cookie should be verified by the receiving PE's ASAP
   Endpoint.  The details of the verification procedure are out of scope
   for this document.  It is only important that the PU always stores
   the last received Cookie parameter and sends that back unmodified in
   case of a PE failure.

3.9.  Business Card Handling Procedures

   When communication begins between a PU and a PE, either of which
   could be part of a PU/PE combination (i.e., a message is sent between
   the entities), a PE should always send an ASAP_BUSINESS_CARD message
   to a PU.  A PU should send an ASAP_BUSINESS_CARD message to a PE only
   if it is part of a PU/PE combination.  An ASAP_BUSINESS_CARD message
   MUST ONLY be sent if a control channel exists between a PU and PE.
   After communication has been established between a PE and PU, a new
   ASAP_BUSINESS_CARD message may be sent at any time by either entity
   to update its failover order.

   The ASAP_BUSINESS_CARD message serves two purposes.  First, it lists
   the pool handle.  For a PU that is part of a PU/PE combination that
   is contacting a PE, this is essential so that the PE learns the pool
   handle of the PU/PE combination requesting service.  Secondly, the
   ASAP_BUSINESS_CARD message tells the receiving entity a failover
   order that is recommended to follow.  This should facilitate
   rendezvous between entities that have been working together, as well
   as to control the load redistribution upon the failure of any PE.

   Upon receipt of an ASAP_BUSINESS_CARD message (see Section 2.2.13),
   the receiving ASAP Endpoint SHOULD:

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

   BC2)  Unpack the message and populate a preferred list for failover
      order.  If the peer's PE should fail, this preferred list will be
      used to guide the ASAP Endpoint in the selection of an alternate
      PE.

Top      Up      ToC       Page 31 
4.  Roles of Endpoints

   A PU MUST implement the handling of ASAP_HANDLE_RESOLUTION and
   ASAP_HANDLE_RESOLUTION_RESPONSE messages.  Furthermore, it MUST
   support the handling of ASAP_ERROR messages.  It MAY implement the
   handling of ASAP_COOKIE, ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD
   messages.  It MAY also implement the handling of ASAP_SERVER_ANNOUNCE
   messages.

   A PE MUST implement the handling of ASAP_REGISTRATION,
   ASAP_DEREGISTRATION, ASAP_REGISTRATION_RESPONSE, and
   ASAP_DEREGISTRATION_RESPONSE messages.  Furthermore, it MUST support
   the handling of ASAP_ENDPOINT_KEEP_ALIVE,
   ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and
   ASAP_ERROR messages.  It SHOULD support the handling of ASAP_COOKIE,
   ASAP_COOKIE_ECHO, and ASAP_BUSINESS_CARD messages.  Furthermore, it
   MAY support the handling of ASAP_SERVER_ANNOUNCE messages.

   An ENRP server MUST implement the handling of ASAP_REGISTRATION,
   ASAP_DEREGISTRATION, ASAP_REGISTRATION_RESPONSE, and
   ASAP_DEREGISTRATION_RESPONSE messages.  Furthermore, it MUST support
   the handling of ASAP_ENDPOINT_KEEP_ALIVE,
   ASAP_ENDPOINT_KEEP_ALIVE_ACK, ASAP_ENDPOINT_UNREACHABLE, and
   ASAP_ERROR messages.  Furthermore, it MAY support the handling of
   ASAP_SERVER_ANNOUNCE messages.

   If a node acts as a PU and a PE, it MUST fulfill both roles.

5.  SCTP Considerations

   Each ASAP message is considered as an SCTP user message.  The PPID
   registered for ASAP SHOULD be used.  The SCTP port used at the ENRP
   server might be preconfigured or announced in the
   ASAP_SERVER_ANNOUNCE message or the well-known ASAP port.

   ASAP messages belonging to the control channel MUST be sent using the
   PPID registered for ASAP.  Messages belonging to the data channel
   MUST NOT use the PPID registered for ASAP.

6.  The ASAP Interfaces

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

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

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

6.1.  Registration.Request Primitive

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

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

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

   In response to the registration primitive, the ASAP Endpoint will
   send an ASAP_REGISTRATION message to the Home ENRP server (see
   Sections 2.2.1 and 3.1), and start a T2-registration timer.

6.2.  Deregistration.Request Primitive

         Format: deregistration.request(Pool Handle)

   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.

   An ASAP_DEREGISTRATION message will be sent by the ASAP Endpoint to
   the Home ENRP server (see Sections 2.2.2 and 3.2).

Top      Up      ToC       Page 33 
6.3.  CachePopulateRequest Primitive

          Format: cache_populate_request([Pool-Handle |
                                        Pool-Element-Handle])

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

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

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

6.4.  CachePurgeRequest Primitive

      Format: cache_purge_request([Pool-Handle | Pool-Element-Handle])

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

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

6.5.  DataSendRequest 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
   ASAP Endpoint may perform address translation and Pool Element
   selection before sending the message out.  This MAY also 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.

Top      Up      ToC       Page 34 
6.5.1.  Sending to a Pool Handle

   In this case, the destinationAddress and typeOfAddress together
   indicate 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 ASAP
   endpoint MUST first perform a pool handle to address translation.  It
   may also need to perform Pool Element selection if multiple Pool
   Elements exist in the pool.

   If the sender's 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 an
   ASAP_HANDLE_RESOLUTION message (see Sections 2.2.5 and 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 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, choose one of them and transmit
      the message to it.  In that case, the choice of the PE is made by
      the ASAP Endpoint of the sender based on the server pooling
      policy, as discussed in Section 6.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, establish any needed transport state;

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

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

Top      Up      ToC       Page 35 
   For more on the ENRP server request procedures see [RFC5353].

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

   Section 3.7 defines the failover procedures for cases where the
   selected PE is found unreachable.

6.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 ASAP Endpoint must select one of the PEs in
   the pool as the receiver of the current message.  The selection is
   made 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 6.5.5).

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

   One basic policy is defined in this document; others can be found in
   [RFC5356]

6.5.2.1.  Round-Robin Policy

   When an ASAP Endpoint sends messages by Pool Handle and Round-Robin
   is the current policy of that Pool, the ASAP Endpoint of the sender
   will select the receiver for each outbound message by Round-Robining
   through all the registered PEs in that Pool, in an attempt to achieve
   an even distribution of outbound messages.  Note that in a large
   server pool, the ENRP server might 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.

6.5.3.  Sending to a Pool Element Handle

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

Top      Up      ToC       Page 36 
   This requests that the ASAP Endpoint deliver the message to the PE
   identified by the Pool Element handle.

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

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

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

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

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

      If it is *not*, the endpoint will:


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

      ii)  use the response to update the local cache.

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

   Sections 3.5 and 6.9 define the failover procedures for cases where
   the PE pointed to by the Pool Element handle is found to be
   unreachable.

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

Top      Up      ToC       Page 37 
6.5.4.  Send by Transport Address

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

   This directs the sender's ASAP Endpoint to send the message out to
   the specified transport address.

   No endpoint failover is supported when this form of send request is
   used.  This form of send request effectively bypasses the ASAP
   endpoint.

6.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 ASAP
   endpoint on special handling of the message delivery.

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

   ASAP_USE_DEFAULT: 0x0000  Use default setting.

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

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

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

   ASAP_SEND_TO_LAST: 0x0004  This option requests that the sender's
      ASAP Endpoint send the message to the same PE in the pool to which
      the previous message destined to this pool was sent.

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

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

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

6.6.  Data.Received Notification

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

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

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

   A) If the handle translation local cache is implemented at the
      receiver's ASAP Endpoint, a reverse mapping from the sender's IP
      address to the pool handle should be performed, and if the mapping
      is successful, the sender's 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.

Top      Up      ToC       Page 39 
6.7.  Error.Report Notification

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

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

   The destinationAddress and typeOfAddress together indicate to whom
   the message was originally sent.  The address type can be either an
   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.

6.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 the PU and ENRP server and the PE and ENRP servers would be
   using SCTP.

6.8.1.  Send to a New Pool

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

     ENRP Server                       PU         new-handle:PEx

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

Top      Up      ToC       Page 40 
   1) The user at PU invokes:

      data_send_request("new-handle", handle-type, "hello1", 6, 0);

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


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

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

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

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

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

6.8.2.  Send to a Cached Pool Handle

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


     ENRP Server                       PU         new-handle:PEx

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

Top      Up      ToC       Page 41 
   1) The user at PU invokes:

      data_send_request("new-handle", handle-type, "hello2", 6, 0);

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

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

6.9.  PE Send Failure

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

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

6.9.1.  Translation.Request Primitive

           Format: translation.request(Pool-Handle)

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

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

Top      Up      ToC       Page 42 
6.9.2.  Transport.Failure Primitive

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

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



(page 42 continued on part 3)

Next RFC Part