Reliable Server Pooling (rserpool)

Michael Tuexen | 5 Jul 2004 19:20

Picon

Packet format in ENRP

Dear all,

while writing the ethereal dissector for ENRP I found some
things I would like to change:

Section 3.1

The length field is shown as 'Message Length = 0xC' which
is not correct because there can be some parameters.

Section 3.3

Could we exchange the R and M bit? This would align the
R bit position with the reject bit in a PEER_LIST_RESONSE
message.

Section 3.4

To have a similar layout of the packets i would suggest to
change it to:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Type = 0x4  |0|0|0|0|0|0|0|0|        Message Length         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                      Sender Server's ID                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Receiver Server's ID                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(Continue reading)

Michael Tuexen | 6 Jul 2004 20:53

Picon

draft-tuexen-rserpool-policies-00.txt

Dear all,

I just submitted a new ID, an individual submission
to the RSerPool WG regarding server pool policies.

The ID is also available from
http://www.sctp.de/internet-drafts.html

Best regards
Michael

Maureen.Stillman | 7 Jul 2004 15:54

Picon

Agenda for IETF #60

Please send any agenda items.  We are scheduled for Thursday afternoon in San Diego.

Thanks.

-- maureen

Qiaobing Xie | 7 Jul 2004 21:28

Re: Packet format in ENRP

Michael,

Michael Tuexen wrote:

> Dear all,
> 
> while writing the ethereal dissector for ENRP I found some
> things I would like to change:
> 
> Section 3.1
> 
> The length field is shown as 'Message Length = 0xC' which
> is not correct because there can be some parameters.

good catch.

> 
> Section 3.3
> 
> Could we exchange the R and M bit? This would align the
> R bit position with the reject bit in a PEER_LIST_RESONSE
> message.

I agree. Better alignment is always good 

> 
> Section 3.4
> 
> To have a similar layout of the packets i would suggest to
> change it to:

(Continue reading)

Silverton Aron-C1710C | 7 Jul 2004 22:40

RE: Packet format in ENRP

Michael,

The rest of here at Motorola discussed your comments this morning and we, too, agree on all accounts.  Do we
need to wait for further agreement, or should we proceed with updating our documentation and implementations?

Regards,

Aron

Qiaobing Xie <> wrote:
> Michael,
> 
> Michael Tuexen wrote:
> 
>> Dear all,
>> 
>> while writing the ethereal dissector for ENRP I found some things I
>> would like to change: 
>> 
>> Section 3.1
>> 
>> The length field is shown as 'Message Length = 0xC' which
>> is not correct because there can be some parameters.
> 
> good catch.
> 
>> 
>> Section 3.3
>> 
>> Could we exchange the R and M bit? This would align the

(Continue reading)

Johnson Walter-CWJ002 | 8 Jul 2004 00:12

RE: Packet format in ENRP

I agree with all the changes but would like to suggest another. Much like Michael's suggestion in section
3.3 to align the R bit in PEER_NAME_TABLE_RESPONSE with PEER_PRESENCE and PEER_LIST_RESPONSE. How
about the following for the 8 bit flag field. Define bit 15 to be the R flag bit, bit 14 to be the M flag bit, and
bit 13 to be W flag bit as shown below the pertinent ENRP protocol messages. This would allow a single mask at
least until the time that more than 8 flags were required.  

PEER_PRESENCE  			0000000R
PEER_NAME_TABLE 			00000W00
PEER_NAME_TABLE_RESPONSE 	000000MR (Change as suggested by Michael)
PEER_LIST_RESPONSE		0000000R

This would also work for the ASAP protocol messages as currently defined.

REGISTRATION_RESPONSE		0000000R

Walter

Qiaobing Xie <> wrote:
> Michael,
> 
> Michael Tuexen wrote:
> 
>> Dear all,
>> 
>> while writing the ethereal dissector for ENRP I found some things I
>> would like to change: 
>> 
>> Section 3.1
>> 
>> The length field is shown as 'Message Length = 0xC' which

(Continue reading)

dreibh | 8 Jul 2004 15:21

Picon

RE: Packet format in ENRP

Zitat von Johnson Walter-CWJ002 <Walter.Johnson <at> motorola.com>:

> I agree with all the changes but would like to suggest another. Much like
> Michael's suggestion in section 3.3 to align the R bit in
> PEER_NAME_TABLE_RESPONSE with PEER_PRESENCE and PEER_LIST_RESPONSE. How about
> the following for the 8 bit flag field. Define bit 15 to be the R flag bit,
> bit 14 to be the M flag bit, and bit 13 to be W flag bit as shown below the
> pertinent ENRP protocol messages. This would allow a single mask at least
> until the time that more than 8 flags were required.
>
> PEER_PRESENCE  			0000000R
> PEER_NAME_TABLE 			00000W00
> PEER_NAME_TABLE_RESPONSE 	000000MR (Change as suggested by Michael)
> PEER_LIST_RESPONSE		0000000R
>
> This would also work for the ASAP protocol messages as currently defined.
>
> REGISTRATION_RESPONSE		0000000R

This change is a good idea. I support this.

Best regards

Thomas Dreibholz

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Michael Tuexen | 8 Jul 2004 15:36

Picon

Re: Packet format in ENRP

Dear all,

just one note:
the R flag in the PEER_PRESENCE message means 'reply required' and
in the PEER_NAME_TABLE_RESPONSE and PEER_LIST_RESPONSE it means
'reject'. So it is not just 'one bit'.

On Jul 8, 2004, at 12:12 AM, Johnson Walter-CWJ002 wrote:

> I agree with all the changes but would like to suggest another. Much 
> like Michael's suggestion in section 3.3 to align the R bit in 
> PEER_NAME_TABLE_RESPONSE with PEER_PRESENCE and PEER_LIST_RESPONSE. 
> How about the following for the 8 bit flag field. Define bit 15 to be 
> the R flag bit, bit 14 to be the M flag bit, and bit 13 to be W flag 
> bit as shown below the pertinent ENRP protocol messages. This would 
> allow a single mask at least until the time that more than 8 flags 
> were required.
>
> PEER_PRESENCE  			0000000R
> PEER_NAME_TABLE 			00000W00
> PEER_NAME_TABLE_RESPONSE 	000000MR (Change as suggested by Michael)
> PEER_LIST_RESPONSE		0000000R
>
> This would also work for the ASAP protocol messages as currently 
> defined.
>
> REGISTRATION_RESPONSE		0000000R
>
> Walter
>

(Continue reading)

Michael Tuexen | 8 Jul 2004 15:38

Picon

Re: Packet format in ENRP

Aron,

possibly we could update the ENRP ID before the IETF deadline. This
is still one week away. Qiaobing, if the .xml source is in Randalls
CVS, I can do the editing, if you want.

I can also update the ethereal dissector and Thomas can update
the rsplib.

Best regards
Michael

On Jul 7, 2004, at 10:40 PM, Silverton Aron-C1710C wrote:

> Michael,
>
> The rest of here at Motorola discussed your comments this morning and 
> we, too, agree on all accounts.  Do we need to wait for further 
> agreement, or should we proceed with updating our documentation and 
> implementations?
>
> Regards,
>
> Aron
>
> Qiaobing Xie <> wrote:
>> Michael,
>>
>> Michael Tuexen wrote:
>>

(Continue reading)

Johnson Walter-CWJ002 | 8 Jul 2004 16:44

RE: Packet format in ENRP

Michael is right. So how about the move the R flag to bit 12 for PEER_PRESENCE and maybe change R flag to X flag
for reject to avoid confusion in PEER_NAME_TABLE_RESPONSE, PEER_LIST_RESPONSE and ASAP's
REGISTRATION_RESPONSE with the R flag of PEER_PRESENCE. Resulting in the following:

PEER_PRESENCE  			0000R000
PEER_NAME_TABLE 			00000W00
PEER_NAME_TABLE_RESPONSE 	000000MX 
PEER_LIST_RESPONSE		0000000X 

REGISTRATION_RESPONSE		0000000X

Michael Tuexen <mailto:Michael.Tuexen <at> lurchi.franken.de> wrote:
> Dear all,
> 
> just one note:
> the R flag in the PEER_PRESENCE message means 'reply required' and in
> the PEER_NAME_TABLE_RESPONSE and PEER_LIST_RESPONSE it means
> 'reject'. So it is not just 'one bit'.  
> 
> 
> On Jul 8, 2004, at 12:12 AM, Johnson Walter-CWJ002 wrote:
> 
>> I agree with all the changes but would like to suggest another. Much
>> like Michael's suggestion in section 3.3 to align the R bit in
>> PEER_NAME_TABLE_RESPONSE with PEER_PRESENCE and PEER_LIST_RESPONSE.
>> How about the following for the 8 bit flag field. Define bit 15 to be
>> the R flag bit, bit 14 to be the M flag bit, and bit 13 to be W flag
>> bit as shown below the pertinent ENRP protocol messages. This would
>> allow a single mask at least until the time that more than 8 flags
>> were required.

(Continue reading)

Group

gmane.ietf.rserpool.

Advertisement

Search Archive

Page

1 | 2 | 3 | 4

Articles in period: 30

July 2004

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

Call for Participation: PAMS 2013 (5 Feb 2013)
[Extended Deadline] Call for Papers of the PAMS 2013 (5 Oct 2012)
Call for Papers of the PAMS 2013 (4 Sep 2012)
Call for Papers of the PAMS 2013 (19 Jul 2012)
Call for Papers of the PAMS 2013 (1 Jun 2012)
PAMS 2012 -- Call for Participation (19 Mar 2012)
RSPSIM Simulation Model (6 Feb 2012)
start your new life x (13 Jan 2012)
Release of rsplib 2.7.13 (25 Nov 2011)
Deadline Extension: PAMS 2012 -- 2nd InternationalWorkshop on Protocol (1 Oct 2011)
Call for Papers: PAMS 2012 -- 2nd International Workshop on Protocols (8 Sep 2011)
Call for Papers: PAMS 2012 -- 2nd International Workshop on Protocols (2 Aug 2011)
Call for Papers: PAMS 2012 -- 2nd International Workshop on Protocols (2 Jul 2011)
Stable Release 2.7.7 of RSPLIB (27 Jan 2011)
Call for Papers: PAMS 2011 (deadline extended) (14 Sep 2010)
Call for Papers: Int'l Workshop on Protocols and Applications with Mul (25 Aug 2010)
Int'l Workshop on Protocols and Applications with Multi-Homing Support (9 Aug 2010)
Release of rsplib 2.7.5 (27 Jul 2010)
Release of rsplib 2.7.4 (19 Jul 2010)
Release of rsplib 2.7.3 (4 Jul 2010)
Release of rsplib 2.7.0 (8 Dec 2009)

Archives

1	February 2013
1	October 2012
1	September 2012
1	July 2012
1	June 2012
1	March 2012
1	February 2012
1	January 2012
1	November 2011
1	October 2011
1	September 2011
1	August 2011
1	July 2011
1	January 2011
1	September 2010
2	August 2010
3	July 2010
1	December 2009
3	April 2009
4	March 2009
7	February 2009
10	January 2009
1	December 2008
29	November 2008
14	October 2008
6	September 2008
13	July 2008
7	June 2008
6	May 2008
4	April 2008
10	March 2008
12	February 2008
2	January 2008
2	December 2007
12	November 2007
10	October 2007
6	September 2007
10	July 2007
2	June 2007
1	April 2007
1	March 2007
3	February 2007
5	January 2007
1	December 2006
6	November 2006
10	October 2006
2	September 2006
2	August 2006
12	July 2006
6	June 2006
3	May 2006
1	April 2006
7	March 2006
6	February 2006
1	November 2005
6	October 2005
2	September 2005
19	August 2005
37	July 2005
15	June 2005
1	April 2005
4	March 2005
11	February 2005
4	January 2005
6	December 2004
5	November 2004
28	October 2004
3	September 2004
15	August 2004
30	July 2004
5	June 2004
6	March 2004
6	February 2004
3	January 2004
1	December 2003
5	November 2003
18	October 2003
26	September 2003
13	August 2003
13	July 2003
7	June 2003
8	May 2003
33	April 2003
19	March 2003
5	February 2003
14	November 2002
17	October 2002
25	September 2002
7	August 2002
7	July 2002
30	June 2002
29	May 2002
18	April 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template