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

From: "PELLAN,HERVE (HP-France,ex1)" <[email-masked]>
Date: Wed, 18 Dec 2002 12:27:27 +0100

Hi Sandeep and Brian,

Leaving the RFC as it is is OK for us. 

However, to benefit from people experience on IPSP, I think this would be
valuable to add a few comments (in section 4.4.3 ?) on where one might
better adapted than the other. All the discussions were about this aspect.
The purpose is here not to give rules. The exact text is to be defined but
basically the main lines are:

- Single exchange: RK basically consist of <OPC,DPC> i.e. symetric RK.
- Dynamic Registration, when used on both end, requires double exchange. 
- Double exchange: may provide additional flexibility when several AS are
located on one peer while corresponding remote AS are spreaded on several
ones. Generally speaking, DE is more appropriate with dissymetric RK as OPC
may not have to be specified.

Best Regards,
Herve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 18, 2002 9:57 AM
> To: [email-masked]
> Cc: Javier Pastor-Balbas (ECE); 'PELLAN,HERVE (HP-France,ex1)';
> [email-masked]
> Subject: Re: [Sigtran] IPSP double exchange mode of operation
> 
> 
> 
> 
> 
> 
> bidulock,
> 
> I have no problem with leaving the RFC as it stands. 
> Implementation Guide should
> be updated, as it currently disallows DE.
> 
> Best Regards,
> -Sandeep
> 
> 
> 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)
> >
> >
> >
> > 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
> >
> >
> >
> 
> --
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> 
> 
> 
> 
> DISCLAIMER: This message is proprietary to Hughes Software Systems
> Limited (HSS) and is intended solely for the use of the individual
> to whom it is addressed. It may contain  privileged or confidential
> information  and should not be circulated or used for any 
> purpose other
> than for what it is intended. If you have received this 
> message in error,
> please notify the originator immediately. If you are not the intended
> recipient, you are notified that you are strictly prohibited 
> from using,
> copying, altering, or disclosing the contents of this 
> message. HSS accepts
> no responsibility for loss or damage arising from the use of 
> the information
> transmitted by this email including damage from virus.
> 
> 
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Dec 2002 04:56:18 -0700

Herve,

PELLAN,HERVE (HP-France,ex1) wrote:                                           (Wed, 18 Dec 2002 12:27:27)

> - Single exchange: RK basically consist of <OPC,DPC> i.e. symetric RK.

All RKs (MTP-SAP bindings) are symmetrical in SS7.  OPC/DPC/SI, even
OPC/DPC/SI=5/CIC (ISUP binding) is symmetrical in SS7.

In fact, it would be better to say that in DE all RKs must be made
symmetrical and must be registered in symmetrical pairs, otherwise
user parts will be unable to perform their functions.

> - Dynamic Registration, when used on both end, requires double exchange. 

Write it the other way: when dynamic registration is used in SE, one
side should statically configure the routing key and the other dynamically
register (gee, sounds like the definition of SE).

> may not have to be specified.

All SS7 RKs are symmetrical: even "PC to anywhere" is symmetrical to "anywhere
to PC".  Can you provide an example of where an MTP User needs a truly 
asymmetrical routing key?

--brian

---

From: Tolga Asveren <[email-masked]>
Date: Wed, 18 Dec 2002 07:02:01 -0800 (PST)

Hi,

I personally would disagree to call both DE/SE as
different methods of the same thing, because the
difference between them is really more than just
whether one sends one ASPAC or two. Those are really
two different models.

It also seems to me that WG again tries to solve
problems in hurry without thinking too much for the
details and considering whether the decisions are
architecturally correct(unfortunately common for IPSP
discussions). I am afraid, at the end we migth end up
with 3-4 different kinds of models, where in fact not
all of them are necessary.

I also don't know, why people don't try to challenge
the architectural concerns I raised about DE method.

But of course, here only the number of votes count, so
one can even have 2+2=5 with sufficient number of
votes.

    Tolga

--- "PELLAN,HERVE (HP-France,ex1)"
> > > Does this sound reasonable?
=== message truncated ===

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 18 Dec 2002 12:17:01 -0700

Tolga,

I too would like to see the peer-to-peer architecture
instead of a schizophrenic criss-crossed client-server
relationship.  That's another reason that I think it is
a waste of time trying to "fix" the RFC in the IG for
IPSP.  I would far prefer get back to working on a
peer-to-peer extension draft instead.

--brian

Tolga Asveren wrote:                           (Wed, 18 Dec 2002 07:02:01)