Ajay Garg | 28 Mar 12:49 2014
Picon

Query regarding SLC

Hi all.

Does SLC select a "SCTP-link" within a "SCTP-linkset", or a "stream" within a "SCTP-link", or both?


Will be grateful for clarifications.


Thanks and Regards,
Ajay
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Brian F. G. Bidulock | 27 Mar 05:16 2014

Re: Query Regarding RC parameter

Nagesh,

Per the RFC the RC is a 32-bit unsigned integer.  Every value from
0x00000000 to 0xffffffff is a valid 32-bit unsigned integer.  Why
would you not consider it valid?

--brian

Nagesh shamnur wrote:                                (Thu, 27 Mar 2014 01:54:05)
>    Hi Group,
> 
>                    I have a query about the parameter RC as per the RFC
>    4666. As per that, should we consider 0xFFFFFFFF as a valid routing
>    context.
> 
> 
>    Thanks and Regards,
> 
>    Nagesh.

--

-- 
Brian F. G. Bidulock
bidulock <at> openss7.org
http://www.openss7.org/
Ajay Garg | 16 Mar 16:41 2014
Picon

Query for "Routing Context"

Hi all.

I have exactly the same query as asked already at http://www.ietf.org/mail-archive/web/sigtran/current/msg08662.html.

In particular, where is the mapping/indexing for Routing-Key <-> Routing-Context kept? At the AS?  At the SG?  Both?
A Hello-worldish state-machine diagram will be highly appreciated !! :)


Thanks and Regards,
Ajay
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Ajay Garg | 13 Mar 07:45 2014
Picon

State-machines wrong in the RFC-3332 and RFC-4666 ??!!

Hi all.

Sorry if I am acting stupid, but


1)
At https://www.ietf.org/rfc/rfc3332.txt, in the section

                               5.1.4 Three ASPs in an Application Server ("n+k" sparing, loadsharing case)

should not "Notify (AS-ACTIVE)" be sent to ASP1 and ASP2 (as against ASP2 and ASP3 as per the diagram), since ASP1 and ASP2 are the ones that sent the "ASP Act (Ldshr)" message (and are thus the "n" active ASPs)?



2)
At https://tools.ietf.org/html/rfc4666, in the section

                              5.1.4 Three ASPs in an Application Server ("n+k" sparing, loadsharing case)


why will "Notify (AS-ACTIVE)" be sent to ASP3 (since only ASP1 and ASP2 sent the "ASP Act. (Ldshr)" message, and are thus the "n" active ASPs)?





Again, sorry if I am missing something very fundamental.


Thanks and Regards,
Ajay
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Ajay Garg | 13 Mar 07:18 2014
Picon

Conceptual doubt between an ASP and SGP

Hi all.

I am an absolute newbie in telecom domain, so kindly forgive me if I sound incredibly stupid.


From what I understand, an ASP is a process running on an AS, and a SGP is a process running on a SG.
Each ASP <-> SGP link is a SCTP connection.

Also, I understand that SGP is responsible for message-routing, while an ASP is merely an end-point for a SCTP connection.


Given that, are there any extra differences between a ASP and SGP (in addition to the routing-capabilities of a SGP)?


I will be grateful for any pointers/clarifications.


Thanks and Regards,
Ajay
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Norah Jones | 4 Feb 08:09 2014
Picon

Is there any performance impact, if we tune kernel SCTP (/proc/sys/net/sctp/sack_timeout) parameter??

Hi, 

Can we set the same to 0? If so, how??

Thanks,
Norah Jones
Norah Jones | 20 Dec 08:02 2013
Picon

Is MultiHoming on IPV6 supported in SCTP?

Hi, 

When I read wiki , its written like this

    As of 6 February 2010, multihoming in the next-generation Internet Protocol (IPv6) 
    was not yet standardized

Is it supported now ? 

Thanks,
Norah Jones
Suchetha P | 16 Dec 15:24 2013
Picon

SCCP connection refusal please help !

Hi All,

I see a high number of SCCP CREFs(Connection Refusal) in the logs.
None of the calls are successful as observed from PM Counter statistics.
The application has refused with the cause 7.From ITU-T Q.713 it indicates
00000111 network resource – QoS unavailable/transient.

The trillium stack has logged unsolicited status indication with the event "Connection request failure"
and cause "connection threshold exceeded".

Please let me know,

1.) what does this "connection threshold exceeded" indicate ?Is this the SCCP connections ? Is it
configurable ?
2.)what does "network resource – QoS unavailable/transient mean" ?Can "connection threshold
exceeded" be the cause behind 
"network resource – QoS unavailable/transient".Please give me your valuable inputs on how to debug
this further.Whether 
congestion can be the reasone ?

Best Regards,
Suchetha
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
Richard Knowles | 18 Nov 19:24 2013

Optional RC configured on one side and not the other


Hi,

Assume you have the conditions (one AS, etc.) to allow RC to be optional, 
does the RFC permit one side (IPSP SE mode for example) to still send an RC and the 
other to not include an RC?   I think the answer is yes, but I can't find 
an explicit reference permitting it.  

Richard Knowles
David Laight | 14 Oct 11:20 2013

Re: M3UA: Message Length

I’ve NFI what you used to take that trace – Wireshark will only give me a hexdump.

Anyway the packet decodes as:

 

Pad, MAC addresses, ethertype

0000  00 00 00 01 00 06 00 1a  30 2b 4b c0 00 00 08 00

IP header

0010  45 02 00 ac 13 31 00 00  fe 84 3f ca 0a 3a 70 c8

0020  0a 3a e3 94

SCTP

      ports: 0f 53 0f 59

      tag:   49 33 5f c5

      cksum: 7f 3e b6 8d

0030  chunk type: 00

      flags:      03

      length:     00 8a

      TSN:        da 58 6c 93

      Stream id:  00 01

      Stream-seq: 00 08

      Payload-id: 00 00 00 03

 

M3UA data, length 0x7c

0040  01 00 01 01 00 00 00 7c

            02 00 00 08

                  00 00 00 02

0050        00 06 00 08

                  00 00 00 08

            02 10 00 62

                  00 00 0b ba

0060              00 00 13 8b 03 03 01 00  11 01 03 04 08 0c 45 04

0070              43 8b 13 07 04 43 ba 0b  07 39 00 00 00 00 00 00

0080              00 00 00 00 00 00 00 00  00 00 00 00 00 00 04 04

0090              04 04 04 04 04 04 04 04  04 04 04 04 04 04 04 04

00a0              04 04 04 04 04 04 04 04  04 04 04 04 04 04 04 04

00b0              04 04 04 10 04 40 00 00  00 00

 

Inter-chunk pad: 00 00

 

The problem is that the length of the M3UA message (0x7c)  is larger than the payload

part of the SCTP message (0x8a – 0x10 = 0x7a).

The RFC might let you send that if the M3UA length were 0x7a, but I know that

all implementations will not be able to receive such messages – so it is best not

to send them.

 

                David

 

 

From: santosh nayak [mailto:santosh.nayak69 <at> gmail.com]
Sent: 14 October 2013 05:47
To: David Laight
Subject: Re: [Sigtran] M3UA: Message Length

 

Hi,

 

Thanks for the response...

 

I am attaching the pcap... packet number 85

Could you explain what MUST is violated???

 

Thanks,

Santosh

 

 

On Thu, Oct 10, 2013 at 5:57 PM, David Laight <David.Laight <at> aculab.com> wrote:

> From: sigtran-bounces <at> ietf.org [mailto:sigtran-bounces <at> ietf.org] On Behalf Of Michael Tuexen

> On Oct 10, 2013, at 11:40 AM, santosh nayak <santosh.nayak69 <at> gmail.com> wrote:
>
> > Hi,
> >
> > We have a situation where message is being rejected at M3UA layer due to
> > buffer length is not equal to message length.
> >
> > What is the significance of Message Length and its importance with padding...
> >
> > in the current issue M3UA peer is sending the data buffer of size 122 bytes
> > to KSCTP. But message length parameter of M3UA common header contains a value
> > of 124 and KSCTP is doing the padding at its level of 2 bytes which is
> > observed from the wireshark traces.

Are you sure that pad isn't just from SCTP aligning it's chunks?


> > Now at DUT message droped with reason  (message length parameter is greater
> > than actual M3UA data buffer size)
> >
> > Is this expected??? Please comment on this...
>
> At least the behaviour of the sender is not expected, since the sender
> violates a MUST.

I'm not sure what the note in section 3.1.4 is trying to allow, but
I think the message you are describing is definitely illegal.

I believe that the overall length in the 'common' header should always
match that of the SCTP data chunk.
This allows M3UA data to be separated into messages when sent using (say)
TCP rather than SCTP.

I suspect the note allows an implementation to add the pad (following a
parameter) when it adds a new one, rather than when it adds a parameter
that isn't a multiple of 4 bytes.

In any case I'd change your sending end.

        David


 


Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

P Please consider the environment and don't print this e-mail unless you really need to


_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
santosh nayak | 10 Oct 11:40 2013
Picon

M3UA: Message Length

Hi,

We have a situation where message is being rejected at M3UA layer due to buffer length is not equal to message length. 

What is the significance of Message Length and its importance with padding...

in the current issue M3UA peer is sending the data buffer of size 122 bytes to KSCTP. But message length parameter of M3UA common header contains a value of 124 and KSCTP is doing the padding at its level of 2 bytes which is observed from the wireshark traces. 

Now at DUT message droped with reason  (message length parameter is greater than actual M3UA data buffer size


Is this expected??? Please comment on this...


As per RFC 4666
------------------------

3.1.4.  Message Length: 32-Bits (Unsigned Integer)

 

   The Message Length defines the length of the message in octets,

   including the Common Header.  The Message Length MUST include

   parameter padding octets, if there are any.

 

   Note: A receiver SHOULD accept the message whether or not the final

   parameter padding is included in the message length.

---------------------



Thanks,
Santosh


_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran

Gmane