headers
Thomas Dreibholz | 2 Jan 2007 18:26
Picon
Gravatar

Length of the Policy Type field

Hi!

According to the policies draft, the size of the policy type identifier is 8 
bits. However, there are already 16 policies implemented by the rsplib 
prototype implementation (see 
http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/) and it can be 
expected that new applications require additional policies. Since the Policy 
Parameters for each of the defined policies includes 24 reserved (i.e. 
unused) bits after the policy type, what about extending the Policy Type to 
32 bits? While this would not increase the message sizes, it would give 
implementers and users sufficient space for own extensions. Furthermore, I 
would suggest to split the policy type space into a reserved part 
for "standardized" policies (managed by the IANA) and a non-standard user 
part, e.g. 0x00000000 to 0x7fffffff for registered policies and the rest for 
user-defined ones.

Best regards
--

-- 
=======================================================================
 Dipl.-Inform. Thomas Dreibholz

 University of Duisburg-Essen,                   Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
-----------------------------------------------------------------------
 E-Mail:     dreibh <at> exp-math.uni-essen.de
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================

(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Qiaobing Xie
 | 
4 Jan 2007 20:35





Re: Length of the Policy Type field


Thomas,

That sounds like a good idea to me.

regards,
-Qiaobing

Thomas Dreibholz wrote:
> Hi!
> 
> According to the policies draft, the size of the policy type identifier is 8 
> bits. However, there are already 16 policies implemented by the rsplib 
> prototype implementation (see 
> http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/) and it can be 
> expected that new applications require additional policies. Since the Policy 
> Parameters for each of the defined policies includes 24 reserved (i.e. 
> unused) bits after the policy type, what about extending the Policy Type to 
> 32 bits? While this would not increase the message sizes, it would give 
> implementers and users sufficient space for own extensions. Furthermore, I 
> would suggest to split the policy type space into a reserved part 
> for "standardized" policies (managed by the IANA) and a non-standard user 
> part, e.g. 0x00000000 to 0x7fffffff for registered policies and the rest for 
> user-defined ones.
> 
> 
> Best regards
> 
> 
> ------------------------------------------------------------------------
> 

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Internet-Drafts
 | 
5 Jan 2007 21:50






Picon

Favicon





I-D ACTION:draft-ietf-rserpool-enrp-15.txt


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Reliable Server Pooling Working Group of the IETF.

	Title		: Endpoint Handlespace Redundancy Protocol (ENRP)
	Author(s)	: R. Stewart, et al.
	Filename	: draft-ietf-rserpool-enrp-15.txt
	Pages		: 46
	Date		: 2007-1-5
	
Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work
   in conjunction with the Aggregate Server Access Protocol (ASAP) to
   accomplish the functionality of the Reliable Server Pooling
   (Rserpool) requirements and architecture.  Within the operational
   scope of Rserpool, ENRP defines the procedures and message formats of
   a distributed, fault-tolerant registry service for storing,
   bookkeeping, retrieving, and distributing pool operation and
   membership information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rserpool-enrp-15.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Internet-Drafts
 | 
11 Jan 2007 21:50






Picon

Favicon





I-D ACTION:draft-ietf-rserpool-asap-15.txt


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Reliable Server Pooling Working Group of the IETF.

	Title		: Aggregate Server Access Protocol (ASAP)
	Author(s)	: R. Stewart, et al.
	Filename	: draft-ietf-rserpool-asap-15.txt
	Pages		: 49
	Date		: 2007-1-11
	
Aggregate Server Access Protocol (ASAP) in conjunction with the
   Endpoint Handlespace Redundancy Protocol (ENRP) [8] provides a high
   availability data transfer mechanism over IP networks.  ASAP uses a
   handle-based addressing model which isolates a logical communication
   endpoint from its IP address(es), thus effectively eliminating the
   binding between the communication endpoint and its physical IP
   address(es) which normally constitutes a single point of failure.

   In addition, ASAP defines each logical communication destination as a
   pool, providing full transparent support for server-pooling and load
   sharing.  It also allows dynamic system scalability - members of a
   server pool can be added or removed at any time without interrupting
   the service.

   ASAP is designed to take full advantage of the network level
   redundancy provided by the Stream Transmission Control Protocol
   (SCTP) RFC2960 [4].  Each transport protocol, other than SCTP, MUST
   have an accompanying transport mapping document.  It should be noted
   that ASAP messages passed between PE's and ENRP servers MUST use the
   SCTP transport protocol.

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Maureen.Stillman
 | 
16 Jan 2007 17:31






Picon





Not meeting in Prague - IETF #68








Our current goal is to get the following documents ready for review:




Overview
ASAP
ENRP
Common parameters
Threat document
Policy 




We will not be meeting in Prague.




-- Maureen


Maureen Stillman


Nokia Enterprise Solutions


Mobile: (607)279-5080






_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool






Permalink
| Reply
| 0 comments  
| 



  

  

  

  


  





    



Gmane