Subject: Re: [Sigtran] M3UA SG-SG (again)

From: "TOLGA ASVEREN" <[email-masked]>
Date: Wed, 29 Jan 2003 16:51:33 +0200

Ken,

I will try to answer your questions separetly (BTW in general I agree that
some more sections are probably necessary to explain in more detail SG-SG
procedures, my idea was just to get an initial feedback from the WG and to
see whether it can be moved to charter):
                  4.4.1 Changeover Request Message(COR)

                  COR is used to relay changeover order/emergency
changeover order
                  information to/from a SS7 peer. There are two scenarios,
where it
                  can be used. Either it is received from a peer SG, where
a
                  corresponding COO/ECM is sent to peer SS7 node or it can
be
                  generated to a peer SG, after receiving COO/ECM from a
SS7 node.

                  COR message contains the following parameters:

                  Network Appearance: 32 bits (Semi-mandatory)

                  See M3UA Section 3.1.1

                  SLC :  5 bits (Mandatory)

                  The Signalling Link Code of the failed link.

                  FSN :  24 bits (Semi-mandatory)

[KAM] Where does FSN come from?  Are you going to add FSN to Data messages?
Is
this related to Correlation ID?

[TOLGA]FSN will be taken from COO received from SS7. The idea is not to add
FSN to DATA messages or provide a similar mechanism for communination
between peers in IP domain. The whole purpose of changeover/changeback
related SG-SG messages is to be able to relay corresponding
changeover/chnageback SS7 messages for the case explained in Figure7. In
fact probably this should be emphasized more strongly.

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

---

From: "TOLGA ASVEREN" <[email-masked]>
Date: Thu, 30 Jan 2003 07:40:48 +0200

Ken,

[KAM] i don't understand how SG-SG improves upon M3UA for asymmetric RKs

[TOLGA] This was based on that SE model was allowed for IPSP in IG.
Depending on the changes in IG about IPSP, this needs to be updated.

Tolga,

I agree that the SG-SG draft is worthwhile and should move forward.  I
have attached an edited version with more questions than comments.

Regards,

Ken

---

From: "TOLGA ASVEREN" <[email-masked]>
Date: Thu, 30 Jan 2003 08:35:19 +0200

Ken,

[KAM] do you plan to apply for a different SCTP port for SG-SG or reuse
M3UA port of 2905?

[TOLGA]I would think 2905 should be fine. Unless we restrict ASPs to use a
specific port (which is allocated for SG-SG), still we would need to look
to ASPID in ASPUP to decide for the type of peer, when dynamic addressing
is used.

---

From: "TOLGA ASVEREN" <[email-masked]>
Date: Thu, 30 Jan 2003 09:09:07 +0200

Ken,

[KAM] SGP must maintain state on a per SGP peer basis.  Is SGP up after
sending
ASP UP, or after receiving ASP UP ACK, or after DE transfer of ASP UP and
ASP
UP ACK?

[KAM] i'm not sure you say anywhere in the text that ASPUP is double-ended.
certainly,
this needs to be discussed in the state machines above.

[TOLGA]When ASPUP or ASPUP-ACK is received from peer, remote ASP switches
to ASPUP state.
In fact in "2.5 Point Code Status Information Exchange" this is explained:
"After a SCTP association is established, peers SHOULD declare the
availability of their M3UA layer with ASPUP messages. A received
ASPUP message is replied with ASPUP-ACK. If one of the peers
receives ASPUP message before sending ASPUP, it MAY or MAY NOT send
ASPUP message, ASPUP-ACK message declares availability of the remote
peer. Each SGP should declare its availability to each SGP of the
remote SGs separately. A SGP can declare its unavailability with
ASPDN message. ASPDN message is acknowledged with ASPDN-ACK message."

 Also in state machine for SGP, SGP switches to SGPUP state with ASPUP or
ASPUP-ACK.

---

From: "TOLGA ASVEREN" <[email-masked]>
Date: Thu, 30 Jan 2003 10:08:56 +0200

Ken,

[KAM] so ASPAC is not Double-ended?  Is ASP ACTIVE ACK used?
                    SGP1      SGP2          SGP3      SGP4
                        |        |              |        |
                        |-------DUNA(PC1)------>|        |
                        |        |              |        |

                        |-------DRST(PC2)------>|        |
                        |        |              |        |
                        |-------ASPAC---------->|        |
                        |        |              |        |
                        |<------DATA(PC3)-------+--------|
[KAM] how can data be sent.  SGP4 has not sent an ASP ACTIVE.
                        |        |              |        |
                        |        |<---DUNA(PC4)-|        |
                        |        |              |        |
                        |        |<---ASPAC-----|        |
                        |        |              |        |
                        |--------+-DATA(PC5)----+------->|
                        |        |              |        |
                        |        |              |        |
                        |        |              |        |

[TOLGA] ASPAC is used instead of TRA of MTP3(just not to introduce a new
message ASPAC is reused). But yes, there is a problem with sending DATA
just after receiving ASPAC from the peer. This conflicts with the following
sentence from 9.3.2. from Q.704:
"When a traffic restart allowed message has been received by X from
signalling point Y, and a TRA message has been sent by X to Y, X stops
timer 21."
So, both sides should receive ASPAC before any of them can send DATA. And
to assure that the peer has received ASPAC, ASPAC should be replied with
ASPAC-ACK(otherwise DATA from different stream,whşch is sent after ASPAC
might arrive earlier). I will update the draft accordingly.

---

From: "TOLGA ASVEREN" <[email-masked]>
Date: Thu, 30 Jan 2003 13:05:18 +0200

a typo:

to use a specific port ===> not to use a specific port

Ken,

---

From: "TOLGA ASVEREN" <[email-masked]>
Date: Thu, 30 Jan 2003 13:09:30 +0200

Ken,

                 IP-SP  IP Signalling Point

[KAM] does this have same definition as IPSP in M3UA?

[TOLGA] No. This one is a SS7 signalling point, which (also) uses SCTP
associations to transfer messages. I will add the definition to the
draft(also the other editorials).