Subject: who generates the MTP3 services expected by a remote MTP3 user?

From: Jacques Rajchgod <[email-masked]>
Date: Wed, 15 Aug 2001 09:21:15 -0500

Throughout the M3UA-06 draft doc, the text expounds the principle that M3UA
is an adaptation layer that recreates/simulates or otherwise offers the
services expected by an SCN from its immediately-lower layer (Section
1.3.1). Ex: M3UA would offer to a remote SSCP the services of an MTP3 as
would be found at a local MTP3.
M3UA would offer to a remote ISUP the same services that a local ISUP would
expect. Section 1.3.2 further beautifies the principle by explaining that
remote entities do not even know that their "reproduced MTP3" is not native!
All these explanations dribble-down to this: An M3UA offers the services
expected by its user. Put in different words, I would write: "M3UA
generates - at the remote point - the services expected by the remote MTP3
user." However, section 1.3.2 also states (9 lines into it) that M3UA does
not itself provide the MTP3 service. This seems contradictory. One statement
says that it YES provides the services expected, while another statement
says "NO  - it does not ITSELF offer the expected services...". Confusing.

Jacques Rajchgod
MCI Worldcom
Next Generation System Evaluation
Tel: [972] 729-1487
E-mail: [email-masked]

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 10:21:58 -0500

Jacques,

I would say "M3UA transports" rather than "M3UA generates".
I don't see any implied contradiction here, M3UA provides
the same service interface to MTP-Users as does MTP.  It
does not provide the services themselves, it merely transports
the service primitive interface from MTP-Provider to MTP-User.
Or, that is the intent anyway.  Taken along with RFC 2719,
which is referenced in the document, it should appear to
be clearer.  Will you propose improved wording?

--brian

Jacques Rajchgod wrote:                                   (Wed, 15 Aug 2001 09:21:15)
> 
>    Throughout the M3UA-06 draft doc, the text expounds the principle that
>    M3UA is an adaptation layer that recreates/simulates or otherwise
>    offers the services expected by an SCN from its immediately-lower
>    layer (Section 1.3.1). Ex: M3UA would offer to a remote SSCP the
>    services of an MTP3 as would be found at a local MTP3.
>    M3UA would offer to a remote ISUP the same services that a local ISUP
>    would expect. Section 1.3.2 further beautifies the principle by
>    explaining that remote entities do not even know that their
>    "reproduced MTP3" is not native! All these explanations dribble-down
>    to this: An M3UA offers the services expected by its user. Put in
>    different words, I would write: "M3UA generates - at the remote point
>    - the services expected by the remote MTP3 user." However, section
>    1.3.2 also states (9 lines into it) that M3UA does not itself provide
>    the MTP3 service. This seems contradictory. One statement says that it
>    YES provides the services expected, while another statement says "NO
>    - it does not ITSELF offer the expected services...". Confusing.
>    
>    
>    
>    Jacques Rajchgod
>    MCI Worldcom
>    You are currently subscribed to sigtran as: [email-masked]
>    To unsubscribe send a blank email to
>    [email-masked]

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

---

---

From: Jacques Rajchgod <[email-masked]>
Date: Wed, 15 Aug 2001 10:33:23 -0500

Thanks, Brian...

Yes, I would like to propose different wording. This is very important for
industry circles charged with generating Test Case suites for UA
service/SIGTRAN verifications...What do I need to do to cause the
appropriate action item?

Kindly,

Jacques Rajchgod
MCI Worldcom

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2001 10:22 AM
> To: sigtran
> Subject: Re: who generates the MTP3 services expected by a remote MTP3
> user?
>
>
> Jacques,
>
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Jacob Heitz <[email-masked]>
Date: Wed, 15 Aug 2001 08:36:08 -0700

Could you propose alternative text ?

> Jacques Rajchgod wrote:
> 
> Throughout the M3UA-06 draft doc, the text expounds the principle that M3UA is an adaptation layer that recreates/simulates or otherwise offers the services expected by an SCN from its immediately-lower layer (Section 1.3.1). Ex: M3UA would offer to a remote SSCP the services of an MTP3 as would be found at a local MTP3.
> M3UA would offer to a remote ISUP the same services that a local ISUP would expect. Section 1.3.2 further beautifies the principle by explaining that remote entities do not even know that their "reproduced MTP3" is not native! All these explanations dribble-down to this: An M3UA offers the services expected by its user. Put in different words, I would write: "M3UA generates - at the remote point - the services expected by the remote MTP3 user." However, section 1.3.2 also states (9 lines into it) that M3UA does not itself provide the MTP3 service. This seems contradictory. One statement says that it YES provides the services expected, while another statement says "NO  - it does not ITSELF offer the expected services...". Confusing.
> 
> 
> 
> Jacques Rajchgod
> MCI Worldcom
> You are currently subscribed to sigtran as: [email-masked]

-- 
// Jacob Heitz, Planet of the APX. Tel:510-747-2917

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 10:51:04 -0500

Jacques,

I believe that you can post your text proposal right here.
With concensus it should be included in the draft.

Would you elaborate a little more on the importance to
test case suites?  (The importance may not be so immediately
obvious to some participants here.)

--brian

Jacques Rajchgod wrote:                                   (Wed, 15 Aug 2001 10:33:23)

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

---

---

From: Jacques Rajchgod <[email-masked]>
Date: Wed, 15 Aug 2001 11:22:40 -0500

If the consensus were that M3UA does not recreate nor generate the MTP
services at its remote point, but rather receives them from a sender and
merely forwards them up the chain - at its remote point, then my proposed
re-wording would be as follows, in the form of clear bullets:

  a.. M3UA does not itself generate MTP services.
  b.. M3UA receives from a sender - the MTP services expected by a remote
MTP-user.
  c.. M3UA at its remote point, forwards the received MTP services to the
remote MTP-user.
In response to Brian F. G mail - just received, I would clarify the need for
the rewording as follows:
If I am a person responsible for generating Tes Case suites, I need to know
how to simulate/replicate the scenarios described by the IETF, so I do valid
Test Cases. Thus, I need to know for sure who generates the MTP services at
the remote point, so I can make it happen in my lab per the clear specs of
the IETF.
If it is M3UA that does it, then I'll find means in my lab to have M3UA
itself generate the MTP-like services (by working with the particular
manufacturer). If not, if M3UA does not generate the services but rather
forwards them, then I'll see to it that M3UA in my lab only forwards them
and does not generate them. I need ensure that my Test Cases are
eflective  - exactly - of the IETF specs, so the products that I certify can
be marketed as bearing the IETF recommendations (PICS). That is why I need
to know for sure who-does-what...

My appreciation.

Jacques Rajchgod
MCI Worldcom

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Jacob
> Heitz
> Sent: Wednesday, August 15, 2001 10:36 AM
> To: sigtran
> > Throughout the M3UA-06 draft doc, the text expounds the
> principle that M3UA is an adaptation layer that
> recreates/simulates or otherwise offers the services expected by
> an SCN from its immediately-lower layer (Section 1.3.1). Ex: M3UA
> would offer to a remote SSCP the services of an MTP3 as would be
> found at a local MTP3.
> > M3UA would offer to a remote ISUP the same services that a
> local ISUP would expect. Section 1.3.2 further beautifies the
> principle by explaining that remote entities do not even know
> that their "reproduced MTP3" is not native! All these
> explanations dribble-down to this: An M3UA offers the services
> expected by its user. Put in different words, I would write:
> "M3UA generates - at the remote point - the services expected by
> the remote MTP3 user." However, section 1.3.2 also states (9
> lines into it) that M3UA does not itself provide the MTP3
> service. This seems contradictory. One statement says that it YES
> provides the services expected, while another statement says "NO

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 11:50:12 -0500

Jacques,

I concur with your viewpoint and agree with the precept that "M3UA
does not itself generate MTP services", were that it be true in the
remainder of the document.

Stating these points up front may clarify the text which appeared on
the surface unclear, however, there are many places in the draft which
violate these three principles that you so lay out.

In particular, there are proponents in this WG which place the
semantic responsibility for providing MTP services into the hands of
M3UA at the ASP.  For example, the difference between ITUT and ANSI's
handling of when to send MTP-PAUSE primitives.

So, regardless of what principles are mentioned in overview, M3UA at
the ASP is not currently a transparent view of the MTP-Provider at the
SG.  Rather, the responsibilities for providing MTP-User interface
syntax and behavior is blurred between the SG and the ASP.

I feel for your plight in wishing to test M3UA implementations at the
ASP independently from M3UA implementation at the SG; however, with
the way things currently stand in the remainder of the draft, you will
be left no option but to fully regression test every brand of ASP with
every brand of SG to show any definitive level of compliance.

I see your situation as just another example of the problems generated
by violating layer principles and M3UA is abound with them.  I believe
that adding these three points to the document will have no effect on
the layer violations perceived by some to be strangely their preferred
approach.

Perhaps you would care to join the dicussion on the other (very long)
threads where current attitudes appear to not only make M3UA difficult
to monitor (making ferry-clip difficult) but to make M3UA impossible
to test in any formal manner.

I'm sorry if this sounds a little jaded, but my many attempts to
correct layer violations for interoperability have received some
strange dogmatic knee-jerk reaction that "rules are made to be
broken." Aside from my own, I believe that your issue will fall on
deaf ears here.

I should also point out that IETF is not in the habit of generating
PICS Proforma, you must have most certainly encountered layer
violation difficulties with other IETF protocols.

Other comments?

--brian

Jacques Rajchgod wrote:                           (Wed, 15 Aug 2001 11:22:40)
>    services at its remote point, but rather receives them from a sender
>    and merely forwards them up the chain - at its remote point, then my
>    proposed re-wording would be as follows, in the form of clear bullets:
>
>      * M3UA does not itself generate MTP services.
>      * M3UA receives from a sender - the MTP services expected by a
>        remote MTP-user.
>      * M3UA at its remote point, forwards the received MTP services to
>        the remote MTP-user.
>        
>    In response to Brian F. G mail - just received, I would clarify the
>    need for the rewording as follows:
>    
>    If I am a person responsible for generating Tes Case suites, I need to
>    know how to simulate/replicate the scenarios described by the IETF, so
>    I do valid Test Cases. Thus, I need to know for sure who generates the
>    MTP services at the remote point, so I can make it happen in my lab
>    per the clear specs of the IETF.
>    
>    If it is M3UA that does it, then I'll find means in my lab to have
>    M3UA itself generate the MTP-like services (by working with the
>    particular manufacturer). If not, if M3UA does not generate the
>    services but rather forwards them, then I'll see to it that M3UA in my
>    lab only forwards them and does not generate them. I need ensure that
>    my Test Cases are reflective  - exactly - of the IETF specs, so the
>    products that I certify can be marketed as bearing the IETF
>    recommendations (PICS). That is why I need to know for sure
>    who-does-what...

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

---

---

From: Jacques Rajchgod <[email-masked]>
Date: Wed, 15 Aug 2001 13:01:32 -0500

Thanks, Brian...

I understand that the IETF does not generate PICS Proformas, as PICS are
vendor-specific statements of their products. I meant to say that when I
test a vendor product that is accompanied by a PICS sheet, the latter will
typically state what standards the product complies with, and at that time -
that's when I would need to get ahold of an accurate IETF standard...matter
why I had mentioned PICS in my last mail...
Thanks for your input...that now gives me good info.

Jacques Rajchgod
MCI Worldcom

> Sent: Wednesday, August 15, 2001 11:50 AM
> To: sigtran

---

---

From: [email-masked]
Date: Wed, 15 Aug 2001 14:06:33 -0400

An opinion

Seems to me that the PICS Proformas defined by the ITU are much less 
rigorous that previous Q.781/782 type documents and really only spell out 
the features of a protocol to which a vendor puts a check and says comply 
or not. Does not seem like a bad thing to have for the SCTP and MxUAs.

Seamus 

Jacques Rajchgod <[email-masked]>
08/15/2001 02:01 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        RE: who generates the MTP3 services expected by a remote MTP3 user?

Thanks, Brian...

I understand that the IETF does not generate PICS Proformas, as PICS are
vendor-specific statements of their products. I meant to say that when I
test a vendor product that is accompanied by a PICS sheet, the latter will
typically state what standards the product complies with, and at that time 
-
that's when I would need to get ahold of an accurate IETF 
standard...matter
why I had mentioned PICS in my last mail...
Thanks for your input...that now gives me good info.

Jacques Rajchgod
MCI Worldcom

> Jacques Rajchgod wrote:                           (Wed, 15 Aug

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to 
[email-masked]

---

---

From: [email-masked]
Date: Wed, 15 Aug 2001 14:14:39 -0400

Jacques,

I would refine your quote to "M3UA recreates - at the remote point - the 
services expected by the remote MTP3 user". M3UA is merely a way of 
tunneling SS7 signaling through the IP network and re-creating it at the 
other side for the MTP3 user.

Barry Nagelberg
Software Engineer
RadiSys, Corp.
Signaling Products Design Center
[email-masked]
+1-856-642-9229 x237

08/15/01 10:21 AM

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        who generates the MTP3 services expected by a remote MTP3 user?

Throughout the M3UA-06 draft doc, the text expounds the principle that 
M3UA is an adaptation layer that recreates/simulates or otherwise offers 
the services expected by an SCN from its immediately-lower layer (Section 
1.3.1). Ex: M3UA would offer to a remote SSCP the services of an MTP3 as 
would be found at a local MTP3. 
M3UA would offer to a remote ISUP the same services that a local ISUP 
would expect. Section 1.3.2 further beautifies the principle by explaining 
that remote entities do not even know that their "reproduced MTP3" is not native! All these explanations 
dribble-down to this: An M3UA offers the services expected by its user. 
Put in different words, I would write: "M3UA generates - at the remote point - the services expected by the 
remote MTP3 user." However, section 1.3.2 also states (9 lines into it) that M3UA does not itself provide the MTP3 service. This seems contradictory. One statement says that it YES provides the 
services expected, while another statement says "NO  - it does not ITSELF 
offer the expected services...". Confusing. 

Jacques Rajchgod
MCI Worldcom
 
---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to 
[email-masked] 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 13:32:05 -0500

Jacques,

Good luck with a vendor PICS as well: there are only a handful
of MUST and SHOULDs in the draft.  An insufficient number to
determine compliance far less conformance.  A section-by-section
paragraph-by-paragraph compliance statement will be of little
more use.

On the other hand, it is quite possible to use the PICS, PIXIT,
and conformance test quites for MTP against a combined SG/ASP
IUT, and I suggest you perform or require the same test results
before declaring any implementation SS7 worthy (far less IETF
worthy).

--brian

Jacques Rajchgod wrote:                                   (Wed, 15 Aug 2001 13:01:32)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 13:34:06 -0500

Seamus,

I believe you are confusing PICS and PIXIT.

--brian

[email-masked] wrote:              (Wed, 15 Aug 2001 14:06:33)

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

---

---

From: [email-masked]
Date: Wed, 15 Aug 2001 15:06:32 -0400

Brian,

Actually referring to the type of Protocol Impmlementation Conformance 
Statement (PICS) found, as an example, in the appendix of such protocols 
as ITU Q.2110 and Q.2140, Q.2130. These list out all the keys aspects of a 
protocol and a vendor claims to be compliant or not.

 Seamus 

"Brian F. G. Bidulock" <[email-masked]>
08/15/2001 02:34 PM
Please respond to sigtran

        To:     "sigtran" <[email-masked]>
        cc: 
        Subject:        Re: who generates the MTP3 services expected by a remote MTP3 user?

Seamus,

--brian

[email-masked] wrote:              (Wed, 15 Aug 2001 
14:06:33)

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 14:25:12 -0500

Seamus,

I equate Q.781/782 to PIXIT, not PICS.  I just thought
that you were comparing apples and oranges by comparing
Q.78x to PICS.  There is really no comparison there,
they are completely different levels of document: PICS
is a vendor's written conformance statement, Q.781/782
are conformance test suites.

--brian

[email-masked] wrote:              (Wed, 15 Aug 2001 15:06:32)
> protocol and a vendor claims to be compliant or not.
[snip]
> > the features of a protocol to which a vendor puts a check and says >comply 

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

---

---

From: [email-masked]
Date: Wed, 15 Aug 2001 15:27:50 -0400

Exactly! Though the content of the PICS (the boxes and items that need to 
be checked off is formalized) -  so what I am saying is that it is not a 
bad idea to have a formalized PICS for the SCTP and MxUA so that all 
vendors are checking off the same list of boxes.

Seamus

08/15/2001 03:25 PM

Seamus,

--brian

15:06:32)

[snip]

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 15 Aug 2001 16:09:38 -0500

Seamus,

I would be very interested to see your draft of PICS for xUA.
A couple of questions:

    - How will it differ greatly from an AS or BCP?
    - Will it be available before the xUA goes even to Proposed Standard?
    - Before it becomes a Standard?

--brian

[email-masked] wrote:              (Wed, 15 Aug 2001 15:27:50)

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

---

---

From: [email-masked]
Date: Thu, 16 Aug 2001 11:57:00 -0400

If it somehow came across that I had written a draft PICS that is 
certainly not the case. I do think it is a good idea to do and will 
probably ask our system test to look into it.

Seamus

08/15/2001 05:09 PM

Seamus,

--brian

15:27:50)

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

---

---