Subject: [Sigtran] M2PA: list of comments on M2PAv8 and their resolutions in v9

From: Tom George <[email-masked]>
Date: Fri, 11 Jul 2003 16:35:30 -0500

List of comments on M2PA draft version 8.
Tom George
07/11/2003

Here is my list of comments on M2PA draft version 8 and how they were
incorporated into version 9. For the most part, they are arranged by
the thread from the SIGTRAN list. The date/name/subject identify the
beginning of the thread.

01. 04/24/03 Tolga Asveren "[Sigtran] M2PA: T7 and dropping SCTP
     association after link failure".

     (This was a comment about version 7 that came in after I released
     version 8.)

     Should T7 be required to be per-message? Should M2PA terminate the
     association if the link fails?

     A: These issues have been discussed before. No change is needed.

     Changed wording to not explicitly require many timers.

02. 04/24/03 Jeff Craig "[Sigtran] (M2PA) Comments on M2PA v8".

     Several comments.

     A: Here are the comments for which I made changes.

        T7 and PO: Because LS PO is sent on a different stream, it can
        arrive ahead of a message sent before the LS PO. The sender
        would keep T7 running, but the receiver would buffer and not
        ack the message. This would cause the link to fail due to T7
        expiry.

           To fix this, Delete (c) from 4.1.4 and follow MTP2's
	  behavior. In other words, stop T7 during LPO.

        Typo: In 4.1.5, the typo is corrected - LS PO is changed to LS
        Busy.

        FSN, BSN, PO: 4.2.1 says to ignore the FSN and BSN in non-User
        Data messages. But Q.703 uses the BSN to synchronize sequence
        numbers when exiting PO.

           I deleted the statement about ignoring FSN/BSN in LS
	  messages. I added that LS PR can be used to resynchronize
	  sequence numbers after PO. I added that for Flush, queued
	  incoming messages must be discarded as well as messages in
	  the TB/RTB. Added that Continue means to begin processing
	  the incoming queued messages.

           I did not follow a suggestion to put the LS and User Data
	  messages on the same SCTP stream. This would make the
	  synchronization easier and prevent discarding of messages
	  sent after RPO ends, but it takes away some flexibility in
	  allowing LS messages to go around queued User Data messages.

03. 04/28/03 Rohan "[Sigtran] Proving Message".

     Why is there a proving state and proving messages?

     A: For the same reason as in Q.703 and Q.2140: To verify that the
     link is usable before putting real traffic on it. See 4.1, 1st
     paragraph. No change needed.

04. 04/28/03 Pardeep "[Sigtran] Link States during Intial Alignment in
     M2PA".

     Are all of the MTP2 states during alignment needed in M2PA?

     A: Yes.

05. 04/28/03 Pardeep "[Sigtran] m2pa version control (sec 4.1.9)".

     Does "unsupported version" mean "incompatible old version"?

     A: Yes.

06. 04/28/03 Pardeep "[Sigtran] Need for One More message Type in
     M2PA?".

     Is there a need for an "error" message for incompatible M2PA
     versions?

     A: No. Severe errors like these require manual intervention.

07. 05/02/03 Pardeep "[Sigtran] FSN value".

     A: M2PA should not ignore the FSN in an empty user data message.

        The first FSN should be set to 0, and the first BSN to -1, as
        in Q.703.

        No change to the document is necessary.

08. 05/06/03 HannsJuergen Schwarzbauer "[Sigtran] (M2PA) Comments on
     M2PA v8 - Last Call".

     Several comments.

     A: Here is what I did for the comments.

        Definition of SG: OK as is.

           Changed definition of STP to refer to MTP. Added SP. Added
	  reference for SEP definition.

        RFC 2719: Reference to RFC 2719 is OK.

        XCO/XCA: There is sufficient warning about this.

        FSNC or FSNT: It's FSNC as in Q.703.

        Empty User Data message: OK as is.

        Message Data: Added text to 2.3 to clarify what is in this
        field.

        Filler: OK as is.

        Registered port number: OK as is.

        SLC in 4.1.2: Changed sentence in 4.1.2 to read: "Therefore, it
        is possible that the ***SLC*** values a and b MAY be equal."

09. 05/06/03 Andrew Booth "[Sigtran] M2PA v8".

     Should we include a comment on how to handle T7 after a LS Busy or
     LS Busy Ended is received?

     A: Do what MTP2 does. No change is needed to the draft.

10. 05/07/03 HannsJuergen Schwarzbauer "[Sigtran] (M2PA) Comments on
     M2PA v8 - Last Call".

     Proving_Interval has no value assigned to it.

     A: Proving may be omitted if allowed by the MTP2
     standard. Recommend that Proving_Interval be set to imitate
     expected rate of traffic.

11. 05/07/03 HannsJuergen Schwarzbauer "[Sigtran] (M2PA) Comments on
     M2PA v8 - Last Call".

     Spare bits in the LI field.

     A: Only the 2 priority bits are placed in this field. So there is
     no issue about the number of spare bits.

12. 05/07/03 HannsJuergen Schwarzbauer "[Sigtran] (M2PA) Comments on
     M2PA v8 - Last Call".

     LS messages do not go in retransmission buffer. So why say that
     they are not retrieved?

     A: Because untransmitted messages are sometimes retrieved.

        Clarified in 4.2.1 that LS messages are not placed in
        retransmission buffer. Clarified in 4.2.3 that empty User Data
        messages are not retrieved.

13. 05/21/03 David Lehmann "[Sigtran] M2PA I-D version 8, section
     4.2.1".

        Similar to Jeff Craig comment - item 02, "FSN, BSN, PO".

        Inconsistency in 4.2.1. FSN is set in non-User Data messages,
        but then it says to ignore it.

     A: I deleted the sentence saying to ignore the FSN/BSN in LS
     messages. See item 2 above.

=====================================================================

-- 
* Tom George       PB7-24001 (near B-21)      [email-masked]  *
* 972-519-3168   Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel;  3400 West Plano Pkwy,  MS PB7-SWPRO;  Plano, Texas 75075  *
*   I actively disclaim speaking for Alcatel.  I do not purport to    *
*   advertise or represent its position, operations, or activities.   *

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

---

From: "VIvek Toky" <[email-masked]>
Date: Fri, 11 Jul 2003 15:27:14 -0700

I have one question related to Registration Request handling in M3UA IG
V4. I am pasting few lines from Section 3.6

"If the SGP determines that the received RK was already registered, the SGP
returns a registration Response message to the ASP,containing a Registration
Result "Error - Cannot Support Unique Routing". This error applies whether
the Routing Key is Active or Inactive."

Is there any reason why SGP should send this error back. Why should it not
send the same RC back again ?

thanks,
Vivek.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 11 Jul 2003 18:53:53 -0600

VIvek,

Because it is an error.  What would be acheived by sending back the already
registered RC instead?

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: "Umesh Vats" <[email-masked]>
Date: Sat, 12 Jul 2003 09:57:27 -0700

Hi  Brian,

This will be useful in the cases where,  REG-RSP from SGP
to ASP is lost. In this case, ASP will retry the reuqest and SGP
can send the same RC back.

Umesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Friday, July 11, 2003 5:54 PM
To: VIvek Toky
Cc: SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA IG V04: Receiving REG for a RK already
registered

VIvek,

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 12 Jul 2003 13:02:55 -0600

Umesh,

How can the REG-RSP get lost?  SCTP is reliable.

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Mon, 14 Jul 2003 10:07:44 -0700

Right now, if ASP sends REG-REQ for an already registered routing key,
SGP sends unsuccesful REG-RSP. 
But in some scenarios, succesful REG-RSP from SGP to ASP may be lost 
due to network problems/local node problems. In these cases, ASP may
retry REG-REQ. 
In such scenarios (duplicate REG-REQ), as per M3UA IG V03 SGP sends REG-RSP
with error as "Error - Cannot Support Unique Routing"

Is it possible for SGP to include the Routing Context (RC assigned by SGP
for the local rk id received in the first REG-REQ from ASP) in addition 
to the "Local_Routing Key Identifier" in the unsuccessful REG-RSP message
mentioned above. This will allow ASP to recover the RC value.

Thanks
Umesh

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.500 / Virus Database: 298 - Release Date: 7/10/2003

---

From: "VIvek Toky" <[email-masked]>
Date: Mon, 14 Jul 2003 10:25:50 -0700

I think Umesh is right. If REG Response is lost ASP will never be able to
register the same RK again. As it doesn't know the RC so it would not be
able to de-register it and it can also not register it again.

-Vivek.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Umesh Vats
Sent: Monday, July 14, 2003 10:08 AM
To: SIGTRAN e-mail list
Subject: [Sigtran] M3UA : RC in unsuccesful REG-RSP

Thanks
Umesh

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Jul 2003 12:22:34 -0600

VIvek,

REG response cannot be lost.

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Mon, 14 Jul 2003 14:26:05 -0700

Brian,

REG-RSP may be lost at the local ASP node itself. And anyway
REG-RSP is being generated by SG with local Rk Id. It can put
RC also so that ASP can correlate RC and RK in such cases.

Umesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Monday, July 14, 2003 11:23 AM
To: VIvek Toky
Cc: [email-masked]; SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

VIvek,

--brian

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.500 / Virus Database: 298 - Release Date: 7/10/2003

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Jul 2003 15:30:07 -0600

Umesh,

An implementation that is discarding messages is broken.

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Mon, 14 Jul 2003 14:46:00 -0700

It is a very reasonable scenario. On the nodes, which work
in highly-available fault tolerant modes, some message
losses are expected when active/standby switchovers happen.

But there should be mechanism for recovery with minimum impact.

In the specific case I mentioned, if the ASP receives RC in
REG-RSP, it can easily correlate RC with RK. Then, if everything
else is OK, it can keep using same RK. Or it can send request to
SGP for deregistering RK (using RC receivd from SGP).

thanks
Umesh

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, July 14, 2003 2:30 PM
To: Umesh Vats
Cc: VIvek Toky; SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

Umesh,

--brian

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Jul 2003 16:10:36 -0600

Umesh,

Active/standby switchovers occur BETWEEN SCTP associations.  REG RSP is
only relevant WITHIN an SCTP association.  So the scenario you describe
does not apply.

Why does your ASP lose REG RSP messages?  Is is so poorly designed?

The only scenario that we considered for the RFC where the ASP may lose
messages is if the ASP crashes and then come back up again.  Then,
however, if the SCTP association reamins open, it is the responsibility
of the system to send ASP DOWN.  Or, in any case, when the ASP comes
back up, it sends ASP UP, that clears all registrations anyway.

I'm sorry, but you have not presented a reasonable situation yet.
Please try again.

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Mon, 14 Jul 2003 15:33:42 -0700

Brian,

I am talking about node level fault-tolerance.
Consider the following scenario :

      host1
    ASP1-Active---|
        |         |    host3
    Common Data   |---SCTP-------association--------SGP
        |         |
    ASP1-Standby--|
       host2

Here, I am considering node level fault-tolerance. Two,
ASPs are operating in active/standby mode. Both the copies
represent single ASP to SGP (via single SCTP association)
where SCTP is running on host other than those of ASPs.
Also, both the ASPs refer to same data(AS, ASP, Association states,
routing contexts).

Suppose ASP1-Active sends REG-REQ for RK1 to SGP. SGP responds back
with REG-RSP to ASP1. Now, ASP1-Active receives the REG-RSP
but before it could update the common data, it goes down. In
this case, switchover happens and ASP1-Standby become active.
Now, ASP1-Standby sees that RK1 is not registered and sends REG-REQ
again to SGP. The problem comes here.

The other method you discussed (sending ASP-DOWN) will bring down
remaing application servers also which may be already actively receiving
traffic.

Thanks
Umesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Monday, July 14, 2003 3:11 PM
To: Umesh Vats
Cc: VIvek Toky; SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

Umesh,

--brian

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Jul 2003 16:35:05 -0600

Umesh,

M3UA only supports 1 ASP per SCTP association.  You configuration
is not supported.

By your argument, any M3UA message could be lost between SCTP
and M3UA.  This is not provided for the the specification.  Short
of having M3UA acknowledge and retransmit ALL messages, there will
not be support in M3UA for this arrangement.

You need a better design.

--brian

---

From: "VIvek Toky" <[email-masked]>
Date: Mon, 14 Jul 2003 15:43:32 -0700

Brian,
   Probably your thinking is limilted to your implementation only. Some
implmentions may internally be fault tolerant or distributed. Which means
that multiple M3UA instances can be designed to use same SCTP assocation and
to represent single ASP. Now, explaining you the advantage  of that may be
far beyond the topic but I don't see any harm in including RC in the
messages, as some implementaions may use it to their benefit.

  I am not sure why are you objecting to this proposal , do you mean to say
that its difficult for your implemntaion to find an RC for already
registered RK ?

regards,
Vivek.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Monday, July 14, 2003 3:35 PM
To: Umesh Vats
Cc: VIvek Toky; SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

Umesh,

--brian

On Mon, 14 Jul 2003, Umesh Vats wrote:

> > > > I think Umesh is right. If REG Response is lost ASP will never be
able
> > to
> > > > register the same RK again. As it doesn't know the RC so it would
not
> be
> > > > From: [email-masked] [mailto:[email-masked]]On
Behalf
> Of
> > > > Is it possible for SGP to include the Routing Context (RC assigned
by
> > SGP

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Jul 2003 16:46:17 -0600

VIvek,

Because you would have to handle ANY messages being lost to
accomodate this approach.  REG RSP would not be enough.  I
don't see the point in putting a half-bandaid on something
that isn't broken.

Make you distributed system either not lose messages, or
perform ASP Down/Up procedures between switchover.

I do have a distributed implementation, but it does not lose
M3UA messages without an ASP going down.

In the diagram below, where is M3UA?  If it is not riding
directly on top of SCTP (it is after all an SCTP Adaptation
Layer) then it is not provided for in the M3UA specification.
If you have M3UA running on host3, there is no problem, it
will not lose messages.

If you are extending multiple instances of M3UA running over a
single SCTP association, this is not supported.  (1 ASP, 1
SCTP Association).

Am I clear?  Don't expect M3UA to accomodate your unsupported
and poor distributed design.  Make a better design.

The ASP that loses M3UA messages is either ASP-DOWN or broken.

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Mon, 14 Jul 2003 16:01:27 -0700

What do others think about this issue ?
I think, in a practical scenarios its very musch possible
that message loss may happen between ASP and SGP.

Currently SGP sends REG-RSP in case duplicate REG-REQ for
same RK is received. If we assume ideal scenario where no message loss
can ever happen, SGP should simply dump REG-REQ and not send REG-RSP.

But if it is sending REG-RSP with error (as proposed in M3UA IG-V04),
then sufficient information should be included so that ASP may come
to know the correlation between RC and RK.

thanks
Umesh

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, July 14, 2003 3:46 PM
To: VIvek Toky
Cc: Umesh Vats; SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

VIvek,

--brian

Behalf
> > > > > In such scenarios (duplicate REG-REQ), as per M3UA IG V03 SGP
sends
> > > > REG-RSP

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Jul 2003 17:00:27 -0600

Umesh,

When host1 sends REG REQ have is save local-routing-key-id in
common data.  When host3 sends messages to host1 and 2 have it
save a local copy until acknowledged by the host to which it was
sent.  If host1 goes down between receiving and REG RSP and before
acknowledging it, host3 will send REG RSP to host2.  host2 uses
local-routing-key-id in REG RSP to correlate REG REQ from common
data.

Problem solved.

There is no need for such a design to lose messages, particularly
REG RSP.

Please don't expect the protocol to change to accomodate poor design.

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Mon, 14 Jul 2003 16:19:58 -0700

Brian,

I am sure you have sufficient background of highly-available/distributed
systems as your implementation is 100% fault tolerant with
nil (0%) message loss.

In the given scenario, what if host1 receives REG-RSP from host3 but before
updating
the RC received in message to common data, host1 goes down.

In this case, host2 doesn't know the RC and RK relation.
Performing ASP-DOWN procedure will make ASP DOWN for all the Application
Servers
for which traffic exchange might be happening.

Infact, your implementation can use this idea to further decrease message
loss
from 0% to -1% percentage or less :)

Thanks
Umesh

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Monday, July 14, 2003 4:00 PM
To: Umesh Vats
Cc: SIGTRAN e-mail list; Vivek Toky
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

Umesh,

Problem solved.

--brian

On Mon, 14 Jul 2003, Umesh Vats wrote:

> > > > > > Right now, if ASP sends REG-REQ for an already registered
routing
> > key,
> > > > > > to the "Local_Routing Key Identifier" in the unsuccessful
REG-RSP
> > > > message

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Jul 2003 23:13:06 -0600

Umesh,

> the RC received in message to common data, host1 goes down.

An host1 does not acknowledge the message to host3, so when host2 comes
up, host3 sends the REG RSP again to host2.

> In this case, host2 doesn't know the RC and RK relation.

The RC is in the REG RSP that host3 resends to host2.  The RK is in common
data along with the Local-Routing-Key-Identifier that is also contained in
the REG RSP.  host2 will have no problem correlating the REG RSP with the
REG REQ, as would host1 (on the LRK-Id).

> Servers for which traffic exchange might be happening.

So, don't.  Have host3 send the REG RSP message not acknowledged by host1
to host2 when host2 takes over.

> loss from 0% to -1% percentage or less :)

Your implementation does not need to lose REG RSP unless it has been
designed to do so.  Don't do that.  Use techniques such as above so that
you do not lose messages.  Do not expect M3UA to repeat messages to handle
the idiosynchrasies of your own internal architecture.

The reason for sending "Cannot support unique routing" was because we spent
some great pains removing RK depedency from the ASP.  The ASP can be designed
completely RK neutral and treat the RK as opaque.  Only the AS need know the
internals of the RK.  One side effect of this is that mutliple AS at the ASP
may attempt to activate for the same RK.  The ASP cannot detect this an remain
RK neutral.  So, when a second AS attemtps to register the same RK (and obtain
its own unique RC), it is the SGP that refuses the registration with "Cannot
support unique routing", instead of requiring the ASP to maintain RKs and
police AS/RC/RK uniqueness.  The RFC places the obligation at the SGP (M3UA,
NIF or MTP) to enforce the 1:1:1 relationship of AS:RC:RK, because it is the
one that requires this relationship so that there is "unique routing" in the
SGP routing table.

This is rather important to interoperability, because there is no mechanism
in the M3UA ASP specification to enforce this relationship, only the mechanism
at the SGP.  Altering the behviour of the SGP would break this
interoperability mechanism.

There are probably three or four other mechanism within your architecture
that will solve the problem for you without changing M3UA and breaking this
more important interoperability behavior.  So I cannot agree with the change.

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Tue, 15 Jul 2003 12:28:39 -0700

REG-RSP from SGP to ASP ,may be lost at SG itself before it reaches SCTP
due to local problems at SG. In this case, what should ASP do ?

I don't understand why sending of RC from SG poses any problem.
SG already knows about the RK and RC. It just has to return the RC.

Umesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Monday, July 14, 2003 10:13 PM
To: Umesh Vats
Cc: SIGTRAN e-mail list; Vivek Toky
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

Umesh,

The reason for sending "Cannot support unique routing" was because we spent
some great pains removing RK depedency from the ASP.  The ASP can be
designed
completely RK neutral and treat the RK as opaque.  Only the AS need know the
internals of the RK.  One side effect of this is that mutliple AS at the ASP
may attempt to activate for the same RK.  The ASP cannot detect this an
remain
RK neutral.  So, when a second AS attemtps to register the same RK (and
obtain
its own unique RC), it is the SGP that refuses the registration with "Cannot
support unique routing", instead of requiring the ASP to maintain RKs and
police AS/RC/RK uniqueness.  The RFC places the obligation at the SGP (M3UA,
NIF or MTP) to enforce the 1:1:1 relationship of AS:RC:RK, because it is the
one that requires this relationship so that there is "unique routing" in the
SGP routing table.

This is rather important to interoperability, because there is no mechanism
in the M3UA ASP specification to enforce this relationship, only the
mechanism
at the SGP.  Altering the behviour of the SGP would break this
interoperability mechanism.

There are probably three or four other mechanism within your architecture
that will solve the problem for you without changing M3UA and breaking this
more important interoperability behavior.  So I cannot agree with the
change.

--brian

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 15 Jul 2003 13:50:49 -0600

Umesh,

What should ASP do if it loses data.  What should ASP do if it loses
ASP xxxx Ack.  What should ASP do if it loses mandatory Notify.  What
should ASP do....

The SGP should not lose messagez, or if it does, send ASP Inactive Ack
or ASP Down Ack to reset the association.

If it loses messages without detecting them, there is nothing to do but
recreate SCTP in M3UA (a rather absurd proposition).

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Tue, 15 Jul 2003 13:10:04 -0700

If ASP looses ASPSM/ASPTM/DRKM/SSNM messages(which are consumed by M3UA,
it should be able to recover.

For SSNM, subsequent SSNM messages or DAUD procedure take care of message
loss.
For if ASP-ACTIVE_ACK response is lost, ASP can resend ASP-ACTIVE.

But for loss of REG-RSP, the only recovery now possible is ASP-DOWN
procedure which is far worse that deregistering just one RK.

Umesh

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, July 15, 2003 12:51 PM
To: Umesh Vats
Cc: SIGTRAN e-mail list; Vivek Toky
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

Umesh,

--brian

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 15 Jul 2003 15:15:30 -0600

Umesh,

An SG designed to meet SS7 requirements will not have any problems
losing M3UA messages.

--brian

---

From: "VIvek Toky" <[email-masked]>
Date: Tue, 15 Jul 2003 14:50:57 -0700

Brian,

  You said
   "The reason for sending "Cannot support unique routing" was because we
spent
some great pains removing RK depedency from the ASP.  The ASP can be
designed
completely RK neutral and treat the RK as opaque.  Only the AS need know the
internals of the RK."

Why do you want ASPs to be totally unawar of whats inside the RK, If SGPs
have to do the routing based on RKs then ASPs also have to route the
incoming messages to the destined AS (locally). If different ASs try to
register same routing key then it can be checked at ASP itself without even
sending the REG Request message out.

Can you explain more about the interoperability scenarios you mentioned..

-Vivek.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Tuesday, July 15, 2003 2:16 PM
To: Umesh Vats
Cc: SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

Umesh,

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Tue, 15 Jul 2003 15:25:46 -0700

Brian,

REG-RSP message with unsuccesful registration status and Local RK-Id
but no RC serves far less purpose than REG-RSP with Local-RK and RC in
all practical SGP/ASP impplementations.

I don't see any reason why a better approach for handling errors shouldn't
be used if its possible.

Umesh

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, July 15, 2003 2:16 PM
To: Umesh Vats
Cc: SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

Umesh,

--brian

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 15 Jul 2003 16:21:23 -0600

VIvek,

All ASPs need to route messages locally to AS is the RC.  They need
not be aware of the RK.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 15 Jul 2003 16:25:28 -0600

Umesh,

If your SG loses the odd REG RSP have it send two (or, why not,
three) of each.  The ASP can disregard the duplicates.

Oh, you missed DATA and required Notify below.  Also, beat/beat-ack.
And what about unsolicited ASP Inactive Ack and ASP Down Ack.

Tell me, why do you use SCTP?  All that reliabilty just so that your
design will throw away messages: seems like a waste.  You should use
UDP.

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Tue, 15 Jul 2003 18:03:28 -0700

Brian,

Many SGs(except yours) can lose the  REG-RSP in some or the other
node-level fault  scenarios.

If your implementation doesn't store RKs at ASPs, then why to penalise
other implementations who want to use RC for correlation with routing key.

RC is available in SG. So SG can send it in REG-RSP for the benefit of
ASP which don't work in the way your's do.

Thanks
Umesh

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Tuesday, July 15, 2003 3:25 PM
To: Umesh Vats
Cc: SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

Umesh,

--brian

On Tue, 15 Jul 2003, Umesh Vats wrote:

> > > data along with the Local-Routing-Key-Identifier that is also
contained
> in
> > > completely RK neutral and treat the RK as opaque.  Only the AS need
know
> > the
> > > internals of the RK.  One side effect of this is that mutliple AS at
the
> > ASP
> > > NIF or MTP) to enforce the 1:1:1 relationship of AS:RC:RK, because it
is
> > the
> > > one that requires this relationship so that there is "unique routing"
in
> > the

---

---

---

From: "VIvek Toky" <[email-masked]>
Date: Tue, 15 Jul 2003 18:21:36 -0700

Hi Brian,
  Can you give me pointer to a section in RFC or IGv4 where its mentioned
"ASP must use only RC to route messages locally to AS".. If your ASP
implementation does not maintain routing keys, why do you want SGPs to do
the work for you.

 Even if an implementaion routes messages locally based on RC, it can still
validate RK while sending the REG Request message out, I don't see a problem
with that. If you don't want to modify your datastructures, that doesn't
mean M3UA protocol should change for you.

-Vivek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Tuesday, July 15, 2003 3:21 PM
To: VIvek Toky
Cc: Umesh Vats; SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

VIvek,

--brian

contained
know
the
is
in

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 15 Jul 2003 23:25:39 -0600

VIvek,

Validate it at the ASP all you want.  In the RFC it is the SG's responsibility
to guarantee unique routing, not the ASP's.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 15 Jul 2003 23:26:39 -0600

Umesh,

> node-level fault  scenarios.

Who's?  Yours?  I didn't know that you spoke for both me and everybody
else.

--brian

---

From: "VIvek Toky" <[email-masked]>
Date: Wed, 16 Jul 2003 16:52:37 -0700

Brian,
  If the same ASP is serving multiple AS it can also cross check the
uniqueness of the routing Keys among those AS. That way we don't even need
to send the REG Request messages to a peer node.
  Even if multiple ASs (in same ASP) manage to send REG request messages for
same routing keys, SGP can anyway return Response message to the ASP,
containing a Registration Result "Error - Cannot Support Unique Routing" but
can also send RC related to the routing key already registered. This would
help implementations to recover from data inconsistencies (if present),
without stopping all the traffic for that ASP.

-Vivek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Tuesday, July 15, 2003 10:26 PM
To: VIvek Toky
Cc: Umesh Vats; SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

VIvek,

Validate it at the ASP all you want.  In the RFC it is the SG's
responsibility
to guarantee unique routing, not the ASP's.

--brian

Behalf
> > > > > In the given scenario, what if host1 receives REG-RSP from host3
but
> > > > before
> > > > the REG RSP.  host2 will have no problem correlating the REG RSP
with
> > > > The reason for sending "Cannot support unique routing" was because
we
> > > > support unique routing", instead of requiring the ASP to maintain
RKs
> > and
> > > > police AS/RC/RK uniqueness.  The RFC places the obligation at the
SGP
> > > (M3UA,
> > > > that will solve the problem for you without changing M3UA and
breaking
> > > this

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 Jul 2003 18:50:51 -0600

VIvek,

Except the purpose of "Error - Cannot Support Unique Routing" was for
overlapping routing keys.  In the case where the requested RK overlaps with a
number of RKs, there are multiple existing RC values.  Which one would it
return?  Also, because there are overlapping RKs does not mean that the
requesting ASP is registered for any of them.  In that case any of the
overlapping RCs included would have either no meaning or could be poorly
interpreted by the ASP.  That is if one returns an RC value to which the ASP
is not registered and the ASP send DEREG REQ, it will generate another error.
Which is bad.  No, if the RC is actually registered to the ASP and usable by
the ASP, the return should be Success.  And this is what I proposed.  That if
the LRK-Id is the same as the LRK-Id that the ASP is registered against the RK
and the RK matches, then the return would be Success.  In the overlapping
case, or where the RK matches and the LRK-Id does not match, the result would
be "Error - Cannot Support Unique Routing".

Using the LRK-Id serves both needs.

Another possibility would be to return a different error code for a matching
already registered RK.  Such as "Error - Already Registered" in which case the
RC could be returned insted of 0 as you suggest.  This would give the ASP
enough information to either start using the registered RC, or use the RC in
a DEREG REQ.  That text would look something like:

     12             Error - Routing Key Already Registered

  If the SGP determines that the received RK is already registered, the
  SGP returns a Registration Response message to the ASP, containing a
  Regsistration Result "Error - Routing Key Already Registered" and
  includes the Routing Context value of the existing Routing Key in the
  Registration Response.

We would also have to change the passage that says that RC is always
zero for outher than "Successful" to other than "Successful" or "Error -
Routing Key Already Registered".

This would also permit an ASP to audit existing registrations by sending
a REG REQ for an existing RK and comparing the returned RC.

--brian

---

From: "Umesh Vats" <[email-masked]>
Date: Wed, 16 Jul 2003 18:15:14 -0700

Brian,

"Another possibility would be to return a different error code for a
matching
already registered RK.  Such as "Error - Already Registered" in which case
the
RC could be returned insted of 0 as you suggest."

This looks like a good idea. The new error code in REG-RSP along with RC can
be
interpreted more clearly and will be more useful for the ASPs.

Now "Error - Cannot Support Unique Routing" can be returned only for
overlapping
routing keys and not for the same RKs.

Umesh

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Wednesday, July 16, 2003 5:51 PM
To: VIvek Toky
Cc: Umesh Vats; SIGTRAN e-mail list
Subject: Re: [Sigtran] M3UA : RC in unsuccesful REG-RSP

VIvek,

Except the purpose of "Error - Cannot Support Unique Routing" was for
overlapping routing keys.  In the case where the requested RK overlaps with
a
number of RKs, there are multiple existing RC values.  Which one would it
return?  Also, because there are overlapping RKs does not mean that the
requesting ASP is registered for any of them.  In that case any of the
overlapping RCs included would have either no meaning or could be poorly
interpreted by the ASP.  That is if one returns an RC value to which the ASP
is not registered and the ASP send DEREG REQ, it will generate another
error.
Which is bad.  No, if the RC is actually registered to the ASP and usable by
the ASP, the return should be Success.  And this is what I proposed.  That
if
the LRK-Id is the same as the LRK-Id that the ASP is registered against the
RK
and the RK matches, then the return would be Success.  In the overlapping
case, or where the RK matches and the LRK-Id does not match, the result
would
be "Error - Cannot Support Unique Routing".

already registered RK.  Such as "Error - Already Registered" in which case

--brian

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 16 Jul 2003 19:12:41 -0600

Umesh,

Good. I think we are agreed then.

Other comments?

--brian

---

From: "VIvek Toky" <[email-masked]>
Date: Wed, 16 Jul 2003 18:18:20 -0700

Brian,
 I think new error code(Error - Routing Key Already Registered) is fine for
me. Also this error code better explains the actual error.

thanks,
-Vivek.

-----Original Message-----

VIvek,

--brian