Subject: IPSP proposed text (1st approach)

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 25 Oct 2001 20:25:17 +0200

Hi folks, 

Here is the first approach of the IPSP text I promised (attached text file).

- The first section explains how the routing is solved in the IPSP scenarios.

- The second one deals with the slight difference in the state flow diagram for the ASPs (IPSPs)

- After that, a particularization for the main procedures explained in both drafts are extended in a short way to this particular scenario.

- Finally how IPSPs communication (also ASP-ASP communication) work is shown in parallel to the AS-SG examples. We'll probably discuss if it's better to have a separate section for the IPSP examples. My personal opinion is against since it will lead to explain things twice.

Before the text, some initial considerations:

There exist two kinds of nodes:
- SG: Frontier node between SS7 and IP
- AS: IP node with an SS7 application

There exist two kinds of communications:
- SS7-IP also called SG-AS
- IP-IP, also called AS-AS or IPSP communication

Throughout the text it is used IPS and AS as the same thing. In the same way ASP and IPSP refers the same node (or process...). It's something pending to be fixed to unify the text.

I propose to unify all the text to only use AS and ASP nomenclature for the IPSP cases instead of having IPS and IPSP as well.

Cheers // Javier.

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

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Mon, 29 Oct 2001 09:38:19 +0100

Hello Javier,

I like the general approach of your proposal. Putting ASP/SGP in
parallel to IPSP/IPSP makes it very easy to read, and allows to
minimize the changes required. Please find more detailed comments
below.

Francois.

1. General comment
To fulfill the parallelism, I think an IPSP should be configured as client
(behaves like as ASP) or server (behaves like an SGP). Only the client
IPSP would send AS UP and ASPAC, ASPIA messages except in failure/recovery
cases. This would nicely achieve the compatibility and reduce design effort.

2. "If a full-duplex path has been established for an IPSP communication, 
two ASP Inactive messages (one from each end) would be needed to 
close it in both directions."

            IPSP-A                           IPSP-B
              |                                |
              |<-------------ASP Up------------|
              |-----------ASP Up Ack---------->|
              |                                | 
              |<------- ASP Active(RCb)--------|  RC: Routing Context 
              |-----ASP Active Ack (RCb)------>|      (optional)
              |                                |
              |------- ASP Active(RCa)-------->|  RC: Routing Context 
              |<-----ASP Active Ack (RCa)------|      (optional)
              |                                |

[FM] Does this mean you consider messages exchanged in one direction only
mean the signalling traffic is one way? This does not seem consistent nor
in line with the ASP/SGP case. 

3.
     IPSP-A                     IPSP-B1                   IPSP-B2
        |                         |                          |
        |<--------ASP Up----------|                          | 
        |-------ASP Up Ack------->|                          |
        |                         |                          |
        |<-----------------------------ASP Up----------------|
        |-----------------------------ASP Up Ack------------>|
        |                         |                          | 
        |                         |                          |
        |<-------ASP Active-------|                          | 
        |------ASP Active Ack---->|                          | 
        |                         |                          |
        |--------ASP Active------>|                          | 
        |<-----ASP Active Ack-----|                          | 
        |                         |                          |
        |------------------------------ASP Active----------->|
        |<----------------------------ASP Active Ack---------|
        |                         |                          |

[FM] To me this type of scenario should not happen because ASPAC should
only be sent by the client, except in failure/recovery cases.

4.
                    IPSP-A                     IPSP-B
                       |                         |
                       |--------ASP Inactive---->|--MTP-PAUSE ind.---->
                       |                         |

                     IPSP-A                     IPSP-B
                       |                         |
                       |--------ASP Active------>|--MTP-RESUME ind.-->
                       |                         |

                     IPSP-A                     IPSP-B
                       |                         |
                       |----------DUPU --------->|--MTP-STATUS ind.-->
                       |                         |

"There are no examples of DUNA, DAVA, etc, since each IPSP is considered to
be an endpoint. Therefore, it doesn't have to inform about the states of the
other nodes."

[FM] I agree with the first two scenarios but I don't see the point of the
third one.
A DUPU means UP unavailable, so if this UP corresponds to an AS, an ASPIA
should be sent.

> -----Original Message-----
> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Thursday, October 25, 2001 8:25 PM
> To: sigtran
> Subject: IPSP proposed text (1st approach)
> 
> 
> Hi folks, 
> 
> - After that, a particularization for the main procedures 
> explained in both drafts are extended in a short way to this 
> particular scenario.
> 
> - Finally how IPSPs communication (also ASP-ASP 
> communication) work is shown in parallel to the AS-SG 
> examples. We'll probably discuss if it's better to have a 
> separate section for the IPSP examples. My personal opinion 
> is against since it will lead to explain things twice.
> 
> 
> 
> Throughout the text it is used IPS and AS as the same thing. 
> In the same way ASP and IPSP refers the same node (or 
> process...). It's something pending to be fixed to unify the text.
> 
> I propose to unify all the text to only use AS and ASP 
> nomenclature for the IPSP cases instead of having IPS and 
> IPSP as well.
> 
> 
> 
> Cheers // Javier.
> 
> 

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Mon, 29 Oct 2001 02:29:07 -0800 (PST)

Hi Francois, 

Thanks for your comments. See my answers inline  :-D 

Cheers // Javier.

-----Original Message-----
From: MOUILLAUD,FRANCOIS (Non-HP-France,ex2)
To: sigtran
Sent: 10/29/01 9:38 AM
Subject: RE: IPSP proposed text (1st approach)

Hello Javier,

I like the general approach of your proposal. Putting
ASP/SGP in
parallel to IPSP/IPSP makes it very easy to read, and
allows to
minimize the changes required. Please find more
detailed comments
below.

Francois.

1. General comment
To fulfill the parallelism, I think an IPSP should be
configured as
client
(behaves like as ASP) or server (behaves like an SGP).
Only the client
IPSP would send AS UP and ASPAC, ASPIA messages except
in
failure/recovery
cases. This would nicely achieve the compatibility and
reduce design
effort.

[Javier:] There is no need of such configuration. IPSP
communication should be peer to peer from the
beginning. At least we should not restrict it. You can
work with the client-server philosophy, but the
general procedure of the text serves for peer to peer
too.

The reason of having double ASPAC was discussed in
this mailing list in the early September. The
conclussion was basically that as two MTP3 users are
talking to each other, they would need to specify the
RK they are working for. And in that case, if dynamic
registration is used, they have to interchange two
ASPACs in the two directions.

You can see it as: SG does not need to send ASPAC
since it has no RK to register for. But, on the other
hand, ASPs will need to send an ASPAC to get itself
registered for a specific RK. If two ASPs want to
establish a communication between them, they both
should send its own ASPAC, to inform the other peer
what RK they are working for.

The same occurs with ASPIA.

[/Javier]

2. "If a full-duplex path has been established for an
IPSP
communication, 
two ASP Inactive messages (one from each end) would be
needed to 
close it in both directions."

            IPSP-A                           IPSP-B
              |                                |
              |<-------------ASP Up------------|
              |-----------ASP Up Ack---------->|
              |                                | 
              |<------- ASP Active(RCb)--------|  RC:
Routing Context 
              |-----ASP Active Ack (RCb)------>|     
(optional)
              |                                |
              |------- ASP Active(RCa)-------->|  RC:
Routing Context 
              |<-----ASP Active Ack (RCa)------|     
(optional)
              |                                |

[FM] Does this mean you consider messages exchanged in
one direction
only
mean the signalling traffic is one way? This does not
seem consistent
nor
in line with the ASP/SGP case. 

[Javier:]
What it means is that you should send two ASPIAs in
the same way you sent two ASPACs. We don't restrict
nothing again about the possible half-duplex path.
Some configurations can use it if they want. If not,
you just have to wait to the double exchange to happen
and avoid data transfer in the meantime.
[/Javier]

3.
     IPSP-A                     IPSP-B1               
   IPSP-B2
        |                         |                   
      |
        |<--------ASP Up----------|                   
      | 
        |-------ASP Up Ack------->|                   
      |
        |                         |                   
      |
        |<-----------------------------ASP
Up----------------|
        |-----------------------------ASP Up
Ack------------>|
        |                         |                   
      | 
        |                         |                   
      |
        |<-------ASP Active-------|                   
      | 
        |------ASP Active Ack---->|                   
      | 
        |                         |                   
      |
        |--------ASP Active------>|                   
      | 
        |<-----ASP Active Ack-----|                   
      | 
        |                         |                   
      |
        |------------------------------ASP
Active----------->|
        |<----------------------------ASP Active
Ack---------|
        |                         |                   
      |

[FM] To me this type of scenario should not happen
because ASPAC should
only be sent by the client, except in failure/recovery
cases.

[Javier:] See answer to question 1
[/Javier]

4.
                    IPSP-A                     IPSP-B
                       |                         |
                       |--------ASP
Inactive---->|--MTP-PAUSE ind.---->
                       |                         |

                     IPSP-A                     IPSP-B
                       |                         |
                       |--------ASP
Active------>|--MTP-RESUME ind.-->
                       |                         |

                     IPSP-A                     IPSP-B
                       |                         |
                       |----------DUPU
--------->|--MTP-STATUS ind.-->
                       |                         |

"There are no examples of DUNA, DAVA, etc, since each
IPSP is considered
to
be an endpoint. Therefore, it doesn't have to inform
about the states of
the
other nodes."

[FM] I agree with the first two scenarios but I don't
see the point of
the
third one.
A DUPU means UP unavailable, so if this UP corresponds
to an AS, an
ASPIA
should be sent.

[Javier:] DUPU means a temporal failure of the User
Part in any of the two ASPs. ASPIA should be used when
the communication is closed by decission of the user
part.
[/Javier]

> Here is the first approach of the IPSP text I
promised 
> (attached text file).
> 
> - The first section explains how the routing is
solved in the 
> IPSP scenarios.
> 
> - The second one deals with the slight difference in
the 
> state flow diagram for the ASPs (IPSPs)
> 

---
You are currently subscribed to sigtran as:
[email-masked]

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Oct 2001 04:35:16 -0600

Francois, Javier,

I also don't see the point in permitting half-duplex connections
(or dealing with half-open and half-closed paths) when the
signalling being transported is always full-duplex.  There is no
reason why both sides from using the same RC value for the
full-duplex connection rather than each having their own
RC-value.  It just causes more pain at both sides.  A single
coordinated RC value on both ends representing the full duplex
connection would avoid half-open/half-closed scenarios.  Only a
single ASPAC/Ack or ASPIA/Ack exchange would then be required to
open or close a full-duplex path fully.

--brian

MOUILLAUD,FRANCOIS (Non-HP-France,ex2) wrote:  (Mon, 29 Oct 2001 09:38:19)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Mon, 29 Oct 2001 02:50:12 -0800 (PST)

Hi Brian,

The reason behind we went to double ASPAC was the no
need of having a common organism to assign RC to
different ASP. Take into account that if your ASP-A
communicates with ASP-B and you have a RC=3 to define
that communication, then none of the other ASP that
communicate with this two nodes can use RC=3. This
fact means much more management in a big network. It
seems not to be very convinient from my point of view.

Having communication half established, on the other
hand, is a common feature of connection oriented IP
protocols, e.g. TCP, SCTP. I don't see it as a major
concern.

Cheers // Javier.

-----Original Message-----
From: Brian F. G. Bidulock
To: sigtran
Sent: 10/29/01 11:35 AM
Subject: Re: IPSP proposed text (1st approach)

Francois, Javier,

I also don't see the point in permitting half-duplex
connections
(or dealing with half-open and half-closed paths) when
the
signalling being transported is always full-duplex. 
There is no
reason why both sides from using the same RC value for
the
full-duplex connection rather than each having their
own
RC-value.  It just causes more pain at both sides.  A
single
coordinated RC value on both ends representing the
full duplex
connection would avoid half-open/half-closed
scenarios.  Only a
single ASPAC/Ack or ASPIA/Ack exchange would then be
required to
open or close a full-duplex path fully.

--brian

---

---

From: [email-masked]
Date: Mon, 29 Oct 2001 13:18:51 +0200

Hi Brian,

> open or close a full-duplex path fully.

I believe that you have a point in wanting to avoid half-duplex
connections.  It would simplify things.  However, I do not like the
idea of a single co-ordinated RC-value.  The only way that I can
see this working is that the RC would need to be co-ordinated
with the SCTP association on which it came in on.  In that
way, the IPSP needs to tie the value of the RC with the SCTP
association in order to be able to uniquely identify the 
opposite end of the signaling connection.

If this is an acceptable way forward, then lets go with it.

John

---

---

From: [email-masked]
Date: Mon, 29 Oct 2001 13:24:47 +0200

Hi Francis,

> minimize the changes required. Please find more detailed comments

I agree.  
 
> configured as client (behaves like as ASP) or server (behaves 
> like an SGP). Only the client IPSP would send AS UP and ASPAC, 
> ASPIA messages except in failure/recovery cases. This would 
> nicely achieve the compatibility and reduce design effort.

This I think is too close to implementation.  I think that
a clever implementation would allow this kind of behavior.
However, in real-life, a client-server model may not be
the best.  Just consider inter-operator signaling.  Who is
the client & who is the server in such a case?

best regards,
John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Oct 2001 05:25:57 -0600

Javier,

Javier Pastor-Balbas wrote:                                (Mon, 29 Oct 2001 02:50:12)
> seems not to be very convinient from my point of view.

Just because ASP-A and ASP-B use RC=3 to refer to
some traffic between them does not mean that RC=3
cannot be used to refer to some different traffic
between ASP-A and ASP-C.

No common organism required.

You do not present a reason at all.

> protocols, e.g. TCP, SCTP. I don't see it as a major

But noticably missing from SS7.

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Oct 2001 05:30:33 -0600

John,

John Loughney wrote:                                         (Mon, 29 Oct 2001 13:18:51)
> opposite end of the signaling connection.

This is precisely what is done in the SG/AS case (co-ordinated
with the SCTP association (ie. SGP/ASP relation) upon which it
is sent).  RC has no meaning outside the association upon which
the ASPAC/Ack or REG REQ was exchanged.  The only coordination
necessary is between one IPSP and another IPSP.  There is just
one RC value to coordinate instead of two.  There are nothing
but advantages for the single-ended procedure and disadvantages
for the double-ended procedure.

> If this is an acceptable way forward, then lets go with it.

Double-ended is unacceptable.

--brian

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

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Mon, 29 Oct 2001 03:46:17 -0800 (PST)

Hi Brian, 

Then you mean having a RC for two RK? Because it is
that fact what happens if you reuse RC=3 when
communicating with ASP-A...

M3UA says that a RC uniquely identifies a RK.

Cheers //Javier. 

-----Original Message-----
From: Brian F. G. Bidulock
To: sigtran
Sent: 10/29/01 12:25 PM
Subject: Re: IPSP proposed text (1st approach)

Javier,

Javier Pastor-Balbas wrote:                           
    (Mon, 29 Oct
2001 02:50:12)

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

---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 29 Oct 2001 06:00:23 -0600

Javier,

Javier Pastor-Balbas wrote:                                (Mon, 29 Oct 2001 03:46:17)
> M3UA says that a RC uniquely identifies a RK.

RC would uniquely define an RK: at each end.

--brian

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

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Mon, 29 Oct 2001 04:09:46 -0800 (PST)

Brian, 

At ASP-A you have RK-b and RK-c defined by the same
RC=3. There is one RC defining more than one RK at one
end. 

Cheers // Javier.

-----------------
Brian wrote:

Javier,

2001 03:46:17)

--brian

-- 
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, 29 Oct 2001 06:44:27 -0600

Javier,

So what.  At an ASP I can have RC=3 defining RK-a to one SG
and RK-b to another SG.  RC "values" are not unique in this
respect even for the SG/AS case.

This ASP registers RK-a with SG-1 and gets RC=3, it registers
RK-b with SG-2 and gets RC=3.

At an SG, RC uniquely defines a RK, not at an ASP.

--brian

Javier Pastor-Balbas wrote:                                (Mon, 29 Oct 2001 04:09:46)

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

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Mon, 29 Oct 2001 13:58:52 -0800 (PST)

Brian, 

You have unicity in an SGP, right? Then you should also have unicity in
an ASP.

In an SGP is the SGP the one who is giving RC values to the different
RKs and it is therefore who assures the unicity. In the ASP-ASP case
has to be completely the same. The ASP is the one who decides what RC
is assigning.

With the double ASPAC we don't change the philosophy of the SG-AS
scenario. It's simply an extension. The only thing needed is a very
simple logic at the ASP to inform the MTP3 user over M3UA that the
connection has been completely established right after the ASPAC-ACK
has been sent (originating peer) or after the last ASPAC-ACK is
received (non-originating peer). As simple as that. 

And if you want, after that interchange of messages, you can assign
each RC to the Assoc Identifier inside your node, or manage it in the
way you prefer... Implementation dependant.

Cheers // Javier.

--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Oct 2001 00:15:00 -0600

Javier,

Javier Pastor-Balbas wrote:                                (Mon, 29 Oct 2001 13:58:52)
> You have unicity in an SGP, right? Then you should also have unicity in

What do you mean by "unicity"?

> RKs and it is therefore who assures the unicity.

I don't think the statement above is completely accurate.  RC values are
assigned on an SG basis not a SGP basis.  For a given RK at an SG, all
SGP are to use the same RC value.  We even recommended this in the
drafts.  So, an SG assigns an RC value to SG->ASP RK that uniquely
defines the RC, RK, and AS to which traffic belongs to the ASP.  An ASP
can rely on the RC value for a given RK and AS to be the same for each
SGP in an SG.  The SG need make no other assurances regarding the
"value" of the RC.

When dynamic configuration is used, it is clear that the SG assigns the
"value" to the RC (e.g. RC=3), but the SG makes absolutely no assurances
to any ASP that the value is different that the values assigned by other
SGs of the SG in question may or may not be aware.  Another SG can also
assign the same value of RC (e.g., RC=3) as well.

The draft gives you a clue here when it says (or used to say) that the
RC might be viewed as an index into the RK/AS table for an SG.

> In the ASP-ASP case has to be completely the same.

That is what I would like as well; however, the double-ended procedure
does not permit it to be the same.

In the SG/AS case, the ASP either knows the RC as an RK/AS identifier by
static configuration (which needs to match that assigned at the SG) or
by obtaining the RC value from the SG using the registration procedure.
Regardless of how the RC as an RK/AS identifier is obtained at the ASP,
the ASP already needs handle the fact that there are different RC values
assigned at different SGs referring to the same AS.

> The ASP is the one who decides what RC is assigning.

The ASP in the SG/AS case is used to obtaining this value from the peer
either by configuration or by registration: which makes your statement
above strange.  The ASP does not decide what RC values are assigned,
the SG does.

> scenario.

It is completely changed.  Suddenly, not only does that ASP have to
generate RKs and RC values to identify AS (the reverse of the SG/AS
case where the ASP need not maintain any RKs whatsoever) but now it
also has to remember that an RC/RK/AS value that it assigned for
another ASP is coupled to a RC/RK/AS value that the other end assigned
for the same connection.  This is two RC values per bidirectional
traffic flow, where in the SG/AS case, there is only one RC value per
bidirectional traffic flow.

It is this very radical change in philosophy over the SG/AS case to
which I object.

> It's simply an extension.

An extension is a change.  In this case, a bad change.

> The only thing needed is a very simple logic at the ASP to inform the
> MTP3 user over M3UA that the connection has been completely
> established right after the ASPAC-ACK has been sent (originating peer)
> or after the last ASPAC-ACK is received (non-originating peer). As
> simple as that. 

What is simply required is the simple single-ended procedure with
the existing simple single RC value.  Your proposal is the complication.

> way you prefer... Implementation dependant.

Under the single-ended approach, if an implementation wants to assign
multiple redundant internal identifiers to RKs and ASs that serve as
little purpose as yours, then it is already welcome to do so....
Implementation dependent.

You have not made any case whatsoever for a double-ended approach over
single ended.  The single ended approach matches the SG/AS approach
(which is also single-ended) and there is no reason to deviate widely
from the single-ended approach for IPSP.  If you are going to attempt
a double-ended approach, the matter should be addressed in an extension
draft, because it deviates so far from the text and procedures for the
SG/AS case.  With a double-ended procedure, IPSP will be a beast that
is completely different from the AS/SG case and cannot be painted with
the same brush by placing it in the same draft.  Descibing this double-
ended scenario would otherwise require the twinning of text throughout
the entire document, as the ISPS case will always be different from the
AS/SG case.  You seem to want to make the very definitions of RC,
RK and AS different to match your view of a double-ended approach, 
rather than working with the definitions that already work in the
AS/SG case.  Even the terminology might need to be twinned, becuase
your IPSP RC is starting to look different from an SG/AS RC.  For
example, ASPTM procedures must consider two RCs (one of your IPSP
RCs in either direction) to determine whether received DATA or SNMM
messages are for an active or inactive AS.

A single-ended approach, on the other hand, is common to the SG/AS
case and could be dealt with in the draft currenly before us by
expanding some text to include IPSP, or by recognizing that the term
ASP extends to also include the case of ASP to ASP communication for
the non-backhaul scenario.

So, please, let us continue this discussion with the understanding
that a double-ended procedure is very unlike the single-ended procedure
of the SG/AS case that will require all manner of special considerations
in the text (definitions and procedures), and that a single-ended
procedure that closely parallels the SG/AS case is what is called for.
Let us also understand that no reason has been presented and no problem
identified to justify us to deviate so widely and to go searching
out a double-ended approach.  Double-ended doesn't "fix" anything
and it just adds complications.

Comments?

--brian

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

---

---

From: [email-masked]
Date: Tue, 30 Oct 2001 09:38:21 +0200

Hi Javier & Brian,
> An ASP can rely on the RC value for a given RK and AS to be the 
> same for each SGP in an SG.  The SG need make no other assurances 
> regarding the "value" of the RC.

> When dynamic configuration is used, it is clear that the SG 
> assigns the "value" to the RC (e.g. RC=3), but the SG makes 
> absolutely no assurances to any ASP that the value is different 
> that the values assigned by other SGs of the SG in question may 
> or may not be aware.  Another SG can also assign the same value of RC
(e.g., RC=3) as well.

Brian makes a very good point here.  If an ASP is connected
to 2 SGs, each SG may reuse 
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: [email-masked]
Date: Tue, 30 Oct 2001 09:40:10 +0200

Hi Javier & Brian,

> or may not be aware.  Another SG can also assign the same value 
> of RC (e.g., RC=3) as well.

Brian makes a very good point here.  If an ASP is connected
to 2 SGs, each SG may 'reuse' the same value for an RC, 
therefore an ASP MUST discriminate between the values.
I think this is the same situation in the IPSP case.

Put me as in favor of Brian's approach.

John

---

---

From: "MOUILLAUD,FRANCOIS (Non-HP-France,ex2)" <[email-masked]>
Date: Tue, 30 Oct 2001 09:00:13 +0100

Hi Javier,

With respect to the double flow of communications, I have
nothing to add to Brian's comments which wittingly describe
the major changes single-ended flows would require.

Regarding DUPU, yes UPU means the remote UP is unavailable
in MTP3. And DUPU means the remote UP in SS7 network is 
unavailable in M3UA. But in the IPSP case you have no SS7 
network, therefore using the DUPU would be very confusing.
If the UP is unavailable, an ASPIA for all the AS concerned
would clearly describe the situation. Anyway, in an IPSP world,
UPU basically means that an AS is unavailable, right? That's
what ASPIA is all about.

And enjoy Paris and its unexpected "indian summer" this year..

Francois.

> Sent: Monday, October 29, 2001 11:27 PM
> To: 'MOUILLAUD,FRANCOIS (Non-HP-France,ex2) '
> Cc: Javier Pastor-Balbas (ECE)
> Hi François, 
> My first reason to have that scenario is to do AS-AS 
> communication as similar as possible to AS-SG. Wherever you 
> have an AS, you have an SS7 application over M3UA, and 
> wherever you have it you have to inform the other peer what 
> kind of traffic your application wants to receive. This is 
> the normal behaviour for SG-AS and should be the normal 
> behaviour for AS-AS. I think it is very convenient to have an 
> ASP node that easily can work in both configuration and not 
> having to think in which way it has to talk to the adjacent 
> node (ASP or SGP).
> 
> Second reason is that half-duplex communications do exit in 
> current SS7 networks. Take into account that a link is 
> bidirectional but a route is unidirectional !!
> 
> Third, you don't have to support half-duplex communications. 
> And with the current draft, I don't see the use of 
> half-duplex. But, why to close it? Maybe an extension draft 
> can make use of it....
> 
> Four, the coordination needed to the Brian's proposal is far 
> more complicated, since 
>  - you need additional external management 
>  - ASP doesn't work in the same way depending of the adjacent node
>  - you have inside one ASP a RC for more than one RK !! What 
> definetely breaks the M3UA philosophy....
> 
> 
> Having the double ASPAC is like extending the SG-AS behaviour 
> for an ASP node to make possible to him communicate with 
> another ASP. As easy as that. Maybe the sentence of the 
> example is confusing people and we should for the moment 
> assume that all the communications are being full-duplex... 
> Well, I don't care about changing it if you guys think it's 
> better... :-D.
> 
> 
> 
> 
> The DUPU question: Doesn't exist a message in MTP3 that says 
> to a peer node that the User Part of a node is unavailable? 
> I'm currently on vacation in Paris and I don't have the specs 
> with me but I would say it exists...  :-/
> 
> 
> Cheers  // Javier.
> 
> 
> 
> 
> To: 'Javier Pastor-Balbas (ECE)'
> Sent: 10/29/01 6:25 PM
> Please see comments below.
> Francois.
> 
> > Sent: Monday, October 29, 2001 11:17 AM
> > To: 'MOUILLAUD,FRANCOIS (Non-HP-France,ex2) '; 'sigtran '
> > communication should be peer to peer from the beginning. At 
> > least we should not restrict it. You can work with the 
> > client-server philosophy, but the general procedure of the 
> > text serves for peer to peer too.
> > 
> > The reason of having double ASPAC was discussed in this 
> > mailing list in the early September. The conclussion was 
> > basically that as two MTP3 users are talking to each other, 
> > they would need to specify the RK they are working for. And 
> > in that case, if dynamic registration is used, they have to 
> > interchange two ASPACs in the two directions.
> > 
> > You can see it as: SG does not need to send ASPAC since it 
> > has no RK to register for. But, on the other hand, ASPs will 
> > need to send an ASPAC to get itself registered for a specific 
> > RK. If two ASPs want to establish a communication between 
> > them, they both should send its own ASPAC, to inform the 
> > other peer what RK they are working for.
> > 
> [FM] I don't see any value in these half-duplex communications.
> If you're talking to an IPSP shouldn't you know it and then know
> the appropiate RK?
> I am completely in line with Brian's comments on this point.
> Half-duplex mode will add unnecessary complexity and IMHO no value.
> Can you please find a need for this half-duplex mode?
> 
> > 
> > [/Javier]
> > 
> > 
> > mean the signalling traffic is one way? This does not seem 
> consistent
> > nor
> > What it means is that you should send two ASPIAs in the same 
> > way you sent two ASPACs. We don't restrict nothing again 
> > about the possible half-duplex path. Some configurations can 
> > use it if they want. If not, you just have to wait to the 
> > double exchange to happen and avoid data transfer in the meantime.
> > [/Javier]
> > 
> >  
> > 3.
> >      IPSP-A                     IPSP-B1                   IPSP-B2
> >         |                         |                          |
> > "There are no examples of DUNA, DAVA, etc, since each IPSP is 
> > considered
> > to
> > be an endpoint. Therefore, it doesn't have to inform about 
> > the states of
> > the
> > other nodes."
> > 
> > [FM] I agree with the first two scenarios but I don't see 
> the point of
> > the
> > third one.
> > [Javier:] DUPU means a temporal failure of the User Part in 
> > any of the two ASPs. ASPIA should be used when the 
> > communication is closed by decission of the user part.
> > [/Javier]
> 
> [FM] DUPU refers to a remote UPU coming from the SS7 network like DAVA
> or DUNA for destinations. There is no SS7 network here. ASPIA is the 
> relevant message for User Part failure.
> 
> > 

---

---

From: [email-masked]
Date: Tue, 30 Oct 2001 16:08:59 +0200

Hi Javier,

> I agree with Brian's comment that two different SG can reuse 
> the RC value. But going back to the ASP-ASP scenario, if we 
> have three ASPs (ASP-A, ASP-B, ASP-C) and ASP-A wants to 
> communicate with the other two, and the other two are the one 
> who initiate the communication, how can ASP-B and ASP-C know 
> that they both cannot use RC=3. Because, at the same ASP 
> (ASP-A) we cannot have two RKs (RK-B and RK-C ) referred with 
> the same RC ??
> 
> And even more, if ASP-D wants to communicate with ASP-C how 
> can ASP-D know that ASP-C is already using RC=3 ?? 

Because they will not be using the same SCTP association.

John

---

---

From: [email-masked]
Date: Tue, 30 Oct 2001 19:55:55 +0530

Hi John

    Does this mean that we need to interpret the Routing Contexts with
respect to the SCTP Associations on which they came?

Regards
Vaibhav

----- Original Message -----
From: <[email-masked]>
To: "sigtran" <[email-masked]>
Sent: Tuesday, October 30, 2001 7:38 PM
Subject: RE: IPSP proposed text (1st approach)

> You are currently subscribed to sigtran as: [email-masked]

---

---

From: [email-masked]
Date: Tue, 30 Oct 2001 16:29:16 +0200

Hi Vaibhav,

> respect to the SCTP Associations on which they came?

I think that would be a reasonable sanity check, even in the Signaling
Gateway case.

best regards,
John

---

---

From: Dennis Niermann <[email-masked]>
Date: Tue, 30 Oct 2001 11:28:01 -0600

Hi John, Brian

I think that I need my own sanity check regarding
RCs and how they are used in a peer-to-peer situation.
Could you please indicate any statement below that is incorrect. 

Figure 1: SG - ASP

                  +--------+  IP   +-----+
              SS7 |        +------/       \
     +------+     |  SG1   |      | ASP3  |     +------+
     |      +-----+  "STP" +-+   /\       /- - -+      |
     | SEP  |     +--------+  \ /  +-----+      | AS   |
     | 100  |                  \                | 200  |
     |      |     +--------+  / \  +-----+      |      |
     |      +-----+        +-+   \/       \- - -+      |
     +------+     |  SG2   |      | ASP4  |     +------+
                  | "STP"  +------\       /    
                  +--------+       +-----+

In the case of figure 1 (non-peer),
SG1 will have a Routing Context associated with AS200 
(RK indicates DPC=200), say RC3.
RC3 needs to have the same meaning at SG1 for ASP3 and ASP4
(not per association) since at SG1 there needs to be a 1-1 
mapping among RK, RC and AS.
SG2 will also have a Routing Context associated with AS200,
but the RC value does not have to match what is used by SG1,
so it can be say RC4. 

ASP3 and ASP4 each do an ASPAC towards both SGs to declare
that are actively handling AS200 (ASP3 uses RC3 towards SG1
and ASP4 uses RC4 towards SG1 in the ASPAC request, 
but both are refering to the same AS).
The knowledge at the ASPs about how to reach SEP100 (what SG
can be used) needs to be configured to the ASPs since this
is not necessarily conveyed to the ASP in the M3UA message flow,
although there might be a DAVA arrive at some point to 
indicate the availability of point code 100. This will only
happen as the result of a change of state or due to a DAUD
request from the ASP.

 Figure 2:  IPSP - IPSP

                   +-----+   IP   +-----+
                  /       \------/       \
     +------+     | IPSP1 |      | IPSP3 |     +------+
     |      +- - -\       /-+   /\       /- - -+      |
     | AS   |      +-----+   \ /  +-----+      | AS   |
     | 100  |                 \                | 200  |
     |      |      +-----+   / \  +-----+      |      |
     |      +- - -/       \-+   \/       \- - -+      |
     +------+     | IPSP2 |      | IPSP4 |     +------+
                  \       /------\       /    
                   +---- +        +-----+

In the case of figure 2, we are saying that IPSP3 and 
IPSP4 should still send a ASPAC in the same way as
ASP3 and ASP4 in the previous scenario
in order to notify IPSP1 and IPSP2 that they are ready to 
handle traffic for AS200. Once again the RC used with IPSP1
might be RC3, but RC4 might be used with IPSP2.

But, what I do not understand is this.
If IPSP3 and IPSP4 need to send an ASPAC to IPSP1 and IPSP2,
why shouldn't IPSP1 and IPSP2 need to send an ASPAC to IPSP3 and 
IPSP4 to notify them that IPSP1 and IPSP2 are ready to handle 
traffic for AS100?
Since it is a peer and symmetrical network configuration, why
would the need to activate traffic be asymmetrical?
It seems to me that if IPSP1 does not need to activate itself for AS100
then IPSP3 should not have to activate itself for AS200.

Regards,  Dennis

[email-masked] wrote:
> You are currently subscribed to sigtran as: [email-masked]

-- 
---------------------------------------------------------------
 Dennis Niermann              [email-masked]
 Ericsson Network Systems   
 Richardson, Tx 75081

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 30 Oct 2001 12:24:00 -0600

Hi Dennis,

Please see some comments below.
  
  Tolga

> From: Dennis Niermann [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2001 12:28 PM
> To: sigtran
[TOLGA] Why should RC3 have the same meaning on SG1 both for ASP3 and ASP4? RC has meaning only between two entities. So, although it is possible that the same RK has the same RC values for ASP3 and ASP4 on SG1, this is not mandatory.
> happen as the result of a change of state or due to a DAUD
[TOLGA] I think this is currently what is discussed on this thread :) Maybe one of the important points is that how one interprets traffic from AS200 to AS100. If one sees it as part of traffic, which was activated with ASPAC from IPSP3/4 to IPSP1/2 (like in SG-ASP case), then it seems no other activation is necessary. But if one sees it as belonging to another traffic range (to another route key), then ASPAC also in this direction seems logical. With the second approach, one will have only unidirectional traffic for a route key (because for the other direction, one interprets it as different route key) But if it is agreed (?) that we always have symmetrical communication betwen entities, then this model won't bring additional benefit. And it seems that the first one is more similar to SG-ASP case because also there with one activation , one opens a bidirectional communication path.
> [email-masked]
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Oct 2001 12:26:23 -0600

Dennis,

Please see comments below...

Dennis Niermann wrote:                                     (Tue, 30 Oct 2001 11:28:01)
> Hi John, Brian
> 
> I think that I need my own sanity check regarding RCs and how
> they are used in a peer-to-peer situation.  Could you please
> indicate any statement below that is incorrect. 
> 
> 
> Figure 1: SG - ASP
> 
>                   +--------+  IP   +-----+
>               SS7 |        +------/       \
> In the case of figure 1 (non-peer), SG1 will have a Routing
> Context associated with AS200 (RK indicates DPC=200), say RC3.
> mapping among RK, RC and AS.  SG2 will also have a Routing
> Context associated with AS200, but the RC value does not have
> to match what is used by SG1, so it can be say RC4. 
> 
> and ASP4 uses RC4 towards SG1 in the ASPAC request, but both
> are refering to the same AS).  The knowledge at the ASPs about
> how to reach SEP100 (what SG can be used) needs to be
> configured to the ASPs since this is not necessarily conveyed
> to the ASP in the M3UA message flow, although there might be a
> DAVA arrive at some point to indicate the availability of
> point code 100. This will only happen as the result of a
> change of state or due to a DAUD request from the ASP.

Well, an ASP could probably determine which SGs could be
used for SEP 100 from SNMM without static configuration;
however, static configuration is possible too.

> In the case of figure 2, we are saying that IPSP3 and IPSP4
> should still send a ASPAC in the same way as ASP3 and ASP4 in
> the previous scenario in order to notify IPSP1 and IPSP2 that
> they are ready to handle traffic for AS200. Once again the RC
> used with IPSP1 might be RC3, but RC4 might be used with
> IPSP2.
> 
> But, what I do not understand is this.  If IPSP3 and IPSP4
> need to send an ASPAC to IPSP1 and IPSP2, why shouldn't IPSP1
> and IPSP2 need to send an ASPAC to IPSP3 and IPSP4 to notify
> them that IPSP1 and IPSP2 are ready to handle traffic for
> AS100?

I have no doubt that you are confused: you jumped from an STP
SG/AS case to a point-to-point case IPSP case.  Let's go back
to a SG/AS case that parallels the IPSP case and you might see
why:

  Figure 3:  SG - AS
 
                      SG
                    +-----+   IP   +-----+
                   /       \------/       \
      +------+     | SGP1  |      |  ASP3 |     +------+
      |      +- - -\       /-+   /\       /- - -+      |
      | SEP  |      +-----+   \ /  +-----+      | AS   |
      | 100  |                 \                | 200  |
      |      |      +-----+   / \  +-----+      |      |
      |      +- - -/       \-+   \/       \- - -+      |
      +------+     | SGP2  |      |  ASP4 |     +------+
                   \       /------\       /    
                    +---- +        +-----+
 
This is a point-to-point SG/AS case.  The SG, composed of
SGP1 and SP2 is connected (directly) to SEP 100.  The SG
has point code 200.  ASP3 and ASP4 register with SGP1 and
SGP2 (or configure) AS200 with RC3.  Once ASP3 and ASP4
activate RC3 they can then communicate with SEP 100
based on SNMM received concerning SEP 100.

>                    +-----+   IP   +-----+

Now, going back to your IPSP case, IPSP1 and IPSP2 represent
AS100.  IPSP3 and IPSP4 represent AS200 as ASP3 and ASP4
did in the previous case.  IPSP3 and IPSP4 register (or
configure) AS200 as having RC1.  Flipping it around, IPSP1 and
IPSP2 could register (or configure) AS100 as having RC1.

Actually, for RK at point code granularity, you don't even
need an RC value at all in the IPSP case as it is implict
to the association.  AS100 talks to noone but AS200 on all
associations between IPSP1/2 and IPSP3/4.

As IPSP is point-to-point for M3UA, there is never a need
for an RC value at all.   Even AS(PC100/SI3) knows that it
can only communicate with AS(PC200/SI3).  Any yet someone
would have us doing ASPAC twice?  Once for one direction and
once for the other?  Each without an RC?

> would the need to activate traffic be asymmetrical?  It seems
> to me that if IPSP1 does not need to activate itself for AS100

It is not a peer and symmetrical configuration.  It is a
client-server configuration.  One IPSP must connect and the
other must listen, one is active, one is passive.

The symmetry in the situation is that when one IPSP sends
ASPAC, the other replies with ASPAC Ack.  One takes an active
role and the other a passive role.  But either side can
initiate ASPAC.

It is going to be tough finding a case where RC is needed at
all for point-to-point IPSP.

This probably confused you more...

--brian

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

---

---

From: Dennis Niermann <[email-masked]>
Date: Tue, 30 Oct 2001 13:21:53 -0600

Hi Brian,
A followup question.  If in figure 2 IPSP1 and IPSP2
operation in override mode for AS100, and IPSP3 and 
IPSP4 operate in override mode for AS200, how does 
IPSP3 know if IPSP1 or IPSP2 is currently handling 
AS100 if it does not get an ASPAC?

Regards,  Dennis

---

---

From: Dennis Niermann <[email-masked]>
Date: Tue, 30 Oct 2001 13:37:19 -0600

Hi Tolga,
See my comments below.
/Dennis

> [TOLGA] Why should RC3 have the same meaning on SG1 both for ASP3 and ASP4? RC has meaning only between two entities. So, although it is possible that the same RK has the same RC values for ASP3 an…

Section 1.4.1.2 says that at the sending node that there 
is a 1-1 relationship between a RC and a Routing Key and that the RC
can be viewed as an index into the sending node's Message Distribution
Table. I believe this does make it mandatory.

> [TOLGA] I think this is currently what is discussed on this thread :) Maybe one of the important points is that how one interprets traffic from AS200 to AS100. If one sees it as part of traffic, wh…

I believe that once we start looking at more complicated network
examples (AS100 not restricted to talking to only one other AS and AS200
not restricted to talking to only one other AS) that the need for the
second
approach becomes evident.

---

---

From: Dennis Niermann <[email-masked]>
Date: Tue, 30 Oct 2001 14:24:54 -0600

Hi Brian,
Thanks for the challenge!

  <snip>

> all for point-to-point IPSP.

I believe that the following is legal since an ASP can service
more than one AS and an AS can be serviced by more than one ASP:

 Figure 4:  IPSP - IPSP, multiple AS's

     +------+                                  +------+
     |      |                                  |      |
     | AS   |                                  | AS   |
     | 100:4|                                  | 201  |
     |      | \                              / |      |
     +------+   \  +-----+   IP   +-----+  /   +------+
                  /       \------/       \
     +------+     | IPSP1 |      | IPSP3 |     +------+
     |      +- - -\       /-+   /\       /- - -+      |
     | AS   |      +-----+   \ /  +-----+      | AS   |
     | 100:3|                 \                | 200  |
     |      |      +-----+   / \  +-----+      |      |
     |      +- - -/       \-+   \/       \- - -+      |
     +------+     | IPSP2 |      | IPSP4 |     +------+
                  \       /------\       /    
     +------+   /  +---- +        +-----+  \   +------+
     |      | /                              \ |      |
     | AS   |                                  | AS   |
     | 100:5|                                  | 202  |
     |      |                                  |      |
     +------+                                  +------+

Is it supported for an IPSP to handle AS's with different point codes?
Anyway, let's assume that the AS100:3, AS100:4, and AS100:5 all 
use the same point code but have different service indicators.
Doesn't this require IPSP1 and IPSP2 to communicate what traffic
they are handling.  E.g. by IPSP1 activating the RCs for AS100:4 and 
AS100:3 and IPSP2 activating the RC for AS100:5. Otherwise, how will
IPSP3 and IPSP4 know where to send traffic?

Regards,  Dennis

---

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 30 Oct 2001 14:18:11 -0600

Hi Dennis,

Tolga

> Sent: Tuesday, October 30, 2001 2:37 PM
> To: sigtran
> > [TOLGA] Why should RC3 have the same meaning on SG1 both 
> for ASP3 and ASP4? RC has meaning only between two entities. 
> So, although it is possible that the same RK has the same RC 
> values for ASP3 and ASP4 on SG1, this is not mandatory.
> 
[TOLGA] IMHO, another place in the draft, which should be changed. As far as I know, RC have meaning only between two entities (like NA). In fact, maybe one of the editors can tell us the reality. :-)
> > [TOLGA] I think this is currently what is discussed on this 
> thread :) Maybe one of the important points is that how one 
> interprets traffic from AS200 to AS100. If one sees it as 
> part of traffic, which was activated with ASPAC from IPSP3/4 
> to IPSP1/2 (like in SG-ASP case), then it seems no other 
> activation is necessary. But if one sees it as belonging to 
> another traffic range (to another route key), then ASPAC also 
> in this direction seems logical. With the second approach, 
> one will have only unidirectional traffic for a route key 
> (because for the other direction, one interprets it as 
> different route key) But if it is agreed (?) that we always 
> have symmetrical communication betwen entities, then this 
> model won't bring additional benefit. And it seems that the 
> first one is more similar to SG-ASP case because also there 
> with one activation , one opens a bidirectional communication path.
> 
[TOLGA] Nothing is decided yet, so it would be good that you bring up those exmaples, so everybody can say her/his opinion about them.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Oct 2001 14:45:48 -0600

Dennis,

Dennis Niermann wrote:                                     (Tue, 30 Oct 2001 13:37:19)

> > [TOLGA] Why should RC3 have the same meaning on SG1 both for ASP3 and
> > ASP4? RC has meaning only between two entities. So, although it is
> > possible that the same RK has the same RC values for ASP3 and ASP4 on SG1,
> > this is not mandatory.
> 

There is no section 1.4.1.2 in the current M3UA draft.  I think you
are talking about section 1.4.2.1?  Which happens to be entitiled
"Overview".  I think you are reading too much into this passage.
Section 1.4.2.1 is descriptive.  There are no RFC keywords in this
passage.  It is not mandatory.

We once had a RECOMMENDATION (SHOULD) in the draft that said that RC
values should be the same across SGP in an SG for a given ASP, but
it did not address different RCs for different ASPs.  The SG could
implement different routing tables for different ASPs and use
different indexes into those tables.  The ASP should not care.

If you think that a requirement is missing here, we will need to
dicuss it further.

[snip]
> second approach becomes evident.

That remains to be shown.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 30 Oct 2001 15:01:37 -0600

Dennis,

There is still no need (or requirement) for RC in
your illustration.  Each IPSP can activate for all
the AS that it supports (ASPAC without RC).

Then, for example, if IPSP3 loses connection to
AS201, it is ok to send DUNA(201) to IPSP1 and IPSP2.
If you draw the same diagram with AS(PC201/SI3), then
IPSP3 can send DUPU.

Can you come up with a configuration where RC is
'required' considering the point-to-point nature of
IPSPs?  It is not required in this configuration.

--brian

Dennis Niermann wrote:                                     (Tue, 30 Oct 2001 14:24:54)
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: Dennis Niermann <[email-masked]>
Date: Tue, 30 Oct 2001 15:24:54 -0600

Hi Brian,
I agree there is no problem with distributing SSNM messages.
The issue is if IPSP3 has data to send to AS100:3.
How does it know to send it to IPSP1 or IPSP2?
If they work in override mode, only one is actively 
handling traffic for AS100:3.
/Dennis

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Wed, 31 Oct 2001 00:45:45 -0800 (PST)

Hi Brian and others, 

I'm wide open to accept whatever model is better for the IPSP
communication. But everything I see with the single ended model is more
complication and a change in the AS-SG philosophy. So please, if you
think it is better, convince me. It should be easy to  show technical
reasons that I can not debate.

I have some more concerns about your model that I would like to post:

- Do you want to do registration also single ended ?? I suppose this is
in line with your thinkings, since you don't have it from the SG to the
AS.

- Do you want to give new significance to the ASPAC-ACK ?? Till now,
ASPAC-ACK was a result of a successful RK activation in the other peer.
Nothing else. Probably we should change its parameters to inform the
other end what RKs you want to activate !! This in innaceptable. We
have to consider the protocol we have today and not create another
different one. 

- How do you expect to manage the whole thing when you have different
operators ?? We are  going the way back with the single ended model,
far away the automatic configuration...

An ASP in the SG-AS model always sends an ASPAC to activate its RK. It
should be the same for the AS-AS model. Otherwise, we are changing the
way of acting of that node !! 

How can an ASP say the set of RKs it wants to be activated for ?? How
do you manage with single-ended registration ?? 

Even more, how can it differenciate two traffic flows between two ASPs
serving two different ASs each one?? I thought sending the RC along
with the message was an advantage for discriminate amongst the ASs that
an ASP serves.

Your model doesn't seem to resolve this. 

Double ended works in the same way it does with SG-AS. All ASPs
registrate in the other end, and all the ASPs can activate the set of
RKs they want to. As the RC is not tied to a connection, they can use
different RC over a single association. This means, that like in the
SG-AS scenario, you can differenciate the signaling flows over one
association just looking at the RC. 

Everything works in the same way. So good, so easy. You simply reuse
the existing concepts and don't re-interprete them or create new
ones...

Please keep this in your mind: What your model is trying to do is keep
the message flow over the application necessities. What the
double-ended model does is keeping the application necessities over
messages flows. What definetely don't make sense.... 

SG does not have an application, hence it does not need to send ASPAC
and REGISTRATION. In IPSP-IPSP we are talking about other concepts: Two
applications nodes with same necessities and same rights (think again
in multi-operator network).

Cheers // Javier.

---

---

From: [email-masked]
Date: Wed, 31 Oct 2001 11:05:52 +0530

Hi Brian

IPSP-1 is serving AS100/SI3 and AS100/SI4. IPSP-2 is serving AS-200/SI3 and
AS-200/SI4.

     _________
__________
    |AS100/SI3 | \
/ |AS200/SI3 |
                          \
/
                            IPSP1 --------------------- IPSP2
                          /
\
    __________/                                                           \
__________
    |AS100/SI4 |
|AS200/SI4  |

IPSP-1 is the client and IPSP-2 is the server. IPSP-1 sends an ASPUP request
after the SCTP Association is established.
IPSP-1 sends a REG REQ for AS100/SI3 and AS100/SI4. It gets two RC values
RC1(AS100/SI3) and RC2(AS100/SI4).
Now IPSP-1 has to send ASPAC message. As only AS100/SI3 has come up, IPSP-1
sends an ASPAC for RC1. IPSP-1 has to get an ASPAC-ACK before the exchange
of signaling traffic starts. What should IPSP-2 send if the AS200/SI3 is not
ready for exchange of signaling traffic yet? Will it ack the ASPAC message
and then send an DUPU when a message comes for AS200/SI3?

Regards
Vaibhav

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 04:29:31 -0600

Javier,

Javier Pastor-Balbas wrote:                                (Wed, 31 Oct 2001 00:45:45)
> reasons that I can not debate.

There is no change from the AS/SG model.  That is why it is simpler.

> I have some more concerns about your model that I would like to post:

These aren't concerns, they are confusions...

> in line with your thinkings, since you don't have it from the SG to the

For point-to-point nothing more than single-ended registration
is required.  The ASP that doesn't have the RC preconfigured
asks the other.  What's the big deal?

> ASPAC-ACK was a result of a successful RK activation in the other peer.

No.  ASPAC Ack is the result of the successful activation of the AS
not the RK.  The ASP cannot send data to the SG until ASPAC Ack.
Data flows in both directions, you see, even in the SG/AS case.

> have to consider the protocol we have today and not create another

You seem to be creating a different one than the draft in this
message.  There are two sets of management procedures ASPSM and
ASPTM.  ASPTM manages bidirection traffic for AS, not RKs.  RKMM
manages RKs.

> far away the automatic configuration...

It will be easier than double-ended because there are 1/2 the RC
values to assign and no oportunity to mess up the pairing.

> way of acting of that node !! 

You misinterpret the model: ASPAC is to activate (the bidirectional
traffic flow to and from) an AS.  What an SG does with an RK is its
own business.

> do you manage with single-ended registration ?? 

An ASP doesn't say what RKs it wants to be activated for: it tells
the peer what AS it is activating.

> with the message was an advantage for discriminate amongst the ASs that

An ASP identifies the AS it serves by an RC value to its peer.  To
activate its AS to its peer it uses the RC value in ASPAC.  If ASP1
serving AS1 wants to activate AS1 to an ASP2 serving AS2, it
activates it's AS1 with the RC value (RC1) that identifies AS1 to ASP2.
Big deal.

> Your model doesn't seem to resolve this. 

You misinterpret even the SG/AS model.

> association just looking at the RC. 

No.  In the double-ended model, when ASP1 goes to activate AS1 to
ASP2 serving AS2 it must use the RC1 for AS1 to ASP2 and then wait
for RC2 from ASP2 for AS2.  There is no point.

> the existing concepts and don't re-interprete them or create new

All you do is double the RC's and double the complexity of the
procedure.

> messages flows. What definetely don't make sense.... 

What are "application necessities"?

> in multi-operator network).

If SCTP or TCP worked this way you would have to set up two
independent connections to transfer data back and forth.  Only
one is required.  One is active, the other passive.  Think about
it.

--brian

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

---

---

From: [email-masked]
Date: Wed, 31 Oct 2001 17:49:28 +0530

Hi

    As far as I have been able to get it, there are two prevailing thoughts
which have confused me:

   (a) In the SG-ASP case, when I need to send DATA from the ASP to a
destination in the SS7 network, I will have a look at the DPC given by the
M3UA User and have a routing table which will give me the details as to
which all SGPs can be used to reach that destination and so depending on my
load-sharing algorithm I will route the message. KEY POINT : Routing based
on DPC Advantage : Less processing at the ASP

    (b) The second thought(which I could get only yesterday) is that when I
need to send DATA from the ASP to a destination in the SS7 network, then I
do a reverse Routing Key Analysis, get a list of SGPs on which the
particular Routing Context is active and through which the DPC is reachable
and route the message accordingly. KEY POINT : routing based on Routing
Contexts and DPC Advantage : Sanity checks

    Are the two understandings fine? And if the two are fine, then which one
is recommended by the M3UA Editors(at the ASP)?

Regards
Vaibhav

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 31, 2001 3:59 PM
Subject: Re: IPSP proposed text (1st approach)

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 06:32:54 -0600

Vaibhav,

[email-masked] wrote:                      (Wed, 31 Oct 2001 17:49:28)
> is recommended by the M3UA Editors(at the ASP)?

Here's a third: the ASP keeps track of the AS and knows which
messages are coming from which AS.  Then RC is an attribute of
the AS and no RK analysis or DPC examination (which is just a
different RK analysis) is required.

Internally:

              ASP
     +---------------------+
     |                     |
     |   +-------+  RC1    |
     |   |  AS1  |<-----   |
     |   |       |----> \  |
     |   +-------+     \ \ |
     |   +-------+  RC2 \ \|
     |   |  AS2  |<----- \ |
     |   |       |----> \ \|   Association
     |   +-------+     \ \ |
     |   +-------+  RC3 \ \|------------------>
     |   |  AS3  |<--------|<-----------------
     |   |       |-------->|
     |   +-------+      / /|
     |   +-------+     / / |
     |   |  AS4  |<---- / /|
     |   |       |---->/ / |
     |   +-------+      / /|
     |   +-------+     / / |
     |   |  AS5  |<---- /  |
     |   |       |---->/   |
     |   +-------+         |
     |                     |
     +---------------------+

Messages from AS1 are identified as such and are assigned RC1.
No reverse RK analysis or digging in messages is required.

Messages that arrive on the association tagged with RC1 are
delivered to AS1.  No forward RK analysis or digging in
messages is required.

But perhaps you wanted to do all that extra work digging into
messages.

As to approach, that is implementation dependent.  Use what
works (or generates more work) for you.

--brian

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

---

---

From: [email-masked]
Date: Wed, 31 Oct 2001 19:20:12 +0530

Hi Brian

    Please See Comments Inline

Regards
Vaibhav

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: <[email-masked]>
Cc: "sigtran" <[email-masked]>
Sent: Wednesday, October 31, 2001 6:02 PM
Subject: Re: IPSP proposed text (1st approach)

> different RK analysis) is required.

If the RC is an attribute of the AS, then shouldn't the AS have the same
Routing Context over all the ASPs which are serving that AS(no matter which
SG or SGP within a SG)?

The DPC to which the AS wants to send the message might be reachable through
one SG and unreachable through the other SG. When the user sends a DATA
message, I get the RC because it is the AS attribute. Now I need to send the
message to the SG through which the DPC given by the user is reachable. How
do I get that without a DPC examination?

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 07:54:59 -0600

Vaibhav,

[email-masked] wrote:                      (Wed, 31 Oct 2001 19:20:12)

> Routing Context over all the ASPs which are serving that AS(no matter which

You could configure your network that way if you want.  You can't
require others to do so, however.

> do I get that without a DPC examination?

Multiple SGs is a special case, but in general a DPC will not be
unavailable via one STP/SG and available via the other.  These are
STPs you see.  What it can be is restricted via one.  If you a
running in a network without restricted procedures, or don't care
about restricted procedures, you don't necessarily need to keep
track of the state of DPCs via multiple SGs.  That depends alot on
the configuration of the network and what you are trying to acheive.

In a number of cases the ASP could get away without examining DPC
even in multiple SG configurations.  In others it won't.

--brian

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

---

---

From: [email-masked]
Date: Wed, 31 Oct 2001 19:43:29 +0530

Hi

IPSP-1 is serving AS100. IPSP-2 is serving ASP200. IPSP-1 is a client and so
it sends an ASPUP to IPSP-2 after establishing the SCTP Association. Next it
sends an ASPAC with RC1(Routing Key ASP100) to IPSP-2. The IPSP-2 sends an
ASPAC-Ack. Now data can flow as once the exchange is over, the Signaling
data can flow. But AS200 hasn't come up. There is no knowledge at IPSP-1
that AS200 is active or not because ASPAC has to be sent only in one
direction. So we send a message to AS200 from IPSP-1. What will be the
action at IPSP-2? Will it send a DUPU back to IPSP-1 and discard the message
or will it reject the ASPAC in the first place?

Regards
Vaibhav

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 08:21:11 -0600

vaibhav.madan,

[email-masked] wrote:                      (Wed, 31 Oct 2001 19:43:29)
> data can flow. But AS200 hasn't come up.

If AS200 has not come up, IPSP-2 has two choices.  Accept ASPAC and send
DUNA(200), or refuse the ASPAC with Error("Management Blocking").

> There is no knowledge at IPSP-1 that AS200 is active or not because ASPAC
> has to be sent only in one direction.

IPSP-2 knows and has two (count 'em) ways above to inform IPSP-1 of
that fact.

> So we send a message to AS200 from IPSP-1.

If IPSP-2 used Error("Management Blocking") it can discard the message
(IPSP-1 mustn't send unless it gets ASPAC Ack), if it sent DUNA(200),
it can send DUNA(200) again in response to the message as it discards it.

> What will be the action at IPSP-2?

Either of the above, just as an SG would function...

> Will it send a DUPU back to IPSP-1 and discard the message or will it reject
> the ASPAC in the first place?

Now you have the right idea.  Either would work within the existing
message and procedure definitions.  IPSP-1 can be an ASP that doesn't
know that its talking to an IPSP instead of an SG.

--brian

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

---

---

From: [email-masked]
Date: Wed, 31 Oct 2001 19:54:40 +0530

Brian,

Pls see comments inline...

Anshoo.

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 31, 2001 7:24 PM
Subject: Re: IPSP proposed text (1st approach)

> > > different RK analysis) is required.

How can the M3UA at ASP know which AS the DATA to be sent belongs to
without analysing the Routing Label. Do you mean to say that the
AS Identifier would be given by MTP3 User Part??? Pls clarify...

and even after knowing the AS there would be a considerable amount of
processing involved in finding the SGPs in which this AS is Active.

I do not understand why we need to know whether the RC is Active
while sending DATA from the ASP to SG. Is the SG Reachability Status
of the DPC not sufficient?

> You are currently subscribed to sigtran as: [email-masked]

---

---

From: [email-masked]
Date: Wed, 31 Oct 2001 20:11:00 +0530

Hi Brian
    Please See Comments -

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: <[email-masked]>
Cc: "sigtran" <[email-masked]>
Sent: Wednesday, October 31, 2001 7:51 PM
Subject: Re: IPSP proposed text (1st approach)

> DUNA(200), or refuse the ASPAC with Error("Management Blocking").

As far as sending ASPAC and then sending DUNA is concerned DUNA is for a
point code and in case where it is one AS which is not available on the
point code and not all the AS(say AS200/SI3 is not available and AS200/SI4
is available) We cannot send DUNA because one AS is there and sending a DUNA
will make the peer feel that the whole node is down.( We may be using the
same SCTP Association to serve both the Application Servers)

Probably we need to go for two different reasons while sending the Error
message - Management Blocking would not be the exact choice if the AS has
not come up but will come up just after the Error message was sent. If we
send a Management Blocking, then the peer might think that it has not paid
the fees and it is gone :):) We could have something like - AS NOT UP for
RC1 PLEASE TRY AFTER SOME TIME instead of Management Blocking.

> know that its talking to an IPSP instead of an SG.

At last I am catching the frequency of Communication :):)

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 08:43:14 -0600

anssharma,

[email-masked] wrote:                            (Wed, 31 Oct 2001 19:54:40)
> AS Identifier would be given by MTP3 User Part??? Pls clarify...

It is implicit to the interface to the MTP3 User.

> processing involved in finding the SGPs in which this AS is Active.

Depends if there are more than one.

> of the DPC not sufficient?

No.  It was decided that SNMM needed to be on a per-SG basis rather
than a per SGP basis.  ASPTM is on a per ASP/AS basis and is the best
way for the SG can control traffic.  SNMM becomes insufficient for
controlling traffic between SGP and ASP when the RC is more granular
than DUPU (e.g. CIC Range).

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 08:49:30 -0600

Vaibhav,

Vaibhav Madan wrote:                                      (Wed, 31 Oct 2001 20:11:00)
> same SCTP Association to serve both the Application Servers)

So I take it you prefer the Error(Mgmt Blocking) approach.  You're welcome.

> not come up but will come up just after the Error message was sent.

Then IPSP-2 could send ASPAC.

> If we send a Management Blocking, then the peer might think that it has not
> paid the fees and it is gone :):) We could have something like - AS NOT UP
> for RC1 PLEASE TRY AFTER SOME TIME instead of Management Blocking.

Management Blocking is ok.  It means, the AS is not available for RC1, please
try after some time.  I has nothing to do with paying bills.

--brian

> -------------------------------------------------------------------------------------------------------------------------
> Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and
> is intended for use only by the individual or entity to which it is
> addressed, and may contain information that is privileged, confidential or
> exempt from disclosure under applicable law. If you are not the intended
> recipient or it appears that this mail has been forwarded to you without
> proper authority, you are notified that any use or dissemination of this
> information in any manner is strictly prohibited. In such cases, please
> notify us immediately at mailto:[email-masked] and delete this mail
> from your records.
> ----------------------------------------------------------------------------------------------------------------------

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

---

---

From: [email-masked]
Date: Wed, 31 Oct 2001 20:33:25 +0530

Hi Brian

    If Management Blocking is OK, then is there any way at the SG to
indicate to the peer ASP that you cannot access the SS7 world through the
SG(probably for security reasons) or there is no need for any such blocking?
I mean if the SG acts as a kind of gateway between the IP domain and the SS7
world, then it could de well with rejecting some users in the IP domain of
access to the SS7 world.

Regards
Vaibhav

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "Vaibhav Madan" <[email-masked]>
Cc: "sigtran" <[email-masked]>
Sent: Wednesday, October 31, 2001 8:19 PM
Subject: Re: IPSP proposed text (1st approach)

> > > > IPSP-1 is serving AS100. IPSP-2 is serving ASP200. IPSP-1 is a
client
> > and so
> > > > sends an ASPAC with RC1(Routing Key ASP100) to IPSP-2. The IPSP-2
sends
> > an
> > > > Will it send a DUPU back to IPSP-1 and discard the message or will
it
> > reject
> --------------------------------------------------------------------------
-----------------------------------------------
> --------------------------------------------------------------------------
--------------------------------------------

---

---

From: [email-masked]
Date: Wed, 31 Oct 2001 20:41:35 +0530

Hi Brian

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 31, 2001 8:13 PM
Subject: Re: IPSP proposed text (1st approach)

> than DUPU (e.g. CIC Range).

Coming back to the case where the SSNM messages are per-SG basis, then long
time back I had sent a mail with the following architecture

                        ______
                        SGP 1    \
                        ______        \    _________
                            |               /       ASP1
                        __|____  /          _________
                         SGP2
                        ______

ASP1 has an SCTP Association with SGP1 and SGP2 . Also SGP1 and SGP2 belong
to the same SG. Now DPC 1 in the SS7 network becomes available from the
point of view of the SGP-1 but is still available from SGP-2. So we send a
DUNA to ASP1 from SGP1 or we do not because SSNM messages are per SG basis?
If we do not send it, then how will the ASP which will now had been load
sharing on both SGP-1 and SGP-2 send all the messages to SGP-2 only.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 09:11:08 -0600

Vaibhav,

Access in the SS7 world is handled with SNMM.  Send DUNA or
DUPU if you want to deny access to SS7.  That is what SS7
does.

--brian

[email-masked] wrote:                      (Wed, 31 Oct 2001 20:33:25)

Content-Description: footer

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 09:22:03 -0600

vaibhav.madan,

[email-masked] wrote:                      (Wed, 31 Oct 2001 20:41:35)
> time back I had sent a mail with the following architecture

SGP failures are not SS7 events and are not communicated using SNMM.

In this case there are two (count 'em) choices.  Either SGP1 and SGP2
have the RECOMMENDED inter-SGP communication and can transfer the
necessary messages betwixt themselves, or SGP1 can now send unsolicited
ASPIA Ack to shut down the traffic.

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 31 Oct 2001 16:26:37 +0100

Hi Vaibhav,

In this case there are several options :

- if SGP2 has gone down (single processor failure in the SG), the ASP gets
to know via the SCTP CDI;

- if the SGP2 gets totally isolated from the rest of the SG system, it could
send ASP_Inactive_Ack to stop traffic to it.

But normally, both SGP1/SGP2 share the same SS7 view. Otherwise, they're
simply two different SGs !

____________________________

Gery Verwimp
> SIEMENS ATEA
> ICN D CS D5
> Tel. : +32 14 25 3424
Fax : +32 14 25 3212
mailto:[email-masked]
____________________________________

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 31 oktober 2001 16:12
To: sigtran
Subject: Re: IPSP proposed text (1st approach)

Hi Brian

----- Original Message -----
From: "Brian F. G. Bidulock" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, October 31, 2001 8:13 PM
Subject: Re: IPSP proposed text (1st approach)

                        ______
                        SGP 1    \
                        ______        \    _________
                            |               /       ASP1
                        __|____  /          _________
                         SGP2
                        ______

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Wed, 31 Oct 2001 12:05:42 -0800 (PST)

Brian, 

See below...

> There is no change from the AS/SG model.  That is why it is simpler.

THERE IS A CLEAR CHANGE in the ASP conception. Single ended ASP don't
activate its ASs !!! In SG-AS model all the ASP activate their ASs !!

> asks the other.  What's the big deal?

You mean that one of the two ASPs needs to have the RC preconfigured ??
Which one of them ? How can an operator get assure that he has not to
preconfigure RC since the other one has already done it? I'm afraid
this is not automatic. Single ended model is going backwards...

> Data flows in both directions, you see, even in the SG/AS case.

SG doesn't have RK to activate in the ASP. That's a big difference that
is not present in the IPSP cases...

> ASPTM.  ASPTM manages bidirection traffic for AS, not RKs.  RKMM

Apart from your clarification on AS (thanks), you have not answer my
question. Why other ASP has to activate my own AS ?? Maybe I want to
activate a different AS or simply I don't want to activate it right
now...

> values to assign and no oportunity to mess up the pairing.

Sorry, but having two RCs per communication don't add complexity in
computer programs developed today. You can easily treat them with the
same reference if that is your problem... And from then it's like
single-ended model but working as the SG-AS used to work.

> traffic flow to and from) an AS.  What an SG does with an RK is its

Change RK for AS in my comment above and answer it...

> activates it's AS1 with the RC value (RC1) that identifies AS1 to

You misinterpreted my statement... Imagine that ASP1 serves AS-1A and
AS-1B. And ASP2 serves AS-2A and AS-2B. The wanted communication is
between AS-1A and AS-2A and over the same association AS-2A and AS-2B.
How can  this been solved ? In fact, a big deal....

> for RC2 from ASP2 for AS2.  There is no point.
Right !! Each ASP sends an ASPAC to activate its AS and an AS has
associated its own RC. It works as SG-AS...

> All you do is double the RC's and double the complexity of the

All I do is to use the same philosophy as in AS-SG communication. ASP
works in the same way as in AS-SG since it always sends an ASPAC to
activate its ASs.

> What are "application necessities"?

Each application wants to activate its own AS as it does in the SG-AS
model. The number of messages in the middle depends on whether you have
a SG ( no application there) or another AS (with an application)

> one is required.  One is active, the other passive.  Think about
We are not talking of transport protocols here. But anyway SCTP works
similar to this. Take a look to the negotiation of a number of
streams... I'm afraid that is not only one node who has the number
stores and simply send it to the other peer.

In the same way I think (trying to remember) that TCP sends two SYNCs. 

We could also modify these protocols to work only with single ASPACs...

Anyway you didn't demonstrate my statement was wrong. Think again in
multioperator networks...

Cheers // Javier.

---

---

From: Javier Pastor-Balbas <[email-masked]>
Date: Wed, 31 Oct 2001 12:18:45 -0800 (PST)

Hi Brian, 

See comments below...

--- "Brian F. G. Bidulock" <[email-masked]> wrote:
> > > [email-masked] wrote:                      (Wed, 31 Oct
> 2001
> > 19:20:12)
> > >
> > > > >

One of the reasons of including RC in DATA mesgs, was to be able in the
ASP to differenciate data flows to different ASs. With single-ended you
lose this capability since RC is like a connection identifier. It loses
its meaning of being a different value for each AS. Therefore RC in
DATA msgs can not make sense...

Anyway, a model has to be good enough to not change the previously
agreed defined parameters...

Cheers //Javier.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 14:37:17 -0600

Javier,

Javier Pastor-Balbas wrote:                                (Wed, 31 Oct 2001 12:05:42)
> activate its ASs !!! In SG-AS model all the ASP activate their ASs !!

In the SG/AS model ASP activate their ASs !!!!!   That is the same
for the IPSP model !!!!!

> You mean that one of the two ASPs needs to have the RC preconfigured ??

In doubled-ended each ASP need one configured each or one ASP needs
both RCs configured at one.  What's worse, they both need to be
preconfigured to know the other's RC in advance so that it can
ensure duplex communication.  Double-ended is more that twice as
bad.

In both the SG and single ended model, only one end needs to determine
the RC and the other can register.

> Which one of them ?

Only one of them.  In double-ended model: both of them for both RCs.

> How can an operator get assure that he has not to
> preconfigure RC since the other one has already done it?

There are human beings to tell it just as in the SG/AS case.  In
singled ended human beings do half the telling and made half the
mistakes.

> I'm afraid this is not automatic.

Double ended is not automatic either.  When ASP1 registers with
ASP2, how does ASP2 know the RC to return?  And then then ASP2
registers with ASP1 how does ASP1 know what RC to return?  An how
does either ASP know the RCs are related?

> Single ended model is going backwards...

Single ended is status quo with SG/AS.  Double-ended is the great
leap backwards.

> is not present in the IPSP cases...

IPSP does not have an RK to activate in other IPSP either.  This is
point-to-point operation only.  No routing involved.  No keys required.

> activate a different AS or simply I don't want to activate it right

It works for SG/AS.  SG can refuse if not prepared to serve the AS.
IPSP can refuse if not prepared to serve its AS.

> single-ended model but working as the SG-AS used to work.

SG does not register with AS.  SG does not activate AS.  Only ASP
does this.  SG/AS model is single ended.  You propose something
complete different.

> Change RK for AS in my comment above and answer it...

A: In single-ended model ASP sends ASPAC to activate it's AS.

> How can  this been solved ? In fact, a big deal....

That is not point-to-point.  Form two associations: one for AS-1A to
AS-2A and one for AS-2A and AS-2B if you'd like.

> associated its own RC. It works as SG-AS...

When ASP1 sends ASPAC with RC1 for AS1 to ASP2 it activates nothing.
No traffic can flow until the reverse direction has been performed.
It just takes twice as many messages and RC values to perform the
same function.

> works in the same way as in AS-SG since it always sends an ASPAC to

But in the double ended model, the first ASPAC exchange activates
nothing because traffic cannot flow (one direction does not a signalling
relation make).

> a SG ( no application there) or another AS (with an application)

It appears that the number of messages in the middle only depends on
the number that one wants to waste and the number of RC assignments
that one wants to waste as well.  Only the single ended procedure
is necessary.  Half the double procedure is unnecessary as it only
takes twice as many messages to accomplish the same goal: a full-duplex
signalling relation between a pair of AS.

> We are not talking of transport protocols here.

Gee.  I though we were transporting SS7.  That's what it says in the
SIGTRAN framework, charter, scope, ....   What are we doing if not
transporting SS7?

> But anyway SCTP works similar to this. Take a look to the negotiation of a
> number of streams... I'm afraid that is not only one node who has the number

But only two messages are exchanged to accomplish this: it is single
ended.

> In the same way I think (trying to remember) that TCP sends two SYNCs. 

SYN-SYN/ACK-ACK is enough.

> We could also modify these protocols to work only with single ASPACs...

The third message is not required for the active side to start traffic.
Only two messages set up the connection already.

> multioperator networks...

Double-ended: Twice the headache with twice the RCs.  Single-ended:
only single headache.

Why do you want to give operators the double migraine?

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 31 Oct 2001 14:42:42 -0600

Javier,

Javier Pastor-Balbas wrote:                                (Wed, 31 Oct 2001 12:18:45)
> DATA msgs can not make sense...

Wrong.  RC is still used to identify the AS at the local end of an
association.  All that is needed.  With double ended you would like
to force the AS to be associated wtih two RCs (one for each direction)
meaning that existin ASP code cannot be reused.  It makes perfect sense
to use one RC to represent the local AS and traffic in both directions
to and from it just as in the SG/AS case.  Your proposal wants to change
all that and require the ASP to attach one RC for outgoing messages
and another to incoming for the same AS.  This is positively different
from the SG/AS case, and my primary objection to the double-ended
proposal.

> agreed defined parameters...

That's why single-ended is the way to go.  Double ended changes
conditions at the ASP by requiring two RCs (count 'em) to be
associated with one AS for a single bidirectional traffic flow.
In both the single-ended and SG/AS models only one RC value (count
'em) need be associated with an AS at an ASP to represent a single
bidirectional traffic flow.

Can you count?  Count the RCs for us...

--brian

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

---