Re: SIGTRAN specs: Some doubts

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:
> 
> 
>    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);

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):
> 
> 
>    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!!

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
>    different RFCs to represent entities or is there a point that we are
>    missing?

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

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.

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

Is there a question in there?

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

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 protected]
http://www.openss7.org/