Subject: [Sigtran] many thanks for ur reply there few more

From: ali ovaisi <[email-masked]>
Date: Wed, 27 Jun 2007 04:59:27 -0700 (PDT)

Dear Brian

I am a student and doing a project related to SS7oIP

Then I assume that you might actually want to learn something instead

of just being told.

Correct

 To  accomplish  my project I have to achieve the task that What is

 the SS7oIP  rate  generated by each of the following protocols for a

 given VoIP traffic.

 Then I also assume that you do not simply want to be told the answer.

correct

>    M3UA

 M3UA carries in it MTP3 messages (see the DATA message description in

 section 3 of RFC 4666).  MTP3 messages correspond to regular PSTN (not VoIP)

 telephone calls(i totally agree and it should be the case that SS7 messages will be wrap up in the M3UA packets to move from IP network and nothing to do with VoIP except that SIGTRAN (eg M3UA) over head is added in signaling gateway (whether the complete ss7 message is encapsulated or break up into chunks in M3UA??????) ) and are either ISUP messages (call control) or TCAP/SCCP messages

 (INAP queries, LNP(local number portability) dips, location services).  To understand ISUP messaging

 requires understanding how telephone switches communicate with each other for

making telephone calls in the network.  From purely a protocol perspecfic,

 examples can be found in any good book written on telecommunications that has at

 least a section on SS7 (its done once again.

 You will see three books (that are old enough they should be at a

 library) mentioned here:

 http://www.openss7.org/faq13.html

(i have just arranged SS7 by travis Russel 4/ed) 

There is a tutorial on SS7 that many people recommend here:

 http://www.pt.com/tutorials/ss7/  (good one)

 There are better web resources: Google is your friend (I opened ITU-T’s Q.763 but it don’t give the exact value (in bytes) of any of the ISUP message (as there are optional parameters so how you calculate 35 or it used to be 45 when u were studying??) and one more thing that there are 39 messages to be used in different occasion).

 What you need to do is to take the message format for a typical ISUP

call flow IAM, ACM, ANM/CPG, REL, and RLC message and count up the number of

bytes for each and then add(each one separately or individually as IAM will come first and this data will pass on to IP via M3UA and after ,say, 10 minutes when call is finished then the REL will be generated by ss7 and then go to SG and converted in IP via M3UA and go across so if we add 175 altogether in one M3UA header we will miss the over head added by M3UA each time isup message is generated ) in the overhead of the M3UA DATA message (what after that as I have to know about the rate (and rate is a quantity with respect to time and please tell that what effect does the length of call will put on isup message and on M3UA message)).  The IAM is

difficult as it can contain many optional parameters that depend upon

 the specific country of operation, the features associated with the call,

 and the position in the switching hierarchy.  IAM message use to be about 45

 bytes in Canada back when I used to do network engineering, but LNP and other

 things have probably raised that to about 60 bytes.  The other mesages do no

 normally carry many optional parameters except the REL.  Note that unsuccessful

 calls also use almost as many messages (but there are still isup messages flowing between nodes during ANM and REL what about them??).  All in all the order-of-manitude

 rule of thumb (please do tell me where you got this rule of thumb from although I agree that typical ISUP messages(for a typical call) are 5 so I can use this as the basis of taking 5 messages) used to be to estimate that a call takes 5 messages and that the

 average length of the messages is 35 bytes(is this a rule of thumb as well and if so where you get this as well????) (I can't remember whether that

 included the FSN/BSN and RL, I'm pretty sure it did (but fsn/bsn are part of every signaling unit and MSU???)) so about 175 bytes per call ( so u are saying that if call is ,let say, for 10 minutes so it has the same number of bytes generating as for the one which last for ,say, 20 minutes).

If you need refined numbers you would have to actually capture SS7 or

 M3UA

traffic from a real network and analyze it statistically or using a

 traffic

model.  Modelling of traffic in a telephone network is an entire field

 of

study.

>    M2UA

M2UA carries a little more of the SS7 message in the MAUP data (it

 includes

FSN/BSN whereas M3UA does not (are these fsn/bsn form SIGTRAN protocols or the one with the Signaling Units of SS7 because SU have fsn/bsn as fixed part of it???  And above you have written that in 35 bytes fsn/bsn are included for isup messages so if they do then how come after reaching at M3UA they are detached from it)).  FSN/BSN are 2 bytes for each message.

See section 3 in RFC 3331.

>    M2PA

M2PA does not carry FSN/BSN from the SS7 message, but adds its own in

 the User

Data message whose format is given in section 2.3.1 of RFC 4165.

>    Need your help and guidance

>    hope to get reply soon

If you need more guidance, I suggest that you consult with the people

 at

your learning institution that assigned the project to you (the project is assigned to me by my institution but those people has told me straight that they have very little or no knowledge of this and I took it as a challenge moreover the time given to me for this is very short but I am still very much confident that I will be able to do this in time) 

I would like to thank you for your sincere help as this mail helps me a lot in making my concepts clearer 

and also for not telling the answer straight away.

 Hope you will keep on helping me during this project.

KR

ALI

---------------------------------
Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Jun 2007 00:16:27 -0600

ali,

ali ovaisi wrote:                               (Wed, 27 Jun 2007 04:59:27)
>
>
> (i totally agree and it should be the case that SS7 messages will be wrap up
> in the M3UA packets to move from IP network and nothing to do with VoIP
> except that SIGTRAN (eg M3UA) over head is added in signaling gateway
> (whether the complete ss7 message is encapsulated or break up into chunks in
> M3UA??????) ) 

The maximum narrow-band SS7 message length is 272 octets.  ISUP messages are
almost never that large (including IAMs which are the largest of ISUP
messages).  SIGTRAN uses IP which has an minimum MTU of 536 (no, its larger,
someone help me here) but is normally larger.  The point is there is never
any reason for SIGTRAN to break an SS7 message into multiple chunks, so you
can assume one DATA Chunk header overhead per SS7 message.

> (I opened ITU-Ts Q.763 but it dont give the exact value (in bytes) of any of
> the ISUP message (as there are optional parameters so how you calculate 35
> or it used to be 45 when u were studying??) and one more thing that there
> are 39 messages to be used in different occasion).

The length of the messages containing mandatory variable parameters or
optional parameters (such as the IAM) are not fixed; however, they are
bounded.  The minimum length of the message is the length of the message
including only mandatory fixed and mandatory variable parameters (of minimum
possible length).  The maximum length of the message is the length of the
message including all mandatory fixed, mandatory variable parameters (of
maximum possible length) and all optional parameters (of maximum possible
length).

Usually, the only messages that will contain variable parameters of any
concern are the IAM and the CPG (possibly the REL/RLC in some protocol
variants).  Whether a particular traffic flow contains a given optional
parameter, and the length of the mandatory variable and optional parameters,
depends upon the precise protocol variant (ITU-T, ETSI, ANSI), the traffic in
question (e.g.  international, national tandem, local tandem, ingress or
egress), and the features used by the call (e.g. ISDN access transport, DISA,
local number portability, malicious call trace, emergency, call forwarding
(redirect), release to voice mail, etc.)  The protocol variant can be
determined by the country within which the messaging occurs; the type of
traffic, from the position within the telephone network;  the features used,
by service penetration levels and usage studies for the particular operator.

The point here is: you cannot calculate it because you have too many unknowns,
you can only estimate it.

> >
> > What you need to do is to take the message format for a typical ISUP call
> > flow IAM, ACM, ANM/CPG, REL, and RLC message and count up the number of
> > bytes for each and then add
>
> (each one separately or individually as IAM will come first and this data
> will pass on to IP via M3UA and after ,say, 10 minutes when call is finished
> then the REL will be generated by ss7 and then go to SG and converted in IP
> via M3UA and go across so if we add 175 altogether in one M3UA header we
> will miss the over head added by M3UA each time isup message is generated )

(IAM + ACM + ANM/CPG + REL + RLC) + (M3UA overhead for the 5 messages).

The M3UA overhead for the 5 messages could be 5 times the overhead for a
single message, or could be less if SCTP is bundling messages from many
calls in to the same packet.

> >
> > in the overhead of the M3UA DATA message
>
> (what after that as I have to know about the rate (and rate is a quantity
> with respect to time and please tell that what effect does the length of
> call will put on isup message and on M3UA message)).

You originally asked the rate of SS7oIP traffic given a rate of VoIP traffic.

So, if you calculate, say, 1600 bits per call, then for a VoIP traffic
rate of 300 calls per second, you will have, expressed in bits per second,
an SS7oIP rate of 1600 x 300 = 480,000 bits per second.  As there are about 5
messages per call, you will have an SS7oIP rate, expressed in messages per
second, of 5 x 300 = 1500 messages per second.

The length of the call does not affect the signalling rate in any significant
way.

> >
> > The IAM is difficult as it can contain many optional parameters that
> > depend upon the specific country of operation, the features associated
> > with the call, and the position in the switching hierarchy.  IAM message
> > use to be about 45 bytes in Canada back when I used to do network
> > engineering, but LNP and other things have probably raised that to about
> > 60 bytes.  The other mesages do no normally carry many optional parameters
> > except the REL.  Note that unsuccessful calls also use almost as many
> > messages
>
> (but there are still isup messages flowing between nodes during ANM and REL
> what about them??).

Messages other than the IAM are very small in size compared to the size of the
IAM, but their size is easier to determine.

> >
> > All in all the order-of-manitude rule of thumb
>
> (please do tell me where you got this rule of thumb from although I agree
> that typical ISUP messages(for a typical call) are 5 so I can use this as
> the basis of taking 5 messages)

The rule of thumb comes from 20 years of traffic engineering experience.

> >
> > used to be to estimate that a call takes 5 messages and that the average
> > length of the messages is 35 bytes
>
> (is this a rule of thumb as well and if so where you get this as well????)

Again, from experience.  If you take a 45 byte IAM and add length of the other
messages and then divide by 5, you will get about 35.  Just works that way.
Engineering estimation is all about remembering these results.

>
> > (I can't remember whether that included the FSN/BSN and RL, I'm pretty
> > sure it did
>
> (but fsn/bsn are part of every signaling unit and MSU???))

What I mean was whether 45 bytes included the length of the BSN/FSN and RL
whether it was excluded from the size (i.e. the 45 bytes represented the
length of only the ISUP part of the message) or was included (i.e. the 45
bytes represented the entire length of the SS7 message, including the BSN/FSN
and RL, which are not the ISUP part of the message).  But, as I recall, it
was the entire length of the IAM and therefore the 45 bytes was the length of
the entire IAM, including the length of the BSN/FSN and RL.

>
> > so about 175 bytes per call
>
> ( so u are saying that if call is ,let say, for 10 minutes so it has the
> same number of bytes generating as for the one which last for ,say, 20
> minutes).

The same number of signalling bytes, yes.  You were seeking the SS7oIP rate
(signalling only) for a given VoIP traffic rate.

> > 
> > If you need refined numbers you would have to actually capture SS7 or M3UA
> > traffic model.  Modelling of traffic in a telephone network is an entire
> > field of study.
> > >
> > >  M2UA
> > 
> > includes FSN/BSN whereas M3UA does not
> 
> (are these fsn/bsn form SIGTRAN protocols or the one with the Signaling
> Units of SS7 because SU have fsn/bsn as fixed part of it ???  And above you
> have written that in 35 bytes fsn/bsn are included for isup messages so if
> they do then how come after reaching at M3UA they are detached from it)).

I'm sorry.  M2UA MAUP Protocol Data messages do not include BSN/FSN, nor the
LI for that matter (unless it is TTC protocol variant, in which case it
includes the first octet of the LI).  Therefore, you need to subtract the
length of the BSN/FSN and LI from the length of the SS7 message before adding
the M2UA header.

> >
> > FSN/BSN are 2 bytes for each message.  See section 3 in RFC 3331.
> > 
> > >    M2PA
> > 
> > M2PA does not carry FSN/BSN from the SS7 message, but adds its own in the
> > User Data message whose format is given in section 2.3.1 of RFC 4165.
> > 
> > If you need more guidance, I suggest that you consult with the people at
> > your learning institution that assigned the project to you
> 
> (the project is assigned to me by my institution but those people has told
> me straight that they have very little or no knowledge of this and I took it
> as a challenge moreover the time given to me for this is very short but I am
> still very much confident that I will be able to do this in time)

You will not be able to calculate an accurate answer (too many unknowns): you
can get an order-of-magnitude approximation (the unknowns can be bounded).

> 
> I would like to thank you for your sincere help as this mail helps me a lot
> in making my concepts clearer and also for not telling the answer straight
> away.
>

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

---

From: Steve Hill <[email-masked]>
Date: Thu, 28 Jun 2007 09:28:42 +0100

> someone help me here) but is normally larger.  The point is there is never

The minimum MTU for IPv4 is 576 octets.  For IPv6 is has been increased to
1280 octets.

Usually an MTU of 1500 is used, which is the maximum ethernet payload
length (although there is a trend towards larger, so called "jumbograms"
on gigabit and 10 gigabit ethernet) although connections that are
tunnelled over another protocol will often have a lower MTU.

> can assume one DATA Chunk header overhead per SS7 message.

It should be noted that this is not strictly true for all SIGTRAN
protocols - SUA, for example, can carry messages much longer than a single
SS7 message.  (I realise this conversation was primarilly about M3UA/M2PA,
but your statement was a little ambiguous so I am just clarifying it)

-- 
 - Steve Hill
   Software Engineer

Dialogic (UK) Limited
21 Green Lane,
Fordingbridge
Hampshire
SP6 1HU
UK

Tel:    +44 (0) 1425 651 392
Mobile: +44 (0) 7976 911 174
Fax:    +44 (0) 1425 655 075
Email:  [email-masked]
Web:    www.dialogic.com

Dialogic (UK) Limited, Company Registration Number 2017909. Registered in
England and Wales. Registered Address Kings Chase, 107-123 King Street,
Maidenhead, Berkshire, SL6 1DP.

This e-mail is intended only for the named recipient(s) and may contain
information that is privileged, confidential and/or exempt from disclosure
under applicable law. No waiver of privilege, confidence or otherwise is
intended by virtue of communication via the internet. Any unauthorized use,
dissemination or copying is strictly prohibited. If you have received this
e-mail in error, or are not named as a recipient, please immediately notify
the sender and destroy all copies of this e-mail.

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Jun 2007 03:45:33 -0600

Steve,

Steve Hill wrote:                                (Thu, 28 Jun 2007 09:28:42)
> The minimum MTU for IPv4 is 576 octets.  For IPv6 is has been increased to

Thanks.
> but your statement was a little ambiguous so I am just clarifying it)

You clipped the point: narrow-band SS7 messages are 272 octets or
smaller so SIGTRAN never needs to break them across multiple DATA
Chunks.

Also, I do not think that you clarified it, as there is no 272 octet
limit for M3UA, M2UA nor M2PA either.  The 272 octet limit is imposed by
the narrow-band SS7 network (or by the expectation of the user part).
See for example:

SUA: RFC 3868/4.7.1: (Note that this also includes IPSP.)

 4.7.1.  Segmenting / Reassembly

   When it is expected that signalling messages will not fit into a PDU
   of the most restrictive transport technology used (e.g., 272-SIF of
   MTP3), then segmenting/reassembly could be performed at the SG, ASP
   or IPSP.  If the SG, ASP or IPSP is incapable of performing a
   necessary segmentation/reassembly, it can inform the peer of the
   failure using the appropriate error in a CLDR or RESRE/COERR message.

M3UA: RFC 4666/1.3.2.1:

1.3.2.1.  Support for the Transport of MTP3-User Messages

   ...

   The M3UA layer does not impose a 272-octet signalling information
   field (SIF) length limit as specified by the SS7 MTP Level 2 protocol
   [7,8,9].  Larger information blocks can be accommodated directly by
   M3UA/SCTP, without the need for an upper layer segmentation/
   re-assembly procedure as specified in recent SCCP or ISUP versions.
   However, in the context of an SG, the maximum 272-octet block size
   must be followed when interworking to a SS7 network that does not
   support the transfer of larger information blocks to the final
   destination.  This avoids potential ISUP or SCCP fragmentation
   requirements at the SGPs.  The provisioning and configuration of the
   SS7 network determines the restriction placed on the maximum block
   size.  Some configurations (e.g., Broadband MTP [19,20,22]) may
   permit larger block sizes.

ETSI TS 102 142 sets the maximum size to 272, regardless of this
passage.

M2UA: No limit on message size.  Any limits are set by the remote
signalling link.

M2PA: No limit on message size.  Any limits are set by the "applicable
standard".

So, in the context in which it was stated: there is no need for SIGTRAN
to ever break a *narrow-band* SS7 message into more than one DATA chunk.

I didn't want to confuse the student with further narrow-band vs.
broadband distinctions, but now it's too late. ;)

--brian

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 28 Jun 2007 13:24:43 +0200

Hi Steve,

just a quick note: The minimum MTU for IPv4 is 68 bytes (Up
to 60 bytes for the IP header, 8 bytes for the payload). 576
is the minimal size of the reassembly buffer.

Best regards
Michael