Subject: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2

From: Ken Morneault <[email-masked]>
Date: Tue, 05 Nov 2002 17:24:17 -0500

Below is a summary of issues / comments raised during the first
day of testing at the plugtest:

SUA 
--------

1.  sequence number parameter is mandatory for protocol class 3 in the CORE
msg while the data is optional.
The sequence number parameter is directly related to the data. If NO data is
present(class3), then no sequence number can be provided. If data is
present(Class3), then the sequence number must be provided. The note in the
spec is not completely clear on this issue. Remove the note(making both
optional) or clarify the note via similar text as provided above(clarify the
dependency).

2.   the implementation note on the sequence of parameters (or rather on the
non-sequenced nature of the parameters) is a bit contradicting. If it is
truly a set of parameters(meaning not fixed sequence of parameters to occur),
then the implementation notes may sometimes contradict each other and imply
a certain sequence of parameters. Maybe the note can be removed or changed
to "the parameters in a SUA msg should be seen as a set with each parameter
only occurring once, with no fixed ordering  

M3UA
---------

1. The last test case in the test plan shows a scenario in which the
ASP does not have NA configured but the SGP does.  It indicates the
ASP should accept message from SGP with NA but SGP should 
send an Error message to the ASP if it sends a message without
NA.

Recommendation:  This behavior is incorrect since NA is optional.
An Error should only be appropriate in the case of NA configured
on both sides and an incorrect NA value was found in a message.

2.  Concern about the state of IPSP.  With IPSP as single-exchange,
there is an issue related to dynamic registration.  General consensus
is that dynamic registration needs to be double-exchange to avoid
potential for race condition.  Thus, there is a desire to move back
to double-exchange.

3.  Does a message have to match one Routing Key?  This question
arose from the following scenario:

      REG REQ (RK1, DPC X)
      REG REQ (RK2, DPC X, SI ISUP)

One SG treats this as an overlapping RK and sends an Error for the
second REG REQ.  Another SG treats it as an overlapping RK, but
allows the configuration because it supports hierarchical RKs.  
With hierarchical RKs, a message can match more than one RK, but
the best match is taken.

4.  Is the NTFY message mandatory.

Recommendation:  The RFC indicates that it is.  Check text to make
sure this is clear for all conditions.

5.  Should NTFY be sent before or after a ASPSM or ASPTM Ack.

Recommendation:  Send after, because if sent before in the case
of ASP Up Ack, the ASP still considers itself "Down" and may 
drop the NTFY.

6.  What should SG do in the following situation:

        ASP1:  SPC 100, RC X
        ASP2:  SPC 200, RC Y

ASP1 sends a SCON (APC 100, CPC 200, RC X).  Does
SG send a SCON to ASP2.  If so, does SG maintain congestion
state?  There is no way for SG to audit congestion of ASP1.

One recommendation:  SG sends SCON to ASP2.  Maintains
a timer that decreases congestion level every time it triggers.
Further recommendation was to evaluate based on end-to-end
congestion principle in SS7.  Need to make sure solution works
equally well for ANSI and ITU.

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 5 Nov 2002 17:35:35 -0500

Ken,

> potential for race condition.  Thus, there is a desire to move back
[TOLGA] What is exactly the problem scenario? Is the proposal to move just
dynamic registration to double exchange or the whole IPSP model? 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: [email-masked]
Date: Wed, 6 Nov 2002 10:47:21 +0530

hi
     Tolga  I am not able to understand how TFC is similar to
      TFP as suggested by you below, also how ASP goes inactive after sending
SCON
      message back to SG1. Please clearify.

Regards
Kamesh

Tolga Asveren <[email-masked]> on 11/06/2002 08:55:15 AM

To:   [email-masked]
cc:    (bcc: Kamesh Kaul/HSS)

Subject:  RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2

A correction:
IMO, SCON should be sent to ASP2, based on RFC3332. I
didn't pay attention that CPC = SPC of ASP2, sorry for
that.
But this is really an interesting scenario:
Let's assume PC 100 was in TDM domain. In such a case,
SG would execute relevant congestion test procedures
on behalf of ASP2(which has sent the message causing
TFC/SCON to be generated). And let's furthermore
assume, this is an ANSI network. In this case, SG
would generate RCT messages. But now what? Based on
that one might argue introducing a SSNM counterpart
for RCT (which is really necessary for SG-SG case but
IMO not for ASP/SGP case)
As indicated in my former message, following MTP3
congestion method between SGP and ASP is not a good
idea IMO. Like SGP combines information from ASPs and
generates TFP/TFA/DUNA/DAVA, the same should apply
also for TFC/SCON. Consider the following
configuration:
  AS1:1-1-1  AS1:1-1-1    AS1:1-1-1
   +----+   +----+        +----+
   |ASP1|   |ASP2|        |ASPn|
   +-+--+   +--+-+ . . .  +--+-+
     |         |             |
     |         |             |
     |         |  |  |       |
     |         |  |  |       |
     |    +----+--+--+--+    |
     +----+    SG1      +----+
          |             |
          +-----+-------+
                |
                |
              TDM based SS7 network

Let's say one message arrives from SS7 network with
DPC=1-1-1 to SG1 and it routes it to one of the
ASPs(AS mode is loadsharing for AS1)And if that ASP is
congested because of that message SCON will be sent
from ASP to SG and SG will generate a corresponding
TFC. This is similar to generating TFP, because one of
the ASPs goes INACTIVE for AS1. But if a method, where
each ASP declares its congestion to SG, whenever it
happens, SG has the combined SPMC view and decide-in
an implementation dependent way-, when to reply with
TFC(SCON if the initiator is in IP domain) to an
incoming message destined for AS1.

    Tolga

--- Tolga Asveren <[email-masked]> wrote:
> Some comments below.
>    Tolga
> [TOLGA] In such a situation, I wouldn't expect that
> SCON is sent to ASP2,
> based on the current RFC3332(because it is sent as
> reply to an incoming
> message). But as a lot of people might recall, we
> had some discussions about
> the current congestion announcement procedure from
> ASP to SGP recently. I
> think, the current approach does not fit M3UA model.
> Trying to mimic
> congestion mechanims of MTP3 between SGP and ASP is
> not the correct approach
> in my opinion. Congestion should be informed from
> ASP to SGP, whenever it
> happens, not as a response to an incoming message.
> SG controls the SPMC and
> can decide, whenever to reply with TFC or SCON to a
> message. I furthermore
> would prefer a new ASPTM message for it.
>

__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: [email-masked]
Date: Thu, 7 Nov 2002 13:41:24 +0530

Hi
I guess the original issue remains unresolved here.

> incoming message destined for AS1.

SCON is to be sent as the initiator, which is ASP2, lies in IP domain. But then
how does ASP2 update the congestion status of ASP1 later, when ASP1 is no
more congested.
Though SG may receive SCON(Cong level = 0) from ASP1 later, but how would
it know that this should be informed to ASP2, if there is no "Concerned
Destination"
parameter in the 2nd message.

-neeraj

Tolga Asveren <[email-masked]> on 11/06/2002 07:06:52 PM

To:   [email-masked]
cc:   Tolga Asveren <[email-masked]> (bcc: Neeraj Jain/HSS)

Hi Kamesh,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 06, 2002 12:17 AM
> To: [email-masked]
> Cc: Tolga Asveren
[TOLGA] Again consider the configuration in the original message. If ASP1
goes INACTIVE for AS1, does SG send TFP to SS7 network or does ASP1 send
DUNA(this is even not allowed, it is strange that SCON is allowed from ASP
to SGP side)? It does not, because there are still other ASPs serving this
AS (i.e. the corresponding PC) -in fact one might argue that when to declare
a destination in IP domain as prohibited is implementation dependent but I
think doing it like I described is a logical way-. SG has the information
for the whole SPMC and can decide about its status. Personally I don't see a
reason, why this shouldn't apply for congestion. Whenever congestion happens
ASPs inform SG, and SG decides for the new SPMC state. When I said "This is
similar to generating TFP, because one of the ASPs goes INACTIVE for AS1.",
what I meant is, in such a case TFP is not generated and so similarly
generating TFc is also wrong. The key point is, it is SG, which has the
combined SPMC view. It can decide, when to send TFC/TFP/TFA for a SPMC, ASPs
don't have the necessary information

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 7 Nov 2002 08:43:34 -0500

Neeraj,

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, November 07, 2002 3:11 AM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] SCON does not need to be initiated by ASP2, this is the key point.
It is MTP3 (i.e. SG) which decides when SPMC is congested. If one wants
still to use SCON to inform congestion at ASP from ASP to SG (which in my
opinion abusing this message), this does not trigger directly a SCON from SG
to ASP2, i.e. SG is not just simply relaying SCON. With SCON from ASP to SG,
SG will update its SPMC view and based on that, if necessary, it will send
SCON to ASP2. And also another point is, congestion indication from ASPs to
SG shouldn't happen as reply to an incoming message but whenever congestion
state changes.
> how does ASP2 update the congestion status of ASP1 later, 
[TOLGA] Again it will be SG, which is going to update ASP2 about the end of
the congestion, not ASP1 itself.
> parameter in the 2nd message.
[TOLGA] The relationship between SG and ASP is a MTP3/MTP3 user part
relationship. When SG decides that SPMC for AS1 is no more congested, it
will inform ASP2 about this.

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 7 Nov 2002 09:13:53 -0500

One comment below.....

   Tolga

> will inform ASP2 about this.
[TOLGA] In fact for that I am not sure. It might be better that ASP2 is
informed, when it send a new message to the congested SPMC, this will be
similar to traditional SS7 case.
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 7 Nov 2002 15:12:44 -0500

typo corrected below(as usuall with a quick answer)

   Tolga

> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, November 07, 2002 3:05 PM
> To: [email-masked]'
> Brian,
> > Without a changeover/changeback or controlled rerouting 
> > procedure it would be
> > very foolish for an SG to change its loadsharing based on a 
> > received SCON.
> > Frankly, even *with* a rerouting procedure it would be very 
> > foolish for an SG
> > to change its loadsharing based on congestion whatsoever.  
> > The possibilities
> > for thrashing and scattering messages within an SLS is boundless.
> [TOLGA]Why it is "foolish"? For example in the example I 
> gave, which problem
> cases would happen?
> > 
> > ANSI T1.111.4/Q.704 only allow use of the transfer restricted 
> > procedure in
> > response to congestion in very narrowly defined situations 
> > (congestion on
> > C-links and nodal congestion at an STP); and this is not 
> one of them.
> [TOLGA] Isn't the relationship between SG/ASP a MTP3/MTP3 user part
> relationship? Even if one has multiple SGs, it is SGs which 
> control SPMC.
> IMO, in fact the strange thing is that messages loadshared to 
> one SG are
      ^^^^^
      ASP
> generating TFC, whereas the ones loadshared to other ASPs don't. This
> happens, if one follows current RFC.
> > 
> > The situation you describe is analogous to signalling links 
> > in a link set.
> [TOLGA] No, IMO it is similar to a case, where one 
> distributes its user
> parts.
> > The "nodal" TFC procedures that SCON was intended to parallel 
> > do not permit
> > transfer-restricted or change in routing procedures as a 
> > result of "nodal" TFC
> > when routing to a SEP.
> [TOLGA] IMO the procedures you are referring to define the 
> relationship
> between SPMCs and nodes in TDM domain and between SPMCs 
> themselves, not the
> relationship between SGs and ASPs.

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 8 Nov 2002 07:55:54 -0500

Brian,

I think it will be more clear (at least for me) to discuss this based on a
configuration:

    +-----+   +-----+    +-----+
    |ASP1 |   |ASP2 |    |ASP3 |
    |     |   |     |    |     |
    +--+--+   +--+--+    +--+--+
       |         |          |
       |         |          |
       |         |          |
       |         |          |
       |         |          |
       |      +--+--+       |
       |      | SG1 |       |
       +------+     +-------+
              +--+--+
                 |
               --+---
            ///      \\\
           |            |
          |   SS7        |
          |   network    |
           |            |
            \\\\    ////
                ----

SG1 is loadsharing between ASPs based on SLS. Let's consider ASP2 is
congested. Then what will happen with messages arriving from SS7 network:

*Based on current SCON mechanism according to RFC3332:
Messages sent to ASP1/ASP3 will be processed. ASP2 will drop the
message(based on the congestion level if applicable) and willr eply with
SCON. It also will fill Concerned Destination field with the OPC of the
incoming message. Now what will SG do? Generate TFC based on that SCON, or
nothing at all?If it sends TFC, how can it reply to a possible future RCT
coming from SS7 network, because in this model ASPs don't update SG,
whenever congestion level changes, they only can generate SCON as reply to
an incoming message.

*How it should work IMO:
a)Whenever ASP gets congested for an AS, it informs SG, so can have the
combined congestion view for SPMC. Whenever traffic to a particular ASP is
switched on or off based on congestion level for a particular priority
level, SG executes necessary procuderes to prevent missequencing.

b)(If all of this routing based on congestion level/message priority is too
complex and we don't see too much added value)Whenever ASP is congested for
an AS, in sends ASPIA to SG. SG can decide, when SPMC is congested based on
the number of ACTIVE ASPs.
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 8 Nov 2002 08:27:33 -0500

Kamesh,

> Sent: Friday, November 08, 2002 8:19 AM
> To: Tolga Asveren
> Cc: [email-masked]
>      Tolga this is fine if SPMC congestion status is updated by
>                  SCONS coming from ASP's serving SPMC TFC will be send
>                  to the conerned PC. We can have a congestion 
> timer per SPMC
>                  which will be triggered when ever SPMC 
> congestion status is
>                  updated.When the timer expires we can 
> decrement the congestion
>                  level of SPMC. This seems similar to RCT 
> procedure. Here in
> this
>                  case RCT messages is nothing but MSU's received from
>                  the SS7 domain.
[TOLGA] I failed understant what you mean exactly (maybe an example might
make it more clear for me). IMO, if ASPs update SG about congestion status
changes, whenever it happens, there is no need for a timer on SG to decide
for the SPMC congestion level.
> Regards
> Kamesh
> 
> 
> 
> 
> 
> Tolga Asveren <[email-masked]> on 11/08/2002 06:40:54 PM
> 
> To:   "[email-masked]'" <[email-masked]>

---

From: [email-masked]
Date: Fri, 8 Nov 2002 18:54:13 +0530

Hi
     Tolga this is fine if SPMC congestion status is updated by
                 SCONS coming from ASP's serving SPMC TFC will be send
                 to the conerned PC. We can have a congestion timer per SPMC
                 which will be triggered when ever SPMC congestion status is
                 updated.When the timer expires we can decrement the congestion
                 level of SPMC. This seems similar to RCT procedure. Here in
this
                 case RCT messages is nothing but MSU's received from
                 the SS7 domain.
Regards
Kamesh

Brian,

*How it should work IMO:

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.

---

From: [email-masked]
Date: Fri, 8 Nov 2002 19:25:23 +0530

Hi
     What i want to say is that  SCON from ASP is send to SG when
                 it receives data message in congested state. That means
                 when congestion abets at ASP, ASP will not respond with SCON
message.
                 So SG should have some SPMC congestion provisioning mechanism.
                 So I was suggesting to have a timer per SPMC to provision
congestion at SG side.
                  When SCON is received at SG timer starts and if timer expires
without
                   receiving SCON SPMC can decrement its congestion level
similar to
                   RCT mechanism in Q.704 .
Regards
Kamesh

Tolga Asveren <[email-masked]> on 11/08/2002 07:12:33 PM

Kamesh,

---

From: [email-masked]
Date: Fri, 8 Nov 2002 19:50:12 +0530

Tolga
     It may be typo. In my openion TFC will be generated by SG
                if and only if SPMC congestion status is changed on reception
                of SCON from any ASP(serving SPMC). Also SCON from
                ASP is send only when ASP receives MSU's from SG in congested
state. In my openion
                SG has to have a timer per SPMC to provision congestion status
                of SPMC. There is no way by which SG will come to know about
congestion abatement
                of ASP'S serving SPMC.
Regards
Kamesh

Tolga Asveren <[email-masked]> on 11/08/2002 07:50:06 PM

To:   [email-masked]

Kamesh,

As far as I understand, you propose that each SCON from ASP generates a TFC.
In such a case, if only one of the n ASPs serving the same AS gets
congested, TFC will be generated, not nice IMO. Even for one ASP case, when
TFC is generated based on SCON, the remote SP in SS7 domain will stop
sending messages and will send RCT. So, there will be no DATA to audit
status of ASP.
Also, IMO it is important not to forget about the relationship between ASP
and SG, i.e. that it is similar to relationship between MTP3 and MTP3 user.

     Tolga

> Sent: Friday, November 08, 2002 8:55 AM
> To: [email-masked]
> Cc: [email-masked]

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 8 Nov 2002 09:29:52 -0500

Kamesh,

For example in the scenario in my original message (3 ASPs, one of them gets
congested and sends SCON as response to a received DATA), what would you
expect SG to do? Also, how should SG resposne to an incoming RCT afterwards,
just set a timer and wait till it times out (if there won't be any more DATa
to send to congested ASP)?

    Tolga

> Sent: Friday, November 08, 2002 9:20 AM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: [email-masked]
Date: Fri, 8 Nov 2002 20:20:38 +0530

Tolga
     Let us assume SPMC congestion level  0 initially. Now when one
                 of the ASP (out of 3 ASP's) sends SCON in response to DATA
message
                 received. SPMC congestion status is updated to lets say 1 (as
received
                 in SCON message).Now as SPMC congestion status is updated TFC
                 will be send to conerned PC , Concerned Point code will start
RCT procedure.
                 At SG congestion timer (per SPMC ) will start on reception of
SCON. If SG
                 side goes on pumping data messages to congested ASP. Data
messages
                 in a way will audit ASP congestion status. If no SCON message
is received
                 by SG till congestion timer expires SG will decrement
congestion level of SPMC
                 assuming congestion abatement.
Regards
Kamesh

Tolga Asveren <[email-masked]> on 11/08/2002 08:14:52 PM

Kamesh,

    Tolga

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 8 Nov 2002 09:05:06 -0500

Kamesh,

     Tolga

---

From: [email-masked]
Date: Fri, 8 Nov 2002 23:47:16 +0530

Tolga
If ASP is congested you have to indicate this to the orginator of the messages
who has caused the congestion. How can can you do this unless or untill you dont
send TFC to the originator. Or let us take you openion that SPMC is not
congested then does that mean traffic which was diverted to congested ASP is
rerouted, which is strictly not recommended as it leads to missequencing.Second
option is dont disturb the traffic and let messages be routed to congested ASP,
this is even poor as you may loose data messages.
Regards
Kamesh

Tolga Asveren <[email-masked]> on 11/08/2002 09:05:37 PM

Kamesh,

a) You put the SPMC to congested status even when only one ASP is congested.

b) After receiving TFC the peer in SS7 domain will stop sending messages and
will send RCT. So, there won't be any DATA to be pumped from SG to ASP,
there you rely only on a timer.

For both of those reasons (especially a) ) I disagree with that method.

    Tolga

> Sent: Friday, November 08, 2002 9:51 AM
> To: Tolga Asveren
> Cc: [email-masked]

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 8 Nov 2002 13:28:47 -0500

Kamesh,

> Sent: Friday, November 08, 2002 1:17 PM
> To: Tolga Asveren
> Cc: [email-masked]
[TOLGA] How it works is, ASP declares congestion and SG does not route to it
anymore, there is no need of rerouting from ASP to another ASP, just SG does
not route to the congested ASP. To prevent missequencing, SG shouls follow
procedures, which it should follow when a new ASP gets ACTIVE or when an ASP
goes to INACTIVE.
Apart from this, do you believe the method you explained makes sense,
declaring the whole SPMC congested with one congested ASP?

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 8 Nov 2002 13:55:05 -0500

Kamesh,

One more comment below.

   Tolga

> send TFC to the originator. Or let us take you openion that 
[TOLGA] You need to inform other nodes with TFC only, if the whole SPMC is
congested, not when a single ASP is congested. If only one ASP is
unavailable, are you generating TFP or are you waiting for the whole SPMC to
be inaccessible?
> SPMC is not

---

From: [email-masked]
Date: Tue, 12 Nov 2002 20:43:54 +0530

Hi
     TFC is send in response to RCT(2) message only if message priority in the
RCT message is greater than congestion status of the routeset. Let RCT procedure
to continue and next time when RCT(1) is send TFC(1) will be send back by STP1.
This is what happens in SS7.

Regards
Kamesh

Tolga Asveren <[email-masked]> on 11/12/2002 08:24:14 PM

Brian,

My proposal:
1)3.4.4
Current:
"The SCON message MAY also be sent from the M3UA layer of an ASP to an M3UA
peer indicating that the M3UA layer or the ASP is congested."
Proposal:
"The SCON message SHOULD be sent from the M3UA layer of an ASP to an M3UA
peer indicating that the congestion level of the M3UA layer or of the ASP
has changed."
Why?: So, SCON will be sent, whenever ASP gets congested, because of an
incoming message to ASP or for any other reason(for example because of a
message destined for another AS, served by the same ASP). IMO, it is also
better to change MAY to SHOULD, so we update the SG, and it is up to it how
to behave.

2)Replacing SCON from ASP to M3UA with a new ASPTM (I am not very hopefull
but anyway)
Why?: Because Information about local SPMC is sent via ASPTM.

3)IMO, there should be a section about congestion indication mechanims
between ASP and SG, like we have sections "ASP Up Procedures" etc...
Why?: Because this is a procedure between ASP and SG, not between ASP and
another SS7 endpoint. The relationship with other SS7 endpoints is between
SG and them. So, like other ASP/SG procedures are explained, I also would
prefer a section for congestion procedure.

> The STP will not send TFC at a lower level than RCT: the TFC
> must contain the
> same congestion level as the message priority in the RCT if
> the STP is going
> to send TFC in response to it.
[TOLGA] Take this as a question instead of a comment, but I would expect STP
to respond TFC with a lower congestion level in the following sceanrio:
STP1 receives message with DPC=1-1-1. Links are congested, TFC(3) is replied
to originator.
Originator sends RCT(2) and RCT(2) reaches STP1. Let's assume at this time
congestion level for routeset=1-1-1 is 1. In this case, I would expect STP1
to reply with TFC(1), because Q.704 13.9.5. says "At the reception of a
signalling-route-set-congestion-test message, as signalling transfer point
will route it as an ordinary message, i.e. according to the procedures
specified in 2.3.5."
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 12 Nov 2002 13:12:31 -0500

Kamesh,

> > It is true that RCT is treated as regular message but
> > TFC is only responded back if the message priority in
> > the message is less than the congestion status of the
> > signalling routeset (this happens in national with
> > priority option).In international option TFC is
> > replied back if routeset is congested.
> [TOLGA] In the example I gave STP received RCT with level2 
> and at that time congestion level for corresponding route set 
> was 1. So, I think you also agree that TFC(1) is the correct 
> reply from STP. 
[TOLGA] Oopps sorry, confused that 1 was smaller than 2. I agree, for the
example I gave, no TFC(1) is necessary from STP. 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: Tolga Asveren <[email-masked]>
Date: Tue, 12 Nov 2002 14:11:16 -0500

Kamesh,

> Tolga RCT procedure is valid only in national option
> .As in international networks MTP3 indicates the
> received TFC to its concerned users ,  MTP3 does not
> maintain the congestion status of the received TFC in
> international option . That's why I will prefer RCT
> (2) will get discarded at the STP even though STP is
> having congestion status 1 for the concerned routeset,
> because not getting back TFC in response of RCT(2)
> itself means that originator of RCT will now assume
> the congestion status of concerned routeset as 1.
[TOLGA] As I indicated in my former message, I was wrong about the expected
behavior in my example. In such a case, STP should just route RCT(2)
-because congestion level is 1 and is less than priority of the message),
but also shouldn't discard RCT(2).
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran