draft-ietf-rserpool-asap-05.txt   draft-ietf-rserpool-asap-06.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: May 1, 2003 Q. Xie Expires: August 27, 2003 Q. Xie
Motorola, Inc. Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Siemens AG February 26, 2003
October 31, 2002
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-05.txt draft-ietf-rserpool-asap-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 1, 2003. This Internet-Draft will expire on August 27, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Aggregate Server Access Protocol (ASAP) in conjunction with the Aggregate Server Access Protocol (ASAP) in conjunction with the
Endpoint Name Resolution Protocol (ENRP) [6] provides a high Endpoint Name Resolution Protocol (ENRP) [6] provides a high
availability data transfer mechanism over IP networks. ASAP uses a availability data transfer mechanism over IP networks. ASAP uses a
name-based addressing model which isolates a logical communication name-based addressing model which isolates a logical communication
endpoint from its IP address(es), thus effectively eliminating the endpoint from its IP address(es), thus effectively eliminating the
binding between the communication endpoint and its physical IP binding between the communication endpoint and its physical IP
address(es) which normally constitutes a single point of failure. address(es) which normally constitutes a single point of failure.
skipping to change at page 3, line 23 skipping to change at page 3, line 23
2. Message Definitions . . . . . . . . . . . . . . . . . . . 8 2. Message Definitions . . . . . . . . . . . . . . . . . . . 8
2.1 ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8 2.1 ASAP Parameter Formats . . . . . . . . . . . . . . . . . . 8
2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8 2.2 ASAP Messages . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 REGISTRATION message . . . . . . . . . . . . . . . . . . . 9 2.2.1 REGISTRATION message . . . . . . . . . . . . . . . . . . . 9
2.2.2 DEREGISTRATION message . . . . . . . . . . . . . . . . . . 9 2.2.2 DEREGISTRATION message . . . . . . . . . . . . . . . . . . 9
2.2.3 REGISTRATION_RESPONSE message . . . . . . . . . . . . . . 10 2.2.3 REGISTRATION_RESPONSE message . . . . . . . . . . . . . . 10
2.2.4 DEREGISTRATION_RESPONSE message . . . . . . . . . . . . . 10 2.2.4 DEREGISTRATION_RESPONSE message . . . . . . . . . . . . . 10
2.2.5 NAME_RESOLUTION message . . . . . . . . . . . . . . . . . 11 2.2.5 NAME_RESOLUTION message . . . . . . . . . . . . . . . . . 11
2.2.6 NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . . . 11 2.2.6 NAME_RESOLUTION_RESPONSE message . . . . . . . . . . . . . 11
2.2.7 ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . . . . . 12 2.2.7 ENDPOINT_KEEP_ALIVE message . . . . . . . . . . . . . . . 12
2.2.8 ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . . . . . 12 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message . . . . . . . . . . . . . 13
2.2.9 ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . . . 13 2.2.9 ENDPOINT_UNREACHABLE message . . . . . . . . . . . . . . . 13
2.2.10 SERVER_ANNOUNCE message . . . . . . . . . . . . . . . . . 13 2.2.10 SERVER_ANNOUNCE message . . . . . . . . . . . . . . . . . 14
2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . . . . 14 2.2.11 COOKIE message . . . . . . . . . . . . . . . . . . . . . . 14
2.2.12 COOKIE_ECHO message . . . . . . . . . . . . . . . . . . . 14 2.2.12 COOKIE_ECHO message . . . . . . . . . . . . . . . . . . . 14
2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . . . . 14 2.2.13 BUSINESS_CARD message . . . . . . . . . . . . . . . . . . 15
2.2.14 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 15 2.2.14 PEER_ERROR message . . . . . . . . . . . . . . . . . . . . 15
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.15 Data Channel Contact message . . . . . . . . . . . . . . . 15
3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 16 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 17 3.1 Registration . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 18 3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 18
3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19 3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 19
3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20 3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 20
3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20 3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 21
3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 21 3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 21
3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . . . 22 3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 23
3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . . . 22 3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . . . 23
3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 22 3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . . . 23
3.9 Business Card handling procedures . . . . . . . . . . . . 23 3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23
4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 24 3.9 Business Card handling procedures . . . . . . . . . . . . 24
4.1 Registration.Request Primitive . . . . . . . . . . . . . . 24 3.10 Data Channel Contact Message . . . . . . . . . . . . . . . 24
4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 24 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 25
4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 25 4.1 Registration.Request Primitive . . . . . . . . . . . . . . 25
4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 25 4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 25
4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 25 4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 26
4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 26 4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 26
4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 27 4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 26
4.5.2.1 Round Robin Policy . . . . . . . . . . . . . . . . . . . . 27 4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 27
4.5.2.2 Least Used Policy . . . . . . . . . . . . . . . . . . . . 27 4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 28
4.5.2.3 Least Used with Degradation Policy . . . . . . . . . . . . 28 4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 29
4.5.2.4 Weighted Round Robin Policy . . . . . . . . . . . . . . . 28 4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 30
4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 28 4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 30
4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 29 4.6 Data.Received Notification . . . . . . . . . . . . . . . . 32
4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 29 4.7 Error.Report Notification . . . . . . . . . . . . . . . . 32
4.6 Data.Received Notification . . . . . . . . . . . . . . . . 30 4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.7 Error.Report Notification . . . . . . . . . . . . . . . . 31 4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 33
4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 34
4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 31 4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 34
4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 33 4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 35
4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 33 4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 35
4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 33 5. Variables, Timers, and Thresholds . . . . . . . . . . . . 36
4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 34 5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5. Variables, Timers, and Thresholds . . . . . . . . . . . . 35 5.2 Thresholds and Variables . . . . . . . . . . . . . . . . . 36
5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6. Security Considerations . . . . . . . . . . . . . . . . . 37
5.2 Thresholds and Variables . . . . . . . . . . . . . . . . . 35 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 38
6. Security Considerations . . . . . . . . . . . . . . . . . 36 Normative References . . . . . . . . . . . . . . . . . . . 39
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 37 Informational References (non-normative) . . . . . . . . . 40
Normative References . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40
Informational References (non-normative) . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39
Full Copyright Statement . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6] Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6]
provides a high availability data transfer mechanism over IP provides a high availability data transfer mechanism over IP
networks. ASAP uses a name-based addressing model which isolates a networks. ASAP uses a name-based addressing model which isolates a
logical communication endpoint from its IP address(es), thus logical communication endpoint from its IP address(es), thus
effectively eliminating the binding between the communication effectively eliminating the binding between the communication
endpoint and its physical IP address(es) which normally constitutes a endpoint and its physical IP address(es) which normally constitutes a
single point of failure. single point of failure.
skipping to change at page 9, line 4 skipping to change at page 8, line 47
0x05 - Name Resolution 0x05 - Name Resolution
0x06 - Name Resolution Response 0x06 - Name Resolution Response
0x07 - Endpoint Keep Alive 0x07 - Endpoint Keep Alive
0x08 - Endpoint Keep Alive Acknowledgement 0x08 - Endpoint Keep Alive Acknowledgement
0x09 - Endpoint Unreachable 0x09 - Endpoint Unreachable
0x0a - Server Announce 0x0a - Server Announce
0x0b - Cookie 0x0b - Cookie
0x0c - Cookie-Echo 0x0c - Cookie-Echo
0x0d - Business Card 0x0d - Business Card
0x0e - Peer Error 0x0e - Peer Error
0x0f - Data Channel Contact
2.2.1 REGISTRATION message 2.2.1 REGISTRATION message
0 1 2 3 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 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 | | Type = 0x1 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 17 skipping to change at page 11, line 17
2.2.5 NAME_RESOLUTION message 2.2.5 NAME_RESOLUTION message
0 1 2 3 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 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 | | Type = 0x5 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Communication Restrictions Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a ENRP server to request translation of the 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 Pool Handle to a list of Pool Elements. If sent from a PE the SCTP
association used for registration SHOULD be used. association used for registration SHOULD be used.
The Communication Restrictons Parameter is an optional parameter that
MAY be included. Note that if a Communication Restrictions Parameter
is NOT present the ENRP server will treat the request the same as if
the requestor had specified any transport for both Control and Data.
2.2.6 NAME_RESOLUTION_RESPONSE message 2.2.6 NAME_RESOLUTION_RESPONSE message
0 1 2 3 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 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 | | Type = 0x6 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Overall PE Selection Policy (optional) : : Overall PE Selection Policy (optional) :
skipping to change at page 16, line 5 skipping to change at page 15, line 40
This message is used to report an operation error. This message is used to report an operation error.
0 1 2 3 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 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 | | Type = 0xe |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operation Error Parameter : : Operation Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.15 Data Channel Contact message
This message is used in communication between a PE and PU. When the
PE wishes the PU to transfer data on a different transport address
this message is sent to the PU by the PE to inform the PU where data
messages should be sent.
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 = 0xf |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: User Transport Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A single User Transport Parameter is included with this message. The
parameter identifies a transport address (UDP, TCP or SCTP) to send
Data to.
3. Procedures 3. Procedures
This section will focus on the methods and procedures used by an This section will focus on the methods and procedures used by an
internal ASAP endpoint. Appropriate timers and recovery actions for internal ASAP endpoint. Appropriate timers and recovery actions for
failure detection and management are also discussed. failure detection and management are also discussed.
3.1 Registration 3.1 Registration
When a PE wishes to join its server pool it MUST use the procedures 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 outlined in this section to register. Often the registration will be
skipping to change at page 24, line 5 skipping to change at page 24, line 42
receiver SHOULD: receiver SHOULD:
BC1) Unpack the business card, and if no entry exists in the BC1) Unpack the business card, and if no entry exists in the
translation cache and one exists, populate the new Pool Handle translation cache and one exists, populate the new Pool Handle
into the cache and request a NAME.RESOLUTION of the pool handle. into the cache and request a NAME.RESOLUTION of the pool handle.
BC2) Create a list for this PE of prefered failover order so that in BC2) Create a list for this PE of prefered failover order so that in
the event of a failure the prefered list will be used to guide the the event of a failure the prefered list will be used to guide the
ASAP endpoint in the selection of an alternate PE. ASAP endpoint in the selection of an alternate PE.
3.10 Data Channel Contact Message
At the beginning of communication between a PE and a PU, a PE may
send this message to info the PU what transport is to be used for
Data. This message SHOULD only be sent at initial contact between a
PE and a PU.
4. The ASAP Interfaces 4. The ASAP Interfaces
This chapter will focus primarily on the primitives and notifications This chapter will focus primarily on the primitives and notifications
that form the interface between the ASAP-user and ASAP and that that form the interface between the ASAP-user and ASAP and that
between ASAP and its lower layer transport protocol (e.g., SCTP). between ASAP and its lower layer transport protocol (e.g., SCTP).
An ASAP User passes primitives to the ASAP sub-layer to request An ASAP User passes primitives to the ASAP sub-layer to request
certain actions. Upon the completion of those actions or upon the certain actions. Upon the completion of those actions or upon the
detection of certain events, the ASAP will notify the ASAP user. detection of certain events, the ASAP will notify the ASAP user.
skipping to change at page 25, line 30 skipping to change at page 26, line 30
Note that if the ASAP service does NOT support a local cache this Note that if the ASAP service does NOT support a local cache this
primitive performs NO action. primitive performs NO action.
4.4 Cache.Purge.Request Primitive 4.4 Cache.Purge.Request Primitive
Format: cache.purge.request([Pool-Handle | Pool-Element-Handle]) Format: cache.purge.request([Pool-Handle | Pool-Element-Handle])
If the user passes a Pool handle and local name translation cache If the user passes a Pool handle and local name translation cache
exists, the ASAP endpoint should remove the mapping information on exists, the ASAP endpoint should remove the mapping information on
the Pool handle from its local cache. If the user passes a Pool- the Pool handle from its local cache. If the user passes a
Element-Handle then the Pool handle within is used for the Pool-Element-Handle then the Pool handle within is used for the
cache.purge.request. cache.purge.request.
Note that if the ASAP service does NOT support a local cache this Note that if the ASAP service does NOT support a local cache this
primitive performs NO action. primitive performs NO action.
4.5 Data.Send.Request Primitive 4.5 Data.Send.Request Primitive
Format: data.send.request(destinationAddress, typeOfAddress, Format: data.send.request(destinationAddress, typeOfAddress,
message, sizeOfMessage, Options); message, sizeOfMessage, Options);
skipping to change at page 30, line 12 skipping to change at page 31, line 12
data.send.request primitive gives directions to the senders ASAP data.send.request primitive gives directions to the senders ASAP
endpoint on special handling of the message delivery. endpoint on special handling of the message delivery.
The value of the Options parameter is generated by bit-wise "OR"ing The value of the Options parameter is generated by bit-wise "OR"ing
of the following pre-defined constants: of the following pre-defined constants:
ASAP_USE_DEFAULT: 0x0000 Use default setting. ASAP_USE_DEFAULT: 0x0000 Use default setting.
ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In 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 case where the first selected PE or the PE pointed to by the PE
handle is found unreachable, this option allows the senders ASAP handle is found unreachable, the sender's ASAP endpoint SHOULD
endpoint to re-select an alternate PE from the same pool if one re-select an alternate PE from the same pool if one exists, and
exists, and silently re-send the message to this newly selected silently re-send the message to this newly selected endpoint.
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 ASAP_SEND_NO_FAILOVER: 0x0002 This option prohibits the senders ASAP
endpoint from re-sending the message to any alternate PE in case 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 that the first selected PE or the PE pointed to by the PE handle
is found unreachable. Instead, the senders ASAP endpoint shall is found unreachable. Instead, the senders ASAP endpoint shall
notify its upper layer about the unreachability with an notify its upper layer about the unreachability with an
Error.Report and return any unsent data. Error.Report and return any unsent data.
ASAP_SEND_TO_LAST: 0x0004 This option requests the senders ASAP 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 endpoint to send the message to the same PE in the pool that the
skipping to change at page 35, line 23 skipping to change at page 36, line 23
the ENRP server (providing application information is queued). the ENRP server (providing application information is queued).
Normally set to 15 seconds. Normally set to 15 seconds.
T2-registration - A timer started when sending a registration request T2-registration - A timer started when sending a registration request
to the home ENRP server, normally set to 30 seconds. to the home ENRP server, normally set to 30 seconds.
T3-deregistration - A timer started when sending a deregistration T3-deregistration - A timer started when sending a deregistration
request to the home ENRP server, normally set to 30 seconds. request to the home ENRP server, normally set to 30 seconds.
T4-reregistration - This timer is started after successful T4-reregistration - This timer is started after successful
registration into the ASAP name space and is used to cause a re- registration into the ASAP name space and is used to cause a
registration at a periodic interval. This timer is normally set re-registration at a periodic interval. This timer is normally
to 10 minutes or 20 seconds less than the Life Timer parameter set to 10 minutes or 20 seconds less than the Life Timer parameter
used in the registration request (whichever is less). used in the registration request (whichever is less).
T5-Serverhunt - This timer is used during the ENRP server hunt T5-Serverhunt - This timer is used during the ENRP server hunt
procedure and is normally set to 120 seconds. procedure and is normally set to 120 seconds.
T6-Serverannounce - This timer gives the time between the sending of T6-Serverannounce - This timer gives the time between the sending of
consequetive SERVER_ANNOUNCE messages. It is normally set to 1 consequetive SERVER_ANNOUNCE messages. It is normally set to 1
second. second.
T7-ENRPoutdate - This timer gives the time a server announcement is T7-ENRPoutdate - This timer gives the time a server announcement is
skipping to change at page 36, line 21 skipping to change at page 37, line 21
network architects based on system requirements. network architects based on system requirements.
For networks that demand IPsec security, implementations MUST support For networks that demand IPsec security, implementations MUST support
SCTPIPSEC [7] which describes IPsec-SCTP. IPsec is two layers below SCTPIPSEC [7] which describes IPsec-SCTP. IPsec is two layers below
RSerPool. Therefore, if IPsec is used for securing Rserpool, no RSerPool. Therefore, if IPsec is used for securing Rserpool, no
changes or special considerations need to be made to Rserpool to changes or special considerations need to be made to Rserpool to
secure the protocol. secure the protocol.
For networks that cannot or do not wish to use IPsec and prefer For networks that cannot or do not wish to use IPsec and prefer
instead TLS, implementations MUST support TLS with SCTP as described instead TLS, implementations MUST support TLS with SCTP as described
in SCTPTLSls [8] or TLS over TCP as described in RFC2246 [3] When in RFC3436 [8] or TLS over TCP as described in RFC2246 [3] When using
using TLS/SCTP we must ensure that RSerPool does not use any features TLS/SCTP we must ensure that RSerPool does not use any features of
of SCTP that are not available to an TLS/SCTP user. This is not a SCTP that are not available to an TLS/SCTP user. This is not a
difficult technical problem, but simply a requirement. When difficult technical problem, but simply a requirement. When
describing an API of the RSerPool lower layer we have also to take describing an API of the RSerPool lower layer we have also to take
into account the differences between TLS and SCTP. This is also not into account the differences between TLS and SCTP. This is also not
difficult, but it is in contrast to the IPsec solution which is difficult, but it is in contrast to the IPsec solution which is
transparently layered below Rserpool. transparently layered below Rserpool.
Support for security is required for the ENRP server and the PEs. Support for security is required for the ENRP server and the PEs.
Security support for the Rserpool end user is optional. Note that Security support for the Rserpool end user is optional. Note that
the end user implementation contains a piece of the Rserpool protocol the end user implementation contains a piece of the Rserpool protocol
-- namely ASAP -- whereby the pool handle is passed for name -- namely ASAP -- whereby the pool handle is passed for name
skipping to change at page 38, line 30 skipping to change at page 39, line 30
[5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Server Access Protocol and Endpoint Name Resolution Protocol Server Access Protocol and Endpoint Name Resolution Protocol
Common Parameters", draft-ietf-rserpool-common-param-01 (work in Common Parameters", draft-ietf-rserpool-common-param-01 (work in
progress), June 2002. progress), June 2002.
[6] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution [6] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution
Protocol (ENRP)", draft-ietf-rserpool-enrp-04 (work in Protocol (ENRP)", draft-ietf-rserpool-enrp-04 (work in
progress), May 2002. progress), May 2002.
[7] Bellovin, S., "On the Use of SCTP with IPsec", draft-ietf-ipsec- [7] Bellovin, S., "On the Use of SCTP with IPsec",
sctp-03 (work in progress), February 2002. draft-ietf-ipsec-sctp-04 (work in progress), October 2002.
[8] Rescorla, E., Tuexen, M. and A. Jungmaier, "TLS over SCTP", [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC
draft-ietf-tsvwg-tls-over-sctp-00 (work in progress), November 3436, December 2002.
2001.
Informational References (non-normative) Informational References (non-normative)
[9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 39, line 41 skipping to change at page 40, line 41
Maureen Stillman Maureen Stillman
Nokia Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
USA USA
Phone: +1-607-273-0724 Phone: +1-607-273-0724
EMail: maureen.stillman@nokia.com EMail: maureen.stillman@nokia.com
Michael Tuexen Michael Tuexen
Siemens AG
ICN WN CC SE 7
D-81359 Munich
Germany Germany
Phone: +49 89 722 47210 Phone:
EMail: Michael.Tuexen@siemens.com EMail: tuexen@fh-muenster.de
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/