SIGTRAN specs: Some doubts

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

_______________________________________________
Sigtran mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sigtran