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

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

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

> -----Original Message-----
> From: ARCHIBALD,JOYCE (A-Scotland,ex1) 
> Sent: 11 March 2002 08:48
> To: [email-masked]'
> Cc: [email-masked]; [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
>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            |   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
> 
> ==================================================================
> 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]
> ==================================================================
> 
> > -----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
> > > 
> > > ==================================================================
> > > 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]
> > > ==================================================================
> > > 
> > > > -----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,
> > > > 
> > > > 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
> > > > 
> > > > At 12:49 PM 3/5/2002 +0100, [email-masked] wrote:
> > > > >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 
> > > > 
> > > 
> > > _______________________________________________
> > > Sigtran mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/sigtran
> > 
> > -- 
> > Brian F. G. Bidulock
> > [email-masked]
> > http://www.openss7.org/
> > 
> 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 11 Mar 2002 03:32:16 -0600

Joyce,

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)

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