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

From: "Javier Pastor-Balbas (ECE)" <[email-masked]>
Date: Tue, 28 May 2002 15:51:28 +0200

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.

Date: Tue, 28 May 2002 15:54:25 +0200

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 28 May 2002 10:13:39 -0400

Javier,

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Javier Pastor-Balbas (ECE)
> 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.
>
[TOLGA] It is much longer than I expected :-)
>
> 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.
[TOLGA] I propose that before you write it, first to have some discussions
on the document you sent recently. Otherwise we will have an inflation of
documents, and people might get confused, as they were confused with the
current M3UA drafts explanation about IPSP mode.

Send a message to:
	[email-masked].
In the body type:

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 28 May 2002 10:33:44 -0500

Javier,

Please see comments below...

Javier Pastor-Balbas (ECE) wrote:               (Tue, 28 May 2002 15:51:28)

>  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.
> 
>     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."

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?

>  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.

>  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).

>  1.4 Functional Areas
> 
>  1.4.1 Routing Contexts and Routing Keys
> 
>  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.

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?

>  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?

>  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.

>  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.
> 
>  1.6 Definition of M3UA Boundaries
> 
>     As defined in [RFC-M3UA].

Problem.  The message boundaries in M3UA are MTP3 to MTP3-User.

>  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?

>  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.

>  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.

>  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.

>  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.

>  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?

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.

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?

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

--brian

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