Subject: [Sigtran] IPSP double exchange mode of operation

From: "PELLAN,HERVE (HP-France,ex1)" <[email-masked]>
Date: Fri, 6 Dec 2002 17:12:46 +0100

Hi all,

To conclude the thread "[Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day
2" with respect to the support of the Double Exchange between IPSP:

We would like to hear the voice of the companies which expressed their wish
to continue to support IPSP double exchange.

1) Double Exchange support in the M3UA standard:
================================================

As far as we know the status of the RFC3332 being "Proposed Standard", and
as several implementations interoperated sucessfully (at 2nd and 3rd M3UA
plugtest) showing that the IPSP Double Ended operation is a valid mode of
operation with static registration AND dynamic registration, we feel that,
from a pure standardization point of view (as specified in
http://www.ietf.org/rfc/rfc2026.txt)the IPSP Double Exchange mode of
operation must be kept in the standard. 

From our perspective, IPSP Single Exchange and Double Exchange may coexist
as long as it is specified in the text that peers must agree per
configuration which mode is used in their exchange.

As the previous mentionned thread showed, it seems to be the consensus that
the two mode of operations address possibly different needs: Double Exchange
seems to be especially appropriate for full meshed network (a example of
such a configuration is also attached to this e-mail: See point 3)) (but
fits also the 1 to 1 configuration), and Single Exchange is more targeted at
1 to 1 configuration. 

2) Dynamic Registration in Single Exchange:
===========================================

Concerning the Dynamic Registration use in Single Ended mode of operation,
we would like to hear whether, at least two implementations successfully
interoperated, and more specifically, showed that when REG REQ are generated
at the same time by the two ends, each implementation was able to handle the
race condition and the consequences. The following message flow illustrate
the issue.

If multiple implementations didn't show that dynamic registration works in
Single Exchange, then, from a standardization point of view, this feature
must be either fixed or dropped for IPSP Single Exchange, as proposed in the
Implementor's Guide text proposal attached (See point 4))

Single Exchange dynamic registration issue:

IPSP A                              IPSP B

   |-------------ASPUP---------------->|
   |<------------ASPUP ACK-------------|
   |                                   |
   |------------REG REQ (RK_A)-------->|
   |<----------REG REQ (RK_B)----------|

Then what's happen ?
Possibly:
   |------------REG RSP(RC_B)--------->|
   |<-----------REG RSP(RC_A)----------|
                   .
                   .
                   .

Either RC_A and RC_B are correlated in some way, or if not, then possibly
each end will generate its own ASPAC with its own RC ?? It looks then like
Double exchange ...

3)  1 to many large configuration example:
==========================================
Here is an example of the large configuration where the IPSP double exchange
seems to us more appropriate:
SMS offload: Let's consider the problem from an SMSC standpoint. The
considered SMSC_A (See figure below) is a new generation SMSC providing M3UA
connectivity only. It will have to talk to several MSCs either directly
through a full IP network or by going through SGs, to HLRs (SS7 or M3UA),
SGSNs for GPRS,... etc. At some point in time, IPSP and ASP type of behavior
will be required for this SMSC (at least for migration purpose of the
infrastructure). The number of IPSP peers may be significant as well as the
number of SGPs. 

 Operator portal
    |
    |   /----------------------------HLR_1
    |  /
   SMSC_A -------------------------------HLR_m
    \ \ \_______________________________________ MSC_1
    |\ \___________________________________________MSC_n
    | \ \____________________________________________SGSN_1
    |  \
===== HLR_n
    |   \___________________________________SG_1  ==========
===== MSC_a
    |    \                                                   ....... SS7
.......
    |     \__________________________________SG_x ==========
===== MSC_b
    |
===== VLR_a
    |                              
    |
===== VLR_z
    SMSC_B.....
     
At SMSC_A, we would configured one single Routing Key made of SMSC_A Point
Code plus SI.
This means 
- one RC configured for the local AS. 
- one RC per IPSP remote AS.

4) Implementor's Guide text addition proposal:
=============================================

We are therefore proposing to amend the current M3UA implementor's guide
with the attached text.

Generally speaking, we would like to see the M3UA implementor's guide
modified to reflect the following rules:
1. When using static configuration of RCs, both SE and DE IPSP are allowed
and the chosen mode must be configured on both sides.
2. When using dynamic registration of Routing Keys, only DE IPSP is allowed.

We propose the following texts:

3.12 IPSP stuff

3.12.1 Description of the problem

    ---------
    Old text: (Section 3.12.1)
    ---------

    At the 2nd M3UA Plugtest several concerns were raised about the non-
    interoperability of the two different IPSP exchanges defined in M3UA.

    ---------
    New text: (Section 3.12.1)
    ---------
    
    At the 2nd M3UA Plugtest several concerns were raised about the non-
    interoperability of the two different IPSP exchanges defined in M3UA.
    
    The mode of communication (SE or DE) MUST be agreed between both peers. 

 3.12.2 Text changes to the document

    ---------
    Old text: (Section 4.3.1)
    ---------

    Figure 4: ASP State Transition Diagram, per AS

                                       +--------------+
                                       |              |
                +----------------------|  ASP-ACTIVE  |
                |      Other   +-------|              |
                |   ASP in AS  |       +--------------+
                |   Overrides  |           ^     |
                |              |    ASP    |     | ASP
                |              |    Active |     | Inactive
                |              |           |     v
                |              |       +--------------+
                |              |       |              |
                |              +------>| ASP-INACTIVE |
                |                      +--------------+
                |                          ^     |
      ASP Down/ |                     ASP  |     | ASP Down /
      SCTP CDI/ |                     Up   |     | SCTP CDI/
      SCTP RI   |                          |     v SCTP RI
                |                      +--------------+
                |                      |              |
                +--------------------->|   ASP-DOWN   |
                                       |              |
                                       +--------------+

    ---------
    New text: (Section 4.3.1)
    ---------

    The figure below shows the transitions for the ASP and IPSP cases.

            Figure 5: IPSP SE State Transition Diagram, per AS

                                       +--------------+
                                       |              |
                +----------------------|  ASP-ACTIVE  |
                |        Other +-------|              |
                |   IPSP in AS |       +--------------+
                |    Overrides |           ^     |
                |              |    ASPAC/ |     | ASPIA/
                |              |[ASPAC-Ack]|     | [ASPIA-Ack]
                |              |           |     v
                |              |       +--------------+
                |              |       |              |
                |              +------>| ASP-INACTIVE |
                |                      |              |
                |                      +--------------+
                |                          ^     |
         ASPDN/ |                          |     | ASPDN /
    [ASPDN-Ack/]|                   ASPUP/ |     | [ASPDN-Ack /]
      SCTP CDI/ |              [ASPUP-Ack] |     | SCTP CDI/
      SCTP RI   |                          |     | SCTP RI
                |                          |     v
                |                      +--------------+
                |                      |              |
                +--------------------->|   ASP-DOWN   |
                                       |              |
                                       +--------------+

            Figure 6: IPSP DE State Transition Diagram, per AS

                                       +--------------+
                                       |              |
                +----------------------|  ASP-ACTIVE  |
                |        Other +-------|              |
                |   IPSP in AS |       +--------------+
                |    Overrides |           ^     |
                |              |    ASPAC  |     | ASPIA
                |              |           |     |
                |              |           |     v
                |              |       +--------------+
                |              |       |              |
                |              +------>| ASP-INACTIVE |
                |                      |              |
                |                      +--------------+
                |                          ^     |
         ASPDN/ |                          |     | ASPDN /
    [ASPDN-Ack/]|                   ASPUP/ |     | [ASPDN-Ack /]
      SCTP CDI/ |              [ASPUP-Ack] |     | SCTP CDI/
      SCTP RI   |                          |     | SCTP RI
                |                          |     v
                |                      +--------------+
                |                      |              |
                +--------------------->|   ASP-DOWN   |
                                       |              |
                                       +--------------+

    The transitions in brackets are just valid for the IPSP communication
    while the rest are valid for both ASPs and IPSPs.

    ---------
    Old text: (Section 4.3.4.1.2)
    ---------

    Alternatively, an interchange of ASP Up messages from each end can be
    performed. This option follows the ASP state transition diagram. It
    would need four messages for completion.

    ---------
    New text: (Section 4.3.4.1.2) i.e. UNCHANGED versus RFC
    ---------

    Alternatively, an interchange of ASP Up messages from each end can be
    performed. This option follows the ASP state transition diagram. It
    would need four messages for completion.
    
    ---------
    Old text: (Section 4.3.4.3.1)
    ---------

    Alternatively, an interchange of ASP Active messages from each end
    can be performed. This option follows the ASP state transition
    diagram and gives the additional advantage of selecting a particular
    AS to be activated from each end. It is especially useful when an
    IPSP is serving more than one AS. It would need four messages for
    completion.

    ---------
    New text: (Section 4.3.4.3.1) i.e. UNCHANGED versus RFC
    ---------
    Alternatively, an interchange of ASP Active messages from each end
    can be performed. This option follows the ASP state transition
    diagram and gives the additional advantage of selecting a particular
    AS to be activated from each end. It is especially useful when an
    IPSP is serving more than one AS. It would need four messages for
    completion.

    ---------
    Old text: (Section 4.3.4.4.1)
    ---------

    Alternatively, an interchange of ASP Inactive messages from each end
    can be performed. This option follows the ASP state transition
    diagram and gives the additional advantage of selecting a particular
    AS to be deactivated from each end. It is especially useful when an
    IPSP is serving more than one AS. It would need four messages for
    completion.

    ---------
    New text: (Section 4.3.4.4.1) i.e. UNCHANGED versus RFC
    ---------

    Alternatively, an interchange of ASP Inactive messages from each end
    can be performed. This option follows the ASP state transition
    diagram and gives the additional advantage of selecting a particular
    AS to be deactivated from each end. It is especially useful when an
    IPSP is serving more than one AS. It would need four messages for
    completion.
    
    ---------
    Old text: (Section 4.4.3)
    ---------

    The Registration/Deregistration procedures work in the IPSP cases in
    the same way as in AS-SG cases.  An IPSP may register an RK in the
    remote IPSP.  An IPSP is responsible for deregistering the RKs that
    it has registered.

    ---------
    New text: (Section 4.4.3)
    ---------

    The Registration/Deregistration procedures are not recommended in the
    IPSP cases working in SE mode as one or two RC may be involved 
    in the exchange depending of the sequence of events.

    The Registration/Deregistration procedures work in the IPSP cases in
    the same way as in AS-SG cases.  An IPSP may register an RK in the
    remote IPSP.  An IPSP is responsible for deregistering the RKs that
    it has registered.

    ---------
    Old text: (Section 5.5)
    ---------

    These scenarios show a basic example for IPSP communication for the
    three phases of the connection (establishment, data exchange,
    disconnection). It is assumed that the SCTP association is already
    set up. Both single exchange and double exchange behavior are
    included for illustrative purposes.

    5.5.1 Single exchange:

                IPSP-A                           IPSP-B
                  |                                |
                  |-------------ASP Up------------>|
                  |<----------ASP Up Ack-----------|
                  |                                |
                  |<------- ASP Active(RCb)--------|  RC: Routing Context
                  |-----ASP Active Ack (RCb)------>|      (optional)
                  |                                |
                  |                                |
                  |<=========  DATA (RCb) ========>|
                  |                                |
                  |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                  |----ASP Inactive Ack (RCb)----->|        (optional)
                  |                                |
                  |<-----------ASP Down------------|
                  |---------ASP Down Ack---------->|
                  |                                |

    Routing Context are previously agreed to be the same in both
    directions.

    5.5.2 Double exchange:

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

    In this approach, only one single exchange of ASP Up message can be
    considered as enough since the response by the other peer can be
    considered as a notice that it is in ASP_UP state.

    For the same reason, only one ASP Down message is needed since once
    that an IPSP receives ASP_Down ack message it is itself considered as
    being in the ASP_Down state and not allowed to receive ASPSM
    messages.

    ---------
    New text: (Section 5.5)
    ---------

    These scenarios show a basic example for IPSP communication for the
    three phases of the connection (establishment, data exchange,
    disconnection). It is assumed that the SCTP association is already
    set up. Both single exchange and double exchange behavior are
    included for illustrative purposes.

    5.5.1 Single exchange:

                IPSP-A                           IPSP-B
                  |                                |
                  |-------------ASP Up------------>|
                  |<----------ASP Up Ack-----------|
                  |                                |
                  |<------- ASP Active(RCb)--------|  RC: Routing Context
                  |-----ASP Active Ack (RCb)------>|      (optional)
                  |                                |
                  |                                |
                  |<=========  DATA (RCb) ========>|
                  |                                |
                  |<-----ASP Inactive (RCb)--------|  RC: Routing Context
                  |----ASP Inactive Ack (RCb)----->|        (optional)
                  |                                |
                  |<-----------ASP Down------------|
                  |---------ASP Down Ack---------->|
                  |                                |

    No registration/deregistration procedure is supported. Routing 
    Context are previously agreed to be the same in both directions.

    5.5.2 Double exchange:

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

    In this approach, only one single exchange of ASP Up message can be
    considered as enough since the response by the other peer can be
    considered as a notice that it is in ASP_UP state.

    For the same reason, only one ASP Down message is needed since once
    that an IPSP receives ASP_Down ack message it is itself considered as
    being in the ASP_Down state and not allowed to receive ASPSM
    messages.

    Registration/deregistration procedure is supported.

-----------------------------------------------------------------------
         /\\/\0 Herve PELLAN       /\    Telnet:  779-4511
  /\    /  \\                  /\ /  \   non-TN:  (33) 4-76-14-4511
 /  \/\/    \  Telecom Infrastructure \  Fax:     (33) 4-76-14-4323
/    \ \     \_Division      /  /      \ e-mail:
[email-masked]
                                         e-card:
https://ecardfile.com/id/Herve_Pellan
              HEWLETT PACKARD  
              5 Av R. Chanas 38053 Grenoble Cedex 9
              FRANCE
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 6 Dec 2002 10:40:16 -0700

PELLAN,HERVE,

All this was deferred to extension draft.  It looks like you have the
beginnings of a draft here, why don't you start writing an extension
draft?

IMO, the IG is not the place for extensions of this nature.

--brian

PELLAN,HERVE (HP-France,ex1) wrote:                                           (Fri, 06 Dec 2002 17:12:46)

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