Subject: [Sigtran] I-D ACTION:draft-ietf-sigtran-signalling-over-sctp-applic-04.txt

From: Coene Lode <[email-masked]>
Date: Wed, 6 Mar 2002 09:39:34 +0100

Folks,

new version of the Telephony signalling over SCTP applicability statement is
out.
Javier and me will do some editing in Minneapolis. 
If you have suggestions, new text, corrections, removals..., send them to us
and we'll include them.
After Minneapolis, we will issue a new draft.

yours sincerly,
Lode

Siemens atea
atealaan 34          2200 Herentals, Belgium
E-mail: [email-masked]
Tel: +32-14-252081
Fax: +32-14-253212

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 05, 2002 12:32 PM
Cc: [email-masked]
Subject: [Sigtran] I-D
ACTION:draft-ietf-sigtran-signalling-over-sctp-applic-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Signaling Transport Working Group of the
IETF.

	Title		: Telephony Signalling Transport over SCTP
applicability
                          statement
	Author(s)	: L. Coene, J. Pastor
	Filename	:
draft-ietf-sigtran-signalling-over-sctp-applic-04.txt
	Pages		: 18
	Date		: 04-Mar-02
	
This document describes the applicability of the Stream Control
Transmission Protocol (SCTP)[RFC2960] for transport of telephony
signalling information over IP infrastructure. Special
considerations for using SCTP to meet the requirements of
transporting telephony signalling [RFC2719] are discussed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-signalling-over-sctp-
applic-04.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-ietf-sigtran-signalling-over-sctp-applic-04.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-ietf-sigtran-signalling-over-sctp-applic-04.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: Wed, 6 Mar 2002 09:43:02 +0100

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 6 Mar 2002 04:46:56 -0600

Lode,

A few comments on this draft:

Section 2:

>   ...            Message boundaries are preserved during data
>   transport and so no message delineation is needed. ...

Yet, each UA message has a common header which contains a label
and a length which indicates the length of the message.  This is
a message delimitation.  Why is it present in each UA if it is
not required?

>                                                  ... The user data can
>   be delivered by the order of transmission within a stream(in
>   sequence delivery) or the order of arrival.

Unordered delivery in SCTP and "order of arrival" delivery are different
things.  SCTP is permitted to place a priority on out of order packets
from various streams.  Preference for delivery of stream "0" unordered
packets ahead of other stream unordered packets is of significant advantage
to most UAs (regarless of order of arrival).  Please use the term
"unordered delivery" instead of "order of arrival".

>   SCTP can be used to provide redundancy and fault tolerance at the
>   transport layer and below. Telephony applications needing this level
>   of fault tolerance can make use of SCTP's multi-homing support.

"Fault tolerance" usually has a different connotation when used in
telephony related computing.  It indicates a level of reliability
(greater than 5 9's).  Please reword as follows:

<   SCTP can be used to provide redundancy at the transport layer and
<   below. Telephony applications needing this level of redundancy can
<   make use of SCTP's multi-homing support.

Section 3.1:

>                                               ...  Additionally,
>   telephony applications may use SCTP stream based flow control
>   [SCTPFLOW].

I believe that stream based flow controls were dropped (in favor of
application level flow controls).  Please remove this sentence.

Section 3.2:

>   Telephony systems often must achieve high availability in operation.

Again, "high availability" has the connotation of a specific level
of reliability in telephony related computing (in this case less than
5 9's).  Please reword as:

<   Telephony systems often must achieve redundancy in operation.

or

<   Telephony systems often must have no single point of failure in
<   operation.

>   transport layer and below must be detected very fast so that the

grammar, reword as:

<   transport layer and below must be detected quickly so that the

>   For example, they are often required to be able to preserve stable
>   calls during a component failure. Therefore error situations at the
>   transport layer and below must be detected very fast so that the
>   application can take approriate steps to recover and preserve the
>   stable calls. ...

This example is a poor one and shows an utter lack of understanding
for telephony.  Stable calls have *no* signalling associated with them.
It is only a call in transition that has signalling.  Signalling
transport need not worry about affecting stable calls.  Only redundant
systems maintaining call state need worry about this.  While this is
a system requirement for an MG or MGC, it has nothing to do with
signalling components.  Also, sharing of call state between redundant
systems is explicitly excluded from the scope of the UAs.  Please
remove this example: it makes the applicability statement sound foolish.

On the other hand, telephony applications pose requirements on the
availability of signalling paths to meet service availability and
performance requirements.  SS7 has such signalling relation availability
requirements.  These are the telephony requirements which impose on
SCTP's ability to detect failures.  (Again, nothing to do with call
state.)  Please replace this example in section 3.2 with words to this
effect.

Section 3.2.2:

>   For faster detection of (un)availability of idle paths, the
>   telephony application may consider lowering the SCTP parameter
>   HB.interval. It should be noted this will result in a higher traffic
>   load.

It is not always true that lowered HB.interval will incresae traffic
load.  Please change "will result" to "might result".

Section 3.2.3:

>   Setting Path.Max.Retrans and Association.Max.Retrans SCTP parameters
>   to lower values will speed up both destination address and peer
>   failure detection. However, if these values are set too low, the
>   probability of false detections will increase.

What false detection?  A retransmission is a retransmission.  There is
no "false" retransmission or "false detection" mentioned anywhere.
In tests we have shown that Path.Max.Retrans of zero (0) (changing
destination address on every retransmission) works quite fine.  I don't
understand what you are trying to warn against here...

Section 3.3:

>   Telephony applications often require short end-to-end message
>   delays.  The methods described in section 3.2.1 on lowering RTO and
>   not using delayed SACK may be considered.

Not using delayed SACK does nothing to shorten end-to-end message
delay.  Please remove it.

Section 4:

>   Users Adaptation Layers are defined to substitute the telephony
>   signaling protocol that is below of the telephony signaling protocol
>   to be relayed.

"that is below of the"????  This sentence is so malformed I don't know
what it means.  Please correct.

Section 4:

>      - Support management of SCTP transport associations and traffic
>         between SGs and ISEPs or two ISEPs

It is a sore point that several UAs do *not* adequately support
management between "two ISEPs."

Section 4:

>                 SP:   Signaling Protocol

What is shown is not a signalling protocol, but a signalling protocol
user.  Please change to SPU (Signalling Protocol User).

>                 TTST: Traditional Telephony Signaling Transport

The only traditional SS7 signalling that qualifies as a transport
is TCAP.  I suggest you use "Protocol" instead of "Transport".
Please replace TTST with TTSP (Traditional Telephony Signalling
Protocol).

>   It is also referred as SG to AS communication. AS I the name that

Typo: change "AS I the name" to "AS is the name"

>   It is also referred as IPSP communication. IPSP is the name of the
>   role that an IP-based node plays UAL usually gives to the ISEP
>   nodes. It stands for IP Signaling Point.

English usage.  Please reword this entire paragraph (especially the
middle line "IP-based node plays UAL usually").

Section 4.1:

>                                             ... The default orientation
>   would be for the SG to take on the role of server while the ISEP is
>   the client. ...

Grammar: change "would be for" to "is for".

>   Examples of the upper layers to be transported would be Q.931 and
>   QSIG.

Grammar: change "would be" to "are".

>   communication where the ISEP role is typically played by a node
>   called MGC defined in [RFC2719].

Grammar: change "called MGC defined" to "called an MGC, as defined".

>   The value assigned by IANA for the Payload Protocol Identifier in the
>   SCTP Payload Data chunk is ô1ö

Non-ascii characters at the end of this sentence.

Section 4.2:

>                                                   ... It is basically
>   implemented in an interworking scenario with SG.

Usage: change "basically" to "typically".

>           AN    û Access Network
>           NIF   û Nodal Interworking Function
>           LAPV5 û Link Access Protocol for the V5 channel

Non-ascii characters in text.

Section 4.3:

>   The DUA is built on top of IUA defining the necessary extensions to
>   IUA for a DPNSS/DASS2 transport. ...

grammar: change "top of IAU defining" to "top of IUA and defines"

>                                ... DPNSS stands for Digital Private
>   Network Signaling System and DASS2 for Digital Access Signaling
>   System No 2

Missing period at end of sentence.

>   The value assigned by IANA for the Payload Protocol Identifier in the
>   SCTP Payload Data chunk is ôTBDö.

Non-ascii text at end of sentence.

Does not DUA have a PPI assigned yet?

Section 4.4:

>   This protocol would be mainly used between a Signaling Gateway (SG)
>   and Media Gateway Controler (MGC). ...

Grammar: change "would be" to "is"; change "mainly" to "typically" or
"largely" or "usually".

>   The only SS7 MTP2 User is MTP3 that is the protocol transported by
>   this UAL.

Really bad sentence formation:  change to:

<   MTP3 is the only MTP2-User that is transport by this UAL.

Besides, the statement is incorrect: MTP3b could also be transported.

>   The SG provides a interworking of transport functions with the IP
>   transport, in order to transfer the MTP2-User signaling messages to
>   and from an Application Server (e.g. MGC) where the peer MTP2-
>   User protocol layer exists.

This is a relly awkward paragraph.  I think you mean "interworking of
SS7 transport functions with IP transport functions".  Change "in order
to" to "to", change "the MTP2-User" to "MTP2-User"; change "to and from"
to "with"; change "Application Server (e.g., MGC) where the peer
MTP2-User protocol layer exists" to "MTP2-User at an Application Server
(e.g., MGC)."

>   The value assigned by IANA for the Payload Protocol Identifier in the
>   SCTP Payload Data chunk is ô2ö

Non-ascii text at end of sentence.

Section 4.5:

>   This protocol is used between SS7 Signaling Points employing the MTP
>   Level 3 protocol. The SS7 Signaling Points may also employ standard
>   SS7 links using the SS7 MTP Layer 2 to provide transport of MTP Layer
>   3 signaling messages.

Word usage: change "employing" to "using" and "employ" to "use".

There is no such thing as "MTP Layer 2" or "MTP Layer 3"; in SS7 it is
referred to as "MTP Level 2" and "MTP Level 3".

>   Both configurations: intercommunication of SS7 and IP with SG and
>   communication between ISEPs are possible.

There is no such word as "intercommunication".  "Communication" is
already between two things ("inter").

Besides, M2PA only provides for communication between SPs.  There is
no need for the two diagrams for M2PA.  There is no distinction between
the first diagram and the right-hand side of the second diagram for
M2PA.

>   These figures are only an example. Other configurations are possible.
>   For example, IPSPs without traditional SS7 links could use the
>   protocol layers MTP3/M2PA/SCTP/IP to route SS7 messages in a network
>   with all IP links.
>
>   Another example is that two SGs could be connected over an IP network
>   to form an SG mated pair similar to the way STPs are provisioned in
>   traditional SS7 networks.

These statements sound foolish.  M2PA is really just a different sort
of SS7 link.  Plesae remove.

>   The value assigned by IANA for the Payload Protocol Identifier in the
>   SCTP Payload Data chunk is TBD

Does not M2PA have a PPI yet?

>      b. M2PA: SG-IPSP connection is an SS7 link.
>         M2UA: SG-MGC connection is not an SS7 link. It is an
>               extension of MTP to a remote entity.

There is nothing stopping M2UA from being used in a peer-to-peer
fashion.

>      c. M2PA: SG is an SS7 node with a point code.
>         M2UA: SG is not an SS7 node and has no point code.

This is not necessarily a correct statement.  There is nothing
restricting an M2UA SG from having a point code or being an
SS7 node in its own right.

>      d. M2PA: SG can have upper SS7 layers, e.g., SCCP.
>         M2UA: SG does not have upper SS7 layers since it has no MTP3.

Same is true here.  The above statement is false.

>      e. M2PA: relies on MTP3 for management procedures.
>         M2UA: uses M2UA management procedures.

If need explanation of the absurdity of this statement, consider
this SG:
                     ____
                    |
                    |
                +------+
                | M2UA |
                +------+
                | M2PA |
                +------+
                    |
             _______|

Which is referred to in the M2UA document.

This SG is an M2PA SG, but it has no point code, has no local MTP3,
has no local upper layers (SCCP), and relies on M2UA for management
procedures.

Section 4.6:

>      - Interconnection of SS7 and IP nodes

Grammar: replace "Interconection" with "Connection".

>   It works using the client-server philosophy. ...

This might be ok in German, but is awkward in English.  Reword as:

<   M3UA uses a client-server architecture.

>                                            ... ISEP is recommended to
>   be client when talking with a SG.

<   It is recommended that the ISEP act as the client and initiate
<   SCTP associations with the SG.

>                                 ... The reserved port by IANA is 2905
>   to listen to possible client connections.

<   The port reserved by IANA is port number 2905.  This is the port
<   upon which the SG should listen for client connections.

>   The assigned payload protocol identifier for the SCTP DATA chunks is
>   ô3ö.

Non-ascii text at end of sentence.

Section 4.7:

>                 ... SUA can support only non-call related signaling.

Almost all SUA signalling is call related.  I think you mean
non-call-associated signalling; but, then, *all* SS7 signalling is
non-call-associated signalling.  Please strike this sentence.

>   SUA does not pose stringent timing constraints on SCTP due to the
>   fact that SUA applications have broad timing requirement (from 10 of
>   seconds to hours) which the applications guard themselves and the
>   timing supervision of the application is end-to-end, not hop-by-
>   hop(as with ISUP).

This statement is false and misleading.  SCCP, particularly for the
cited applications: MAP, INAP, SMS, BSSAP, RANAP, has very stringent
timing requirements, often more stringent than ISUP due to the fact
that these represent transaction which are made during ISUP call setup.

Tens of seconds to hours is false; and atypical.  Transaction timers
an performance requirements for INAP, for example, are 1 second maximum
with 100 ms nominal query/response times.  Please remove this paragraph.

>      - Interconnection of SS7 and IP

Change "Interconnection" to "Connection".

>   connections. The payload protocol identifier for the SCTP DATA chunks
>   is ô4ö.

Non-ascii text.

General:

There is a mixture of "signalling" (two l's British/Canadian spelling)
and "signaling" (American spelling).  As the title contains signalling
with two l's, please use signalling with two l's throughout.

--brian

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

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