draft-ietf-rserpool-enrp-21.txt   rfc5353.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft R. Stewart Request for Comments: 5353 R. Stewart
Intended status: Experimental Category: Experimental The Resource Group
Expires: January 12, 2009 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. Sun Microsystems, Inc.
July 11, 2008 September 2008
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
draft-ietf-rserpool-enrp-21.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2009. This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
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
(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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Definitions ................................................3
1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Conventions ................................................4
2. ENRP Message Definitions . . . . . . . . . . . . . . . . . . . 6 2. ENRP Message Definitions ........................................4
2.1. ENRP_PRESENCE message . . . . . . . . . . . . . . . . . . 6 2.1. ENRP_PRESENCE Message ......................................5
2.2. ENRP_HANDLE_TABLE_REQUEST message . . . . . . . . . . . . 8 2.2. ENRP_HANDLE_TABLE_REQUEST Message ..........................6
2.3. ENRP_HANDLE_TABLE_RESPONSE message . . . . . . . . . . . . 8 2.3. ENRP_HANDLE_TABLE_RESPONSE Message .........................7
2.4. ENRP_HANDLE_UPDATE message . . . . . . . . . . . . . . . . 10 2.4. ENRP_HANDLE_UPDATE Message .................................9
2.5. ENRP_LIST_REQUEST message . . . . . . . . . . . . . . . . 12 2.5. ENRP_LIST_REQUEST Message .................................10
2.6. ENRP_LIST_RESPONSE message . . . . . . . . . . . . . . . . 13 2.6. ENRP_LIST_RESPONSE Message ................................11
2.7. ENRP_INIT_TAKEOVER message . . . . . . . . . . . . . . . . 14 2.7. ENRP_INIT_TAKEOVER Message ................................12
2.8. ENRP_INIT_TAKEOVER_ACK message . . . . . . . . . . . . . . 14 2.8. ENRP_INIT_TAKEOVER_ACK Message ............................13
2.9. ENRP_TAKEOVER_SERVER message . . . . . . . . . . . . . . . 15 2.9. ENRP_TAKEOVER_SERVER Message ..............................14
2.10. ENRP_ERROR message . . . . . . . . . . . . . . . . . . . . 16 2.10. ENRP_ERROR Message .......................................15
3. ENRP Operation Procedures . . . . . . . . . . . . . . . . . . 17
3.1. Methods for Communicating amongst ENRP Servers . . . . . . 17
3.2. ENRP Server Initialization . . . . . . . . . . . . . . . . 17
3.2.1. Generate a Server Identifier . . . . . . . . . . . . . 17
3.2.2. Acquire Peer Server List . . . . . . . . . . . . . . . 18
3.2.3. Download ENRP Handlespace Data from Mentor Peer . . . 19
3.3. Server Handlespace Update . . . . . . . . . . . . . . . . 21
3.3.1. Announcing Addition or Update of PE . . . . . . . . . 21
3.3.2. Announcing Removal of PE . . . . . . . . . . . . . . . 22
3.4. Maintaining Peer List and Monitoring Peer Status . . . . . 23
3.4.1. Discovering New Peer . . . . . . . . . . . . . . . . . 23
3.4.2. Server Sending Heartbeat . . . . . . . . . . . . . . . 23
3.4.3. Detecting Peer Server Failure . . . . . . . . . . . . 23
3.5. Taking-over a Failed Peer Server . . . . . . . . . . . . . 24
3.5.1. Initiating Server Take-over Arbitration . . . . . . . 24
3.5.2. Take-over Target Peer Server . . . . . . . . . . . . . 25
3.6. Handlespace Data Auditing and Re-synchronization . . . . . 26
3.6.1. Auditing Procedures . . . . . . . . . . . . . . . . . 26
3.6.2. PE Checksum Calculation Algorithm . . . . . . . . . . 27
3.6.3. Re-synchronization Procedures . . . . . . . . . . . . 28
3.7. Handling Unrecognized Message or Unrecognized Parameter . 28 3. ENRP Operation Procedures ......................................15
4. Variables and Thresholds . . . . . . . . . . . . . . . . . . . 29 3.1. Methods for Communicating amongst ENRP Servers ............16
4.1. Variables . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2. ENRP Server Initialization ................................16
4.2. Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.1. Generate a Server Identifier .......................16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 3.2.2. Acquire Peer Server List ...........................17
5.1. A New Table for ENRP Message Types . . . . . . . . . . . . 30 3.2.2.1. Finding the Mentor Server .................17
5.2. A New Table for Update Action Types . . . . . . . . . . . 30 3.2.2.2. Request Complete Server List from
5.3. Port numbers . . . . . . . . . . . . . . . . . . . . . . . 31 Mentor Peer ...............................17
5.4. SCTP payload protocol identifier . . . . . . . . . . . . . 31 3.2.3. Download ENRP Handlespace Data from Mentor Peer ....18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 3.3. Server Handlespace Update .................................20
6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 32 3.3.1. Announcing Additions or Updates of PE ..............20
6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 33 3.3.2. Announcing Removal of PE ...........................21
6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 36 3.4. Maintaining Peer List and Monitoring Peer Status ..........22
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 3.4.1. Discovering New Peer ...............................22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.4.2. Server Sending Heartbeat ...........................22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 39 3.4.3. Detecting Peer Server Failure ......................23
8.2. Informative References . . . . . . . . . . . . . . . . . . 40 3.5. Taking Over a Failed Peer Server ..........................23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 3.5.1. Initiating Server Take-over Arbitration ............23
Intellectual Property and Copyright Statements . . . . . . . . . . 42 3.5.2. Takeover Target Peer Server ........................24
3.6. Handlespace Data Auditing and Re-synchronization ..........25
3.6.1. Auditing Procedures ................................25
3.6.2. PE Checksum Calculation Algorithm ..................26
3.6.3. Re-Synchronization Procedures ......................27
3.7. Handling Unrecognized Messages or Unrecognized
Parameters ................................................28
4. Variables and Thresholds .......................................28
4.1. Variables .................................................28
4.2. Thresholds ................................................28
5. IANA Considerations ............................................28
5.1. A New Table for ENRP Message Types ........................29
5.2. A New Table for Update Action Types .......................29
5.3. Port Numbers ..............................................30
5.4. SCTP Payload Protocol Identifier ..........................30
6. Security Considerations ........................................30
6.1. Summary of RSerPool Security Threats ......................30
6.2. Implementing Security Mechanisms ..........................32
6.3. Chain of Trust ............................................34
7. Acknowledgments ................................................35
8. References .....................................................36
8.1. Normative References ......................................36
8.2. Informative References ....................................37
1. Introduction 1. Introduction
ENRP is designed to work in conjunction with ASAP ENRP is designed to work in conjunction with ASAP [RFC5352] to
[I-D.ietf-rserpool-asap] to accomplish the functionality of RSerPool accomplish the functionality of RSerPool as defined by its
as defined by its requirements [RFC3237]. requirements [RFC3237].
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.
Whenever appropriate, in the rest of this document we will refer to Whenever appropriate, in the rest of this document, we will refer to
this RSerPool registry service as ENRP handlespace, or simply this RSerPool registry service as ENRP handlespace, or simply
handlespace because it manages all pool handles. handlespace, because it manages all pool handles.
1.1. Definitions 1.1. Definitions
This document uses the following terms: This document uses the following terms:
Operational scope: The part of the network visible to pool users by Operational scope: The part of the network visible to pool users by
a specific instance of the reliable server pooling protocols. a specific instance of the reliable server pooling protocols.
Pool (or server pool): A collection of servers providing the same Pool (or server pool): A collection of servers providing the same
application functionality. application functionality.
skipping to change at page 4, line 46 skipping to change at page 3, line 46
Pool user: A server pool user. Pool user: A server pool user.
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 Pool Element (PE) or Pool User (PU)) requests ENRP
client channel is usually defined by the transport address of the handlespace service. The client channel is usually defined by the
home server and a well-known port number. transport address of the Home ENRP server and a well-known port
number.
ENRP server channel: Defined by a list of IP addresses (one for each ENRP server channel: Defined by a list of IP addresses (one for each
ENRP servers in an operational scope) and a well known port ENRP server in an operational scope) and a well-known port number.
number. All ENRP servers in an operational scope can send "group- All ENRP servers in an operational scope can send "group-cast"
cast" messages to other servers through this channel. In a messages to other servers through this channel. In a "group-
"group-cast", the sending server sends multiple copies of the cast", the sending server sends multiple copies of the message,
message, one to each of its peer servers, over a set of point-to- one to each of its peer servers, over a set of point-to-point
point SCTP associations between the sending server and the peers. Stream Control Transmission Protocol (SCTP) associations between
The "group-cast" may be conveniently implemented with the use of the sending server and the peers. The "group-cast" may be
the "SCTP_SENDALL" option on an one-to-many style SCTP socket conveniently implemented with the use of the "SCTP_SENDALL" option
[I-D.ietf-tsvwg-sctpsocket]. on a one-to-many style SCTP socket.
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.
ENRP server does not need to know, nor does it need to keep track
of this relationship.
1.2. Conventions 1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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 [I-D.ietf-rserpool-asap]. A are part of ASAP and are defined in [RFC5352]. A common format, that
common format, that is defined in [I-D.ietf-rserpool-common-param], is defined in [RFC5354], is used for all ENRP and ASAP messages.
is used for all ENRP and ASAP messages.
Most ENRP messages contains a combination of fixed fields and TLV Most ENRP messages contain a combination of fixed fields and TLV
parameters. The TLV (Type-Length_value) parameters are also defined (Type-Length-Value) parameters. The TLV parameters are also defined
in [I-D.ietf-rserpool-common-param]. If a nested TLV parameter is in [RFC5354]. If a nested TLV parameter is not ended on a 32-bit
not ended on a 32-bit word boundary, it will be padded with all '0' word boundary, it will be padded with all '0' octets to the next 32-
octets to the next 32-bit word boundary. 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 (aka Big Endian, meaning
meaning the most significant byte is transmitted first). 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)
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_ERROR 0x0a - ENRP_ERROR
0x0b-0xff - (reserved by IETF) 0x0b-0xff - (Reserved by IETF)
Figure 1 Figure 1
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 sent on the ENRP server channel or sent point-to-
to another ENRP server. point 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x01 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x01 |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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: PE Checksum Param : : PE Checksum Param :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Param (optional) : : Server Information Param (optional) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID: 32 bit (unsigned integer) Sending Server's ID: 32 bits (unsigned integer)
This is the ID of the ENRP server which sent this message. This is the ID of the ENRP server that sent this message.
Receiving Server's ID: 32 bit (unsigned integer) Receiving Server's ID: 32 bits (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 group-casted 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 0s. If the message
is send point-to-point this field MAY be sent with all 0's. is sent point-to-point, this field MAY be sent with all 0s.
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 that sends the ENRP_PRESENCE. This parameter SHOULD be
included for handlespace consistency auditing. See included for handlespace consistency auditing. See
Section 3.6.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 (the Server
Parameter is defined in [I-D.ietf-rserpool-common-param]). Information Parameter is defined in [RFC5354]). This parameter
This parameter is optional. However, if this message is sent is optional. However, if this message is sent in response to a
in response to a received "reply required" ENRP_PRESENCE from a received "reply required" ENRP_PRESENCE from a peer, the sender
peer, the sender then MUST include its server information. then MUST include its server information.
Note, at startup an ENRP server MUST pick a randomly generated, non- Note, at startup, an ENRP server MUST pick a randomly generated, 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
until the ENRP server is rebooted. until the ENRP server is rebooted.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC | | Type = 0x02 |0|0|0|0|0|0|0|W| Message Length = 0xC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
W (oWn-children-only) Flag: 1 bit
W (oWn-children-only) flag: 1 bit
Set to '1' if the sender of this message is only requesting Set to '1' if the sender of this message is only requesting
information about the PEs owned by the message receiver. information about the PEs owned by the message receiver.
Otherwise, set to '0'. Otherwise, set to '0'.
Sending Server's ID: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiving Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
2.3. ENRP_HANDLE_TABLE_RESPONSE message 2.3. ENRP_HANDLE_TABLE_RESPONSE Message
The PEER_NAME_TABLE_RESPONSE message is sent by an ENRP server in The PEER_NAME_TABLE_RESPONSE message is sent by an ENRP server in
response to a received PEER_NAME_TABLE_REQUEST message to assist peer response to a received PEER_NAME_TABLE_REQUEST message to assist
server initialization or handle-space synchronization. peer-server initialization or handlespace 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x03 |0|0|0|0|0|0|M|R| Message Length | | Type = 0x03 |0|0|0|0|0|0|M|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID | | Sending Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: Pool entry #1 (optional) : : Pool Entry #1 (optional) :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: ... : : ... :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : :
: Pool entry #n (optional) : : Pool Entry #n (optional) :
: : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M (More_to_send) flag: 1 bit M (More_to_send) Flag: 1 bit
Set to '1' if the sender of this message has more pool entries Set to '1' if the sender of this message has more pool entries
to send in subsequent ENRP_HANDLE_TABLE_RESPONSE messages. to send in subsequent ENRP_HANDLE_TABLE_RESPONSE messages.
Otherwise, set to '0'. Otherwise, set to '0'.
R (Reject) flag: 1 bit R (Reject) Flag: 1 bit
MUST be set to '1' if the sender of this message is rejecting a MUST be set to '1' if the sender of this message is rejecting a
handlespace request. In this case, pool entries MUST NOT be handlespace request. In this case, pool entries MUST NOT be
included. This might happen if the sender of this message is included. This might happen if the sender of this message is
in the middle of initializing its database or it is under high in the middle of initializing its database or is under high
load. load.
Message Length: 16 bits (unsigned integer) Message Length: 16 bits (unsigned integer)
Indicates the entire length of the message including the header Indicates the entire length of the message, including the
in number of octets. header, in number of octets.
Note, the value in Message Length field will NOT cover any Note, the value in the Message Length field will NOT cover any
padding at the end of this message. padding at the end of this message.
Sending Server's ID: Sending Server's ID:
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.9 of Pool Handle parameter, as defined in Section 3.9 of [RFC5354],
[I-D.ietf-rserpool-common-param], and is followed by one or and is followed by one or more Pool Element parameters in TLV
more Pool Element parameters in TLV format, as shown below: format, 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, re-registration, or de- to all peer servers to announce registration, re-registration, or de-
registration of the PE in the handle-space. registration of the PE in the handlespace.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Action | (reserved) | | Update Action | (reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Element Parameter : : Pool Element Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Length: 16 bits (unsigned integer) Message Length: 16 bits (unsigned integer)
Indicates the entire length of the message including the header Indicates the entire length of the message, including the
in number of octets. header, in number of octets.
Note, the value in Message Length field will NOT cover any Note, the value in the Message Length field will NOT cover any
padding at the end of this message. padding at the end of this message.
Update Action: 16 bits (unsigned integer) Update Action: 16 bits (unsigned integer)
This field indicates the requested action of the specified PE. This field indicates the requested action of the specified PE.
The field MUST be set to one of the following values: The field MUST be set to one of the following values:
0x0000 - ADD_PE: Add or update the specified PE in the ENRP 0x0000 - ADD_PE: Add or update the specified PE in the ENRP
handlespace handlespace.
0x0001 - DEL_PE: Delete the specified PE from the ENRP 0x0001 - DEL_PE: Delete the specified PE from the ENRP
handlespace. handlespace.
0x0002 - 0xFFFF: Reserved by IETF. 0x0002 - 0xFFFF: Reserved by IETF.
Other values are reserved by IETF and MUST NOT be used. Other values are reserved by IETF and MUST NOT be used.
Reserved: 16 bits Reserved: 16 bits
This field MUST be set to all 0's by sender and ignored by the This field MUST be set to all 0s by the sender and ignored by
receiver. the receiver.
Sending Server's ID: Sending Server's ID:
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 handle: Pool Handle:
Specifies to which the PE belongs. Specifies to which the PE belongs.
Pool Element: Pool Element:
Specifies the PE. Specifies the PE.
2.5. ENRP_LIST_REQUEST message 2.5. ENRP_LIST_REQUEST Message
The PEER_LIST_REQUEST message is sent to request a current copy of The PEER_LIST_REQUEST message is sent to request a current copy of
the ENRP server list. This message is normally sent from a newly the ENRP server list. This message is normally sent from a newly
activated ENRP server to an established ENRP server as part of the activated ENRP server to an established ENRP server as part of the
initialization process. initialization process.
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 = 0x05 |0|0|0|0|0|0|0|0| Message Length = 0xC | | Type = 0x05 |0|0|0|0|0|0|0|0| Message Length = 0xC |
skipping to change at page 13, line 5 skipping to change at page 11, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiving Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
2.6. ENRP_LIST_RESPONSE message 2.6. ENRP_LIST_RESPONSE Message
The PEER_LIST_RESPONSE message is sent in response from an ENRP The PEER_LIST_RESPONSE message is sent in response from an ENRP
server that receives a PEER_LIST_REQUEST message to return server that receives a PEER_LIST_REQUEST message to return
information about known ENRP servers. information about known ENRP servers.
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 = 0x06 |0|0|0|0|0|0|0|R| Message Length | | Type = 0x06 |0|0|0|0|0|0|0|R| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 27 skipping to change at page 11, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiving Server's ID | | Receiving Server's ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Parameter of Peer #1 : : Server Information Parameter of Peer #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Server Information Parameter of Peer #n : : Server Information Parameter of Peer #n :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R (Reject) flag: 1 bit R (Reject) Flag: 1 bit
This flag MUST be set to '1' if the sender of this message is This flag MUST be set to '1' if the sender of this message is
rejecting a PEER_LIST_REQUEST message. If this case occurs, rejecting a PEER_LIST_REQUEST message. If this case occurs,
the message MUST NOT include any Server Information Parameters. the message MUST NOT include any Server Information Parameters.
Message Length: 16 bits (unsigned integer) Message Length: 16 bits (unsigned integer)
Indicates the entire length of the message in number of octets. Indicates the entire length of the message in number of octets.
Note, the value in Message Length field will NOT cover any Note, the value in the Message Length field will NOT cover any
padding at the end of this message. padding at the end of this message.
Sending Server's ID: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiving Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Server Information Parameter of Peer #1-#n: Server Information Parameter of Peer #1-#n:
Each contains a Server Information Parameter of a peer known to Each contains a Server Information Parameter of a peer known to
the sender. The Server Information Parameter is defined in the sender. The Server Information Parameter is defined in
[I-D.ietf-rserpool-common-param]. [RFC5354].
2.7. ENRP_INIT_TAKEOVER message 2.7. ENRP_INIT_TAKEOVER Message
The ENRP_INIT_TAKEOVER message is sent by an ENRP server (the The ENRP_INIT_TAKEOVER message is sent by an ENRP server (the
takeover initiator) to announce its intention of taking over a takeover initiator) to announce its intention of taking over a
specific peer ENRP server. It is send to all its peers. specific peer ENRP server. It is sent to all 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 = 0x07 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x07 |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 37 skipping to change at page 12, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sending Server's ID: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiving Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Targeting Server's ID: 32-bit (unsigned integer) Targeting Server's ID: 32 bits (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_TAKEOVER 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 30 skipping to change at page 14, line 5
Receiving Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Targeting Server's ID: Targeting Server's ID:
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.9. ENRP_TAKEOVER_SERVER message 2.9. ENRP_TAKEOVER_SERVER Message
The PEER_TAKEOVER_REGISTRAR message is sent by the takeover initiator The PEER_TAKEOVER_REGISTRAR message is sent by the takeover initiator
to declare the enforcement of a takeover to all active peer ENRP to declare the enforcement of a takeover to all active peer ENRP
servers. servers.
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 = 0x09 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x09 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 17 skipping to change at page 15, line 5
Receiving Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Targeting Server's ID: Targeting Server's ID:
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 operation. takeover operation.
2.10. ENRP_ERROR message 2.10. ENRP_ERROR Message
The ENRP_ERROR message is sent by a registrar to report an The ENRP_ERROR message is sent by a registrar to report an
operational error to a peer ENRP server. operational error to a peer 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x0a |0|0|0|0|0|0|0|0| Message Length | | Type = 0x0a |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sending Server's ID | | Sending Server's ID |
skipping to change at page 16, line 44 skipping to change at page 15, line 32
Sending Server's ID: Sending Server's ID:
See Section 2.1. See Section 2.1.
Receiving Server's ID: Receiving Server's ID:
See Section 2.1. See Section 2.1.
Operational Error Parameter: Operational Error Parameter:
This parameter, defined in [I-D.ietf-rserpool-common-param], This parameter, defined in [RFC5354], indicates the type of
indicates the type of error(s) being reported. error(s) 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 follow these procedures when sending, receiving, An ENRP server MUST follow these procedures when sending, receiving,
or processing ENRP messages. or processing ENRP messages.
Many of the RSerPool events call for both server-to-server and PU/ Many of the RSerPool events call for both server-to-server and 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 [I-D.ietf-rserpool-asap]. are defined in [RFC5352].
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
the pool membership changes, handlespace data synchronization, etc. the pool membership changes, handlespace data synchronization, etc.
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 exchanges from one ENPR server to a
peer server, and specific 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 sent out via "group-casts" over the ENRP server
channel. channel.
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 among all the ENRP servers in the operational as unique as possible among all the ENRP servers in the operational
scope and this server Id MUST remain unchanged for the lifetime of scope, and this server ID MUST remain unchanged for the lifetime of
the server. Normally, a good 32-bit random number will be good the server. Normally, a good 32-bit random number will be good
enough as the server Id ([RFC4086] provides some information on enough, as the server ID [RFC4086] provides some information on
randomness guidelines). 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 Note, the ENRP server ID space is separate from the PE Id space
defined in [I-D.ietf-rserpool-asap]. defined in [RFC5352].
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 (the initiating server) will first
learn all existing peer ENRP servers in the same operational scope, attempt to learn of all existing peer ENRP servers in the same
or to determine that it is alone in the scope. operational 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 one 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 MUST then use database, startup scripts, etc.), the initiating server MUST then use
this peer server as its mentor server. this peer server as its mentor server.
If multiple existing peer servers are specified, the initiating If multiple existing peer servers are specified, the initiating
server MUST pick one of them as its mentor server and keep the others server MUST pick one of them as its mentor server and keep the others
as its backup mentor servers. as its backup mentor servers.
If no existing peer server is specified, the initiating server MUST If no existing peer server is specified, the initiating server MUST
assume that it is alone in the operational scope, and MUST skip the assume that it is alone in the operational scope, and MUST skip the
procedures in Section 3.2.2.2 and Section 3.2.3 and MUST consider its procedures in Section 3.2.2.2 and Section 3.2.3 and MUST consider its
initialization completed and start offering ENRP services. 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.4 for maintaining server list). Section 3.4 for maintaining a 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 abandon the interaction with the current initiating server SHOULD abandon the interaction with the current
mentor server and send a new server list request to a backup mentor mentor server and send a new server list request to a backup mentor
peer, if one is available. 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
skipping to change at page 19, line 32 skipping to change at page 18, line 24
re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a re-send the ENRP_LIST_REQUEST to the mentor server, or if there is a
backup mentor peer available, select another mentor peer server and backup mentor peer available, select another mentor peer server and
send the ENRP_LIST_REQUEST to the new mentor server. send the ENRP_LIST_REQUEST to the new mentor server.
3.2.3. Download ENRP Handlespace Data from Mentor Peer 3.2.3. Download ENRP Handlespace Data from Mentor Peer
After a peer list download is completed, the initiating server MUST After a peer list download is completed, the initiating server MUST
request a copy of the current handlespace data from its mentor peer request a copy of the current handlespace data from its mentor peer
server, by taking the following steps: server, by taking the following steps:
1. The initiating server MUST first send a ENRP_HANDLE_TABLE_REQUEST 1. The initiating server MUST first send an
message to the mentor peer, with W flag set to '0', indicating ENRP_HANDLE_TABLE_REQUEST message to the mentor peer, with the W
that the entire handlespace is requested. flag set to '0', indicating that the entire handlespace is
requested.
2. Upon the reception of this message, the mentor peer MUST start a 2. Upon the reception of this message, the mentor peer MUST start a
download session in which a copy of the current handlespace data download session in which a copy of the current handlespace data
maintained by the mentor peer is sent to the initiating server in maintained by the mentor peer is sent to the initiating server in
one or more ENRP_HANDLE_TABLE_RESPONSE messages (Note, the mentor one or more ENRP_HANDLE_TABLE_RESPONSE messages. (Note, the
server may find it particularly desirable to use multiple mentor server may find it particularly desirable to use multiple
ENRP_HANDLE_TABLE_RESPONSE messages to send the handlespace when ENRP_HANDLE_TABLE_RESPONSE messages to send the handlespace when
the handlespace is large, especially when forming and sending out the handlespace is large, especially when forming and sending out
a single response containing a large handlespace may interrupt a single response containing a large handlespace may interrupt
its other services). its other services.)
If more than one ENRP_HANDLE_TABLE_RESPONSE message are used If more than one ENRP_HANDLE_TABLE_RESPONSE message is used
during the download, the mentor peer MUST use the M flag in each during the download, the mentor peer MUST use the M flag in each
ENRP_HANDLE_TABLE_RESPONSE message to indicate whether this ENRP_HANDLE_TABLE_RESPONSE message to indicate whether this
message is the last one for the download session. In particular, message is the last one for the download session. In particular,
the mentor peer MUST set the M flag to '1' in the outbound the mentor peer MUST set the M flag to '1' in the outbound
ENRP_HANDLE_TABLE_RESPONSE if there is more data to be ENRP_HANDLE_TABLE_RESPONSE if there is more data to be
transferred and MUST keep track of the progress of the current transferred and MUST keep track of the progress of the current
download session. The mentor peer MUST set the M flag to '0' in download session. The mentor peer MUST set the M flag to '0' in
the last ENRP_HANDLE_TABLE_RESPONSE for the download session and the last ENRP_HANDLE_TABLE_RESPONSE for the download session and
close the download session (i.e., removing any internal record of close the download session (i.e., removing any internal record of
the session) after sending out the last message. the session) after sending out the last message.
skipping to change at page 20, line 38 skipping to change at page 19, line 34
When creating the pool, the initiation server MUST set the When creating the pool, the initiation server MUST set the
overall member selection policy type of the pool to the overall member selection policy type of the pool to the
policy type indicated in the first PE. policy type indicated in the first PE.
B. If the pool already exists in the local handlespace, but the B. If the pool already exists in the local handlespace, but the
PE(s) in the pool entry is not currently a member of the PE(s) in the pool entry is not currently a member of the
pool, the initiating server MUST add the PE(s) to the pool. pool, the initiating server MUST add the PE(s) to the pool.
C. If the pool already exists in the local handlespace AND the C. If the pool already exists in the local handlespace AND the
PE(s) in the Pool entry is already a member of the pool, the PE(s) in the pool entry is already a member of the pool, the
initiating server SHOULD replace the attributes of the initiating server SHOULD replace the attributes of the
existing PE(s) with the new information. ENRP will make sure existing PE(s) with the new information. ENRP will make sure
that the information keeps up to date. that the information stays up to date.
5. When the last ENRP_HANDLE_TABLE_RESPONSE message is received from 5. When the last ENRP_HANDLE_TABLE_RESPONSE message is received from
the mentor peer and unpacked into the local handlespace, the the mentor peer and unpacked into the local handlespace, the
initialization process is completed and the initiating server initialization process is completed and the initiating server
SHOULD start to provide ENRP services. SHOULD start to provide ENRP services.
Under certain circumstances, the mentor peer itself may not be able Under certain circumstances, the mentor peer itself may not be able
to provide a handlespace download to the initiating server. For to provide a handlespace download to the initiating server. For
example, the mentor peer is in the middle of initializing its own example, the mentor peer is in the middle of initializing its own
handlespace database, or it has currently too many download sessions handlespace database, or it currently has too many download sessions
open to other servers. open to other servers.
In such a case, the mentor peer MUST reject the request by the In such a case, the mentor peer MUST reject the request by the
initiating server and respond with an ENRP_HANDLE_TABLE_RESPONSE initiating server and respond with an ENRP_HANDLE_TABLE_RESPONSE
message with the R flag set to '1', and with no pool entries included message with the R flag set to '1', and with no pool entries included
in the response. in the response.
In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the In the case where its ENRP_HANDLE_TABLE_REQUEST is rejected by the
mentor peer, the initiating server SHOULD either wait for a few mentor peer, the initiating server SHOULD either wait for a few
seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor seconds and re-send the ENRP_HANDLE_TABLE_REQUEST to the mentor
skipping to change at page 21, line 27 skipping to change at page 20, line 26
A handlespace download session that has been started may get A handlespace download session that has been started may get
interrupted for some reason. To cope with this, the initiating interrupted for some reason. To cope with this, the initiating
server SHOULD start a timer every time it finishes sending an server SHOULD start a timer every time it finishes sending an
ENRP_HANDLE_TABLE_REQUEST to its mentor peer. If this timer expires ENRP_HANDLE_TABLE_REQUEST to its mentor peer. If this timer expires
without receiving a response from the mentor peer, the initiating without receiving a response from the mentor peer, the initiating
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 setting the M-bit to '1' to indicate that it has more
send, it SHOULD start a session timer. If this timer expires without data to send, it SHOULD start a session timer. If this timer expires
receiving another request from the initiating server, the mentor peer without receiving another request from the initiating server, the
SHOULD abort the session, cleaning out any resource and record of the mentor peer SHOULD abort the session, cleaning out any resource and
session. record of the session.
3.3. Server Handlespace Update 3.3. 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.3.1. Announcing Addition or Update of PE 3.3.1. Announcing Additions or Updates 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
ADD_PE, indicating the addition of a new PE or the modification of an 'ADD_PE', indicating the addition of a new PE or the modification of
existing PE. The complete new information of the PE and the pool its an existing PE. The complete new information of the PE and the pool
belongs to MUST be indicated in the message with a PE parameter and a it belongs to MUST be indicated in the message with a PE parameter
Pool Handle parameter, respectively. and a Pool Handle parameter, respectively.
The home ENRP server SHOULD fill in its server Id in the Sending The Home ENRP server SHOULD fill in its server ID in the Sending
Server's ID field and leave the Receiving Server's ID blank (i.e., Server's ID field and leave the Receiving Server's ID blank (i.e.,
all 0's). all 0s).
When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take When a peer receives this ENRP_HANDLE_UPDATE message, it MUST take
the following actions: the following actions:
1. If the named pool indicated by the pool handle does not exist in 1. If the named pool indicated by the pool handle does not exist in
its local copy of the handlespace, the peer MUST create the named its local copy of the handlespace, the peer MUST create the named
pool in its local handlespace and add the PE to the pool as the pool in its local handlespace and add the PE to the pool as the
first PE. It MUST then copy in all other attributes of the PE first PE. It MUST then copy in all other attributes of the PE
carried in the message. carried in the message.
When the new pool is created, the overall member selection policy When the new pool is created, the overall member selection policy
of the pool MUST be set to the policy type indicated by the PE. of the pool MUST be set to the policy type indicated by the PE.
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.3.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 3.5 in [I-D.ietf-rserpool-asap]), the ENRP server MUST uses this see Section 3.5 in [RFC5352]), the ENRP server MUST use this
procedure to inform all its peers about the change just made. procedure to inform 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 peers 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 it belongs to MUST be indicated in
in the message with a PE parameter and a Pool Handle parameter, the message with a PE parameter and a Pool Handle parameter,
respectively. respectively.
The sending server MUST fill in its server ID in the Sending Server's The sending server MUST fill in its server ID in the Sending Server's
ID field and leave the Receiving Server's ID blank (i.e., set to all ID field and leave the Receiving Server's ID blank (i.e., set to all
0's). 0s).
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 the pool and the PE in its own handlespace, and then remove the
from its local handlespace. If the removed PE is the last one in the PE from its local handlespace. If the removed PE is the last one in
pool, the peer MUST also delete the pool from its local handlespace. the 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.4. Maintaining Peer List and Monitoring Peer Status 3.4. 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.4.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
skipping to change at page 24, line 7 skipping to change at page 23, line 15
3.4.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 the 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.5. and SHOULD initiate the takeover procedure defined in Section 3.5.
3.5. 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 takeover 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 the PE to continue to operate in case of a failure of their Home ENRP
server. server.
3.5.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 takeover arbitration
process by sending a ENRP_INIT_TAKEOVER message to all its peer process by sending an 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 (group-casting to all After announcing the ENRP_INIT_TAKEOVER message ("group-casting" to
known peers, including the target server), the initiating server all known peers, including the target server), the initiating server
SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from each of its SHOULD wait for an ENRP_INIT_TAKEOVER_ACK message from each of its
known peers, except of the target server. known peers, except that of the target server.
Each peer receiving an ENRP_INIT_TAKEOVER message from the initiating Each peer receiving an ENRP_INIT_TAKEOVER message from the initiating
server MUST 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 it (itself) is the target
indicated in the ENRP_INIT_TAKEOVER message, it MUST immediately server indicated in the ENRP_INIT_TAKEOVER message, it MUST
announce an ENRP_PRESENCE message to all its peer ENRP servers in immediately announce an ENRP_PRESENCE message to all its peer
an attempt to stop this take-over process. This indicates a ENRP servers in an attempt to stop this takeover process. This
false failure detection case by the initiating server. The indicates a false failure-detection case by the initiating
initiating server MUST stop the takeover operation by marking the server. The initiating server MUST stop the takeover operation
target server as "active" and taking no further takeover actions. 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 takeover 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 MUST immediately abort its own take-over attempt peer server MUST immediately abort its own take-over attempt
by taking no further takeover actions of its own. Moreover, by taking no further takeover actions of its own. Moreover,
the peer MUST mark the target server as "not active" on its the peer MUST mark the target server as "not active" on its
internal peer list so that its status will no longer be internal peer list so that its status will no longer be
monitored by the peer, and reply the initiating server with monitored by the peer, and reply to the initiating server
an ENRP_INIT_TAKEOVER_ACK message. 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. 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 MUST: a) mark the target its own takeover 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) MUST status will no longer be monitored by this peer, and b) MUST
reply to the initiating server with an ENRP_INIT_TAKEOVER_ACK reply to the initiating server with an ENRP_INIT_TAKEOVER_ACK
message. message.
Once the initiating server has received the 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 target message from all of its currently known peers (except for the target
server), it MUST consider that it has won the arbitration and MUST server), it MUST consider that it has won the arbitration and MUST
proceed to complete the take-over, following the steps described in proceed to complete the takeover, following the steps described in
Section 3.5.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 stop the take-over process and mark the status of the immediately stop the takeover process and mark the status of the
target server as "active". target server as "active".
3.5.2. Take-over Target Peer Server 3.5.2. Takeover Target Peer Server
The initiating ENRP server MUST first send, via an announcement, an 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 takeover has been enforced. The target server's ID MUST be filled in
message. The initiating server SHOULD then remove the target server the message. The initiating server SHOULD then remove the target
from its internal peer list. server 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, with the 2. send a point-to-point ASAP_ENDPOINT_KEEP_ALIVE message, with the
'H' flag set to '1', to each of the PEs. This will trigger the 'H' flag set to '1', to each of the PEs. This will trigger the
PE to adopt the initiating sever 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.
3.6. 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.6.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 that should be the same is exchanged to
figure out if the data is the same or not. figure out whether or not the data is the same.
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 16-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.6.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 it
take no further actions. should 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.6.3). immediately with server B (see Section 3.6.3).
3.6.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) calculates 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
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 16-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
Internet algorithm described in [RFC1071]. Internet algorithm described in [RFC1071].
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/de-registration, 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.
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 need not
to re-calculate the affected PE checksum; it can instead simply re-calculate the affected PE checksum; it can instead simply update
update the checksum by adding or subtracting the byte block of the 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.6.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 regard to
to the PEs owned by that peer, it MUST perform the following steps 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
message with W flag set to '1' to the peer to request a complete message with the W flag set to '1' to the peer to request a
list of PEs owned by the peer; complete list of PEs owned by the peer;
3. Upon reception of the ENRP_HANDLE_TABLE_REQUEST message with W 3. Upon reception of the ENRP_HANDLE_TABLE_REQUEST message with the
flag set to '1', the peer server SHOULD immediately respond with W flag set to '1', the peer server SHOULD immediately respond
an ENRP_HANDLE_TABLE_RESPONSE message listing all PEs currently with an ENRP_HANDLE_TABLE_RESPONSE message listing all PEs
owned by the peer. currently owned by the peer.
4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the 4. Upon reception of the ENRP_HANDLE_TABLE_RESPONSE message, the
ENRP server SHOULD transfer the PE entries carried in the message ENRP server SHOULD transfer the PE entries carried in the message
into its local handlespace database. If an PE entry being into its local handlespace database. If a PE entry being
transferred already exists in its local database, the ENRP server transferred already exists in its local database, the ENRP server
MUST replace the entry with the copy found in the message and MUST replace the entry with the copy found in the message and
remove the "mark" from the entry. remove the "mark" from the entry.
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.7. Handling Unrecognized Message or Unrecognized Parameter 3.7. Handling Unrecognized Messages or Unrecognized Parameters
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 [I-D.ietf-rserpool-common-param]. defined in Sections 3 and 4 in [RFC5354].
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 a 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 group-cast 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 16-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
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.)
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.)
5. IANA Considerations 5. IANA Considerations
[NOTE to RFC-Editor: This document (RFC 5353) is the reference for all registrations
described in this section. All registrations have been listed on the
"RFCXXXX" is to be replaced by the RFC number you assign this RSerPool Parameters page.
document.
]
This document (RFCXXX) is the reference for all registrations
described in this section. All registrations need to be listed on an
RSerPool specific page.
5.1. A New Table for ENRP Message Types 5.1. A New Table for ENRP Message Types
ENRP Message Types have to be maintained by IANA. Ten initial values ENRP Message Types are maintained by IANA. Ten initial values have
should be assigned by IANA as described in Figure 1. This requires a been assigned by IANA, as described in Figure 1. IANA created a new
new table "ENRP Message Types": table, "ENRP Message Types":
Type Message Name Reference Type Message Name Reference
----- ------------------------- --------- ----- ------------------------- ---------
0x00 (reserved by IETF) RFCXXXX 0x00 (Reserved by IETF) RFC 5353
0x01 ENRP_PRESENCE RFCXXXX 0x01 ENRP_PRESENCE RFC 5353
0x02 ENRP_HANDLE_TABLE_REQUEST RFCXXXX 0x02 ENRP_HANDLE_TABLE_REQUEST RFC 5353
0x03 ENRP_HANDLE_TABLE_RESPONSE RFCXXXX 0x03 ENRP_HANDLE_TABLE_RESPONSE RFC 5353
0x04 ENRP_HANDLE_UPDATE RFCXXXX 0x04 ENRP_HANDLE_UPDATE RFC 5353
0x05 ENRP_LIST_REQUEST RFCXXXX 0x05 ENRP_LIST_REQUEST RFC 5353
0x06 ENRP_LIST_RESPONSE RFCXXXX 0x06 ENRP_LIST_RESPONSE RFC 5353
0x07 ENRP_INIT_TAKEOVER RFCXXXX 0x07 ENRP_INIT_TAKEOVER RFC 5353
0x08 ENRP_INIT_TAKEOVER_ACK RFCXXXX 0x08 ENRP_INIT_TAKEOVER_ACK RFC 5353
0x09 ENRP_TAKEOVER_SERVER RFCXXXX 0x09 ENRP_TAKEOVER_SERVER RFC 5353
0x0a ENRP_ERROR RFCXXXX 0x0a ENRP_ERROR RFC 5353
0x0b-0xff (reserved by IETF) RFCXXXX 0x0b-0xff (Available for assignment) RFC 5353
For registering at IANA an ENRP Message Type in this table a request Requests to register an ENRP Message Type in this table should be
has to be made to assign such a number. This number must be unique. sent to IANA. The number must be unique. The "Specification
The "Specification Required" policy of [RFC5226] MUST be applied. Required" policy of [RFC5226] MUST be applied.
5.2. A New Table for Update Action Types 5.2. A New Table for Update Action Types
Update Types have to be maintained by IANA. Two initial values Update Types are maintained by IANA. Two initial values have been
should be assigned by IANA. This requires a new table "Update Action assigned by IANA. IANA created a new table, "Update Action Types":
Types":
Type Update Action Reference Type Update Action Reference
------------- -------------------- --------- ------------- -------------------- ---------
0x0000 ADD_PE RFCXXXX 0x0000 ADD_PE RFC 5353
0x0001 DEL_PE RFCXXXX 0x0001 DEL_PE RFC 5353
0x0002-0xffff (reserved by IETF) RFCXXXX 0x0002-0xffff (Available for assignment) RFC 5353
For registering at IANA an Update Action Type in this table a request Requests to register an Update Action Type in this table should be
has to be made to assign such a number. This number must be unique. sent to IANA. The number must be unique. The "Specification
The "Specification Required" policy of [RFC5226] MUST be applied. Required" policy of [RFC5226] MUST be applied.
5.3. Port numbers 5.3. Port Numbers
The references for the already assigned port numbers The references for the already assigned port numbers
enrp-udp 9901/udp enrp-udp 9901/udp
enrp-sctp 9901/sctp enrp-sctp 9901/sctp
enrp-sctp-tls 9902/sctp enrp-sctp-tls 9902/sctp
should be updated to RFCXXXX. have been updated to RFC 5353.
5.4. SCTP payload protocol identifier 5.4. SCTP Payload Protocol Identifier
The reference for the already assigned ENRP payload protocol The reference for the already assigned ENRP payload protocol
identifier 12 should be updated to RFCXXXX. identifier 12 have been updated to RFC 5353.
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.
6.1. Summary of Rserpool Security Threats 6.1. Summary of RSerPool Security Threats
Threats Introduced by RSerPool and Requirements for Security in "Threats Introduced by Reliable Server Pooling (RSerPool) and
Response to Threats [I-D.ietf-rserpool-threats] describes the threats Requirements for Security in Response to Threats" [RFC5355] describes
to the RSerPool architecture in detail lists the security the threats to the RSerPool architecture in detail and lists the
requirements in response to each threat. From the threats described security requirements in response to each threat. From the threats
in this document, the security services required for the RSerPool described in this document, the security services required for the
protocol are enumerated below. RSerPool protocol are enumerated below.
Threat 1) PE registration/deregistration flooding or spoofing Threat 1) PE registration/de-registration flooding or spoofing
----------- -----------
Security mechanism in response: ENRP server authenticates the PE Security mechanism in response: ENRP server authenticates the PE.
Threat 2) PE registers with a malicious ENRP server Threat 2) PE registers with a malicious ENRP server
----------- -----------
Security mechanism in response: PE authenticates the ENRP server Security mechanism in response: PE authenticates the ENRP server.
Threat 1 and 2 taken together results in mutual authentication of the Threats 1 and 2, taken together, result in mutual authentication of
ENRP server and the PE. the ENRP server and the PE.
Threat 3) Malicious ENRP server joins the ENRP server pool Threat 3) Malicious ENRP server joins the ENRP server pool
----------- -----------
Security mechanism in response: ENRP servers mutually authenticate Security mechanism in response: ENRP servers mutually authenticate.
Threat 4) A PU communicates with a malicious ENRP server for handle Threat 4) A PU communicates with a malicious ENRP server for handle
resolution resolution
----------- -----------
Security mechanism in response: The PU authenticates the ENRP server Security mechanism in response: The PU authenticates the ENRP server.
Threat 5) Replay attack Threat 5) Replay attack
----------- -----------
Security mechanism in response: Security protocol which has Security mechanism in response: Security protocol that has protection
protection from replay attacks from replay attacks.
Threat 6) Corrupted data which causes a PU to have misinformation Threat 6) Corrupted data that causes a PU to have misinformation
concerning a pool handle resolution concerning a pool handle resolution
----------- -----------
Security mechanism in response: Security protocol which supports Security mechanism in response: Security protocol that supports
integrity protection integrity protection
Threat 7) Eavesdropper snooping on handlespace information Threat 7) Eavesdropper snooping on handlespace information
----------- -----------
Security mechanism in response: Security protocol which supports data Security mechanism in response: Security protocol that supports data
confidentiality confidentiality.
Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to Threat 8) Flood of ASAP_ENDPOINT_UNREACHABLE messages from the PU to
ENRP server ENRP server
----------- -----------
Security mechanism in response: ASAP must control the number of ASAP Security mechanism in response: ASAP must control the number of ASAP
endpoint unreachable messages transmitted from the PU to the ENRP endpoint unreachable messages transmitted from the PU to the ENRP
server. server.
Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from Threat 9) Flood of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE from
the ENRP server the ENRP server
----------- -----------
Security mechanism in response: ENRP server must control the number Security mechanism in response: ENRP server must control the number
of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE of ASAP_ENDPOINT_KEEP_ALIVE messages to the PE.
To summarize the threats 1-7 require security mechanisms which To summarize, threats 1-7 require security mechanisms that support
support authentication, integrity, data confidentiality, protection authentication, integrity, data confidentiality, and protection from
from replay attacks. replay attacks.
For RSerPool we need to authenticate the following: For RSerPool, we need to authenticate the following:
PU <---- ENRP Server (PU authenticates the ENRP server) PU <---- ENRP server (PU authenticates the ENRP server)
PE <----> ENRP Server (mutual authentication) PE <----> ENRP server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication) ENRP server <-----> ENRP server (mutual authentication)
6.2. Implementing Security Mechanisms 6.2. Implementing Security Mechanisms
We do not define any new security mechanisms specifically for We do not define any new security mechanisms specifically for
responding to threats 1-7. Rather we use an existing IETF security responding to threats 1-7. Rather, we use an existing IETF security
protocol, specifically [RFC3237], to provide the security services protocol, specifically [RFC3237], to provide the security services
required. TLS supports all these requirements and MUST be required. TLS supports all these requirements and MUST be
implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be implemented. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be
supported at a minimum by implementors of TLS for Rserpool. For supported, at a minimum, by implementers of TLS for RSerPool. For
purposes of backwards compatibility, ENRP SHOULD support purposes of backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other IETF approved ciphersuites. other IETF-approved ciphersuites.
ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs MUST ENRP servers, PEs, and PUs MUST implement TLS. ENRP servers and PEs
support mutual authentication using PSK. ENRP servers MUST support MUST support mutual authentication using PSK. ENRP servers MUST
mutual authentication among themselves using PSK. PUs MUST support mutual authentication among themselves using PSK. PUs MUST
authenticate ENRP servers using certificates. authenticate ENRP servers using certificates.
TLS with PSK is mandatory to implement as the authentication TLS with PSK is mandatory to implement as the authentication
mechanism for ENRP to ENRP authentication and PE to ENRP mechanism for ENRP to ENRP authentication and PE to ENRP
authentication. For PSK, having a pre-shared-key constitutes authentication. For PSK, having a pre-shared-key constitutes
authorization.The network administrators of a pool need to decide authorization. The network administrators of a pool need to decide
which nodes are authorized to participate in the pool. The which nodes are authorized to participate in the pool. The
justification for PSK is that we assume that one administrative justification for PSK is that we assume that one administrative
domain will control and manage the server pool. This allows for PSK domain will control and manage the server pool. This allows for PSK
to be implemented and managed by a central security administrator. to be implemented and managed by a central security administrator.
TLS with certificates is mandatory to implement as the authentication TLS with certificates is mandatory to implement as the authentication
mechanism for PU to ENRP server. PUs MUST autnthenticate ENRP mechanism for PUs to the ENRP server. PUs MUST authenticate ENRP
servers using certificates. ENRP servers MUST possess a site servers using certificates. ENRP servers MUST possess a site
certificate whose subject corresponds to their canonical hostname. certificate whose subject corresponds to their canonical hostname.
PUs MAY have certificates of their own for mutual authentication with PUs MAY have certificates of their own for mutual authentication with
TLS, but no provisions are set forth in this document for their use. TLS, but no provisions are set forth in this document for their use.
All Rserpool elements that support TLS MUST have a mechanism for All RSerPool elements that support TLS MUST have a mechanism for
validating certificates received during TLS negotiation; this entails validating certificates received during TLS negotiation; this entails
possession of one or more root certificates issued by certificate possession of one or more root certificates issued by certificate
authorities (preferably well-known distributors of site certificates authorities (preferably, well-known distributors of site certificates
comparable to those that issue root certificates for web browsers). comparable to those that issue root certificates for web browsers).
In order to prevent man-in-the-middle attacks, the client MUST verify In order to prevent man-in-the-middle attacks, the client MUST verify
the server's identity (as presented in the server's Certificate the server's identity (as presented in the server's Certificate
message). The client's understanding of the server's identity message). The client's understanding of the server's identity
(typically the identity used to establish the transport connection) (typically the identity used to establish the transport connection)
is called the "reference identity". The client determines the type is called the "reference identity". The client determines the type
(e.g., DNS name or IP address) of the reference identity and performs (e.g., DNS name or IP address) of the reference identity and performs
a comparison between the reference identity and each subjectAltName a comparison between the reference identity and each subjectAltName
value of the corresponding type until a match is produced. Once a value of the corresponding type until a match is produced. Once a
match is produced, the server's identity has been verified, and the match is produced, the server's identity has been verified, and the
server identity check is complete. Different subjectAltName types server identity check is complete. Different subjectAltName types
are matched in different ways. The client may map the reference are matched in different ways. The client may map the reference
identity to a different type prior to performing a comparison. identity to a different type prior to performing a comparison.
Mappings may be performed for all available subjectAltName types to Mappings may be performed for all available subjectAltName types to
which the reference identity can be mapped; however, the reference which the reference identity can be mapped; however, the reference
identity should only be mapped to types for which the mapping is identity should only be mapped to types for which the mapping is
either inherently secure (e.g., extracting the DNS name from a URI to either inherently secure (e.g., extracting the DNS name from a URI to
compare with a subjectAltName of type dNSName) or for which the compare with a subjectAltName of type dNSName) or for which the
mapping is performed in a secure manner (e.g., using DNSSEC, or using mapping is performed in a secure manner (e.g., using DNS Security
user- or admin-configured host- to-address/address-to-host lookup (DNSSEC), or using user- or admin-configured host-to-address/
tables).. address-to-host lookup tables).
If the server identity check fails, user-oriented clients SHOULD If the server identity check fails, user-oriented clients SHOULD
either notify the user or close the transport connection and indicate either notify the user or close the transport connection and indicate
that the server's identity is suspect. Automated clients SHOULD that the server's identity is suspect. Automated clients SHOULD
close the transport connection and then return or log an error close the transport connection and then return or log an error
indicating that the server's identity is suspect or both. Beyond the indicating that the server's identity is suspect, or both. Beyond
server identity check described in this section, clients should be the server identity check described in this section, clients should
prepared to do further checking to ensure that the server is be prepared to do further checking to ensure that the server is
authorized to provide the service it is requested to provide. The authorized to provide the service it is requested to provide. The
client may need to make use of local policy information in making client may need to make use of local policy information in making
this determination. this determination.
If the reference identity is an internationalized domain name, If the reference identity is an internationalized domain name,
conforming implementations MUST convert it to the ASCII Compatible conforming implementations MUST convert it to the ASCII Compatible
Encoding (ACE) format as specified in Section 4 of [RFC3490] before Encoding (ACE) format, as specified in Section 4 of [RFC3490], before
comparison with subjectAltName values of type dNSName. Specifically, comparison with subjectAltName values of type dNSName. Specifically,
conforming implementations MUST perform the conversion operation conforming implementations MUST perform the conversion operation
specified in Section 4 of [RFC3490] as follows: * in step 1, the specified in Section 4 of [RFC3490] as follows: * in step 1, the
domain name SHALL be considered a "stored string"; * in step 3, set domain name SHALL be considered a "stored string"; * in step 3, set
the flag called "UseSTD3ASCIIRules"; * in step 4, process each label the flag called "UseSTD3ASCIIRules"; * in step 4, process each label
with the "ToASCII" operation; and * in step 5, change all label with the "ToASCII" operation; and * in step 5, change all label
separators to U+002E (full stop). separators to U+002E (full stop).
After performing the "to-ASCII" conversion, the DNS labels and names After performing the "to-ASCII" conversion, the DNS labels and names
MUST be compared for equality according to the rules specified in MUST be compared for equality according to the rules specified in
Section 3 of RFC3490. The '*' (ASCII 42) wildcard character is Section 3 of RFC 3490. The '*' (ASCII 42) wildcard character is
allowed in subjectAltName values of type dNSName, and then only as allowed in subjectAltName values of type dNSName, and then, only as
the left-most (least significant) DNS label in that value. This the left-most (least significant) DNS label in that value. This
wildcard matches any left-most DNS label in the server name. That wildcard matches any left-most DNS label in the server name. That
is, the subject *.example.com matches the server names a.example.com is, the subject *.example.com matches the server names a.example.com
and b.example.com, but does not match example.com or a.b.example.com. and b.example.com, but does not match example.com or a.b.example.com.
When the reference identity is an IP address, the identity MUST be When the reference identity is an IP address, the identity MUST be
converted to the "network byte order" octet string representation RFC converted to the "network byte order" octet string representation RFC
791[RFC0791][RFC2460][RFC2460]. For IP Version 4, as specified in 791 [RFC0791] and RFC 2460 [RFC2460]. For IP version 4, as specified
RFC 791, the octet string will contain exactly four octets. For IP in RFC 791, the octet string will contain exactly four octets. For
Version 6, as specified in RFC 2460, the octet string will contain IP version 6, as specified in RFC 2460, the octet string will contain
exactly sixteen octets. This octet string is then compared against exactly sixteen octets. This octet string is then compared against
subjectAltName values of type iPAddress. A match occurs if the subjectAltName values of type iPAddress. A match occurs if the
reference identity octet string and value octet strings are reference identity octet string and value octet strings are
identical. identical.
After a TLS layer is established in an session, both parties are to After a TLS layer is established in a session, both parties are to
each independently decide whether or not to continue based on local independently decide whether or not to continue based on local policy
policy and the security level achieved. If either party decides that and the security level achieved. If either party decides that the
the security level is inadequate for it to continue, it SHOULD remove security level is inadequate for it to continue, it SHOULD remove the
the TLS layer immediately after the TLS (re)negotiation has completed TLS layer immediately after the TLS (re)negotiation has completed
(see RFC4511)[RFC4511]. Implementations may reevaluate the security (see RFC 4511)[RFC4511]. Implementations may re-evaluate the
level at any time and, upon finding it inadequate, should remove the security level at any time and, upon finding it inadequate, should
TLS layer. remove the TLS layer.
Implementations MUST support TLS with SCTP as described in [RFC3436] Implementations MUST support TLS with SCTP, as described in [RFC3436]
or TLS over TCP as described in [RFC4346]. When using TLS/SCTP we or TLS over TCP, as described in [RFC5246]. When using TLS/SCTP we
must ensure that RSerPool does not use any features of SCTP that are must ensure that RSerPool does not use any features of SCTP that are
not available to an TLS/SCTP user. This is not a difficult technical not available to a TLS/SCTP user. This is not a difficult technical
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 also have 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 this document) ASAP_ENDPOINT_UNREACHABLE messages (see Section 3.5 of RFC 5352) to
to the ENRP server. the 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. ASAP_ENDPOINT_KEEP_ALIVE messages from the ENRP server to the PE.
There is no security mechanism defined for the multicast There is no security mechanism defined for the multicast
announcements. Therefore a receiver of such an announcement can not announcements. Therefore, a receiver of such an announcement cannot
consider the source address of such a message to be a trustworthy consider the source address of such a message to be a trustworthy
address of an ENRP server. A receiver must also be prepared to address of an ENRP server. A receiver must also be prepared to
receive a large number of multicast announcements from attackers. receive a large number of multicast announcements from attackers.
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 the ENRP server. We define an ENRP
that uses TLS for all communication and authenticates ENRP peers and server that uses TLS for all communication and authenticates ENRP
PE registrants to be a secured ENRP server. peers and 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
the security. the security.
PU <---> secured ENRP Server (authentication of ENRP server; PU <---> secured ENRP server (authentication of ENRP server;
queries over TLS) queries over TLS)
PE <---> secured ENRP server (mutual authentication; PE <---> secured ENRP server (mutual authentication;
registration/deregistration over TLS) registration/de-registration over TLS)
secured ENRP server <---> secured ENRP server (mutual authentication; secured ENRP server <---> secured ENRP server (mutual authentication;
database updates using TLS) database updates using TLS)
If all components of the system authenticate and communicate using If all components of the system authenticate and communicate using
TLS, the chain of trust is sound. The root of the trust chain is the TLS, the chain of trust is sound. The root of the trust chain is the
ENRP server. If that is secured using TLS, then security will be ENRP server. If that is secured using TLS, then security will be
enforced for all ENRP and PE components that try to connect to it. enforced for all ENRP and PE components that try to connect to it.
Summary of interaction between secured and unsecured components: If Summary of interaction between secured and unsecured components: If
the PE does not use TLS and tries to register with a secure ENRP the PE does not use TLS and tries to register with a secure ENRP
server, it will receive an error message response indicated as error server, it will receive an error message response indicated as an
due to security considerations and the registration will be rejected. error due to security considerations and the registration will be
If an ENRP server which does not use TLS tries to update the database rejected. If an ENRP server that does not use TLS tries to update
of a secure ENRP server, then the update will be rejected. If an PU the database of a secure ENRP server, then the update will be
does not use TLS and communicates with a secure ENRP server, it will rejected. If a PU does not use TLS and communicates with a secure
get a response with the understanding that the response is not secure ENRP server, it will get a response with the understanding that the
as the response can be tampered with in transit even if the ENRP response is not secure, as the response can be tampered with in
database is secured. transit even if the ENRP database is secured.
The final case is the PU sending a secure request to ENRP. It might The final case is the PU sending a secure request to ENRP. It might
be that ENRP and PEs are not secured and this is an allowable be that ENRP and PEs are not secured and this is an allowable
configuration. The intent is to secure the communication over the configuration. The intent is to secure the communication over the
Internet between the PU and the ENRP server. Internet between the PU and the ENRP server.
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
skipping to change at page 39, line 9 skipping to change at page 36, line 9
7. Acknowledgments 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, Frank Volkmer, and many others for their invaluable Thomas Dreibholz, Frank Volkmer, and many others for their invaluable
comments and feedback. comments and feedback.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071,
September 1988.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
Requirement Levels", BCP 14, RFC 2119, March 1997. "Computing the Internet checksum", RFC 1071,
September 1988.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
(IPv6) Specification", RFC 2460, December 1998. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
Loughney, J., and M. Stillman, "Requirements for Reliable 6 (IPv6) Specification", RFC 2460, December 1998.
Server Pooling", RFC 3237, January 2002.
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L.,
Layer Security over Stream Control Transmission Protocol", Loughney, J., and M. Stillman, "Requirements for
RFC 3436, December 2002. Reliable Server Pooling", RFC 3237, January 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
"Internationalizing Domain Names in Applications (IDNA)", Layer Security over Stream Control Transmission
RFC 3490, March 2003. Protocol", RFC 3436, December 2002.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
(TLS) Protocol Version 1.1", RFC 4346, April 2006. "Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
(LDAP): The Protocol", RFC 4511, June 2006. (LDAP): The Protocol", RFC 4511, June 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 5226, an IANA Considerations Section in RFCs", BCP 26,
May 2008. RFC 5226, May 2008.
[I-D.ietf-rserpool-common-param] [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, Security (TLS) Protocol Version 1.2", RFC 5246,
"Aggregate Server Access Protocol (ASAP) and Endpoint August 2008.
Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-17 (work in progress),
May 2008.
[I-D.ietf-rserpool-asap] [RFC5354] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, "Aggregate Server Access Protocol (ASAP) and Endpoint
"Aggregate Server Access Protocol (ASAP)", Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-asap-20 (work in progress), May 2008. RFC 5354, September 2008.
[I-D.ietf-rserpool-threats] [RFC5352] Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. "Aggregate Server Access Protocol (ASAP)", RFC 5352,
Sengodan, "Threats Introduced by RSerPool and Requirements September 2008.
for Security in Response to Threats",
draft-ietf-rserpool-threats-15 (work in progress),
July 2008.
[I-D.ietf-tsvwg-sctpsocket] [RFC5355] Stillman, M., Ed., Gopal, R., Guttman, E., Holdrege,
Stewart, R., Xie, Q., Corp, T., Poon, K., Tuexen, M., and M., and S. Sengodan, "Threats Introduced by Reliable
V. Yasevich, "Sockets API Extensions for Stream Control Server Pooling (RSerPool) and Requirements for Security
Transmission Protocol (SCTP)", in Response to Threats", RFC 5355, September 2008.
draft-ietf-tsvwg-sctpsocket-16 (work in progress),
February 2008.
8.2. Informative References 8.2. Informative References
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] 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.
[SCTPSOCKET] Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P.
Lei, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)", Work in Progress,
July 2008.
Authors' Addresses Authors' Addresses
Qiaobing Xie Qiaobing Xie
The Resource Group
1700 Pennsylvania Ave NW
Suite 560
Washington, D.C., 20006
USA USA
Phone: +1 224-465-5954 Phone: +1 224-465-5954
Email: Qiaobing.Xie@gmail.org EMail: Qiaobing.Xie@gmail.com
Randall R. Stewart Randall R. Stewart
4875 Forest Drive The Resource Group
Suite 200 1700 Pennsylvania Ave NW
Columbia, SC 29206 Suite 560
Washington, D.C., 20006
USA USA
Phone: Phone:
Email: randall@lakerest.net EMail: randall@lakerest.net
Maureen Stillman Maureen Stillman
Nokia Nokia
127 W. State Street 1167 Peachtree Ct.
Ithaca, NY 14850 Naperville, IL 60540
US US
Phone: Phone:
Email: maureen.stillman@nokia.com EMail: maureen.stillman@nokia.com
Michael Tuexen Michael Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
Email: tuexen@fh-muenster.de EMail: tuexen@fh-muenster.de
Aron J. Silverton Aron J. Silverton
Motorola, Inc. Sun Microsystems, Inc.
1301 E. Algonquin Road 10 S. Wacker Drive
Room 2246 Suite 2000
Schaumburg, IL 60196 Chicago, IL 60606
USA USA
Phone: +1 847-576-8747 Phone:
Email: aron.j.silverton@motorola.com EMail: ajs.ietf@gmail.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 215 change blocks. 
480 lines changed or deleted 455 lines changed or added

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