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

From: Ken Morneault <[email-masked]>
Date: Thu, 07 Nov 2002 12:30:46 -0500

Below are a list of issues raised during the Day 4 wrap-up.

M3UA
----------

1.  Location of NA in messages

The RFC is unclear about the location of NA in messages.  In Section
3.3.1, the text says the NA "must" be the first parameter in the message
if it is included.  In the description of other messages with NA, Section 3.3.1 
is referenced in regards to NA but is not shown first in the message.

If there is a decision for NA to always be first in each message in which
it appears, the text (message formats) need to be changed to reflect
this.

Recommendation:  A non-binding vote was taken and there were more
people in favor of changing the text to say NA "MUST" be first in each
message in which it appears.

2.  There was a question about the following flow:

      ASP1   ------ASP Active ----------->   SGP1
                 <-----ASP Act Ack----------
                  --------Error------------------->

In this case, ASP1 sends an Error in response to the ASP Act
Ack so there is a potential for the ASP and SGP to be out of sync
regarding state.  Should ASP1 just resend the ASP Active or should
it take action to re-sync with SGP1 first (i.e. send an ASP Inactive
and wait for an ASP Inactive Ack before re-sending the ASP Active
message).

3.  Question if DUNA(*) is supported

General consensus was that since there is no text saying it is not
allowed, it is supported.  However, there were doubts noted about it's
usefulness.

M2UA
----------

1.  Partial List of Interface Identifiers in ASP Active message

There was a question about how the SGP should handle the
receipt of a partial list of Interface Identifiers in the ASP Active 
message.  Concern that the text in Section 4.3.4.3 was not
clear enough.

However, there is text in Section 3.3.2.7 that addresses this
situation:

   If no Interface Identifiers are included, the message is for all
   provisioned Interface Identifiers within the AS(s) in which the ASP
   is provisioned.  If only a subset of Interface Identifiers for an AS
   are included, the ASP is noted as Active for all the Interface
   Identifiers provisioned for that AS.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 7 Nov 2002 13:13:17 -0700

Ken,

Please see comments below:

Ken Morneault wrote:                          (Thu, 07 Nov 2002 12:30:46)
> Below are a list of issues raised during the Day 4 wrap-up.

This was discussed on the WG list in detail prior to RFC.  It is clear
that the M3UA must decode the entire message to detect syntax errors
which would cause a different response and therefore it makes little
difference where in the message the NA resides.  DATA is a rather different
case: in implementations where chain buffers are used, if the DATA portion
is very large, it would be advantageous to have NA in the first chain buffer
rather than the last.  In all other messages, there is no potentially large
transparent field such as there is in DATA, and there is no need to place
NA first in the message.

Unless one can show a clear interoperability need to have NA always first
in all messages, please leave the RFC as it stands.

> and wait for an ASP Inactive Ack before re-sending the ASP Active

Section 4.3.4.3:

  When the ASP sends an ASP Active message it starts timer T(ack).  If
  the ASP does not receive a response to an ASP Active message within
  T(ack), the ASP MAY restart T(ack) and resend ASP Active messages
  until it receives an ASP Active Ack message. ...

Section 4.3.4.3:

  Whe SGP MUST send an ASP Active Ack message in response to a received
  ASP Active message from the ASP, if the ASP is already marked in the
  ASP-ACTIVE state at the SGP.

Presumably, ASP1 is already prepared to process traffic on the RC
because it has sent ASP Active.  If SGP1 starts sending DATA after
receiving ASP Active Ack, the ASP has a further indication that its
activation may have been successful.  However, ASP1 should not send
DATA to SGP1 until it has properly received an ASP Active Ack (or it
will risk data loss also per section 4.3.4.3).

I don't think that there is a problem here as management will be
informed of the failure to receive an ASP Act Ack after T(ack) expires
and someone will have to be dispatched to repair the broken SGP1.

> allowed, it is supported.  However, there were doubts noted about it's

DUNA(*) is supported.  Section 3.4.1 clearly states:

Section 3.4.1:

	...

	Mask: 8-bits (unsigned integer)

	...

	A mask value equal (or greater than) the number of bits in the
	PC indicates that the entire network appearance is affected -
	this is used to indicate network isolation to the ASP.

It has use in the cited case: in situations where network isolation occurs
(i.e., the final signalling link to the SS7 network fails), sending DUNA(*) is
possible and has advantages over sending a large number of DUNAs for
indivieual routes sets which are prohibited as a result of the isolation.

(Remember: For the situation where the NIF fails, we agreed that unsolicited
ASP Inactive Ack was a better approach and DUNA(*) is only used for SS7
network isolation cases.)

> M2UA

I don't know that everyone really agrees with this behavior, but it is
clear in the RFC.

--brian

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

---

From: Ken Morneault <[email-masked]>
Date: Fri, 08 Nov 2002 09:04:00 -0500

Pls see comment below.

Ken

>in all messages, please leave the RFC as it stands.

[KAM]  I think there is still a desire to clarify all the NA references to Section
3.3.1 to note that this is only for the format (not location) of NA in the message.  

>and someone will have to be dispatched to repair the broken SGP1.

[KAM]  Agree..this situation is most likely caused by a mis-configuration that
will require operator intervention.  It is unlikely that re-sending ASP Active
will resolve the problem (as you note).  Further, it is unlikely that 
sending ASP Inactive, later followed by ASP Active will resolve the
problem.  

>network isolation cases.)

[KAM] agree

>I don't know that everyone really agrees with this behavior, but it is

[KAM] agree

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 8 Nov 2002 16:16:34 -0700

Ken,

Ken Morneault wrote:                                                                   (Fri, 08 Nov 2002 09:04:00)
> 3.3.1 to note that this is only for the format (not location) of NA in the message.  

I agree with putting the clarification in the IG, but NA positioning
should only be restricted in DATA messages.

--brian