Subject: RE: [Sigtran] FW: I-D ACTION:draft-pastor-sigtran-m3ua-ipspcomm-0 0.txt

From: "Bep Verberk" <[email-masked]>
Date: Tue, 28 May 2002 11:50:16 -0400

Javier,
here are my initial comments on the draft.

> 1.1 IPSP Definition
> IP Server Process (IPSP) - A process instance of an IP-based
> application.  An IPSP is essentially the same as an ASP, except that
> it uses M3UA in a point-to-point fashion.  Conceptually, an IPSP does
> not use the services of a Signalling Gateway node.

I object to the defintion of an IPSP in terms of m3ua.
Looking at the m3ua draft I see that is how it's defined there
as well. So apologies for being one who comments/complains
after the fact.

My feeling is that the ASP, SG, and IPSP definitions should not
be based on a specific adaptation layer such a m3ua.

It is OK to define an m3ua-ipsp or an m3ua-asp, but what about
sua ?

> 1.4.1 Routing Contexts and Routing Keys

I'm not sure why this section even exists in here. If you
are talking about an "m3ua-ipsp" type on communication.
There is no need for any routing keys. The End point 
represents an MTP3 address (ie Point Code) - that is all.

Routing Keys and such are necessary at an SG because the SG,
providing the Gateway function, needs to know how to direct 
messages to the ASs (by DPC, by OPC, etc). 

For IPSP this distribution function behind the IPSP does
not need to be defined as part of the IPSP discussions. 

> 1.4.3.1 Application Server Redundancy
This section again is confusing me because it refers to
things happening behind the IPSP as if the IPSP was 
a SG distributing to ASPs.
The m3ua-IPSP dicussion should focus on sending MTP3 user messages
between 2 IP nodes, each owning a Point Code. What happens
to the messages after they reach the IP node is not a concern to
the IPSP protocol.

After reading a little further I see you would like to be able to
have multiple IPSP nodes representing a single Point Code and
therefore need to have other IPSPs sending messages to that point
code be able to pick (and hence the need to routing keys). 
Personnally I think this is a bad idea and only complicates the whole
thing. 

Bep 

> -----Original Message-----
> From: Javier Pastor-Balbas (ECE)
> [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2002 9:51 AM
> To: [email-masked]'
> Subject: [Sigtran] FW: I-D
> ACTION:draft-pastor-sigtran-m3ua-ipspcomm-00.txt
> 
> 
> Hi guys, 
> 
> Here it is. It is a compilation of all the literature 
> regarding IPSP. It comes from the RFC, but it is only about 
> IPSPs to avoid mixing concepts. I hope it is easier to read 
> and understand.
> 
> What we try with this document is to set a clear basis to 
> discuss over. By completing this draft, finding the holes,  
> making it more understandable and workable, we can complete 
> the work for the current RFC and focus in new scenarios and 
> functionalities.
> 
> Therefore our first task would be to detect the open issues. 
> Afterthat we should find the solutions.
> 
> I'm writing another draft with a proposed solution to allow 
> compatibility between both types of exchanges. I hope to sent 
> it out this week.
> 
> 
> Cheers // Javier
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, May 28, 2002 1:41 PM
> Subject: I-D ACTION:draft-pastor-sigtran-m3ua-ipspcomm-00.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 
> 	Title		: IPSP Commmunication Description for M3UA
> 	Author(s)	: J. Pastor, H. Schwarzbauer
> 	Filename	: draft-pastor-sigtran-m3ua-ipspcomm-00.txt
> 	Pages		: 40
> 	Date		: 24-May-02
> 	
> This document is a compilation of all the IPSP literature presented
> in the M3UA (MTP-3 User Adaptation Layer) RFC. It contains a
> description of IPSP commmunication showing the main concepts and
> procedures.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-pastor-sigtran-m3ua-
ipspcomm-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-pastor-sigtran-m3ua-ipspcomm-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-pastor-sigtran-m3ua-ipspcomm-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 29 May 2002 12:26:52 +0200

Hi Brian, 

Thanks a lot for your comments. They are very helpful to see your concept more in detail. After reading it I got the following conclusion:

There are some functions common to ASP and SGP in the IPSPs, but just putting together ASP and SGP will not be an IPSP, or at least it would be very difficult to deal with an IPSP composed of those functions. You just need to integrate the needed components and make an IPSP with single state machine. :-D Then everything works in a very easy way.

Please, see below the specific comments on yours...

> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Tuesday, May 28, 2002 5:34 PM
> To: Javier Pastor-Balbas (ECE)
> Cc: [email-masked]'
> Subject: Re: [Sigtran] FW: I-D
> Please see comments below...
> 
> Javier Pastor-Balbas (ECE) wrote:               (Tue, 28 May 
> 2002 15:51:28)
> 
> >  1.1 IPSP Definition
> > 
> >     A key point to understand the IPSP concept is said in [M3UA-RFC]
> >     section 4.3, when describing the procedures and is the 
> following:
> > 
> >     "[...] only the SGP/ASP case is described but the SGP 
> side of the
> >     procedures also apply to an IPSP sending traffic to an 
> AS consisting
> >     of a set of remote IPSPs."
> 
> I find this definition rather confusing: one the one hand "an 
> IPSP does
> not use the services of a Signalling Gateway node," yet on the other
> hand "the SGP side of the procedures also apply to an IPSP 
> sending traffic
> to an AS."
> 
It comes from the original wording. I already see it confusing. It should say the "[...]not use the services of a Signalling Gateway node related to SS7 management/routing"

> Is this meant to mean that the IPSP "contains" the SGP procedures that
> would normally be executed by an SG, but that it does not interface to
> and external SG?  So the SG functionality (SGPF), with the exception
> of connection to the SS7 network is contained within the 
> IPSP?  How does
> this differ than just grouping ASPF and SGPF in the same box?
> 

Yes, you got it. All the SS7 related functionality included in the SGPF is not used. IPSP only have the routing and state machine needed to communicate with a remote AS.

> >  1.2 Protocol Architecture.
> > 
> >     The framework architecture that has been defined for 
> SCN signalling
> >     transport over IP uses multiple components, including a common
> >     signalling transport protocol and an adaptation module 
> to support the
> >     services expected by a particular SCN signalling 
> protocol from its
> >     underlying protocol layer.
> > 
> >     Within the framework architecture, this document 
> defines an MTP3-User
> >     adaptation module suitable for supporting the transfer 
> of messages of
> >     any protocol layer that is identified to the MTP Level 
> 3 as an MTP
> >     User.  The list of these protocol layers includes, but 
> is not limited
> >     to, ISDN User Part (ISUP), Signalling Connection Control Part
> >     (SCCP), and Telephone User Part (TUP).  TCAP or RANAP 
> messages are
> >     transferred transparently by the M3UA protocol as SCCP 
> payload, as
> >     they are SCCP-User protocols.
> 
> This is confusing.  This protocol architecture describes the 
> M3UA backhaul
> case and says nothing about IPSP.  IPSP to IPSP relationship is not an
> MTP to MTP-User relationship: that is the backhaul case.  
> IPSP cannot use
> this protocol boundary to communication between IPSPs, 
> otherwise each IPSP
> will have to contain both MTP3 and MTP3-User functionality.  
> MTP3 capabilities
> are across the NIF from M3UA in the backhaul case.  MTP3 
> capabilities only
> reside at the SG in the backhaul model.  If IPSP has MTP3 and 
> MTP3-User
> functions, then it contains ASPF and SGPF.
> 

It basically says that M3UA is used to transport SS7 signaling protocols that are referred as MTP3-users as payload. How to you get the idea that MTP3 is needed?  

> >  1.3 Services Provided by the M3UA Layer
> > 
> >     The M3UA Layer at an IPSP provides the equivalent set 
> of primitives
> >     at its upper layer to the MTP3-Users as provided by the 
> MTP Level 3
> >     to its local MTP3-Users at an SS7 SEP.
> > 
> >     In IPSP communication the M3UA layer is used for point-to-point
> >     signalling between two IP Server Processes (IPSPs).  In 
> this case,the
> >     M3UA layer provides the same set of primitives and 
> services at its
> >     Upper layer as the MTP3.
> > 
> >     The expected MTP3 services are not offered remotely 
> from an SGP.  The
> >     MTP3 services are provided but the procedures to support these
> >     services are a subset of the MTP3 procedures due to the 
> simplified
> >     point-to-point nature of the IPSP to IPSP relationship.
> > 
> >  1.3.1 Support for the Transport of MTP3-User Messages
> > 
> >     The M3UA layer provides the transport of MTP-TRANSFER primitives
> >     across an established SCTP association between IPSPs.
> > 
> >     The M3UA layer does not impose a 272-octet signalling 
> information
> >     field (SIF) length limit as specified by the SS7 MTP 
> Level 2 protocol
> >     [7,8,9].  Larger information blocks can be accommodated 
> directly by
> >     M3UA/SCTP, without the need for an upper layer segmentation /
> >     reassembly procedure as specified in recent SCCP or 
> ISUP versions.
> 
> Again, this describes the MTP3 to MTP3-User boundary.  If 
> IPSP uses this
> boundary it will have to be both MTP3 (SGPF) and MTP3-User (ASPF).
> 

M3UA uses the same boundary with the MTP3-users as MTP3 did to hide the MTP3-user all about the new network. That's all about this. No MTP3 is needed.

> >  1.4 Functional Areas
> >  1.4.1.1 Overview
> >     The distribution of SS7 messages between an IPSP within an
> >     Application Server and another IPSP within a remote Application
> >     Server is determined by the Routing Keys and their 
> associated Routing
> >     Contexts. A Routing Key is essentially a set of SS7 
> parameters used
> >     to filter SS7 messages, whereas the Routing Context 
> parameter is a 4-
> >     byte value (integer) that is associated to that Routing 
> Key in a 1:1
> >     relationship. The Routing Context therefore can be 
> viewed as an index
> >     into a sending node's Message Distribution Table containing the
> >     Routing Key entries.
> 
> Again, in the backhaul model, only SG's distribute messages based on
> Routing Keys.  AS send messges to SGs based on a full-duplex 
> connection
> identified by Routing Context.  All messages from a given AS 
> have a one
> to one relationship with a RC and there is no need to apply any RK
> whatsoever.  If IPSP is applying RKs to distribute traffic, 
> it is performing
> the SG functions.
>

IPSP is just performing the routing functions needed to route the messages to the peer AS. RK is just the set of parameters that you use to find the destination. RC can be avoided if one IPSP just serves to one AS. As I said in a previous mail:

"You can call the parameters you use to route RK or whatever other thing. But when a message comes from the MTP3-user, you need to send it to a remote node. To get this routing you should look into the Routing Label and get the IP address where the remote node is."

This routing is needed in all the nodes that use DPCs in the IP network.

> There is much more about passing mesages based on routing 
> keys, provisioning
> routing keys, registering routing keys, which is an SG 
> function only in the
> backhaul model, but somehow to be performed by the IPSP?
> 

You may define the nodes you can reach locally in the IPSP. And the relation between the node's DPC and the IP address. If you want to have replication (more than one IPSP serves the same AS) you should also provision it. Whether statically or dynamically is currently a choice.

But this concerns to the management of a remote AS, what is also included in a SG. It simply follows the model "ASPs serving ASes"

> >  1.4.1.4 Message Distribution at the IPSP
> > 
> >     To direct messages received from the MTP3-User to the 
> appropriate IP
> >     destination, an IPSP must perform a message 
> distribution function
> >     using information from the received MTP3-User message.
> > 
> >     To support this message distribution, the IPSP might, 
> for example,
> >     maintain the equivalent of a network address translation table,
> >     mapping incoming SS7 message information to an 
> Application Server for
> >     a particular application and range of traffic.  This could be
> >     accomplished by comparing elements of the incoming SS7 
> message to
> >     currently defined Routing Keys in the IPSP.
> > 
> >     These Routing Keys could in turn map directly to an Application
> >     Server that is enabled by one or more remote IPSPs.  
> These remote
> >     IPSPs provide dynamic status information regarding their
> >     availability, traffic handling capability and 
> congestion to the IPSP
> >     using various management messages defined in the M3UA protocol.
> > 
> >     The list of IPSPs in an AS is assumed to be dynamic, taking into
> >     account the availability, traffic handling capability 
> and congestion
> >     status of the individual IPSPs in the list, as well as 
> configuration
> >     changes and possible failover mechanisms.
> > 
> >     Normally, one or more IPSPs are active (i.e., currently 
> processing
> >     traffic) in the AS but in certain failure and 
> transition cases it is
> >     possible that there may be no active IPSP available.  Broadcast,
> >     loadsharing and backup scenarios are supported.
> > 
> >     When there is no matching Routing Key entry for an incoming SS7
> >     message from the local MTP3-User to M3UA, a default 
> treatment MAY be
> >     specified.  Possible solutions are to provide a default 
> Application
> >     Server at the IPSP that directs all unallocated traffic 
> to a (set of)
> >     default remote IPSP(s), or to drop the message and provide a
> >     notification to layer management. The treatment of unallocated
> >     traffic is implementation dependent.
> 
> This is not required of an ASP.  An ASP can distribute 
> messages based on
> the AS identity (which *is* the RC).  No examination of 
> MTP3-User messages
> is required.  Only the SG is required to examine message 
> contents to apply
> a Routing Key.  Why is the IPSP performing this SG function?
> 

RC use is not compulsory. It is an optional parameter whenever an IPSP does not serve to more than on ASes. 

If you don't use the RC, you should be able to filter possible erroneous messages coming to your node, and you can do it simply checking the DPC. If your node implements policy you could just allow some messages to come in. This function is what is also implemented in the each of the peers that take part in a AS-SG communication.

Evenmore, you might check (when using the RC) if it was correctly assigned. For that you also need to check the Routing Label as minimum.

> >  1.4.2 SS7 and M3UA Interworking
> > 
> >     Since IPSPs use M3UA in a point-to-point fashion, there 
> is no concept
> >     of routing of messages beyond the remote end.  
> Therefore, SS7 and
> >     M3UA interworking is not necessary for this model.
> 
> I would say it is not supported by the model.  It has been agreed that
> peer-to-peer M3UA and SS7 interworking is a necessary evolution.

Yes I agree, but it is talking about the IPSP communcation only, and not about the complete network.

> 
> >  1.5 Sample Configuration: SCCP Transport between IPSPs
> > 
> > 
> >                       Figure 1
> > 
> > 
> >             ********    IP    ********
> >             * IPSP *----------* IPSP *
> >             ********          ********
> > 
> >             +------+          +------+
> >             |SCCP- |          |SCCP- |
> >             | User |          | User |
> >             +------+          +------+
> >             | SCCP |          | SCCP |
> >             +------+          +------+
> >             | M3UA |          | M3UA |
> >             +------+          +------+
> >             | SCTP |          | SCTP |
> >             +------+          +------+
> >             |  IP  |          |  IP  |
> >             +------+          +------+
> >                |________________|
> >                 ----------------
> > 
> >     This example shows an architecture where no Signalling 
> Gateway is
> >     used.
> 
> Yet you have just described an IPSP as having all the 
> capabilities of a
> Signalling Gateway except the useful interconnection to the 
> SS7 network.

Agreed.

> > 
> >  1.6 Definition of M3UA Boundaries
> > 
> >     As defined in [RFC-M3UA].
> 
> Problem.  The message boundaries in M3UA are MTP3 to MTP3-User.

And what about the LM and SCTP ?? This is also needed.

> 
> >  4. Procedures
> > 
> >     The M3UA layer needs to respond to various local primitives it
> >     receives from other layers as well as the messages that 
> it receives
> >     from the peer M3UA layer.  This section describes the 
> M3UA procedures
> >     in response to these events.
> > 
> >  4.1 Procedures to Support the M3UA-User
> > 
> >  4.1.1 Receipt of Primitives from the M3UA-User
> > 
> >     On receiving an MTP-TRANSFER request primitive from an 
> upper layer at
> >     an IPSP, the M3UA layer sends a corresponding DATA message (see
> >     Section 3 of [M3UA-RFC]) to its M3UA peer.  The M3UA 
> peer receiving
> >     the DATA message sends an MTP-TRANSFER indication 
> primitive to the
> >     upper layer.
> > 
> >     The M3UA message distribution function (see Section 
> 1.4.2.1 in [M3UA-
> >     RFC]) determines the Application Server (AS) based on 
> comparing the
> >     information in the MTP-TRANSFER request primitive with 
> a provisioned
> >     Routing Key.
> > 
> >     From the list of IPSPs within the AS table, a remote 
> IPSP in the ASP-
> >     ACTIVE state is selected and a DATA message is 
> constructed and issued
> >     on the corresponding SCTP association.  If more than 
> one IPSP is in
> >     the ASP-ACTIVE state (i.e., traffic is to be loadshared 
> across more
> >     than one IPSP), one of the IPSP in the ASP_ACTIVE state 
> is selected
> >     from the list.  If the IPSPs are in Broadcast Mode, all 
> active IPSPs
> >     will be selected and the message sent to each of the 
> active IPSPs.
> >     The selection algorithm is implementation dependent but 
> could, for
> >     example, be round robin or based on the SLS or ISUP CIC.  The
> >     appropriate selection algorithm must be chosen 
> carefully as it is
> >     dependent on application assumptions and understanding 
> of the degree
> >     of state coordination between the ASP_ACTIVE IPSPs in the AS.
> > 
> >     In addition, the message needs to be sent on the 
> appropriate SCTP
> >     stream, again taking care to meet the message 
> sequencing needs of the
> >     signalling application. DATA messages MUST be sent on 
> an SCTP stream
> >     other than stream '0'.
> 
> Problem here: does one IPSP's SGPF have to keep track of the state of
> all connection IPSP's ASPF?  And visa versa?  And in DE once for each
> direction?  So for a given connection betwen IPSP-A and IPSP-B, the
> IPSP-A SGPF must track its own state and the state of the 
> IPSP-B ASPF, and
> the IPSP-B SGPF must track its own state and the state of the 
> IPSP-B ASPF?
> For DE this is for the same full-duplex communication, so 
> what happens when
> the 4 sets of state for the same communicating pair of 
> MTP3-Users do not 
> agree?  How are these 4 sets of state for the same 
> full-duplex communication
> synchronized?
> 

I see your model is not too good here...

If we just see and IPSP and not an ASPF+SGPF things are much easier:

See IPSPas a whole (different from ASP and SGP but with common elements and one state as a whole and independent entity), then...
IPSP-A keeps track of IPSP-B state and viceversa. That's all.  The state machine for an IPSP is the same as the state machine for the ASP, see the drawing.
And this is valid for SE and DE with the difference that for the current SE we should change a little bit the IPSP state machine.

> 
> >  4.3.4 ASPM Procedures for Peer-to-Peer Messages
> > 
> >  4.3.4.1 ASP Up Procedures
> > 
> >     After an IPSP has successfully established an SCTP 
> association to a
> >     peer IPSP, the peer IPSP waits for the IPSP to send an ASP Up
> >     message, indicating that the IPSP M3UA peer is 
> available.  One IPSP
> >     is always the initiator of the ASP Up message.  This 
> action MAY be
> >     initiated at the IPSP by an M-ASP_UP request primitive 
> from Layer
> >     Management or MAY be initiated automatically by an M3UA 
> management
> >     function.
> 
> What happens when an IPSP's SGPF is not available but its 
> ASPF is?  The
> SGPF at IPSP-A responds with an ASPUP ACK to ASPF at IPSP-B, but there
> is no ASPF at IPSP-A to communicate with the SGPF at IPSP-B?  
> If you are
> going to criss-cross you will need double-ended ASPUP.
> 

This scenarios only happens if you model your IPSP as SGPF+ASPF. IPSP is a whole.

> >  4.3.4.1.2 Practical  Considerations (ASP Up)
> > 
> >     To follow this process means an interchange of ASP Up 
> messages from
> >     each end. Therefore four messages would be needed for 
> completion.
> > 
> >     Another option is to consider a simple exchange. This is a
> >     simplification for the processed explained above. An IPSP may be
> >     considered in the ASP-INACTIVE state after an ASP Up or 
> ASP Up Ack
> >     has been received from it. This option does not follow 
> the ASP state
> >     transition diagram.
> 
> That would be nice, but it is not simple: there is ASPF and 
> SGPF at either
> end and double-exchange of ASPUP is required to establish 
> both directions
> of traffic under the DE criss-cross model.
> 

Again, this is a failure of your modeling. :-)

> >  4.3.4.2 ASP-Down Procedures
> > 
> >     The IPSP will send an ASP Down message to a peer IPSP 
> when the IPSP
> >     wishes to be removed from service in all Application 
> Servers that it
> >     is a member and no longer receive any DATA, SSNM or 
> ASPTM messages.
> >     This action MAY be initiated at the IPSP by an 
> M-ASP_DOWN request
> >     primitive from Layer Management or MAY be initiated 
> automatically
> >     by an M3UA management function.
> > 
> >     Whether the IPSP is permanently removed from any AS is 
> a function of
> >     configuration management.  In the case where the IPSP 
> previously used
> >     the Registration procedures (see Section 4.4.1) to 
> register within
> >     Application Servers but has not deregistered from all 
> of them prior
> >     to sending the ASP Down message, the peer IPSP MUST 
> consider the ASP
> >     as Deregistered in all Application Servers that it is 
> still a member.
> > 
> 
> > 
> >  4.3.4.2.1 Practical  Considerations (ASP Down)
> > 
> >     To follow this process means an interchange of ASP Down 
> messages from
> >     each end. Therefore four messages would be needed for 
> completion.
> > 
> >     Another option is to consider a simple exchange. This is a
> >     simplification for the processed explained above An IPSP can be
> >     considered in the ASP-DOWN state after an ASP Down or 
> ASP Down Ack
> >     has been received from it. This option does not follow 
> the ASP state
> >     transition diagram.
> > 
> >     The IPSP may inform Layer Management of the change in 
> state of the
> >     remote IPSP using M-ASP_DN indication or confirmation 
> primitives.
> > 
> >     If for any local reason (e.g., management lockout) an 
> IPSP cannot
> >     respond to an ASP Down message with an ASP Down Ack message, it
> >     responds to an ASP Down message with an Error message 
> with reason
> >     "Refused - Management Blocking" and leaves the remote 
> IPSP in the
> >     ASP-INACTIVE state.
> 
> Again, because ASPF and SGPF in each IPSP is independent in 
> DE model (each has
> its own set of state), it is necessary to perform 
> double-exchange of ASPDN.
> 

Model IPSP as a whole and you avoid those problems. You just don't keep the states of the different components/functions that are included in a software program....

> >  4.3.4.3.1 Practical Considerations (ASP Active)
> > 
> >     Either of the IPSPs can initiate communication.
> > 
> >     An interchange of ASP Active messages from each end is 
> performed.
> >     This behavior gives the additional advantage of allowing the
> >     selection of a particular AS to be activated from each 
> end. It is
> >     especially useful when an IPSP is serving more than one 
> AS. It will
> >     need four messages for completion.
> > 
> >     Alternatively a simplification of this process can also be
> >     implemented. When an IPSP receives an ASP Active, it 
> should mark the
> >     peer as ASP-ACTIVE and return an ASP Active Ack message. An ASP
> >     receiving an ASP Active Ack message may mark the peer 
> as ASP-Active,
> >     if it is not already in the ASP-ACTIVE state. This 
> option does not
> >     follow the IPSP state transition diagram. Only two 
> messages will be
> >     needed for completion.
> 
> In the DE exchange it is clear that each IPSP needs a RK 
> (acting as an SG)
> and each IPSP will use RC in the reverse direction (acting as 
> ASP).  Therefore
> IPSP is, again, just a combination of ASP and SGP.
> 
As you can see, there are some functions common to ASP and SGP in the IPSPs, but just putting together ASP and SGP will not be an IPSP, or at least it would be very difficult to deal with an IPSP composed of those functions. You just need to integrate the needed components and make an IPSP with single state machine. :-D

> 
> >  4.3.4.4.1 Practical Considerations (ASP Inactive)
> > 
> >     An interchange of ASP Inactive messages from each end 
> is performed.
> >     This option gives the additional advantage of allowing 
> the selection
> >     of 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.
> > 
> >     A simplification can apply for some cases. An IPSP may 
> be considered
> >     in the ASP-INACTIVE state by a remote IPSP after an ASP 
> Inactive or
> >     ASP Inactive Ack message has been received from it. 
> This option does
> >     not follow the IPSP state transition diagram. Only two 
> messages will
> >     be needed for completion.
> 
> Same story here.
> 
> >  4.4 Routing Key Management Procedures [Optional]
> > 
> >  4.4.1 Registration
> > 
> >     An IPSP MAY dynamically register with a peer IPSP as an 
> IPSP within
> >     an Application Server using the REG REQ message. A Routing Key
> >     parameter in the REG REQ message specifies the 
> parameters associated
> >     with the Routing Key.
> > 
> >     The peer IPSP examines the contents of the received Routing Key
> >     parameter and compares it with the currently provisioned Routing
> >     Keys.  If the received Routing Key matches an existing 
> IPSP Routing
> >     Key entry at the peer IPSP, and the IPSP is not 
> currently included in
> >     the list of IPSPs for the related Application Server, 
> the peer IPSP
> >     MAY authorize the IPSP to be added to the AS.  Or, if 
> the Routing Key
> >     does not currently exist and the received Routing Key 
> data is valid
> >     and unique, a peer IPSP supporting dynamic configuration MAY
> >     authorize the creation of a new Routing Key and related 
> Application
> >     Server and add the IPSP to the new AS.  In either case, 
> the peer IPSP
> >     returns a Registration Response message to the IPSP, 
> containing the
> >     same Local-RK-Identifier as provided in the initial 
> request, and a
> >     Registration Result "Successfully Registered".  A unique Routing
> >     Context value assigned to the peer IPSP Routing Key is 
> included. The
> >     method of Routing Context value assignment at the peer IPSP is
> >     implementation dependent but must be guaranteed to be 
> unique for each
> >     Application Server or Routing Key supported by the peer IPSP.
> 
> Again for registration, in the DE model, one IPSP is acting as an SG
> (installing RKs, making sure they are unique, assigning RCs, making a
> table for routing messages based on message contents) to the 
> other acting as
> an AS.  And then visa versa in the opposite direction.  Each 
> IPSP is both
> SG and AS.  This can be accomplished by placing ASPF and SGPF 
> in the same
> box.  Why throw away SS7 network communication?
> 

SS7 communication in not thrown away. It is just in the other side of the SG.
(about registration and your model, I've already answered)

> Indeed this is the same half-baked criss-cross DE model that 
> has already
> cause so much problems.  Why not say that this IPSP is ASP 
> and SGP in the
> same box and be done with it?  This IPSP affords nothing that 
> is not already
> acheivable by double symmetrical backhaul between paired 
> AS/SG.  There is
> no need to define anything.
> 

As you probably see taking IPSP as two different things with differents state machines, with messages or new primitives between them is not worth. It creates more problems and does not solve any single scenario. Taking IPSP as whole as ASP is, is definitely much more easier. ;-)

> But it does not address the needs of peer-to-peer 
> communication within the
> IP network.  This is client-server (it still operates on the 
> MTP3/MTP3-User
> boundary) and essentially is just double-backhaul.  Why waste 
> your time on
> this?

Forget your model and see IPSP as a whole. You'll probably realise that it is different and complementary to SG-SG.   :-)

I'm really happy of being produced this draft. It can hopefully help us to understand each other view and work as a group looking for common targets.

> 
> SG-SG addresses actual peer-to-peer communication between IP 
> nodes in an
> IP network in accordance with the architectural framework for SIGTRAN.
> 

I don't think this is true. SG to SG is defined in the framework just for M2PA. Check RFC2719.
But I would like to discuss about M3UA SG-SG     :-)

Cheers // Javier.

> --brian
> 
> -- 
> 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: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Wed, 29 May 2002 12:40:04 +0200

Hi Bep, 

Thanks a lot for your comments. See mine on yours below...

-----Original Message-----
From: Bep Verberk [mailto:[email-masked]]
Sent: Tuesday, May 28, 2002 5:50 PM
To: 'Javier Pastor-Balbas (ECE)'
Cc: [email-masked]'
Subject: RE: [Sigtran] FW: I-D ACTION:draft-pastor-sigtran-m3ua-ipspcomm-0 0.txt

Javier, 
 
[Javier:] This is a historical fact. The general concept is the same but the particulars are different.  Currently we need to solve this issues and we just focused on M3UA. I just copied it from the RFC... 

[Javier:] Take into account that from the message you get from the user, you need to route it to the final destination. What RK does is to help finding the possible IP destinations where that message can be directed to get the final AS. In the simpler case, only one IPSP will serve the AS.

[Javier:] Why do you say this is not needed? How would you do it?

[Javier:] Well I left aside my personal thoughts about this. I was simply following the model from the RFC. You can decide just to implement one node per SPC and no redundancy. It is the easier approach.

Cheers // Javier.

Bep 
ipspcomm-00.txt