Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2

From: "PELLAN,HERVE (HP-France,ex1)" <[email-masked]>
Date: Tue, 3 Dec 2002 18:35:46 +0100

let me add some clarification to what I was meaning and give some concrete
examples. See my comments below.

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, November 28, 2002 9:26 PM
> To: PELLAN,HERVE (HP-France,ex1)
> Cc: 'Tolga Asveren'; [email-masked]
> Subject: Re: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> 
> 
> HERVE,
> 
> Several comments:
> 
> PELLAN,HERVE (HP-France,ex1) wrote:                           
>                 (Thu, 28 Nov 2002 16:55:49)
> > Hi Tolga,
> > 
> > If using static RC, SE IPSP works, but requires a lot of 
> different RKs for
> > the same local AS. This is not the case for DE IPSP.
> 
> It was shown that SE requires half the RKs of DE, so you will have
> to justify this statement.
> > 

[Herve]  Considering one end-point PC1 talking to two end-points PC2 and
PC3: one will have to specify OPC, DPC in the Routing Key in SE. From the
PC1 perspective, this will translate into RK1=(opc=PC2, dpc=PC1) and
RK2=(opc=pc3=,dpc=PC1), while in DE you can restrict to one RK
(opc=*,dpc=PC1).

[Herve] Now when looking at the exchange on the network, there will be 4 RC
in the game in the DE  case (i.e. two per (PC1, PCx) pair), while in SE
case: there will only one per (PC1 ,PCx) pair in static registration and,
either one or two with dynamic registration.

[Herve] Yes, there twice the number of RC in SE while using DE due the
symetry. The point was about Routing Keys.

> > If using dynamic registration, the race conditions in SE 
> IPSP will prevent
> > it to work, hence the need for DE IPSP.
> 
> There is never a race condition when one side is statically 
> configured and
> the other dynamically registers.
> 

[Herve] I agree: when adding this restriction, you are getting rid of the
race condition. But, possibly there will still be one or two RC in the game.

[Herve] And this is actually one of the advantage of the DE mode. In SE: may
be there will be one RC in the exchange, may be there will be two. This will
really make the SE difficult to tune from our perspective. Did anybody
implemented a stack able to manage this ambiguity ? The DE mode is
determistic whith respect to that: there are always two RC in the game
between two peers. 

> > We think that both large scale configurations and dynamic 
> registration (not
> > necessarily at the same time) will be deployed, and we 
> therefore feel that
> > DE IPSP is needed.
> 
> Perhaps you misunderstand SE.
> 
> > 
> > To add on the type of configuration that we have requests 
> for: the large
> > scale configuration that we are mentionning above includes 
> a mix of IPSP and
> > ASP/SG. Some ASP will definitively talk to SGs AND to IPSP 
> at the same time.
> > In such a case another argument for the dynamic 
> registration and the DE mode
> > is to configure the local AS only in the RK (DPC+SI) in 
> much the same way
> > for the IPSP behavior and for the pure ASP behavior. So to 
> not make much
> > difference from a network configuration standpoint.
> 
> This is certainly not supported in the RFC.  A node acting as 
> ASP and IPSP
> is a relay point which is precluded for IPSP in the RFC.  
> This work was
> deferred to extension draft.
> 

[Herve] I am not quite sure to understand the term "relay".
[Herve] To clarify what I was meaning, let me take a very concrete exemple:
SMS offlload. Let's consider the problem from an SMSC standpoint. The
considered  SMSC 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 through STPs behind 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. 

> > 
> > >From an implementation stand point we think that this is 
> more flexible to
> > have two state machines coexisting (one for the IPSP/ASP 
> side and one for
> > the IPSP/SG side) and some consolidation process on top of 
> those two state
> > machines than having a third hybrid state machine in the 
> game. From a design
> > stand point, we feel this is more flexible and reliable approach.
> 
> This receive much discussion, and we decided that a third 
> approach (SG-SG
> communication or M3PA) was a preferrable design approach.
> 

[Herve] The example given above is being developped now on the basis of what
is described in the RFC text which fits the need.

Regards,
Herve

> --brian
> 
> > 
> > Best Regards,
> > Herve
> > 
> > 
> > > -----Original Message-----
> > > From: Tolga Asveren [mailto:[email-masked]]
> > > Sent: Wednesday, November 27, 2002 1:30 AM
> > > To: [email-masked]
> > > Subject: RE: [Sigtran] Sigtran Plugtest SUA/M3UA/M2UA/IUA - Day 2
> > > 
> > > 
> > > Resending, with some additions......
> > > 
> > > Hi Herve,
> > > 
> > > Most of IPSP discussions were done on the SIGTRAN WG
> > > list. The ones you mention in your message were more
> > > about SG-SG communication, because there the tendency
> > > was to use that model for intra-IP communication.
> > > IMO, for intra-IP communication, the key point is to
> > > define a peer-to-peer relationship. This can be
> > > achieved either with SE model or with SG-SG
> > > communication (kind of M3PA, which defines
> > > relationship between IP-SPs, where IP-SP stands for
> > > IP-Signalling point). DE is a client/server model, and
> > > in fact this kind of relationship between nodes is
> > > already defined for ASP/SGP communication.
> > > Now it seems to me your real concern is about number
> > > of RKs, instead of some race conditions during dynamic
> > > registration(?)
> > > 
> > >     Regards,
> > >      Tolga
> > > 
> > > --- "PELLAN,HERVE (HP-France,ex1)"
> > > <[email-masked]> wrote:
> > > > Hi Tolga,
> > > > 
> > > > > -----Original Message-----
> > > > > From: Tolga Asveren
> > > > [mailto:[email-masked]]
> > > > > Sent: Monday, November 25, 2002 8:55 PM
> > > > > To: [email-masked]
> > > > > Subject: RE: [Sigtran] Sigtran Plugtest
> > > > SUA/M3UA/M2UA/IUA - Day 2
> > > > > 
> > > > > 
> > > > > After long discussions the consensus was that IPSP
> > > > is
> > > > > intended to be AS-to-AS. IMO, DE does not fit this
> > > > > model, so my personal preference is to keep IPSP
> > > > as it
> > > > > is.
> > > > 
> > > >  This is actually the point that we would like to
> > > > discuss with you.
> > > > 
> > > >  Unfortunately we didn't follow the discussion that
> > > > occured, as far as I
> > > > remember on a separate mailing list (by the way, is
> > > > there a way to access
> > > > the mail archive now). At the first plugtest,
> > > > implementor's consensus was
> > > > that the double ended model was more flexible than
> > > > the SE mode. 
> > > > 
> > > >  Since then, things are getting much clearer for HP
> > > > which got customers
> > > > requests which does not fit into the simple AS-to-AS
> > > > model which gets a
> > > > consensus on the mailing list and we do feel this
> > > > flexibility is now a MUST
> > > > for the IPSP-IPSP case. 
> > > > 
> > > >  We have requests to support AS-to-several AS
> > > > (namely hundred of AS): this
> > > > make dynamic registration especially useful and from
> > > > our perspective a MUST:
> > > > It allows to define the AS RK as DPC(,SI) instead of
> > > > having of hundred of
> > > > symetric RK (OPC+DPC).
> > > > 
> > > >  This is a real concrete business case. It has been
> > > > successfully tested in
> > > > interop sessions in DE mode. 
> > > > 
> > > >  Therefore, the DE mode must at least be kept in the
> > > > standard. 
> > > > If we get too far in the standard to drop the SE
> > > > mode, then both modes need
> > > > to coexist to address different architecture.
> > > > 
> > > > Best Regards,
> > > > Herve
> > > > 
> > > > > If the problem case with dynamic registration is
> > > > > presented in the forum (because till now it
> > > > wasn't),
> > > > > we might try to find a solution for it within the
> > > > > boundaries of current IPSP model.
> > > > > DE is totally a different model and thinking that
> > > > both
> > > > > SE/DE can coexist is not logical IMO.
> > > > > 
> > > > >    Regards,
> > > > >     Tolga
> > > > > 
> > > > > --- "PELLAN,HERVE (HP-France,ex1)"
> > > > > <[email-masked]> wrote:
> > > > > > 
> > > > > > > > 2.  Concern about the state of IPSP.  With
> > > > IPSP
> > > > > > as single-exchange,
> > > > > > > > there is an issue related to dynamic
> > > > > > registration.  General 
> > > > > > > consensus
> > > > > > > > is that dynamic registration needs to be
> > > > > > double-exchange to avoid
> > > > > > > > potential for race condition.  Thus, there
> > > > is a
> > > > > > desire to move back
> > > > > > > > to double-exchange.
> > > > > > > [TOLGA] What is exactly the problem scenario?
> > > > Is
> > > > > > the proposal 
> > > > > > > to move just
> > > > > > > dynamic registration to double exchange or the
> > > > > > whole IPSP model? 
> > > > > > 
> > > > > > Hi Tolga,
> > > > > > 
> > > > > > we know that there has been a lot of discussion
> > > > > > about the subject SE IPSP
> > > > > > vs. DE IPSP.
> > > > > > It is not our intention to re-open the technical
> > > > > > parts of these discussions.
> > > > > > However, as Ken indicated in his summary of the
> > > > 2nd
> > > > > > day of the plugtest,
> > > > > > there is an argument to be made to put DE IPSP
> > > > back
> > > > > > in the M3UA
> > > > > > implementor's guide:
> > > > > > 
> > > > > > 1. Both DE and SE IPSP are included in RFC 3332
> > > > > > 2. During the 3rd M3UA plug test, we have
> > > > > > successfully interoperated in DE
> > > > > > IPSP mode, both with static RCs configured and
> > > > with
> > > > > > dynamic registration of
> > > > > > Routing Keys.
> > > > > > 3. There was a clear consensus amongst those
> > > > present
> > > > > > at the plug test that
> > > > > > for an implementation that wants to use dynamic
> > > > > > registration, only DE IPSP
> > > > > > will work.
> > > > > > 
> > > > > > So, for these reasons, 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
> > > > > >                 |              |      
> > > > > > +--------------+
> > > > > >                 |              |       |        
> > > >    
> > > > 
> > > === 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
> > > 
> > _______________________________________________
> > Sigtran mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/sigtran
> 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/
> _______________________________________________
> 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, 3 Dec 2002 11:48:07 -0700

PELLAN,HERVE,

PELLAN,HERVE (HP-France,ex1) wrote:                                           (Tue, 03 Dec 2002 18:35:46)
> symetry. The point was about Routing Keys.

You have miscounted: DE must also register a routing key in the opposite
direction.  Also, SE can use wildcards too.  When performed properly, DE
takes twice the number of RKs as SE (because it must register each traffic
flow in both directions, requiring two RKs where one will do).

> determistic whith respect to that: there are always two RC in the game

On the contrary, having two RCs, one for each half of a traffic flow it the
most problematic part of DE: relating events in one direction to events in
the other.  Unless the node couples these two RCs, there are many problems in
DE.  SE uses one RC to represent one (bi-directional) traffic flow and there
are no problems relating half-flows.  (BTW: Because there are half the RC
values, there are half the routing keys because of the 1:1:1 relationship
between RK:RC:AS in SE.  In DE there are two RKs, two RCs relating to one AS:
this is where the problems start.)

> infrastructure). The number of IPSP peers may be significant as well as the

The RFC does not support ISPS connected to, or acting as STPs.  Only ASPs are
supported in connection to STPs (SGs).  Additional behavior was postponed for
extension draft.

> is described in the RFC text which fits the need.

As relay is not supported in IPSP, I suggest that you contribute to
work on an extension draft for SG-SG behavior.

--brian