draft-ietf-rserpool-enrp-17.txt   draft-ietf-rserpool-enrp-18.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft Motorola
Intended status: Experimental R. Stewart Intended status: Experimental R. Stewart
Expires: March 25, 2008 Cisco Systems, Inc. Expires: May 22, 2008 Cisco Systems, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
A. Silverton A. Silverton
Motorola, Inc. Motorola, Inc.
September 22, 2007 November 19, 2007
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
draft-ietf-rserpool-enrp-17.txt draft-ietf-rserpool-enrp-18.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 March 25, 2008. This Internet-Draft will expire on May 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to
work in conjunction with the Aggregate Server Access Protocol (ASAP) work in conjunction with the Aggregate Server Access Protocol (ASAP)
to accomplish the functionality of the Reliable Server Pooling to accomplish the functionality of the Reliable Server Pooling
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . 12 2.5. ENRP_LIST_REQUEST message . . . . . . . . . . . . . . . . 12
2.6. ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13 2.6. ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13
2.7. ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14 2.7. ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14
2.8. ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14 2.8. ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14
2.9. ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15 2.9. ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15
2.10. ENRP_ERROR message . . . . . . . . . . . . . . . . . . . . 16 2.10. ENRP_ERROR message . . . . . . . . . . . . . . . . . . . . 16
3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . . 17 3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . . 17
3.1. Methods for Communicating amongst ENRP Servers . . . . . . 17 3.1. Methods for Communicating amongst ENRP Servers . . . . . . 17
3.2. ENRP Server Initialization . . . . . . . . . . . . . . . . 18 3.2. ENRP Server Initialization . . . . . . . . . . . . . . . . 17
3.2.1. Generate a Server Identifier . . . . . . . . . . . . . 18 3.2.1. Generate a Server Identifier . . . . . . . . . . . . . 17
3.2.2. Acquire Peer Server List . . . . . . . . . . . . . . . 19 3.2.2. Acquire Peer Server List . . . . . . . . . . . . . . . 18
3.2.3. Download ENRP Handlespace Data from Mentor Peer . . . 21 3.2.3. Download ENRP Handlespace Data from Mentor Peer . . . 19
3.3. Handle PE Registration . . . . . . . . . . . . . . . . . . 23 3.3. Server Handlespace Update . . . . . . . . . . . . . . . . 21
3.3.1. Rules on PE Re-registration . . . . . . . . . . . . . 24 3.3.1. Announcing Addition or Update of PE . . . . . . . . . 21
3.4. Handle PE De-registration . . . . . . . . . . . . . . . . 25 3.3.2. Announcing Removal of PE . . . . . . . . . . . . . . . 22
3.5. Pool Handle Translation . . . . . . . . . . . . . . . . . 26 3.4. Maintaining Peer List and Monitoring Peer Status . . . . . 23
3.6. Server Handlespace Update . . . . . . . . . . . . . . . . 27 3.4.1. Discovering New Peer . . . . . . . . . . . . . . . . . 23
3.6.1. Announcing Addition or Update of PE . . . . . . . . . 27 3.4.2. Server Sending Heartbeat . . . . . . . . . . . . . . . 23
3.6.2. Announcing Removal of PE . . . . . . . . . . . . . . . 28 3.4.3. Detecting Peer Server Failure . . . . . . . . . . . . 23
3.7. Detecting and Removing Unreachable PE . . . . . . . . . . 28 3.5. Taking-over a Failed Peer Server . . . . . . . . . . . . . 24
3.8. Helping PE and PU to Discover Home ENRP Server . . . . . . 29 3.5.1. Initiating Server Take-over Arbitration . . . . . . . 24
3.9. Maintaining Peer List and Monitoring Peer Status . . . . . 29 3.5.2. Take-over Target Peer Server . . . . . . . . . . . . . 25
3.9.1. Discovering New Peer . . . . . . . . . . . . . . . . . 30 3.6. Handlespace Data Auditing and Re-synchronization . . . . . 26
3.9.2. Server Sending Heartbeat . . . . . . . . . . . . . . . 30 3.6.1. Auditing Procedures . . . . . . . . . . . . . . . . . 26
3.9.3. Detecting Peer Server Failure . . . . . . . . . . . . 30 3.6.2. PE Checksum Calculation Algorithm . . . . . . . . . . 27
3.10. Taking-over a Failed Peer Server . . . . . . . . . . . . . 30 3.6.3. Re-synchronization Procedures . . . . . . . . . . . . 28
3.10.1. Initiating Server Take-over Arbitration . . . . . . . 31 3.7. Handling Unrecognized Message or Unrecognized Parameter . 28
3.10.2. Take-over Target Peer Server . . . . . . . . . . . . . 32 4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 29
3.11. Handlespace Data Auditing and Re-synchronization . . . . . 32 4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 29
3.11.1. Auditing Procedures . . . . . . . . . . . . . . . . . 33 4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 29
3.11.2. PE Checksum Calculation Algorithm . . . . . . . . . . 33 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
3.11.3. Re-synchronization Procedures . . . . . . . . . . . . 34 5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 30
3.12. Handling Unrecognized Message or Unrecognized Parameter . 35 5.2. A New Table for Update Action Types . . . . . . . . . . . 30
4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 36 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 36 6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 32
4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36 6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 33
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 34
5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 37 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
5.2. A New Table for Update Action Types . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3. Multicast Addresses . . . . . . . . . . . . . . . . . . . 38 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37
6. Security Considerations . . . . . . . . . . . . . . . . . . . 39 8.2. Informative References . . . . . . . . . . . . . . . . . . 38
6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . . . . 41
6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 41
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.1. Normative References . . . . . . . . . . . . . . . . . . . 44
8.2. Informative References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 47
1. Introduction 1. Introduction
ENRP is designed to work in conjunction with ASAP [9] to accomplish ENRP is designed to work in conjunction with ASAP [9] to accomplish
the functionality of RSerPool as defined by its requirements [5]. the functionality of RSerPool as defined by its requirements [5].
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
and membership information. and membership information.
skipping to change at page 4, line 47 skipping to change at page 4, line 47
Pool element handle (or endpoint handle): A logical pointer to a Pool element handle (or endpoint handle): A logical pointer to a
particular pool element in a pool, consisting of the pool handle particular pool element in a pool, consisting of the pool handle
and a destination transport address of the pool element. and a destination transport address of the pool element.
Handle space: A cohesive structure of pool handles and relations Handle space: A cohesive structure of pool handles and relations
that may be queried by an internal or external agent. that may be queried by an internal or external agent.
ENRP client channel: The communication channel through which an ASAP ENRP client channel: The communication channel through which an ASAP
User (either a PE or PU) requests ENRP handlespace service. The User (either a PE or PU) requests ENRP handlespace service. The
client channel is usually defined by the transport address of the client channel is usually defined by the transport address of the
home server and a well-known port number. The channel MAY make home server and a well-known port number.
use of multi-cast or a named list of ENRP servers.
ENRP server channel: Defined by a well-known multicast IP address ENRP server channel: Defined by a list of IP addresses (one for each
and a well known port number. All ENRP servers in an operational ENRP servers in an operational scope) and a well known port
scope can send multicast messages to other servers through this number. All ENRP servers in an operational scope can send "group-
channel. PEs are also allowed to multicast on this channel cast" messages to other servers through this channel. In a
occasionally; "group-cast", the sending server sends multiple copies of the
message, one to each of its peer servers, over a set of point-to-
point SCTP associations between the sending server and the peers.
The "group-cast" may be conveniently implemented with the use of
the "SCTP_SENDALL" option on an one-to-many style SCTP socket
[11].
Home ENRP server: The ENRP server to which a PE or PU currently Home ENRP server: The ENRP server to which a PE or PU currently
belongs. A PE MUST only have one home ENRP server at any given belongs. A PE MUST only have one home ENRP server at any given
time and both the PE and its home ENRP server MUST keep track of time and both the PE and its home ENRP server MUST keep track of
this master/slave relationship between them. A PU SHOULD select this master/slave relationship between them. A PU SHOULD select
one of the available ENRP servers as its home ENRP server, but the one of the available ENRP servers as its home ENRP server, but the
ENRP server does not need to know, nor does it need to keep track ENRP server does not need to know, nor does it need to keep track
of this relationship. of this relationship.
1.2. Conventions 1.2. Conventions
skipping to change at page 6, line 15 skipping to change at page 6, line 15
2. ENRP Message Definitions 2. ENRP Message Definitions
In this section, we define the format of all ENRP messages. These In this section, we define the format of all ENRP messages. These
are messages sent and received amongst ENRP servers in an operational are messages sent and received amongst ENRP servers in an operational
scope. Messages sent and received between a PE/PU and an ENRP server scope. Messages sent and received between a PE/PU and an ENRP server
are part of ASAP and are defined in [9]. A common format, that is are part of ASAP and are defined in [9]. A common format, that is
defined in [8], is used for all ENRP and ASAP messages. defined in [8], is used for all ENRP and ASAP messages.
Most ENRP messages contains a combination of fixed fields and TLV Most ENRP messages contains a combination of fixed fields and TLV
parameters. The TLV (Type-Length_value) parameters are also defined parameters. The TLV (Type-Length_value) parameters are also defined
in [8]. in [8]. If a nested TLV parameter is not ended on a 32-bit word
boundary, it will be padded with all '0' octets to the next 32-bit
word boundary.
All messages, as well as their fields/parameters described below, All messages, as well as their fields/parameters described below,
MUST be transmitted in network byte order (a.k.a. Big Endian, MUST be transmitted in network byte order (a.k.a. Big Endian,
meaning the most significant byte is transmitted first). meaning the most significant byte is transmitted first).
For ENRP, the following message types are defined in this section: For ENRP, the following message types are defined in this section:
Type Message Name Type Message Name
----- ------------------------- ----- -------------------------
0x00 - (reserved by IETF) 0x00 - (reserved by IETF)
skipping to change at page 6, line 40 skipping to change at page 6, line 42
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_ERROR 0x0a - ENRP_ERROR
0x0b-0xff - (reserved by IETF) 0x0b-0xff - (reserved by IETF)
Figure 1 Figure 1
Except for the ENRP_PRESENCE message, the usage of the ENRP server
channel is for further study. The usage of point-to-point
communications is assumed in this specification.
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 server. This an ENRP server, or to probe the status of a peer ENRP server. This
message is either send on the ENRP server channel or point-to-point message is either send on the ENRP server channel or point-to-point
to another ENRP server. to another ENRP server.
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 7, line 33 skipping to change at page 7, line 33
field MUST be set to '0'. field MUST be set to '0'.
Sending Server's ID: 32 bit (unsigned integer) Sending Server's ID: 32 bit (unsigned integer)
This is the ID of the ENRP server which sent this message. This is the ID of the ENRP server which sent this message.
Receiving Server's ID: 32 bit (unsigned integer) Receiving Server's ID: 32 bit (unsigned integer)
This is the ID of the ENRP server to which this message is This is the ID of the ENRP server to which this message is
intended. If the message is not intended for an individual intended. If the message is not intended for an individual
server (e.g., the message is multicasted to a group of server (e.g., the message is group-casted to a group of
servers), this field MUST be sent with all 0's. If the message servers), this field MUST be sent with all 0's. If the message
is send point-to-point this field MAY be sent with all 0's. is send point-to-point this field MAY be sent with all 0's.
PE Checksum Parameter: PE Checksum Parameter:
This is a TLV that contains the latest PE checksum of the ENRP This is a TLV that contains the latest PE checksum of the ENRP
server who sends the ENRP_PRESENCE. This parameter SHOULD be server who sends the ENRP_PRESENCE. This parameter SHOULD be
included for handlespace consistency auditing. See included for handlespace consistency auditing. See
Section 3.11.1 for details. Section 3.6.1 for details.
Server Information Parameter: Server Information Parameter:
If this parameter is present, it contains the server If this parameter is present, it contains the server
information of the sender of this message (Server Information information of the sender of this message (Server Information
Parameter is defined in [8]). This parameter is optional. Parameter is defined in [8]). This parameter is optional.
However, if this message is sent in response to a received However, if this message is sent in response to a received
"reply required" ENRP_PRESENCE from a peer, the sender then "reply required" ENRP_PRESENCE from a peer, the sender then
MUST include its server information. MUST include its server information.
skipping to change at page 10, line 17 skipping to change at page 10, line 17
See Section 2.1. See Section 2.1.
Receiving Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Pool entry #1-#n: Pool entry #1-#n:
If the R flag is set to '0', at least one pool entry SHOULD be If the R flag is set to '0', at least one pool entry SHOULD be
present in this message. Each pool entry MUST start with a present in this message. Each pool entry MUST start with a
Pool Handle parameter as defined in section 3.1.7, and is Pool Handle parameter as defined in section 3.9 of [8], and is
followed by one or more Pool Element parameters in TLV format, followed by one or more Pool Element parameters in TLV format,
as shown below: as shown below:
+---------------------------+ +---------------------------+
: Pool handle : : Pool handle :
+---------------------------+ +---------------------------+
: PE #1 : : PE #1 :
+---------------------------+ +---------------------------+
: PE #2 : : PE #2 :
+---------------------------+ +---------------------------+
: ... : : ... :
+---------------------------+ +---------------------------+
: PE #n : : PE #n :
+---------------------------+ +---------------------------+
2.4. ENRP_HANDLE_UPDATE message 2.4. ENRP_HANDLE_UPDATE message
The PEER_NAME_UPDATE message is sent by the home ENRP server of a PE The PEER_NAME_UPDATE message is sent by the home ENRP server of a PE
to all peer servers to announce registration, reregistration, or to all peer servers to announce registration, re-registration, or de-
deregistration of the PE in the handle-space. registration of the PE in the handle-space.
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 = 0x04 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x04 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 45 skipping to change at page 14, line 45
See Section 2.1. See Section 2.1.
Targeting Server's ID: 32-bit (unsigned integer) Targeting Server's ID: 32-bit (unsigned integer)
This is the ID of the peer ENRP that is the target of this This is the ID of the peer ENRP that is the target of this
takeover attempt. takeover attempt.
2.8. ENRP_INIT_TAKEOVER_ACK message 2.8. ENRP_INIT_TAKEOVER_ACK message
The PEER_INIT_TAKEOVER_ACK message is sent in response to a takeover The PEER_INIT_TAKEOVER_ACK message is sent in response to a takeover
initiator to acknowledge the reception of the PEER_INIT_TAKEROVER initiator to acknowledge the reception of the PEER_INIT_TAKEOVER
message and that it does not object to the takeover. message and that it does not object to the takeover.
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 = 0x08 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x08 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID | | Receiving Server's ID |
skipping to change at page 17, line 35 skipping to change at page 17, line 35
Two types of communications are used amongst ENRP servers: Two types of communications are used amongst ENRP servers:
o point-to-point message exchange from one ENPR server to a specific o point-to-point message exchange from one ENPR server to a specific
peer server, and peer server, and
o announcements from one server to all its peer servers in the o announcements from one server to all its peer servers in the
operational scope. operational scope.
Point-to-point communication is always carried out over an SCTP Point-to-point communication is always carried out over an SCTP
association between the sending server and the receiving server. association between the sending server and the receiving server.
Announcements are sent out via "group-casts" over the ENRP server
Announcements are communicated out with one of the following two channel.
approaches:
1. The sending server sends the announcement message to the ENRP
server channel. This must also handle the relation between the
ENRP server channel and the operational scope. The usage of the
ENRP server channel is for further study.
2. The sending server sends multiple copies of the announcement, one
to each of its peer servers, over a set of point-to-point SCTP
associations between the sending server and the peers.
In order to maximize inter-operability of ENRP servers, the following
rules MUST be followed:
1. At the startup time, a new ENRP server SHOULD make a decision on
whether it will enable IP multicast for ENRP announcements. This
decision should be based on preconfigured information such as the
availability of IP multicast and the security requirements from
the user of RSerPool.
2. If an ENRP server disables multicast, it then:
A. MUST NOT subscribe to the well-known server multicast
channel, i.e., it only receives peer announcements over SCTP
associations, and
B. MUST transmit all its out-going announcements over point-to-
point SCTP associations with its peers.
3. If an ENRP server enables itself to use multicast, it then:
A. MUST subscribe to the well-known server multicast channel to
ready itself for receiving peers' multicast announcements,
B. MUST also be prepared to receive peer announcements over
point-to-point SCTP associations from peers.
C. MUST track internally which peers are multicast-enabled and
which are not. Note: A peer is always assumed to be
multicast-disabled until/unless an ENRP message of any type
is received from that peer over the well-known server
multicast channel.
D. when sending out an announcement, MUST send a copy to the
ENRP server channel AND a copy to each of the peers that are
marked as multicast-disabled over a point-to-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
A new ENRP server MUST generate a non-zero, 32-bit server Id that is A new ENRP server MUST generate a non-zero, 32-bit server Id that is
as unique as possible in the operational scope and this server Id as unique as possible among all the ENRP servers in the operational
MUST remain unchanged for the lifetime of the server. Normally, a scope and this server Id MUST remain unchanged for the lifetime of
good 32-bit random number will be good enough as the server Id the server. Normally, a good 32-bit random number will be good
(RFC4086 [11] provides some information on randomness guidelines). enough as the server Id (RFC4086 [12] provides some information on
randomness guidelines).
Note, there is a very remote chance (about 1 in about 4 billion) that Note, there is a very remote chance (about 1 in about 4 billion) that
two ENRP servers in an operational scope will generate the same two ENRP servers in an operational scope will generate the same
server Id and hence cause a server Id conflict in the pool. However, server Id and hence cause a server Id conflict in the pool. However,
no severe consequence of such a conflict has been identified. no severe consequence of such a conflict has been identified.
Note, the ENRP server Id space is separate from the PE Id space
defined in [9].
3.2.2. Acquire Peer Server List 3.2.2. Acquire Peer Server List
At startup, the ENRP server (initiating server) will first attempt to At startup, the ENRP server (initiating server) will first attempt to
learn all existing peer ENRP servers in the same operational scope, learn all existing peer ENRP servers in the same operational scope,
or to determine that it is alone in the scope. or to determine that it is alone in the scope.
The initiating server uses an existing peer server to bootstrap The initiating server uses an existing peer server to bootstrap
itself into service. We call this peer server the mentor server. itself into service. We call this peer server the mentor server.
3.2.2.1. Finding the mentor server 3.2.2.1. Finding the mentor server
If the initiating server is told about an existing peer server If the initiating server is told about one existing peer server
through some administrative means (such as DNS query, configuration through some administrative means (such as DNS query, configuration
database, startup scripts, etc), the initiating server SHOULD then database, startup scripts, etc), the initiating server MUST then use
use this peer server as its mentor server and SHOULD skip the this peer server as its mentor server.
remaining steps in this subsection.
If multiple existing peer servers are specified, the initiating If multiple existing peer servers are specified, the initiating
server SHOULD pick one of them as its mentor server, keep the others server MUST pick one of them as its mentor server and keep the others
as its backup mentor servers, and skip the remaining steps in this as its backup mentor servers.
subsection.
If no existing peer server is specified to the initiating server AND
if multicast is available in the operational scope, the following
mentor server discovery procedures SHOULD be followed:
1. The initiating server SHOULD first join the ENRP server channel.
2. When the first ENRP_PRESENCE message arrives, the server SHOULD
take the sender of this received response as its mentor server.
This completes the discovery of the mentor server.
If ENRP_PRESENCE messages are also received from other peers (a
likely event when multiple peers exist in the operational scope
at the time the new server started), the initiating server SHOULD
keep a list of those responded as its backup mentor servers (see
below).
3. If no response to its ENRP_PRESENCE message are received after
TIMEOUT-SERVER-HUNT seconds, the initiating server SHOULD repeat
steps 2) and 3) for up to MAX-NUMBER-SERVER-HUNT times. After
that, if there is still no response, the initiating server MUST
assume that it is alone in the operational scope.
4. If the initiating server determined that it is alone in the
scope, it MUST skip the procedures in Section 3.2.2.2 and
Section 3.2.3 and MUST consider its initialization completed and
start offering ENRP services.
Note, if multicast is not available (or not allowed for reasons such
as security concerns) in the operational scope, at least one peer
server MUST be specified to the initiating server through
administrative means, unless the initiation server is the first
server to start in the operational scope.
Note, if the administratively specified mentor peer(s) fails and the If no existing peer server is specified, the initiating server MUST
ENRP server channel is available, the initiating server SHOULD use assume that it is alone in the operational scope, and MUST skip the
the auto-discover procedure defined in steps 1-5 above. procedures in Section 3.2.2.2 and Section 3.2.3 and MUST consider its
initialization completed and start offering ENRP services.
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.4 for maintaining server list).
The initiating server SHOULD start a MAX-TIME-NO-RESPONSE timer every The initiating server SHOULD start a MAX-TIME-NO-RESPONSE timer every
time it finishes sending an ENRP_LIST_REQUEST message. If the timer time it finishes sending an ENRP_LIST_REQUEST message. If the timer
expires before receiving a response from the mentor peer, the expires before receiving a response from the mentor peer, the
initiating server SHOULD abort and send a new server list request to initiating server SHOULD abandon the interaction with the current
a backup mentor peer, if one is available. mentor server 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
skipping to change at page 23, line 14 skipping to change at page 21, line 33
server SHOULD abort the current download session and re-start a new server SHOULD abort the current download session and re-start a new
handlespace download with a backup mentor peer, if one is available. handlespace download with a backup mentor peer, if one is available.
Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, and the Similarly, after sending out an ENRP_HANDLE_TABLE_RESPONSE, and the
mentor peer set the M-bit to 1 to indicate that it has more data to mentor peer set the M-bit to 1 to indicate that it has more data to
send, it SHOULD start a session timer. If this timer expires without send, it SHOULD start a session timer. If this timer expires without
receiving another request from the initiating server, the mentor peer receiving another request from the initiating server, the mentor peer
SHOULD abort the session, cleaning out any resource and record of the SHOULD abort the session, cleaning out any resource and record of the
session. session.
3.3. Handle PE Registration 3.3. Server Handlespace Update
To register itself with the handlespace, a PE sends an
ASAP_REGISTRATION message to its home ENRP server. The format of
ASAP_REGISTRATION message and rules of sending it are defined in [9].
In the ASAP_REGISTRATION message, the PE indicates the handle of the
pool it wishes to join in a pool handle parameter, and its complete
transport information and any load control information in a PE
parameter.
The ENRP server handles the ASAP_REGISTRATION message according to
the following rules:
1. If the named pool does not exist in the handlespace, the ENRP
server MUST creates a new pool with that handle in the
handlespace and add the PE to the pool as its first PE;
When a new pool is created, the overall member selection policy
of the pool MUST be set to the policy type indicated by the first
PE, the overall pool transport type MUST be set to the transport
type indicated by the PE, and the overall pool data/control
channel configuration MUST be set to what is indicated in the
Transport Use field of the User Transport parameter by the
registering PE.
2. If the named pool already exists in the handlespace, but the
requesting PE is not currently a member of the pool, the ENRP
server will add the PE as a new member to the pool;
However, before adding the PE to the pool, the server MUST check
if the policy type, transport type, and transport usage indicated
by the registering PE is consistent with those of the pool. If
different, the ENRP server MUST reject the registration.
3. If the named pool already exists in the handlespace AND the
requesting PE is already a member of the pool, the ENRP server
SHOULD consider this as a re-registration case. The ENRP server
MUST perform the same tests on policy, transport type, transport
use, as described above. If the re-registration is accepted
after the test, the ENRP Server SHOULD replace the attributes of
the existing PE with the information carried in the received
ASAP_REGISTRATION message.
4. After accepting the registration, the ENRP server MUST assign
itself the owner of this PE. If this is a re-registration, the
ENRP server MUST take over ownership of this PE regardless of
whether the PE was previously owned by this server or by another
server. The ENRP server MUST also record the SCTP transport
address from which it received the ASAP_REGISTRATION in the ASAP
Transport parameter TLV inside the PE parameter of this PE.
5. The ENRP server may reject the registration due to other reasons
such as invalid values, lack of resource, authentication failure,
etc.
In all above cases, the ENRP server MUST reply to the requesting PE
with an ASAP_REGISTRATION_RESPONSE message. If the registration is
accepted, the ENRP server MUST set the 'R' flag in the
ASAP_REGISTRATION_RESPONSE to '0'. If the registration is rejected,
the ENRP server MUST indicate the rejection by setting the 'R' flag
in the ASAP_REGISTRATION_RESPONSE to '1'.
If the registration is rejected, the ENRP server SHOULD include the
proper error cause(s) in the ASAP_REGISTRATION_RESPONSE message.
If the registration is granted (either a new registration or a re-
registration case), the ENRP server MUST assign itself to be the home
ENRP server of the PE, i.e., to "own" the PE.
Implementation note: for better performance, the ENRP server may
find it both efficient and convenient to internally maintain two
separate PE lists or tables - one is for the PEs that are "owned"
by the ENRP server and the other for all the PEs owned by its
peer(s).
Moreover, if the registration is granted, the ENRP server MUST take
the handlespace update action as described in Section 3.6 to inform
its peers about the change just made. If the registration is denied,
no message will be sent to its peers.
3.3.1. Rules on PE Re-registration
A PE may re-register itself to the handlespace with a new set of
attributes in order to, for example, extend its registration life,
change its load factor value, etc. as described in the ASAP
specification.
A PE may modify its load factor value at any time via re-
registration. Based on the number of PEs in the pool and the pool's
overall policy type, this operation allows the PE to dynamically
control its share of inbound messages received by the pool (also see
Section ???? in [9] for more on load control).
Moreover, when re-registering, the PE MUST NOT change its policy
type. The server MUST reject the re-registration if the PE attempt
to change its policy type. In the rejection, the server SHOULD
attach an error code "Pooling Policy Inconsistent".
Regardless whether it is the current owner of the PE, if the re-
registration is granted to the PE, the ENRP server MUST assign itself
to be the new home ENRP server of the PE.
Moreover, if the re-registration is granted, the ENRP server MUST
take the handlespace update action as described in Section 3.6 to
inform its peers about the change just made. If the re-registration
is denied, no message will be sent to its peers.
3.4. Handle PE De-registration
To remove itself from a pool, a PE sends an ASAP_DEREGISTRATION
message to its home ENRP server. The complete format of
ASAP_DEREGISTRATION message and rules of sending it are defined in
[9].
In the ASAP_DEREGISTRATION message the PE indicates the handle of the
pool it belongs to in a pool handle parameter and provides its PE
identifier.
Upon receiving the message, the ENRP server SHALL remove the PE from
its handlespace. Moreover, if the PE is the last one of the named
pool, the ENRP server will remove the pool from the handlespace as
well.
If the ENRP server fails to find any record of the PE in its
handlespace, it SHOULD consider the de-registration granted and
completed, and send an ASAP_DEREGISTRATION_RESPONSE message to the
PE.
The ENRP server may reject the de-registration request for various
reasons, such as invalid parameters, authentication failure, etc.
In response, the ENRP server MUST send an
ASAP_DEREGISTRATION_RESPONSE message to the PE. If the de-
registration is rejected, the ENRP server MUST indicate the rejection
by including the proper Operational Error parameter.
It should be noted that de-registration does not stop the PE from
sending or receiving application messages.
Once the de-registration request is granted AND the PE removed from
its local copy of the handlespace, the ENRP server MUST take the
handlespace update action described in Section 3.6 to inform its
peers about the change just made. Otherwise, the ENRP server MUST
NOT inform its peers.
3.5. Pool Handle Translation
A PU uses the pool handle translation service of an ENRP server to
resolve a pool handle to a list of accessible transport addresses of
the member PEs of the pool.
This requires the PU to send an ASAP_HANDLE_RESOLUTION message to its
home ENRP server and in the ASAP_HANDLE_RESOLUTION message specify
the pool handle to be translated in a Pool Handle parameter.
Complete definition of the ASAP_HANDLE_RESOLUTION message and the
rules of sending it are defined in [9].
An ENRP server SHOULD be prepared to receive ASAP_HANDLE_RESOLUTION
requests from PUs either over an SCTP association on the well-know
SCTP port, or over a TCP connection on the well-know TCP port.
Upon reception of the ASAP_HANDLE_RESOLUTION message, the ENRP server
MUST first look up the pool handle in its handlespace. If the pool
exits, the home ENRP server MUST compose and send back an
ASAP_HANDLE_RESOLUTION_RESPONSE message to the requesting PU.
In the response message, the ENRP server SHOULD list all the PEs
currently registered in this pool, in a list of PE parameters. The
ENRP server MUST also include a pool member selection policy
parameter to indicate the overall member selection policy for the
pool, if the current pool member selection policy is not round-robin.
If the named pool does not exist in the handlespace, the ENRP server
MUST reject the handle resolution request by responding with an
ASAP_HANDLE_RESOLUTION_RESPONSE message carrying a Unknown Poor
Handle error.
The complete format of ASAP_HANDLE_RESOLUTION_RESPONSE message and
the rules of receiving it are defined in [9].
3.6. Server Handlespace Update
This includes a set of update operations used by an ENRP server to This includes a set of update operations used by an ENRP server to
inform its peers when its local handlespace is modified, e.g., inform its peers when its local handlespace is modified, e.g.,
addition of a new PE, removal of an existing PE, change of pool or PE addition of a new PE, removal of an existing PE, change of pool or PE
properties. properties.
3.6.1. Announcing Addition or Update of PE 3.3.1. Announcing Addition or Update of PE
When a new PE is granted registration to the handlespace or an When a new PE is granted registration to the handlespace or an
existing PE is granted a re-registration, the home ENRP server uses existing PE is granted a re-registration, the home ENRP server uses
this procedure to inform all its peers. this procedure to inform all its peers.
This is an ENRP announcement and is sent to all the peer of the home This is an ENRP announcement and is sent to all the peer of the home
ENRP server. See Section 3.1 on how announcements are sent. ENRP server. See Section 3.1 on how announcements are sent.
An ENRP server MUST announce this update to all its peers in a An ENRP server MUST announce this update to all its peers in a
ENRP_HANDLE_UPDATE message with the Update Action field set to ENRP_HANDLE_UPDATE message with the Update Action field set to
skipping to change at page 28, line 5 skipping to change at page 22, line 33
2. If the named pool already exists in the peer's local copy of the 2. If the named pool already exists in the peer's local copy of the
handlespace AND the PE does not exist, the peer MUST add the PE handlespace AND the PE does not exist, the peer MUST add the PE
to the pool as a new PE and copy in all attributes of the PE to the pool as a new PE and copy in all attributes of the PE
carried in the message. carried in the message.
3. If the named pool exists AND the PE is already a member of the 3. If the named pool exists AND the PE is already a member of the
pool, the peer MUST replace the attributes of the PE with the new pool, the peer MUST replace the attributes of the PE with the new
information carried in the message. information carried in the message.
3.6.2. Announcing Removal of PE 3.3.2. Announcing Removal of PE
When an existing PE is granted de-registration or is removed from its When an existing PE is granted de-registration or is removed from its
handlespace for some other reasons (e.g., purging an unreachable PE, handlespace for some other reasons (e.g., purging an unreachable PE,
see Section 3.7), the ENRP server MUST uses this procedure to inform see 3.5 in [9]), the ENRP server MUST uses this procedure to inform
all its peers about the change just made. all its peers about the change just made.
This is an ENRP announcement and is sent to all the peer of the home This is an ENRP announcement and is sent to all the peer of the home
ENRP server. See Section 3.1 on how announcements are sent. ENRP server. See Section 3.1 on how announcements are sent.
An ENRP server MUST announce the PE removal to all its peers in an An ENRP server MUST announce the PE removal to all its peers in an
ENRP_HANDLE_UPDATE message with the Update Action field set to ENRP_HANDLE_UPDATE message with the Update Action field set to
DEL_PE, indicating the removal of an existing PE. The complete DEL_PE, indicating the removal of an existing PE. The complete
information of the PE and the pool its belongs to MUST be indicated information of the PE and the pool its belongs to MUST be indicated
in the message with a PE parameter and a Pool Handle parameter, in the message with a PE parameter and a Pool Handle parameter,
skipping to change at page 28, line 34 skipping to change at page 23, line 14
0's). 0's).
When a peer receives this ENRP_HANDLE_UPDATE message, it MUST first When a peer receives this ENRP_HANDLE_UPDATE message, it MUST first
find pool and the PE in its own handlespace, and then remove the PE find pool and the PE in its own handlespace, and then remove the PE
from its local handlespace. If the removed PE is the last one in the from its local handlespace. If the removed PE is the last one in the
pool, the peer MUST also delete the pool from its local handlespace. pool, the peer MUST also delete the pool from its local handlespace.
If the peer fails to find the PE or the pool in its handlespace, it If the peer fails to find the PE or the pool in its handlespace, it
SHOULD take no further actions. SHOULD take no further actions.
3.7. Detecting and Removing Unreachable PE 3.4. Maintaining Peer List and Monitoring Peer Status
Whenever a PU finds a PE unreachable (e.g., via an SCTP SEND.FAILURE
Notification, see section 10.2 of [4]), the PU SHOULD send an
ASAP_ENDPOINT_UNREACHABLE message to its home ENRP server. The
message SHOULD contain the pool handle and the PE Id of the
unreachable PE.
Upon the reception of an ASAP_ENDPOINT_UNREACHABLE message, a server
MUST immediately send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE
message to the PE in question (the 'H' flag in the message SHOULD be
set to '0' in this case). If this ASAP_ENDPOINT_KEEP_ALIVE fails
(e.g., it results in an SCTP SEND.FAILURE notification), the ENRP
server MUST consider the PE as truly unreachable and MUST remove the
PE from its handlespace and take actions described in Section 3.6.2.
If the ASAP_ENDPOINT_KEEP_ALIVE message is transmitted successfully
to the PE, the ENRP server MUST retain the PE in its handlespace.
Moreover, the server SHOULD keep a counter to record how many
ASAP_ENDPOINT_UNREACHABLE messages it has received reporting
reachability problem relating to this PE. If the counter exceeds the
protocol threshold MAX-BAD-PE-REPORT, the ENRP server SHOULD remove
the PE from its handlespace and take actions described in
Section 3.6.2.
Optionally, an ENRP server may also periodically send point-to-point
ASAP_ENDPOINT_KEEP_ALIVE (with 'H' flag set to '0') messages to each
of the PEs owned by the ENRP server in order to check their
reachability status. If the send of ASAP_ENDPOINT_KEEP_ALIVE to a PE
fails, the ENRP server MUST consider the PE as unreachable and MUST
remove the PE from its handlespace and take actions described in
Section 3.6.2. Note, if an ENRP server owns a large number of PEs,
the implementation should pay attention not to flood the network with
bursts of ASAP_ENDPOINT_KEEP_ALIVE messages. Instead, the
implementation MUST distribute the ASAP_ENDPOINT_KEEP_ALIVE message
traffic over a time period.
The complete definition and rules of sending
ASAP_ENDPOINT_UNREACHABLE and receiving ASAP_ENDPOINT_KEEP_ALIVE
messages are described in [9].
3.8. Helping PE and PU to Discover Home ENRP Server
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
server. For this reason, the PE or PU will need to maintain a list
of currently available ENRP servers in its scope.
To help the PE or PU maintaining this list, an ENRP server, if it is
enabled for multicast, SHOULD periodically send out an
ASAP_SERVER_ANNOUNCE message every SERVER-ANNOUNCE-CYCLE seconds to
the well-known ASAP multicast channel. And in the
ASAP_SERVER_ANNOUNCE message the ENRP server SHOULD include all the
transport addresses available for ASAP communications. If the ENRP
server only supports SCTP for ASAP communications, the transport
information MAY be omitted in the ASAP_SERVER_ANNOUNCE message.
For the complete procedure of this, see Section 3.6?? in [9].
3.9. Maintaining Peer List and Monitoring Peer Status
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.4.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 Reply- The ENRP server MUST send an ENRP_PRESENCE message with the Reply-
required flag set to '1' to the source address found in the arrived required flag set to '1' to the source address found in the 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).
3.9.2. Server Sending Heartbeat 3.4.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
peers to update their internal variable "peer_last_heard" for the peers to update their internal variable "peer_last_heard" for the
sending server (see Section 3.9.3 for more details). sending server (see Section 3.4.3 for more details).
3.9.3. Detecting Peer Server Failure 3.4.3. Detecting Peer Server Failure
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 MAX-TIME-NO- If the send fails or the peer does not reply after MAX-TIME-NO-
RESPONSE seconds, the ENRP server MUST consider the peer server dead RESPONSE seconds, the ENRP server MUST consider the peer server dead
and SHOULD initiate the takeover procedure defined in Section 3.10. and SHOULD initiate the takeover procedure defined in Section 3.5.
3.10. Taking-over a Failed Peer Server 3.5. 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." This allows server" and the failed peer server the "target server." This allows
PE to continue to operate in case of a failure of their Home ENRP PE to continue to operate in case of a failure of their Home ENRP
server. server.
3.10.1. Initiating Server Take-over Arbitration 3.5.1. Initiating Server Take-over Arbitration
The initiating server SHOULD first start the take-over arbitration The initiating server SHOULD first start the take-over arbitration
process by sending a ENRP_INIT_TAKEOVER message to all its peer process by sending a ENRP_INIT_TAKEOVER message to all its peer
servers. See Section 3.1 on how announcements are sent. In the servers. See Section 3.1 on how announcements are sent. In the
message, the initiating server MUST fill in the Sending Server's ID message, the initiating server MUST fill in the Sending Server's ID
and Targeting Server's ID. The goal is that only one ENRP server and Targeting Server's ID. The goal is that only one ENRP server
takes over the PE from the target. takes over the PE from the target.
After announcing the ENRP_INIT_TAKEOVER message, the initiating After announcing the ENRP_INIT_TAKEOVER message (group-casting to all
server SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from each of known peers, including the target server), the initiating server
its known peers, except of the target server. SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from each of its
known peers, except of the target server.
Each peer receiving a ENRP_INIT_TAKEOVER message from the initiating Each peer receiving an ENRP_INIT_TAKEOVER message from the initiating
server SHOULD take the following actions: server MUST take the following actions:
1. If the peer server determines that itself is the target server 1. If the peer server determines that itself is the target server
indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately
announce an ENRP_PRESENCE message to all its peer ENRP servers in announce an ENRP_PRESENCE message to all its peer ENRP servers in
an attempt to stop this take-over process. This indicates a an attempt to stop this take-over process. This indicates a
false failure detection case by the initiating server. The false failure detection case by the initiating server. The
initiating server MUST stop the takeover operation. initiating server MUST stop the takeover operation by marking the
target server as "active" and taking no further takeover actions.
2. If the peer server finds that it has already started its own 2. If the peer server finds that it has already started its own
take-over arbitration process on the same target server, it MUST take-over arbitration process on the same target server, it MUST
perform the following arbitration: perform the following arbitration:
A. If the peer's server ID is smaller in value than the Sending A. If the peer's server ID is smaller in value than the Sending
Server's ID in the arrived ENRP_INIT_TAKEOVER message, the Server's ID in the arrived ENRP_INIT_TAKEOVER message, the
peer server SHOULD immediately abort its own take-over peer server MUST immediately abort its own take-over attempt
attempt. Moreover, the peer SHOULD mark the target server as by taking no further takeover actions of its own. Moreover,
"not active" on its internal peer list so that its status the peer MUST mark the target server as "not active" on its
will no longer be monitored by the peer, and reply the internal peer list so that its status will no longer be
initiating server with an ENRP_INIT_TAKEOVER_ACK message. monitored by the peer, and reply the initiating server with
an ENRP_INIT_TAKEOVER_ACK message.
B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER B. Otherwise, the peer MUST ignore the ENRP_INIT_TAKEOVER
message and take no action. message.
3. If the peer finds that it is neither the target server nor is in 3. If the peer finds that it is neither the target server nor is in
its own take-over process, the peer SHOULD: a) mark the target its own take-over process, the peer MUST: a) mark the target
server as "not active" on its internal peer list so that its server as "not active" on its internal peer list so that its
status will no longer be monitored by this peer, and b) reply to status will no longer be monitored by this peer, and b) MUST
the initiating server with an ENRP_INIT_TAKEOVER_ACK message. reply to the initiating server with an ENRP_INIT_TAKEOVER_ACK
message.
Once the initiating server has received ENRP_INIT_TAKEOVER_ACK Once the initiating server has received the ENRP_INIT_TAKEOVER_ACK
message from _all_ of its currently known peers (except for the message from all of its currently known peers (except for the target
target server), it SHOULD consider that it has won the arbitration server), it MUST consider that it has won the arbitration and MUST
and SHOULD proceed to complete the take-over, following the steps proceed to complete the take-over, following the steps described in
described in Section 3.10.2. Section 3.5.2.
However, if it receives an ENRP_PRESENCE from the target server at However, if it receives an ENRP_PRESENCE from the target server at
any point in the arbitration process, the initiating server MUST any point in the arbitration process, the initiating server MUST
immediately abort the take-over process and mark the status of the immediately stop the take-over process and mark the status of the
target server as "active". target server as "active".
3.10.2. Take-over Target Peer Server 3.5.2. Take-over Target Peer Server
The initiating ENRP server SHOULD first send, via an announcement, a The initiating ENRP server MUST first send, via an announcement, an
ENRP_TAKEOVER_SERVER message to inform all its active peers that the ENRP_TAKEOVER_SERVER message to inform all its active peers that the
take-over is enforced. The target server's ID MUST be filled in the take-over is enforced. The target server's ID MUST be filled in the
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
skipping to change at page 32, line 40 skipping to change at page 26, line 12
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.
3.11. Handlespace Data Auditing and Re-synchronization 3.6. Handlespace Data Auditing and Re-synchronization
Message losses or certain temporary breaks in network connectivity Message losses or certain temporary breaks in network connectivity
may result in data inconsistency in the local handlespace copy of may result in data inconsistency in the local handlespace copy of
some of the ENRP servers in an operational scope. Therefore, each some of the ENRP servers in an operational scope. Therefore, each
ENRP server in the operational scope SHOULD periodically verify that ENRP server in the operational scope SHOULD periodically verify that
its local copy of handlespace data is still in sync with that of its its local copy of handlespace data is still in sync with that of its
peers. peers.
This section defines the auditing and re-synchronization procedures This section defines the auditing and re-synchronization procedures
for an ENRP server to maintain its handlespace data consistency. for an ENRP server to maintain its handlespace data consistency.
3.11.1. Auditing Procedures 3.6.1. Auditing Procedures
A checksum covering the data which should be the same is exchanged to A checksum covering the data which should be the same is exchanged to
figure out if the data is the same or not. figure out if the data is the same or not.
The auditing of handlespace consistency is based on the following The auditing of handlespace consistency is based on the following
procedures: procedures:
1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit 1. An ENRP server SHOULD keep a separate PE checksum (a 32-bit
integer internal variable) for each of its known peers and for integer internal variable) for each of its known peers and for
itself. For an ENRP server with 'k' known peers, we denote these itself. For an ENRP server with 'k' known peers, we denote these
internal variables as "pe_checksum_pr0", "pe_checksum_pr1", ..., internal variables as "pe_checksum_pr0", "pe_checksum_pr1", ...,
"pe_checksum_prk", where "pe_checksum_pr0" is the server's own PE "pe_checksum_prk", where "pe_checksum_pr0" is the server's own PE
checksum. The list of what these checksums cover and a detailed checksum. The list of what these checksums cover and a detailed
algorithm for calculating them is given in Section 3.11.2. algorithm for calculating them is given in Section 3.6.2.
2. Each time an ENRP server sends out an ENRP_PRESENCE, it MUST 2. Each time an ENRP server sends out an ENRP_PRESENCE, it MUST
include in the message its current PE checksum (i.e., include in the message its current PE checksum (i.e.,
"pe_checksum_pr0"). "pe_checksum_pr0").
3. When an ENRP server (server A) receives a PE checksum (carried in 3. When an ENRP server (server A) receives a PE checksum (carried in
an arrived ENRP_PRESENCE) from a peer ENRP server (server B), an arrived ENRP_PRESENCE) from a peer ENRP server (server B),
server A SHOULD compare the PE checksum found in the server A SHOULD compare the PE checksum found in the
ENRP_PRESENCE with its own internal PE checksum of server B ENRP_PRESENCE with its own internal PE checksum of server B
(i.e., "pe_checksum_prB"). (i.e., "pe_checksum_prB").
4. If the two values match, server A will consider that there is no 4. If the two values match, server A will consider that there is no
handlespace inconsistency between itself and server B and should handlespace inconsistency between itself and server B and should
take no further actions. take no further actions.
5. If the two values do NOT match, server A SHOULD consider that 5. If the two values do NOT match, server A SHOULD consider that
there is a handlespace inconsistency between itself and server B there is a handlespace inconsistency between itself and server B
and a re-synchronization process SHOULD be carried out and a re-synchronization process SHOULD be carried out
immediately with server B (see Section 3.11.3). immediately with server B (see Section 3.6.3).
3.11.2. PE Checksum Calculation Algorithm 3.6.2. PE Checksum Calculation Algorithm
When an ENRP server (server A) calculate an internal PE checksum for When an ENRP server (server A) calculate an internal PE checksum for
a peer (server B), it MUST use the following algorithm. a peer (server B), it MUST use the following algorithm.
Let us assume that in server A's internal handlespace there are Let us assume that in server A's internal handlespace there are
currently 'M' PEs that are owned by server B. Each of the 'M' PEs currently 'M' PEs that are owned by server B. Each of the 'M' PEs
will then contribute to the checksum calculation with the following will then contribute to the checksum calculation with the following
byte block: byte block:
0 1 2 3 0 1 2 3
skipping to change at page 34, line 36 skipping to change at page 28, line 5
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.
Implementation Note: when the internal handlespace changes (e.g., a Implementation Note: when the internal handlespace changes (e.g., a
new PE added or an existing PE removed), an implementation needs not new PE added or an existing PE removed), an implementation needs not
to re-calculate the affected PE checksum; it can instead simply to re-calculate the affected PE checksum; it can instead simply
update the checksum by adding or subtracting the byte block of the update the checksum by adding or subtracting the byte block of the
corresponding PE from the previous checksum value. corresponding PE from the previous checksum value.
3.11.3. Re-synchronization Procedures 3.6.3. Re-synchronization Procedures
If an ENRP server determines that there is inconsistency between its If an ENRP server determines that there is inconsistency between its
local handlespace data and a peer's handlespace data with regarding local handlespace data and a peer's handlespace data with regarding
to the PEs owned by that peer, it MUST perform the following steps to to the PEs owned by that peer, it MUST perform the following steps to
re-synchronize the data: re-synchronize the data:
1. The ENRP server SHOULD first "mark" every PE it knows about that 1. The ENRP server SHOULD first "mark" every PE it knows about that
is owned by the peer in its local handlespace database; is owned by the peer in its local handlespace database;
2. The ENRP server SHOULD then send an ENRP_HANDLE_TABLE_REQUEST 2. The ENRP server SHOULD then send an ENRP_HANDLE_TABLE_REQUEST
skipping to change at page 35, line 23 skipping to change at page 28, line 41
5. After transferring all the PE entries from the received 5. After transferring all the PE entries from the received
ENRP_HANDLE_TABLE_RESPONSE message into its local database, the ENRP_HANDLE_TABLE_RESPONSE message into its local database, the
ENRP server SHOULD check whether there are still PE entries that ENRP server SHOULD check whether there are still PE entries that
remain "marked" in its local handlespace. If so, the ENRP server remain "marked" in its local handlespace. If so, the ENRP server
SHOULD silently remove those "marked" entries. SHOULD silently remove those "marked" entries.
Note, similar to what is described in Section 3.2.3, the peer may Note, similar to what is described in Section 3.2.3, the peer may
reject the ENRP_HANDLE_TABLE_REQUEST or use more than one reject the ENRP_HANDLE_TABLE_REQUEST or use more than one
ENRP_HANDLE_TABLE_RESPONSE message to respond. ENRP_HANDLE_TABLE_RESPONSE message to respond.
3.12. Handling Unrecognized Message or Unrecognized Parameter 3.7. Handling Unrecognized Message or Unrecognized Parameter
When an ENRP server receives an ENRP message with an unknown message When an ENRP server receives an ENRP message with an unknown message
type or a message of known type that contains an unknown parameter, type or a message of known type that contains an unknown parameter,
it SHOULD handle the unknown message or the unknown parameter it SHOULD handle the unknown message or the unknown parameter
according to the unrecognized message and parameter handling rules according to the unrecognized message and parameter handling rules
defined in Sections 3 and 4 in [8]. defined in Sections 3 and 4 in [8].
According to the rules, if an error report to the message sender is According to the rules, if an error report to the message sender is
needed, the ENRP server that discovered the error SHOULD send back an needed, the ENRP server that discovered the error SHOULD send back an
ENRP_ERROR message with proper error cause code. ENRP_ERROR message with proper error cause code.
4. Variables and Thresholds 4. Variables and Thresholds
4.1. Variables 4.1. Variables
peer_last_heard - the local time that a peer server was last heard peer_last_heard - the local time that a peer server was last heard
(via receiving either a multicast or point-to-point message from (via receiving either a group-cast or point-to-point message from
the peer). the peer).
pe_checksum_pr - the internal 32-bit PE checksum that an ENRP server pe_checksum_pr - the internal 32-bit PE checksum that an ENRP server
keeps for a peer. A separate PE checksum is kept for each of its keeps for a peer. A separate PE checksum is kept for each of its
known peers as well as for itself. known peers as well as for itself.
4.2. Thresholds 4.2. Thresholds
MAX-NUMBER-SERVER-HUNT - the maximal number of attempts a sender
will make to contact an ENRP server (Default=3 times).
TIMEOUT-SERVER-HUNT - pre-set threshold for how long a sender will
wait for a response from an ENRP server (Default=5 seconds).
PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a PEER-HEARTBEAT-CYCLE - the period for an ENRP server to announce a
heartbeat message to all its known peers. (Default=30 secs.) heartbeat message to all its known peers. (Default=30 secs.)
SERVER-ANNOUNCE-CYCLE - the period for an ENRP server to announce a
SERVER_ANNOUNCE message to all PEs and PUs. (Default=5 secs.)
MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server MAX-TIME-LAST-HEARD - pre-set threshold for how long an ENRP server
will wait before considering a silent peer server potentially will wait before considering a silent peer server potentially
dead. (Default=61 secs.) dead. (Default=61 secs.)
MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message MAX-TIME-NO-RESPONSE - pre-set threshold for how long a message
sender will wait for a response after sending out a message. sender will wait for a response after sending out a message.
(Default=5 secs.) (Default=5 secs.)
MAX-BAD-PE-REPORT - the maximal number of unreachability reports on
a PE that an ENRP server will allow before purging this PE from
the handlespace. (Default=3)
5. IANA Considerations 5. IANA Considerations
[NOTE to RFC-Editor: [NOTE to RFC-Editor:
"RFCXXXX" is to be replaced by the RFC number you assign this "RFCXXXX" is to be replaced by the RFC number you assign this
document. document.
] ]
This document (RFCXXX) is the reference for all registrations This document (RFCXXX) is the reference for all registrations
skipping to change at page 38, line 10 skipping to change at page 32, line 5
Type Update Action Reference Type Update Action Reference
------------- -------------------- --------- ------------- -------------------- ---------
0x0000 ADD_PE RFCXXXX 0x0000 ADD_PE RFCXXXX
0x0001 DEL_PE RFCXXXX 0x0001 DEL_PE RFCXXXX
0x0002-0xffff (reserved by IETF) RFCXXXX 0x0002-0xffff (reserved by IETF) RFCXXXX
For registering at IANA an Update Action Type in this table a request For registering at IANA an Update Action Type in this table a request
has to be made to assign such a number. This number must be unique. has to be made to assign such a number. This number must be unique.
The "Specification Required" policy of RFC2434 [3] MUST be applied. The "Specification Required" policy of RFC2434 [3] MUST be applied.
5.3. Multicast Addresses
IANA should assign one multicast address for the ENRP server channel
and another one for the ENRP client channel.
6. Security Considerations 6. Security Considerations
We present a summary of the threats to the RSerPool architecture and We present a summary of the threats to the RSerPool architecture and
describe security requirements in response to mitigate the threats. describe security requirements in response to mitigate the threats.
Next we present the security mechanisms, based on TLS, that are Next we present the security mechanisms, based on TLS, that are
implementation requirements in response to the threats. Finally, we implementation requirements in response to the threats. Finally, we
present a chain of trust argument that examines critical data paths present a chain of trust argument that examines critical data paths
in RSerPool and shows how these paths are protected by the TLS in RSerPool and shows how these paths are protected by the TLS
implementation. implementation.
skipping to change at page 41, line 26 skipping to change at page 34, line 26
problem, but simply a requirement. When describing an API of the problem, but simply a requirement. When describing an API of the
RSerPool lower layer we have also to take into account the RSerPool lower layer we have also to take into account the
differences between TLS and SCTP. differences between TLS and SCTP.
Threat 8 requires the ASAP protocol to limit the number of Threat 8 requires the ASAP protocol to limit the number of
ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in [9]) to the ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 in [9]) to the
ENRP server. ENRP server.
Threat 9 requires the ENRP protocol to limit the number of Threat 9 requires the ENRP protocol to limit the number of
ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE (see
section Section 3.7). 3.5 in [9]).
6.3. Chain of trust 6.3. Chain of trust
Security is mandatory to implement in RSerPool and is based on TLS Security is mandatory to implement in RSerPool and is based on TLS
implementation in all three architecture components that comprise implementation in all three architecture components that comprise
RSerPool -- namely PU, PE and ENRP server. We define an ENRP server RSerPool -- namely PU, PE and ENRP server. We define an ENRP server
that uses TLS for all communication and authenticates ENRP peers and that uses TLS for all communication and authenticates ENRP peers and
PE registrants to be a secured ENRP server. PE registrants to be a secured ENRP server.
Here is a description of all possible data paths and a description of Here is a description of all possible data paths and a description of
skipping to change at page 43, line 5 skipping to change at page 36, line 5
Summary: Summary:
RSerPool architecture components can communicate with each other to RSerPool architecture components can communicate with each other to
establish a chain of trust. Secured PE and ENRP servers reject any establish a chain of trust. Secured PE and ENRP servers reject any
communications with unsecured ENRP or PE servers. communications with unsecured ENRP or PE servers.
If the above is enforced, then a chain of trust is established for If the above is enforced, then a chain of trust is established for
the RSerPool user. the RSerPool user.
7. Acknowledgements 7. Acknowledgments
The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson, The authors wish to thank John Loughney, Lyndon Ong, Walter Johnson,
Thomas Dreibholz, and many others for their invaluable comments and Thomas Dreibholz, and many others for their invaluable comments and
feedback. feedback.
8. References 8. References
8.1. Normative References 8.1. Normative References
[1] Braden, R., Borman, D., Partridge, C., and W. Plummer, [1] Braden, R., Borman, D., Partridge, C., and W. Plummer,
skipping to change at page 44, line 35 skipping to change at page 37, line 35
J., and M. Stillman, "Requirements for Reliable Server J., and M. Stillman, "Requirements for Reliable Server
Pooling", RFC 3237, January 2002. Pooling", RFC 3237, January 2002.
[6] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer [6] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436, Security over Stream Control Transmission Protocol", RFC 3436,
December 2002. December 2002.
[7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [7] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006. Protocol Version 1.1", RFC 4346, April 2006.
[8] Stewart, R., "Aggregate Server Access Protocol (ASAP) and [8] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate
Endpoint Handlespace Redundancy Protocol (ENRP) Parameters", Server Access Protocol (ASAP) and Endpoint Handlespace
draft-ietf-rserpool-common-param-12 (work in progress), Redundancy Protocol (ENRP) Parameters",
July 2007. draft-ietf-rserpool-common-param-14 (work in progress),
November 2007.
[9] Stewart, R., "Aggregate Server Access Protocol (ASAP)", [9] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate
draft-ietf-rserpool-asap-16 (work in progress), July 2007. Server Access Protocol (ASAP)", draft-ietf-rserpool-asap-18
(work in progress), November 2007.
[10] Gopal, R., Guttman, E., Holdrege, M., Sengodan, S., and M. [10] Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S.
Stillman, "Threats Introduced by Rserpool and Requirements for Sengodan, "Threats Introduced by RSerPool and Requirements for
Security in response to Threats", Security in Response to Threats",
draft-ietf-rserpool-threats-08 (work in progress), draft-ietf-rserpool-threats-09 (work in progress),
September 2007. October 2007.
[11] Stewart, R., "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-15
(work in progress), July 2007.
8.2. Informative References 8.2. Informative References
[11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [12] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
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
Phone: Phone:
Email: qxie1@email.mot.com Email: Qiaobing.Xie@motorola.com
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
USA USA
Phone: Phone:
Email: rrs@cisco.com Email: rrs@cisco.com
 End of changes. 65 change blocks. 
479 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/