Subject: [Sigtran] RFC-4460

From: Bhanu Prakash <[email-masked]>
Date: Tue, 03 Oct 2006 14:14:17 +0530

The section 2.4.2. of RFC-4460 says that:

   ---------
   New text: (Section 3.2.1)
   ---------
 
   The actual SCTP parameters are defined in the specific SCTP chunk
   sections.  The rules for IETF-defined parameter extensions are
   defined in Section 13.2.  Note that a parameter type MUST be unique
   across all chunks.  For example, the parameter type '5' is used to
   represent an IPv4 address (see Section 3.3.2).  The value '5' then is
   reserved across all chunks to represent an IPv4 address and MUST NOT
   be reused with a different meaning in any other chunk.

Does it means that the RFC 2960 had allowed to have same parameter type 
across different chunks..?
Can an implementor define and use his own parameter type other than what 
specified in RFC..?
Please clarify.

Thanks.
Bhanuprakash.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 3 Oct 2006 12:09:28 +0200

Yes, RFC 2960 did not specify if there is one number space for  
parameters
or one number space for each chunk.

This has been clarified that there is only one number space.

You can write an ID for an extension of the protocol, define there
new parameters and register them at IANA. This is how protocol  
extensions
work.

Best regards
Michael

On Oct 3, 2006, at 10:44 AM, Bhanu Prakash wrote:

> Does it means that the RFC 2960 had allowed to have same parameter  
> type across different chunks..?
> Can an implementor define and use his own parameter type other than  
> what specified in RFC..?
> Please clarify.
>
> Thanks.
> Bhanuprakash.
>
>
>

---

From: Bhanu Prakash <[email-masked]>
Date: Tue, 03 Oct 2006 18:02:31 +0530

I need clarification with regrards to the section 2.17 it says:

   ---------
   New text: (Section 3.3.4)
   ---------
 
   Cumulative TSN Ack: 32 bits (unsigned integer)
 
      This parameter contains the TSN of the last DATA chunk received in
      sequence before a gap.  In the case where no DATA chunk has
      been received, this value is set to the peer's Initial TSN minus
      one.

When there is no DATA received why a SACK will be sent..?

Thanks
Bhanuprakash.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 3 Oct 2006 06:57:33 -0600

Bhanu,

Bhanu Prakash wrote:                              (Tue, 03 Oct 2006 18:02:31)
>    When there is no DATA received why a SACK will be sent..?

To update the receive window.

Read RFC 2960.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/