Re: Question related with DAUD Message

The problem is if the ASP totally depends on SG for the destination status, the SG has to have a way to guarantee that:
1) DAVA and DUNA won't get lost unless there is a bug in SG, however, although it is unlikely, we do need to have a "plan B", if it did happen. (It is possible that SG drops some messages due to defected overload management but does manage to recover without reset the link) 
2) After a association restarts, ASP would probably reset all the destination status that associated with this M3UA link to "unknown", and SG will have to send all the destination status to the ASP; the problem is if the SG uses some kind of default route, there is no way SG would know which destination status needs to report to ASP, in this case, ASP should probably send the DAUD to find out the status of destinations it cares.

So my personal opinion is for ASP to send the DAUD whenever it feels necessary (such as link restart). It is a safe way to make sure the ASP always know the most recent destination status with a little bit overhead, because if you have an ASP, you probably don't want to totally rely on the external NEs, especially there are third-party's products.
Luke

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Thursday, February 01, 2007 1:43 AM
To: [email protected]
Subject: Sigtran Digest, Vol 34, Issue 1

Send Sigtran mailing list submissions to
	[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/sigtran
or, via email, send a message with subject or body 'help' to
	[email protected]

You can reach the person managing the list at
	[email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Sigtran digest..."


Today's Topics:

   1. Re: Question related with DAUD Message (Brian F. G. Bidulock)
   2. Re: Question related with DAUD Message (Brian F. G. Bidulock)
   3. Re: Question related with DAUD Message (Ankit Kumar Sharma)


----------------------------------------------------------------------

Message: 1
Date: Wed, 31 Jan 2007 12:35:26 -0700
From: "Brian F. G. Bidulock" <[email protected]>
Subject: Re: [Sigtran] Question related with DAUD Message
To: Andrew Booth <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Andrew,

I am a little confused by your statements.  A couple of comments:

Andrew Booth wrote:                        (Wed, 31 Jan 2007 11:17:54)
> I think the ASP can send DAUD in any way it sees fit, according to the RFC.
> 
> The following comments are my own and are not specified in the RFC.
> 
> I think assuming that state is always synchronized is a dangerous
> assumption.  For instance, what if the SG is in overload and discards a
> DAVA?

SCTP is a reliable transport.  DAVAs don't go missing without
loss of the association.

> What if there's a bug on one end or the other?

Bugs can cause failures: serious bugs, serious failures.
Rigorous software test and field testing comes to mind ;)

> What if the ASP is connected to two SGPs and receives DUNA + DAVA from SGP1
> and DUNA + association loss from SGP2, in that order?

The concensus of the designers of the M3UA and SUA protocols
long ago (at about m3ua-06) was that SNMM are to be interpreted
by the ASP on a per-SG basis rather than a per-SGP basis.  For
example, when an AS receives DUNA from any SGP in the SG, it
means DUNA for the entire SG, not just the SGP that sent the
message.

> The main risk would probably be a missing DAVA, since a missing DUNA
> would get discovered by a response DUNA if traffic is sent to the
> destination.

The easier test instead of DAUD is to have the SCCP-User send
traffic.  ITU specs require a DUNA every 8 or 10 messages for
N-PCSTATE.  Nevertheless, back to the first question, why would
an SG "miss" a DAVA?

I do not understand why the SG would be designed in such way
that it gets a positive response to an SST and yet somehow
"discards" the DAVA.

If it is going to lose simple management state it certainly
cannot provide service and the better course of action would be
sending ASP Inactive Ack, ASP Down Ack, or dropping the SCTP
association.

You see, if it cannot issue the DAVA message, how can it expect
to be able to handle data traffic for the AS?  If it cannot
issue the DAVA message, how is it to issue a DAUD response?

> >From an operational standpoint I'd be careful sending DAUD with a big
> wildcard, since it's difficult to estimate how many responses you might
> get and how fast, so it's hard to avoid potential overloads.  Also, you
> won't necessarily know when you have all the responses (if you care).

If an SGP cannot handle sending DAUD responses for, say, 1024
point codes, how could it expect to handle traffic for same?
(E.g, 80 messages per second for each of the 1024 point codes.)
Management message are rare compared to the data traffic and
only represent a very small percentage of the engineered
bandwidth use between SGP and ASP.  If there is insufficient
bandwidth for an SGP to send management messages, there is
insufficient bandwidth for normal operation.  In that case,
"delaying" (I don't agree with discarding) a DAVA message is a
good thing.

> 
> Other than that, it's more bandwidth efficient to send multiple affected
> PCs in one message, but that's only a concern if you're running over
> bandwidth constrained networks or auditing many PCs.  So, take your pick.

Again, management messages is a very small fraction of the
engineered bandwidth for data traffic.  If management messages
cannot be exchanged, neither can normal traffic.  Both the SGP
and ASP have all the protocol means necessary for indicating
same (ASP Inactive procedures, ASP Down procedures, and SCTP
communications lost procedures.)

--brian

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



------------------------------

Message: 2
Date: Wed, 31 Jan 2007 13:05:53 -0700
From: "Brian F. G. Bidulock" <[email protected]>
Subject: Re: [Sigtran] Question related with DAUD Message
To: "Colmenares, Oscar (Oscar)" <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

Oscar,

Some implementations of SCCP provide local management primitives
that permit the SCCP-User to query the local SCCP-provider to
determine the state of subsystems and SCCP for associated point
codes.  For SUA ASP-SG operation, the SCCP-provider is at the SG
and the SCCP-User at the ASP.  DAUD provides a mechanism that
can be used by SCCP-Users at the ASP using legacy management
interfaces to peform a like function.

Other implementation of SCCP use the normal responsive method
described by ITU specifications.  Under the method when the
SCCP-User requests transfer of traffic (N-DATA-Request,
N-UNITDATA-Request) to unavailable subsystems, it is informed on
a responsive basis (N-INFORM-Indication) every 8 or 10 requests.
In this way the SCCP-User does not have to maintain state but
can blindly send messages.

Some SUA implementations might prefer to maintain SCCP-Provider
management state at the ASP.  Others might leave it at the SCCP
layer in the SG (where I think it belongs).  The DUNA procedures
provide a protocol mechanism to accomplish this.  An SUA
implementation that choses to maintain SCCP-Provider management
state at the ASP can use the explicit and periodic DAUD
procedures to keep that management state synchronized with the
SCCP-Provider at the SG.  An SUA implementation that chooses to
leave SCCP-Provider management state at the SG has little need
for periodic DAUD procedures.

As to whether multiple responses should be grouped into one
message or not, it is pretty much up to the SGP.  The form of
the response is usable.

At any point in time in the SS7 network, subsystems and remote
SCCPs are mostly available.  The easiest way to reduce the size
of SNMM messages sent in response to DAUD is to send SCON for
listing congested subsystems, then DAVA(*) indicating all
subsystems are available,  immediately followed by DUNA listing
only the unavailable subsystems/point codes (all sent ordered on
SCTP stream 0).  This should result in only two or three really
small messages.  Note also that subsystems are only informed of
the N-STATE and N-PCSTATE of subsystems and point codes for
which they are concerned (as indicated by the RC in the DAUD
message), which is also a short list.  SGs do not need to limit
the size of responses as management messages are rare compated
to traffic.  An ASP might want to somehow limit the rate at which
it sends DAUD(*) to better utilize the SCTP association, however,
it is up to the ASP how it wishes to utilize its available
bandwidth and the SG simply responds to any request.

IMO is not not up to the SG to limit sending the responses
either in size or frequency.  The ASP that wishes to avoid
inefficient use of the available bandwidth is welcome to send
fewer DAUD messages, or to send DAUD messages with a narrower
response (i.e. DAUD(5-5-5) instead of DAUD(*)).

I hope that addresses your questions with regard to DAUD.

--brian


Colmenares, Oscar (Oscar) wrote:             (Wed, 31 Jan 2007 08:43:55)
> 
> Sigtran Experts
> 
> 	I was looking for some help related with how to set the DAUD
> message, I was reading some message from HS Jang related when the ASP need
> to use the DAUD message, explain as follow
> 
> Let me summarize about DAUD in SUA ASP with your postings and my
> understanding. first of all,
>  1) ASP does not need to send DAUD in normal situation. because SCCP in SG
> cares it with its mechanism and inform the ASP of the changes in DPC/SSN
> with SSNM message. i.e. the state information about destinations are
> synchronized all the time.
>  2) the only time ASP needs to send DAUD is when the ASP is recovered from
> isolation because ASP has no state information about destinations now. ( but
> this is also not necessary for normal operation of data transfer. it is only
> necessary when ASP really wants to know the state information of
> destinations for example, in the respect of OAM or something ) 
> 3) there are mentions about sending DAUD periodically in RFC but it is
> somewhat wrong. 
> 	
> 	Now base on these explanation and related with point 2, send DAUD
> message when the ASP is recovered from isolation, my question is there is
> any rules in other to how to send these point codes?? do we have or must
> send multiple messages with one point code information per message, or send
> just one message with all the point codes information???
> 
> 	The main idea here is understand if I have a system with multiple
> point codes, for example 25 point codes, how the standard said we need to
> send the DAUD message, just one message with all the point codes inside or
> 25 single messages with just one point code per message.
> 
> I really appreciate your help on this question
> 
> Best regards
> 
> Oscar
> 
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran

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



------------------------------

Message: 3
Date: Thu, 1 Feb 2007 09:43:08 +0000
From: "Ankit Kumar Sharma" <[email protected]>
Subject: Re: [Sigtran] Question related with DAUD Message
To: "Barry Nagelberg" <[email protected]>
Cc: SIGTRAN Mailing List <[email protected]>
Message-ID:
	<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"

On 1/31/07, Barry Nagelberg <[email protected]> wrote:
>
> Oscar,
>
> There is nothing in the RFC which states that "there is no limit to the
> number of point codes in the DAUD (or DUNA or
> DAVA)".


Max limit could be calculated from the  max value of 'length'  parameter

This is an interoperability bug in the RFC, because obviously there must be
> some limit - an SGP could run out of
> resources if the ASP sends it a DAUD msg with a billion point codes. A
> limit of 1024 sounds reasonable to me.


Not billion...we could send maximum 16382 point codes in a DAUD

The main point facing us now is that the size of the limit is an
> implementation decision for each vendor. I suggest that
> the RFC be updated to state explicity what the limit is - otherwise this
> will continue to cause interoperability
> problems.


I agree with you...

Barry Nagelberg
>
> -----Original Message-----
> From: Colmenares, Oscar (Oscar) [mailto:[email protected]]
> Sent: Wednesday, January 31, 2007 12:23 PM
> To: Ankit Kumar Sharma; Colmenares, Oscar (Oscar)
> Cc: Andrew Booth; [email protected]
> Subject: RE: [Sigtran] Question related with DAUD Message
>
>
>
> Ankit
>
>     This part sound better for me, do you have the RFC that mentioned that
> there is not limit on the number of point
> codes in DAUD message, I will need this in order to talk with our SG
> provider??
>
>     Also can I share your email with people from my company and the
> customer???? Or this could be a problem for you?
>
> Regards
>
> Oscar
> -----Original Message-----
> From: Ankit Kumar Sharma [mailto:[email protected]]
> Sent: Miércoles, 31 de Enero de 2007 01:15 p.m.
> To: Colmenares, Oscar (Oscar)
> Cc: Andrew Booth; [email protected]
> Subject: Re: [Sigtran] Question related with DAUD Message
>
>
> I have also faced this problem in past. Some stack vendors limit it on no.
> of point codes in DAUD message and some on
> the length of DAUD message(DAUD message greater than xx limit would get
> discarded).
> If I am not wrong then as per RFC, there isn't any limit on number of
> Point codes in DAUD. If any vendor is not
> following this then its a bug in their stack.
> I think there should be some upper limit set on number of Point codes in
> DAUD for better interworking.
>
> cheers,
> Ankit
>
>
> On 1/31/07, Colmenares, Oscar (Oscar) <[email protected]>
> wrote:
>
> Andrew
>
>         My concern here is that is multiple ASP and SG providers are
> having
> their own interpretation to the standard and we can have inter-operability
> problems in the future.
>
>         So far we as an ASP we are trying to implement multiple point
> codes
> in the same DAUD message and we can support up to 1024 point codes but the
> SG interpretation was to set a limit in the numbers of point codes per
> DAUD
> message up to 16, so we are facing some developments problems due
> different
> interpretations.
>
>         I think it will be a good idea to have a recommendation from the
> Sigtran expert as how this should work in order to align all the ASP and
> SG
> and define a way to use this kind of message.
>
>         So my answer here will be, this help but not enough due there is
> no
> way to decide who is right or wrong performing this setting in the
> message.
>
>         Please if you or your team have recomendations in how to set this
> (something official) please let us know, because this is very important
> for
> us.
>
> Regards
>
> Oscar
>
> -----Original Message-----
> From: Andrew Booth [mailto:[email protected] ]
> Sent: Miércoles, 31 de Enero de 2007 12:18 p.m.
> To: Colmenares, Oscar (Oscar)
> Cc: [email protected]
> Subject: Re: [Sigtran] Question related with DAUD Message
>
>
> I think the ASP can send DAUD in any way it sees fit, according to the
> RFC.
>
> The following comments are my own and are not specified in the RFC.
>
> I think assuming that state is always synchronized is a dangerous
> assumption.  For instance, what if the SG is in overload and discards a
> DAVA?  What if there's a bug on one end or the other?  What if the ASP
> is connected to two SGPs and receives DUNA + DAVA from SGP1 and DUNA +
> association loss from SGP2, in that order?
> The main risk would probably be a missing DAVA, since a missing DUNA
> would get discovered by a response DUNA if traffic is sent to the
> destination.
>
> >From an operational standpoint I'd be careful sending DAUD with a big
> wildcard, since it's difficult to estimate how many responses you might
> get and how fast, so it's hard to avoid potential overloads.  Also, you
> won't necessarily know when you have all the responses (if you care).
>
> Other than that, it's more bandwidth efficient to send multiple affected
> PCs in one message, but that's only a concern if you're running over
> bandwidth constrained networks or auditing many PCs.  So, take your pick.
>
> Does that help?
> Andrew
>
> Colmenares, Oscar (Oscar) wrote:
> > Sigtran Experts
> >
> >       I was looking for some help related with how to set the DAUD
> > message, I was reading some message from HS Jang related when the ASP
> need
> > to use the DAUD message, explain as follow
> >
> > Let me summarize about DAUD in SUA ASP with your postings and my
> > understanding. first of all,
> >  1) ASP does not need to send DAUD in normal situation. because SCCP in
> SG
> > cares it with its mechanism and inform the ASP of the changes in DPC/SSN
> > with SSNM message. i.e. the state information about destinations are
> > synchronized all the time.
> >  2) the only time ASP needs to send DAUD is when the ASP is recovered
> from
> > isolation because ASP has no state information about destinations now. (
> but
> > this is also not necessary for normal operation of data transfer. it is
> only
> > necessary when ASP really wants to know the state information of
> > destinations for example, in the respect of OAM or something )
> > 3) there are mentions about sending DAUD periodically in RFC but it is
> > somewhat wrong.
> >
> >       Now base on these explanation and related with point 2, send DAUD
> > message when the ASP is recovered from isolation, my question is there
> is
> > any rules in other to how to send these point codes?? do we have or must
> > send multiple messages with one point code information per message, or
> send
> > just one message with all the point codes information???
> >
> >       The main idea here is understand if I have a system with multiple
> > point codes, for example 25 point codes, how the standard said we need
> to
> > send the DAUD message, just one message with all the point codes inside
> or
> > 25 single messages with just one point code per message.
> >
> > I really appreciate your help on this question
> >
> > Best regards
> >
> > Oscar
>
>
> _______________________________________________
> Sigtran mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/sigtran
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www1.ietf.org/pipermail/sigtran/attachments/20070201/24080de3/attachment.html

------------------------------

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


End of Sigtran Digest, Vol 34, Issue 1
**************************************