Nagesh shamnur | 30 May 12:58 2016

Query regarding Interface Identifier parameter as per the RFC 4233/3057

Hi Group,

                As per as part of adhering to RFC 4233/ RFC 3057 regarding Interface identifier, we have met a situation where I thought it would be apt to query the correct way in the group. The protocol definition for "Interface Identify " as per the RFC is mentioned as integer range with value from 0 UINT_MAX. While processing the ASPAC message, if the Interface identifier Start is given as 0 and Interface identifier End is given as UINT_MAX(2%32), then it can result in a big loop in the code which can spike the CPU.  Is there any recommendations from the protocol side to avoid such a problem?

 

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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |           Tag (0xb)           |             Length            |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                     Traffic Mode Type                         |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |     Tag (0x1=integer)         |            Length             |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

   |                     Interface Identifiers*                    |

 

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |    Tag (0x8=integer range)    |            Length             |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                 Interface Identifier Start1*                  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                  Interface Identifier Stop1*                  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                 Interface Identifier Start2*                  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                  Interface Identifier Stop2*                  |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Regards,

Nagesh.

 

_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
RFC Errata System | 31 Oct 08:12 2015

[Errata Held for Document Update] RFC4666 (4475)

The following errata report has been held for document update 
for RFC4666, "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4666&eid=4475

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Valentin Micic <v <at> pharos-avantgard.com>
Date Reported: 2015-09-14
Held by: Ben Campbell (IESG)

Section: 3.6.1, Pg 53

Original Text
-------------
The optional SI [7,8] field contains one or more Service
      Indicators from the values described in the MTP3-User Identity
      field of the DUPU message.  The absence of the SI parameter in the
      Routing Key indicates the use of any SI value, excluding of course
      MTP management.  Where an SI parameter does not contain a multiple
      of four SIs, the parameter is padded out to 32-byte alignment.

Corrected Text
--------------
The optional SI [7,8] field contains one or more Service
      Indicators from the values described in the MTP3-User Identity
      field of the DUPU message.  The absence of the SI parameter in the
      Routing Key indicates the use of any SI value, excluding of course
      MTP management.  Where an SI parameter does not contain a multiple
      of four SIs, the parameter is padded out to 32-bit alignment.

Notes
-----
It seems obvious that diagram is referring to 32-bit and not 32-byte (as in 32-octets) alignment.

--------------------------------------
RFC4666 (draft-ietf-sigtran-rfc3332bis-06)
--------------------------------------
Title               : Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
Publication Date    : September 2006
Author(s)           : K. Morneault, Ed., J. Pastor-Balbas, Ed.
Category            : PROPOSED STANDARD
Source              : Signaling Transport
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
David Laight | 16 Sep 11:30 2015

Re: [Editorial Errata Reported] RFC4666 (4475)

(Sorry I’m forced to top post)

 

It would be interesting to know what has actually been implemented.

(No one will have generated 32 byte alignment.)

We’d assumed that the parameter length excluded any required pad, and that

the diagram showed it because this was one place where padding was likely to be needed.

 

Indeed how many implementations actually support the key management messages.

AFAICT the main commercial implementation of M3UA still uses RFC 3332.

 

If the length of this parameter includes these pad bytes, then what should you do

if a zero is followed by a non-zero byte?

 

                David

 

 

 

There's a clear statement on page 32 of RFC 4666 that indicates that the "Parameter Length does not include any padding octets".

Even though SI parameter specification violates this "rule", it is quite plausible that there may be a number of implementations that may have followed this specification with padding octets.

 

Thus, how practical would it be to indicate that there will be no padding for SI parameter that does not contain multiple of four SIs, considering that we may end up converting a number of  compliant implementations into a score of non-compliant ones.

 

I think that changing 32-byte to 32-bit alignment is much safer (and considerably cheaper) option.

 

Kind regards

 

V/

 

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
RFC Errata System | 15 Sep 01:48 2015

[Editorial Errata Reported] RFC4666 (4475)

The following errata report has been submitted for RFC4666,
"Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4666&eid=4475

--------------------------------------
Type: Editorial
Reported by: Valentin Micic <v <at> pharos-avantgard.com>

Section: 3.6.1, Pg 53

Original Text
-------------
The optional SI [7,8] field contains one or more Service
      Indicators from the values described in the MTP3-User Identity
      field of the DUPU message.  The absence of the SI parameter in the
      Routing Key indicates the use of any SI value, excluding of course
      MTP management.  Where an SI parameter does not contain a multiple
      of four SIs, the parameter is padded out to 32-byte alignment.

Corrected Text
--------------
The optional SI [7,8] field contains one or more Service
      Indicators from the values described in the MTP3-User Identity
      field of the DUPU message.  The absence of the SI parameter in the
      Routing Key indicates the use of any SI value, excluding of course
      MTP management.  Where an SI parameter does not contain a multiple
      of four SIs, the parameter is padded out to 32-bit alignment.

Notes
-----
It seems obvious that diagram is referring to 32-bit and not 32-byte (as in 32-octets) alignment.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4666 (draft-ietf-sigtran-rfc3332bis-06)
--------------------------------------
Title               : Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
Publication Date    : September 2006
Author(s)           : K. Morneault, Ed., J. Pastor-Balbas, Ed.
Category            : PROPOSED STANDARD
Source              : Signaling Transport
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
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

Gmane