Subject: RE: [Sigtran] M3UA Test Plan for ETSI PlugTest

From: Tolga Asveren <[email-masked]>
Date: Fri, 18 Oct 2002 19:06:59 -0400

For IPSP tests, it is said 
"Routing Context may be optionally based on the following example
    routing  keys.
    1. DPC
    2. DPC+CIC+SIO
    3. DPC+SIO
    4. DPC+SIO+OPC
    5. DPC+OPC
    6. DPC+CIC+OPC+SIO
    7. DPC+CIC+OPC
    8. DPC+CIC "

DPC+OPC is mandatory for the current IPSP model, becuse RK identifies
traffic range at both ends for IPSP.

  Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 18, 2002 8:20 AM
> To: [email-masked]
> Subject: [Sigtran] M3UA Test Plan for ETSI PlugTest
> 
> 
> 
> 
> 
> Hi All,
> 
> Here is the first draft of M3UA Test Plan for Plugtest. 
> Please review the same
> and send me the comments you have.
> 
> Best Regards,
> -Sandeep
> 
> (See attached file: m3ua_interop_plan_draft01_oct18.txt)
> 
> 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.
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: [email-masked]
Date: Mon, 21 Oct 2002 17:49:07 +0530

Hi Tolga,

This was an oversight, we would correct this in next version of test plan.

Best Regards,
-Sandeep

Tolga Asveren <[email-masked]> on 10/19/2002 05:36:59 AM

To:   [email-masked]
cc:    (bcc: Sandeep Mahajan/HSS)

Subject:  RE: [Sigtran] M3UA Test Plan for ETSI PlugTest

  Tolga

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 21 Oct 2002 08:56:58 -0400

Sandeep,

A further comment again related with test-case 3.6.1. It is said there
"The test case tests the interoperability of the two stacks in the
scenario when no network appearance is configured.
i.e network appearance configured is default."

I think, even for cases, where traffic belonging to multiple networks is
carried over one association, we can have the scenario where NA is not
present in DATA, because RC will imply it. So, IMO "i.e. network appearence
configured is default" is better to be deleted, it might be misleading.

   Tolga

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, October 18, 2002 7:48 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sigtran] M3UA Test Plan for ETSI PlugTest
> 
> 
> Sandeep,
> 
> Thanks for all the test plans.   In test 3.6.1 a default NA
> is sent in a DATA message and the receiver is expected to
> process this without error.  Section 3.6 is listed as a level 1
> section.  Where in RFC3332 does it say that the NA should be
> ignored by the ASP?  Is this a good thing?  What if the SGP
> starts directing the wrong traffic at the ASP?  It should ignore
> NA values in DATA messages indicating that the message does not
> belong to this ASP?
> 
> -brian
> 
> 
> [email-masked] wrote:                   (Fri, 18 Oct 
> 2002 17:50:26)
> > 
> > 
> > 
> > Hi All,
> > 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

---

From: [email-masked]
Date: Mon, 21 Oct 2002 19:44:56 +0530

Hi Tolga,

We will clarify the description of the test case as per your suggestion. Thanks
..

Best Regards,
-Sandeep

Tolga Asveren <[email-masked]> on 10/21/2002 07:26:58 PM

To:   "[email-masked]'" <[email-masked]>
cc:    (bcc: Sandeep Mahajan/HSS)

Sandeep,

   Tolga

---

From: [email-masked]
Date: Tue, 22 Oct 2002 18:41:32 +0530

Hi Brian,

I agree with you on case a) to c) and would modify the test case to explicitly
state the scenario.

Case d) is not that straight forward. Since NA is a optional parameter, not all
implementations would like to reject data based on the value of an optional
parameter. So In case d) listed by you, I suggest to add a clarification that
implementation can reject the data or can accept it in case an implementation
wish handle it as per a default NA (Equivalent to the case when NA is not
received in the message).

Best Regards,
-Sandeep

"Brian F. G. Bidulock" <[email-masked]> on 10/21/2002 08:55:04 PM

Please respond to [email-masked]

To:   Sandeep Mahajan/HSS@HSS
cc:   [email-masked]

Sandeep,

An implementation is fully within its rights to dicard (or reply with ERR to)
messages in case (c).  The test case should not expect an ASP to accept all
such messages.

There are actually a number of different cases here (expanding on your list):

 a) NA is not present

 b) NA is present (was configured in the Sg), but the ASP has no NA configured
    for the connection

 c) NA is present (was configured in the SG) and the ASP has an NA configured
    for the connection and the NA values match.

 d) NA is present (was configured in the SG) and the ASP has an NA configured
    for the connection and the NA values don't match.

It appears that the test case expects all 4 of these cases to accept the
message, when certainly (d) demands discard or error.

--brian

[email-masked] wrote:                             (Mon, 21 Oct 2002
19:36:48)
>
>
> Hi Brian,
>
> Following is the scenario.
> A SIGTRAN Node (ASP/SG) is handling only one network appearance and it is
> connected to multiple peers. Some of these peer SIGTRAN nodes (SG/ASP) sends
NA
> in Data message and some does not send NA in DATA message to this node.
>
> The expected behaviour
> As NA is a optional parameter,  SIGTRAN Node serving single NA should accept
> data message from peer in case a) NA is not present, b) NA is present and
value
> of NA is correct  c) NA is present and value of NA is incorrect.
>
> Regarding your concern for a SIGTRAN node (ASP) accepting messages not meant
for
> it, the same will anyway happen for case a). I am not sure if case c) is
clearly
> allowed/prohibited by M3UA RFC.
>
> Best Regards,
> -Sandeep
>