headers
Randall Stewart | 2 Jan 2009 15:01

Re: SCTP support for Solaris

Sorry for seeing this so late :-(

On Nov 25, 2008, at 3:13 PM, Michael Tüxen wrote:

>>
> So the idea is to be able to be able to provide a some cmghdr
> structure, each one for
> - The PPID
> - The stream id
> - Sending ordered/unordered
> - the PR-SCTP policy
> - the PR-SCTP value
> - the SCTP-AUTH keyid
> - the flags (from the sndrcv info flags)
> - the context
> - and a couple more that I forgot...
>
> The experience I had is that people avoid using the the
> cmghdr stuff... That is why we added sctp_sendmsg() which
> was just a wrapper added to handle the cmghdr stuff..

I tend to agree with you here Michael. I have taught
quite a few classes on the SCTP socket API.. where you
get blood curdling screams, groans and moans is when you
try to get folks to use the cmsg stuff. Its real ugly
and quite awkward to use. Most folks just plain do not
want to use it.

No matter what we do, I think having something simple
to use is far better. Even if that means wrapping a library
(Continue reading)

Permalink | Reply | 1 comment |
headers
Randy Stewart | 4 Jan 2009 15:03

Re: Multihoming during SCTP 4-way handshake?

Just saw this... sorry for the delay..

On Nov 21, 2008, at 6:36 AM, Tim Stevens wrote:

> Dear Randy,
>
> Thanks alot for your help!
>
> Considering scenario 2, see my comments below.
>
>>> Scenario 2:
>>> Consider that both hosts support RFC5061. Is the following  
>>> sequence of
>>> events correct?
>>> 1) C1 sends INIT to S1
>>> 2) S1 receives the request, but prefers to use interface S2
>>> 3) S2 sends INIT ACK + ADDRESS PARAMETERS S2,S1 + SET PRIMARY  
>>> ADDRESS
>>> S2 to C1
>>> 4) interface S1 becomes unreachable (due to some network event)
>>> 5) C1 sends COOKIE ECHO + HEARTBEAT to S2 (because S2 is  
>>> UNCONFIRMED?)
>>> 6) S2 sends COOKIE ACK + HEARTBEAT ACK to C1
>>> 7) connection ESTABLISHED
>>
>> When S2 sends the INIT it is not legal for it to bundle a
>> Set-Primary in it. The INIT and INIT-ACK chunks are specifically
>> prohibited from having any other chunks bundled with them.
>>
>> S2 could send the INIT-ACK (remember it has no state either)... and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ross Callon | 6 Jan 2009 20:04
Favicon

FW: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications) to Proposed Standard

FYI.  This may be of interest to the CCAMP, MPLS, PCE and TSVWG WGs.

thanks, Ross

-----Original Message-----
From: ietf-announce-bounces <at> ietf.org
[mailto:ietf-announce-bounces <at> ietf.org] On Behalf Of The IESG
Sent: 06 January 2009 13:56
To: IETF-Announce
Subject: Last Call: draft-farrel-rtg-common-bnf (Reduced Backus-Naur
Form (RBNF) A Syntax Used in Various Protocol Specifications) to
Proposed Standard 

The IESG has received a request from an individual submitter to consider
the following document:

- 'Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol 
   Specifications '
   <draft-farrel-rtg-common-bnf-07.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2009-02-03. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-farrel-rtg-common-bnf-07.txt

IESG discussion can be tracked via
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vlad Yasevich | 7 Jan 2009 16:23
Picon
Favicon

Re: SCTP support for Solaris

Randall Stewart wrote:
> Sorry for seeing this so late :-(
> 
> 
> On Nov 25, 2008, at 3:13 PM, Michael Tüxen wrote:
> 
>>>
>> So the idea is to be able to be able to provide a some cmghdr
>> structure, each one for
>> - The PPID
>> - The stream id
>> - Sending ordered/unordered
>> - the PR-SCTP policy
>> - the PR-SCTP value
>> - the SCTP-AUTH keyid
>> - the flags (from the sndrcv info flags)
>> - the context
>> - and a couple more that I forgot...
>>
>> The experience I had is that people avoid using the the
>> cmghdr stuff... That is why we added sctp_sendmsg() which
>> was just a wrapper added to handle the cmghdr stuff..
> 
> 
> I tend to agree with you here Michael. I have taught
> quite a few classes on the SCTP socket API.. where you
> get blood curdling screams, groans and moans is when you
> try to get folks to use the cmsg stuff. Its real ugly
> and quite awkward to use. Most folks just plain do not
> want to use it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hannes Tschofenig | 15 Jan 2009 09:24
Picon

draft-ietf-tsvwg-admitted-realtime-dscp-05

By coincident I ran into the following draft: 
http://tools.ietf.org/html/draft-ietf-tsvwg-admitted-realtime-dscp-05

Section 2.3 says: 

"
   On the point of what protocols and procedures are required for
   authentication, authorization, and capacity admission, we note that
   clear standards do not at this time exist for bandwidth brokers, NSIS
   has not at this time been finalized and in any event is limited to
   unicast sessions, and that RSVP has been standardized and has the
   relevant services.  We therefore recommend the use of RSVP at the
   UNI.  Procedures at the NNI are business matters to be discussed
   between the relevant networks, and are recommended but not required.
"

and the IANA consideration section says:

"
   This traffic class requires the use of capacity admission such as
   RSVP services together with AAA services at the User/Network
   Interface (UNI); the use of such services at the NNI is at the option
   of the interconnected networks.
"

The text (to me) sounds like that this DSCP essentially requires RSVP to be
implemented in order to get this to work. This is IMHO not correct. 

To give you one other example of a standardized mechanism that would do the
job: Rx/Gx (3GPP)
(Continue reading)

Permalink | Reply | 9 comments |
headers
ken carlberg | 15 Jan 2009 13:59
Picon

Re: draft-ietf-tsvwg-admitted-realtime-dscp-05

I'm afraid you've lost me.  The words "recommend" and "such as" from  
the cited text below doesn't IMO come close to giving an impression  
of "essentially requires".  The cited text makes an observation about  
the work from NSIS, with (my) assumption that the authors choose to  
discuss the topic within the context of IETF signaling protocols.

If you would like to advocate the integration of Rx/Gx (3GPP) with  
the work at hand, perhaps it may be more helpful to describe this  
suggested interaction in more detail with suggested text.

cheers,

-ken

On Jan 15, 2009, at 5:24 AM, Hannes Tschofenig wrote:

> By coincident I ran into the following draft:
> http://tools.ietf.org/html/draft-ietf-tsvwg-admitted-realtime-dscp-05
>
> Section 2.3 says:
>
> "
>    On the point of what protocols and procedures are required for
>    authentication, authorization, and capacity admission, we note that
>    clear standards do not at this time exist for bandwidth brokers,  
> NSIS
>    has not at this time been finalized and in any event is limited to
>    unicast sessions, and that RSVP has been standardized and has the
>    relevant services.  We therefore recommend the use of RSVP at the
>    UNI.  Procedures at the NNI are business matters to be discussed
(Continue reading)

Permalink | Reply | 8 comments |
headers
Tschofenig, Hannes (NSN - FI/Espoo | 15 Jan 2009 14:04

Re: draft-ietf-tsvwg-admitted-realtime-dscp-05

Hi Ken, 

I would like the document not to talk about this at all. 
I don't know why it has to. 

Ciao
Hannes 

>-----Original Message-----
>From: tsvwg-bounces <at> ietf.org [mailto:tsvwg-bounces <at> ietf.org] 
>On Behalf Of ext ken carlberg
>Sent: 15 January, 2009 15:00
>To: Hannes Tschofenig
>Cc: tsvwg <at> ietf.org
>Subject: Re: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05
>
>I'm afraid you've lost me.  The words "recommend" and "such 
>as" from the cited text below doesn't IMO come close to giving 
>an impression of "essentially requires".  The cited text makes 
>an observation about the work from NSIS, with (my) assumption 
>that the authors choose to discuss the topic within the 
>context of IETF signaling protocols.
>
>If you would like to advocate the integration of Rx/Gx (3GPP) 
>with the work at hand, perhaps it may be more helpful to 
>describe this suggested interaction in more detail with suggested text.
>
>cheers,
>
>-ken
(Continue reading)

Permalink | Reply | 7 comments |
headers
ken carlberg | 15 Jan 2009 14:13
Picon

Re: draft-ietf-tsvwg-admitted-realtime-dscp-05

ok, but could you make a stronger case as for why?  the cited text  
presents context and recommendations with what we have on hand now,  
but doesn't make a hard requirement of MUST.  if someone else comes  
along later and defines a better widget, or simply another way of  
accomplishing the fundamental objectives of the draft with a  
different signaling protocol....great, and please let's encourage  
them to tell "us" how.

cheers,

-ken

On Jan 15, 2009, at 10:04 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> Hi Ken,
>
> I would like the document not to talk about this at all.
> I don't know why it has to.
>
> Ciao
> Hannes
>
>> -----Original Message-----
>> From: tsvwg-bounces <at> ietf.org [mailto:tsvwg-bounces <at> ietf.org]
>> On Behalf Of ext ken carlberg
>> Sent: 15 January, 2009 15:00
>> To: Hannes Tschofenig
>> Cc: tsvwg <at> ietf.org
>> Subject: Re: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05
>>
(Continue reading)

Permalink | Reply | 6 comments |
headers
Tschofenig, Hannes (NSN - FI/Espoo | 15 Jan 2009 14:19

Re: draft-ietf-tsvwg-admitted-realtime-dscp-05

Creating the perception that only RSVP can be used to provide the
required functionality does not reflect reality. 
If one wants to be fair then this has to be stated. When protocols are
discussed then it would be fair to say that there isn't only RSVP and
NSIS. 

Does this make sense to you? 

Ciao
Hannes

>-----Original Message-----
>From: ext ken carlberg [mailto:carlberg <at> g11.org.uk] 
>Sent: 15 January, 2009 15:13
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: Hannes Tschofenig; tsvwg <at> ietf.org
>Subject: Re: [Tsvwg] draft-ietf-tsvwg-admitted-realtime-dscp-05
>
>ok, but could you make a stronger case as for why?  the cited 
>text presents context and recommendations with what we have on 
>hand now, but doesn't make a hard requirement of MUST.  if 
>someone else comes along later and defines a better widget, or 
>simply another way of accomplishing the fundamental objectives 
>of the draft with a different signaling protocol....great, and 
>please let's encourage them to tell "us" how.
>
>cheers,
>
>-ken
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
ken carlberg | 15 Jan 2009 14:34
Picon

Re: draft-ietf-tsvwg-admitted-realtime-dscp-05

no, and this discussion is becoming circular.  I go back to the  
preciseness of the language in the text of the draft that discusses  
RSVP as a recommendation, not a requirement in the form of a must.

to follow your line of reasoning, we would need to go back to all  
protocols that interact with SIP and say "please consider other  
protocols like H.323, and perform the interaction in the following  
way (blah, blah, blah)", since there are others means to signal the  
establishment of sessions.

the two of us seem to agree to disagree.

kindest regards,

-ken

On Jan 15, 2009, at 10:19 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote:

> Creating the perception that only RSVP can be used to provide the
> required functionality does not reflect reality.
> If one wants to be fair then this has to be stated. When protocols are
> discussed then it would be fair to say that there isn't only RSVP and
> NSIS.
>
> Does this make sense to you?
>
> Ciao
> Hannes
>
>> -----Original Message-----
(Continue reading)

Permalink | Reply | 4 comments |

Gmane