Subject: Re: M3UAv8: point code representation

From: Jeff Copley <[email-masked]>
Date: Fri, 03 Aug 2001 13:14:36 -0500

Hello Maria-Cruz,

I have one minor comment.  Please see below.

Regards,

Jeff

"Maria-Cruz Bartolome-Rodrigo (ECE)" wrote:
> 
> Hi all,
> 
> According to the following parragraph:
> 
> ---------------------------------------------------------------------
> 1.4.1 Signalling Point Code Representation
> 
> .......
> Application Servers can be represented under the same Point
> Code of the SG, their own individual Point Codes or grouped with other
> Application Servers for Point Code preservation purposes.  A single
> Point Code may be used to represent the SG and all the Application
> Servers together, if desired.
> ---------------------------------------------------------------------
> 
> Although this sentence is not under discussion and it is an assumption
> generally agreed upon, I find a problem with that.
> 
> Let's say we do NOT have a single PC to represent the SG and all the ASs,
> on the contrary, we have one PC for the SG and one/several PCs for the ASs.
> (This is what happens e.g. in the STP case)
> In that case, when the MTPL3 at the SGP receives a message whose DPC is
> NOT the SG PC but any of those DPCs assigned to the ASs, then the MTPL3
> will divert this message to MTP-L2 rather than to a NIF (it detects
> the PC in the message is not the 'own PC' then the message should be
> relayed).
> 
> Then, if I'm not wrong, to have the right behaviour we are expecting, the
> MTPL3 should be somehow modified, updating its routing tables to be able
> to route towards EITHER the 'SS7 domain' via MTPL2 OR the 'IP domain' via NIF/M3UA
> OR a possible local MTPL3 User.

[Jeff] There would not be a local MTPL3 user in this case since the
received DPC is not that of the SG.  Right?
> 
> If you agree this should be stated in the draft, although it may not be
> easily accept that a 'protocol layer' could impose 'requirements' on others...
> 
> Please, comments on that?
> 
> /MCruz
> 
> ---
> You are currently subscribed to sigtran as: [email-masked]
> To unsubscribe send a blank email to [email-masked]

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

---

From: "Cheu, Janey M, NNAD" <[email-masked]>
Date: Fri, 3 Aug 2001 14:48:07 -0400

Hi Maria-Cruz & Jeff:
See below for my comments.
Janey

Janey M.Y. Cheu
AT&T
Signaling Planning District
200 Laurel Avenue, Room E3-3D26
Middletown, NJ 07748   USA
Tel: +1 732.420.4598   Fax: +1 732.368.6703
Email: [email-masked]

> ----------
> From: 	Jeff Copley[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	August 3, 2001 2:14 PM
> To: 	sigtran
> Subject: 	Re: M3UAv8: point code representation
> 
> <<File: Jeff.Copley.vcf>><<File: ATT735999.txt>>
> Hello Maria-Cruz,
> 
[Janey]  If the message is for the ASs associated with the SG, we would
treat the other Point Codes (PCs) as we do today when dealing with alias
PCs.  They are viewed as being "in back of" the SG and handled by the
discrimination function (i.e., the procedure is implementation specific)
before they are handled by the routing function.  Also, I have a comment on
the terminology "the MTP3 will divert this mesage to the MTP-L2" -- it
sounds a bit misleading as it implies that the MTP-L2 will route the message
but it has no routing function other than a "nailed down" link.

> > To unsubscribe send a blank email to
> [email-masked]
> 

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 3 Aug 2001 12:23:31 -0700

Maria,

I decided that I would add my 2 cents worth.  See below.

John

> -----Original Message-----
> From: Cheu, Janey M, NNAD [mailto:[email-masked]]
> Sent: Friday, August 03, 2001 1:48 PM
> To: sigtran
> Subject: RE: M3UAv8: point code representation
> 
> 
> Hi Maria-Cruz & Jeff:
> > > Let's say we do NOT have a single PC to represent the SG 
> and all the
> > ASs,
> > > on the contrary, we have one PC for the SG and 
> one/several PCs for the
> > ASs.

[John]  I agree with you.  I think the more common case is where SG is
acting as an STP and only has its own PC (plus an alias PC for GTT
functionality).  The signalling end-points (SEP) (the AS is only a logical
not a physical concept, perhaps a sub-set of the SEP's functionality) has a
PC (or multiple PCs). 

> > > the PC in the message is not the 'own PC' then the 

[John]  Look at the figure below.  It shows the flow.

                   +-----------------------+      +------------------------+
  Message with     |           SG          |      |      SEP (PC = X)      |
    DPC = X   ---> | MTP2->MTP3->NIF->M3UA | ---> | M3UA->ISUP/SCCP->Appl. |
  (SS7 Network)    +-----------------------+      +------------------------+

The message from the SS7 network with DPC = X must be handled by the SS7
stack at the SG and handed over to the SS7 over IP stack (in this case M3UA)
via the NIF.  If the message's DPC had been the SGs, the SS7 stack would
have looked for an MTP-user at the SG (as in the case of GTT when the
message's DPC = SG and SI = SCCP).

> > > Then, if I'm not wrong, to have the right behaviour we 
> are expecting,
> > the
> > > to route towards EITHER the 'SS7 domain' via MTPL2 OR the 
> 'IP domain'
> > via NIF/M3UA
[John]  What you state here does match my figure and this is how I think it
works.  Any messages destined to the 'IP domain' need to be passed over to
the NIF/M3UA as part of a routing function.  But now we are talking
implementation.

> > > easily accept that a 'protocol layer' could impose 
> 'requirements' on
> > others...
> > > 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 3 Aug 2001 15:03:48 -0500

Maria-Cruz,

Essentially, there are two approaches to the STP connected case:
the SG/ASP approach and the IPSP approach as follows:

SG/ASP Approach:
                                         __________   
                                        |          |  
                                        | MTP-User |  
                                        |          |  
                                        |          |  
                                        |          |  
                   ___             ___  |__________|  
                  |   |           |   |     ^  ^      
                  | M |           | M |     |  |      
            +---->| 3 |<--------->| 3 |<----+  |      
            |     | U |           | U |        |      
          __v__   | A |           | A |        |      
         |     |  |___|           |___|        |      
         | MTP |   SGP             ASP         |      
    SG1  |     |                               |      
         |     |                               |      
         |_____|                               |      
                                               |      
                                               |      
                                               |      
                   ___             ___         |      
                  |   |           |   |        |      
                  | M |           | M |        |      
            +---->| 3 |<--------->| 3 |<-------+      
            |     | U |           | U |               
          __v__   | A |           | A |               
         |     |  |___|           |___|               
         | MTP |   SGP             ASP                
    SG2  |     |                                      
         |     |                                      
         |_____|                                      

In the SGP/ASP approach above, the AS Point Code is an alias of each
of the STPs as well.  This alias point code is exported using M3UA
backhaul to the ASP.  The difficulty with this arrangement is that
the restricted status of routesets from the AS point code must be
communicated using DRST to the AS.  The ASP must keep track of the
availability, restriction and congestion of routesets via each SG.
Also, the SG MUST communicate with each other concerning user part
availability to know when to send UPU to the SS7 network.  This is
not a straighforward export of the MTP to MTP-User interface per the
backhaul case.  It is not very workable using third-party MTP stacks
(as you way, M3UA requires changes to the layer below).

ISPS Approach:
                                         __________   
                                        |          |  
                                        | MTP-User |  
                                        |          |  
                                        |          |  
                                        |          |  
                                        |__________|  
          ________________                    ^       
         |                |                   |       
         |_____ NIF ______|                ___v__     
         |     |   |      |               |      |    
         | MTP |   | M3UA |               | M3UA |    
    SG1  |     |   | IPSP |               | IPSP |    
         |     |___|______|               |______|    
         |_____|       ^                    ^  ^      
                       |                    |  |      
                       +--------------------+- |      
                                               |      
          ________________                     |      
         |                |                    |      
         |_____ NIF ______|                    |      
         |     |   |      |                    |      
         | MTP |   | M3UA |                    |      
    SG1  |     |   | IPSP |                    |      
         |     |___|______|                    |      
         |_____|       ^                       |      
                       |                       |      
                       +-----------------------+      

In the IPSP approach above, the MTP interface is not exported, each
SG with its own point code acts as a point code in the IP network.
The AS is a completely separate IPSP point code within the IP
domain.  In this case, the associations are more likened to
linksets.  Rather than exporting the MTP interface, the entire point
code resides at the AS and the SG perform no management functions
with respect to it, only routing functions.  The M3UA at the SG acts
as a routeset towards the AS and the SG only performs routing
functions.  This has none of the problems of the above case.

But this is mostly undefined behavior for M3UA (the IPSP to IPSP
case).  I raised a question to Greg some months ago concerning the
need for an M3PA to address this situation.  The feeling at the time
was that M3UA was sufficient (the SG/ASP case).  Certainly M2PA
could be used in this case; however, M2PA is a little too low down
for what is required (inter-link changeover and changeback within
the linkset is not required; other per-link signals are not
required).  Identification of a Signalling Link Set or Signalling
Route Set interface within MTP3 would provide the ability to perform
this interworking function with less chance of significant
interoperability issues arrising.

Certainly in the IPSP scenario, there is no need to go unpacking
TFPs and such into DUNAs and such: the SCTP assocation could be used
identically to a link set.

All in all, you are correct.  M3UA fails to properly address the
"multiple SG acting as STP" case.

--Brian

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Fri, 03 Aug 2001 16:00:16)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 3 Aug 2001 13:24:42 -0700

Hey Brian, whatcha' smoking!

Your first picture is better example of a pair of SGs acting in the STP
capacity.  I would say the MTP-user/M3UA node has its own point code that is
not a virtual PC associated with either SG.

Your second figure doesn't exist at all.  IPSP to IPSP is signalling
end-point to signalling end-point or may be SG to SG.  Look at the
definitions and figures in M3UA.

John

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Friday, August 03, 2001 3:04 PM
> To: sigtran
> and all the ASs,
> 'IP domain' via NIF/M3UA
> 'requirements' on others...
> > 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 3 Aug 2001 15:34:16 -0500

John,

There is nothing precluding an STP from being an IPSP w.r.t.
its own point code in the IP domain.

The first figure still has problems.

--brian

John Schantz wrote:                                          (Fri, 03 Aug 2001 13:24:42)

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

---

---

From: "Maria-Cruz Bartolome-Rodrigo (ECE)" <[email-masked]>
Date: Mon, 6 Aug 2001 12:10:09 +0200

John, Brian,

See comments below
/MCruz

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Friday, August 03, 2001 10:34 PM
To: sigtran
Subject: Re: M3UAv8: point code representation

John,

--brian

> > of the STPs as well.  

Is that your opinion about how it should be? I haven't read any 
explanation at all about 'alias PCs' in the draft...

> > This alias point code is exported using M3UA

I agree with John, I do not think this is a valid IPSP-to-IPSP scenario.
An IPSP is meant to do not have a NIF interface... moreover, I do not
see the need for this scenario at all.

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

---
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: Mon, 6 Aug 2001 10:18:19 -0500

Maria-Cruz,

Please see comments below....

Maria-Cruz Bartolome-Rodrigo (ECE) wrote:              (Mon, 06 Aug 2001 12:10:09)
> explanation at all about 'alias PCs' in the draft...

The draft doesn't really explain the multiple SG as STP arrangement
does it?  Maybe because it doesn't work in fitting with the SIGTRAN
architecture?  This shown is the only way to "export the MTP/MTP-User
interface" as stated in the draft.

> see the need for this scenario at all.

The NIF is outside the scope of the draft.  This is as valid a IPSP
arrangement as any described in the draft.

--Brian

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

---

---

From: "Cil, Serkan" <[email-masked]>
Date: Mon, 6 Aug 2001 12:23:39 -0500

I think MCruz means the SG configuration where it is configured to be seen
as an STP in the SS7 network. In this case the PCs represented by ASs 
are different than SGs own PC. 

> > > > > OR a possible local MTPL3 User.

I agree with the approach where there is a need to modify MTPL3. But I don't
think that it should be stated in the spec. It is rather an implementation
detail.

Serkan Cil.

> Sent: Monday, August 06, 2001 11:18 AM
> To: sigtran
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Greg Sidebottom <[email-masked]>
Date: Mon, 6 Aug 2001 14:06:33 -0400

Hi Maria-Cruz, Brian

A small comment or two below ...

----- Original Message -----
From: "Maria-Cruz Bartolome-Rodrigo (ECE)"
<[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, August 06, 2001 6:10 AM
Subject: RE: M3UAv8: point code representation

> explanation at all about 'alias PCs' in the draft...

[Greg] This a troublesome internal SG aspect to explain in the STP-model.  I
think that it is easier for an SG implementing an STP-model to not view M3UA
as a backhaul case (and thus not exporting the MTP to MTP-User interface)
but rather have internal MTP3 routesets to the the other non-SG Point Codes.
But one way around this is to view the "non-SG" Point Codes as alias point
codes in the MTP3 discrimination function of the SGs to direct messages to
an internal MTP3-User - the NIF.  Then the NIF sends the messages to the
M3UA for routing on the IP side.

> > > communicated using DRST to the AS.

[Greg] Brian, wouldn't a DRST from the SG reflect the restricted status of
routesets from the SG's Point Code, not the AS point code?

Cheers,

  Greg

The ASP must keep track of the
>
>
> ---
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Aug 2001 14:26:46 -0500

Serkan,

If the multiple SG as STP configuration is such an implementation
detail, how can SG and ASP be expected to interoperate?

--Brian

Cil, Serkan wrote:                                           (Mon, 06 Aug 2001 12:23:39)

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Aug 2001 14:32:53 -0500

Greg,

Please see comments below...

Greg Sidebottom wrote:                        (Mon, 06 Aug 2001 14:06:33)
> but rather have internal MTP3 routesets to the the other non-SG Point Codes.

I am glad that someone else is on the same page here.  If not the backhaul
case, then the ISPS case, correct?  Or are you suggesting that this
falls in some unspecified netherland between the case 1 and 2 in the
SIGTRAN architecture?

> M3UA for routing on the IP side.

The above will not work because two SG MTPs will still be responsible
for user part availability.  When does each SG send UPU with regard to
user parts on this "alias" point code?  Some additional closely coupled
SG to SG communication would be required.

> routesets from the SG's Point Code, not the AS point code?

Yes.  You miss the point: there is no "restricted" MTP-STATUS indication
in defined the MTP-User interface.  Getting this "restricted" status
upon which to generate the DRST must constitute modifications to the
underlying MTP Level 3 implementation.

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

---

---

From: "Cil, Serkan" <[email-masked]>
Date: Mon, 6 Aug 2001 18:24:40 -0500

Brian:

definitely multiple SG as STP configuration is not an implementation
detail and should be cleared in the spec further. What I was referring to
is my understanding of MCruz's question which I depict with a simple
scenario
where we have an SG with a single SGP and an ASP:
                 
      +------+-----+           +------+     
      |OPC=X |     |           | PC=Y |
    --| MTP  | NIF |-----------| ASP  |
      |      |     |           |      |
      +------+-----+           +------+
            SGP

So the question is: how can MTP forward the MSUs received for PC Y to NIF?

As MCruz states:
> > > > > > > In that case, when the MTPL3 at the SGP receives 
> a message 
> > > > > > whose DPC is 
> > > > > > > Then, if I'm not wrong, to have the right 
> behaviour we are 
> > > > > > expecting, the

And I agree with this approach, however, IMHO, this suggests a requirement
for MTP3
and I don't feel the need for such a requirement in M3uA spec. 

regards
Serkan

> Sent: Monday, August 06, 2001 3:27 PM
> To: sigtran
> > > > > > > Then, if I'm not wrong, to have the right 
> behaviour we are 
> > > > > > expecting, the
> > > > > > Maria-Cruz Bartolome-Rodrigo (ECE) wrote:           
>    (Fri, 
> > > > > > 03 Aug 2001 16:00:16)
> > > > > > > 
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > Code of the SG, their own individual Point Codes 
> or grouped 
> > > > > > with other 
> > > > > > > Although this sentence is not under discussion 
> and it is an 
> > > > > > assumption
> one/several 
> > > > > > PCs for the ASs.
> > > > > > > In that case, when the MTPL3 at the SGP receives 
> a message 
> > > > > > whose DPC is 
> > > > > > > Then, if I'm not wrong, to have the right 
> behaviour we are 
> > > > > > expecting, the

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 6 Aug 2001 20:07:15 -0500

Serkan,

Cil, Serkan wrote:                           (Mon, 06 Aug 2001 18:24:40)
> detail and should be cleared in the spec further. What I was referring
> to is my understanding of MCruz's question which I depict with a
> simple scenario where we have an SG with a single SGP and an ASP:
>                  
>       +------+-----+           +------+     
>       |OPC=X |     |           | PC=Y |

Two possibilities:

  1)	PC=Y is an "alias" or "virtual" point code of the MTP at PC=X.
	Then the MTP will forward messgaes for PC=Y to NIF.  This was my
	"backhaul" case.

  2)	NIF is part of the MTP at PC=X.  This was my "IPSP" case.

> 
> As MCruz states:
> > > > > > > > In that case, when the MTPL3 at the SGP receives a
> > > > > > > > message whose DPC is NOT the SG PC but any of those DPCs
> > > > > > > > assigned to the ASs, then the MTPL3 will divert this
> > > > > > > > message to MTP-L2 rather than to a NIF (it detects the
> > > > > > > > PC in the message is not the 'own PC' then the message
> > > > > > > > should be relayed).
> > > > > > > > 
> > > > > > > > are expecting, the MTPL3 should be somehow modified,
> > > > > > > > updating its routing tables to be able to route towards
> > > > > > > > EITHER the 'SS7 domain' via MTPL2 OR the 'IP domain' via
> > > > > > > > NIF/M3UA OR a possible local MTPL3 User.
> 
> And I agree with this approach, however, IMHO, this suggests a
> requirement for MTP3 and I don't feel the need for such a requirement
> in M3uA spec. 

Indeed, both possbilities place a requirement on MTP3 (that is the MTP3
implementation must be modified from the original to support M3UA in
this configuration).  There is no getting around it.

For the backhaul case, restricted routeset status must be exposed to the
MTP-User requring an extension to MTP-STATUS indication.  Also, the
MTP-User must be placed under control for sending UPU messages,
requiring an MTP-STATUS request to the MTP.  Also, the MTP must be aware
that this is a "virtual" point code and that local MTP unavailability
does not mean that the routeset is prohibited: it may still be available
via the alternate STP.  This requires routing changes in the MTP if the
MTP implementation does not already support the concept of a "virtual"
point code.

--brian

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Tue, 7 Aug 2001 01:14:50 -0400

Hi Brian

More below ...

BTW what font are you using for drawing of your diagrams? - Maybe it is just
me but I am having a hell of a time trying to figure them out in my Outlook
Express so I am probably missing valuable information.

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Monday, August 06, 2001 3:32 PM
Subject: Re: M3UAv8: point code representation

> > > John Schantz wrote:                                          (Fri, 03
Aug
> > 2001 13:24:42)

[Greg2]  Maybe, I'm not sure that this is the IPSP case.  (I'm assuming that
you are referring to the two cases you have drawn in your e-mail, that I am
having trouble viewing)?

The NIF is now shown as being both between and on top of the MTP3 and M3UA
layers in the SG.  So I guess there are other possibilities for how to show
the communication inside the SG.  I suppose that the primitive police will
not knock on your door to enforce one model or the other.

> SG to SG communication would be required.

[Greg2] An SG in this model shouldn't send a UPU.  I'm not sure why an SG
(acting like an STP) would send a UPU with regard to an "alias" point code.
It doesn't have enough information to trigger this procedure.  I think that
STPs in the SS7 network would not originate UPUs on behalf of any aliases
either.

> underlying MTP Level 3 implementation.

[Greg2] Yes I think I see now - the MTP3 has to tell the M3UA somehow.

Thanks,

   Greg

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 7 Aug 2001 01:49:50 -0500

Greg,

Comments below...

Greg Sidebottom wrote:                                (Tue, 07 Aug 2001 01:14:50)
> Hi Brian
> 
> More below ...
> 
> BTW what font are you using for drawing of your diagrams? - Maybe it
> is just me but I am having a hell of a time trying to figure them out
> in my Outlook Express so I am probably missing valuable information.

It is not a font, it is ASCII.  Does OE have problems displaying ASCII?
(ASCII drawings are best viewed with a fixed pitch font.)

> > > > > Your first picture is better example of a pair of SGs acting
> > > > > in the STP capacity.  I would say the MTP-user/M3UA node has
> > > > > its own point code that is not a virtual PC associated with
> > > > > either SG.
> > > > >
> > > > > Your second figure doesn't exist at all.  IPSP to IPSP is
> > > > > signalling end-point to signalling end-point or may be SG to
> > > > > SG.  Look at the definitions and figures in M3UA.
> > > > >
> > > > > John
> > > > >
> > > > > > Essentially, there are two approaches to the STP connected
> > > > > > case: the SG/ASP approach and the IPSP approach as follows:
> > > > > >
> > > > > > SG/ASP Approach:
> > > > > >                                          __________
> > > > > >                                         |          |
> > > > > >                                         | MTP-User |
> > > > > >                                         |          |
> > > > > >                                         |          |
> > > > > >                                         |          |
> > > > > >                    ___             ___  |__________|
> > > > > >                   |   |           |   |     ^  ^
> > > > > >                   | M |           | M |     |  |
> > > > > > In the SGP/ASP approach above, the AS Point Code is an alias
> > > > > > of each of the STPs as well.
> > > >
> > > [Greg] This a troublesome internal SG aspect to explain in the
> > > STP-model.  I think that it is easier for an SG implementing an
> > > STP-model to not view M3UA as a backhaul case (and thus not
> > > exporting the MTP to MTP-User interface) but rather have internal
> > > MTP3 routesets to the the other non-SG Point Codes.
> >
> > I am glad that someone else is on the same page here.  If not the
> > backhaul case, then the ISPS case, correct?  Or are you suggesting
> > that this falls in some unspecified netherland between the case 1
> > and 2 in the SIGTRAN architecture?
> >
> 
> [Greg2]  Maybe, I'm not sure that this is the IPSP case.  (I'm
> assuming that you are referring to the two cases you have drawn in
> your e-mail, that I am having trouble viewing)?
> 
> The NIF is now shown as being both between and on top of the MTP3 and
> M3UA layers in the SG.  So I guess there are other possibilities for
> how to show the communication inside the SG.  I suppose that the
> primitive police will not knock on your door to enforce one model or
> the other.

Yes, this is why I proposed that the NIF be drawn "between" MTP
and M3UA: because M3UA cannot operating in the multiple SG mode
without modification to MTP3 at the SG.

> 
> 
> > > But one way around this is to view the "non-SG" Point Codes as
> > > alias point codes in the MTP3 discrimination function of the SGs
> > > to direct messages to an internal MTP3-User - the NIF.  Then the
> > > NIF sends the messages to the M3UA for routing on the IP side.
> >
> > The above will not work because two SG MTPs will still be
> > responsible for user part availability.  When does each SG send UPU
> > with regard to user parts on this "alias" point code?  Some
> > additional closely coupled SG to SG communication would be required.
> >
> 
> [Greg2] An SG in this model shouldn't send a UPU.  I'm not sure why an
> SG (acting like an STP) would send a UPU with regard to an "alias"
> point code.  It doesn't have enough information to trigger this
> procedure.  I think that STPs in the SS7 network would not originate
> UPUs on behalf of any aliases either.

Normally in the SS7 network "alias" point codes are only used to
represent the GTT function at the STP.  This is only one user.
UPU is not necessary in that case because UPU and TFP are the
same (an alias point code with only one user).

The general case for M3UA "alias" point codes is that they
represent multiple MTP Users (e.g. ISUP and SCCP).  Therefore,
it is possible, for example, that SCCP is unavailable while ISUP
is still available.  TFP is inappropriate in this case, UPU for
SCCP is the appropriate action.  Yes, STPs are not equipped to
deal with this, but the SGs will for the backhaul case if they
follow current MTP procedures.  The MTP at the SG will have to
be modified to either accept UPU from the ASP.

> > > > > > This alias point code is exported using M3UA backhaul to the
> > > > > > ASP.  The difficulty with this arrangement is that the
> > > > > > restricted status of routesets from the AS point code must
> > > > > > be communicated using DRST to the AS.
> > >
> > > [Greg] Brian, wouldn't a DRST from the SG reflect the restricted
> > > status of routesets from the SG's Point Code, not the AS point
> > > code?
> >
> > Yes.  You miss the point: there is no "restricted" MTP-STATUS
> > indication in defined the MTP-User interface.  Getting this
> > "restricted" status upon which to generate the DRST must constitute
> > modifications to the underlying MTP Level 3 implementation.
> >
> >
> 

Now think out UPU as well...

--brian

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Tue, 7 Aug 2001 12:02:54 +0200

Brian,

1. If we say the SG truly acts as an STP, then IMHO the valid solution
would be to alter the MTP routing function (i.e. put the NIF in MTP)
such that MTP can route MSUs either to the IP side or the SS7 side.
One benefit of this could be to have STP-like features such as SCCP
Global Title Translation implemented in the SG.
In that case M3UA at the SG acts in a backhaul fashion for the AS PC
(but not for the SG PC which is handled by MTP).

2. The scenario where the SG acts as a gateway between an MTP interface
and an IPSP M3UA is valid (for example IP-based SGSN interface in 3G mobile
networks). But this is neither backhaul nor STP behavior therefore it is
probably out of the scope of M3UA.

3. If we look at the AS as a virtual point code of the SG, then two cases:
 a. the AS point codes are not visible to the MTP interface. MSUs are
    received with DPC=VPC. The SG distributes them to AS and substitutes
    internally the PC with the AS PC (based on RK and/or load sharing)
    MSUs received from AS with OPC=AS PC are sent to MTP with OPC=VPC.
    The purpose for doing this could be to hide the internal SS7
configuration
    of the AS to the network, simplify management, and address PC/CIC
exhaustion
    or hiding issues. One VPC can represent many AS, and the traffic coming 
    from MTP can be discriminated by OPC.
    The SG must implement VPC management based on the AS SPMC states.
 
 b. the AS point codes are visible to the MTP users but not to SSNM
    (if they're also visible to SSNM, what's the difference between 
    VPC and STP?). 
    Traffic MSUs are received with DPC=AS PC per each application or
    DPC=VPC if the message concerns all AS.
    MSUs received from AS with OPC=AS PC are sent to MTP users with OPC=AS
PC.
    MSUs concerning the whole M3UA interface (e.g. if all ASPs are
unavailable)
    would be sent to MTP interface with OPC=VPC.
    Messages concerning an AS availability would be sent as UPU with OPC=AS
PC.
    The purpose for doing this could be to simplify the network management,
    and address PC/CIC exhaustion issues.
    In that case the IP side of the SG would also be seen as a single
    PC wrt to SSNM. Note that the SG can also act as a STP in that scenario
    but with another PC (e.g. for MTP purposes: routing, GTT,..).  
    It is unclear to me whether this model brings more benefits or issues
    (in particular the VPC management may be not trivial and introduces
     interoperability issues if not described clearly in the standard).

As a conclusion my feeling is that the easiest is probably to offer the STP
functionnality with the NIF built in MTP to address the IP interface.
Does anyone have comments on the need for having VPC in M3UA?

Francois Mouillaud.

> Sent: Tuesday, August 07, 2001 3:07 AM
> To: sigtran
> You are currently subscribed to sigtran as: 
> [email-masked]

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Tue, 7 Aug 2001 12:02:54 +0200

Brian,

 

Francois Mouillaud.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 9 Aug 2001 22:55:39 -0500

Francois,

Sorry for the delay in responding: I was sidetracked by Network
Appearance ;)

A couple of comments.

MTP can no easier perform this "virtual" PC function across multiple
STPs than can M3UA.  The only actual case in the SS7 network where
this is attempted is the "alias" point code which is assigned to
mated of STPs to address the GTT function.  This "virtual" GTT point
code does not present a problem from the perspective of User Part
flow control because the "alias" point code has only a single user:
the SCCP GTT function.

If one only wanted to export the common GTT function from mated
STPs, there are better ways of doing that which do not involve M3UA
(e.g. RPC, CORBA, ODC, DCE, ...).

In other cases where only a single user part is exported per point
code, then point code accessibility and user part accessibility
could be equated and the configuration will work in the back-haul
case or the virtual point code case you illustrate.

However, where multiple user parts are exported which are
independent of each other, the STPs will be incapable of performing
user part flow control on behalf of the signalling points.  This
means that, for both the back-haul and IPSP cases, the ASs must be
responsible for signalling UPU to the SGs and responding to UPT,
even for an inactive AS (the SG cannot determine user part
unavailability on the basis of AS activity because it does not know
the AS state at the other SG).  This also means that the SG must
forward any UPT or other user-part flow control messages related to
user parts at the AS to the AS.  There is no equivalent to a UPT
message in M3UA.

In both the back-haul and the IPSP cases, because the SG/STPs are
incapable of managing user-part flow control, it make sense not to
discriminate routing keys to the user-part level.  Otherwise the
SG/STP may be forced to route specific user-part messages over
C-links, but not others.  As there are no user-part-restricted
procedures in SS7, this could be permanent C-link traffic.  Consider
the case where one SG/STP has an AS active for ISUP but inactive for
SCCP and the other SG/STP has an AS active for SCCP but inactive for
ISUP.  Where are the SG's going to send the inactive AS traffic?  Is
the one SG going to send ISUP across C-links and the other send SCCP
across C-links?  The semi-permanent C-link traffic could endanger
the survivability of the mated STPs because there is no
user-part-restricted procedure to ask the network one hop back to
redirect the traffic.  Another failure could cause C-link exhaustion
and network isolation.

Therefore, it only makes sense in the SG/STP case to route traffic
on an entire point code basis (perhaps the only point that John and
I agree on).  Routing entire point code traffic, both the back-haul
and IPSP cases decomposes to a simple situation where the SCTP
associations to the ASP form a virtual route (i.e. link set).
Because this decomposes to a virtual link set, the multiple SG/STP
case is better addressed by M2PA than by M3UA.  Then one doesn't
have to go mucking with MTP at the HMDC or HMRT function, just strap
M2PA links to the ASPs under the Plain-Jane MTP3.

In conclusion:

   The back-haul case for multiple SGs can be handled if the MTP to
   MTP-User interface is enhanced to indicate signal route set
   restriction (really simple addition to MTP-STATUS indication),
   and all user parts are exported to the same AS and inexorably
   tied together in terms of user-part flow control (i.e. they are
   all available or all unavailable at a given SG).  M3UA already
   has everything necessary for this case.

   Neither the back-haul case nor the IPSP case require M3UA
   treatment at all.  M2PA provides the necessary functionality.
   The ASP can then deal with the SS7 SNTM and UFC messages itself
   rather than the bastardized M3UA versions.  The required
   procedures are the same, it is just the syntax of the messages
   which differs.  ASP management procedures in M3UA are replaced by
   signalling link signals to MTP2, and the resulting arrangement
   will work far better than any short-sighted ASP implementation of
   M3UA which gives little consideration for changeover,
   change-back, mis-sequencing, congestion, discard, buffer
   updating, flow control, force and controlled rerouting, and
   everything that MTP provides that M3UA leaves implementation
   dependent in the back-haul case or unspecified for the IPSP case.

   M2PA satisfies Maria-Cruz' understanding that these message a
   "passed down to MTP2" and I believe that this is what led Barry
   to say: "It sounds to me as though you should use M2PA, not
   M3UA."

--brian

(It is possible to accomplish this "virtual" point code concept for
all cases of user-part and finer routing keys only when there is a
closely-coupled communication between the two SGs.  But in that case
the two SGs look like two SGPs in one SG, so this would worm-hole to
the partitioned SGP discussion: what happens when--not if in this
case--the SGP get partitioned?)

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote: (Tue, 07 Aug 2001 12:02:54)
> Global Title Translation implemented in the SG.  In that case M3UA at
> the SG acts in a backhaul fashion for the AS PC (but not for the SG PC
> which is handled by MTP).
> 
> 2. The scenario where the SG acts as a gateway between an MTP
> interface and an IPSP M3UA is valid (for example IP-based SGSN
> interface in 3G mobile networks). But this is neither backhaul nor STP
> behavior therefore it is probably out of the scope of M3UA.
> 
>     received with DPC=VPC. The SG distributes them to AS and
>     substitutes internally the PC with the AS PC (based on RK and/or
>     load sharing) MSUs received from AS with OPC=AS PC are sent to MTP
>     with OPC=VPC.  The purpose for doing this could be to hide the
>     internal SS7 configuration of the AS to the network, simplify
>     management, and address PC/CIC exhaustion or hiding issues. One
>     VPC can represent many AS, and the traffic coming from MTP can be
>     discriminated by OPC.  The SG must implement VPC management based
>     on the AS SPMC states.
>  
>     VPC and STP?).  Traffic MSUs are received with DPC=AS PC per each
>     application or DPC=VPC if the message concerns all AS.  MSUs
>     received from AS with OPC=AS PC are sent to MTP users with OPC=AS
>     PC.  MSUs concerning the whole M3UA interface (e.g. if all ASPs
>     are unavailable) would be sent to MTP interface with OPC=VPC.
>     Messages concerning an AS availability would be sent as UPU with
>     OPC=AS PC.
>
>     The purpose for doing this could be to simplify the network
>     management, and address PC/CIC exhaustion issues.  In that case
>     the IP side of the SG would also be seen as a single PC wrt to
>     SSNM. Note that the SG can also act as a STP in that scenario but
>     with another PC (e.g. for MTP purposes: routing, GTT,..).  It is
>     unclear to me whether this model brings more benefits or issues
>     (in particular the VPC management may be not trivial and
>     introduces interoperability issues if not described clearly in the
>     standard).
> 
> As a conclusion my feeling is that the easiest is probably to offer
> the STP functionnality with the NIF built in MTP to address the IP
> interface.  Does anyone have comments on the need for having VPC in
> M3UA?
> 
> Francois Mouillaud.
> 
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Greg Sidebottom <[email-masked]>
Date: Fri, 10 Aug 2001 02:45:50 -0400

Hi Brian,

I'm having real problems with your views and conclusions below.  It is a
self-fulfilling prophesy if you are working to turn the M3UA into the MTP3
and then say that the M3UA/M2PA is better suited.  Am I misunderstanding
your views here?  I'm confused as it sounds like you want to build an SS7
network on the IP-side, although I note in other threads you say otherwise.

If you (and John?) are agreeing that the M3UA distribution function must be
reduced back to point code distribution only, and thus have RKs correspond
totally to MTP3 routes/linksets, then I strenuously disagree.  I also don't
want to see the perceived need for UPU procedures as driving a dumbing down
of the M3UA distribution possibilities.  To me this is the tail wagging the
dog.  I'd rather find some other solution or do without UPU.  (I will admit
a bias - I am not a fan of UPU procedures, even in SS7 networks).  But I'll
try to respond to this in the proper thread.  I still hold that SGs can use
SI, SSN and CIC-range routing to provide some interesting solutions.   The
idea that the SG can't or shouldn't look at information in the upper layers
is still incomprehensible to me.

But enough whining from me - FWIW I'm off this morning for a short vacation
(with no computer).  I'll be back again Tuesday morning.

Cheers,

    Greg

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Thursday, August 09, 2001 11:55 PM
Subject: Re: M3UAv8: point code representation

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 02:18:47 -0500

Greg,

Greg Sidebottom wrote:                                       (Fri, 10 Aug 2001 02:45:50)
> network on the IP-side, although I note in other threads you say otherwise.

I was talking about the multiple SG as STP case.  M3UA is particularly
poorly suited to this configuration as we have discussed at length
before.  Just chucking DRST into the mix was not enough.

> totally to MTP3 routes/linksets, then I strenuously disagree.

Again, we are talking about the multiple SG as STP case on this thread.
Are you saying that an SG as STP can handle user flow control for an MTP
user on a virtual point code behind the STPs when it doesn't know the
user status on its mate?  Are you saying that the SG (as STP) can C-link
route user traffic independent of the signalling point status?  Where
is your disagreement?

> I also don't
> dog.  I'd rather find some other solution or do without UPU.

So, what's your proposal for a solution?

> (I will admit
> SI, SSN and CIC-range routing to provide some interesting solutions.

For the non-multiple SG as STP case, I completely agree (well... except for
SSN <-- get rid of it! ;)  Where multiple SGs are not viewed as STPs by the
SS7 network or there are single SGs, all the interesting routing and backhaul
cases are still quite valid.

> The

You must have real problems with the OSI model then... ;)

> (with no computer).  I'll be back again Tuesday morning.

I'll try to fill your mailbox before you return :)

--brian

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Fri, 10 Aug 2001 12:02:51 +0200

Brian,

Thanks for your answer and detailed explanations.
I would appreciate if you could clarify the following points for me.

1. I acknowledge the lack of equivalent to UPT in M3UA but
why does that imply that an ASP can only host one UP per PC?
There is no UPT in MTP3 either so I thought the UPs were
responsible for monitoring the UP status (for example there
is a UPT message in ISUP). So when an ASP receives a DUPU for
an unavailable UP, that UP would send the necessary "polling"
messages as long as it receives DUPU->MTP_STATUS back.
Is this view also promoted in M3UA?

2. Is the signal routeset restriction the mapping of a TFR to
the user part?

3. In an another thread you said that SEP can have STP function.
Could you clarify what you mean by that: do you imply that the
message transfer is possible at level 3 but that the SNM features
are not implemented (sending TFx, responding to test messages,
behavior in MTP restart, others..)?

4. Is it your intention to describe how the STP feature should
behave in the M3UA draft? Same question for Alias PC.

5. I have the feeling that restricting the number of User Parts
to 1 in an SG/STP scenario is a serious limitation. As you point
out, GTT is probably the only use case for alias PC in SS7 today.
However, is it your view that SG/STP always implies an alias PC?
We can imagine a SG which transfers messages to AS in a non backhaul
fashion (IPSP-like) with multiple UP. Does M3UA support this view?

Thanks,
Francois Mouillaud

> Sent: Friday, August 10, 2001 5:56 AM
> To: sigtran
> behaviour we

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 11:03:41 -0500

Francois,

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Fri, 10 Aug 2001 12:02:51)
> Is this view also promoted in M3UA?

We could check with Al on this, but I believe UPT/UPA were part of
the ANSI-91 spec.  Let us not forget that there are parts of the
world and pockets within networks not running the most current
versions of these variants.  That is why backwards compatibility is
usually enforced for updates to SS7 specs.

> 2. Is the signal routeset restriction the mapping of a TFR to

As it stands in MTP, where the optional transfer-retricted
procedures are applied, TFR refers to a route, not a routeset.  It
is for all user parts on the applicable route.

> behavior in MTP restart, others..)?

Q.704/T1.111.4 clearly label which elements on the SDLs are
necessary only when a signalling point has the "transfer function".
The term SEP is no a term from the standards, although is it used
within this working group.  The standards talk of all signalling
points being SPs.   An SP is a general term.  It can have a user
function (which the drafts call SEP) and can have the transfer
function (which some want to call STP).  An SP can have both a user
function and the transfer function, in which case neither the label
SEP, not the label STP, really applies.  It is both as shown
diagramatically in Q.701/T1.111.1.

> behave in the M3UA draft? Same question for Alias PC.

It is not my intention to describe how the STP features, nor Alias
PCs should behave in the M3UA draft. (Principally because there are
cases where it doesn't work and doesn't make sense.) I do, however,
believe that the draft should address these points, as leaving them
largely unspecified leads to poor interoperability.

> fashion (IPSP-like) with multiple UP. Does M3UA support this view?

Yes, M3UA supports this view, but your going to have to go mucking
with your STP MTP code, go around the full stack conformance loop
again (on and STP yet) 'cause you mucked with the code and slipped
M3UA between MTP and the MTP-User.  Good luck passing the Q.782
tests.

Otherwise, you can use M2PA, only add a new signalling link type to
your STP and do Q.781/Q.782 testing only (not the rest of the
stack.)  Pretty much guaranteed to work (once M2PA fixes acks).

You pick.

--brian

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Fri, 10 Aug 2001 09:54:19 -0700

Francios,

Comments below.

> Sent: Friday, August 10, 2001 11:04 AM
> To: sigtran
Francois, your right, there was never a UPT/UPA.  ANSI followed the ITUs
direction in making the resolution of status the responsibility of the
remote affected MTP-user.
You are also right that this is not an excuse to say that PC is restricted
to one UP.
I am not sure that M3UA understands the user flow control procedures.
> is for all user parts on the applicable route.
Francois, normally the scenario for the TFR is when an STP's only route to a
specific SP is its C-links.  If this situation occurs, the STP would sent
TFR to the adjacent nodes trying to reach the affected SP.  The message
informs the adjacent nodes that if they have an alternative available route
to the affected SP, they should use it.  I don't think M3UA has the C-link
concept, directly (STP vendors making SGs will know what to do).  An SG
should only send a TFR to its adjacent nodes, if all of the SG's routes to
the affected SP are restricted.
> diagramatically in Q.701/T1.111.1.
Francois, if a node supports the STP functions, this include both the
transfer and network management functions.
SEP is used in the SS7 standards, we us it all the time at our standards
meetings.  You can find an example of its usage in T1.111.5, Annex C,
Routing Methods.
> largely unspecified leads to poor interoperability.
Francois, this is the main reason I go back to the SS7 standards to see how
it should work.
> M3UA between MTP and the MTP-User.  Good luck passing the Q.782
Francois, M3UA does support an AS (I prefer node) with multiple user parts.
The SI in the SS7 is there for M3UA to distribute the traffic to the
appropriate UP.
I think the Alias PC concept can be supported in the SGs, the STP vendors
making SGs will know how to do it.
I do not see why a good SG/AS implementation of M3UA could not pass
equivalent tests to the following test sets in Q.782:  Test set 1 (Link
Management), Test set 2 (Message Handling), Test set 8 (Traffic Flow
Control), and Test set 9 (Route Management).

> > > > 3. If we look at the AS as a virtual point code of the 
> SG, then two
> > > >    cases:
> > > >

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Mon, 13 Aug 2001 13:49:09 +0200

Hello,

Brian, John, thanks for your valuable feedback.
Do we have an agreement that User Part test procedures are UP's
responsibility, not MTP's or is there truly a UPT/UPA in ANSI
MTP specs?

If so, does this mean we agree on the possibility for an AS to
manage several UP within a PC when the SG acts as an STP?
In that case, the SG would behave as an IPSP ("peer-to-peer")
for the concerned point codes and would be subject to IPSP-like
network management features.

With respect to Virtual Point Codes, I am wondering if there is 
a real justification for a feature like this because the rationale
for doing this in the MTP world is not so strong in SIGTRAN.
Nevertheless, in short, what a VPC means to me is that it's the
visible side of the configuration to the SS7 world (hence all
messages to/from it only expose the VPC), while internally, the
VPC can correspond to several nodes (SS7 point codes) on different
physical machines for redundancy or security reasons. Maybe we could
limit the description of VPC to something like this so that everybody
shares the same view. How the VPC is used, managed, and so on would
be considered implementation dependant as long as M3UA rules are
followed.

This means that VPC and SG/STP are to be treated as completely separate 
issues (opposing the initial message on this thread).

Brian, with a clear separation like this, do you still think that Q.782
would be greatly impacted? In my view, the only serious interaction with
the MTP model in that scenario would be to route messages to an IP
interface instead of MTP2 interface where the adjacent point code is in
the IP world. But I guess this has to be done anyway, right?

Francois.

> From: Schantz, John [mailto:[email-masked]]
> Sent: Friday, August 10, 2001 6:54 PM
> To: sigtran
> > > > > > > > > > > > > > message whose DPC is NOT the SG PC 
> but any of 
> > > > > > those DPCs
> > > > > > > > > > > > > > EITHER the 'SS7 domain' via MTPL2 
> OR the 'IP 
> > > > > > domain' via
> > > > > > via the alternate STP.  This requires routing 
> changes in the 
> > > > > > MTP if the
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 13 Aug 2001 12:50:32 -0500

Francois,

Please see comment below...

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Mon, 13 Aug 2001 13:49:09)
> the IP world. But I guess this has to be done anyway, right?

In directing (as Maria-Cruz first put) to an IP interface instead
of an MTP2 interface, I think you need M2PA here not M3UA.  M3UA
lacks the MTP functions necessary to make this work.  MTP3 using
M2PA could (if M2PA ack problem ever gets fixed ;).

I do not agree that there is such a thing as the IPSP case for M3UA.
It is completely under-specified in the draft and it has not even been
thought out.

--brian

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Tue, 14 Aug 2001 09:50:28 +0200

Brian,

Thanks for your feedback on this issue. I think we need to get to
the bottom of it because, as we go deeper, the views on this seem
to be drifting apart as you state you do not support the "IP redirect"
view of the SG/STP feature.

What I'm trying to get at here is to clarify the behavior expected
at an STP connected to different SS7 networks.
The following is a quote form M3UA v8.

*** START QUOTE ***
"An SG may be logically partitioned to operate in multiple SS7 network 
appearances.  In such a case, the SG could be addressable with a Point 
Code in each network appearance, and represents a set of nodes in the 
IP domain into each SS7 network.  Alias Point Codes [15] may also be 
used within an SG network appearance. 

Where an SG contains more than one SGP, the MTP3 routeset, SPMC and 
remote AS/ASP states of each SGP SHOULD be coordinated across all the 
SGPs.  Re-routing of traffic between the SGPs SHOULD also be supported.

If an ASP or group of ASPs is available to the SS7 network via more 
than one SG, each with its own Point Code, the ASP(s) will typically be 
represented by a Point Code that is separate from any SG Point Code.  
This allows, for example, these SGs to be viewed from the SS7 network as 
"STPs", each having an ongoing "route" to the same ASP(s).  
Under failure conditions 
where the ASP(s) become(s) unavailable from one of the SGs, this 
approach enables MTP3 route management messaging between the SG and SS7 
network, allowing simple SS7 re-routing through an alternate SG without 
changing the Destination Point Code Address of SS7 traffic to the 
ASP(s)."
*** END QUOTE ***

To me this clearly calls for an STP or VPC role at the SG.
I take it that, based on your answer, you would like NO changes to be made
to the MTP3 layer at a SG. Is that so? The quote above does not mention M2PA
at all but rather sets the debate at level 3. I think it would be a very
serious limitation to state that you need a M2PA association to realize the
STP function at an SG.

With respect to IPSP, this is how the IP side of an SG/STP would behave
if the SG had its own PC. Nothing more.

Francois.

> Sent: Monday, August 13, 2001 7:51 PM
> To: sigtran

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 14 Aug 2001 07:42:10 -0700

Francois,

comments below.

> From: MOUILLAUD,FRANCOIS (Non-HP-France,ex2)
> [mailto:[email-masked]]
> Sent: Monday, August 13, 2001 6:49 AM
> To: sigtran
[John]  There is nothing to agree to.  User part testing is the
responsibility of the user part.  This is how it is done in ANSI and ITU
(and every protocol based on ITU).  There never have been nor will there be
UPT/UPA messages in ANSI.

> network management features.
[John]  I agree with your first sentence.  This is how it is today in the
SS7 networks.
I don't agree with the SG and AS dropping into the IPSP mode.  I have talked
with several other companies and they did not get this interpretation from
the spec.
 
> be considered implementation dependant as long as M3UA rules are
[John]  I would rather leave the VPC discussion alone.

> > > > > > > > detail and should be cleared in the spec 
> further. What I 
> > > > > > > was referring
> > > > > > > > So the question is: how can MTP forward the 
> MSUs received 
> > > > > > > for PC Y to NIF?
> > > > > > > 
> > > > > > > Two possibilities:
> > > > > > > 
> > > > > > > > requirement for MTP3 and I don't feel the need 
> for such a 
> > > > > > > requirement
> > > > > > > > in M3uA spec. 
> > > > > > > 
> > > > > > > Indeed, both possbilities place a requirement on 
> MTP3 (that 
> > > > > > > is the MTP3
> > > > > > > requiring an MTP-STATUS request to the MTP.  
> Also, the MTP 
> > > > > > > must be aware
> > > > > > > does not mean that the routeset is prohibited: it 
> may still 
> > > > > > > be available
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 14 Aug 2001 11:48:37 -0500

Francois,

I provided a rather detailed diagram of how this can be accomplished
in the Backhaul case.  It requires that the routing key be on a whole
point code basis, that DRST be provided and that DUPU be accepted by
the SG.  This blurs the MTP/MTP-User line.

For the IPSP approach, there is no such thing as "multiple SGs" in the
IP domain, and there need be no "STP" function in the IP domain.

So, you are faced with doing it in a rather blurry way using backhaul,
doing it in a really blurry way using IPSP, or using M2PA in its
proscribed fashion.

The nice thing about standards is there are so many to choose from.
You pick!

--brian

[snip]

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Tue, 14 Aug 2001 10:46:10 -0700

You are contradicting yourself.  You draw a figure about a week ago where
you had the IPSP running at an SG and an SEP.

> Sent: Tuesday, August 14, 2001 11:49 AM
> To: sigtran

---

---

From: "Gradischnig, Klaus" <[email-masked]>
Date: Thu, 16 Aug 2001 08:52:09 -0500

Greg,

I agree w/ you - at least regarding UPU. I'd rather buy/build a reliable
system.

Klaus

> From: Greg Sidebottom [mailto:[email-masked]]
> Sent: August 10, 2001 2:46 AM
> To: sigtran
> [email-masked]

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Mon, 20 Aug 2001 10:37:15 +0200

Brian,

What I'm getting at in this thread is to clarify the SG
description when it has its own Point Code as an STP does.
In this scenario, messages could be transferred at level 3
within the SS7 domain (regular STP) as well as between the
IP and SS7 domains, and in the IP domain too (why restrict
it? You will have to do that as the MTP interfaces gradually
disappear). This requires the MTP3 transfer function
to be slightly altered.

To narrow down the issues of discussion here are the points
that might be included:

1. STP functions (message transfer + SSNM) are supported in
   the M3UA vision.
2. Multiple User Parts per PC (on AS) are supported when the
   SG has this STP feature.
3. Describe what is a virtual point code. The term is mentioned
   in the draft but what it really means is not described.

Francois.

> Sent: Tuesday, August 14, 2001 6:49 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 08:19:50 -0500

Francois,

I don't agree.  IMHO there is no need for this function
in the IP domain.  Placing transfer functions into the
IP domain recreates the SS7 network within the IP domain:
a rather pointless exercise, not covered in the SIGTRAN
architecture.

==brian

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Mon, 20 Aug 2001 10:37:15)

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Mon, 20 Aug 2001 15:50:37 +0200

Brian,

We're talking about the SG here, with SS7 and IP interfaces.
I agree that SS7 transfer functions would be pointless in a
pure IP world, but I'm more in a gradual migration case from
SS7 to IP. Then the SG will be linked to multiple SS7 networks
and may have its own PC. For global consistency, IPSP would
keep their PC for a while. Anyway I was more addressing the
general issue of message transfer at level 3 within an SG, of
which the pure IP transfer is a minor special case.

In this scenario, the SG would act as an IPSP to the IP domain
when the transfer function is exercised and as ASP interface
otherwise.

Again, these concepts (STP, VPC) are already described in the draft
but what is behind the concepts is not spelled out which might lead
to misunderstandings, or already does as it seems P-(

Francois.

> Sent: Monday, August 20, 2001 3:20 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 09:47:32 -0500

Francois,

I agree that draft is unclear regarding these issues.
Particularly multiple SG as STP.  I can conceive of
a single SG acting also as an IPSP into the IP domain.
But I cannot conceive of multiple SG acting as STP
also attempting to represent a single IPSP into the
IP domain.  What is the purpose of such an arrangement?
I believe a single SG would do in this case, viewed
as having the transfer function to the SS7 network, and
viewed as a single IPSP to the IP domain.  Why two?

--brian

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Mon, 20 Aug 2001 15:50:37)

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

---

---

From: "Schantz, John" <[email-masked]>
Date: Mon, 20 Aug 2001 08:00:28 -0700

I agree with you Francois.  It is also something that SG vendors will need
to decide on.  I don't think the pure IP world for SS7 is just around the
corner.  It will take a very long time in getting here.  Also, IP networks
serving SS7 may rediscover the "Star Network" and may want to deploy IP-STPs
since PCs will be with us for a long time and star networks are more
efficient.

Actually, I think that SGs that are providing non-backhaul access for groups
of IP signalling points must function as STPs.  They are now part of the
SS7's backbone network and must participate in message routing, GTT, and
network management.  All the elements for the SGs to be STPs are already in
the spec.  Also, since the SGs must have MTP3 when connecting to the SS7
network, a sharp SG (or STP) vendor could find a way to merge MTP3 and M3UA
so that they share the common network management functions.  

John

> Sent: Monday, August 20, 2001 8:51 AM
> To: sigtran

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Mon, 20 Aug 2001 18:23:56 +0200

Brian,

In M3UA V8 section 1.5.3 there is a schema of an SGP
performing GTT for messages from both the IP and SS7
domains, hence performing transfer for potentially
several SS7 nodes and several IPSPs.

A possible application could be a node with a 
centralized GTT function, that terminates
SS7 links to multiple switches in order to backhaul 
TCAP processing for a specific service (say INAP),
while acting as IPSP to emulate SS7 presence for 
nodes that may not have an SS7 interface (say a SGSN
for example).

By providing the message's DPC, the GTT would indicate
if the processing is backhaul (DPC=SG) or not. If not,
(DPC^=SG) the SG could be linked to several remote IPSP
or go back to SS7.

Would you call this one SG and what is your opinion 
about this?

Francois.

> Sent: Monday, August 20, 2001 4:48 PM
> To: sigtran

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 20 Aug 2001 11:45:42 -0500

Francois,

You should know better than to ask for my option ;)

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Mon, 20 Aug 2001 18:23:56)
> several SS7 nodes and several IPSPs.

The example is not an IPSP example.  I see it as an
SGP/ASP example (IPSP is never mentioned).

Also it clearly states that the example requires an
unspecified NIF.

> (DPC^=SG) the SG could be linked to several remote IPSP

I think you need SUA.
> Would you call this one SG and what is your opinion 

Your description not only mucks with SS7 MTP functions,
but mucks with SS7 SCCP functions.  You would be better
to use SUA in this case.  SUA provides the AMF that you
are looking for with smooth and transparent interworking
with the SCCP GTT function.

It is a bad example.  SUA is far more suited to this
configuration than is M3UA.

--brian

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

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Tue, 21 Aug 2001 16:37:16 +0200

Brian,

Thanks for your valuable comments.
I may have pushed the NIF description a little far to
illustrate the fact that it could be valid to have message
transfer in the SS7 AND IP domains in an SG. Moreover, 
SCCP is not the only User Part liable to be backhauled.
For example if you need to backhaul TUP or ISUP as well,
SUA won't do (even if message transfer is only for SCCP).

Anyway, this discussion is drifting. Initially it started
by a remark stating that MTP3 required changes to be able
to transfer messages to both MTP2 and M3UA if the SG had
transfer functions. There seems to be a convergence to a
solution where such messages that would be routed to the
IP domain would be handled by an implementation-specific NIF.
This could be added as a short description to the draft (#1).

Another addition could be:
Multiple User Parts per PC (on AS) are supported when the
SG has this STP feature. User Part availability is handled 
by their peers like in MTP and is not provided by M3UA (#2).

The SSNM and STP features are already described especially in
1.4.1 and 1.5.3. However, my point when I mention IPSP in the
STP scenario was that MTP3 is terminated at the SG for SS7
perspective, and the AS-SG relation is more of point-to-point
nature than backhaul. Still, I agree that this is misleading
because there is no User Part peer on the SG. The text in the
draft is probably enough as long as everyone realizes what it
takes to have the STP feature in the SG.

Francois.

> Sent: Monday, August 20, 2001 6:46 PM
> To: sigtran

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Wed, 22 Aug 2001 09:55:37 +0200

Brian,
I believe we can close on these issues with the slight
improvement identified below.
Francois.

> Sent: Tuesday, August 21, 2001 9:32 PM
> To: sigtran
> MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Tue, 21 Aug 
> 2001 16:37:16)
> > Brian,
> > 
> I agree with the statement, but it already apprears in the
> draft with respect to the NIF: that the NIF is implementation
> dependent and that its specification is out of scope.  Is that
> not sufficient?
> 
> > 
> I agree, this should be mentioned in the draft and the role
> of DUPU in the direction from AS to SG identified.
> 
> > 

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Wed, 22 Aug 2001 12:03:20 +0200

Brian,

Thanks for sharing this very interesting view.

Is the usage (SSN=-1 CLDT interpreted as M3UA DATA) considered 
a standard part of SUA? I could not find it in the draft.
In that case would we consider that all non-SCCP User Parts
are mutualized by this SSN? I don't think there is a DUPU in SUA.

Also CICs ae not mentioned in the SUA Routing Keys and it appears
that the Registration messages are not in SUA, which would be
cumbersome for ISUP.

Having both M3UA and SUA would be a good solution, although that
kind of defeats the "one size fits all" purpose of M3UA...

I hope the RC/NA issue will come to an end (personnally I liked
your very aptly presented G option!) that will enable ISUP to
work over M3UA!

Francois.

> Sent: Wednesday, August 22, 2001 5:09 AM
> To: sigtran
> Hi Francois,
> > ... Moreover, SCCP is not the only User Part liable to be 
> backhauled.
> SUA won't do
> > (even if message transfer is only for SCCP).
> 
> SUA is still the clear choice where backhaul of both ISUP and SCCP
> is concerned where the SG acts as an SCCP relay.  Use M3UA for ISUP
> and SUA for SCCP.  The only reason to use M3UA for ISUP is because
> there is no ISUA.  If the current NA/RC discussions in M3UA don't
> resolve to the concensus AS model of RC in DATA and SNMM, M3UA will
> be useless for ISUP anyway.  In that case it would be easier to
> carry ISUP using SUA (SSN=-1 CLDT interpreted as M3UA DATA) than
> using M3UA.  Nevertheless, if M3UA issues get worked out, the model
> which would work is as follows:
> 
>         ________                                       ________ 
>        |    |   |                                     |   |    |
>        | T  |   |                                     |   |  T |
>        | C  |   |                                     | I |  C |
>        | A  |   |                                     | S |  A |
>        | P  | I |                                     | U |  P |
>        |____| S |                                     | P |____|
>        |    | U |                                     |   |    |
>        | S  | P |        ________ _____________       |   |    |
>        | C  |   |       |        |             |      |___|    |
>        | C  |   |       |  SCCP  |     SUA     |      |   |  S |
>        | P  |   |       |        |             |      | M |  U |
>        |____|___|       |________|______       |      | 3 |  A |
>        |        |       |        |      |      |      | U |    |
>        |  MTP3  |       |  MTP3  | M3UA |      |      | A |    |
>        |________|       |________|______|______|      |___|____|
>        |        |       |        |             |      |        |
>        |  MTP2  |       |  MTP2  |     SCTP    |      |  SCTP  |
>        |________|       |________|_____________|      |________|
>             |                |           |                 |    
>             |________________|           |_________________|    
> 
> 
> Because it is provided to multiplex SUA and M3UA over the same SCTP
> associations by PPI, it is possible to use common SCTP associations.
> Here full SCCP transparency including final or non-final GTT or just
> MTP-transfer at the SG/STP is provided.  SUA smoothly handles all
> issues associated with multiple SGs, handling of 
> segementation/reassembly,
> SIF max size interworking, and all the things you need for SCCP,
> while M3UA just delivers ISUP.  There are none of the issues of
> downwards MTP-User primitives or IPSP operation at the SG for M3UA:
> M3UA is the pure backhaul case for ISUP.  If the objective is TCAP
> and the connection-oriented procedures are not required, SUA is a
> rather trivial extension and shares all of the same ASP management
> procedures with M3UA (load 'em once and link 'em to both).
> 
> SUA is still far more advisable that trying to push M3UA into
> handling the SCCP relay node.  SUA has special provisions (see
> thread SUA Relay Problems and the resulting changes to SUA) to
> permit multiple SG as either SCCP Relay Nodes or MTP transfers or
> both.
> 
> The M3UA example is still a bad example.  SUA is far better suited
> to providing SCCP Relay Node SGs.
> 
> But this has already been discussed in the thread SSN and TID in M3UA.
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> ---

---

---

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

Francois,

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Wed, 22 Aug 2001 12:03:20)
> a standard part of SUA?

It is by no means standard and is not part of the draft.

> I could not find it in the draft.

I would be suprised if you did.

> are mutualized by this SSN? I don't think there is a DUPU in SUA.

Just use DUNA with SSN -1 and a GT with TT -1 and SI in the
digits. :)  (Just stroke out machine gun and write in pizza oven.)

> that the Registration messages are not in SUA, which would be

I guess we might need an ISUA if M3UA does not come to fully
address the needs of ISUP users.

> kind of defeats the "one size fits all" purpose of M3UA...

The SUA spec is full of functionality that M3UA cannot provide.

The problem here is that the example is attempting to make the
SG both an MTP STP and an SCCP Relay node.  It is more related
to the difficulties of multiple SG/STPs in both M3UA and SUA
than a decision between the UAs.  In all other cases it is clear
that the M3UA is quite capable of transporting SCCP alongside
ISUP as an MTP-User.

> your very aptly presented G option!) that will enable ISUP to

I invite you to state your support for an approach on the
"RC in SNMM and DATA" thread.  Just remember to duck afterwards.

--brian

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

---