[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-xie-rserpool-asap) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 RFC 5352

Network Working Group                                         R. Stewart
Internet-Draft                                       Cisco Systems, Inc.
Expires: December 8, 2004                                         Q. Xie
                                                           Motorola, Inc.
                                                              M. Stillman
                                                                    Nokia
                                                                M. Tuexen
                                                             June 9, 2004


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

Status of this Memo

    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    and any of which I become aware will be disclosed, in accordance with
    RFC 3668.

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

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

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

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

    This Internet-Draft will expire on December 8, 2004.

Copyright Notice

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

Abstract

    Aggregate Server Access Protocol (ASAP) in conjunction with the
    Endpoint Name Resolution Protocol (ENRP) [6] provides a high
    availability data transfer mechanism over IP networks.  ASAP uses a
    name-based addressing model which isolates a logical communication
    endpoint from its IP address(es), thus effectively eliminating the



Stewart, et al.         Expires December 8, 2004                [Page 1]


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


    binding between the communication endpoint and its physical IP
    address(es) which normally constitutes a single point of failure.

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

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

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






























Stewart, et al.         Expires December 8, 2004                [Page 2]


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


Table of Contents

    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   5
      1.1  Definitions  . . . . . . . . . . . . . . . . . . . . . . .   5
      1.2  Organization of this document  . . . . . . . . . . . . . .   7
      1.3  Scope of ASAP  . . . . . . . . . . . . . . . . . . . . . .   7
        1.3.1  Extent of the Namespace  . . . . . . . . . . . . . . .   7
      1.4  Conventions  . . . . . . . . . . . . . . . . . . . . . . .   7
    2.   Message Definitions  . . . . . . . . . . . . . . . . . . . .   8
      2.1  ASAP Parameter Formats . . . . . . . . . . . . . . . . . .   8
      2.2  ASAP Messages  . . . . . . . . . . . . . . . . . . . . . .   8
        2.2.1  REGISTRATION message . . . . . . . . . . . . . . . . .   9
        2.2.2  DEREGISTRATION message . . . . . . . . . . . . . . . .   9
        2.2.3  REGISTRATION_RESPONSE message  . . . . . . . . . . . .  10
        2.2.4  DEREGISTRATION_RESPONSE message  . . . . . . . . . . .  10
        2.2.5  NAME_RESOLUTION message  . . . . . . . . . . . . . . .  11
        2.2.6  NAME_RESOLUTION_RESPONSE message . . . . . . . . . . .  11
        2.2.7  ENDPOINT_KEEP_ALIVE message  . . . . . . . . . . . . .  12
        2.2.8  ENDPOINT_KEEP_ALIVE_ACK message  . . . . . . . . . . .  13
        2.2.9  ENDPOINT_UNREACHABLE message . . . . . . . . . . . . .  13
        2.2.10   SERVER_ANNOUNCE message  . . . . . . . . . . . . . .  13
        2.2.11   COOKIE message . . . . . . . . . . . . . . . . . . .  14
        2.2.12   COOKIE_ECHO message  . . . . . . . . . . . . . . . .  14
        2.2.13   BUSINESS_CARD message  . . . . . . . . . . . . . . .  14
        2.2.14   PEER_ERROR message . . . . . . . . . . . . . . . . .  15
    3.   Procedures . . . . . . . . . . . . . . . . . . . . . . . . .  16
      3.1  Registration . . . . . . . . . . . . . . . . . . . . . . .  16
      3.2  Deregistration . . . . . . . . . . . . . . . . . . . . . .  18
      3.3  Name resolution  . . . . . . . . . . . . . . . . . . . . .  18
      3.4  Endpoint keep alive  . . . . . . . . . . . . . . . . . . .  19
      3.5  Reporting unreachable endpoints  . . . . . . . . . . . . .  20
      3.6  ENRP server hunt procedures  . . . . . . . . . . . . . . .  20
      3.7  Handle ASAP to ENRP Communication Failures . . . . . . . .  22
        3.7.1  SCTP Send Failure  . . . . . . . . . . . . . . . . . .  22
        3.7.2  T1-ENRPrequest Timer Expiration  . . . . . . . . . . .  22
      3.8  Cookie handling procedures . . . . . . . . . . . . . . . .  23
      3.9  Business Card handling procedures  . . . . . . . . . . . .  23
    4.   The ASAP Interfaces  . . . . . . . . . . . . . . . . . . . .  25
      4.1  Registration.Request Primitive . . . . . . . . . . . . . .  25
      4.2  Deregistration.Request Primitive . . . . . . . . . . . . .  25
      4.3  Cache.Populate.Request Primitive . . . . . . . . . . . . .  26
      4.4  Cache.Purge.Request Primitive  . . . . . . . . . . . . . .  26
      4.5  Data.Send.Request Primitive  . . . . . . . . . . . . . . .  26
        4.5.1  Sending to a Pool Handle . . . . . . . . . . . . . . .  27
        4.5.2  Pool Element Selection . . . . . . . . . . . . . . . .  28
        4.5.3  Sending to a Pool Element Handle . . . . . . . . . . .  29
        4.5.4  Send by Transport Address  . . . . . . . . . . . . . .  30
        4.5.5  Message Delivery Options . . . . . . . . . . . . . . .  31



Stewart, et al.         Expires December 8, 2004                [Page 3]


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


      4.6  Data.Received Notification . . . . . . . . . . . . . . . .  32
      4.7  Error.Report Notification  . . . . . . . . . . . . . . . .  32
      4.8  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  33
        4.8.1  Send to a New Pool . . . . . . . . . . . . . . . . . .  33
        4.8.2  Send to a Cached Pool Handle . . . . . . . . . . . . .  34
      4.9  PE send failure  . . . . . . . . . . . . . . . . . . . . .  34
        4.9.1  Translation.Request Primitive  . . . . . . . . . . . .  35
        4.9.2  Transport.Failure Primitive  . . . . . . . . . . . . .  35
    5.   Timers, Variables, and Thresholds  . . . . . . . . . . . . .  36
      5.1  Timers . . . . . . . . . . . . . . . . . . . . . . . . . .  36
      5.2  Variables  . . . . . . . . . . . . . . . . . . . . . . . .  36
      5.3  Thresholds . . . . . . . . . . . . . . . . . . . . . . . .  36
    6.   Security Considerations  . . . . . . . . . . . . . . . . . .  37
      6.1  Implementing Security Mechanisms . . . . . . . . . . . . .  38
    7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  40
    8.   References . . . . . . . . . . . . . . . . . . . . . . . . .  41
    8.1  Normative References . . . . . . . . . . . . . . . . . . . .  41
    8.2  Informational References (non-normative) . . . . . . . . . .  41
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  42
         Intellectual Property and Copyright Statements . . . . . . .  43































Stewart, et al.         Expires December 8, 2004                [Page 4]


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


1.  Introduction

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

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

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

    ASAP uses the Endpoint Name Resolution Protocol (ENRP) to provide a
    high availability name space.  ASAP is responsible for the
    abstraction of the underlying transport technologies, load
    distribution management, fault management, as well as the
    presentation to the upper layer (i.e., the ASAP user) a unified
    primitive interface.

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

    This document defines the ASAP portion of the high availability
    server pool.  ASAP depends on the services of a high availability
    name space a.k.a.  ENRP [6].

1.1  Definitions

    This document uses the following terms:

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

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






Stewart, et al.         Expires December 8, 2004                [Page 5]


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


    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.  Having a "home"
       ENRP server helps provide a mechanism to minimize the number of
       associations a given PE will have.

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

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

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

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

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



Stewart, et al.         Expires December 8, 2004                [Page 6]


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


1.2  Organization of this document

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

1.3  Scope of ASAP

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

1.3.1  Extent of the Namespace

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

1.4  Conventions

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










Stewart, et al.         Expires December 8, 2004                [Page 7]


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


2.  Message Definitions

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

2.1  ASAP Parameter Formats

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

2.2  ASAP Messages

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

    The following ASAP message types are defined in this section:


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







Stewart, et al.         Expires December 8, 2004                [Page 8]


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


2.2.1  REGISTRATION message

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

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

2.2.2  DEREGISTRATION message

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

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














Stewart, et al.         Expires December 8, 2004                [Page 9]


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


2.2.3  REGISTRATION_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 = 0x3  |0|0|0|0|0|0|0|R|        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                     Pool Handle Parameter                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                    PE Identifier Parameter                    :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                   Operational Error (optional)                :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    R (Reject) flag

    When set to '1', indicate that the ENRP server that sent this message
    has rejected the registration.  Otherwise, the registration is
    granted.

    Operational Error

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

2.2.4  DEREGISTRATION_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 = 0x4  |0|0|0|0|0|0|0|0|        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                     Pool Handle Parameter                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                    PE Identifier Parameter                    :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                   Operational Error (optional)                :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Operational Error




Stewart, et al.         Expires December 8, 2004               [Page 10]


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


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

2.2.5  NAME_RESOLUTION 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 = 0x5  |0|0|0|0|0|0|0|0|        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                     Pool Handle Parameter                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    This message is sent to a ENRP server to request translation of the
    Pool Handle to a list of Pool Elements.  If sent from a PE the SCTP
    association used for registration SHOULD be used.

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

    Overall PE Selection Policy:

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

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



Stewart, et al.         Expires December 8, 2004               [Page 11]


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


    overall pool policy.

    Pool Element Parameters

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

    Operational Error

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

2.2.7  ENDPOINT_KEEP_ALIVE 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 = 0x7  |0|0|0|0|0|0|0|0|        Message Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    :                     Pool Handle Parameter                     :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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










Stewart, et al.         Expires December 8, 2004               [Page 12]


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


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

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

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

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

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




Stewart, et al.         Expires December 8, 2004               [Page 13]


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


    This message is sent by an ENRP server such that PUs and PEs know the
    transport layer information necessary to connect to the ENRP server.
    The transport parameters are optional and only TCP and SCTP transport
    parameters are allowed.

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

    This message is sent by a PE to a PU.  It may only be sent when a
    control channel exists between the PE and PU.

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

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

2.2.13  BUSINESS_CARD message

    This message is sent by a PU to a PE or from a PE to a PU.  This
    parameter MUST NOT be sent if a control channel does NOT exists
    between the PE and PU.















Stewart, et al.         Expires December 8, 2004               [Page 14]


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


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

    The sender of this message lists both the Pool that the sender
    belongs to and a preferred list of failover candidates.

2.2.14  PEER_ERROR message

    This message is used to report an operation error.


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






















Stewart, et al.         Expires December 8, 2004               [Page 15]


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


3.  Procedures

    This section will focus on the methods and procedures used by an
    internal ASAP endpoint.  Appropriate timers and recovery actions for
    failure detection and management are also discussed.

3.1  Registration

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

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

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

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



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

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

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

       R2.4) Fill in a User Transport Parameter for the type of transport
          and the data/control channel usage the PE is willing to
          support.  Note, to join 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.



Stewart, et al.         Expires December 8, 2004               [Page 16]


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


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

    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.

    The registration response may also indicate that the registration is
    accepted with a warning, often indicating that the ENRP server might
    have made modifications to the value of some registration attribute
    or attributes (such as policy type, transport usage, etc.).  When
    this happens, the PE SHOULD immediately notify its upper layer about
    the registration modifications.  This gives the upper layer a chance,
    for example, to withdraw itself from the pool if such modifications
    are unacceptable for its operation.

    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.






Stewart, et al.         Expires December 8, 2004               [Page 17]


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


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) Send the deregistration message to the Home ENRP server using the
       SCTP association.

    D4) Start a T3-Deregistration timer.

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

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

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

3.3  Name resolution

    At any time a PE or PU may wish to resolve a name.  This usually will
    occur when a Endpoint sends to a Pool handle ( Section 4.5.1) or
    requests a cache population (Section 4.3) but may occur for other
    reasons (e.g.  the internal ASAP PE wishes to know its peers for
    sending a message to all of them).  When an Endpoint (PE or PU)
    wishes to resolve a name it MUST take the following actions:




Stewart, et al.         Expires December 8, 2004               [Page 18]


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


    NR1) Fill in a NAME_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) 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 (i.e., a
    NAME_RESOLUTION_RESPONSE) 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 use 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



Stewart, et al.         Expires December 8, 2004               [Page 19]


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


    reception of an ENDPOINT_KEEP_ALIVE message the following actions
    MUST be taken:

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

    KA2) Send a ENDPOINT_KEEP_ALIVE_ACK (Section 2.2.8) by:



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

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

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

       KA2.4) Adopt the sender of the ENDPOINT_KEEP_ALIVE message as the
          new home 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 an ASAP user report via the Transport.Failure Primitive
    (Section 4.9.2).  In either case the ASAP endpoint SHOULD report the
    unavailability of the PE by sending an ENDPOINT_UNREACHABLE message
    to its home ENRP server.  The Endpoint should fill in the Pool Handle
    and PE identifier of the unreachable endpoint.  If the sender is a PE
    the message MUST be sent via SCTP to the Endpoints Home ENRP server.
    Note: an ASAP endpoint MUST report No more than once each time it
    encounters such an event.

    Note: when processing a Transport.Failure Primitive (Section 4.9.2)
    the ASAP endpoint MUST NOT send a unreachable report unless the ASAP
    endpoint has sent at least one message to the PE specified by the
    primitive.

3.6  ENRP server hunt procedures

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

    If the multicast capabilities are used an ENRP server MUST send
    periodically every T6-Serverannounce a SERVER_ANNOUNE message



Stewart, et al.         Expires December 8, 2004               [Page 20]


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


    (Section 2.2.10) including all the transport addresses available for
    ASAP communication to the multicast channel.

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

    If no multicast capabilities are used each PU and PE MUST have a
    configured list of transport addresses of ENRP servers.

    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
    establish its Home ENRP server, i.e.  setup a TCP connection or SCTP
    association with an ENRP server.

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

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

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

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

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

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

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





Stewart, et al.         Expires December 8, 2004               [Page 21]


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


       SH5.2) The endpoint SHOULD stop the establishment of associations
          and connections.

       SH5.2) The 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 to
          connect to.

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


3.7  Handle ASAP to ENRP Communication Failures

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

    A) SCTP send failure

    B) T1-ENRPrequest timer expiration

    C) Registration failure

    Registration failure is discussed in Section 3.1

3.7.1  SCTP Send Failure

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

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

3.7.2  T1-ENRPrequest Timer Expiration

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

    This should be repeated up to 'MAX-REQUEST-RETRANSMIT' times.  After
    that, an Error.Report notification should be generated to inform the
    ASAP user and the ENRP request message associated with the timer
    should be discarded.  Note that if an alternate ENRP server responds



Stewart, et al.         Expires December 8, 2004               [Page 22]


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


    the ASAP endpoint SHOULD adopt the responding ENRP server as its new
    "home" server and resend the request to the new "home" server.

3.8  Cookie handling procedures

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

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

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

3.9  Business Card handling procedures

    When communication begins between a PU and a PE (i.e.  the first
    message is sent from the PU to the PE) the ASAP layer in the PU
    SHOULD send a Business card IF the sender is also registered as a PE.
    A PE may also send back to a PU a business card as well.  A Business
    card MUST NOT be sent if a control channel does NOT exist between the
    PU and PE.  After communication as been established between a PE and
    PU at any time either entity may update its failover distribution by
    sending a new Business Card.

    The business card serves two purposes (for both endpoints PU and PE).
    First it lists the endpoints pool handle.  For a PU contacting a PE
    this is essential so that the PE may also gain the full benefits of
    ASAP if the PU is also a PE.  Secondly the business card tells the
    receiver a failover order that is recommended to follow.  This may
    facilitate rendezvous between PE's as well as some control of load
    redistribution upon the failure of any given PE.

    Upon receipt of a Business Card Message (see Section 2.2.13) the
    receiver SHOULD:

    BC1) Unpack the business card, and if no entry exists in the
       translation cache and one exists, populate the new Pool Handle
       into the cache and request a NAME.RESOLUTION of the pool handle.




Stewart, et al.         Expires December 8, 2004               [Page 23]


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


    BC2) Create a list for this PE of preferred failover order so that in
       the event of a failure the preferred list will be used to guide
       the ASAP endpoint in the selection of an alternate PE.
















































Stewart, et al.         Expires December 8, 2004               [Page 24]


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


4.  The ASAP Interfaces

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

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

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

4.1  Registration.Request Primitive

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

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

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

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

4.2  Deregistration.Request Primitive

          Format: deregistration.request(poolHandle)

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




Stewart, et al.         Expires December 8, 2004               [Page 25]


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


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

4.3  Cache.Populate.Request Primitive

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

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

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

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

4.4  Cache.Purge.Request Primitive

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

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

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

4.5  Data.Send.Request Primitive

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

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

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



Stewart, et al.         Expires December 8, 2004               [Page 26]


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


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

4.5.1  Sending to a Pool Handle

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

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

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

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

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

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

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

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

    D) if no transport association or connection exists towards the
       destination PE, ASAP will establish any needed transport state,

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





Stewart, et al.         Expires December 8, 2004               [Page 27]


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


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

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

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

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

4.5.2  Pool Element Selection

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

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

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

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

4.5.2.1  Round Robin Policy

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



Stewart, et al.         Expires December 8, 2004               [Page 28]


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


4.5.2.2  Least Used Policy

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

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

4.5.2.3  Least Used with Degradation Policy

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

    This provides a degradation of the policy towards round Robin policy
    over time.  As with the Least Used policy, every local cache update
    at the sender will bring the policy back to Least Used with
    Degradation.

4.5.2.4  Weighted Round Robin Policy

    [TBD]

4.5.3  Sending to a Pool Element Handle

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

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

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

    The ASAP endpoint shall use the transport address and transport type
    to identify the endpoint to communicate with.  If no communication
    state exists with the peer endpoint (and is required by the transport
    protocol) the ASAP endpoint MAY setup the needed state and then



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


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


    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 name resolution on pool handle by
          sending a NAME.RESOLUTION message (see Section 2.2.5), and

       ii) use the response to update the local cache.

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

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

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

4.5.4  Send by Transport Address

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

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

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






Stewart, et al.         Expires December 8, 2004               [Page 30]


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


4.5.5  Message Delivery Options

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

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

    ASAP_USE_DEFAULT: 0x0000 Use default setting.

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

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

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

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

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

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





Stewart, et al.         Expires December 8, 2004               [Page 31]


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


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


4.6  Data.Received Notification

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

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

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

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

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


4.7  Error.Report Notification


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

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

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

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



Stewart, et al.         Expires December 8, 2004               [Page 32]


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


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

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






Stewart, et al.         Expires December 8, 2004               [Page 33]


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


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

    4) The ENRP Server responds to the query with a
       NAME_RESOLUTION_REPONSE message that contains all the information
       about pool "new-name".

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

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


4.8.2  Send to a Cached Pool Handle

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


      ENRP Server                       PU         new-name:PEx

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


    1) The user at PU invokes:

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

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

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


4.9  PE send failure

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



Stewart, et al.         Expires December 8, 2004               [Page 34]


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


    Section 3.5 .

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

4.9.1  Translation.Request Primitive

            Format: translation.request(Pool-Handle)

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

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

4.9.2  Transport.Failure Primitive

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

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



















Stewart, et al.         Expires December 8, 2004               [Page 35]


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


5.  Timers, Variables, and Thresholds

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

5.1  Timers

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

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

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

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

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

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

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


5.2  Variables

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


5.3  Thresholds

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

    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.



Stewart, et al.         Expires December 8, 2004               [Page 36]


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


6.  Security Considerations

    Threats Introduced by Rserpool and Requirements for Security in
    Response to Threats [7] describes the threats to the Rserpool
    architecture in detail and lists the security requirements in
    response to each threat.  From the threats described in this
    document, the security services required for the Rserpool protocol
    are enumerated below.

    Threat 1) PE registration/deregistration flooding or spoofing
    -----------
    Security mechanism in response: ENRP server authenticates the PE

    Threat 2) PE registers with a malicious ENRP server
    -----------
    Security mechanism in response: PE authenticates the ENRP server

    Threat 1 and 2 taken together results in mutual authentication of the
    ENRP server and the PE.

    Threat 3) Malicious ENRP server joins the ENRP server pool
    -----------
    Security mechanism in response: ENRP servers mutually authenticate

    Threat 4) A PU communicates with a malicious ENRP server for name
    resolution
    -----------
    Security mechanism in response: The PU authenticates the ENRP server

    Threat 5) Replay attack
    -----------
    Security mechanism in response: Security protocol which has
    protection from replay attacks

    Threat 6) Corrupted data which causes a PU to have misinformation
    concerning a pool handle resolution
    -----------
    Security mechanism in response: Security protocol which supports
    integrity protection

    Threat 7) Eavesdropper snooping on namespace information
    -----------
    Security mechanism in response: Security protocol which supports data
    confidentiality

    Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP
    server
    -----------



Stewart, et al.         Expires December 8, 2004               [Page 37]


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


    Security mechanism in response: ASAP must control the number of
    endpoint unreachable messages transmitted from the PU to the ENRP
    server.

    Threat 9) Flood of Endpoint_KeepAlive messages to the PE from the
    ENRP server
    -----------
    Security mechanism in response: ENRP server must control the number
    of Endpoint_KeepAlive messages to the PE

    To summarize the threats 1-7 require security mechanisms which
    support authentication, integrity, data confidentiality, protection
    from replay attacks.

    For Rserpool we need to authenticate the following:

       PU <----  ENRP Server (PU authenticates the ENRP server)
       PE <----> ENRP Server (mutual authentication)
       ENRP server <-----> ENRP Server (mutual authentication)

    We do not define any new security mechanisms specifically for
    responding to threats 1-7.  Rather we use existing IETF security
    protocols to provide the security services required.  TLS supports
    all these requirements and MUST be implemented.  The
    TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
    minimum by implementers of TLS for Rserpool.  For purposes of
    backwards compatibility, ENRP SHOULD support
    TLS_RSA_WITH_3DES_EDE_CBC_SHA.  Implementers MAY also support any
    other ciphersuite.

    Threat 8 requires the ASAP protocol to limit the number of
    Endpoint_Unreachable messages (see Section 3.5) to the ENRP server.

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

6.1  Implementing Security Mechanisms

    ENRP servers, PEs, PUs MUST implement TLS.  ENRP servers and PEs must
    support mutual authentication.  ENRP servers must support mutual
    authentication among themselves.  PUs MUST authenticate ENRP servers.

    ENRP servers and PEs SHOULD possess a site certificate whose subject
    corresponds to their canonical hostname.  PUs MAY have certificates
    of their own for mutual authentication with TLS, but no provisions
    are set forth in this document for their use.  All Rserpool elements
    that support TLS MUST have a mechanism for validating certificates
    received during TLS negotiation; this entails possession of one or



Stewart, et al.         Expires December 8, 2004               [Page 38]


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


    more root certificates issued by certificate authorities (preferably
    well-known distributors of site certificates comparable to those that
    issue root certificates for web browsers).

    Implementations MUST support TLS with SCTP as described in RFC3436
    [8] or TLS over TCP as described in RFC2246 [3].  When using TLS/SCTP
    we must ensure that RSerPool does not use any features of SCTP that
    are not available to an TLS/SCTP user.  This is not a difficult
    technical problem, but simply a requirement.  When describing an API
    of the RSerPool lower layer we have also to take into account the
    differences between TLS and SCTP.








































Stewart, et al.         Expires December 8, 2004               [Page 39]


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


7.  Acknowledgments

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















































Stewart, et al.         Expires December 8, 2004               [Page 40]


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


8.  References

8.1  Normative References

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

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

    [3]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
         P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
         1999.

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

    [5]  Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
         Server Access Protocol (ASAP) and Endpoint Name Resolution
         Protocol (ENRP) Parameters", draft-ietf-rserpool-common-param-06
         (work in progress), June 2004.

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

    [7]  Stillman, M., "Threats Introduced by Rserpool and Requirements
         for Security in Response to Threats",
         draft-ietf-rserpool-threats-02 (work in progress), Sept 2003.

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

8.2  Informational References (non-normative)

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













Stewart, et al.         Expires December 8, 2004               [Page 41]


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


Authors' Addresses

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

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


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

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


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

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


    Michael Tuexen

    Germany

    Phone:
    EMail: tuexen@fh-muenster.de












Stewart, et al.         Expires December 8, 2004               [Page 42]


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


Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    ietf-ipr@ietf.org.


Disclaimer of Validity

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

    Copyright (C) The Internet Society (2004).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Stewart, et al.         Expires December 8, 2004               [Page 43]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/