Subject: IPSP Text (take 3?)

From: [email-masked]
Date: Thu, 15 Nov 2001 14:31:44 +0200

Hi all,

I've reviewed Javier's text, and I have made some modifications.  I've
removed text.  Please comment.  

best regards,
John

============================================================================
======

1.4.2.4 Message Distribution at the IPSP 

[I suggest we delete this text, it is mostly operational in nature.  If it
is truly needed, I think we should simplify it.

4.3.3. IPSP Considerations (ASP State Transition Diagram)

For IPSP signalling, the state transition is diagrammed in Figure F.

Figure F: ASP State Transition Diagram (Per AS for AS-AS communication) 
    
                                      +--------------+  
                                      |              | 
               +----------------------|  ASP-ACTIVE  | 
               |      Other   +-------|              | 
               |   ASP in AS  |       +--------------+ 
               |   Overrides  |           ^     | 
               |              |    ASP    |     | ASP 
               |              |    Active |     | Inactive 
               |              |           |     v 
               |              |       +--------------+ 
               |              |       |              | 
               |              +------>| ASP-INACTIVE | 
               |                      +--------------+ 
               |                          ^     | 
     ASP Down/ |                 ASP Up / |     | ASP Down / 
 ASP Down Ack/ |              ASP Up Ack  |     | ASP Down Ack /
     SCTP CDI/ |                          |     | SCTP CDI /
       SCTP RI |                          |     | SCTP RI
               |                          |     v
               |                      +--------------+ 
               |                      |              | 
               +--------------------->|   ASP-DOWN   | 
                                      |              | 
                                      +--------------+

The AS state diagram for the AS-SG case is applicable for IPSP communication

4.3.4.1.2 IPSP Considerations  (ASPUP)

A single ASP UP and ASP UP Ack is needed to start communication between two
IPSPs.  When an IPSP recieves an ASP UP, it should mark the peer as
ASP-INACTIVE and return an ASP UP Ack message, if it is not already in the
ASP_INACTIVE state, and informs Layer Management with an M-ASP_UP
confirmation primitive.  An ASP recieving an ASP UP Ack message should mark
the peer as ASP-Inactive, if it is not already in the ASP_INACTIVE state,
and informs Layer Management with an M-ASP_UP confirmation primitive. 

If for any local reason (e.g., management lock-out) the IPSP-B cannot
respond with an ASP Up Ack message, it responds to an ASP Up message with an
Error message with Reason "Refused - Management Blocking" and leaves IPSP-A
in the ASP-DOWN state.

4.3.4.4.1 IPSP Considerations (ASPAC)
    
Either of the IPSPs can initiate communication. When an IPSP recieves an ASP
Active, it should mark the peer as ASP-ACTIVE and return an ASP Active Ack
message, if it is not already in the ASP-ACTIVE state. An ASP recieving an
ASP Active Ack message should mark the peer as ASP-Active, if it is not
already in the ASP-ACTIVE state.  Both IPSPs SHOULD be in the ASP-ACTIVE
state before traffic can start to flow.

4.3.4.5.1 IPSP Considerations (ASPIA)

An IPSP can be considered in the ASP-INACTIVE state by a remote IPSP after
an ASP Inactive message has been received from it. 

4.3.4.6.1 IPSP Considerations (NTFY)

Notify works in the same manner as in the SG-AS case. One of the IPSPs can
send this message to any remote IPSP that is not in the ASP-DOWN state.

4.4.3 IPSP Considerations (REG/DEREG)

The Registration/Deregistration procedures work in the IPSP cases in the
same way as in AS-SG cases. Each IPSP has to register its own RK in the
remote IPSP.  Each IPSP deregisters itself.

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 15 Nov 2001 09:34:24 -0800

Folks,

We're coming up very soon on the deadline for updated
draft submission (next Wednesday).  The updates to M3UA and SUA
should be taking into account the comments that have
been made since the last versions (editors will 
provide change lists as usual).

Regarding IPSP, it seems that there are still differing
views on the composition of an IPSP, but at the same time
a strong interest in having supporting text for IPSP
based on anticipated applications (esp. 3GPP).  As a
way forward, let's look closely at the text that is
currently in the drafts, together with John's proposed text
(editted from Javier's) and see if that's acceptable
and does not constrain the design of an IPSP.

Cheers,

L. Ong

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, November 15, 2001 4:32 AM
To: sigtran
Subject: IPSP Text (take 3?)
Importance: High

Hi all,

best regards,
John

    
                                      +--------------+  
                                      |              | 

    

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

---

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 15 Nov 2001 14:57:57 -0800 (PST)

Hi,

Please see comments below.

  Tolga

> From:	[email-masked] 
> Sent:	Thursday, November 15, 2001 7:42 AM
> To:	"sigtran" <[email-masked]>
> Cc:	 
==============================================================
> ==============
> [I suggest we delete this text, it is mostly
operational in 
> nature.  If it
> Figure F: ASP State Transition Diagram (Per AS for
AS-AS 
> communication)
+--------------+
>                                       |             
|
>                |      Other   +-------|             
|
>                |              |    ASP    |     |
ASP
>                |              |    Active |     |
Inactive
+--------------+
|
>                |                     
+--------------+
>        SCTP RI |                          |     |
SCTP RI
>                |                     
+--------------+
|
>                                       |             
|
+--------------+
> The AS state diagram for the AS-SG case is
applicable for 
> IPSP communication
> ASP-INACTIVE and return an ASP UP Ack message, if it
is not 
> already in the
> confirmation primitive.  An ASP recieving an ASP UP
Ack 
> message should mark
> the peer as ASP-Inactive, if it is not already in
the 
> ASP_INACTIVE state,
> respond with an ASP Up Ack message, it responds to
an ASP Up 
> message with an
> Error message with Reason "Refused - Management
Blocking" and 
> leaves IPSP-A
[TOLGA] If the proposed model is so similar to the
regular SG/ASP case, why not to make it the same?
Let's have double ASPUPs. Like this, our IPSP node
does need need to know, whether it is communicating
with another IPSP node or with a SG. What is bad about
it, just one more message and we will keep the logic
same like in SG/ASP case. Otherwise, we need to know,
whether our peer is another IPSP or a SG. 
> Either of the IPSPs can initiate communication. When
an IPSP 
> recieves an ASP
> Active, it should mark the peer as ASP-ACTIVE and
return an 
> ASP Active Ack
> message, if it is not already in the ASP-ACTIVE
state. An ASP 
> recieving an
> ASP Active Ack message should mark the peer as
ASP-Active, if 
> it is not
> already in the ASP-ACTIVE state.  Both IPSPs SHOULD
be in the 
> ASP-ACTIVE
[TOLGA] Again why not to make it the same like in
SG/ASP case? Why do we need to wait that both of IPSPs
are in ASP-ACTIVE state. If one could have a pairing
between ASs in both IPSPs (for example AS1 on IPSP1 is
communicating with AS7 on IPSP2) then before sending a
message for AS1 from IPSP1, it could be -maybe-
meaningfull  to check whether IPSP2 is active for AS7.
 But what is the reson behind waiting till both of the
IPSPs are in ASP-ACTIVE state.
> An IPSP can be considered in the ASP-INACTIVE state
by a 
> remote IPSP after
> Notify works in the same manner as in the SG-AS
case. One of 
> the IPSPs can
> send this message to any remote IPSP that is not in
the 
> ASP-DOWN state.
> The Registration/Deregistration procedures work in
the IPSP 
> cases in the
> same way as in AS-SG cases. Each IPSP has to
register its own 
> RK in the
[TOLGA] My opinion is not to make any changes to
protocol for IPSP case. We can mention about it as a
sample configuration. Everything necessary to let two
nodes in IP domain to communicate in point-to-point
fashion is already provided with M3UA protocol.
> ---
> You are currently subscribed to sigtran as:
[email-masked]
> [email-masked]

__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 15 Nov 2001 20:44:18 -0600

Tolga,

Tolga Asveren wrote:                       (Thu, 15 Nov 2001 14:57:57)
[snip]
> > A single ASP UP and ASP UP Ack is needed to start communication
> > between two IPSPs.  When an IPSP recieves an ASP UP, it should mark
> > the peer as ASP-INACTIVE and return an ASP UP Ack message, if it is
> > not already in the ASP_INACTIVE state, and informs Layer Management
> > with an M-ASP_UP confirmation primitive.  An ASP recieving an ASP UP
> > Ack message should mark the peer as ASP-Inactive, if it is not
> > already in the ASP_INACTIVE state, and informs Layer Management with
> > an M-ASP_UP confirmation primitive.  If for any local reason (e.g.,
> > management lock-out) the IPSP-B cannot respond with an ASP Up Ack
> > message, it responds to an ASP Up message with an Error message with
> > Reason "Refused - Management Blocking" and leaves IPSP-A in the
> > ASP-DOWN state.

> [TOLGA] If the proposed model is so similar to the regular SG/ASP
> case, why not to make it the same?  Let's have double ASPUPs. Like
> this, our IPSP node does need need to know, whether it is
> communicating with another IPSP node or with a SG. What is bad about
> it, just one more message and we will keep the logic same like in
> SG/ASP case. Otherwise, we need to know, whether our peer is another
> IPSP or a SG. 

But double ASPUPs are not required to an SG.

We should leave this as either IPSP able to issue ASPUP.

> > Either of the IPSPs can initiate communication. When an IPSP
> > recieves an ASP Active, it should mark the peer as ASP-ACTIVE and
> > return an ASP Active Ack message, if it is not already in the
> > ASP-ACTIVE state. An ASP recieving an ASP Active Ack message should
                         ^^^
> > mark the peer as ASP-Active, if it is not already in the ASP-ACTIVE
> > state.  Both IPSPs SHOULD be in the ASP-ACTIVE state before traffic
> > can start to flow.

> [TOLGA] Again why not to make it the same like in SG/ASP case? Why do
> we need to wait that both of IPSPs are in ASP-ACTIVE state. If one
> could have a pairing between ASs in both IPSPs (for example AS1 on
> IPSP1 is communicating with AS7 on IPSP2) then before sending a
> message for AS1 from IPSP1, it could be -maybe- meaningfull  to check
> whether IPSP2 is active for AS7.  But what is the reson behind waiting
> till both of the IPSPs are in ASP-ACTIVE state.

Double ASPACs are not required to an SG.  It sounds like you are asking
for single ASPACs here while above you ask for double ASPUPs.

If you want to truly parallel the AS/SG operation, only on ASPUP is
required and only one ASPAC is require to start traffic.

I agree with you that the IPSP may want to check that it can access the
destination to which it is sending; however, that could be accomplished
with SNMM and has nothing to do with the IPSP peer being "active".

So, essentially, once the IPSP receives ASPAC Ack it can send traffic to
destinations that it knows to be available.  This is a single ASPAC.

So strike "Both IPSPs SHOULD be in the ASP-ACTIVE state before traffic
can start to flow."

The text should say "IPSP receiving and ASP Active Ack" instead of
an "ASP receiving...".

> > An IPSP can be considered in the ASP-INACTIVE state by a remote IPSP
> > after an ASP Inactive message has been received from it.
> > Notify works in the same manner as in the SG-AS case. One of the
> > IPSPs can send this message to any remote IPSP that is not in the
> > ASP-DOWN state.
> > The Registration/Deregistration procedures work in the IPSP cases in
> > the same way as in AS-SG cases. Each IPSP has to register its own RK
> > in the remote IPSP.  Each IPSP deregisters itself.

> [TOLGA] My opinion is not to make any changes to protocol for IPSP
> case. We can mention about it as a sample configuration. Everything
> necessary to let two nodes in IP domain to communicate in
> point-to-point fashion is already provided with M3UA protocol.

I agree.  There is no reason to state that each IPSP must register.
Registration is optional.  If nothing else, one IPSP could be statically
configured and the other dynamic.

With those reductions, it would be possible to remove IPSP
considerations altogether and write "ASP/IPSP" everywhere.

--brian

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 16 Nov 2001 10:01:03 +0100

> From: Tolga Asveren [mailto:[email-masked]]
> Sent: Thursday, November 15, 2001 11:58 PM
> To: sigtran
> Subject: Re: IPSP Text (take 3?)
> 
> 

As you can see from the draft, sending two ASPUP has no problems with the above definition. But what we can remark is that only one is enough, since receiving the response from the other side (Asp-Up ack) gives the result that it is also UP and running.

> IPSPs are in ASP-ACTIVE state.

I think you mean sending a message for AS7 from IPSP1. If AS7 in IPSP2 is not in ASP-ACTIVE state, then traffic won't go through the wire. This means that traffic won't flow. You don't have to send two ASPACs every time that two AS located in different IPSPs want to communicate. They can be already activated. Therefore you should check it before sending data thru the wire. Does this answer your question... ?  :-)

> fashion is already provided with M3UA protocol.

You are right. That's the philosophy. It's only having a little text to avoid confusion and misinterpretation in the key points.

Cheers // Javier.

> [email-masked]

---

---

From: [email-masked]
Date: Fri, 16 Nov 2001 13:07:06 +0200

Hi Brian,

> We should leave this as either IPSP able to issue ASPUP.

Agreed.

> Double ASPACs are not required to an SG.  It sounds like you 
> are asking for single ASPACs here while above you ask for double
>  ASPUPs.
> 
> I agree with you that the IPSP may want to check that it can 
> access the destination to which it is sending; however, that could 
> be accomplished with SNMM and has nothing to do with the IPSP peer 
> being "active".
>
> So, essentially, once the IPSP receives ASPAC Ack it can send 
> traffic to destinations that it knows to be available.  This is a single 
> ASPAC.
> 

I can do that.
 
> The text should say "IPSP receiving and ASP Active Ack" instead of

Will change that.
 
> Registration is optional.  If nothing else, one IPSP could be 
> statically configured and the other dynamic.

So, I will modify it to this:

Each IPSP may register its own RK in the remote IPSP.  Each IPSP 
deregisters itself.

> considerations altogether and write "ASP/IPSP" everywhere.

So, you wouldn't want to see the text seperated, it might be
useful still to have it.

John

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 16 Nov 2001 13:06:01 +0100

Hi John,

IPSP, as it now stands, is a union of ASP/SGP functionality, where the ASPs
run the (signalling) applications and the SGP provides distribution of
traffic to the configured/registered ASPs and provides connectivity to what
basically is an SS7 signalling overlay network (using SNMM etc.), based on
point codes (IPSP IDs ?).

In that respect, it is sufficient for the SCTP associations between IPSPs to
be up and running, without further ado. Perhaps ASPSM procedures (up, down,
heartbeat) are still useful, but I don't see any need for ASPTM procedures
as traffic distribution is hidden from the network.

Traffic modes between IPSPs, as in SS7, are then fixed by configuration ...
dynamic routing procedures is part of the IP routing protocols anyway ...
and there's no need to split-up traffic that was aggregated in the SG in the
first place.

So from the outside, an IPSP just looks like a SG. It can be considered
active as soon as the SCTP association is up.

____________________________

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: vrijdag 16 november 2001 12:07
To: sigtran
Subject: RE: IPSP Text (take 3?)

Hi Brian,

Agreed.

I can do that.

Will change that.

John

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

---

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 16 Nov 2001 05:50:34 -0800 (PST)

Brian,

   Tolga
--- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> regular SG/ASP
[TOLGA] You are rigth, if we have one ASP and one SG,
we need only one ASPUP. But in the proposed IPSP
model, an IPSP consist of ASP and SG functionality.
So, if there are two IPSPs there are also two SGs and
two ASPs from protocol point of view. With one ASPUP
between two ASPs, the protocol behaeves different than
in SG/ASP case. My opinion is, if possible, to make it
exactly the same, i.e. a node should't behaeve
differently whether its peer is a SG or IPSP. Shortly,
what I said was, use one ASPUP from ASP of IPSP1 and
one ASPUP from ASP of IPSP2.
> SG/ASP case? Why do
> meaningfull  to check
[TOLGA] Here my argument is again the same like in
ASPUP case. Between ASP of IPSP1 and and SG of IPSP2,
we need only one ASPAC, like in regular SG/ASP case.
Traffic from IPSP2 to IPSP1 belongs to another RK and
currently there is no way in the proposed model to RKs
in reverse directions to each other. So, one ASPAC
from IPSP1 to IPSP2 should be enough to start traffic
flowing from IPSP1 to IPSP2. For IPSP2 to IPSP1
direction we need ASPAC from IPSP2 to IPSP1. Also, it
should be noted, when I proposed double ASPUP, it is
not necessary to let traffic flow in one direction.
For example, IPSP1 sends ASPUP, receives ASPUP-ACK
from IPSP2, IPSP1 sends ASPAC receives ASPAC-ACK from
IPSP2. Now, IPSP1 cans end traffic to IPSP2. There is
no need for IPSP2 to send ASPUP to IPSP1 for this.
ASPUP is sent from ASP functionalituy of IPSP1 and
received by SG functionality of IPSP2. My opinion is
thinking ASP and SG functionalities of IPSPs as
separate entities.
> case. One of the
> protocol for IPSP
> [email-masked]

---

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 16 Nov 2001 06:06:52 -0800 (PST)

Javier,

Please see comemnts below.

   Tolga

--- "Javier Pastor-Balbas (ECE)"
<[email-masked]> wrote:
> > > A single ASP UP and ASP UP Ack is needed to
> start 
> > > communication between two
> > > IPSPs.  When an IPSP recieves an ASP UP, it
> should
> > mark the peer as
> > > If for any local reason (e.g., management
> lock-out)
> > the IPSP-B cannot
> As you can see from the draft, sending two ASPUP has
> no problems with the above definition. But what we
> can remark is that only one is enough, since
> receiving the response from the other side (Asp-Up
> ack) gives the result that it is also UP and
> running.
[TOLGA] In my opinion, if possible it could be better
to have the same mechanisms, regardless whether  two
IPSPs are communciating, one IPSP and one SG, or one
ASP and one SG. Now for IPSP, if IPSP1 one sends ASPUP
and receives ASPUP-ACK, then ASP functionality of
IPSP1 (which has sent and received ASPUP) will inform
SG functionality of IPSP1 internally, so that it can
mark ASP2 (which corresponds to ASP functionality of
IPSP2) as INACTIVE. And before ASP of IPSP1 one can
inform SG of IPSP1 after receiving ASPUP-ACK, it also
should know, whetehr the peer was an IPSP or a SG.
Only if the peer is IPSP it should inform SG
functionality. Personally, I perefer an approach,
where the nature of the peer is totally transparent,
if possible of course.
> I think you mean sending a message for AS7 from
> IPSP1. If AS7 in IPSP2 is not in ASP-ACTIVE state,
> then traffic won't go through the wire. This means
> that traffic won't flow. You don't have to send two
> ASPACs every time that two AS located in different
> IPSPs want to communicate. They can be already
> activated. Therefore you should check it before
> sending data thru the wire. Does this answer your
> question... ?  :-)
[TOLGA] No, I don't mean sending a message for AS7
from IPSP1 :-) . What I couldn't understand is why
both IPSPs should be ASP-ACTIVE? It should be enough
if the receiving one is in ASP-ACTIVE state. As I
stated in the original message, the proposed IPSP
model does not pair ASs on two communciating IPSPs to
each other. Otherwise, maybe it could be meaningfull
to check whether the communication path between two
ASs is open in both directions or not.
> You are right. That's the philosophy. It's only
> having a little text to avoid confusion and
> misinterpretation in the key points.
> 
> Cheers // Javier.
> 
> > > ---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 Nov 2001 08:06:00 -0600

Tolga,

Tolga Asveren wrote:                                        (Fri, 16 Nov 2001 05:50:34)
> > start communication

To what SG is this ASPUP being sent?  Having an ASP
function in an IPSP talk to the SG function in the
other is absurd.

> flowing from IPSP1 to IPSP2.

Explain again how only one ASPAC is needed but two
ASPUPs are?

> For IPSP2 to IPSP1

I though we agreed that ASP and SG functionalities
were internal.

--brian

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

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

---

---

From: [email-masked]
Date: Fri, 16 Nov 2001 16:11:20 +0200

Hi Tolga,

> Please see comemnts below.

At this late date, my feeling is that unless someone
you can suggest specific text to be added to the documents,
we should stick with what we have.

br,
John

---

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 16 Nov 2001 06:24:48 -0800 (PST)

Brian,
Please see comments/questions below.

  Tolga
wrote:
> > > Tolga Asveren wrote:                       (Thu,
> 15
> > > Nov 2001 14:57:57)
> > > [snip]
> > > > > between two IPSPs.  When an IPSP recieves an
> ASP
> > > UP, it should mark
> > > > > the peer as ASP-INACTIVE and return an ASP
> UP
> > > Ack message, if it is
> > > > > with an M-ASP_UP confirmation primitive.  An
> ASP
> > > recieving an ASP UP
> > > > > already in the ASP_INACTIVE state, and
> informs
> > > Layer Management with
> > > > > an M-ASP_UP confirmation primitive.  If for
> any
> > > local reason (e.g.,
> > > > > management lock-out) the IPSP-B cannot
> respond
> > > with an ASP Up Ack
> > > > > message, it responds to an ASP Up message
> with
> > > an Error message with
> > > > communicating with another IPSP node or with a
> SG.
> > > What is bad about
> > > > SG/ASP case. Otherwise, we need to know,
> whether
> > > our peer is another
> > > > IPSP or a SG. 
> > > 
> > > We should leave this as either IPSP able to
> issue
> > > ASPUP.
[TOLGA] But then who is sending ASPUP to who, if it is
not sent by ASP functionality of IPSP1 to SG
functionality of IPSP2?
> > > > > Either of the IPSPs can initiate
> communication.
> > > When an IPSP
> > > > > recieves an ASP Active, it should mark the
> peer
> > > as ASP-ACTIVE and
> > > > > return an ASP Active Ack message, if it is
> not
> > > already in the
> > > > > ASP-ACTIVE state. An ASP recieving an ASP
> Active
> > > Ack message should
> > >                          ^^^
> > > > > state.  Both IPSPs SHOULD be in the
> ASP-ACTIVE
> > > state before traffic
> > > > > can start to flow.
> > > 
> > > > whether IPSP2 is active for AS7.  But what is
> the
> > > reson behind waiting
> > > Double ASPACs are not required to an SG.  It
> sounds
> > > like you are asking
> > > If you want to truly parallel the AS/SG
> operation,
> > > only on ASPUP is
[TOLGA] For only flowing traffic from IPSP1 to IPSP2
only one ASPUP (from IPSP2 to IPSP1)and one ASPAC
(from IPSP2 to IPSP1)is necessary. Interface between
ASP of IPSP1 and SG of IPSP1 is internal, and there we
don't need RKs. Everything is sent directly from ASP
to SG via the internal interface.
> I though we agreed that ASP and SG functionalities
[TOLGA] My understanding was that the interface
between them is internal. Seeing them as separate
entities from protocol point of view will enable 
nodes not to have to know whether their peer are IPSPs
or SGs.
> > > destination to which it is sending; however,
> that
> > > could be accomplished
> > > with SNMM and has nothing to do with the IPSP
> peer
> > > being "active".
> > > 
> > > So, essentially, once the IPSP receives ASPAC
> Ack it
> > > can send traffic to
> > > destinations that it knows to be available. 
> This 
=== message truncated ===

---

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 16 Nov 2001 06:27:54 -0800 (PST)

Hi John,

  Tolga

> we should stick with what we have.
[TOLGA] Personally I have no problem, that the current
proposal is put to draft10. But should this prevent us
to discuss further to refine it for draft11? And in
fact, what I want to say is, that almost no change is
necessary to the document, just a sample
configuration.

---

---

From: [email-masked]
Date: Fri, 16 Nov 2001 16:30:18 +0200

Hi Tolga

> necessary to the document, just a sample

M3UA & SUA should be sent to the area directors to be considered
for IETF last call.  With any luck, there won't be any more 
drafts!

John

---

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 16 Nov 2001 06:36:48 -0800 (PST)

Hi Gery,

   Tolga

> as traffic distribution is hidden from the network.
[TOLGA] Why is traffic distribution hidden from the
network? An IPSP can have associations to multiple
IPSPs, where for different RKs, it wants to use
different ones.
> [mailto:[email-masked]]
> SG. What is bad about
> > > [TOLGA] Again why not to make it the same like
> in SG/ASP 
> > > case? Why do
> meaningfull 
> > > to check
> the reson 
> > > behind waiting
> sounds like you 
> [email-masked]

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 16 Nov 2001 15:37:44 +0100

Hi Tolga,

IMO sending of ASPAC between IPSPs is irrelevant, ASP
registration/activation is internal to the IPSP, and communication between
IPSPs is the same as between SGs. That is, when SCTP association is up, an
after a single ASPUP-Ack exchange, traffic can be sent back and forth.

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: vrijdag 16 november 2001 15:07
To: sigtran
Subject: RE: IPSP Text (take 3?)

Javier,

   Tolga

---

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 16 Nov 2001 15:45:55 +0100

Hi, 

I can live with almost all these changes. Only one comment below. 

On the other hand, I think having the text included in not harmful at all. It could clarify things to other people reading the draft for the first time....

> Sent: Friday, November 16, 2001 12:07 PM
> To: sigtran

Question: How can an IPSP handle traffic if it is not in ACTIVE state? Read the definition of ACTIVE state and you'll realise that it is the only possibility that traffic can flow... IMO that statement is true. 

Therefore Brian's statement has to be slightly modified... Once an IPSP receives ASPAC Ack it can send traffic to destinations that it knows to be available IF AND ONLY IF that IPSP is in the ACTIVE state.  :-D

This means either the IPSP has informed that the implicated AS is active before, OR it has to do it after receiving ASPAC Ack. This is performed sending the other ASPAC. Otherwise, the peer (acting symmetrically) can not know that this IPSP is ready to deal with traffic. 

Cheers // Javier.

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 16 Nov 2001 16:00:53 +0100

Hi, 

I would just like to clarify some ideas...

Probably it could be good to forget what an IPSP is composed of. Simply think that we have an SS7 application within the IP network and this application is over M3UA. 

How does M3UA fulfill the needs of the SS7 applications? Take into account that the SS7 application is keeping the use of SS7 addressing parameters. 

Therefore SS7 addressing parameters needs to be used in IP to IP communication as well. How to deal with them? In the same way as M3UA does nowadays. Just using RK and RC concepts. 

How can we deal with several ASs served by the same IPSP? Same answer. 

How to deal with traffic mode types? With ASPTM. You can have several IPSPs serving an AS and use a loadsharing/override traffic policy... It's not good to limit this.

How can you monitor the state of the peer and inform of your own state to the others? With ASPTM. 

You can have an IPSP up and only active for some RK/RC/AS that you desire and not for the others... how to deal with it? ASPTM is used for that purpose as well. It is a good way to perform policy.

And in the following the same reasoning, IPSP can OPTIONALLY use the REG procedures to avoid some static configuration. 

Cheers // Javier.

> Sent: Friday, November 16, 2001 3:25 PM
> To: sigtran
> Cc: [email-masked]
> > in

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 16 Nov 2001 16:10:43 +0100

Hi Tolga,

This approach requires double-ended REG and ASPTM, and would require a
distinction between SG and IPSP. The model you are describing is exactly the
ASP-SG case. As the model stands, REG and Activation is done in ASP->SGP
direction (with possible SGP-TMT sent back in a REG_Ack from SGP).

For each RK, your IPSP may look different however, so I'd say IPSP is a
logical concept combining AS (pool of ASPs configured/registered for the RK)
and SG (pool of SGPs providing the connectivity for the AS, and have thus
received the REG/ASPACs for this RK).

Communication between 2 IPSPs reduces to communication between 2 SGs, not
even ASPUP would be required. As such, IPSPs present a network element view
manageable by existing SS7 network management procedures (MTP, SCCP) and
supported by SNMM. Finer management procedures (e.g. GT range) are useful on
the ASP-SGP interface, but deemed unviable outside this scope by the WG
(high additional cost => having to know each remote AS status, low
additional value => routing along the way (transfer/relay on SGs) will look
for available IPSPs anyway instead of burdening the application with it, and
some are best left to the applications themselves, e.g. ISUP CIC
management).

Also this view requires close to no adaptations to the xUA protocols, just
clear explanation of the model !

Opinions/comments ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: vrijdag 16 november 2001 15:37
To: sigtran
Subject: RE: IPSP Text (take 3?)

Hi Gery,

   Tolga

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 16 Nov 2001 16:12:52 +0100

Hi Gery, 

Take a look to the definition of IPSP in the SUA or M3UA draft. You'll realise that it is a little bit different to what you states below....  :-)

Cheers // Javier.

> From: Verwimp Gery [mailto:[email-masked]]
> Sent: Friday, November 16, 2001 4:11 PM
> To: sigtran

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 16 Nov 2001 16:38:44 +0100

Hi Javier,

What, we did include double-ended approach then ? Well, exchange the "as it
stands" by "my interpretation".

But with the draft's definition, ASPTM are still insufficient (congestion ?)
and the SNMM are impossible to place without an SS7 overlay ...

Anyway, comments on my interpretation ?

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Javier Pastor-Balbas (ECE)
[mailto:[email-masked]]
Sent: vrijdag 16 november 2001 16:13
To: sigtran
Subject: RE: IPSP Text (take 3?)

Hi Gery, 

Take a look to the definition of IPSP in the SUA or M3UA draft. You'll
realise that it is a little bit different to what you states below....  :-)

Cheers // Javier.

---

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 16 Nov 2001 17:08:58 +0100

Hi Javier,

See comments below ...

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Javier Pastor-Balbas (ECE)
[mailto:[email-masked]]
Sent: vrijdag 16 november 2001 16:01
To: sigtran
Subject: RE: IPSP Text (take 3?)

Hi, 

Probably it could be good to forget what an IPSP is composed of. Simply
think that we have an SS7 application within the IP network and this
application is over M3UA. 

How does M3UA fulfill the needs of the SS7 applications? Take into account
that the SS7 application is keeping the use of SS7 addressing parameters. 

Therefore SS7 addressing parameters needs to be used in IP to IP
communication as well. How to deal with them? In the same way as M3UA does
nowadays. Just using RK and RC concepts. 

How to deal with traffic mode types? With ASPTM. You can have several IPSPs
serving an AS and use a loadsharing/override traffic policy... It's not good
to limit this.

[GV] : Traffic policy is a configuration/registration concern. Changing
traffic policy changes the RK/RC. It brings about a lot of issues when
trying to solve this with ASPTM (point of the SUA bake**f).

How can you monitor the state of the peer and inform of your own state to
the others? With ASPTM. 

[GV] : No audit/congestion procedures present yet in ASPTM ... only
active/inactive. What about SNMM procedures ?

You can have an IPSP up and only active for some RK/RC/AS that you desire
and not for the others... how to deal with it? ASPTM is used for that
purpose as well. It is a good way to perform policy.

And in the following the same reasoning, IPSP can OPTIONALLY use the REG
procedures to avoid some static configuration. 

[GV] : Double-ended ASPAC is required and assumes RCs for each direction.
That's not clear in the draft yet.

Cheers // Javier.

---

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 16 Nov 2001 17:03:49 +0100

Hi Gery, 

I send you more comments below...

> Sent: Friday, November 16, 2001 4:39 PM
> To: sigtran
> What, we did include double-ended approach then ? 

It's been always there: two SS7 applications, same needs in both ends.

> Well, 
> exchange the "as it

Do you mean network congestion? It's point to point... And there you can control it with the SCTP mechanisms.

> and the SNMM are impossible to place without an SS7 overlay ...
Use the ASPTM that has more granularity... (more about this below)

> Anyway, comments on my interpretation ?
I don't agree on that. IPSP can serve different ASs.

> > Communication between 2 IPSPs reduces to communication 
> > between 2 SGs,

Don't agree either. It is possible to solve the problem with a lot of approaches, but if you think about the mail I sent before trying to clarify, you realize that you need to cover the problem in the same way (with the same philosophy) as you do in the rest of the draft. The core is that IPSP is an application within the IP network. No SG there in any case. We have to forget the internal composition of IPSP, as Lyndon says. Just think it as an application "process" in the IP network that uses M3UA to communicate with another IPSP. You have to be able to use the same procedures as you use in the rest of the M3UA draft. You have to keep it open in order to allow different traffic modes, registration (optionally). What ASPSM and ASPTM offers you (as in the ASP-SGP scenario) is more flexibility. Two reasons to include them: follow the same basis and not constraining things.

> > not
> > even ASPUP would be required.

You can think the same for ASP-SGP... But it's not good to change so many things when 21st is the cutoff date...

> > As such, IPSPs present a 
> > network element view
> > supported by SNMM.

You can perfectly deal with it using ASPTM. SNMM has been only thought as a translation of SS7 procedures for the case where interworking is needed. Imagine that an IPSP is serving two ASs that represent the same SPC and that one of those AS has a RK that handles only some CICs and the another bunch of CICs  are handled by another AS, how could you inform to a peer that one of those ASs is down? The solution is using M3UA tools: RC/RK/AS concepts. No SNMM messages are useful for that because in IP we have defined from the beginning more granularity.

Cheers // Javier.

> > Finer management procedures (e.g. GT 
> > range) are useful on

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Fri, 16 Nov 2001 17:16:58 +0100

Hi Gery, 

Comments below...

> Sent: Friday, November 16, 2001 5:09 PM
> To: sigtran
[snip]
> trying to solve this with ASPTM (point of the SUA bake**f).

When you activate your AS with ASPAC, you can also mention traffic mode.
[snip]

> That's not clear in the draft yet.
I think you should talk to John L. about this issue. In M3UA will be reflected in the examples section I sent in the 2nd approach.

Cheers // Javier.

---

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 16 Nov 2001 09:39:55 -0800

Also some comments, esp. if they do not affect the
main technical content of the protocol, can be handled
in IETF Last Call.

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 16, 2001 6:30 AM
To: sigtran
Subject: RE: IPSP Text (take 3?)

Hi Tolga

John

---

---

---

From: [email-masked]
Date: Fri, 16 Nov 2001 10:29:44 -0800

Hi Gery,

   Tolga

> From:   Verwimp Gery <[email-masked]>
> Sent:   Friday, November 16, 2001 10:19 AM
[TOLGA] I agree that it is exactly ASP-SG case, and this is my intention,
to handle point-to-point communication between two nodes in IP domain
without changing existing protocol at all. Using one ASPUP between IPSPs
brings a change to the ASP state machine, and I just want that it stays the
same like in ASP/SG case, so I propose to use double ASPUP, one in each
direction. Like this, no change is necessary on the state machines. It
won't require distinction between SG and IPSP.
> between 2 SGs, not
[TOLGA] Communication between SGs is something needed, I totally agree for
this. But I also think communicating point-to-point between two nodes is
another option. Both of them should be possible and in fact point-to-point
case is already possible with the existing protocol.
> clear explanation of the model !
[TOLGA] In general I agree with your view of SG-to-SG communication. Maybe
some minor modifications are necessary to the protocol. My impression was
that SG-to-SG case will be defined in an extension draft (?).
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: [email-masked]
Date: Fri, 16 Nov 2001 10:44:54 -0800

Hi Gery,

   Tolga

> Sent:   Friday, November 16, 2001 11:19 AM
[TOLGA] My opinion is, like in ASP/SG case a SG should control an entire
SPMC to be able to give a consistent view to the outside world, in IPSP
case, one IPSP should also control a SPMC as a whole. Here, it should be
noted that this SPMC consist of remote ASs, not local ASs, because SG
functionality of IPSP should have this control and ASs from which it is
receiving ASPACs (which are forming the SPMC controlled by SG
functionality) are residing on other IPSPs. If the configuration is done
likte this, then SNMM can be used also in the proposed IPSP model. Again,
everything is the same like in SG/ASP case.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 16 Nov 2001 15:52:41 -0600

Tolga,

Tolga Asveren wrote:                                        (Fri, 16 Nov 2001 06:24:48)
> not sent by ASP functionality of IPSP1 to SG

Here it appears that you are saying the interface from
ASP to SG is exposed in both directions.

> to SG via the internal interface.

Here you are saying that one interface is internal.

> nodes not to have to know whether their peer are IPSPs

I agree with Gery.  If interface from ASP to SG is
internal, SG-SG communication is all that is needed.
Exposing the ASP/SG interface internal to the IPSP is
fraught with problems and brings no value.

--brian

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

---

---

From: Tolga Asveren <[email-masked]>
Date: Fri, 16 Nov 2001 17:05:26 -0800 (PST)

Brian,

   Tolga

> > > > > [TOLGA] If the proposed model is so similar
to
> > the
> > > > regular SG/ASP
> > > > > case, why not to make it the same?  Let's
have
> > > > double ASPUPs. Like
> > > > > it, just one more message and we will keep
the
> > > > logic same like in
> > > [TOLGA] You are rigth, if we have one ASP and
one
> > SG,
> > > So, if there are two IPSPs there are also two
SGs
> > and
> > > between two ASPs, the protocol behaeves
different
> > than

Here it appears that you are saying the interface from
ASP to SG is exposed in both directions.
[TOLGA] Interface between ASP and SG functionality of
an IPSP is internal (that is what my understanding of
the proposed model) Interface between ASP
functionality of IPSP1 to SG functionality of IPSP2 is
not.

> > > > > could have a pairing between ASs in both
IPSPs
> > > > (for example AS1 on
> > > > > IPSP1 is communicating with AS7 on IPSP2)
then
> > > > before sending a
> > > > required and only one ASPAC is require to
start
> > > > traffic.
> > > Traffic from IPSP2 to IPSP1 belongs to another
RK
> > and
> > > currently there is no way in the proposed model
to
> > RKs

[TOLGA] As I stated earlier, this interface is local
and internal.
> > 
> > > For IPSP2 to IPSP1
> > > direction we need ASPAC from IPSP2 to IPSP1.
Also,
> > it
> > > should be noted, when I proposed double ASPUP,
it
> > is
> > > IPSP2. Now, IPSP1 cans end traffic to IPSP2.
There
> > is
> > > received by SG functionality of IPSP2. My
opinion
> > is

I agree with Gery.  If interface from ASP to SG is
internal, SG-SG communication is all that is needed.
Exposing the ASP/SG interface internal to the IPSP is
fraught with problems and brings no value.
[TOLGA] I also support the idea of defining SG-to-SG
communication, but I don't think that this should
prevent people to have configurations as the proposed
IPSP model. Afterall, it is just another configuration
of the regular SG/ASP case. If there is SG-to-SG
communication, I don't think there is a need to put
ASP and SG functionality in a box and use an internal
interface between them. We can use the M3UA protocol
itself between ASP and SG. In such a case, there is
also no need to have a one SG for one ASP. Multiple
ASPs can be served by one SG, like in the regular
SG/ASP case, messaging between them will stay the
same. At least this is my understanding of SG-to-SG
communication.

--brian

---

---

From: [email-masked]
Date: Mon, 19 Nov 2001 11:21:26 +0530

Hi all
     Who will trigger the ASP-UP message? Will it be the ASP functionality
in IPSP1? If yes, then whom will it send it to - Does it send it to the SG
functionality in IPSP-2? If not, how does the ASP-UP message flow?

ASP/IPSP-1        SGP/IPSP-1                            SGP/IPSP-2
ASP/IPSP-2
        |----ASP-UP---->|                                               |
|
        |                            |  --------ASP-UP-->              |
|
        |                            |  <---ASP-UP ACK-              |
|
        |                            |
|                           |

Regards
Vaibhav

----- Original Message -----
From: "Tolga Asveren" <[email-masked]>
To: "sigtran" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, November 17, 2001 6:35 AM
Subject: Re: IPSP Text (take 3?)

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

---

---

From: [email-masked]
Date: Mon, 19 Nov 2001 09:30:55 -0500

Hi,

My interpretation is that it is sent by ASP/IPSP1 to SG/IPSP2 directly.

  Tolga

> From: [email-masked]
> Sent: Monday, November 19, 2001 12:50 AM
>         |----ASP-UP---->|
>         |                            |  --------ASP-UP-->
>  - InterScan_Disclaimer.txt
>
> ---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Nov 2001 08:43:20 -0600

Tolga,

[email-masked] wrote:               (Mon, 19 Nov 2001 09:30:55)
> My interpretation is that it is sent by ASP/IPSP1 to SG/IPSP2 directly.

Is not the ASPUP from ASP/IPSP2 to SG/IPSP2 internal then?  Would
not only one ASPUP be required?

--brian

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

---

---

From: [email-masked]
Date: Mon, 19 Nov 2001 07:02:15 -0800

Hi Brian,

   Tolga

> From:   "Brian F. G. Bidulock" <[email-masked]>
> Sent:   Monday, November 19, 2001 9:49 AM
> To:     [email-masked]
> Cc:     sigtran <[email-masked]>
[TOLGA] I also interpret the ASPUP from ASP/IPSP2 to SG/IPSPS2 internal.
So, that one ASPUP (from ASP/IPSP1 to SG/IPSP2) is enough is correct, but
this will open the path for management messages only in one direction
between IPSPs . Still ASP/IPSP2 can't receive management messages from
SG/IPSP1. As I said this is just my interpretation, in the proposed IPSP
text, one ASPUP opens the path for management messages in both of the
directions. This changes the ASP state machine, depending on whether the
peer a M3UA node is communicating is an IPSP or SG. I prefer a solution,
where no state machine changes are necessary and that a node is unaware of
the nature of its peer. And when 2 ASPUPs are necessary, everything is
exactly the same like in SG/ASP case. One has 2 ASPs and 2 SG. Just the
interface between ASP1 and SG1 and between ASP2 and SG2 are internal, whihc
is an implementation issue.
> > >         |                            |  <---ASP-UP ACK-
> [email-masked]

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Nov 2001 09:25:49 -0600

Tolga,

[email-masked] wrote:                        (Mon, 19 Nov 2001 07:02:15)
> is an implementation issue.

Are you saying that ASP/IPSP1 treats SG/IPSP1 and SG/IPSP2 as multiple
SG configuration?  That is, ASP/IPSP1 must keep track of SNMM (and even
DRST) from each SG?

Multiple SG configuration is where SG function moves into the ASP.
What is the diffence between ASP/IPSP always keeping track of SNMM
from multiple SGs and SG-SG communication?

--brian

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

---

---

From: [email-masked]
Date: Mon, 19 Nov 2001 07:46:44 -0800

Brian,

   Tolga

> Sent:   Monday, November 19, 2001 10:35 AM
[TOLGA] No, ASP/IPSP1 does not need to treat SG/IPSP1 as a different SG. It
is even not aware of its existence as a SG. The local interface between
ASP/IPSP1 and SG/IPSP1 is only used, when ASP/IPSP1 wants to send a
message. It just dumps everything to the local interface. Then SG/IPSP1
takes care of it. But there is no RK analysis on ASP/IPSP1, when it wants
to send messages. Everyhting goes to local interface.
Again I am for SG-to-SG communication, but what I understand from current
IPSP approach is that it is exactly the same like SG/ASP case (except
opening the path for management messages with one ASPUP, which I hope could
be changed), just a sample configuration. It does not break anything in the
protocol. I agree, not for everybody it is the best choice for their
network, but  there can be cases, where people prefer this solution.

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Nov 2001 15:57:29 -0600

Tolga,

[email-masked] wrote:                        (Mon, 19 Nov 2001 07:46:44)
> network, but  there can be cases, where people prefer this solution.

I think your view of this IPSP-IPSP operation is rather different from
Javier's and Dennis'.  The JD approach has the ASP/IPSP1 sending messages
after RK analysis to SG/IPSP2.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Nov 2001 19:48:26 -0600

Tolga,

Tolga Asveren wrote: (Mon, 19 Nov 2001 16:30:22)
> > 
> > Then should we remove "IPSP Considerations" from
> > the draft altogether (leave it for extension or
> > descriptive appendix only)?
> > 
> > For SG-SG communication the only thing that appears
> > missing from the drafts is some way for SG's to
> > ping-pong each other after the association is up.
> > But even there a single-ended ASPUP would do.  So,
> > SG-SG communication could be addressed in the same
> > extension or appendix.
> > 
> > Does that make sense?
>
> [TOLGA] In my opinion, IPSP shouldn't be mentioned
> more than a sample configuration in the draft and of
> course the change to ASP state machine should be
> removed, so that everything stays the same like in
> regular SG/ASP case. 
>
> Unfortunately there wasn't too much oportunity to
> discuss about SG-to-SG case. For example, how will
> the mechanism on a SG decide , whether a message
> should be forwarded to an ASP or to a SG? Will there
> be a two level RK analysis mechanism?  

Well, I think the SG would just use similar routing
mechanisms and state machines as are present in the
SS7 stack for SS7 SG-SG communication today.  Whether
to deliver to an ASP is the same discrimination
function present in the SS7/NIF today, whether to
delivery to an SG is the same routing function present
in the SS7/NIF today.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Nov 2001 18:14:49 -0600

Tolga,

Tolga Asveren wrote:                                        (Mon, 19 Nov 2001 15:49:51)
> > Tolga Asveren wrote: (Mon, 19 Nov 2001 15:25:36)
> > 
> > > > 
> > > > I think your view of this IPSP-IPSP operation
> > > > is rather different from Javier's and Dennis'.
> > > > The JD approach has the ASP/IPSP1 sending
> > > > messages after RK analysis to SG/IPSP2.
> > 
> > > [TOLGA] There are two approaches one can choose,
> > > either not to do RK analysis on ASP or not to
> > > make RK analysis on SG of an IPSP. In the
> > > approach I was talking about RK analysis was done
> > > on SG functionality, ASP was sending everyhting
> > > to SG (I believe this is what Javier was
> > > proposing, his document says "IPSP sends data as
> > > SGP and receives as ASP"). The other approach is,
> > > IPSP receives as a SGP and sends as an ASP. In
> > > this case, SG will send everyhting it receives
> > > via internal interface to ASP, without doing a RK
> > > analysis.  When ASP is sending messages , it does
> > > RK analysis and selects one of the SGs of other
> > > IPSPs or maybe a regular SG. 
> > 
> > Is there any reason not to allow/describe both
> > aproaches?
>
> [TOLGA] IMHO no, both of them are just a sample
> configuration of regular SG/ASP case. So, both of
> them are allowed.

Then should we remove "IPSP Considerations" from the
draft altogether (leave it for extension or descriptive
appendix only)?

For SG-SG communication the only thing that appears
missing from the drafts is some way for SG's to
ping-pong each other after the association is up. But
even there a single-ended ASPUP would do.  So, SG-SG
communication could be addressed in the same extension
or appendix.

Does that make sense?

--brian

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

---

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 19 Nov 2001 15:25:36 -0800 (PST)

resending.....

Brian,

  Tolga

wrote:
> > > [email-masked] wrote:                    
>    (Mon, 19
> > > Nov 2001 07:02:15)
> > > > Hi Brian,
> > > >
> > > > > [email-masked] wrote:              
> (Mon, 19 Nov
> > > 2001 09:30:55)
> > > > > > Hi,
> > > > > >
> > > > > > My interpretation is that it is sent by
> ASP/IPSP1 to
> > > > > SG/IPSP2 directly.
> > > SG configuration?  That is, ASP/IPSP1 must keep
> track of SNMM
> > > (and even
> > > DRST) from each SG?
[TOLGA] There are two approaches one can choose,
either not to do RK analysis on ASP or not to make RK
analysis on SG of an IPSP. In the approach I was
talking about RK analysis was done on SG
functionality, ASP was sending everyhting to SG (I
believe this is what Javier was proposing, his
document says "IPSP sends data as SGP and receives as
ASP"). The other approach is, IPSP receives as a SGP
and sends as an ASP. In this case, SG will send
everyhting it receives via internal interface to ASP,
without doing a RK analysis. When ASP is sending
messages , it does RK analysis and selects one of the
SGs of other IPSPs or maybe a regular SG. 
> > > > > > >      Who will trigger the ASP-UP
> message? Will it be the ASP
> > > > > > > functionality
> > > > > > > in IPSP1? If yes, then whom will it send
> it to - Does it send
> > > > > > > it to the SG
> > > > > > > functionality in IPSP-2? If not, how
> does the ASP-UP
> > > message flow?
> > > > > > >
> > > > > > > ASP/IPSP-1        SGP/IPSP-1
> > >   SGP/IPSP-2
> > > > > > > ASP/IPSP-2
> > > > > > >         |----ASP-UP---->|
> > > > > > >           |
> > > > > > > |
> > > > > > >         |                            | 
> --------ASP-UP-->
> > > > > > >          |
> > > > > > > |
> > > > > > >         |                            | 
> <---ASP-UP ACK-
> > > > >            |
> > > > > > > |
> > > > > > >         |                            |
> > > > > > > |                           |
> > > > > > >
> > > > > > > Regards
> > > > > > > Vaibhav
> > > > > > >
> > > > > > >
> > > > > > > > > > > > > > A single ASP UP and ASP UP
> Ack is needed
> > > > > > > > to
> > > > > > > > > > > > start communication
> > > > > > > > > > > > > > between two IPSPs.  When
> an IPSP recieves
> > > > > > > > an
> > > > > > > > > > ASP
> > > > > > > > > > > > UP, it should mark
> > > > > > > > > > > > > > the peer as ASP-INACTIVE
> and return an ASP
> > > > > > > > > > UP
> > > > > > > > > > > > Ack message, if it is
> 

---

---

From: [email-masked]
Date: Mon, 19 Nov 2001 15:28:49 -0800

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 19 Nov 2001 17:41:26 -0600

Tolga,

> > 
> > I think your view of this IPSP-IPSP operation is rather
> > different from Javier's and Dennis'.  The JD approach has
> > the ASP/IPSP1 sending messages after RK analysis to
> > SG/IPSP2.

> [TOLGA] There are two approaches one can choose, either not to
> do RK analysis on ASP or not to make RK analysis on SG of an
> IPSP. In the approach I was talking about RK analysis was done
> on SG functionality, ASP was sending everyhting to SG (I
> believe this is what Javier was proposing, his document says
> "IPSP sends data as SGP and receives as ASP"). The other
> approach is, IPSP receives as a SGP and sends as an ASP. In
> this case, SG will send everyhting it receives via internal
> interface to ASP, without doing a RK analysis. When ASP is
> sending messages , it does RK analysis and selects one of the

Is there any reason not to allow/describe both aproaches?

--brian

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

---

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 19 Nov 2001 15:49:51 -0800 (PST)

Brian,

wrote:
> either not to
> document says
[TOLGA] IMHO no, both of them are just a sample
configuration of regular SG/ASP case. So, both of them
are allowed.

---

---

From: Tolga Asveren <[email-masked]>
Date: Mon, 19 Nov 2001 16:30:22 -0800 (PST)

Brian,

  Tolga
wrote:
> But

---