draft-ietf-rserpool-enrp-19.txt   draft-ietf-rserpool-enrp-20.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
Internet-Draft Motorola Internet-Draft R. Stewart
Intended status: Experimental R. Stewart Intended status: Experimental
Expires: September 29, 2008 Cisco Systems, Inc. Expires: November 30, 2008 M. Stillman
M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
Muenster Univ. of Applied Sciences Muenster Univ. of Applied Sciences
A. Silverton A. Silverton
Motorola, Inc. Motorola, Inc.
March 28, 2008 May 29, 2008
Endpoint Handlespace Redundancy Protocol (ENRP) Endpoint Handlespace Redundancy Protocol (ENRP)
draft-ietf-rserpool-enrp-19.txt draft-ietf-rserpool-enrp-20.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 29, 2008. This Internet-Draft will expire on November 30, 2008.
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
skipping to change at page 3, line 22 skipping to change at page 3, line 22
5.4. SCTP payload protocol identifier . . . . . . . . . . . . . 31 5.4. SCTP payload protocol identifier . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 32 6.1. Summary of Rserpool Security Threats . . . . . . . . . . . 32
6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 33 6.2. Implementing Security Mechanisms . . . . . . . . . . . . . 33
6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 34 6.3. Chain of trust . . . . . . . . . . . . . . . . . . . . . . 34
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . . 37 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . . 38 8.2. Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . . . . 40
1. Introduction 1. Introduction
ENRP is designed to work in conjunction with ASAP ENRP is designed to work in conjunction with ASAP
[I-D.ietf-rserpool-asap] to accomplish the functionality of RSerPool [I-D.ietf-rserpool-asap] to accomplish the functionality of RSerPool
as defined by its requirements [RFC3237]. as defined by its 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
skipping to change at page 5, line 28 skipping to change at page 5, line 28
time and both the PE and its home ENRP server MUST keep track of time and both the PE and its home ENRP server MUST keep track of
this master/slave relationship between them. A PU SHOULD select this master/slave relationship between them. A PU SHOULD select
one of the available ENRP servers as its home ENRP server, but the one of the available ENRP servers as its home ENRP server, but the
ENRP server does not need to know, nor does it need to keep track ENRP server does not need to know, nor does it need to keep track
of this relationship. of this relationship.
1.2. Conventions 1.2. Conventions
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 [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 [I-D.ietf-rserpool-asap]. A
common format, that is defined in [I-D.ietf-rserpool-common-param], common format, that is defined in [I-D.ietf-rserpool-common-param],
is used for all ENRP and ASAP messages. is used for all ENRP and ASAP messages.
skipping to change at page 9, line 36 skipping to change at page 9, line 36
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 it 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 header
in number of octets. in number of octets.
Note, the value in Message Length field will NOT cover any Note, the value in Message Length field will NOT cover any
skipping to change at page 11, line 42 skipping to change at page 11, line 42
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 0's by sender and ignored by the
receiver. receiver.
Sending Server's ID: Sending Server's ID:
See Section 2.1. See Section 2.1.
skipping to change at page 17, line 51 skipping to change at page 17, line 51
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 [RFC4086] provides some information enough as the server Id ([RFC4086] provides some information on
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 [I-D.ietf-rserpool-asap].
3.2.2. Acquire Peer Server List 3.2.2. Acquire Peer Server List
skipping to change at page 30, line 41 skipping to change at page 30, line 41
0x05 ENRP_LIST_REQUEST RFCXXXX 0x05 ENRP_LIST_REQUEST RFCXXXX
0x06 ENRP_LIST_RESPONSE RFCXXXX 0x06 ENRP_LIST_RESPONSE RFCXXXX
0x07 ENRP_INIT_TAKEOVER RFCXXXX 0x07 ENRP_INIT_TAKEOVER RFCXXXX
0x08 ENRP_INIT_TAKEOVER_ACK RFCXXXX 0x08 ENRP_INIT_TAKEOVER_ACK RFCXXXX
0x09 ENRP_TAKEOVER_SERVER RFCXXXX 0x09 ENRP_TAKEOVER_SERVER RFCXXXX
0x0a ENRP_ERROR RFCXXXX 0x0a ENRP_ERROR RFCXXXX
0x0b-0xff (reserved by IETF) RFCXXXX 0x0b-0xff (reserved by IETF) RFCXXXX
For registering at IANA an ENRP Message Type in this table a request For registering at IANA an ENRP Message Type in this table a request
has to be made to assign such a number. This number must be unique. has to be made to assign such a number. This number must be unique.
The "Specification Required" policy of RFC2434 [RFC2434] MUST be The "Specification Required" policy of [RFC5226] MUST be applied.
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 have to be maintained by IANA. Two initial values
should be assigned by IANA. This requires a new table "Update Action should be assigned by IANA. This requires a new table "Update Action
Types": Types":
Type Update Action Reference Type Update Action Reference
------------- -------------------- --------- ------------- -------------------- ---------
0x0000 ADD_PE RFCXXXX 0x0000 ADD_PE RFCXXXX
0x0001 DEL_PE RFCXXXX 0x0001 DEL_PE RFCXXXX
0x0002-0xffff (reserved by IETF) RFCXXXX 0x0002-0xffff (reserved by IETF) RFCXXXX
For registering at IANA an Update Action Type in this table a request For registering at IANA an Update Action Type in this table a request
has to be made to assign such a number. This number must be unique. has to be made to assign such a number. This number must be unique.
The "Specification Required" policy of RFC2434 [RFC2434] MUST be The "Specification Required" policy of [RFC5226] MUST be applied.
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
skipping to change at page 37, line 16 skipping to change at page 37, line 16
8.1. Normative References 8.1. Normative References
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer,
"Computing the Internet checksum", RFC 1071, "Computing the Internet checksum", RFC 1071,
September 1988. September 1988.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L.,
Loughney, J., and M. Stillman, "Requirements for Reliable Loughney, J., and M. Stillman, "Requirements for Reliable
Server Pooling", RFC 3237, January 2002. Server Pooling", RFC 3237, January 2002.
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission Protocol", Layer Security over Stream Control Transmission Protocol",
RFC 3436, December 2002. RFC 3436, December 2002.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[I-D.ietf-rserpool-common-param] [I-D.ietf-rserpool-common-param]
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) and Endpoint
Handlespace Redundancy Protocol (ENRP) Parameters", Handlespace Redundancy Protocol (ENRP) Parameters",
draft-ietf-rserpool-common-param-16 (work in progress), draft-ietf-rserpool-common-param-16 (work in progress),
March 2008. March 2008.
[I-D.ietf-rserpool-asap] [I-D.ietf-rserpool-asap]
Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
"Aggregate Server Access Protocol (ASAP)", "Aggregate Server Access Protocol (ASAP)",
draft-ietf-rserpool-asap-18 (work in progress), draft-ietf-rserpool-asap-19 (work in progress),
November 2007. March 2008.
[I-D.ietf-rserpool-threats] [I-D.ietf-rserpool-threats]
Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S. Stillman, M., Gopal, R., Guttman, E., Holdrege, M., and S.
Sengodan, "Threats Introduced by RSerPool and Requirements Sengodan, "Threats Introduced by RSerPool and Requirements
for Security in Response to Threats", for Security in Response to Threats",
draft-ietf-rserpool-threats-09 (work in progress), draft-ietf-rserpool-threats-12 (work in progress),
October 2007. May 2008.
[I-D.ietf-tsvwg-sctpsocket] [I-D.ietf-tsvwg-sctpsocket]
Stewart, R., Xie, Q., Corp, T., Poon, K., Tuexen, M., and Stewart, R., Xie, Q., Corp, T., Poon, K., Tuexen, M., and
V. Yasevich, "Sockets API Extensions for Stream Control V. Yasevich, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)", Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-16 (work in progress), draft-ietf-tsvwg-sctpsocket-16 (work in progress),
February 2008. 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.
Authors' Addresses Authors' Addresses
Qiaobing Xie Qiaobing Xie
Motorola, Inc. USA
1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004
US
Phone: Phone: +1 224-465-5954
Email: Qiaobing.Xie@motorola.com Email: Qiaobing.Xie@gmail.org
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc.
4875 Forest Drive 4875 Forest Drive
Suite 200 Suite 200
Columbia, SC 29206 Columbia, SC 29206
USA USA
Phone: Phone:
Email: rrs@cisco.com Email: randall@lakerest.net
Maureen Stillman Maureen Stillman
Nokia Nokia
127 W. State Street 127 W. State Street
Ithaca, NY 14850 Ithaca, NY 14850
US US
Phone: Phone:
Email: maureen.stillman@nokia.com Email: maureen.stillman@nokia.com
 End of changes. 19 change blocks. 
38 lines changed or deleted 26 lines changed or added

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