Subject: RE: [Sigtran] Query: IPSP-SE definition

From: "Soni Goel" <[email-masked]>
Date: Tue, 22 Nov 2005 03:31:35 -0800

Hi, 

In one of the earlier mails , I saw the following configuration being discussed. I have related query.

It is an IPSP-IPSP Single Ended communication. We have AS1 served by IPSP1. IPSP2 and IPSP3 are in the same
Application Server (AS2). Every IPSP is operating in Override traffic mode, where IPSP1 and IPSP2 are
configured to be in the ASP-ACTIVE state and IPSP3 is acting as backup.

   ________           ________     ________ 
  |        |         |        |   |        |
  |  AS1   |         |  AS2   |   |  AS2   |
  | PC = X |         | PC = Y |   | PC = Y |
  |________|         |________|   |________|
      |                  |            |     
   ___|____           ___|____     ___|____ 
  |        |         |        |   |        |
  | IPSP1  |         | IPSP2  |   | IPSP3  |
  |  IP@1  |         |  IP@2  |   |  IP@3  |
  |Override|         |Override|   |Override|
  |(Active)|         |(Active)|   |(Backup)|
  |________|         |________|   |________|
       |                  |            |    
       |__________________|____________|    

As per the RFC -
"In the case of an Override mode AS, reception of an ASP Active message at an SGP causes the (re)direction of all traffic for the AS to the ASP that sent the ASP Active message.  Any previously active ASP in the AS is now considered to be in state ASP-INACTIVE and SHOULD no longer receive traffic from the SGP within the AS.  The SGP   or IPSP then MUST send a Notify message ("Alternate ASP_Active") to the previously active ASP in the AS, and SHOULD stop traffic to/from that ASP. ""

In the following scenario, IPSP1 on receiving ASP Active Ack from IPSP2, redirects all the traffic to IPSP2 and considers IPSP3 as Inactive. Isn't this contradicting with the RFC paragraph (stated above)? As per the RFC, the SGP or IPSP receiving ASP-Active message redirects the traffic and sends NTFY(Alt ASP-Act), not the IPSP receiving the ASP-Active Ack. 
If this is true, then if IPSP1 needs to use Override mode towards AS2 (consisting of IPSP2 and IPSP3), then ASP-Active messages must be initiated by IPSP2 and/or IPSP3, not by IPSP1.

 IPSP1                   IPSP2                   IPSP3
   |                        |                      |
   |-------------------ASP Active----------------->|
   |<----------------ASP Active Ack----------------|
   |                        |                      |
   |-------ASP Active------>|                      |
   |<------ASP Active Ack---|                      |
   |                        |                      |
   |----------------NTFY(Alt ASP-Act)------------> |
   |                        |                      | 

Thanks,
Soni

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]] 
Sent: Monday, November 21, 2005 2:56 AM
To: Soni Goel
Cc: [email-masked]
Subject: Re: [Sigtran] Query: IPSP-SE definition

Soni,

Soni Goel wrote:                           (Mon, 21 Nov 2005 01:18:13)
> Hi,
> 
> I have been following the IPSP-SE definition thread. As per the last 
> mail from Ken the sigtran team will be working on draft(s) for SE-IPSP 
> model and a SG-SG draft.
> 
> In the meantime, is there any consensus reached regarding the IPSP-SE 
> definition?

No, I don't think that there was any concensus.

> 
> If yes, can you please let me know which of the following definitions 
> are correct for IPSP-SE mode -

The matter is rather moot because the TM in the ASP Active Ack is just the same value that was present in the ASP Active.  As it stands, whichever view you take towards role modeling of IPSPs, the side sending ASP Active can inform the other about its intended traffic mode, but any traffic distribution method in the other direction will have to be provisioned.

It don't think that is such a great limitation: in a real world engineered network I would expect that traffic mode (or distribution method, if you prefer) would be provisioned on both sides.

--brian

> 
> 1) In IPSP-SE model, the IPSP sending ASPAC acts as an ASP. The IPSP 
> receiving ASPAC acts as an SGP.  When acting like an SGP, the peer 
> IPSP can distribute traffic in accordance with the way that an ASP 
> distributes messages to the SGP that make up an SG.  The SE-IPSP 
> acting in SGP mode does not require an "ASP Traffic Mode".
> 
> OR,
> 
> 2) SE-IPSP is an IPSP not an ASP and not an SGP. So, the traffic mode 
> is required to be exchanged both ways. So if IPSP1 sends ASPAC message 
> and IPSP2 replies with ASPAC-Ack message. IPSP2 can update IPSP1 about 
> the traffic mode (in ASPAC-Ack message) to be used for message 
> distribution towards IPSP2. This will enable both IPSP1 and IPSP2 to 
> use same override/loadshare mode towards eahc other, OR, both IPSP1 
> and IPSP2 can use different modes.
> 
> Thanks,
> Soni
> 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005
>  
> 
> _______________________________________________
> Sigtran mailing list
> [email-masked] https://www1.ietf.org/mailman/listinfo/sigtran

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

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.859 / Virus Database: 585 - Release Date: 2/14/2005

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 22 Nov 2005 04:45:04 -0700

Soni,

Soni Goel wrote:                                                                      (Tue, 22 Nov 2005 03:31:35)
> It is an IPSP-IPSP Single Ended communication. We have AS1 served by
> IPSP1. IPSP2 and IPSP3 are in the same Application Server (AS2). Every
> IPSP is operating in Override traffic mode, where IPSP1 and IPSP2 are
> "In the case of an Override mode AS, reception of an ASP Active
> message at an SGP causes the (re)direction of all traffic for the AS
> to the ASP that sent the ASP Active message.  Any previously active
> ASP in the AS is now considered to be in state ASP-INACTIVE and SHOULD
> no longer receive traffic from the SGP within the AS.  The SGP   or
> IPSP then MUST send a Notify message ("Alternate ASP_Active") to the
> previously active ASP in the AS, and SHOULD stop traffic to/from that
> ASP. ""
> 
> In the following scenario, IPSP1 on receiving ASP Active Ack from
> IPSP2, redirects all the traffic to IPSP2 and considers IPSP3 as
> Inactive. Isn't this contradicting with the RFC paragraph (stated
> above)? As per the RFC, the SGP or IPSP receiving ASP-Active message
> redirects the traffic and sends NTFY(Alt ASP-Act), not the IPSP
> receiving the ASP-Active Ack.  If this is true, then if IPSP1 needs to
> use Override mode towards AS2 (consisting of IPSP2 and IPSP3), then
> ASP-Active messages must be initiated by IPSP2 and/or IPSP3, not by
> IPSP1.

No, you should follow the RFC as above.

Let me make one change to your diagram:

   IPSP1                   IPSP2                   IPSP3
     |                        |                      |
     |-------------------ASP Active----------------->|
     |<----------------ASP Active Ack----------------|
     |                        |                      |
     |-------ASP Active------>|                      |
     |<------ERR[Mgmt Blking]-|                      |
     |                        |                      |
     |                        |                      | 

A standby IPSP need not accept an ASP Active from an IPSP.

--brian

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

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 22 Nov 2005 08:09:30 -0500

Soni,

It is obvious that certain clarifications are necessary for the existing
text in the document regarding IPSP, but still please see below for my 2
cents about how it is supposed to work.

   Thanks,
   Tolga

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Soni Goel
> Sent: Tuesday, November 22, 2005 6:32 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sigtran] Query: IPSP-SE definition
>
>
> Hi,
>
> It is an IPSP-IPSP Single Ended communication. We have AS1 served
> by IPSP1. IPSP2 and IPSP3 are in the same
> message at an SGP causes the (re)direction of all traffic for the
> AS to the ASP that sent the ASP Active message.  Any previously
> active ASP in the AS is now considered to be in state
> ASP-INACTIVE and SHOULD no longer receive traffic from the SGP
> within the AS.  The SGP   or IPSP then MUST send a Notify message
> ("Alternate ASP_Active") to the previously active ASP in the AS,
> and SHOULD stop traffic to/from that ASP. ""
>
> above)? As per the RFC, the SGP or IPSP receiving ASP-Active
> message redirects the traffic and sends NTFY(Alt ASP-Act), not
> the IPSP receiving the ASP-Active Ack.
> If this is true, then if IPSP1 needs to use Override mode towards
> AS2 (consisting of IPSP2 and IPSP3), then ASP-Active messages
> must be initiated by IPSP2 and/or IPSP3, not by IPSP1.
[TOLGA]If you interprete the current text literally, I agree with you that
is not very clear. OTOH, I don't see something conceptually wrong. The key
point is that for SE-IPSP mode of operation AS defines traffic at both ends,
it is not a cleint-server model like SGP/ASP communication. For that reason,
ASPAC and ASPAC-ACK usually have the same semantics from SE-IPSP processing
point of view.
> The matter is rather moot because the TM in the ASP Active Ack is
> just the same value that was present in the ASP Active.  As it
> stands, whichever view you take towards role modeling of IPSPs,
> the side sending ASP Active can inform the other about its
> intended traffic mode, but any traffic distribution method in the
> other direction will have to be provisioned.
>
> It don't think that is such a great limitation: in a real world
> engineered network I would expect that traffic mode (or
> distribution method, if you prefer) would be provisioned on both sides.
>
> --brian
>
> >