Subject: RE: M2UA: Parameter usage

From: "Greg Sidebottom" <[email-masked]>
Date: Mon, 5 Mar 2001 13:11:45 -0500

Hi Joyce,

Re your suggestion to keep a single Data Message with two possible Protocol
Data parameters - this is what I have also proposed in the M3UA (finally
sent in Friday - coming soon to a server near you!).  I called the
parameters Protocol Data 1 and 2  so it is not quite so specific to TTC but
the result is essentially the same.    

Cheers,

     Greg

From M3UA.06:

*******************************************************

3.3.1 Payload Data Message (DATA)

The DATA message contains the SS7 MTP3-User protocol data, which is an 
MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The 
Data message contains the following variable length parameters:

     Network Appearance       Optional
     Protocol Data 1 or 2     Mandatory

The following format MUST be used for the Data Message:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Tag = 1            |          Length = 8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Network Appearance*                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Tag = 3            |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               \
   /                        Protocol Data                          /
   \                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and ...

Protocol Data 1 or 2: variable length

   One of two possible Protocol Data parameters are included in a DATA 
   message: Protocol Data 1 or Protocol Data 2.  

   The Protocol Data 1 parameter contains the original SS7 MTP3 
   message, including the Service Information Octet and Routing Label. 

   The Protocol Data 1 parameter contains the following fields:

       Service Information Octet. Includes:
            Service Indicator, 
            Network Indicator,
            and Spare/Priority codes

       Routing Label. Includes:
            Destination Point Code,
            Originating Point Code,
            And Signalling Link Selection Code (SLS)

       User Protocol Data.  Includes:
            MTP3-User protocol elements (e.g., ISUP, SCCP, or TUP 
               parameters)
       
   The Protocol Data 2 parameter contains all the information in 
   Protocol Data 1 as described above, plus the MTP2 Length Indicator 
   octet.  The MTP2 Length Indicator (LI) octet appears before the SIO 
   and Routing Label information.  The MTP2 Length Indicator octet is 
   required for some national MTP variants that use the spare bits in 
   the LI to carry additional information of interest to the MTP3 and 
   MTP3-User (e.g., the Japan TTC standard use of LI spare bits to 
   indicate message priority)

*********************************

 -----Original Message-----
From: 	Joyce Archibald [mailto:[email-masked]] 
Sent:	Thursday, March 01, 2001 3:37 AM
To:	[email-masked];
[email-masked]
Subject:	M2UA: Parameter usage

Hi All,

I am sending these comments again, in the hope that they reach the list
this time!

I have some queries/suggestions concerning the format of some messages.

1. The TTC Data Message (section 3.3.1.2)

   The TTC Protocol Data parameter (tag = 0xf) has been included, in
order to support the Japanese TTC variant of the Protocol Data Unit.
Fine.

   I don't see why it is necessary to add the message type 'TTC Data',
since the Data message could be defined to contain either parameter.
(i.e. a Mandatory Choice, to use ASN.1 terms)

   The Data Retrieval Indication and Data Retrieval Indication Complete
messages, presumably can also carry either Protocol Data or TTC Protocol
Data.

   May I suggest that tags should be used to identify the parameter and
therefore should not change depending on which message they are in.

   Thus the Data, Data Retrieval Indication and Data Retrieval
Indication Complete messages could each contain, either Protocol Data
(tag = 0xe) or TTC Protocol Data (tag = 0xf), but not both.

   The 'TTC Data' message and 'PDU from retransmit queue' parameter
would not be required.

   Similarly the tag 0x10 should identify the State parameter regardless
of whether it appears in the State Request or State Confirm message. The
Result field in the State Confirm message could be a separate parameter,
possibly using tag 0x16.

2. The Congestion Indication message (section 3.3.1.7)

   The spec states that there are 2 parameters:
         Congestion Status (Mandatory)
         Discard Status    (Optional)

   However, only the Congestion Status has a tag and length. 

3. The Retrieval (Request, Confirm) messages (section 3.3.1.8)

   The spec does not state whether the parameters are Mandatory or
Optional, although the text implies both are Mandatory. Also the
Sequence number field is used as a result indicator in certain messages.
This is messy.

May I suggest the following definitions:

   3.3.1.1 Data

   The Data message MUST contain ONE of the following parameters:

        Protocol Data     (Optional)
        TTC Protocol Data (Optional)

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x0e)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Protocol Data                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x0f)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       TTC Protocol Data                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   3.3.1.5 State Confirm

   The State Confirm message contains the following parameters:

        State  (Mandatory)
        Result (Mandatory)

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x10)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             State                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x16)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Result                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Values as already defined.

   3.3.1.7 Congestion Indication

   The Congestion Indication message contains the following parameters:

         Congestion Status (Mandatory)
         Discard Status    (Optional)
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x15)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Congestion Status                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x14)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Discard Status                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Values as already defined.

   3.3.1.8.1 Retrieval Request

   The Retrieval Request message contains the following parameters:

        Action           (Mandatory)
        Sequence Number   (Optional)

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x12)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Action                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x13)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Values as already defined, except that the Sequence number should
   only be present if Action is ACTION_RTRV_MSGS.

   3.3.1.8.2 Retrieval Confirm

   The Retrieval Confirm message contains the following parameters:

        Action           (Mandatory)
        Sequence Number   (Optional)
        Result            (Optional)

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x12)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Action                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x13)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x16)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Result                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Values as defined in sections 3.3.1.8.1 and 3.3.1.5

   3.3.1.9 Retrieval Indication

   The Retrieval Indication message MUST contain ONE of the
   following parameters:

        Protocol Data     (Optional)
        TTC Protocol Data (Optional)

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x0e)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Protocol Data                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x0f)           |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       TTC Protocol Data                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Regards,

Joyce

---

From: Ken Morneault <[email-masked]>
Date: Mon, 05 Mar 2001 13:35:01 -0500

this one either...

>Date: Mon, 05 Mar 2001 08:16:53 -0500
>To: [email-masked]
>From: Ken Morneault <[email-masked]>
>Subject: Re: M2UA: Parameter usage
>Cc: [email-masked]
>
>
>
>Joyce,
>
>Thanks for the text proposals.
>
>Regards,
>
>Ken
>
>At 10:06 AM 2/28/01 +0000, Joyce Archibald wrote:
>>Hi Ken,
>>
>>I have a couple a queries/suggestions concerning the format of some
>>messages.
>>
>>1. The Congestion Indication message (section 3.3.1.7)
>>
>>2. The Retrieval (Request, Confirm) messages (section 3.3.1.8)
>>
>>    3.3.1.6 State Indication - no change
>>