Subject: [Sigtran] Re: TUA query

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 1 Mar 2002 00:16:16 -0600

Rajesh,

Please see comments below...

rkgupta wrote:                                            (Fri, 01 Mar 2002 09:28:04)
>
>  Hi All,
> 
>  We would like to know that -
> 
>  1. Whether TUA itself is an ASP or TC-user is an ASP ?

An ASP is an instance of TUA.  TUA ASPs serve one or
more AS.  An AS is equivalent to a TC-user.

>  2. Can a single TUA stack have multiple instances so that each instance can
>  work as an ASP ?

Yes, ours does.

>  rgds,
>  Rajesh

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

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

---

From: "rkgupta" <[email-masked]>
Date: Fri, 1 Mar 2002 16:26:51 +0530

Brian,

Thanks for reply.

As you mentioned that An AS is equivalent to a TC-user.
I would like to know that if an ASP(serving for one TC-user) is connected
with two SGs will serve for two(different) AS or not ??

rgds,
Rajesh

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Sat, 2 Mar 2002 12:58:46 -0600

rkgupta,

rkgupta wrote:                                            (Fri, 01 Mar 2002 16:26:51)
> with two SGs will serve for two(different) AS or not ??

Not necessary.  It could serve the same AS from both SGs.

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Sanjeev" <[email-masked]>
Date: Sat, 2 Mar 2002 16:14:25 +0530

Brain,
 I am confused a bit here...

1). Even though i have a common TUA demon running, for each application that
uses it, can it be viewed as an instance of TUA for each of those
applications?

If yes, does the TUA demon maintain different ASP instances (ASP State
Machines, because one application may choose to go down resulting in a ASP
serving it to go down) for each of the applications registered to it?

2). Being new to this concept, i am finding it a bit difficult to correlate
the ASP and AS in a SS7 network.. Can u please help me by making a
correlation with their SS7 counterparts...Also, if TC User is an AS, is it
that each TC User is going to be an End point (like what the stack is in a
SS7 network).

Thanks in advance...

Regards,
Sanjeev.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Brian F. G. Bidulock
Sent: Friday, March 01, 2002 11:46 AM
To: rkgupta
Cc: [email-masked]
Subject: [Sigtran] Re: TUA query

Rajesh,

rkgupta wrote:                                            (Fri, 01 Mar 2002
09:28:04)

Yes, ours does.

--
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 4 Mar 2002 09:02:28 -0600

Sanjeev,

Sanjeev wrote:                                            (Sat, 02 Mar 2002 16:14:25)
> uses it, can it be viewed as an instance of TUA for each of those

Yes, it can.

> serving it to go down) for each of the applications registered to it?

Yes, it can.

> that each TC User is going to be an End point (like what the stack is in a

One psosible model is where an AS is a TC-User and an ASP is merely a
collection of AS.  The TC-Provider exists only at the SG, and can either
be an end-point or a relay point (i.e., SEP or STP).

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Tom George <[email-masked]>
Date: Mon, 04 Mar 2002 15:47:51 -0600

Here are the changes in draft-ietf-sigtran-m2pa-04.txt (M2PAv4).

If anyone wants to study the changes in detail, I have a "diff" file I
can send.

Changes for the M2PA Interop Issues
-----------------------------------

All the major changes in M2PAv4 were identified in "M2PA
Interoperability Test Results and Issues"
http://search.ietf.org/internet-drafts/draft-george-sigtran-m2pa-interop-00.txt
That document lists M2PA issues and possible solutions. The numbering
here refers to the section numbers of that document.

2.1  SCTP Acknowledgement 

There was inadequate support in the TSVWG for the changes needed to
support options 2, 3, and 4. Option 5, M2PA sequence numbers, was
implemented in M2PAv4.

2.2  Link Status Out of Service Message 

An OOS was added to the Link Status message values. 

2.3  Aborting an Association for Performance 

The text recommending that M2PA abort an association for poor
performance was removed.

2.4  Aborting an Association for MTP3 Stop 

Text about aborting the association was removed. Now M2PA goes to the
out of service state instead of aborting the association.

2.5  Failing a Link 

See response to 2.4.

2.6  Order of Transmission 

The bits in the Spare/PRI field were reversed. That has been corrected.

2.7  Local Processor Outage and Link Status Ready 

If LPO occurs during alignment, the alignment procedure
continues. This was clarified.

2.8  Proper Stream for Proving Data Messages 

Proving messages are now sent on the Status stream. 

The Proving Data message is eliminated. The Link Status Proving
message serves its purpose.

2.9  Tuning SCTP Parameters 

Suggested values for SCTP parameters will be published later, probably
in an applicability statement.

2.10 M2PA Keep Alive Message 

It was not considered necessary to create a Keep Alive message at this
time.

2.11 Emergency Changeover for Japanese SS7 

Support for the Japanese SS7 changeover was added to the changeover
section.

2.12 Eliminate Client/Server Distinction 

The client/server distinction was removed. A suggestion was added on
how to avoid duplicate associations.

2.13 Resolving Normal and Emergency Proving 

This was clarified in the alignment section.

2.14 Need Reference for Busy 

This reference is no longer needed, since the SCTP congestion
procedure is not part of the Busy procedure.

2.15 Processor Outage and Busy in Various States 

The alignment section includes statements about Processor Outage. I
did not see any other specific changes that were needed. 

A more detailed list of changes:
--------------------------------

This is not a complete list of changes. I did not include minor
rewording.

1.6.1: Changed SCTP sequence numbers to M2PA sequence numbers.

1.6.2, paragraph "FISUs...": Acknowledgement is provided at M2PA level
now.

1.7.4, 2nd paragraph: Removed Proving Data messages.

2.1: Added "message class". This should have been there in version 3.

2.1.4: Removed Proving Data from list of types.

2.2: Added this section for the M2PA header.

2.3: Added M2PA-specific header to the message.

2.3.1, both diagrams: Order of PRI/spare fields is reversed.

2.3.2, 1st paragraph: Removed clause "except as modified later",
because it was not modified later.

2.3.2, list: Added Out of Service and In Service.

2.3.2.1: Link Status Proving message replaces Proving Data message.

3, definition of PROVING: Link Status Proving message replaces Proving
Data message.

3, Figure 7: Several changes because M2PA does not terminate the
association. T1 Expiry, Receive LS OOS, and T3 Expiry take M2PA to the
OOS state. 

3, Figure 8: Several changes because M2PA does not terminate the
association. Removed Abort paths. 

4.1.2, first few paragraphs: Rewrote this to eliminate client/server
distinction. If both ends know the endpoints, SCTP can prevent the
duplicate associations.

4.1.2, figures: Removed labelling of client and server.

4.1.3, paragraph "If timer T1 expires...": Add that M2PA sends the
Link Status OOS message.

4.1.3, paragraph "M2PA starts the proving period timer T2.": Removed
Proving Data messages. Removed M2PA checking SCTP performance.

4.1.3, paragraph "When the proving period timer T2 expires...":
Removed M2PA checking SCTP performance.

4.1.3, paragraph "M2PA shall stop timer T3...": Replaced Links Status
Proving Complete with Link Status Ready. Added sending Link Status
OOS. 

4.1.3, paragraph "Note that if M2PA has already received...": Removed
M2PA checking SCTP performance.

4.1.3, paragraph "If M2PA receives a Stop command...": Added this
paragraph.

4.1.4, paragraph "When M2PA detects a local processor outage...":
Added last sentence: "M2PA shall stop receiving incoming messages from
SCTP."

4.1.4, paragraph "M2PA should periodically...": Clarified that this is
done only if link is in service.

4.1.4, paragraph "MTP3 may send a Flush Buffers...": Added sentence
about data retieval.

4.1.5: Removed references to congestion notification from SCTP. 

4.1.5, paragraph "When the peer M2PA...": The link is taken out of
service instead of aborting the association.

4.1.5, paragraph "The peer M2PA shall cease...": M2PA shall cease,
instead of continue, transmitting messages.

4.1.6: Removed monitoring of SCTP performance.

4.1.7: Removed implementation note. The draft that was cited does not
really provide stream priorities. 

4.2.3: The link is taken out of service instead of aborting the
association.

4.2.5, paragraph "M2PA shall detect transmit congestion...": Removed
references to congestion notification from SCTP.

4.2.5: Removed the "Note" paragraph about M2PA not discarding messages
because of congestion. This is an implementation issue.

4.2.6, paragraph "(1) buffer updating...": Changed SCTP to M2PA.

4.2.6, paragraph "Note that only User Data messages...": Removed
sentence about stream sequence numbers, since M2PA sequence numbers
are used now.

4.2.6, paragraph "M2PA's Sequence Numbers...": Replaced SCTP sequence
numbers with M2PA sequence numbers.

4.2.6, paragraph "For data retrieval, MTP3...": Replaced SCTP sequence
numbers with M2PA sequence numbers. Removed discussion about SCTP
gaps.

4.2.6, paragraph "If there are any messages on the M2PA...": Clarified
which messages should be kept, which should be discarded. 

4.2.6, paragraph "Note: For the Japanese version...": Added this
requirement to retrieve all messages.

4.2.6.1: Replaced SCTP sequence numbers with M2PA sequence numbers.

5.1: Moved Emergency and Start in the diagram. Changed Proving Data to
Link Status Proving. Removed check on SCTP performance. 

5.5: Removed SCTP-to-M2PA congestion notification. Changed aborting
association to going out of service.

5.6: Removed SCTP-to-M2PA congestion notification. 

5.7: Changed aborting association to going out of service.

5.8: Removed step where M2PA looks for SCTP gaps, since SCTP sequence
numbers are not the basis for retrieval.

9.: Removed SCTP Extensions for Dynamic Reconfiguration of IP
Addresses and Enforcement of Flow and Message Limits" since it is no
longer referenced.

10.: Updated some addresses.

(end)

-- 
* Tom George          972-519-3168           [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
* Alcatel USA, Inc.; 1000 Coit Rd, MS PB2-STPA; Plano TX 75075-5813   *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 4 Mar 2002 18:57:33 -0600

Tom,

M2PA-04 says that if a message is received with a sequence
number that is out of order it is discarded.  Consider some of
the ramifications of this approach:

I can only think of several reasons that an M2PA peer would
receive a sequence number which is out of order:

1)  The sending (receiving) peer has made a mistake applying
    (or obtaining) the sequence number to the message.

2)  The network or SCTP implementation has reordered the
    message (either because the sender erroneously set
    the unordered bit or because the SCTP implementation
    has errors).

3)  The network has mangled a bit in the sequence number
    undetected by error detection algorithms (e.g., checksum).

In cases 1), 2) and, paricularly 3), there is a high
probability that the peer will never receive a sequence number
in order because an essential sequence number in the series
has been missed.

M2PA as it stands does not run a T7 timer (excessive delay
of acknowledgement) or any SCTP lifetimes.  So, cases 1), 2)
and 3) can yeild the syndrome where one M2PA peer is
discarding every user data message but the sender has no
indication of this until, perhaps, congestion occurs at the
sender.

This is extremely poor for SS7 performance.

On the other hand, failing the link is too drastic,
particularly in case 2) or 3), where recovery is easy to
accomplish.

There are several ways to avoid this syndrome:

a)  Run a T7 timer.  However, relying T7 timeouts to detect
    these low probablility errors (particularly case (3)) will
    still result in the link failing when recovery is simple.

b)  Provide for negative acknolwedgement and retransmission
    including the abnormal FSN/BSN FIB/BIB procedures from
    Q.703.

c)  Provide a reset mechanism for resetting sequence numbers
    in this event by including the reset procedures of Q.2140.

d)  Do not place the FSN in any message: have each end count
    the messages to derive the sequence number (remember SCTP
    cannot lose or missequence a properly sent message).
    Also, do not use BSN for acknowledgement, but ack a number
    of messages without reference to a sequence number.  This
    would completely erradicate the syndrome of cases 1), 2)
    and 3).

e)  A combination of the above.  A GPL'ed implementation of
    M2PA using combined procedures (except (c)) is provided at
    http://www.openss7.org/ with conformance test cases as
    described in draft-bidulock-sigtran-m2pa-test-00.txt.

I think that allowing a situation where M2PA hangs indefinitely
is an unacceptable situation for SS7.

Please rethink M2PA-04's use of sequence numbers.

--brian
    
-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 4 Mar 2002 19:05:20 -0600

Tom,

Gee.  If we added BIB/FIB into M2PA, it would be SS7 with
FISU/LSSU compression, where SCTP is being used as a wire.
Then we could throw out all of the procedures and just
reference Q.2210 or Q.703 with mention of the changed
error monitoring, proving and FISU/LSSU compression.

As SCTP offers little to nothing, what is the matter with
just using UDP or TCP (or even just IP--if you check there
is already an IP protocol number for SS7 L2) for M2PA?

--brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---

From: Tom George <[email-masked]>
Date: Fri, 08 Mar 2002 17:51:34 -0600

I think you are right that discarding the message is not a good
solution. 

If we put in a mechanism to get the messages back in order, then we are
duplicating SCTP features. 

I think failing the link is a better idea. You list the 3 cases where
this can happen. In 1 and 2, there is an error in the M2PA or SCTP
stack. In the case of 3, the probability of this happening is equal to
something like

   (probability of mangled bit)
      * (probability of mangled bit being in the sequence number)
      * (probability of checksum not detecting the mangle)

All 3 of these factors are very small. 

tomG.