Re: SIGTRAN specs: Some doubts

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 protected]>wrote:

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

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

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

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

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

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