Subject: RE: [Sigtran] IPSP double exchange mode of operation

From: [email-masked]
Date: Wed, 18 Dec 2002 09:36:20 +0530

Hi Javier,

I agree with your proposal. This looks to be a good path forward as it would
allow applications to choose any model that suits them and also address the
minimum interoperability issue among IPSPs. IG can be updated accordingly.

Best Regards,
-Sandeep

"Javier Pastor-Balbas (ECE)" <[email-masked]> on
12/09/2002 07:52:39 PM

To:   "'PELLAN,HERVE (HP-France,ex1)'" <[email-masked]>, Sandeep
      Mahajan/HSS@HSS, "[email-masked]'" <[email-masked]>,
      [email-masked]
cc:

Subject:  RE: [Sigtran] IPSP double exchange mode of operation

Hi guys,

It's right that DE is more dynamic than SE which requires a lot more
configuration effort. That was one of the main points in favor of using the DE.
But when discussed, there were just a few people that preferred DE to SE and
then the use of SE was decided. On the other hand there are some operators that
prefer to have everything under control and use the static configuration without
the registration procedures.

From the standards point of view, I see that there should be a minimum
interoperability in the main scenarios used by the standard protocol, i.e. one
implementation will interwork successfully  with any other just implementing the
protocols basics (the MUST clauses). This means that we could think in IPSP of
having a minimum mandatory implementation and a optional enhanced one.

Moreover, I don't see any technical reason to leave out of the spec other
possible options that work and show clear advantages in certain scenarios.

I think we could achieve a consensus solution. I propose to change the IG in
order to:

a) specify the mandatory minimum implementation to achieve interoperability. In
this case SE, as was agreed some months ago (it is the simplest case). Therefore
IPSP SE MUST be supported

b) permit the DE option and enhance the basic protocol to allow handling some
scenarios in a more plug and play fashion.  This is due to the fact that DE is
being asked by operators and has been successfully tested. Since the RC
flexibility in the DE is mainly got with the use of the Registration procedures,
this is also inline with their optionality. Therefore DE MAY be supported.

Does this sound reasonable?

Cheers // Javier.

> -----Original Message-----
> From: PELLAN,HERVE (HP-France,ex1)
> [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 5:13 PM
> To: [email-masked]
> Subject: [Sigtran] IPSP double exchange mode of operation
>
>
> 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
>
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 17 Dec 2002 22:36:37 -0700

Samahajan,

How is this so different than the existing RFC?  The RFC permits
double ended exchanges in all messages (as an alternative) and
even gives an example using DE exchange.  Javier's proposal would
make SE mandatory (when is it not now: it is one alternative),
and DE optional (when it is not now: it is the other alternative).

IMO leave the RFC as it stands.

--brian

[email-masked] wrote:                        (Wed, 18 Dec 2002 09:36:20)

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