Subject: Re: M2PA-01

From: Tom George <[email-masked]>
Date: Mon, 05 Mar 2001 11:17:49 -0600

I don't think this made it to the list the first time I sent it. If not,
here it is again....

-------- Original Message --------
Subject: Re: M2PA-01
Date: Wed, 28 Feb 2001 19:00:10 -0600
From: Tom George <[email-masked]>
Organization: Alcatel USA, Inc.
To: [email-masked]
CC: Bernard Kuc <[email-masked]>
References: <934C10A9A64AD4119440009027E0998874A3F2@MAIL>

On 12/04/00 Bernard Kuc wrote:
> 
> Hi Tom,
> 
> I just have a few questions.
> 
> 1. Is M2PA going to adapt the same message header as the other
> adaptation layers? If yes, here is a proposed text:

  [... proposed text is at the end of this message for reference...]

For now I am inclined to leave this out since I don't see the
advantage of it. Maybe someone can enlighten me. 8-)

> 2. In your description of the Association process (5.1), you request
> the SRTT from SCTP. Would not this SRTT be very un-smoothed as no
> data messages have been sent yet? Should not a few filler Link Status
> messages be sent as in the alignment of MTP2?

This is a good question. I had been thinking that the SRTT would be
accurate based on handshaking and heartbeat messages. Would an
MTP2-like proving be a good idea? If so, can anyone give a suggestion
as to how it might work?

> 3. Under what scenarios would a M2PA layer have multiple SCTP
> associations with another M2PA layer? (re: Figure 7)

The only reason I could think is if you wanted a box that converted
links on a one-to-one basis.

                      SG                     IPSP

                  +----------+           +----------+
            SS7 1 |          | SS7/IP 1  |          |
       -----------|          |-----------|          |
                  |          |           |          |
            SS7 2 |          | SS7/IP 2  |          |
       -----------|          |-----------|          |
                  |          |           |          |
            SS7 3 |          | SS7/IP 3  |          |
       -----------|          |-----------|          |
                  |          |           |          |
                  +----------+           +----------+

But that is not necessary since you have an MTP3 layer. It can route
all of SS7 links 1, 2, 3 to a single SS7/IP link to IPSP.

The capability is there if anyone wants to use it. 

I put the example of the multiple associations in M2PA because it was
the "hard case". Several readers thought I meant that was the
recommended way of using M2PA. I will clear that up in version 2.

> 4. After you have flushed buffers (from a request by MTP3) how do we
> ensure that SCTP does not carry on delivering data (that it has queued)
> to the peer M2PA? or is that not critical?

There is no way to stop SCTP from transmitting messages it has been
given, except to destroy the association (in which case you wouldn't
be worrying about flushing buffers 8-) ). I do not see it as a serious
problem. MTP3 stops transmitting when it finds out about the Remote
Processor Outage. That should be enough.

> Best Regards
> Bernard

The proposed text:
> ---------------------------------------------------------------
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |    Version    |     Spare     | Message Class | Message Type  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                        Message Length                         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                   Figure 5  Common Message Header
> 
> All fields in an M2PA message MUST be transmitted in the network byte
> order, unless otherwise stated.
> 
> 2.1.1  Version
> 
> The version field (vers) contains the version of the M2PA adapation
> layer.  The supported versions are:
> 
>        Value    Version
>        -----    -------
>          1      Release 1.0 of M2PA protocol
> 
> 2.1.2  Message Classes and Types
> 
> The following List contains the valid Message Classes:
> 
>    Message Class: 8 bits (unsigned integer)
> 
>          0        Management (MGMT) Message [IUA/M2UA/M3UA/SUA]
>          1        Transfer Messages [M3UA]
>          2        SS7 Signalling Network Management (SSNM) Messages
> [M3UA/SUA]
>          3        ASP State Maintenance (ASPSM) Messages [IUA/M2UA/M3UA/SUA]
>          4        ASP Traffic Maintenance (ASPTM) Messages
> [IUA/M2UA/M3UA/SUA]
>          5        Q.921/Q.931 Boundary Primitives Tranport (QPTM)
>                   Messages [IUA]
>          6        MTP2 User Adaptatation (MAUP) Messages [M2UA]
>          7        Connectionless Messages [SUA]
>          8        Connection-Oriented Messages [SUA]
>          9        MTP2 Peer Adaptation (MPAM) Messages [M2PA]
>      10 to 127    Reserved by the IETF
>     128 to 255    Reserved for IETF-Defined Message Class extensions
> 
> The following list contains the message types for the defined messages.
> 
>      MTP2 Peer Adaptation (MPAM) Messages
> 
>          0        Reserved
>          1        User Data
>          2        Link Status
>       3 to 127    Reserved by the IETF
>     128 to 255    Reserved for IETF-Defined MPAM extensions
> 
> 2.1.3  Spare
> 
> The Spare field is 8-bits.  It SHOULD be set to all '0's and
> ignored by the receiver.
> 
> 2.1.4  Message Length
> 
> The Message length defines the length of the message in octets,
> including the header.
> 

-- 
* Tom George        972-519-3168         [email-masked]   *
* PB2-1323       Intranet:  http://www.ssd.usa.alcatel.com/~tgeorge/  *
*    Alcatel USA, Inc.; 1000 Coit Rd, MS STPA; Plano TX 75075-5813    *
* I actively disclaim speaking for Alcatel USA, Inc. I do not purport *
* to advertise or represent its position,  operations, or activities. *

---

From: Joyce Archibald <[email-masked]>
Date: Mon, 12 Mar 2001 12:23:58 +0000

Hi Tom,

I would very strongly request that the Common Message Header (section
2.1) conform to the common format used by all the other adaption layer
protocols, otherwise how can it be called "Common".

I realise that M2PA only uses one Message Class, but that is not a good
reason to leave it out. I don't mind whether you change the spec to use
Message Class 09, as suggested by Bernard, or if you continue to use
Message Class 06 and change the Message Class defintion for that value
to something like:
       6        MTP2 User Adaptatation (MAUP) Messages [M2UA/M2PA]

More importantly the Message length should include the header, in order
to compatible with SCTP as well as all the other adaption protocols.

Regards,
Joyce