Subject: [Sigtran] M3UA-12: Contents of Protocol Data

From: [email-masked]
Date: Tue, 5 Mar 2002 12:49:21 +0100

Hi,

Section 3.3.1 defines Protocol Data as follows:

"The Protocol Data fiels contains a byte string of MTP-User information from
the original SS7 message starting with the first byte of the original SS7
message following the Routing Label."

However TUP uses a 40-byte Routing label containing DPC, OPC and CIC. Where
the least significant 4 bits of the CIC are in the same octet as the most
significant 4 bits of the OPC.
           +-+-+-+-+-+-+-+-+
           |CIC ls | OPC ms|
           +-+-+-+-+-+-+-+-+

How will this be formatted when TUP is carried by M3UA?

Regards,
Joyce

==================================================================
Joyce Archibald, TSD R&D     | Phone:    +44 (0) 131 3317521 
Agilent Technologies UK Ltd  | Telnet:   313 2521
South Queensferry,           | Mailstop: SQFRD3A
EH30 9TG, Scotland.          | E-mail: [email-masked]
==================================================================

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

---

From: Ken Morneault <[email-masked]>
Date: Fri, 08 Mar 2002 16:25:32 -0500

Joyce,

The implementation guide will need to contain a note about
handling TUP.  Do you prefer that the CIC be placed into
a field or that that byte that is shared by CIC/OPC be the
first byte in the Protocol Data (the OPC bits should/must
be zeroed)?  Or, do you have another alternative?

Regards,

Ken

---

From: [email-masked]
Date: Mon, 11 Mar 2002 09:47:44 +0100

Hi Brian,

The reason I suggested putting it in the Protocol Data is so that the CIC
field would not be split between two fields, SLS and Protocol Data. The
least significant 4 bits of the CIC (i.e. the SLS) could also be placed in
the SLS field.

If the LS 4 bits of the CIC are placed in the SLS field, then the CIC field
received by the TUP user will be:
                                           |--> First bit transmitted
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |   CIC (ms)    |0 0 0 0|CIC ls |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                             <-------------Transmission order

(unless TUP-specific action is taken by the M3UA to MTP-User interface)

If the whole CIC field (as expected by the TUP user) is placed in the
Protocol Data field, it can simply be passed to the user with no special
action required by the interface.

All Protocol Data fields are protocol-specific. The contents should not
matter to M3UA.

Regards,
Joyce

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 11 March 2002 08:25
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sigtran] M3UA-12: Contents of Protocol Data
> 
> 
> Joyce,
> 
> Another (this time MTP-user-specific) protocol-specific protocol
> data payload?
> 
> Please leave the SLS bits in the SLS field and only place the
> 8 CIC bits that do not overlap with SLS, in the payload.  The
> M3UA to MTP-User interface for TUP can place them back together
> for the TUP user if required.
> 
> Thanks.
> 
> --brian
> 
> [email-masked] wrote:     (Mon, 11 Mar 2002 08:59:17)
> > Hi Ken,
> > 
> > My preference would be for the first byte in the Protocol 
> Data to contain
> > the least significant 4 bits of the CIC in its top 4 bits. 
> The bottom 4 bits
> > would be reserved and must be ignored by the receiver, 
> whether they are zero
> > or not. That is:
> > 
> >            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >            |CIC ls | resvd |    CIC (ms)   |
> >            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > Regards,
> > Joyce
> > 
> > > -----Original Message-----
> > > From: Ken Morneault [mailto:[email-masked]]
> > > Sent: 08 March 2002 21:26
> > > To: [email-masked]; [email-masked]
> > > Subject: Re: [Sigtran] M3UA-12: Contents of Protocol Data
> > > 
> > > 
> > > 
> > > 
> > > Joyce,
> > > 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

---

From: [email-masked]
Date: Mon, 11 Mar 2002 13:20:00 +0100

Hi Ken,

> be zeroed)?  Or, do you have another alternative?

I guess Brian and I have agreed on an alternative. 
If you want a note in the implementation guide, perhaps you could argue it
out with Brian.

Cheers,
Joyce

> Sent: 11 March 2002 12:08
> joyce_archibald,
> [email-masked] wrote:                (Mon, 11 
> Mar 2002 12:57:49)
> > Brian,
> > 
> > I don't care what it is called. The point I am trying to 
> make is that if
> > M3UA extracts the SLS bits and places them in its own SLS 
> field, they will
> > then be in the least significant 4 bits of the octet 
> preceding the remaining
> > CIC 8 bits. Whereas the TUP user will expect them to be in the most
> > significant 4 bits of the octet since they are normally transmitted
> > immediately before the rest of the CIC and not separated by 
> 4 zero bits.
> > This should be pointed out to anyone implementing TUP over IP.
> 
> I think it is clear from the diagrams is M3UA where the SLS
> bits are coded and where the first bits following the routing
> label are coded.  There is no need to point to the diagram.
> 
> --brian
> 
> > 
> > Alternatively you can assume that no-one will want to use 
> TUP in which case
> > the reference in section 3.3.1 (top of Page 30) should be removed.
> > 
> > Regards,
> > Joyce
> > 
> > > Sent: 11 March 2002 11:47
> > > Your msising the point.  There is no Routing Label Type B.  
> > > There is only
> > > a Label Type B.  The label refers to the whole TUP CIC.  The 
> > > ROUTING label
> > > refers to only the SLS portion.  The M3UA spec clearly 
> states that the
> > > first byte after the Routing Label (the SLS) is the first 
> byte in the
> > > protocol data field.  This cannot be made any more clear.
> > > 
> > > --brian
> > > 
> > > [email-masked] wrote:                (Mon, 11 
> > > Mar 2002 12:33:40)
> > > > Hi Brian,
> > > > 
> > > > I agreed with you a couple of my e-mails ago, that no 
> > > changes were needed to
> > > > the M3UA spec.
> > > > 
> > > > I thought you agreed with me a couple of your e-mails ago, 
> > > that a note could
> > > > be placed in the implementation guide. 
> > > > I don't think it would be necessary to name all the TUP 
> > > variants. How about
> > > > a warning regarding the use of protocols with Q.700 Routing 
> > > Label Type B.
> > > > 
> > > > Regards,
> > > > Joyce
> > > > 
> > > > > Sent: 11 March 2002 11:21
> > > > > [email-masked] wrote:     (Mon, 11 Mar 
> 2002 11:49:27)
> > > > > > Hi Brian,
> > > > > > 
> > > > > > For definition of the TUP routing label, see Q.700. 
> > > > > 
> > > > > The RL is illustrated in Figure 7/Q.700 as not including 
> > > the entire
> > > > > CIC for TUP (and not including the CIC for ISUP either).
> > > > > 
> > > > > See also Figure 3/Q.704 which does not include CIC and 
> > > particularly
> > > > > the note about TUP in clause 2.2.4 describing the 
> Signalling Link
> > > > > Selection (SLS) field:
> > > > > 
> > > > >    "In the case of circuit related messages of the 
> TUP, the field
> > > > >     contains the least significant bits of the circuit 
> > > identification
> > > > >     code (or bearer identification code, in the case of 
> > > the Data User
> > > > >     Part), and these bits are not repeated elsewhere."
> > > > > 
> > > > > Shall we place notes in the imp guide for that other widely
> > > > > used SS7 protocol DUP? ;)
> > > > > 
> > > > > Also in Clause 14.3, Q.704 says:
> > > > > 
> > > > >    "The structure and content of the label is defined for 
> > > each User
> > > > >     Part and is defined in the relevant 
> specification.  The common
> > > > >     part of the label used for signalling message handling, 
> > > > > the routing
> > > > >     label, is specified in 2.2."
> > > > > 
> > > > > So, really the TUP "routing label" consists of only the 
> > > SLS portion
> > > > > of the CIC.  The TUP "label" includes the CIC.  
> Because the M3UA
> > > > > specification defines the fields in terms of the "routing 
> > > label", I
> > > > > don't see any need for further clarification.
> > > > > 
> > > > > M3UA says:
> > > > > 
> > > > > | Protocol Data: (variable)
> > > > > | 
> > > > > |    The Protocol Data field contains a byte string 
> of MTP-User 
> > > > > |    information from the original SS7 message 
> starting with the 
> > > > > |    first byte of the original SS7 message following the 
> > > > > Routing Label.
> > > > > 
> > > > > Accent on "ROUTING Label".
> > > > > 
> > > > > > 
> > > > > > I agree that this also applies to all TUP variants, 
> > > > > including BT-NUP and IUP
> > > > > > (in practice, any protocol which uses SI = 4).
> > > > > 
> > > > > TUP-E, TUP-P and TUP-N don't use SI=4.  (But as I'm 
> pretty sure
> > > > > none of them are used anymore, the point is moot.)
> > > > > 
> > > > > I though the world was erradicated of TUP much the same way it
> > > > > has been widely erradicated of small pox.
> > > > > 
> > > > > No change is required to M3UA spec because it refers to 
> > > the "Routing
> > > > > Label" of Q.704 and not the TUP-specific "Label".
> > > > > 
> > > > > --brian
> > > > > 
> > > > > > 
> > > > > > Regards,
> > > > > > Joyce
> > > > > > 
> > > > > > > Sent: 11 March 2002 10:31
> > > > > > > MTP does not use more than SLS for routing TUP 
> messages.  The 
> > > > > > > routing in
> > > > > > > an MTP implementation does not consider the additional 
> > > > > CIC bits.  Only
> > > > > > > 4-bits of the TUP CIC are used for signalling link 
> > > > > selection and there
> > > > > > > are in the same bit locations as normal SLS.  It could be 
> > > > > argued that
> > > > > > > the TUP RL does not include the 8 high-order CIC bits.  
> > > > > When M3UA uses
> > > > > > > SLS for loadsharing, it uses the same bits for 
> TUP as it uses 
> > > > > > > for other
> > > > > > > MTP-users, just as MTP uses the same bits for 
> signalling link 
> > > > > > > selection
> > > > > > > as it uses for other MTP-users.  TUP is not listed as 
> > > having an
> > > > > > > SI-specific routing label.  (Only a potential for an MTUP 
> > > > > > > SI-specific RL
> > > > > > > is mentioned in the specs.)  It could be argued that a 
> > > > > TUP RL does not
> > > > > > > include the addtional CIC bits regardless of what is 
> > > > > shown in the TUP
> > > > > > > spec diagrams.  I would expect that those contemplating 
> > > > > carrying TUP
> > > > > > > over M3UA might know what they are doing; but, a 
> note could 
> > > > > > > be placed in
> > > > > > > the imp guide (even though noone is likely to use it).  
> > > > > Then there is
> > > > > > > also TUP-N and TUP-E and a bunch of national an 
> > > > > international variants
> > > > > > > of TUP.  What about BT-NUP?  The imp guide could get 
> > > fairly wordy
> > > > > > > talking about all these archane variants of SS7.  Perhaps 
> > > > > it would be
> > > > > > > better to talk of the RL as defined by Q.704 rather than 
> > > > > > > involving TUP.
> > > > > > > 
> > > > > > > --brian
> > > > > > > 
> > > > > > > [email-masked] wrote:     (Mon, 11 Mar 
> > > 2002 10:56:27)
> > > > > > > > Hi Brian and Ken,
> > > > > > > > 
> > > > > > > > To be accurate, for TUP the routing label is 5 
> octets and 
> > > > > > > consists of
> > > > > > > > DPC,OPC,CIC. However, I concede your point. 
> Since TUP is 
> > > > > > > unlikely to be used
> > > > > > > > much (if at all) over IP, it makes sense to ignore its 
> > > > > > > existence where
> > > > > > > > possible.
> > > > > > > > 
> > > > > > > handling TUP, so
> > > > > > > > that the M3UA interface to the TUP user knows how to 
> > > > > > > reconstruct the CIC,
> > > > > > > > from the first octet of the Protocol Data and 
> the bottom 4 
> > > > > > > bits of the SLS.
> > > > > > > > 
> > > > > > > > Regards
> > > > > > > > Joyce
> > > > > > > > 
> > > > > > > > > Sent: 11 March 2002 09:32
> > > > > > > > > As it stands, M3UA takes the routing label and places 
> > > > > it into the
> > > > > > > > > routing label data fields and takes the SIF and 
> > > > > places it in the
> > > > > > > > > protocol data.  For your proposal it would have to do 
> > > > > something
> > > > > > > > > different for TUP than it does for other 
> > > user-parts.  I see no
> > > > > > > > > reason why the SLS can't stay in the SLS and the 
> > > > > 8-bit portion of
> > > > > > > > > the CIC which is in the SIF can't stay in the SIF 
> > > (payload).
> > > > > > > > > Again, at the TUP interface at the receiving M3UA, 
> > > > > these can be
> > > > > > > > > placed back together (but at the TUP interface it is 
> > > > > known that
> > > > > > > > > it is a TUP MTP-User).
> > > > > > > > > 
> > > > > > > > > Under the current situation (splitting up the TUP 
> > > > > CIC), the M3UA
> > > > > > > > > need only know the form of the RL and is MTP-User 
> > > independent.
> > > > > > > > > As TUP is so little used today (if at all), it does 
> > > > > not make any
> > > > > > > > > sense to expose M3UA to TUP oddities.
> > > > > > > > > 
> > > > > > > > > There is no problem with the current situation, in 
> > > > > the message you
> > > > > > > > > can expect to see the first bits following 
> the RL (8-bits 
> > > > > > > of the CIC)
> > > > > > > > > and the SLS will appear in the SLS field.  
> The spec is 
> > > > > > > fine as it is.
> > > > > > > > > 
> > > > > > > > > --brian
> > > > > > > > > 
> > > > > > > > > [email-masked] wrote:     (Mon, 11 Mar 
> > > > > 2002 09:55:08)
> > > > > > > > > > Hi Brian,
> > > > > > > > > > 
> > > > > > > > > > Sorry, I realise that the contents do matter to 
> > > M3UA, since 
> > > > > > > > > the message must
> > > > > > > > > > be constructed by someone. However, doesn't 
> > > that mean that 
> > > > > > > > > special code is
> > > > > > > > > > required for TUP anyway, so the rest of my 
> > > reasoning stands.
> > > > > > > > > > 
> > > > > > > > > > Regards,
> > > > > > > > > > Joyce
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > From: ARCHIBALD,JOYCE (A-Scotland,ex1) 
> > > > > > > > > > > Sent: 11 March 2002 08:48
> > > > > > > > > > > To: [email-masked]'
> > > > > > > > > > > Subject: RE: [Sigtran] M3UA-12: Contents of 
> > > Protocol Data
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Hi Brian,
> > > > > > > > > > > 
> > > > > > > > > > > The reason I suggested putting it in the Protocol 
> > > > > Data is so 
> > > > > > > > > > > that the CIC field would not be split between two 
> > > > > fields, SLS 
> > > > > > > > > > > and Protocol Data. The least significant 4 bits 
> > > > > of the CIC 
> > > > > > > > > > > (i.e. the SLS) could also be placed in 
> the SLS field.
> > > > > > > > > > > 
> > > > > > > > > > > If the LS 4 bits of the CIC are placed in the SLS 
> > > > > field, then 
> > > > > > > > > > > the CIC field received by the TUP user will be:
> > > > > > > > > > >                                            
> > > |--> First bit 
> > > > > > > > > transmitted
> > > > > > > > > > > (unless TUP-specific action is taken by the M3UA 
> > > > > to MTP-User 
> > > > > > > > > > > interface)
> > > > > > > > > > > 
> > > > > > > > > > > If the whole CIC field (as expected by the 
> > > TUP user) is 
> > > > > > > > > > > placed in the Protocol Data field, it can simply 
> > > > > be passed to 
> > > > > > > > > > > the user with no special action required by 
> > > the interface.
> > > > > > > > > > > 
> > > > > > > > > > > All Protocol Data fields are protocol-specific. 
> > > > > The contents 
> > > > > > > > > > > should not matter to M3UA.
> > > > > > > > > > > 
> > > > > > > > > > > Regards,
> > > > > > > > > > > Joyce
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > 
> > > > > > > > > > > > Please leave the SLS bits in the SLS 
> field and only 
> > > > > > > place the
> > > > > > > > > > > > M3UA to MTP-User interface for TUP can 
> place them 
> > > > > > > back together
> > > > > > > > > > > > [email-masked] wrote:     
> (Mon, 11 Mar 
> > > > > > > > > 2002 08:59:17)
> > > > > > > > > > > > > Hi Ken,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > the least significant 4 bits of the 
> CIC in its 
> > > > > > > top 4 bits. 
> > > > > > > > > > > > The bottom 4 bits
> > > > > > > > > > > > > Joyce Archibald, TSD R&D     | Phone: 
>    +44 (0) 
> > > > > > > 131 3317521 
> > > > > > > > > > > > > > The implementation guide will need 
> to contain a 
> > > > > > > note about
> > > > > > > > > > > > > > first byte in the Protocol Data 
> (the OPC bits 
> > > > > > > should/must
> > > > > > > > > > > > > > >"The Protocol Data fiels contains a 
> > > byte string of 
> > > > > > > > > MTP-User 
> > > > > > > > > > > > > > information from
> > > > > > > > > > > > > > >the original SS7 message starting with 
> > > the first 
> > > > > > > > > byte of the 
> > > > > > > > > > > > > > original SS7
> > > > > > > > > > > > > > >However TUP uses a 40-byte Routing label 
> > > > > > > > > containing DPC, OPC 
> > > > > > > > > > > > > > and CIC. Where
> > > > > > > > > > > > > > >the least significant 4 bits of 
> the CIC are in 
> > > > > > > the same 
> > > > > > > > > > > > > > octet as the most
> > > > > > > > > > > > > > >Joyce Archibald, TSD R&D     | Phone:  
> > >   +44 (0) 
> > > > > > > > > 131 3317521 

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

---

From: Ken Morneault <[email-masked]>
Date: Mon, 11 Mar 2002 11:03:47 -0500

Joyce,

After re-reading Section 3.3.1 of M3UA, the current text seems
sufficient.  However, it would be useful to add a reference
to Q.700.  It would also be good to be consistent with the use
of "User Protocol Data" versus "Protocol Data".

Also, TUP is still used and M3UA does need to support it.

Regards,

Ken