RFC 5352 on Aggregate Server Access Protocol (ASAP)

rfc-editor@rfc-editor.org Tue, 30 September 2008 17:26 UTC

Return-Path: <ietf-announce-bounces@ietf.org>
X-Original-To: ietf-announce-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-announce-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242B73A69F2; Tue, 30 Sep 2008 10:26:24 -0700 (PDT)
X-Original-To: ietf-announce@core3.amsl.com
Delivered-To: ietf-announce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A592B3A6A15; Tue, 30 Sep 2008 10:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.474
X-Spam-Level:
X-Spam-Status: No, score=-17.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC7Mef+oMdT7; Tue, 30 Sep 2008 10:26:21 -0700 (PDT)
Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id B27953A67F8; Tue, 30 Sep 2008 10:26:21 -0700 (PDT)
Received: by bosco.isi.edu (Postfix, from userid 70) id A14E815ECF4; Tue, 30 Sep 2008 10:26:43 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Subject: RFC 5352 on Aggregate Server Access Protocol (ASAP)
From: rfc-editor@rfc-editor.org
Message-Id: <20080930172643.A14E815ECF4@bosco.isi.edu>
Date: Tue, 30 Sep 2008 10:26:43 -0700
Cc: rserpool@ietf.org, rfc-editor@rfc-editor.org
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5352

        Title:      Aggregate Server Access Protocol (ASAP) 
        Author:     R. Stewart, Q. Xie,
                    M. Stillman, M. Tuexen
        Status:     Experimental
        Date:       September 2008
        Mailbox:    randall@lakerest.net, 
                    Qiaobing.Xie@gmail.org, 
                    maureen.stillman@nokia.com,
                    tuexen@fh-muenster.de
        Pages:      53
        Characters: 118712
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-rserpool-asap-21.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5352.txt

Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction
with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353),
provides a high-availability data transfer mechanism over IP
networks.  ASAP uses a handle-based addressing model that isolates a
logical communication endpoint from its IP address(es), thus
effectively eliminating the binding between the communication
endpoint and its physical IP address(es), which normally constitutes
a single point of failure.

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

ASAP is designed to take full advantage of the network level
redundancy provided by the Stream Transmission Control Protocol
(SCTP; RFC 4960).  Each transport protocol, other than SCTP, MUST
have an accompanying transport mapping document.  It should be noted
that ASAP messages passed between Pool Elements (PEs) and ENRP
servers MUST use the SCTP transport protocol.

The high-availability server pooling is gained by combining two
protocols, namely ASAP and ENRP, in which ASAP provides the user
interface for Pool Handle to address translation, load sharing
management, and fault management, while ENRP defines the high-
availability Pool Handle translation service.  This memo defines an 
Experimental Protocol for the Internet community.

This document is a product of the Reliable Server Pooling Working Group of the IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce