prabath weerasinghe | 22 Jul 14:05 2016
Picon

How a SG selects through which association a DUNA or a SCON message sent.

Hi All, 

This is regarding M3UA SSNM messages. 

1. Take an ASP with 2 SCTP link sets with each link set having 2 associations, connecting to two different SGs.

         | - - - - -> Link Set 1 (2 Associations) - - - - -> SG 1  - - - - - >| 
ASP  |                                                                                              | HLR-1
         | - - - - -> Link Set 2 (2 Associations) - - - - -> SG 2  - - - - - >|


    If all connections between SG-1 and the HLR-1 break,  the ASP would  be notified with a DUNA.
    My question is through which SCTP connection between the ASP and SG-1, the DUNA would be sent in a proper SG implementation? 
    Would it be sent to both connections or to a randomly selected one ?
   


Thanks and Regards,


--
Prabath Weerasinghe
_________________________________________________________________________________
Confidentiality and Disclaimer

This email and any attachments are intended only for the person or entity to whom it is addressed. Its contents may be privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient, please do not read, disclose, distribute or copy this email or use the information therein or act or omit to act in reliance thereof. Please also inform the sender of erroneous receipt and delete the material from your system.
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
prabath weerasinghe | 21 Jul 10:37 2016
Picon

Concern on the M3UA SSNM request, DUPU.

Hi All,

I was referring the rfc4666 for M3UA and have few concerns regarding the DUPU SSNM message. 
The specification says that a DUPU indicates the unavailability of a certain user part.

If I may quote;
The DUPU message is used by an SGP to inform concerned ASPs that a
remote peer MTP3-User Part (e.g., ISUP or SCCP) at an SS7 node is unavailable"

I have two questions.
1.  How these concerned ASPs are identified. 
     Is it upon receiving a MTP-Transfer for a particular user part (say SCCP) or can it      be sent periodically for a given ASP ?

2. I couldn't find any SSNM message that indicates a User Part's  Availability. Am I wrong here to expect such a message and if so how come a concerned ASP know if a     certain User Part is available at a given point code.

It would be an immense help if anyone could clarify the aforementioned concerns.

Thanks and Regards,

--
Prabath Weerasinghe

_________________________________________________________________________________
Confidentiality and Disclaimer

This email and any attachments are intended only for the person or entity to whom it is addressed. Its contents may be privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient, please do not read, disclose, distribute or copy this email or use the information therein or act or omit to act in reliance thereof. Please also inform the sender of erroneous receipt and delete the material from your system.
_______________________________________________
Sigtran mailing list
Sigtran <at> ietf.org
https://www.ietf.org/mailman/listinfo/sigtran
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

Gmane