Subject: [Sigtran] SIGTRAN specs: Some doubts

From: aditi someshwar <[email-masked]>
Date: Mon, 8 Aug 2011 14:34:30 +0530

Hi,

We are a "Telecom Training Group" based out of India. Listed below, are few
doubts from our study of the SIGTRAN RFC documents. We would be grateful if
you can contribute with the clarifications.
The list of queries is long, and we have segregated the points as per the
SIGTRAN topics.. you may like to address any point that you are clear about.

*SCTP:*

* *

SCTP 1) We have understood that there are three mechanisms of
RE-TRANSMISSION –

(i)                  One governed by TIMER that is started each time any
message is sent (within this timer, an ACK must arrive for the UDM);

(ii)                If for a given message, an indication is received FOUR
TIMES CONSECUTIVELY in the SACK that "so & so" message is a missing sequence
case; (iii) under CHANGEOVER. Is that correct, OR are

(iii)               there any more conditions that we have missed? Having
concluded  that RE-TRANSMISSION has to be done, is there a MANDATE that such
RE-TRANSMISSIONs must be done using SECONDARY PATH (for the same
association) even when the PRIMARY PATH is healthy? Are "Primary Path" and
"Secondary Path" pre-nominated (defined by human being at the time of
configuration) OR are they dynamically changed depending on which path is up
at any given point in time, & which one came up later etc?

*User Adaptation (General):*

* *

UA 1) What is the exact meaning of "proper management" of streams in UA
layer?

For example: RFC 4165: It is the responsibility of the M2PA layer to ensure
proper management of the streams allowed within each association. Another
example of this is in 1.5.4.1 of RFC 3331 (M2UA) which states: "SCTP allows
a user specified number of streams to be opened during initialization of the
association.  It is the responsibility of the M2UA layer to ensure proper
management of these streams.  Because of the unidirectional nature of
streams, a M2UA layer is not aware of the stream information from its peer
M2UA layer (our query is WHY SHOULD IT BE AWARE??).  For this reason, the
Interface Identifier is in the M2UA message header"; perhaps, the NEED for
communicating the INTERFACE ID from one M2UA to its PEER also arises from
this "responsibility" that M2UA (or any adaptation layer - for that matter)
must PROPERLY MANAGE the Streams - - is that correct?? If so, the question
of "what is 'proper management' becomes more crucial!!

UA 2) Definition of "IPSP" in RFC4666 (M3UA) & RFC 3868 SUA refers to IP
Server Process where as in RFC4165 (M2PA) refers to IP Signalling Point. Is
it an error that same accronym has been used in

different RFCs to represent entities or is there a point that we are
missing?

Moreover in RFC3331 (M2UA) it is completely absent - it keeps refering to
MGC; can we not say that MGC is also an IPSP (to us IPSP appears to be a
more generic term than MGC, Is it correct?).It is understandable that IPSP
as a term is missing as a term for SCTP.

UA 3) We find that definition of SG in various RFCs is broadly similar with
minor variations (e.g. M3UA states that SG has a Point Code, while M2UA does
not naturally have any reference to Point Code). We are a bit concerned and
confused as to why IETF has chosen to make definitions RFC specific.

*M2PA:*

* *

M2PA 1) RFC 4165: 4.1.2

Figure 10.  Multiple Associations Between Two IP Addresses

are there any guidelines for choosing "pre-selected port number"? (P1)

M2PA 2) RFC 4165: 4.1.4

Processor Outage

M2PA (at both the LPO and RPO ends) uses the BSN value in the received Link
Status Ready message to resynchronize its sequence numbers, if this is
required by MTP2.  M2PA SHALL NOT resume transmitting User Data messages
until it has sent the Link Status Ready message. Why does it mention MTP2?

M2PA 3) RFC 4165: 4.1.5: Flow Control

When the peer M2PA receives the first Link Status Busy message, it SHALL
start the Remote Congestion timer T6 if there are messages in the
retransmission buffer awaiting acknowledgement (i.e., T7 is running).  M2PA
SHALL stop the T7 timer if it is running.  Additional Link Status Busy
messages received while T6 is running do not cause T6 to be reset and do not
cause T7 to be started.  While T6 is running, T7 SHALL NOT be started. When
the peer M2PA receives the Link Status Busy Ended message and T6 has not
expired, it SHALL stop T6 (if T6 is running) and start T7 (if there are
messages awaiting acknowledgement in the retransmission buffer).

M2PA 4) Do you recall in RFC 4165 (or any other RFC) a reference to SSN
being used as a parameter for  "Changeover" with most significant 8 bits
being set to zero? Is there a relation between FSN / BSN of M2PA and TSN /
SSN of SCTP?

*M2UA:*
M2UA 1) While using M2UA, is there a restriction that on SS7 side of an SG,
there can be only "one type" of node (say, PSTN Classical Switch) and on IP
side of THAT SG, there can be only "one type" of node (say, MGC)? In one of
tutorials (ZYTRAX), we have come across an expression that says: "The whole
IP network is represented by a single point code that addresses the MGC at
the network edge. Therefore all messages from the SS7 side going to the IP
side are sent to the MGC through the SG. Do you agree with this statement?
If yes, is that UNCONDITIONAL or this statement is true only under certain
environment (like M2UA)?? Is ZYTRAX, for example, making this statement only
for a certain scenario - where M2UA is deployed for connecting up (say) PSTN
SS7 node with MGC?

* *

M2UA 2) While using M2UA, is there a restriction that on SS7 side of an SG,
there can be only "one type" of node (say, PSTN Classical Switch) and on IP
side of THAT SG, there can be only "one type" of

M2UA 3) In the RFC, it is stated that the M2UA SPECIFIC HEADER is present IF
AT ALL only for MAUP Message Class; however, it goes on to say that it may
or may NOT be present in even when the message is an MAUP (MTP-2 User
Adaptation Messages / Protocol??) messages. Thus, after Common Header,
DIRECTLY, parameters may follow in T-L-V format.

(i)                  Is it prescribed as to WHEN this can be (should be)
absent, & when not - - e.g. does Message Type automatically give any clue
for this??

(ii)                How does the RECEIVING ENTITY come to know whether the
M2UA specific header is present or not - - -is it by looking at the TWO
BYTES that follow "end of COMMON HEADER (message length)", & if the value
therein is "01 (Hex) - indicating Integar Value for IId", THEN CONCLUDE that
the (M2UA specific) header is present & IF IT IS ANYTHING OTHER THAN 01H
(or, of course, 03H for ANSI Networks), then TRY TO INTERPRET the same as a
"Parameter Tag"??

M2UA 3) In one of the (SS7 – with INTRO to SIGTRAN) training sessions that
we held last month, one of the trainees informed us that they have
“deployed” M2UA in the sense that they have a CLUSTER OF BLADE SERVERS in
their MGC. All those blades are represented by a SINGLE SIGNALLING POINT
CODE, but EACH has a unique GT. The M2UA is used INTERNALLY between the SS7
front end (the “master server”- so to say), & the “back-end” cluster of
Blade Servers. Is this a typical usage that you have seen too (we ask this
because it is usually very rare to SEE / get an example of, an M2UA
deployment !!)?

*M3UA:*

* *

M3UA 1) Section 1.1, Terminologies, states “Where an SG contains more than
one SGP, the SG is a logical entity, and the contained SGPs are assumed to *be
coordinated into a single management view* to the SS7 network and to the
supported Application Servers”.  We are confused about what the underlined
part means.

M3UA 2) RFC also states that “An IPSP is essentially the same as an ASP,
except that it uses M3UA in a *point-to-point fashion*.” What does
“point-to-point” mean?

M3UA 3) Routing Context is a 4 – byte number having a one-to-one
relationship with Routing Key. Moreover, Routing context is also transmitted
from 1 node to the other as part of the message. Is it correct to interpret
that Routing Context is something similar to “Translation Type” use in SCCP
– meaning possibly that the receiving node indexes a “ (specific / desired)
table” basis the received RC value, & LOOKS for Routing Key within that
table?

Thanks and Regards,

Aditi

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 8 Aug 2011 15:54:39 -0600

aditi,

aditi someshwar wrote:                                                                                                                                                                                                      (Mon, 08 Aug 2011 14:34:30)
>    Hi,
> 
>    We are a "Telecom Training Group" based out of India. Listed below, are
>    few doubts from our study of the SIGTRAN RFC documents. We would be
>    grateful if you can contribute with the clarifications.
> 
>    The list of queries is long, and we have segregated the points as per
>    the SIGTRAN topics.. you may like to address any point that you are
>    clear about.
> 
>    SCTP:
> 
> 
>    RE-TRANSMISSION
>    (i)                  One governed by TIMER that is started each time
>    any message is sent (within this timer, an ACK must arrive for the
>    UDM);

Well, no.  The time is started when a message is sent when it is not
already running.  That is different than on each message.  There are
a number of other conditions under which the timer should be started,
such as on a reneged TSN when no other data is in flight (i.e. the
timer is not running).

>    (ii)                If for a given message, an indication is received
>    FOUR TIMES CONSECUTIVELY in the SACK that "so & so" message is a
>    missing sequence case; (iii) under CHANGEOVER. Is that correct, OR are
> 
>    (iii)               there any more conditions that we have missed?

That is a simplification of the major two.  Some others:

- Retransmission can be invoked when a destination is deemed failed and
  there is data outstanding to that destination.

- Retransmission is invoked when the peer renegs on an TSN.

There are probably more.  Also, there are a number of instances under
CMT where retransmissions of the first two varieties need to be
suppressed to avoid excessive spurious retransmissions.

>    Having concluded  that RE-TRANSMISSION has to be done, is there a
>    MANDATE that such RE-TRANSMISSIONs must be done using SECONDARY PATH
>    (for the same association) even when the PRIMARY PATH is healthy? Are
>    "Primary Path" and "Secondary Path" pre-nominated (defined by human
>    being at the time of configuration) OR are they dynamically changed
>    depending on which path is up at any given point in time, & which one
>    came up later etc?

This is an entire field of study.

> 
>    User Adaptation (General):
> 
> 
>    For example: RFC 4165: It is the responsibility of the M2PA layer to
>    ensure proper management of the streams allowed within each
>    association. Another example of this is in 1.5.4.1 of RFC 3331 (M2UA)
>    which states: "SCTP allows a user specified number of streams to be
>    opened during initialization of the association.  It is the
>    responsibility of the M2UA layer to ensure proper management of these
>    streams.  Because of the unidirectional nature of streams, a M2UA layer
>    is not aware of the stream information from its peer M2UA layer (our
>    query is WHY SHOULD IT BE AWARE??).  For this reason, the Interface
>    Identifier is in the M2UA message header"; perhaps, the NEED for
>    communicating the INTERFACE ID from one M2UA to its PEER also arises
>    from this "responsibility" that M2UA (or any adaptation layer - for
>    that matter) must PROPERLY MANAGE the Streams - - is that correct?? If
>    so, the question of "what is 'proper management' becomes more crucial!!

Management of stream consists of requesting and negotiating the number
of inbound and outbound streams with the peer, and then selecting the
stream on which to transmit a given message considering the sequence
requirements of the message flows.

>    UA 2) Definition of "IPSP" in RFC4666 (M3UA) & RFC 3868 SUA refers to
>    IP Server Process where as in RFC4165 (M2PA) refers to IP Signalling
>    Point. Is it an error that same accronym has been used in

M2PA and M3UA are different.  M2PA represents a signalling link.  The
entities at either end of a signalling link must be a signalling point.
In M3UA there is no such requirement, it can be a process on a host.

>    Moreover in RFC3331 (M2UA) it is completely absent - it keeps refering
>    to MGC; can we not say that MGC is also an IPSP (to us IPSP appears to
>    be a more generic term than MGC, Is it correct?).It is understandable
>    that IPSP as a term is missing as a term for SCTP.

No, IPSP is a SIGTRAN term, not an SCTP term.  It is defined in the RFC
in which it is used.

>    UA 3) We find that definition of SG in various RFCs is broadly similar
>    with minor variations (e.g. M3UA states that SG has a Point Code, while
>    M2UA does not naturally have any reference to Point Code). We are a bit
>    concerned and confused as to why IETF has chosen to make definitions
>    RFC specific.

Because the RFCs are different and operate at different levels of the
SS7 stack.  M3UA transport MTP/MTP-User (Level 3) interface primitive.
For MTP (Level 3) the MTP-Entity-Identifier is a point code.  M2UA
operates at MTP Level 2.  The identifier for a signalling terminal is
a signalling terminal identifier and/or signalling data link identifier.
The interface identifier is used in this manner.

>    M2PA:

Yes, the well-known M3UA port number.

>    M2PA 2) RFC 4165: 4.1.4
> 
>    Processor Outage
> 
>    M2PA (at both the LPO and RPO ends) uses the BSN value in the received
>    Link Status Ready message to resynchronize its sequence numbers, if
>    this is required by MTP2.  M2PA SHALL NOT resume transmitting User Data
>    messages until it has sent the Link Status Ready message. Why does it
>    mention MTP2?

Because we did not want to transcribe each of or any of the
international nor 49 national flavors of MTP2 specifiacations into the
document.

>    When the peer M2PA receives the first Link Status Busy message, it
>    SHALL start the Remote Congestion timer T6 if there are messages in the
>    retransmission buffer awaiting acknowledgement (i.e., T7 is running).
>    M2PA SHALL stop the T7 timer if it is running.  Additional Link Status
>    Busy messages received while T6 is running do not cause T6 to be reset
>    and do not cause T7 to be started.  While T6 is running, T7 SHALL NOT
>    be started. When the peer M2PA receives the Link Status Busy Ended
>    message and T6 has not expired, it SHALL stop T6 (if T6 is running) and
>    start T7 (if there are messages awaiting acknowledgement in the
>    retransmission buffer).

Is there a question in there?

>    being used as a parameter for  "Changeover" with most significant 8
>    bits being set to zero? Is there a relation between FSN / BSN of M2PA
>    and TSN / SSN of SCTP?

Only 24-bits are significant because the XCO/XCA can only accept 24
bits.  There is no relationship between FSN/BSN and TSN/SSN.

>    M2UA:
>    M2UA 1) While using M2UA, is there a restriction that on SS7 side of an
>    SG, there can be only "one type" of node (say, PSTN Classical Switch)
>    and on IP side of THAT SG, there can be only "one type" of node (say,
>    MGC)? In one of tutorials (ZYTRAX), we have come across an expression
>    that says: "The whole IP network is represented by a single point code
>    that addresses the MGC at the network edge. Therefore all messages from
>    the SS7 side going to the IP side are sent to the MGC through the SG.
>    Do you agree with this statement? If yes, is that UNCONDITIONAL or this
>    statement is true only under certain environment (like M2UA)?? Is
>    ZYTRAX, for example, making this statement only for a certain scenario
>    - where M2UA is deployed for connecting up (say) PSTN SS7 node with
>    MGC?

M2UA has no IPSP mode, just ASP/SG mode.  M2PA is used where you would
want to use M2UA for IPSP.

>    M2UA 2) While using M2UA, is there a restriction that on SS7 side of an
>    SG, there can be only "one type" of node (say, PSTN Classical Switch)
>    and on IP side of THAT SG, there can be only "one type" of

Same as above.

>    M2UA 3) In the RFC, it is stated that the M2UA SPECIFIC HEADER is
>    present IF AT ALL only for MAUP Message Class; however, it goes on to
>    say that it may or may NOT be present in even when the message is an
>    MAUP (MTP-2 User Adaptation Messages / Protocol??) messages. Thus,
>    after Common Header, DIRECTLY, parameters may follow in T-L-V format.
> 
>    (i)                  Is it prescribed as to WHEN this can be (should
>    be) absent, & when not - - e.g. does Message Type automatically give
>    any clue for this??

It is detailed in the message format of each message in the RFC.

>    (ii)                How does the RECEIVING ENTITY come to know whether
>    the M2UA specific header is present or not - - -is it by looking at the
>    TWO BYTES that follow "end of COMMON HEADER (message length)", & if the
>    value therein is "01 (Hex) - indicating Integar Value for IId", THEN
>    CONCLUDE that the (M2UA specific) header is present & IF IT IS ANYTHING
>    OTHER THAN 01H (or, of course, 03H for ANSI Networks), then TRY TO
>    INTERPRET the same as a "Parameter Tag"??

The header is not optional: it is included in some message types and not
in others.  The message type determines whether the header must be there
or not.

>    M2UA 3) In one of the (SS7 with INTRO to SIGTRAN) training sessions
>    that we held last month, one of the trainees informed us that they have
>    deployed M2UA in the sense that they have a CLUSTER OF BLADE SERVERS in
>    their MGC. All those blades are represented by a SINGLE SIGNALLING
>    POINT CODE, but EACH has a unique GT. The M2UA is used INTERNALLY
>    between the SS7 front end (the master server- so to say), & the
>    back-end cluster of Blade Servers. Is this a typical usage that you
>    have seen too (we ask this because it is usually very rare to SEE / get
>    an example of, an M2UA deployment !!)?

M2UA served a purpose for legacy arrangements that is not so prevalent
any more.  Nevertheless, ETSI/3GPP proscribes is use in a number of
scenarios.

>    M3UA:
> 
>    M3UA 1) Section 1.1, Terminologies, states Where an SG contains more
>    than one SGP, the SG is a logical entity, and the contained SGPs are
>    assumed to be coordinated into a single management view to the SS7
>    network and to the supported Application Servers.  We are confused
>    about what the underlined part means.

An SG has a point code, regardless of the number of SGPs providing
identical access to the SS7 network through that point code.  Remember
that a point code is an MTP-Level3-Entity-Identifier in the SS7 network.

>    M3UA 2) RFC also states that An IPSP is essentially the same as an ASP,
>    except that it uses M3UA in a point-to-point fashion. What does
>    point-to-point mean?

One IPSP is at one MTP end-point, the other is at the other MTP
end-point.  There is no relay point (STP), or other MTP entity between
them.  They are used in this point-to-point fashion.

>    M3UA 3) Routing Context is a 4 byte number having a one-to-one
>    relationship with Routing Key. Moreover, Routing context is also
>    transmitted from 1 node to the other as part of the message. Is it
>    correct to interpret that Routing Context is something similar to
>    Translation Type use in SCCP meaning possibly that the receiving node
>    indexes a (specific / desired) table basis the received RC value, &
>    LOOKS for Routing Key within that table?

It has no relation to TT.  It is closer to the concept of a combined
routeset under MTP.

--brian

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

---

From: aditi someshwar <[email-masked]>
Date: Tue, 16 Aug 2011 15:05:01 +0530

Brian,

Thank you very much for the Clarifications.
Have put in responses to two points below (in green), if you can please give
your views.

Thanks and Regards,
Aditi

On Tue, Aug 9, 2011 at 3:24 AM, Brian F. G. Bidulock
<[email-masked]>wrote:

> aditi someshwar wrote:
>                                                                      (Mon,
> 08 Aug 2011 14:34:30)

*Aditi:*

*The BLOW UP of this {& hence, to elaborate on the exact question we have},
the following hypothetical example is perhaps the best way:*

*A. - - - >>> (Just to keep matters simple) We shall assume that ONLY ONE
NODE has any messages to send; Node B has none.*

*B. - - >>> Assume that the "need" for sending the FIRST message (say, with
TSN = 240) arose at exactly 14:00 hrs on 09 Aug 2011. Let us also assume
(for simplicity again) that no timer was running. When Node A (i.e its SCTP)
sends  TSN = 249, we presume that a TIMER T shall now be started. Just to
bring out out exact query more clearly, let us assume that timer is 60
Minutes (!!). Now, let us further assume that Node A keeps getting a "need"
to send a (fresh) message every 1 minute, for next 40 minutes (& after that,
it too has no more FRESH messages to send - - ASSUME, for simplicity again).
We are making some statements below - EACH of which needs to be confirmed or
modified ::::*

*C. - - - >>>> When TSN = 241 is sent (at 14:01 hrs / 09 Aug 2011), TIMER T
shall be RESET (so now it will "blow the whistle at 15:01 hrs, rather than
at 15;00 hrs IF IT HAD NOT BEEN RESET).*

*D. - - - >>> When, similarly, TSN = 242 is sent, the timer T is AGAIN reset
& so on. So, when TSN = 299 is sent (at 14:40 hrs / 09 Aug 2011), it shall
be "set" to "blow its whistle" at 15:40 hrs.*

*E1. (scenario 1)- - - >>> Assume that ALL TSNs get ACKed (whether
sequentially or otherwise) before 14:50 hrs / 09 Aug 2011, THEN, according
to our belief, timer T shall be RESET TO PASSIVE MODE in "not active mode
(not counting any-more); such RESET shall occur according to us at the
instant LAST of the ACKs is received. In this example (scenario), NO
RETRANSMISSION shall occur owing to "blowing up of the timer T's whistle".*

*E2. (scenario 2) - - - >>> Assume that ALL TSNs BUT TSNs 244, 256 & 299 get
ACKed (whether sequentially or otherwise) upto 15:40 hrs / 09 Aug 2011,
 THEN, according to our belief, timer T shall  "blow up its whistle", & post
that, ONLY these three TSNs shall be RE-TRANSMITTED*

*Is the above understanding correct?*

> want to use M2UA for IPSP.

*Aditi: Can you tell us the difference between IPSP and ASP? *

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 16 Aug 2011 04:19:50 -0600

Aditi,

aditi someshwar wrote:                    (Tue, 16 Aug 2011 15:05:01)
> 
> 
>    C. - - - >>>> When TSN = 241 is sent (at 14:01 hrs / 09 Aug 2011),
>    TIMER T shall be RESET (so now it will "blow the whistle at 15:01 hrs,
>    rather than at 15;00 hrs IF IT HAD NOT BEEN RESET).

Have you ever read the specification?  If so, reread the paragraph
at the bottom of page 77.

--brian

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