RE: Query: IPSP-SE definition

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 protected]] 
Sent: Monday, November 21, 2005 2:56 AM
To: Soni Goel
Cc: [email protected]
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 protected] https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[email protected]
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