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
(Continue reading)

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
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

Gmane