Subject: IPSP text (2nd approach)

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 6 Nov 2001 19:19:52 +0100

Dear all, 

Here is the 2nd approach. Let's try to evolve it to the final one...

If you have others, please send them out and we can also discuss them. I'm wide open to whatever reaches consensus.

Cheers // Javier.

---
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: Tue, 6 Nov 2001 16:10:38 -0600

Javier,

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001 19:19:52)

> IPSP: Node that have a mixed functionality...
> --------------------------------------------
> 
> 
> As an SGP:
> 
> - when sending data msg to the other IPSP it does it in the same way an SGP
> sends a message to an ASP: including the RC that ASP got when registering
> its RK

Registration is an OPTIONAL procedure.  RC cannot be defined on the basis
of an OPTIONAL procedure.  The ASP never registered.  What RC value is sent
then?

--brian

> 
> - Receive and treat ASPTM, ASPSM and RRM in the same way as SGP, having
> status information of the other peer
> 
> 
> 
> As an ASP:
> 
> - Receive data messages and distribute them to the ASs in the same way ASP does it, using RC when more than one AS is present in the destination.
> 
> - Send ASPSM, ASPTM and RRM in the same way ASP does 
> 
> (This last point has the particularity that only one ASP-UP is needed. When an IPSP receives an ASPUP and sends back an ASPUP-Ack it does not need to send another ASPUP to the peer and can consider the peer as INACTIVE)
> 
> 
> 
> 
> 1.4.2.4 Message Distribution at the IPSP 
> 
> To support message distribution in an IPSP-A for messages to an IPSP-B in IPSP communication, IPSP-A should maintain the equivalent to a network address translation table. M3UA layer at IPSP-A should map the addressing parameters given by the local SS7 application over it to a valid RK. This could be accomplished by comparing these addressing parameters with the currently registered RK. These set of RKs has been either registered by remote IPSPs or configured statically. If a RK is found to match the addressing parameters, this Routing Key  could in turn map directly to an AS that is enabled by one or more IPSPs. These IPSPs (e.g. IPSP-B) provide dynamic status information regarding their availability, traffic handling capability and congestion to IPSP-A using various management messages defined in the M3UA protocol.  
> 
> The list of IPSPs in an AS is assumed to be dynamic, taking into account the availability, traffic handling capability and congestion status of the individual IPSPs in the list, as well as configuration changes and possible fail-over mechanisms. 
> 
> Normally, one or more IPSPs are active (i.e., currently processing traffic) in the AS but in certain failure and transition cases it is possible that there may be no active IPSP available.  Broadcast, load-sharing and backup scenarios are supported.
> 
> When there is no matching Routing Key entry at IPSP-A for an SS7 message coming from the local application, a default treatment MAY be specified.  Possible solutions are to provide a default AS at the AS-A that directs all unallocated traffic to a (set of) default AS(s), or to drop the message and provide a notification to layer management.  The treatment of unallocated traffic is implementation dependent.
> 
> At the receiving end IPSP-B have to distribute the incoming message to its local SS7 application. In the case it is serving more than one ASs, it would have to determine which one is the destination. In order to achieve it, IPSP-B should take into account the RC received within the DATA message sent by IPSP-A (it is compulsory to send RC when there are more than one remote AS activated in in the same peer), that is the RC that IPSP-B received as the response to the registration of the RK related with that specific AS, for the case of dynamic registration.
> 
> 
> 
> 
> 4.3.3. IPSP Considerations (ASP State Transition Diagram)
> 
> In the case where there exists IPSP communication, the ASP state diagram is slightly modified. This fact is due to the symmetry of the two nodes implied in the communication and the use of a unique ASP Up/ASP Down message to change between the ASP-DOWN and ASP-INACTIVE states.
> 
> 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 flow diagram for the AS-SG case is completely valid for the AS-AS communication
> 
> 
> 
> 4.3.4.1.2 IPSP Considerations  (ASPUP)
> 
> Only one pair of ASP Up and ASP Up ack messages is needed to consider that the two nodes that want to participate in a communication are in the ASP-INACTIVE state. The main purpose of the ASP-Up message is to inform to the other peer the availability of the local M3UA layer to deal with management messages. Then if a remote node responds with ASP Up ack upon the reception of ASP Up message, it can also be considered to be in the ASP-INACTIVE state, and therefore, it does not need to send back another ASP Up message to the other peer to inform of its state.
>     
> In the case of peer-to-peer IPSPs, either of the IPSPs (IPSP-A) may start operations by sending an ASP Up message to the remote peer (IPSP-B).  When the ASP Up message is received at IPSP-B and internally the remote IPSP-A is in the ASP-DOWN state and not considered locked-out for local management reasons, IPSP-B marks the remote IPSP-A in the state ASP-INACTIVE and informs Layer Management with an M-ASP_Up indication primitive.  IPSP-B returns an ASP-Up Ack message to IPSP-A.  IPSP-A moves IPSP-B to the ASP-INACTIVE state upon reception of an ASP Up Ack message, if 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)
>     
> Anyone of the IPSPs can initiate the communication. The initiating side (IPSP-A) sends an ASP Active message. Upon the reception of ASP Active message from the remote node, IPSP-B marks IPSP-A as ASP-ACTIVE and sends back ASP Active Ack.  Next, the other side (IPSP-B) of the signaling connection sends an ASP Active message, and the initiating side (IPSP-A) sends back with another ACTIVE ACK after moving ASP A to the ASP-ACTIVE state. Both IPSPs SHOULD reach the ASP-ACTIVE state before traffic start flowing.
> 
> 4.3.4.5.1 IPSP Considerations (ASPIA)
> 
> ASP-Inactive procedures work in the same way as ASP-Active. An IPSP can be considered in the ASP-INACTIVE state by a remote IPSP after an ASP Inactive message has been received from it. If a 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.
> 
> 
> 
> 4.3.4.6.1 IPSP Considerations (NTFY)
> 
> It works in the same way 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 belonging to an IPS.
> 
> 
> 
> 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. This fact means that for the establishment of a path between two IPSPs two registrations have to be performed, one per node.
> 
> Deregistration process is completely equivalent. A double deregistration process has to be performed if a path was previously established.
> 
> 
> 
> 
> 
> 
> 
> 5. Examples of M3UA Procedures
> 
> 5.1 Establishment of Association and Traffic between SGPs and ASPs
> 
> 5.1.1 Single ASP in an Application Server ("1+0" sparing),
> 
> 5.1.1.1 Single ASP in an Application Server ("1+0" sparing), No 
> Registration
> 
> This scenario shows the example M3UA message flows for the 
> establishment of traffic between an SGP and an ASP, where only one ASP 
> is configured within an AS (no backup).  It is assumed that the SCTP 
> association is already set-up. The sending of any DUNA/SCON messages by 
> the SGP is not shown but is similar to the case described in Section 
> 5.1.2.
> 
>              SGP                              ASP1
>               |                                |
>               |<-------------ASP Up------------|
>               |-----------ASP Up Ack---------->|
>               |                                | 
>               |<------- ASP Active(RCn)--------|  RC: Routing Context 
>               |-----ASP Active Ack (RCn)------>|      (optional)
>               |                                |
> 
> Note: If the ASP Active message contains an optional Routing Context parameter, The ASP Active message only applies for the specified RC value(s). For an unknown RC value, the SGP responds with an Error message.
> 
> 
> Adaptation to IPSP communication.
> 
> 
>             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)
>               |                                |
> 
> 
> 
> 
> Sidebottom et al                                             [Page 84]
> 
> Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
> 
> 5.1.1.2 Single ASP in Application Server ("1+0" sparing), Dynamic 
> Registration
> 
> This scenario is the same as for 5.1.1.1 but with the optional exchange 
> of registration information.  In this case the Registration is accepted 
> by the SGP.
> 
>              SGP                              ASP1
>               |                                |
>               |<------------ASP Up-------------| 
>               |----------ASP Up Ack----------->|
>               |                                |
>               |<----REGISTER REQ(RKn)----------|                               
>               |                                |                  
>               |----REGISTER RESP(RCn)--------->|   RK: Routing Key        
>               |                                |   RC: Routing Context    
>               |                                | 
>               |<------- ASP Active(RCn)--------| 
>               |-----ASP Active Ack (RCn)------>|
>               |                                |
> 
> Note: In the case of an unsuccessful registration attempt (e.g., 
> Invalid RKn), the Register Response message will contain an 
> unsuccessful indication and the ASP will not subsequently send an ASP 
> Active message.  
> 
> 
> Adaptation to IPSP communication.
> 
> Each IPSP has to register each RK that it wants to activate.
> 
> 
>             IPSP-A                           IPSP-B
>               |                                |
>               |<------------ASP Up-------------| 
>               |----------ASP Up Ack----------->|
>               |                                |
>               |<----REGISTER REQRKb)-----------|                              
>               |                                |       
>               |----REGISTER RESP(RCb)--------->|   RK: Routing Key        
>               |                                |   RC: Routing Context    
>               |----REGISTER REQ(RKa)---------->| 
>               |                                | 
>               |<----REGISTER RESP(RCa)---------| 
>               |                                | 
>               |                                | 
>               |<------- ASP Active(RCb)--------| 
>               |-----ASP Active Ack (RCb)------>|
>               |                                |    
>               |-------- ASP Active(RCa)------->| 
>               |<-----ASP Active Ack (RCa)------|
>               |                                |
> 
> 
> 
> 
> 
> 
> 5.1.1.3 Single ASP in Multiple Application Servers (each with "1+0" 
> sparing), Dynamic Registration (Case 1 - Multiple Registration 
> Requests)
> 
>              SGP                              ASP1
>               |                                |
>               |<------------ASP Up-------------| 
>               |----------ASP Up Ack----------->|
>               |                                |
>               |<----REGISTER REQ(RK1)----------| 
>               |                                |       
>               |----REGISTER RESP(RC1)--------->|   RK: Routing Key 
>               |                                |   RC: Routing Context 
>               |                                | 
>               |<------- ASP Active(RC1)--------| 
>               |-----ASP Active Ack (RC1)------>|
>               |                                |
>               |                                |
>               |<----REGISTER REQ(RKn)----------|
>               |                                |
>               |----REGISTER RESP(RCn)--------->|
>               |                                |
>               |                                | 
>               |<------- ASP Active(RCn)--------| 
>               |-----ASP Active Ack (RCn)------>|
>               |                                |
> 
> Note: In the case of an unsuccessful registration attempt (e.g., 
> Invalid RKn), the Register Response message will contain an 
> unsuccessful indication and the ASP will not subsequently send an ASP 
> Active message. Each LRC/RK pair registration is considered 
> independently. 
> 
> It is not necessary to follow a Registration Request/Response message 
> pair with an ASP Active message before sending the next Registration 
> Request. The ASP Active message can be sent at any time after the 
> related successful registration. 
> 
> 
> Adaptation to IPSP communication.
> 
> This is the case where two applications located in AS-B1 and AS-B2 are served by the same IPSP-B. They both want to talk to an application located in AS-A served by IPSP-A. As they want a communication in both directions, they, IPSP-A and IPSP-B, have to activate the RC implicated which are the result for the RK registration.
> 
>  
>             IPSP-A                           IPSP-B
>               |                                |
>               |<------------ASP Up-------------| 
>               |----------ASP Up Ack----------->|
>               |                                |
>               |<---REGISTER REQ(RKb1)----------|  
>               |                                |       
>               |---REGISTER RESP(RCb1)--------->|   RK: Routing Key 
>               |                                |   RC: Routing Context 
>               |                                | 
>               |<------- ASP Active(RCb1)-------| 
>               |-----ASP Active Ack (RCb1)----->|
>               |                                |
>               |                                |
>               |<---REGISTER REQ(RKb2)----------|
>               |                                |
>               |---REGISTER RESP(RCb2)--------->|
>               |                                |
>               |                                | 
>               |<------- ASP Active(RCb2)-------| 
>               |-----ASP Active Ack (RCb2)----->|
>               |                                |
>               |----REGISTER REQ(RKa)---------->| 
>               |                                | 
>               |<----REGISTER RESP(RCa)---------| 
>               |                                | 
>               |                                | 
>               |------- ASP Active(RCa)-------->| 
>               |<-----ASP Active Ack (RCa)------|
>               |                                |
> 
> 
> 
> 
> 
> 
> 5.1.1.4 Single ASP in Multiple Application Servers (each with "1+0" 
> sparing), Dynamic Registration (Case 2 - Single Registration Request)
> 
> 
>              SGP                              ASP1
>               |                                |
>               |<------------ASP Up-------------| 
>               |----------ASP Up Ack----------->|
>               |                                |
>               |<---REGISTER REQ({RK1},---------| 
>               |                   ...,         |
>               |                 {RKn}),--------|
>               |                                |
>               |---REGISTER RESP({RC1},-------->|   
>               |                  ...,          |
>               |                 (RCn})         |   
>               |                                | 
>               |<------- ASP Active(RC1)--------| 
>               |-----ASP Active Ack (RC1)------>|
>               |                                |
>               :                                :
>               :                                :
>               |                                | 
>               |<------- ASP Active(RCn)--------| 
>               |-----ASP Active Ack (RCn)------>|
>               |                                |
> 
> Note: In the case of an unsuccessful registration attempt (e.g., 
> Invalid RKn), the Register Response message will contain an 
> unsuccessful indication and the ASP will not subsequently send an ASP 
> Active message. Each LRC/RK pair registration is considered 
> independently. 
> 
> The ASP Active message can be sent at any time after the related 
> successful registration, and may have more than one RC.
> 
> 
> Adaptation to IPSP communication.
> 
> For the sake of clarity, the number of RK that IPSP-B registers is limited to two.
> 
> 
>             IPSP-A                           IPSP-B
>               |                                |
>               |<------------ASP Up-------------| 
>               |----------ASP Up Ack----------->|
>               |                                |
>               |<---REGISTER REQ{(RKb1)---------|   
>               |                 (RKb2)}        |       
>               |                                |
>               |---REGISTER RESP{(RCb1)-------->|   RK: Routing Key 
>               |                 (RCb2)}        |   RC: Routing Context 
>               |                                | 
>               |<------- ASP Active(RCb1)-------| 
>               |-----ASP Active Ack (RCb1)----->|
>               |                                | 
>               |<------- ASP Active(RCb2)-------| 
>               |-----ASP Active Ack (RCb2)----->|
>               |                                |
>               |----REGISTER REQ(RKa)---------->| 
>               |                                | 
>               |<----REGISTER RESP(RCa)---------| 
>               |                                | 
>               |                                | 
>               |------- ASP Active(RCa)-------->| 
>               |<-----ASP Active Ack (RCa)------|
>               |                                |
> 
> 
> 
> 
> 
> 
> Sidebottom et al                                             [Page 86]
> 
> Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
> 
> 
> 5.1.2 Two ASPs in Application Server ("1+1" sparing)
> 
> This scenario shows the example M3UA message flows for the establishment of traffic between an SGP and two ASPs in the same 
> Application Server, where ASP1 is configured to be in the ASP-ACTIVE state and ASP2 is to be a "back-up" in the event of communication failure or the withdrawal from service of ASP1.  ASP2 may act as a hot, warm, or cold back-up depending on the extent to which ASP1 and ASP2 share call/transaction state or can communicate call state under failure/withdrawal events.  The example message flow is the same whether the ASP Active messages indicate "Over-ride", "Load-share" or 
> "Broadcast" mode, although typically this example would use an Over-ride mode. The SGP MAY start sending any relevant DUNA, DRST and SCON messages to ASPs as soon as they enter the ASP-INACTIVE state. In the case of MTP 
> Restart, the ASP-Active Ack message is only sent after all relevant 
> DUNA/DRST/SCON messages have been transmitted to the concerned ASP.
> 
> 
>        SGP                        ASP1                        ASP2
>         |                         |                          |
>         |<--------ASP Up----------|                          | 
>         |-------ASP Up Ack------->|                          |
>         |                         |                          |
>         |<-----------------------------ASP Up----------------|
>         |-----------------------------ASP Up Ack------------>|
>         |                         |                          | 
>         |                         |                          |
>         |<-------ASP Active-------|                          | 
>         |------ASP Active Ack---->|                          | 
>         |                         |                          |
> 
> Note: It is also possible for ASP2 to send an ASP-Active ("Over-ride-
> Standby") message after ASP1 goes ASP-ACTIVE. A similar sparing arrangement is created, except that the SGP may re-direct traffic to ASP2 more quickly in certain fail-over cases.
> 
> 
> Adaptation to IPSP communication
> 
> IPSP-A serves to AS-A. AS-B1 and IPSP-B2 both serve to AS-B. IPSP-B2 is configured as a back-up process. IPSP-B2 may act as a hot, warm, or cold back-up depending on the extent to which IPSP-B1 and IPSP-B2 share call/transaction state or can communicate call state under failure/withdrawal events.
> 
> 
>      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---------|
>         |                         |                          |
> 
> 
> 
> 
> 5.1.3 Two ASPs in an Application Server ("1+1" sparing, load-sharing 
> case)
> 
> This scenario shows a similar case to Section 5.1.2 but where the two 
> ASPs are brought to the state ASP-ACTIVE and subsequently load-share 
> the traffic.  In this case, one ASP is sufficient to handle the total 
> traffic load. The sending of DUNA, DRST and SCON messages by the SGP is 
> not shown but is similar to the case described in Section 5.1.2.
> 
> 
> 
> 
> 
> 
> 
> Sidebottom et al                                             [Page 87]
> 
> Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
> 
> 
>        SGP                       ASP1                       ASP2
>         |                         |                          |
>         |<---------ASP Up---------|                          | 
>         |--------ASP Up Ack------>|                          |
>         |                         |                          |
>         |<------------------------------ASP Up---------------|
>         |-----------------------------ASP Up Ack------------>|
>         |                         |                          | 
>         |                         |                          |
>         |<--ASP Active (Ldshr)----|                          | 
>         |-----ASP-Active Ack----->|                          | 
>         |                         |                          |
>         |----------------------------NOTIFY (AS-ACTIVE------>|
>         |                         |                          |
>         |<----------------------------ASP Active (Ldshr)-----| 
>         |-------------------------------ASP Active Ack------>| 
>         |                         |                          |
> 
> 
> Adaptation to IPSP communication.
> 
> Same case as before but IPSP-B1 and IPSP-B2 act in the load-sharing mode since both are brought to the ASP-ACTIVE state.
> 
> 
>       IPSP-A                    IPSP-B1                    IPSP-B2
>         |                         |                          |
>         |<---------ASP Up---------|                          | 
>         |--------ASP Up Ack------>|                          |
>         |                         |                          |
>         |<------------------------------ASP Up---------------|
>         |-----------------------------ASP Up Ack------------>|
>         |                         |                          | 
>         |                         |                          |
>         |<--ASP Active (Ldshr)----|                          | 
>         |-----ASP-Active Ack----->|                          | 
>         |                         |                          |
>         |----------------------------NOTIFY (AS-ACTIVE)----->|
>         |                         |                          |
>         |<----------------------------ASP Active (Ldshr)-----| 
>         |-------------------------------ASP Active Ack------>| 
>         |                         |                          |
>         |--------ASP Active------>|                          | 
>         |<-----ASP Active Ack-----|                          | 
>         |                         |                          |
>         |------------------------------ASP Active----------->|
>         |<----------------------------ASP Active Ack---------|
>         |                         |                          |
> 
> 
> 
> 
> 
> 5.1.4 Three ASPs in an Application Server ("n+k" sparing, load-sharing 
> case) 
> 
> This scenario shows the example M3UA message flows for the 
> establishment of traffic between an SGP and three ASPs in the same 
> Application Server, where two of the ASPs are brought to the state ASP-
> ACTIVE and subsequently share the load. In this case, a minimum of two 
> ASPs are required to handle the total traffic load (2+1 sparing). The 
> sending of DUNA, DRST and SCON messages by the SGP is not shown but is 
> similar to the case described in Section 5.1.2.
> 
> 
>    SGP                  ASP1                 ASP2                 ASP3 
>     |                    |                   |                   |
>     |<------ASP Up-------|                   |                   | 
>     |-----ASP Up Ack---->|                   |                   |
>     |                    |                   |                   |
>     |<--------------------------ASP Up-------|                   |
>     |-------------------------ASP Up Ack---->|                   |
>     |                    |                   |                   |
>     |<---------------------------------------------ASP Up--------|
>     |---------------------------------------------ASP Up Ack---->|
>     |                    |                   |                   | 
>     |                    |                   |                   |
>     |<--ASP Act (Ldshr)--|                   |                   | 
>     |----ASP Act Ack---->|                   |                   | 
>     |                    |                   |                   |
>     -----------Notify (AS-ACTIVE)----------->|                   |
>     |-----------------------Notify (AS-ACTIVE)------------------>|
>     |                    |                   |                   |
>     |<--------------------ASP Act. (Ldshr)---|                   | 
>     |-----------------------ASP Act Ack----->|                   | 
>     |                    |                   |                   |
> 
> 
> Adaptation to IPSP communication.
> 
> IPSP-A serves to AS-A. IPSP-B1, IPSP-B2 and IPSP-B3 serve to AS-B and are configure to be in a load-sharing mode.
> 
> 
> 
>   IPSP-A               IPSP-B1             IPSP-B2             IPSP-B3 
>     |                    |                   |                   |
>     |<------ASP Up-------|                   |                   | 
>     |-----ASP Up Ack---->|                   |                   |
>     |                    |                   |                   |
>     |<--------------------------ASP Up-------|                   |
>     |-------------------------ASP Up Ack---->|                   |
>     |                    |                   |                   |
>     |<---------------------------------------------ASP Up--------|
>     |---------------------------------------------ASP Up Ack---->|
>     |                    |                   |                   | 
>     |                    |                   |                   |
>     |<--ASP Act (Ldshr)--|                   |                   | 
>     |----ASP Act Ack---->|                   |                   | 
>     |                    |                   |                   |
>     -----------Notify (AS-ACTIVE)----------->|                   |
>     |-----------------------Notify (AS-ACTIVE)------------------>|
>     |                    |                   |                   |
>     |<--------------------ASP Act. (Ldshr)---|                   | 
>     |-----------------------ASP Act Ack----->|                   | 
>     |                    |                   |                   |
>     |------ASP Active -->|                   |                   | 
>     |<----ASP Act Ack----|                   |                   |
>     |                    |                   |                   |
>     |----------------------ASP Active------->|                   |
>     |<---------------------ASP Active Ack----|                   |
>     |                    |                   |                   |
>     |----------------------------------------------ASP Active--->|
>     |<-----------------------------------------ASP Active Ack----|
>     |                    |                   |                   |
> 
> 
> 
> 
> 
> Sidebottom et al                                             [Page 88]
> 
> Internet Draft       SS7 MTP3-User Adaptation Layer         Jul 2001
> 
> 
> Note: It is also possible for ASP3 to send an ASP Active message 
> ("Loadshare-Standby") after ASP1 and ASP2 go to the ASP-ACTIVE state  A 
> similar sparing arrangement is created, except that the SGP may 
> redirect traffic to ASP3 more quickly in certain fail-over cases.
> 
> 5.2 ASP Traffic Fail-over Examples
> 
> 5.2.1 (1+1 Sparing, Withdrawal of ASP, Back-up Over-ride) 
> 
> Following on from the example in Section 5.1.2, and ASP1 withdraws from 
> service:
> 
>        SGP                       ASP1                       ASP2 
>         |                         |                          |
>         |<-----ASP Inactive-------|                          |
>         |----ASP Inactive Ack---->|                          |
>         |------------------------NTFY(AS-Pending)----------->| 
>         |                         |                          | 
>         |<------------------------------ ASP Active----------| 
>         |------------------------------ASP Active Ack------->| 
>         |                                                    |
> 
> Note: If the SGP M3UA layer detects the loss of the M3UA peer (M3UA 
> heartbeat loss or detection of SCTP failure), the initial ASP Inactive 
> message exchange (i.e., SGP to ASP1) would not occur.
> 
> 
> Adaptation to the IPSP communication.
> 
> In this case the procedure has no difference with the SG-AS one.
> 
> 
>       IPSP-A                    IPSP-B1                   IPSP-B2 
>         |                         |                          |
>         |<-----ASP Inactive-------|                          |
>         |----ASP Inactive Ack---->|                          |
>         |------------------------------NTFY(AS-Pending)----->| 
>         |                         |                          | 
>         |<------------------------------ ASP Active----------| 
>         |------------------------------ASP Active Ack------->| 
>         |                                                    |
> 
> 
> 
> 
> 5.2.2 (1+1 Sparing, Back-up Over-ride)
> 
> Following on from the example in Section 5.1.2, ASP2 wishes to 
> over-ride ASP1 and take over the traffic:
> 
>        SGP                       ASP1                       ASP2 
>         |                         |                          | 
>         |<------------------------------ ASP Active----------| 
>         |-------------------------------ASP Active Ack------>|
>         |----NTFY(Alt ASP-Act)--->| 
>         |                         |                          | 
> 
> 
> Adaptation to the IPSP communication.
> 
> 
>       IPSP-A                   IPSP-B1                    IPSP-B2 
>         |                         |                          | 
>         |<------------------------------ ASP Active----------| 
>         |-------------------------------ASP Active Ack------>|
>         |----NTFY(Alt ASP-Act)--->|                          |
>         |                         |                          | 
> 
> 
> 
> 
> 5.2.3 (n+k Sparing, Load-sharing case, Withdrawal of ASP)
> 
> Following on from the example in Section 5.1.4, and ASP1 withdraws from 
> service:
> 
> 
>    SGP                  ASP1                 ASP2                 ASP3 
>     |                    |                   |                   |
>     |<----ASP Inact.-----|                   |                   | 
>     |---ASP Inact Ack--->|                   |                   |
>     |                    |                   |                   | 
>     |---------------------------------NTFY(Ins. ASPs)----------->| 
>     |                    |                   |                   |
>     |<-----------------------------------------ASP Act (Ldshr)---| 
>     |-------------------------------------------ASP Act (Ack)--->|
>     |                    |                   |                   |
> 
> 
> For the Notify message to be sent, the SG maintains knowledge of the 
> minimum ASP resources required (e.g., if the SG knows that "n+k" = 
> "2+1" for a load-share AS and "n" currently equals "1"). 
> 
> Note: If the SGP detects loss of the ASP1 M3UA peer (M3UA heartbeat 
> loss or detection of SCTP failure), the initial ASP Inactive message 
> exchange (i.e., SGP-ASP1) would not occur.  
> 
> 
> Adaptation to IPSP communication.
> 
> 
>   IPSP-A              IPSP-B1             IPSP-B2             IPSP-B3 
>     |                    |                   |                   |
>     |<----ASP Inact.-----|                   |                   | 
>     |---ASP Inact Ack--->|                   |                   |
>     |                    |                   |                   | 
>     |---------------------------------NTFY(Ins. ASPs)----------->| 
>     |                    |                   |                   |
>     |<-----------------------------------------ASP Act (Ldshr)---| 
>     |-------------------------------------------ASP Act (Ack)--->|
>     |                    |                   |                   |
> 
> 
> 
> 
> 5.3 Normal Withdrawal of an ASP from an Application Server and Tear-
> down of an Association
> 
> An ASP which is now confirmed in the state ASP-INACTIVE (i.e., the ASP 
> has received an ASP Inactive Ack message) may now proceed to the ASP-
> DOWN state, if it is to be removed from service.  Following on from 
> Section 5.2.1 or 5.2.3, where ASP1 has moved to the "Inactive" state:
> 
>        SGP                              ASP1 
>         |                               |
>         |<-----ASP Inactive (RCn)-------|    RC: Routing Context
>         |----ASP Inactive Ack (RCn)---->|
>         |                               |
>         |<-----DEREGISTER REQ(RCn)------|    See Notes 
>         |                               |        
>         |---DEREGISTER RESP(LRCn,RCn)-->|
>         |                               |   
>         :                               :   
>         |                               | 
>         |<-----------ASP Down-----------| 
>         |---------ASP Down Ack--------->|
>         |                               |
> 
> Note: The Deregistration procedure MUST be used if the ASP previously 
> used the Registration procedures for configuration within the 
> Application Server.  ASP Inactive and Deregister messages exchanges may 
> contain multiple Routing Contexts.
> 
> 
> The ASP SHOULD be in the ASP-INACTIVE state and SHOULD have deregistered 
> in all its Routing Contexts before attempting to move to the ASP-DOWN 
> state.  
> 
> 
> Adaptation to IPSP communication.
> 
> 
>       IPSP-A                         IPSP-B 
>         |                               |
>         |<-----ASP Inactive (RCb)-------|    RC: Routing Context
>         |----ASP Inactive Ack (RCb)---->|
>         |                               |
>         |<-----DEREGISTER REQ(RCb)------|    See Notes 
>         |                               |        
>         |---DEREGISTER RESP(LRCn,RCb)-->|
>         |                               |   
>         :                               :   
>         |                               | 
>         |<-----------ASP Down-----------| 
>         |---------ASP Down Ack--------->|
>         |                               |
> 
> 
> 
> 
> 5.4  M3UA/MTP3-User Boundary Examples
> 
> 5.4.1 IPSPs cases
> 
> The interactions with the MTP3 user are shown in the figures below for the regular sending of DATA messages.
> 
> 
> 
>                      IPSP-A                    IPSP-B
>                        |                         |
>   <---MTP-TRANSFER ind.|<---------Data ----------|<--MTP-TRANSFER req.--
>                        |                         |
> 
> 
> 
>                     IPSP-A                     IPSP-B
>                        |                         |
>   --MTP-TRANSFER req.->|----------Data --------->|--MTP-TRANSFER ind.-->
>                        |                         |
> 
> 
> 
> 
>                     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 different from the peer.
> 
> 
> 
> 
> 
> 
> 

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

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

---

---

From: [email-masked]
Date: Wed, 7 Nov 2001 08:08:22 +0200

Hi Brian,
> > As an SGP:
> > 
> > - when sending data msg to the other IPSP it does it in the 
> > same way an SGP sends a message to an ASP: including the RC 
> > that ASP got when registering its RK

> Registration is an OPTIONAL procedure.  RC cannot be defined 
> on the basis of an OPTIONAL procedure.  The ASP never registered.  
> What RC value is sent
> then?

Is this your only objection?  If so, it can be handled this way:

 - when sending data msg to a peer IPSP it does it in the 
   in a similar manner as a SGP sends a message to an ASP 
   (optionally including the RC that ASP recieved when 
   registering its RK or via static configuration).

Is this OK?

John

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 00:30:02 -0600

John,

John Loughney wrote:                                         (Wed, 07 Nov 2001 08:08:22)
> Is this your only objection?  If so, it can be handled this way:

No.  I have more, but they are elsewhere on this thread.

>    registering its RK or via static configuration).

What value of RC is statically configured?  How is the RC value
determined when doing static configuration?  Will any old value
do?

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 10:52:36 +0100

Brian,

See below.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: woensdag 7 november 2001 7:30
To: sigtran
Cc: [email-masked]
Subject: Re: IPSP text (2nd approach)

John,

John Loughney wrote:                                         (Wed, 07 Nov
2001 08:08:22)

[GV] : That's the problem with your interpretation of RC as defining traffic
streams in both directions isn't it ? Aha, that's why you want to get rid of
it in IPSP ... It really isn't : see my previous mails.

That said, the IPSPs agree on the traffic being sent between them. Same as
with ASP/SG, only this time, both IPSPs define their RKs and RCs, and both
have the knwoledge about their partner's.

--gery

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 04:12:59 -0600

Verwimp,

Verwimp Gery wrote:                                       (Wed, 07 Nov 2001 10:52:36)
> [GV]: That's the problem with your interpretation of RC as defining traffic

What does an IPSP care of the state of another IPSP's AS?

--brian

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 11:17:06 +0100

Javier,

Further comments ...

____________________________

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

Javier Pastor-Balbas (ECE) wrote:                          (Tue, 06 Nov 2001
19:19:52)

> - Receive data messages and distribute them to the ASs in the same way ASP
does it, using RC when more than one AS is present in the destination.
> (This last point has the particularity that only one ASP-UP is needed.
When an IPSP receives an ASPUP and sends back an ASPUP-Ack it does not need
to send another ASPUP to the peer and can consider the peer as INACTIVE)

[GV] : What's so particular about it ? At any rate, when both IPSPs send
ASPUP this won't break anything ... Fully agreed with the points above,
though.

> To support message distribution in an IPSP-A for messages to an IPSP-B in
IPSP communication, IPSP-A should maintain the equivalent to a network
address translation table. M3UA layer at IPSP-A should map the addressing
parameters given by the local SS7 application over it to a valid RK. This
could be accomplished by comparing these addressing parameters with the
currently registered RK. These set of RKs has been either registered by
remote IPSPs or configured statically. If a RK is found to match the
addressing parameters, this Routing Key  could in turn map directly to an AS
that is enabled by one or more IPSPs. These IPSPs (e.g. IPSP-B) provide
dynamic status information regarding their availability, traffic handling
capability and congestion to IPSP-A using various management messages
defined in the M3UA protocol.  
> 
> The list of IPSPs in an AS is assumed to be dynamic, taking into account
the availability, traffic handling capability and congestion status of the
individual IPSPs in the list, as well as configuration changes and possible
fail-over mechanisms. 
> 
> Normally, one or more IPSPs are active (i.e., currently processing
traffic) in the AS but in certain failure and transition cases it is
possible that there may be no active IPSP available.  Broadcast,
load-sharing and backup scenarios are supported.
> 
> When there is no matching Routing Key entry at IPSP-A for an SS7 message
coming from the local application, a default treatment MAY be specified.
Possible solutions are to provide a default AS at the AS-A that directs all
unallocated traffic to a (set of) default AS(s), or to drop the message and
provide a notification to layer management.  The treatment of unallocated
traffic is implementation dependent.
> 
> At the receiving end IPSP-B have to distribute the incoming message to its
local SS7 application. In the case it is serving more than one ASs, it would
have to determine which one is the destination. In order to achieve it,
IPSP-B should take into account the RC received within the DATA message sent
by IPSP-A (it is compulsory to send RC when there are more than one remote
AS activated in in the same peer), that is the RC that IPSP-B received as
the response to the registration of the RK related with that specific AS,
for the case of dynamic registration.

[GV] : Ok.

> In the case where there exists IPSP communication, the ASP state diagram
is slightly modified. This fact is due to the symmetry of the two nodes
implied in the communication and the use of a unique ASP Up/ASP Down message
to change between the ASP-DOWN and ASP-INACTIVE states.
> Figure F: ASP State Transition Diagram (Per AS for AS-AS communication) 

[GV] : Fine.

> Only one pair of ASP Up and ASP Up ack messages is needed to consider that
the two nodes that want to participate in a communication are in the
ASP-INACTIVE state. The main purpose of the ASP-Up message is to inform to
the other peer the availability of the local M3UA layer to deal with
management messages. Then if a remote node responds with ASP Up ack upon the
reception of ASP Up message, it can also be considered to be in the
ASP-INACTIVE state, and therefore, it does not need to send back another ASP
Up message to the other peer to inform of its state.

[GV] : When an ASPUP should arrive while waiting for an ASPUP_Ack, the IPSP
responds with an ASPUP_Ack and proceeds to the INACTIVE state. When the
ASPUP_Ack message does arrive, it is ignored in this state.

>     
> In the case of peer-to-peer IPSPs, either of the IPSPs (IPSP-A) may start
operations by sending an ASP Up message to the remote peer (IPSP-B).  When
the ASP Up message is received at IPSP-B and internally the remote IPSP-A is
in the ASP-DOWN state and not considered locked-out for local management
reasons, IPSP-B marks the remote IPSP-A in the state ASP-INACTIVE and
informs Layer Management with an M-ASP_Up indication primitive.  IPSP-B
returns an ASP-Up Ack message to IPSP-A.  IPSP-A moves IPSP-B to the
ASP-INACTIVE state upon reception of an ASP Up Ack message, if 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.
> Anyone of the IPSPs can initiate the communication. The initiating side
(IPSP-A) sends an ASP Active message. Upon the reception of ASP Active
message from the remote node, IPSP-B marks IPSP-A as ASP-ACTIVE and sends
back ASP Active Ack.  Next, the other side (IPSP-B) of the signaling
connection sends an ASP Active message, and the initiating side (IPSP-A)
sends back with another ACTIVE ACK after moving ASP A to the ASP-ACTIVE
state. Both IPSPs SHOULD reach the ASP-ACTIVE state before traffic start
flowing.

[GV] : Activation is per RC the IPSP is serving. Both IPSPs take the
initiative to activate each of their RCs with their communication partners.
If no RC is included in the ASPAC, the receiving nodes assumes that the
sending IPSP is ACTIVE for all RCs it serves.

> ASP-Inactive procedures work in the same way as ASP-Active. An IPSP can be
considered in the ASP-INACTIVE state by a remote IPSP after an ASP Inactive
message has been received from it. If a 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.
> It works in the same way 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 belonging
to an IPS.
> Each IPSP has to register its own RK in the remote IPSP. This fact means
that for the establishment of a path between two IPSPs two registrations
have to be performed, one per node.
> 
> Deregistration process is completely equivalent. A double deregistration
process has to be performed if a path was previously established.

[GV] : Yip ! No further comments on the examples below.

> Note: If the ASP Active message contains an optional Routing Context
parameter, The ASP Active message only applies for the specified RC
value(s). For an unknown RC value, the SGP responds with an Error message.

> This is the case where two applications located in AS-B1 and AS-B2 are
served by the same IPSP-B. They both want to talk to an application located
in AS-A served by IPSP-A. As they want a communication in both directions,
they, IPSP-A and IPSP-B, have to activate the RC implicated which are the
result for the RK registration.
> This scenario shows the example M3UA message flows for the establishment
of traffic between an SGP and two ASPs in the same 
> Application Server, where ASP1 is configured to be in the ASP-ACTIVE state
and ASP2 is to be a "back-up" in the event of communication failure or the
withdrawal from service of ASP1.  ASP2 may act as a hot, warm, or cold
back-up depending on the extent to which ASP1 and ASP2 share
call/transaction state or can communicate call state under
failure/withdrawal events.  The example message flow is the same whether the
ASP Active messages indicate "Over-ride", "Load-share" or 
> "Broadcast" mode, although typically this example would use an Over-ride
mode. The SGP MAY start sending any relevant DUNA, DRST and SCON messages to
ASPs as soon as they enter the ASP-INACTIVE state. In the case of MTP 
> Standby") message after ASP1 goes ASP-ACTIVE. A similar sparing
arrangement is created, except that the SGP may re-direct traffic to ASP2
more quickly in certain fail-over cases.
> IPSP-A serves to AS-A. AS-B1 and IPSP-B2 both serve to AS-B. IPSP-B2 is
configured as a back-up process. IPSP-B2 may act as a hot, warm, or cold
back-up depending on the extent to which IPSP-B1 and IPSP-B2 share
call/transaction state or can communicate call state under
failure/withdrawal events.
> Same case as before but IPSP-B1 and IPSP-B2 act in the load-sharing mode
since both are brought to the ASP-ACTIVE state.
> 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 different from the peer.

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 7 Nov 2001 15:36:11 +0100

Hi Gery, 

Thanks a lot for your comments. 

See my own comments inline...

(snip)
> ASPUP_Ack message does arrive, it is ignored in this state.
(snip)

It is included in the general description of how ASPUP works. Do you think we need to state it here also?

(snip)
> sending IPSP is ACTIVE for all RCs it serves.
(snip)

I agree. I'll include it for the next approach.

Cheers // Javier

---

---

From: Verwimp Gery <[email-masked]>
Date: Wed, 7 Nov 2001 15:54:54 +0100

Hi Javier,

Only 1 comment ...

-----Original Message-----
From: Javier Pastor-Balbas (ECE)
[mailto:[email-masked]]
Sent: woensdag 7 november 2001 15:36
To: sigtran
Subject: RE: IPSP text (2nd approach)

Hi Gery, 

(snip)
(snip)

It is included in the general description of how ASPUP works. Do you think
we need to state it here also?

[GV] : More or less. It wouldn't hurt stating it explicitly here too.

(snip)
(snip)

Cheers // Javier

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 7 Nov 2001 15:53:50 +0100

Hi Gery, 

Ok, If nobody is against, it's OK with me.  :-D

Cheers // Javier.

> From: Verwimp Gery [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2001 3:55 PM
> To: sigtran
> You are currently subscribed to sigtran as: 
> [email-masked]

---

---

From: "Schantz, John" <[email-masked]>
Date: Wed, 7 Nov 2001 13:41:36 -0800

Javier,

I don't agree with these 2 figures (near the end):

                    IPSP-A                     IPSP-B
                       |                         |

                     IPSP-A                     IPSP-B
                       |                         |

These figures are ONLY true if there is a SINGLE association between
IPSP-A and IPSP-B, and if it is a "backhaul" case.  Otherwise there
should be some logic in IPSP-B to determine if there are any alternate
routes/paths to IPSP-A (another association or a route through an SG).
The second one would be true if this association was the FIRST path made
available to IPSP-A, but this is based on logic not a straight
translation of ASP Active to MTP-Resume.  

So please delete them and I hope that this "backhaul" mentality is not
reflected in the rest of the text.

John

> Sent: Wednesday, November 07, 2001 8:54 AM
> To: sigtran
> > [email-masked]
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: Dennis Niermann <[email-masked]>
Date: Wed, 07 Nov 2001 16:51:44 -0600

Hi Javier,
John makes a good point.
If figures like this are included they need
to indicate other conditions that might impact the 
indication to the user.
In addition to the possibility of an alternate path
to the AS that John points out,
it is also necessary to take into account if there is 
another remote AS that uses the same point code as the AS 
going inactive. If so, a MTP-PAUSE would not be appropriate.

/Dennis

"Schantz, John" wrote:
> You are currently subscribed to sigtran as: [email-masked]

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 17:33:22 -0600

Dennis,

Dennis Niermann wrote:                                     (Wed, 07 Nov 2001 16:51:44)
> going inactive. If so, a MTP-PAUSE would not be appropriate.

Just how to do you propose that IPSP-B goes figuring that out?

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 17:32:31 -0600

John,

I agree that ASPTM should not be directly translated into
MTP-PAUSE/RESUME in this fashion.  However, because the AS
may be supported by other IPSPs, IPSP-B cannot be expected
determine that the AS does not have other "routes" via other
IPSPs.  

Because IPSP-B cannot be expected to know the status of
routes from all other IPSPs that serve the same AS, it
appears that IPSP-B can never generate MTP-PAUSE or MTP-RESUME
appropriately.

--brian

John Schantz wrote:                                          (Wed, 07 Nov 2001 13:41:36)

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

---

---

From: Dennis Niermann <[email-masked]>
Date: Wed, 07 Nov 2001 18:03:12 -0600

Brian,
It is the identical logic that the STP/SG must do.

An STP/SG also needs to handle multiple paths to an AS and the
possibility of multiple ASs sharing a point code.
An SG/STP must know how to turn state information into 
the right action towards SS7 destinations. 
In the case that a STP/SG that receives an ASPIA, 
it can only send a TFP if no other path 
to any AS using that point code is still active.
Or, if you prefer, the SGP can only forward PAUSE
via the NIF to MTP3 if no other AS using that point 
code is active.

Once again, the IPSP needs to support the functionality
of a (STP)SGP for that direction.

/Dennis 

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 7 Nov 2001 20:06:07 -0600

Dennis,

Dennis Niermann wrote:                                     (Wed, 07 Nov 2001 18:03:12)
> It is the identical logic that the STP/SG must do.

STP function is for an extension draft.

> possibility of multiple ASs sharing a point code.

An SG (not necessarily an STP) accomplishes this by
routing data messages between SGP in the SG.  If the AS
is active for one SGP it is effectively active for all.
In the reverse direction, the SGP present the same SS7
connectivity to each ASP.

If these two requirements are placed on the SGF of the
IPSP, then the IPSP must present the same view of
connectivity of its local AS over each IPSP in the
cluster, and must route data messages between SGF to
sustain this.  That would mean that AS are active or
inactive on all IPSPs in an IPSP cluster in unison,
negating any need for per-IPSP ASPTM to remote AS.

If IPSPs present the same view of the state of local AS
to peer IPSPs so that the IPSP can operate in the same
fashion as the SG in this regard, approach (B) removes
the overhead of per-IPSP ASPTM and replaces it with
per-IPSP-cluster SNMM.

> the right action towards SS7 destinations.  In the
> case that a STP/SG that receives an ASPIA, it can only
> send a TFP if no other path to any AS using that point
> code is still active.

SS7 SEPs do not send TFP.

> Or, if you prefer, the SGP can only forward PAUSE via
> the NIF to MTP3 if no other AS using that point code
> is active.

The SG can choose to deactivate the entire SPMC any
time it wishes.  To do this it either drops associations
to the ASP or sends unsolicited ASPIA Ack to whatever
AS remain active in the SPMC.

Where is the similar capability in IPSP?

> Once again, the IPSP needs to support the
> functionality of a (STP)SGP for that direction.

There is no STP function at a point-to-point IPSP.

--brian

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

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

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 8 Nov 2001 12:50:24 +0100

Thanks John, 

You are right, I'll delete them for the next approach (hopefully the final :-D)

It was not my intention to do it for the backhaul case, but I realised after sending the 2nd approach of what you write. If you find something else in the text, please send it out so that we can discuss or fix it.. :-)

Cheers // Javier.

> From: Schantz, John [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2001 10:42 PM
> To: sigtran

---

---

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

Hi Dennis, 

You are also right. I'll remove them for the next version.

Thanks // Javier.

> From: Dennis Niermann [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2001 11:52 PM
> To: sigtran
> [email-masked]
> [email-masked]

---

---

From: [email-masked]
Date: Thu, 8 Nov 2001 12:00:52 -0500

Hi Javier,

Small but important comment about 2nd proposal document:
At the very beginning you say IPSP :As an SGP.
The proposed IPSP has the functionality of an ASP and of a SG, not of a SGP
(or maybe the best way to state it is to say SG with one SGP) Otherwise
people can have the confusion that this functionality of two IPSPs have the
relationship like two SGPs of the same SG.

   Tolga

> From:   "Javier Pastor-Balbas (ECE)"
> <[email-masked]>
> Sent:   Thursday, November 08, 2001 6:58 AM
> To:     "sigtran" <[email-masked]>
> Cc:
> > > > > > ASP-INACTIVE state. The main purpose of the ASP-Up
> message is
> > > > > > to inform to
> You are currently subscribed to sigtran as: [email-masked]

---

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Thu, 8 Nov 2001 18:16:36 +0100

Hi Tolga, 

Thanks for the comment :-D. Maybe we should clarify that point. What about saying...

<TEXT>

IPSP: Node that have a mixed functionality taken from SGP and ASP. The way it works can be related with the ASP-SGP scenario in following way:

-IPSP works as an SGP talking with an ASP when:
   -- when sending data msg to a peer IPSP it does it 
      in a similar manner as a SGP sends a message 
      to an ASP (optionally including the RC that ASP 
      received when registering its RK or via static 
      configuration).
   -- when receiving and treating ASPTM, ASPSM and RRM in 
      the same way as SGP, having status information of the 
      other peer

- IPSP works as an ASP talking with an SGP when:
      [...]

</END TEXT>

Cheers // Javier.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, November 08, 2001 6:01 PM
> To: sigtran
> Subject: RE: RE: IPSP text (2nd approach)
> 
> 
> 
> Hi Javier,
> 
> > > > > > > > Only one pair of ASP Up and ASP Up ack messages 
> is needed
> > > > > > > to consider that
> > > > > > > management messages. Then if a remote node 
> responds with ASP
> > > > > > > Up ack upon the
> > > > > > > ASP-INACTIVE state, and therefore, it does not 
> need to send
> > > > > > > back another ASP
> > > > > > It is included in the general description of how 
> ASPUP works.
> > > > > > Do you think
> > > > > > > (IPSP-A) sends an ASP Active message. Upon the 
> reception of
> > > > > > ASP Active
> > > > > > > sends back with another ACTIVE ACK after moving 
> ASP A to the
> > > > > > > ASP-ACTIVE

---

---

From: [email-masked]
Date: Thu, 8 Nov 2001 14:43:02 -0500

Hi,

A comment about the proposed approach in general:
Personally, I believe this approach will work, if one understands it well
and does the configuration accordingly. Because it was just putting an ASP
and SG in the same box. But what is the use of this approach?

The proposed approach is:

  **************      **************
  *            *      *            *
  *  +-----+   *      * +-----+    *
  *  | ASP1|   * +----*-+ ASP2|    *
  *  |     +---*-+-+  * |     |    *
  *  +--+--+   * | |  * +--+--+    *
  *     |      * | |  *    |       *
  *  +--+--+   * | |  * +--+--+    *
  *  | SG1 |   * | |  * | SG2 |    *
  *  |     +---*-+ +--*-+     |    *
  *  +-----+   *      * +-----+    *
  *            *      *            *
  *            *      *            *
  **************      **************
    IPSP1                IPSP2

But we can have the same configuration without defining IPSPs. Just remove
the IPSP boxes and separate ASPs from SGs. So, what is the benefit of
putting them to the same box? Even the following configuration is possible,
so why do we need to have IPSP as defined in this approach?

  +-------+           +------+
  |       |           |      |
  | ASP1  |           | ASP2 |
  +-+-----+           +-+----+
    |                   |
    |                   |
    |                   |
    |                   |
    |                   |
    |     +---------+   |
    |     |         +---+
    +-----+  SG1    |
          |         |
          +---------+

    Tolga

> Sent: Tuesday, November 06, 2001 1:35 PM
> Subject: IPSP text (2nd approach)
>
>
> Dear all,
>
> If you have others, please send them out and we can also
> discuss them. I'm wide
> open to whatever reaches consensus.
>
>
> Cheers // Javier.
>
>
>  - IPSP proposed text SML 2.txt
>
> ---

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 8 Nov 2001 14:30:51 -0600

Tolga,

[email-masked] wrote:                        (Thu, 08 Nov 2001 14:43:02)
> The proposed approach is:

I agree there is little use in this approach.  The configuration
of such an approach requires the operator of one IPSP to expose
the internal architecture of her IPSP to all others.

This is possible now both for M3UA and SUA.  But as you show it,
it does not allow peering.

   +-------+           +------+
   |       |           |      |
   | ASP1  |           | ASP2 |
   +-+-----+           +-+----+
     |                   |     
     |                   |     
     |                   |     
     |                   |     
     |                   |     
   +-------+         +--------+
   |       |   SS7   |        |
   |  SG1  |---------|  SG2   |
   |       | F-link  |        |
   +-------+         +--------+

This is also possible now both for M3UA and SUA, but allows
peering.  It also allows operators to manage SS7 SEPs in the
same fashion as they are managed now in the SS7 network.

All that is needed is a description of how SG can communicate
with each other over SCTP associations using M3UA/SUA.  All
of the necessary messages are in place (with minor adjustments).
For each MTP3 PDU there is an M3UA message.  For each SCCP PDU
there is an SUA message.

If an SG controls one or more point codes, all that would be
required is an exchange of ASPUP(DN)/Ack and an exchange of
ASPAC(IA)/Ack without RC in a single-ended fashion.  SGs would
then exchange MTP3/SCCP PDUs using M3UA/SUA messasges: DATA
*and* SNMM.  Redundancy across associations using override,
loadsharing and broadcast between SGs replaces the changeovers
and such of the SS7 MTP.

It permits peering, management on the same basis as SS7, does
not expose an node operator's internal architecture (she can
define AS/SG relationship any way she wants and can even do
backhaul if desired; or, place everything in one box).

This is approach (B).  Simple, direct and functional.

--brian

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

---

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 8 Nov 2001 13:12:25 -0800 (PST)

Brian,

Please see comments below.

  Tolga

--- "Brian F. G. Bidulock" <[email-masked]>
> the internal architecture of her IPSP to all others.
[TOLGA] My argument to think that this approach is not
very usefull is based mainly on the fact that the same
can be achieved with conventional SGs and ASPs.
Otherwise for a point-to-point communication (if one
thinks ASs as endpoints) I still don't have problem
with the concept defining ASs in both of the sides.
Currently what I think is that IPSP should be totally
taken out of the draft. The proposed model was a
working IPSP model, but IPSP model is not something
usefull. We don't need it. 
I think mostly I agree with you that what we need is
SG-to-SG communication. Probably that was the source
of the problem, you were trying to develop a model for
SG-to-SG communication while the other model was
trying to behaeve like an IPSP as described in the
draft. I still think the proposed IPSP approach is
correct but it is not usefull, because IPSP concept is
not usefull.
> [email-masked]
> [email-masked]
> [email-masked]

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 8 Nov 2001 15:37:07 -0600

Tolga,

So why not remove IPSP and put SG-SG communication in
the draft?  There are bodies already poised for complete
IP-domain operation with point-to-point (SEP-to-SEP)
communication.

Also, I disagree that the current IPSP text describes
approach (A).  I believe that it is closer to describing
approach (B).  Filling out the draft for approach (B)
is not very difficult at all and would meet the needs
of those bodies wishing to use M3UA/SUA in this fashion.

It was felt that point-to-point (SEP-to-SEP) operation
would meet the immediate need, and that transfer/relay
function could be deferred to extension drafts.

Also, there is no reason to change the term IPSP, just
change your diagram to:

   *  | ASP1|   *      * | ASP2|    *
   *  |     |   *      * |     |    *
   *  +--+--+   *      * +--+--+    *
   *     |      *      *    |       *
   *  +--+--+   *      * +--+--+    *
   *  | SG1 |   *      * | SG2 |    *
   *  |     +---*------*-+     |    *

--brian

Tolga Asveren wrote:     (Thu, 08 Nov 2001 13:12:25)

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

---

---

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

Brian,

   Tolga
> of those bodies wishing to use M3UA/SUA in this
[TOLGA] My personal opinion is still that IPSP concept
is not usefull in the context of M3UA, the same can be
achieved with normal ASP/SG model. I think we should
try to develop a model, which will allow us SG-SG
communication.
> Also, there is no reason to change the term IPSP,
[TOLGA] What I had in my was something more like the
following figure:

      +----+  +----+               +---+ +---+   
+---+
      |ASP1|  |ASP2|               |ASP3 |ASP4   
|ASP5
      +-+--+  +-+--+               +-+-+ +-+-+. .
+-+-+
        |       |                    |     |        |
        |       |                    |     |        |
        |       |                    |     |        |
   ********************         
*************************
   *  +-+-------+--+  *          *
+-+-----+--------+-+  *
   *  |   SG1      +--*-+ +------*-+      SG2        
|  *
   *  +----+-------+  * | |      *
+-------+----------+  *
   *  +----+-------+  *
+-+------*-+-------+----------+  *
   *  |  ASP11     +--*---+      * |     ASP22       
|  *
   *  +------------+  *          *
+------------------+  *
   *                  *          *                    
  *
   ********************         
*************************

      IPSP1                             IPSP2

So, I don't think it is nice to label to boxes as
IPSPs. IPSP stands for IP Server Process. But those
are more like an improved version of conventional SGs,
which have the capability to speak to other SGs.

> > > [email-masked] wrote:                    
>   
> > > (Thu, 08 Nov 2001 14:43:02)
> > > > Hi,
> > > > 
> > > > Personally, I believe this approach will work,
> if
> > > one understands it well
> > > > and does the configuration accordingly.
> Because it
> > > was just putting an ASP
> > > I agree there is little use in this approach. 
> The
> > > configuration
> > > > putting them to the same box? Even the
> following
> > > configuration is possible,
> > > > so why do we need to have IPSP as defined in
> this
> > > approach?
> > > > 
> > > 
> > > >   +-------+           +------+
> > > >   |       |           |      |
> > > >   | ASP1  |           | ASP2 |
> > > >   +-+-----+           +-+----+
> > > >     |                   |
> > > >     |                   |
> > > >     |                   |
> > > >     |                   |
> > > >     |                   |
> > > >     |     +---------+   |
> > > >     |     |         +---+
> > > >     +-----+  SG1    |
> > > >           |         |
> > > >           +---------+
> > > > 
> > > 
> > > This is possible now both for M3UA and SUA.  But
> as
> > > you show it,
> > > This is also possible now both for M3UA and SUA,
> but
> > > allows
> > > All that is needed is a description of how SG
> can
> > > communicate
> > > of the necessary messages are in place (with
> minor
> > > adjustments).
> 
=== message truncated ===

---

---

From: [email-masked]
Date: Thu, 8 Nov 2001 14:33:44 -0800

Hi,

Sorry for the corrupted figure. Please consider that one:

 Tolga

        Please view in a fixed-width font such as Courier.

       +-----+  +-----+               +-----++----+     +-----+
       |ASP1 |  |ASP2 |               |ASP3 ||ASP4|     |ASP8 |
       +-+---+  +--+--+               +--+--++-+--+.... +--+--+
         |         |                     |     |           |
         |         |                     |     |           |
         |         |                     |     |           |
    ***********************        *******************************
    *  +-+---------+--+   *        *  +--+-----+-----------+--+  *
    *  |    SG11      +---*-+  +---*--+      SG22             |  *
    *  +--------------+   * |  |   *  +-----------------------+  *
    *  +--------------+   * +--+---*--+-----------------------+  *
    *  |    ASP11     +---*----+   *  |      ASP22            |  *
    *  +--------------+   *        *  +-----------------------+  *
    *                     *        *                             *
    ***********************        *******************************
          IPSP1                              IPSP2

> From:   Tolga Asveren <[email-masked]>
> Sent:   Thursday, November 08, 2001 5:28 PM

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 8 Nov 2001 17:54:31 -0600

Tolga,

Could you explain your figure a bit more?  I'm not
sure just what ASP11 and ASP22 are doing or why they
are necessary.

SG-SG communication is clearly possible without exposing
ASPs or backhaul arrangements.  SG-SG communication is
neatly fits into the SIGTRAN architecture RFC (which does
not involve ASPs or backhaul for peer-to-peer, point-to-
point SG communication).

--brian

[email-masked] wrote:                        (Thu, 08 Nov 2001 14:33:44)

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

---

---

From: Tolga Asveren <[email-masked]>
Date: Thu, 8 Nov 2001 17:11:33 -0800 (PST)

Hi Brian,

In fact if one can let SGs communicate to each other
then ASP22 and ASP11 are not necessary. I just put
them to show the things with conventional SG/ASP
concept. Otherwise, those are not necessary. 
But the real important thing is that the IPSP boxes
(or lets call them better SG boxes) don't include
ASPs.
ASPs, which are serving ASs are outside of the box. In
your figure, SG and ASP were in the same box (IPSP)
and two IPSPs were connected by a connection on their
SGs. Here there are more than one ASP, and I put them
outside of the box. I know, no big change :-)
 --- "Brian F. G. Bidulock" <[email-masked]>
wrote:
> (Thu, 08 Nov 2001 14:33:44)
> > Hi,
> > 
>         |
>         |
>         |
> > > > So why not remove IPSP and put SG-SG
> communication
> > > > in
> > > > the draft?  There are bodies already poised
> for
> > > > complete
> > > > approach (B).  Filling out the draft for
> approach
> > > > (B)
> > > > is not very difficult at all and would meet
> the
> > > > needs
> > > > of those bodies wishing to use M3UA/SUA in
> this
> > > > fashion.
> > > >
> > > > Also, there is no reason to change the term
> IPSP,
> > > > just
> > > > change your diagram to:
> > > >
> > > >
>    |
>    |
>    |

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 8 Nov 2001 19:46:34 -0600

Tolga,

I would think that whether ASPs are inside or
outside the box would be left to the implementation.

--brian

Tolga Asveren wrote:                                        (Thu, 08 Nov 2001 17:11:33)

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

---

---

From: Verwimp Gery <[email-masked]>
Date: Fri, 9 Nov 2001 09:32:58 +0100

Tolga, and others,

Seems that the IPSP is not a single process anymore, but a battery of SG and
ASPs acting to the outside world as an SS7 node. All about ASPSM/TM (traffic
splitting, registration) is kept within this IPSP box (whether you draw the
ASPs out of it or not makes no real difference).

As such SG-SG communication is plainly SS7 (DATA+SNMM), as there's no use
for any ASP management outside this box. And why not, we could have IPSP
boxes with transfer functionality. It's just SCTP transport instead of TDM.

Now although this is quite a valid architecture, and perhaps gives a nice
migration strategy, in my view this has absolutely nothing to do with an
IPSP concept of any sort. So I agree with you on the point to kick the term
IPSP out.

A true IPSP concept would continue on the ideas of ASP (call it IPSP now)
management. At least that's what I would expect, since this is the one new
idea (together with dynamic registration) coming out of this WG.

Surely, the ASPTM can be lacking on some points, e.g. flow and congestion
control that seem useful in the ASP-SG case as well (hey it's called traffic
management for a reason isn't it ?). But the fact we "see" no applications
for this concept (coming out of an SS7 environment), doesn't mean there
aren't any.

So it's all nice and dandy to say we have an IPSP concept here, but it just
doesn't qualify as one.

Regards,

Gery Verwimp
Fax : +32 14 25 3212

-----Original Message-----
From: Tolga Asveren [mailto:[email-masked]]
Sent: vrijdag 9 november 2001 2:12
To: sigtran
Cc: [email-masked]
Subject: Re: IPSP text (2nd approach)

Hi Brian,

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 9 Nov 2001 03:29:49 -0600

Verwimp,

Verwimp Gery wrote:                                       (Fri, 09 Nov 2001 09:32:58)
> idea (together with dynamic registration) coming out of this WG.

These are not new ideas, these concepts have been used internal to
SS7 nodes for some time.  In exposing the internal architecture of
the SS7 node, backhaul exposes these concepts.  For peer-to-peer
they are not only unnecessary but unusable.

> for this concept (coming out of an SS7 environment), doesn't mean there

Proposals with dubious application sound like stuff for extension drafts.

> So it's all nice and dandy to say we have an IPSP concept here, but it just

Just change the SP in IPSP from "server process" back to "signalling point".

--brian

> Fax: +32 14 25 3212

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

---

---

From: [email-masked]
Date: Fri, 9 Nov 2001 06:07:50 -0800

Gery,

   Tolga

> From:   Verwimp Gery <[email-masked]>
> Sent:   Friday, November 09, 2001 3:40 AM
[TOLGA] According to me we just need SGs, which can communciate to each
other. The reason why they are acting like SS7 nodes to the outside world i
because of the fact that a reasonable configuration should let a SG control
SPMCs as a whole (also in ASP/SG case).
But still it is discussible, whether ASPTM between SGs could be usefull or
not.
> As such SG-SG communication is plainly SS7 (DATA+SNMM), as
[TOLGA] I think we should (or at least I, because I don't have a clear idea
about it) think more whether ASPTM+SSNM is better than just SSNM or not.
> there's no use
[TOLGA] I totally agree with you that this is not IPSP as described in the
draft. But in my opinion the problem is that what is described as IPSP in
the draft is something not usefull. Javier's proposal was modeling what was
described in the draft quite well, at least in my opinion. But at the end,
what did we have: one ASP and one SG in one box. So, why should we define a
new concept for it. Also with conventional SG/ASP concept we were free to
put them to the same box if we want. What we achieved was nothing else than
a sample configuration of the regular AS/SGP case.
> for this concept (coming out of an SS7 environment), doesn't
[TOLGA] As I stated before, I think whether ASPTM could be usefull (in
addition to SSNM) for SG-to-SG communciation is a topic, which should be
discussed a little bit more (in my opinion), and I agree with you we
shouldn't take a conservative approach.

---