draft-ietf-rserpool-enrp-11.txt   draft-ietf-rserpool-enrp-12.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Expires: August 22, 2005 R. Stewart Expires: January 16, 2006 R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences
A. Silverton A. Silverton
Motorola, Inc. Motorola, Inc.
February 18, 2005 July 15, 2005
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
draft-ietf-rserpool-enrp-11.txt draft-ietf-rserpool-enrp-12.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 other groups may also distribute working documents as Internet-
Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://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 August 22, 2005. This Internet-Draft will expire on January 16, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work
in conjunction with the Aggregate Server Access Protocol (ASAP) to in conjunction with the Aggregate Server Access Protocol (ASAP) to
accomplish the functionality of the Reliable Server Pooling accomplish the functionality of the Reliable Server Pooling
(Rserpool) requirements and architecture. Within the operational (Rserpool) requirements and architecture. Within the operational
scope of Rserpool, ENRP defines the procedures and message formats of scope of Rserpool, ENRP defines the procedures and message formats of
a distributed, fault-tolerant registry service for storing, a distributed, fault-tolerant registry service for storing,
bookkeeping, retrieving, and distributing pool operation and bookkeeping, retrieving, and distributing pool operation and
membership information. membership information.
Table of Contents Table of Contents
skipping to change at page 2, line 28 skipping to change at page 2, line 27
2. ENRP Message Definitions . . . . . . . . . . . . . . . . . . 6 2. ENRP Message Definitions . . . . . . . . . . . . . . . . . . 6
2.1 ENRP_PRESENCE message . . . . . . . . . . . . . . . . . . 6 2.1 ENRP_PRESENCE message . . . . . . . . . . . . . . . . . . 6
2.2 ENRP_HANDLE_TABLE_REQUEST message . . . . . . . . . . . . 8 2.2 ENRP_HANDLE_TABLE_REQUEST message . . . . . . . . . . . . 8
2.3 ENRP_HANDLE_TABLE_RESPONSE message . . . . . . . . . . . . 8 2.3 ENRP_HANDLE_TABLE_RESPONSE message . . . . . . . . . . . . 8
2.4 ENRP_HANDLE_UPDATE message . . . . . . . . . . . . . . . . 10 2.4 ENRP_HANDLE_UPDATE message . . . . . . . . . . . . . . . . 10
2.5 ENRP_LIST_REQUEST message . . . . . . . . . . . . . . . . 11 2.5 ENRP_LIST_REQUEST message . . . . . . . . . . . . . . . . 11
2.6 ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 12 2.6 ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 12
2.7 ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 13 2.7 ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 13
2.8 ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14 2.8 ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14
2.9 ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 14 2.9 ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 14
2.10 ENRP_OWNERSHIP_CHANGE message . . . . . . . . . . . . . 15 2.10 ENRP_ERROR message . . . . . . . . . . . . . . . . . . . 15
2.11 ENRP_ERROR message . . . . . . . . . . . . . . . . . . . 17 3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . 17
3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . 18 3.1 Methods for Communicating amongst ENRP Servers . . . . . . 17
3.1 Methods for Communicating amongst ENRP Servers . . . . . . 18 3.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 18
3.2 ENRP Server Initialization . . . . . . . . . . . . . . . . 19 3.2.1 Generate a Server Identifier . . . . . . . . . . . . . 19
3.2.1 Generate a Server Identifier . . . . . . . . . . . . . 20 3.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . 19
3.2.2 Acquire Peer Server List . . . . . . . . . . . . . . . 20 3.2.3 Download ENRP Handlespace Data from Mentor Peer . . . 21
3.2.3 Download ENRP Handlespace Data from Mentor Peer . . . 22 3.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 23
3.3 Handle PE Registration . . . . . . . . . . . . . . . . . . 24 3.3.1 Rules on PE Re-registration . . . . . . . . . . . . . 25
3.3.1 Rules on PE Re-registration . . . . . . . . . . . . . 26 3.4 Handle PE De-registration . . . . . . . . . . . . . . . . 25
3.4 Handle PE De-registration . . . . . . . . . . . . . . . . 26 3.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 26
3.5 Pool Handle Translation . . . . . . . . . . . . . . . . . 27 3.6 Server Handlespace Update . . . . . . . . . . . . . . . . 27
3.6 Server Handlespace Update . . . . . . . . . . . . . . . . 28 3.6.1 Announcing Addition or Update of PE . . . . . . . . . 27
3.6.1 Announcing Addition or Update of PE . . . . . . . . . 28 3.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . 28
3.6.2 Announcing Removal of PE . . . . . . . . . . . . . . . 29 3.7 Detecting and Removing Unreachable PE . . . . . . . . . . 28
3.7 Detecting and Removing Unreachable PE . . . . . . . . . . 29 3.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 29
3.8 Helping PE and PU to Discover Home ENRP Server . . . . . . 30 3.9 Maintaining Peer List and Monitoring Peer Status . . . . . 30
3.9 Maintaining Peer List and Monitoring Peer Status . . . . . 31 3.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . 30
3.9.1 Discovering New Peer . . . . . . . . . . . . . . . . . 31 3.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . 30
3.9.2 Server Sending Heartbeat . . . . . . . . . . . . . . . 31 3.9.3 Detecting Peer Server Failure . . . . . . . . . . . . 30
3.9.3 Detecting Peer Server Failure . . . . . . . . . . . . 31 3.10 Taking-over a Failed Peer Server . . . . . . . . . . . . 31
3.10 Taking-over a Failed Peer Server . . . . . . . . . . . . 32 3.10.1 Initiate Server Take-over Arbitration . . . . . . . 31
3.10.1 Initiate Server Take-over Arbitration . . . . . . . 32 3.10.2 Take-over Target Peer Server . . . . . . . . . . . . 32
3.10.2 Take-over Target Peer Server . . . . . . . . . . . . 33 3.11 Handlespace Data Auditing and Re-synchronization . . . . 33
3.11 Handlespace Data Auditing and Re-synchronization . . . . 34 3.11.1 Auditing Procedures . . . . . . . . . . . . . . . . 33
3.11.1 Auditing Procedures . . . . . . . . . . . . . . . . 34 3.11.2 PE Checksum Calculation Algorithm . . . . . . . . . 33
3.11.2 PE Checksum Calculation Algorithm . . . . . . . . . 34 3.11.3 Re-synchronization Procedures . . . . . . . . . . . 34
3.11.3 Re-synchronization Procedures . . . . . . . . . . . 35
3.12 Handling Unrecognized Message or Unrecognized 3.12 Handling Unrecognized Message or Unrecognized
Parameter . . . . . . . . . . . . . . . . . . . . . . . 36 Parameter . . . . . . . . . . . . . . . . . . . . . . . 35
4. Variables and Thresholds . . . . . . . . . . . . . . . . . . 37 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . 36
4.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 37 4.1 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 37 4.2 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36
5. Security Considerations . . . . . . . . . . . . . . . . . . 38 5. Security Considerations . . . . . . . . . . . . . . . . . . 37
5.1 Implementing Security Mechanisms . . . . . . . . . . . . . 39 5.1 Implementing Security Mechanisms . . . . . . . . . . . . . 38
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1 Normative References . . . . . . . . . . . . . . . . . . . 42 7.1 Normative References . . . . . . . . . . . . . . . . . . . 41
7.2 Informative References . . . . . . . . . . . . . . . . . . 43 7.2 Informative References . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . 45 Intellectual Property and Copyright Statements . . . . . . . 44
1. Introduction 1. Introduction
ENRP is designed to work in conjunction with ASAP [1] to accomplish ENRP is designed to work in conjunction with ASAP [1] to accomplish
the functionality of Rserpool as defined by its requirements [2] and the functionality of Rserpool as defined by its requirements [2] and
architecture [3]. architecture [3].
Within the operational scope of Rserpool, ENRP defines the procedures Within the operational scope of Rserpool, ENRP defines the procedures
and message formats of a distributed fault-tolerant registry service and message formats of a distributed fault-tolerant registry service
for storing, bookkeeping, retrieving, and distributing pool operation for storing, bookkeeping, retrieving, and distributing pool operation
skipping to change at page 6, line 34 skipping to change at page 6, line 34
0x00 - (reserved by IETF) 0x00 - (reserved by IETF)
0x01 - ENRP_PRESENCE 0x01 - ENRP_PRESENCE
0x02 - ENRP_HANDLE_TABLE_REQUEST 0x02 - ENRP_HANDLE_TABLE_REQUEST
0x03 - ENRP_HANDLE_TABLE_RESPONSE 0x03 - ENRP_HANDLE_TABLE_RESPONSE
0x04 - ENRP_HANDLE_UPDATE 0x04 - ENRP_HANDLE_UPDATE
0x05 - ENRP_LIST_REQUEST 0x05 - ENRP_LIST_REQUEST
0x06 - ENRP_LIST_RESPONSE 0x06 - ENRP_LIST_RESPONSE
0x07 - ENRP_INIT_TAKEOVER 0x07 - ENRP_INIT_TAKEOVER
0x08 - ENRP_INIT_TAKEOVER_ACK 0x08 - ENRP_INIT_TAKEOVER_ACK
0x09 - ENRP_TAKEOVER_SERVER 0x09 - ENRP_TAKEOVER_SERVER
0x0a - ENRP_OWNERSHIP_CHANGE 0x0a - ENRP_ERROR
0x0b - ENRP_ERROR 0x0b-0xff - (reserved by IETF)
0x0c-0xff - (reserved by IETF)
2.1 ENRP_PRESENCE message 2.1 ENRP_PRESENCE message
This ENRP message is used to announce (periodically) the presence of This ENRP message is used to announce (periodically) the presence of
an ENRP server, or to probe the status of a peer ENRP sever. an ENRP server, or to probe the status of a peer ENRP sever.
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 = 0x01 |0|0|0|0|0|0|0|R| Message Length | | Type = 0x01 |0|0|0|0|0|0|0|R| Message Length |
skipping to change at page 7, line 50 skipping to change at page 7, line 50
Section 3.11.1 for details. Section 3.11.1 for details.
Server Information Parameter: Server Information Parameter:
If present, contains the server information of the sender of If present, contains the server information of the sender of
this message (Server Information Parameter is defined in [11]). this message (Server Information Parameter is defined in [11]).
This parameter is optional. However, if this message is sent This parameter is optional. However, if this message is sent
in response to a received "reply required" ENRP_PRESENCE from a in response to a received "reply required" ENRP_PRESENCE from a
peer, the sender then MUST include its server information. peer, the sender then MUST include its server information.
Note, at startup an ENRP server MUST pick a randomly generated, Note, at startup an ENRP server MUST pick a randomly generated, non-
non-zero 32-bit unsigned integer as its ID and MUST use this same ID zero 32-bit unsigned integer as its ID and MUST use this same ID for
for its entire life. its entire life.
2.2 ENRP_HANDLE_TABLE_REQUEST message 2.2 ENRP_HANDLE_TABLE_REQUEST message
An ENRP server sends this message to one of its peers to request a An ENRP server sends this message to one of its peers to request a
copy of the handlespace data. This message is normally used during copy of the handlespace data. This message is normally used during
server initialization or handlespace re-synchronization. server initialization or handlespace re-synchronization.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 31 skipping to change at page 15, line 31
Receiver Server's ID: Receiver Server's ID:
See Section 2.1. See Section 2.1.
Target Server's ID: Target Server's ID:
Contains the 32-bit server ID of the peer ENRP that is the Contains the 32-bit server ID of the peer ENRP that is the
target of this takeover operation. target of this takeover operation.
2.10 ENRP_OWNERSHIP_CHANGE message 2.10 ENRP_ERROR message
This message is used by the ENRP server, normally after a successful
takeover, to declare that it is now the new home ENRP server of the
listed PEs in the listed pools.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Param #1 of pool #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Param #k of pool #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ... :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle #M :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Param #1 of pool #M :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Identifier Param #n of pool #M :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID:
See Section 2.1.
Receiver Server's ID:
See Section 2.1.
Pool handles and PE Identifier parameters:
Each listed pool handle is followed by a list of PE Identifier
parameters, indicating that the sender of this message is
taking ownership of the listed PEs in the pool.
2.11 ENRP_ERROR message
This message is used by an ENRP server to report an operational error This message is used by an ENRP server to report an operational error
to one of its peers. to one of its peers.
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 = 0x0b |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Server's ID | | Sender Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Server's ID | | Receiver Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Operational Error Parameter : : Operational Error Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sender Server's ID: Sender Server's ID:
See Section 2.1. See Section 2.1.
Receiver Server's ID: Receiver Server's ID:
See Section 2.1. See Section 2.1.
Operational Error Parameter: Operational Error Parameter:
skipping to change at page 18, line 11 skipping to change at page 17, line 11
This parameter, defined in [11], indicates the type of error(s) This parameter, defined in [11], indicates the type of error(s)
being reported. being reported.
3. ENRP Operation Procedures 3. ENRP Operation Procedures
In this section, we discuss the operation procedures defined by ENRP. In this section, we discuss the operation procedures defined by ENRP.
An ENRP server MUST following these procedures when sending, An ENRP server MUST following these procedures when sending,
receiving, or processing ENRP messages. receiving, or processing ENRP messages.
Many of the Rserpool events call for both server-to-server and Many of the Rserpool events call for both server-to-server and PU/
PU/PE-to-server message exchanges. Only the message exchanges and PE-to-server message exchanges. Only the message exchanges and
activities between an ENRP server and its peer(s) are considered activities between an ENRP server and its peer(s) are considered
within the ENRP scope and are defined in this document. within the ENRP scope and are defined in this document.
Procedures for exchanging messages between a PE/PU and ENRP servers Procedures for exchanging messages between a PE/PU and ENRP servers
are defined in [1]. are defined in [1].
3.1 Methods for Communicating amongst ENRP Servers 3.1 Methods for Communicating amongst ENRP Servers
Within an Rserpool operational scope, ENRP servers need to Within an Rserpool operational scope, ENRP servers need to
communicate with each other in order to exchange information such as communicate with each other in order to exchange information such as
skipping to change at page 19, line 21 skipping to change at page 18, line 21
decision should be based on factors such as the availability of decision should be based on factors such as the availability of
IP multicast and the security requirements from the user of IP multicast and the security requirements from the user of
Rserpool. Rserpool.
2. If an ENRP server disables multicast, it then: 2. If an ENRP server disables multicast, it then:
A. MUST NOT subscribe to the well-known server multicast A. MUST NOT subscribe to the well-known server multicast
channel, i.e., it only receives peer announcements over SCTP channel, i.e., it only receives peer announcements over SCTP
associations, and associations, and
B. MUST transmit all its out-going announcements over B. MUST transmit all its out-going announcements over point-to-
point-to-point SCTP associations with its peers. point SCTP associations with its peers.
3. If an ENRP server enables itself to use multicast, it then: 3. If an ENRP server enables itself to use multicast, it then:
A. MUST subscribe to the well-known server multicast channel to A. MUST subscribe to the well-known server multicast channel to
ready itself for receiving peers' multicast announcements, ready itself for receiving peers' multicast announcements,
B. MUST also be prepared to receive peer announcements over B. MUST also be prepared to receive peer announcements over
point-to-point SCTP associations from peers. point-to-point SCTP associations from peers.
C. MUST track internally which peers are multicast-enabled and C. MUST track internally which peers are multicast-enabled and
which are not. Note: A peer is always assumed to be which are not. Note: A peer is always assumed to be
multicast-disabled until/unless an ENRP message of any type multicast-disabled until/unless an ENRP message of any type
is received from that peer over the well-known server is received from that peer over the well-known server
multicast channel. multicast channel.
D. when sending out an announcement, MUST send a copy to the D. when sending out an announcement, MUST send a copy to the
well-known server multicast channel AND a copy to each of the well-known server multicast channel AND a copy to each of the
peers that are marked as multicast-disabled over a peers that are marked as multicast-disabled over a point-to-
point-to-point SCTP association. point SCTP association.
3.2 ENRP Server Initialization 3.2 ENRP Server Initialization
This section describes the steps a new ENRP server needs to take in This section describes the steps a new ENRP server needs to take in
order to join the other existing ENRP servers, or to initiate the order to join the other existing ENRP servers, or to initiate the
handlespace service if it is the first ENRP server started in the handlespace service if it is the first ENRP server started in the
operational scope. operational scope.
3.2.1 Generate a Server Identifier 3.2.1 Generate a Server Identifier
skipping to change at page 21, line 44 skipping to change at page 20, line 44
steps 1-5 above. steps 1-5 above.
3.2.2.2 Request complete server list from mentor peer 3.2.2.2 Request complete server list from mentor peer
Once the initiating server finds its mentor peer server (by either Once the initiating server finds its mentor peer server (by either
discovery or administrative means), the initiating server MUST send discovery or administrative means), the initiating server MUST send
an ENRP_LIST_REQUEST message to the mentor peer server to request a an ENRP_LIST_REQUEST message to the mentor peer server to request a
copy of the complete server list maintained by the mentor peer (see copy of the complete server list maintained by the mentor peer (see
Section 3.9 for maintaining server list). Section 3.9 for maintaining server list).
The initiating server SHOULD start a timer every time it finishes
sending an ENRP_LIST_REQUEST message. If the timer expires before
receiving a response from the mentor peer, the initiating server
SHOULD abort and send a new server list request to a backup mentor
peer, if one is available.
Upon the reception of this request, the mentor peer server SHOULD Upon the reception of this request, the mentor peer server SHOULD
reply with an ENRP_LIST_RESPONSE message and include in the message reply with an ENRP_LIST_RESPONSE message and include in the message
body all existing ENRP servers known by the mentor peer. body all existing ENRP servers known by the mentor peer.
Upon the reception of the ENRP_LIST_RESPONSE message from the mentor Upon the reception of the ENRP_LIST_RESPONSE message from the mentor
peer, the initiating server MUST use the server information carried peer, the initiating server MUST use the server information carried
in the message to initialize its own peer list. in the message to initialize its own peer list.
However, if the mentor itself is in the process of startup and not However, if the mentor itself is in the process of startup and not
ready to provide a peer server list (for example, the mentor peer is ready to provide a peer server list (for example, the mentor peer is
skipping to change at page 25, line 40 skipping to change at page 24, line 45
In all above cases, the ENRP server MUST reply to the requesting PE In all above cases, the ENRP server MUST reply to the requesting PE
with an ASAP_REGISTRATION_RESPONSE message. If the registration is with an ASAP_REGISTRATION_RESPONSE message. If the registration is
accepted, the ENRP server MUST set the 'R' flag in the accepted, the ENRP server MUST set the 'R' flag in the
ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected, ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected,
the ENRP server MUST indicate the rejection by setting the 'R' flag the ENRP server MUST indicate the rejection by setting the 'R' flag
in the ASAP_REGISTRATION_RESPONSE to '1'. in the ASAP_REGISTRATION_RESPONSE to '1'.
If the registration is rejected, the ENRP server SHOULD include the If the registration is rejected, the ENRP server SHOULD include the
proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message. proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message.
If the registration is granted (either a new registration or a If the registration is granted (either a new registration or a re-
re-registration case), the ENRP server MUST assign itself to be the registration case), the ENRP server MUST assign itself to be the home
home ENRP server of the PE, i.e., to "own" the PE. ENRP server of the PE, i.e., to "own" the PE.
Implementation note: for better performance, the ENRP server may Implementation note: for better performance, the ENRP server may
find it both efficient and convenient to internally maintain two find it both efficient and convenient to internally maintain two
separate PE lists or tables - one is for the PEs that are "owned" separate PE lists or tables - one is for the PEs that are "owned"
by the ENRP server and the other for all the PEs owned by its by the ENRP server and the other for all the PEs owned by its
peer(s). peer(s).
Moreover, if the registration is granted, the ENRP server MUST take Moreover, if the registration is granted, the ENRP server MUST take
the handlespace update action as described in Section 3.6 to inform the handlespace update action as described in Section 3.6 to inform
its peers about the change just made. If the registration is denied, its peers about the change just made. If the registration is denied,
no message will be sent to its peers. no message will be sent to its peers.
3.3.1 Rules on PE Re-registration 3.3.1 Rules on PE Re-registration
A PE may re-register itself to the handlespace with a new set of A PE may re-register itself to the handlespace with a new set of
attributes in order to, for example, extend its registration life, attributes in order to, for example, extend its registration life,
change its load factor value, etc. change its load factor value, etc.
A PE may modify its load factor value at any time via A PE may modify its load factor value at any time via re-
re-registration. Based on the number of PEs in the pool and the registration. Based on the number of PEs in the pool and the pool's
pool's overall policy type, this operation allows the PE to overall policy type, this operation allows the PE to dynamically
dynamically control its share of inbound messages received by the control its share of inbound messages received by the pool (also see
pool (also see Section ???? in [1] for more on load control). Section ???? in [1] for more on load control).
Moreover, when re-registering, the PE MUST NOT change its policy Moreover, when re-registering, the PE MUST NOT change its policy
type. The server MUST reject the re-registration if the PE attempt type. The server MUST reject the re-registration if the PE attempt
to change its policy type. In the rejection, the server SHOULD to change its policy type. In the rejection, the server SHOULD
attach an error code "Pooling Policy Inconsistent". attach an error code "Pooling Policy Inconsistent".
Regardless whether it is the current owner of the PE, if the Regardless whether it is the current owner of the PE, if the re-
re-registration is granted to the PE, the ENRP server MUST assign registration is granted to the PE, the ENRP server MUST assign itself
itself to be the new home ENRP server of the PE. to be the new home ENRP server of the PE.
Moreover, if the re-registration is granted, the ENRP server MUST Moreover, if the re-registration is granted, the ENRP server MUST
take the handlespace update action as described in Section 3.6 to take the handlespace update action as described in Section 3.6 to
inform its peers about the change just made. If the re-registration inform its peers about the change just made. If the re-registration
is denied, no message will be sent to its peers. is denied, no message will be sent to its peers.
3.4 Handle PE De-registration 3.4 Handle PE De-registration
To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION
message to its home ENRP server. The complete format of message to its home ENRP server. The complete format of
skipping to change at page 26, line 51 skipping to change at page 26, line 7
pool it belongs to in a pool handle parameter and provides its PE pool it belongs to in a pool handle parameter and provides its PE
identifier. identifier.
Upon receiving the message, the ENRP server SHALL remove the PE from Upon receiving the message, the ENRP server SHALL remove the PE from
its handlespace. Moreover, if the PE is the last one of the named its handlespace. Moreover, if the PE is the last one of the named
pool, the ENRP server will remove the pool from the handlespace as pool, the ENRP server will remove the pool from the handlespace as
well. well.
If the ENRP server fails to find any record of the PE in its If the ENRP server fails to find any record of the PE in its
handlespace, it SHOULD consider the de-registration granted and handlespace, it SHOULD consider the de-registration granted and
completed. completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the
PE.
The ENRP server may reject the de-registration request for various The ENRP server may reject the de-registration request for various
reasons, such as invalid parameters, authentication failure, etc. reasons, such as invalid parameters, authentication failure, etc.
In response, the ENRP server MUST send an In response, the ENRP server MUST send an
ASAP_DEREGISTRATION_RESPONSE message to the PE. If the ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de-
de-registration is rejected, the ENRP server MUST indicate the registration is rejected, the ENRP server MUST indicate the rejection
rejection by including the proper Operational Error parameter. by including the proper Operational Error parameter.
It should be noted that de-registration does not stop the PE from It should be noted that de-registration does not stop the PE from
sending or receiving application messages. sending or receiving application messages.
Once the de-registration request is granted AND the PE removed from Once the de-registration request is granted AND the PE removed from
its local copy of the handlespace, the ENRP server MUST take the its local copy of the handlespace, the ENRP server MUST take the
handlespace update action described in Section 3.6 to inform its handlespace update action described in Section 3.6 to inform its
peers about the change just made. Otherwise, NO message SHALL be peers about the change just made. Otherwise, NO message SHALL be
send to its peers. send to its peers.
skipping to change at page 30, line 5 skipping to change at page 29, line 10
3.7 Detecting and Removing Unreachable PE 3.7 Detecting and Removing Unreachable PE
Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE
Notification, see section 10.2 of [8]), the PU SHOULD send an Notification, see section 10.2 of [8]), the PU SHOULD send an
ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The
message SHOULD contain the pool handle and the PE Id of the message SHOULD contain the pool handle and the PE Id of the
unreachable PE. unreachable PE.
Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server
MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE
message to the PE in question. If this ASAP_ENDPOINT_KEEP_ALIVE message to the PE in question (the 'H' flag in the message SHOULD be
fails (e.g., it results in an SCTP SEND.FAILURE notification), the set to '0' in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails
ENRP server MUST consider the PE as truly unreachable and MUST remove (e.g., it results in an SCTP SEND.FAILURE notification), the ENRP
the PE from its handlespace and take actions described in server MUST consider the PE as truly unreachable and MUST remove the
Section 3.6.2. PE from its handlespace and take actions described in Section 3.6.2.
If the ASAP_ENDPOINT_UNREACHABLE message is transmitted successfully If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully
to the PE, the ENRP server MUST retain the PE in its handlespace. to the PE, the ENRP server MUST retain the PE in its handlespace.
Moreover, the server SHOULD keep a counter to record how many Moreover, the server SHOULD keep a counter to record how many
ASAP_ENDPOINT_UNREACHABLE messages it has received reporting ASAP_ENDPOINT_UNREACHABLE messages it has received reporting
reachability problem relating to this PE. If the counter exceeds the reachability problem relating to this PE. If the counter exceeds the
protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove
the PE from its handlespace and take actions described in the PE from its handlespace and take actions described in
Section 3.6.2. Section 3.6.2.
Optionally, an ENRP server may also periodically send point-to-point Optionally, an ENRP server may also periodically send point-to-point
ASAP_ENDPOINT_KEEP_ALIVE messages to each of the PEs owned by the ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each
ENRP server in order to check their reachability status. If the send of the PEs owned by the ENRP server in order to check their
of ASAP_ENDPOINT_KEEP_ALIVE to a PE fails, the ENRP server MUST reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE
consider the PE as unreachable and MUST remove the PE from its fails, the ENRP server MUST consider the PE as unreachable and MUST
handlespace and take actions described in Section 3.6.2. Note, if an remove the PE from its handlespace and take actions described in
ENRP server owns a large number of PEs, the implementation should pay Section 3.6.2. Note, if an ENRP server owns a large number of PEs,
attention not to flood the network with bursts of the implementation should pay attention not to flood the network with
ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the implementation bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the
should try to smooth out the ASAP_ENDPOINT_KEEP_ALIVE message traffic implementation should try to smooth out the ASAP_ENDPOINT_KEEP_ALIVE
over time. message traffic over time.
The complete definition and rules of sending The complete definition and rules of sending
ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE
messages are described in [1]. messages are described in [1].
3.8 Helping PE and PU to Discover Home ENRP Server 3.8 Helping PE and PU to Discover Home ENRP Server
At its startup time, or whenever its current home ENRP server is not At its startup time, or whenever its current home ENRP server is not
providing services, a PE or PU will attempt to find a new home providing services, a PE or PU will attempt to find a new home
server. For this reason, the PE or PU will need to maintain a list server. For this reason, the PE or PU will need to maintain a list
skipping to change at page 31, line 19 skipping to change at page 30, line 23
An ENRP server MUST keep an internal record on the status of each of An ENRP server MUST keep an internal record on the status of each of
its known peers. This record is referred to as the server's "peer its known peers. This record is referred to as the server's "peer
list" list"
3.9.1 Discovering New Peer 3.9.1 Discovering New Peer
If a message of any type is received from a previously unknown peer, If a message of any type is received from a previously unknown peer,
the ENRP server MUST consider this peer a new peer in the operational the ENRP server MUST consider this peer a new peer in the operational
scope and add it to the peer list. scope and add it to the peer list.
The ENRP server MUST send an ENRP_PRESENCE message with the The ENRP server MUST send an ENRP_PRESENCE message with the Reply-
Reply-required flag set to '1' to the source address found in the required flag set to '1' to the source address found in the arrived
arrived message. This will force the new peer to reply with its own message. This will force the new peer to reply with its own
ENRP_PRESENCE containing its full server information (see ENRP_PRESENCE containing its full server information (see
Section 2.1). Section 2.1).
[editor's note: should we ask for a peer list from the new peer? [editor's note: should we ask for a peer list from the new peer? this
this may help mending two split networks.] may help mending two split networks.]
3.9.2 Server Sending Heartbeat 3.9.2 Server Sending Heartbeat
Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its Every PEER-HEARTBEAT-CYCLE seconds, an ENRP server MUST announce its
continued presence to all its peer with a ENRP_PRESENCE message. In continued presence to all its peer with a ENRP_PRESENCE message. In
the ENRP_PRESENCE message, the ENRP server MUST set the the ENRP_PRESENCE message, the ENRP server MUST set the
'Replay_required' flag to '0', indicating that no response is 'Replay_required' flag to '0', indicating that no response is
required. required.
The arrival of this periodic ENRP_PRESENCE message will cause all its The arrival of this periodic ENRP_PRESENCE message will cause all its
skipping to change at page 31, line 52 skipping to change at page 31, line 9
An ENRP server MUST keep an internal variable "peer.last.heard" for An ENRP server MUST keep an internal variable "peer.last.heard" for
each of its known peers and the value of this variable MUST be each of its known peers and the value of this variable MUST be
updated to the current local time every time a message of any type updated to the current local time every time a message of any type
(point-to-point or announcement) is received from the corresponding (point-to-point or announcement) is received from the corresponding
peer. peer.
If a peer has not been heard for more than MAX-TIME-LAST-HEARD If a peer has not been heard for more than MAX-TIME-LAST-HEARD
seconds, the ENRP server MUST immediately send a point-to-point seconds, the ENRP server MUST immediately send a point-to-point
ENRP_PRESENCE with 'Reply_request' flag set to '1' to that peer. ENRP_PRESENCE with 'Reply_request' flag set to '1' to that peer.
If the send fails or the peer does not reply after If the send fails or the peer does not reply after MAX-TIME-NO-
MAX-TIME-NO-RESPONSE seconds, the ENRP server MUST consider the peer RESPONSE seconds, the ENRP server MUST consider the peer server dead
server dead and SHOULD initiate the takeover procedure defined in and SHOULD initiate the takeover procedure defined in Section 3.10.
Section 3.10.
3.10 Taking-over a Failed Peer Server 3.10 Taking-over a Failed Peer Server
In the following descriptions, We call the ENRP server that detects In the following descriptions, We call the ENRP server that detects
the failed peer server and initiates the take-over the "initiating the failed peer server and initiates the take-over the "initiating
server" and the failed peer server the "target server." server" and the failed peer server the "target server."
3.10.1 Initiate Server Take-over Arbitration 3.10.1 Initiate Server Take-over Arbitration
The initiating server SHOULD first start a take-over arbitration The initiating server SHOULD first start a take-over arbitration
skipping to change at page 33, line 37 skipping to change at page 32, line 40
message. The initiating server SHOULD then remove the target server message. The initiating server SHOULD then remove the target server
from its internal peer list. from its internal peer list.
Then it SHOULD examine its local copy of the handlespace and claim Then it SHOULD examine its local copy of the handlespace and claim
ownership of each of the PEs originally owned by the target server, ownership of each of the PEs originally owned by the target server,
by following these steps: by following these steps:
1. mark itself as the home ENRP server of each of the PEs originally 1. mark itself as the home ENRP server of each of the PEs originally
owned by the target server; owned by the target server;
2. send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message to each of 2. send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message, with the
the PEs. This will trigger the PE to adopt the initiating sever 'H' flag set to '1', to each of the PEs. This will trigger the
as its new home ENRP server; PE to adopt the initiating sever as its new home ENRP server;
When a peer receives the ENRP_TAKEOVER_SERVER message from the When a peer receives the ENRP_TAKEOVER_SERVER message from the
initiating server, it SHOULD update its local peer list and PE cache initiating server, it SHOULD update its local peer list and PE cache
by following these steps: by following these steps:
1. remove the target server from its internal peer list; 1. remove the target server from its internal peer list;
2. update the home ENRP server of each PE in its local copy of the 2. update the home ENRP server of each PE in its local copy of the
handlespace to be the sender of the message, i.e., the initiating handlespace to be the sender of the message, i.e., the initiating
server. server.
skipping to change at page 35, line 21 skipping to change at page 34, line 21
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool handle string of the pool the PE belongs (padded with : : Pool handle string of the pool the PE belongs (padded with :
: zeros to next 32-bit word boundary if needed) : : zeros to next 32-bit word boundary if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE Id (4 octets) | | PE Id (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note, these are not TLVs. This byte block gives each PE a unique Note, these are not TLVs. This byte block gives each PE a unique
byte pattern in the scope. The 32-bit PE checksum for server B byte pattern in the scope. The 16-bit PE checksum for server B
"pe.checksum.prB" is then calculated over the byte blocks contributed "pe.checksum.prB" is then calculated over the byte blocks contributed
by the 'M' PEs one by one. The PE checksum calculation MUST use the by the 'M' PEs one by one. The PE checksum calculation MUST use the
Adler-32 algorithm described in section 8.2 of RFC1950 [4]. Internet algorithm described in [4].
Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0") Server A MUST calculate its own PE checksum (i.e., "pe.checksum.pr0")
in the same fashion, using the byte blocks of all the PEs owned by in the same fashion, using the byte blocks of all the PEs owned by
itself. itself.
Note, whenever an ENRP finds that its internal handlespace has Note, whenever an ENRP finds that its internal handlespace has
changed (e.g., due to PE registration/deregistration, receiving peer changed (e.g., due to PE registration/deregistration, receiving peer
updates, removing failed PEs, downloading handlespace pieces from a updates, removing failed PEs, downloading handlespace pieces from a
peer, etc.), it MUST immediately update all its internal PE checksums peer, etc.), it MUST immediately update all its internal PE checksums
that are affected by the change. that are affected by the change.
skipping to change at page 41, line 7 skipping to change at page 40, line 7
Implementations MUST support TLS with SCTP as described in RFC3436 Implementations MUST support TLS with SCTP as described in RFC3436
[9] or TLS over TCP as described in RFC2246 [7]. When using TLS/SCTP [9] or TLS over TCP as described in RFC2246 [7]. When using TLS/SCTP
we must ensure that RSerPool does not use any features of SCTP that 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 are not available to an TLS/SCTP user. This is not a difficult
technical problem, but simply a requirement. When describing an API technical problem, but simply a requirement. When describing an API
of the RSerPool lower layer we have also to take into account the of the RSerPool lower layer we have also to take into account the
differences between TLS and SCTP. differences between TLS and SCTP.
6. Acknowledgements 6. Acknowledgements
The authors wish to thank John Loughney, Lyndon Ong, and many others The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson,
for their invaluable comments. Thomas Dreibholz, and many others for their invaluable comments and
feedback.
7. References 7. References
7.1 Normative References 7.1 Normative References
[1] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [1] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate
Server Access Protocol (ASAP)", Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-12
Internet-Draft draft-ietf-rserpool-asap-11, February 2005. (work in progress), July 2005.
[2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, [2] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney,
J. and M. Stillman, "Requirements for Reliable Server Pooling", J., and M. Stillman, "Requirements for Reliable Server
RFC 3237, January 2002. Pooling", RFC 3237, January 2002.
[3] Tuexen, M., Xie, Q., Stewart, R., Shore, M. and J. Loughney, [3] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Loughney, J., and
"Architecture for Reliable Server Pooling", A. Silverton, "Architecture for Reliable Server Pooling",
Internet-Draft draft-ietf-rserpool-arch-09, February 2005. draft-ietf-rserpool-arch-10 (work in progress), July 2005.
[4] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format [4] Braden, R., Borman, D., and C. Partridge, "Computing the
Specification version 3.3", RFC 1950, May 1996. Internet Checksum", RFC 1071, September 1988.
[5] Bradner, S., "The Internet Standards Process -- Revision 3", [5] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [8] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
"Stream Control Transmission Protocol", RFC 2960, October 2000. Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[9] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", [9] Jungmaier, A., Rescorla, E., and M. Tuexen, "TLS over SCTP",
RFC 3436, December 2002. RFC 3436, December 2002.
[10] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, "On [10] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On
the Use of Stream Control Transmission Protocol (SCTP) with the Use of Stream Control Transmission Protocol (SCTP) with
IPsec", RFC 3554, July 2003. IPsec", RFC 3554, July 2003.
[11] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [11] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate
Server Access Protocol (ASAP) and Endpoint Handlespace Server Access Protocol (ASAP) and Endpoint Handlespace
Redundancy Protocol (ENRP) Parameters", Redundancy Protocol (ENRP) Parameters",
Internet-Draft draft-ietf-rserpool-common-param-08, Feburary draft-ietf-rserpool-common-param-09 (work in progress),
2005. July 2005.
[12] Stillman, M., "Threats Introduced by Rserpool and Requirements [12] Stillman, M., Gopal, R., Sengodan, S., Guttman, E., and M.
for Security in Response to Threats", Holdrege, "Threats Introduced by Rserpool and Requirements for
Internet-Draft draft-ietf-rserpool-threats-04, January 2005. Security in Response to Threats",
draft-ietf-rserpool-threats-05 (work in progress), July 2005.
7.2 Informative References 7.2 Informative References
[13] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [13] 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
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, 2-F9 1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004 Arlington Heights, IL 60004
US US
skipping to change at page 43, line 39 skipping to change at page 43, line 4
Email: rrs@cisco.com Email: rrs@cisco.com
Maureen Stillman Maureen Stillman
Nokia Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
US US
Phone: Phone:
Email: maureen.stillman@nokia.com Email: maureen.stillman@nokia.com
Michael Tuexen Michael Tuexen
Muenster Univ. of Applied Sciences
Stegerwaldstr. 39
48565 Steinfurt
Germany Germany
Phone:
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Aron J. Silverton Aron J. Silverton
Motorola, Inc. Motorola, Inc.
1301 E. Algonquin Road 1301 E. Algonquin Road
Room 2246 Room 2246
Schaumburg, IL 60196 Schaumburg, IL 60196
USA USA
Phone: +1 847-576-8747 Phone: +1 847-576-8747
Email: aron.j.silverton@motorola.com Email: aron.j.silverton@motorola.com
 End of changes. 

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